DevOps

What is Packer? Packer is an open-source tool from HashiCorp that automates the creation of machine images. Think of it as a “factory” that takes a base image (Ubuntu, CentOS, Windows) and produces consistent, pre-configured VM or cloud images ready for deployment. Instead of manually preparing servers or VMs, you define everything in a template, and Packer does the work. Key Features Multi-platform builds — Create images for AWS AMI, Azure, Google Cloud, VMware, VirtualBox, Docker, and more, all at once. Immutable infrastructure — Instead of configuring servers after they start, you ship pre-baked images. Automation-friendly — Works well with CI/CD pipelines. Extensible — Supports plugins for provisioners (e.g., Ansible, Chef, Puppet, shell scripts). Example: Simple Packer Template { "builders": [{ "type": "docker", "image": "ubuntu:20.04", "commit": true }], "provisioners": [{ "type": "shell", "inline": ["apt-get update", "apt-get install -y nginx"] }] } What happens here: Start with ubuntu:20.04 Docker image. Run provisioning (install Nginx). Save the result as a new Docker image. When to Use Packer Building goldeggn images for production (with pre-installed dependencies). Standardizing environments across multiple clouds. Speeding up autoscaling by using pre-baked images. Conclusion Packer helps developers and DevOps engineers avoid “snowflake servers” and instead work with predictable, automated images. If your infrastructure spans multiple platforms, Packer is a great way to keep things consistent. ...

By default, Kubernetes does not automatically restart a Deployment when its ConfigMap changes. This can lead to situations where your pods keep running with outdated configuration until you trigger a rollout manually. Fortunately, there are common patterns to solve this. Why It Happens Kubernetes mounts ConfigMaps into pods as files or environment variables, but the Deployment controller does not track changes in ConfigMap content. That means no automatic restart. Solution Checksum annotations: Add a hash of the ConfigMap into the Deployment’s pod template annotations. Example in Helm: ...

What are SLO, SLA, and SLI? If you’ve ever dived into SRE (Site Reliability Engineering) or service monitoring, you’ve likely seen three mysterious abbreviations: SLO, SLA, and SLI. They might look similar, but they play different roles in how we measure and guarantee reliability. SLI — Service Level Indicator This is a metric that tells you how your service is doing. Examples: Latency (e.g., “response time of API requests”) Availability (e.g., “percentage of successful requests”) Error rate (e.g., “number of 5xx responses”) 👉 Think of SLI as a thermometer — it measures the state of your system. ...

What is a Percentile in Observability? When we talk about observability, especially metrics like latency, we often hear terms such as p50, p95, or p99. These are percentiles. They give us a way to understand not just the average behavior of a system, but how it performs for the majority (or the unlucky few) of requests. Simple Definition A percentile tells you the value below which a given percentage of measurements fall. ...

Introduction etcd is a distributed key-value store that plays a critical role in Kubernetes by storing cluster configuration and state. When etcd runs into problems, it can cause cluster instability or downtime. This article covers common etcd errors, their underlying causes, and actionable solutions. 1. etcdserver: request timed out ❓ Cause Occurs when etcd members can’t communicate efficiently, often due to network issues or disk I/O latency. 🛠️ Solution Check disk performance: iostat -xz 1 Ensure etcd data is on SSD storage. Check network latency and connectivity between cluster members: ping <etcd-member-IP> 2. etcdserver: leader changed ❓ Cause This is often seen when leadership changes too frequently, indicating instability in the etcd cluster. ...