DevOps Day 58: Deploying Grafana and Attaching Azure Disk
A technical log of DevOps Day 58 covering KodeKloud tasks: deploying Grafana via Kubernetes manifest files, exposing it with NodePort, attaching a managed disk to an Azure VM, and analyzing CLI differences.
Stock photo for illustration only, not from the actual event
- Day 58 DevOps learning logs focus on one Kubernetes task and one Azure task from the KodeKloud platform.
- Deploying Grafana via a Kubernetes Deployment and exposing it on port 32000 using a NodePort Service.
- Attaching an existing managed disk to an Azure VM and analyzing property name formatting in Azure CLI versions.
The DevOps learning journey reaches Day 58 and Day 8 on Azure, highlighting the operational gap between "created" and "working". Tasks often report successful deployment or attachment before the internal agent or operating system is fully ready to serve traffic. Today's hands-on tasks from the KodeKloud platform cover both a Kubernetes deployment and an Azure storage management exercise.
The first task involves creating a Deployment named grafana-deployment-datacenter running the Grafana image, exposed via a NodePort Service on port 32000. A single configuration file can hold both objects separated by a triple-dash line. The Deployment, pod template, and Service are linked strictly through the matching label app: grafana without explicit cross-referencing names.
Stock photo for illustration only, not from the actual event
Applying the manifest using kubectl apply and verifying the status with kubectl get commands confirms that the Deployment shows READY 1/1 and the Service displays the correct port mappings. When node IPs are unreachable, kubectl port-forward provides local access. Initial sign-in requires using admin for both username and password, followed by a mandatory password change prompt.
The discrepancy between container readiness (1/1) and actual application availability highlights why liveness and readiness probes are critical in Kubernetes. Without explicit probes, kubelet considers a container successful the moment it starts, missing the internal initialization time required by complex services like Grafana.
The sample manifest falls short of Grafana's official recommendations in several areas. Official guidelines specify higher minimum memory and CPU limits to prevent out-of-memory issues. Furthermore, because Grafana defaults to an embedded SQLite database stored inside the container, failing to mount external storage means all dashboards and user configurations will be lost if the pod is replaced.
"By default, Grafana uses an embedded SQLite version 3 database to store configuration, users, dashboards, and other data."
Grafana Documentation
The second task requires attaching an existing disk named datacenter-disk to a running Azure VM named datacenter-vm. Azure automatically assigns the lowest available LUN, which in this case is 0, while the VM remains operational throughout the process. The attached disk remains raw with no partition or filesystem, as requested by the task scope.
Stock photo for illustration only, not from the actual event
Querying disk size properties via Azure CLI commands revealed nuanced differences in JSON output structures between commands like az disk show and az vm show, emphasizing how case sensitivity and CLI version updates can influence query results and JMESPath evaluations.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment