[{"content":"If you\u0026rsquo;ve heard the word \u0026ldquo;DevOps\u0026rdquo; thrown around and nodded along without really knowing what it means, you\u0026rsquo;re in the right place. Let\u0026rsquo;s clear it up.\nDevOps in one sentence DevOps is a culture and set of practices that bring software development (Dev) and IT operations (Ops) together to deliver software faster, more reliably, and with fewer headaches.\nIt\u0026rsquo;s not a single tool. It\u0026rsquo;s not a job title you buy off a shelf. It\u0026rsquo;s a way of working.\nThe problem DevOps solves In the old days, teams were split:\nDevelopers wrote code and \u0026ldquo;threw it over the wall.\u0026rdquo; Operations had to deploy and run that code, often with no context. The result? Slow releases, finger-pointing (\u0026ldquo;it works on my machine!\u0026rdquo;), and outages. DevOps tears down that wall.\nThe DevOps lifecycle DevOps is often drawn as an infinity loop because the work never really stops, it continuously improves:\nPlan — decide what to build Code — write the application Build — compile and package it Test — automatically verify it works Release — prepare it for production Deploy — ship it to users Operate — keep it running Monitor — watch, learn, and feed back into planning Plan → Code → Build → Test → Release → Deploy → Operate → Monitor ↑ │ └────────────────────── feedback ───────────────────────┘ The core principles Collaboration — Dev and Ops share ownership and goals. Automation — automate repetitive work (testing, builds, deployments). Continuous Improvement — measure, learn, and get a little better every cycle. Fast feedback — catch problems early, fix them fast. What about all those tools? Tools like Docker, Kubernetes, Terraform, and GitHub Actions support DevOps practices, but they aren\u0026rsquo;t DevOps itself. A team can have every tool and still not \u0026ldquo;do DevOps\u0026rdquo; if the culture isn\u0026rsquo;t there.\nYou\u0026rsquo;ll learn those tools step by step in this series. Don\u0026rsquo;t worry about them yet.\nKey terms you\u0026rsquo;ll hear Term Meaning CI Continuous Integration — automatically build \u0026amp; test code on every change CD Continuous Delivery/Deployment — automatically release code IaC Infrastructure as Code — manage servers via code, not clicks Pipeline An automated sequence of build/test/deploy steps What\u0026rsquo;s next? Now that you know what DevOps is, it\u0026rsquo;s time to build the foundation every DevOps engineer needs: the Linux command line.\n👉 Next up: Linux Basics for DevOps\n","permalink":"https://devopsadda.in/posts/what-is-devops/","summary":"Understand what DevOps really means, why it exists, and the lifecycle behind shipping modern software.","title":"What is DevOps? A Beginner's Guide"},{"content":"Servers run Linux. Containers run Linux. CI runners run Linux. If you want to do DevOps, you need to be comfortable at the Linux command line. Let\u0026rsquo;s get you there.\nTip: On Windows? Install WSL2. On macOS? The Terminal is already Unix-based. Otherwise, spin up an Ubuntu virtual machine.\nGetting around the filesystem pwd # print working directory (where am I?) ls # list files ls -lah # list with details, including hidden files cd /etc # change directory cd ~ # go to your home directory cd .. # go up one level Working with files and folders mkdir projects # create a directory touch notes.txt # create an empty file cp notes.txt backup.txt # copy mv backup.txt old.txt # move or rename rm old.txt # delete a file rm -r projects # delete a directory and its contents Reading and editing files cat file.txt # print the whole file less file.txt # scroll through a large file (q to quit) head -n 20 file.txt # first 20 lines tail -n 20 file.txt # last 20 lines tail -f app.log # follow a log in real time nano file.txt # simple terminal editor Permissions (the part that trips everyone up) Every file has an owner, a group, and permissions for read (r), write (w), and execute (x).\nls -l script.sh # -rwxr-xr-- 1 user group 0 Jan 1 12:00 script.sh chmod +x script.sh # make a file executable chmod 644 file.txt # owner read/write, others read chown user:group f # change ownership Quick guide to the numbers: 4 = read, 2 = write, 1 = execute. Add them up per group (owner/group/others). So 755 = rwxr-xr-x.\nProcesses ps aux # list running processes top # live process view (q to quit) kill 1234 # stop process with PID 1234 kill -9 1234 # force kill Networking basics ping google.com # check connectivity curl https://api.io # make an HTTP request curl -I https://site # headers only ss -tulpn # list listening ports Package management (Ubuntu/Debian) sudo apt update # refresh package lists sudo apt install nginx # install a package sudo apt remove nginx # remove a package Piping and redirection This is where the shell gets powerful, you chain commands together:\ncat access.log | grep \u0026#34;404\u0026#34; | wc -l # count 404s in a log ls -l \u0026gt; files.txt # write output to a file echo \u0026#34;hello\u0026#34; \u0026gt;\u0026gt; notes.txt # append to a file Practice challenge 🏋️ Try this end to end:\nCreate a folder called devops-practice. Inside it, create a file hello.sh containing echo \u0026quot;Hello DevOps\u0026quot;. Make it executable and run it with ./hello.sh. mkdir devops-practice cd devops-practice echo \u0026#39;echo \u0026#34;Hello DevOps\u0026#34;\u0026#39; \u0026gt; hello.sh chmod +x hello.sh ./hello.sh If you saw Hello DevOps printed, congrats, you just wrote and ran your first script. 🎉\nWhat\u0026rsquo;s next? You can move around Linux now. Time to learn how teams track and share code.\n👉 Next up: Git \u0026amp; GitHub Crash Course\n","permalink":"https://devopsadda.in/posts/linux-basics-for-devops/","summary":"Master the essential Linux commands every DevOps engineer uses daily — files, permissions, processes, and networking.","title":"Linux Basics for DevOps"},{"content":"Git tracks every change to your code so you can collaborate, experiment safely, and never lose work. GitHub hosts that code online. Together they\u0026rsquo;re the backbone of modern software teams.\nOne-time setup git config --global user.name \u0026#34;Your Name\u0026#34; git config --global user.email \u0026#34;you@example.com\u0026#34; Starting a repository git init # turn a folder into a Git repo git clone \u0026lt;url\u0026gt; # copy an existing repo from GitHub The core workflow Git has three areas: your working directory, the staging area, and the repository.\ngit status # what\u0026#39;s changed? git add file.txt # stage a specific file git add . # stage everything git commit -m \u0026#34;message\u0026#34; # save a snapshot git log --oneline # view history Think of it like packing a box: add puts items in the box, commit seals and labels it.\nBranching Branches let you work on features without touching the main code.\ngit branch feature-login # create a branch git checkout feature-login # switch to it git checkout -b feature-x # create AND switch in one step git merge feature-login # merge a branch into the current one Working with GitHub git remote add origin \u0026lt;url\u0026gt; # link your repo to GitHub git push -u origin main # upload your commits git pull # fetch and merge remote changes A typical day-to-day flow git checkout -b add-readme # 1. branch off echo \u0026#34;# My Project\u0026#34; \u0026gt; README.md # 2. make changes git add README.md # 3. stage git commit -m \u0026#34;Add README\u0026#34; # 4. commit git push -u origin add-readme # 5. push # 6. Open a Pull Request on GitHub for review Pull Requests (PRs) A Pull Request is how you propose your changes to a project. Teammates review it, leave comments, and approve before it merges into main. PRs are where code review and collaboration happen, a core DevOps practice.\nHandy recovery commands git diff # see unstaged changes git restore file.txt # discard changes to a file git reset --soft HEAD~1 # undo last commit, keep changes git stash # shelve changes temporarily git stash pop # bring them back A good .gitignore Don\u0026rsquo;t commit secrets or junk. Create a .gitignore:\nnode_modules/ .env *.log .DS_Store Practice challenge 🏋️ Create a new repo on GitHub. Clone it locally. Add a README.md, commit, and push. Create a branch, make a change, push it, and open a Pull Request. What\u0026rsquo;s next? You can track and share code. Now let\u0026rsquo;s automate repetitive tasks with scripting.\n👉 Next up: Bash Scripting for Beginners\n","permalink":"https://devopsadda.in/posts/git-github-crash-course/","summary":"Learn version control with Git: commits, branches, merges, and collaborating on GitHub.","title":"Git \u0026 GitHub Crash Course"},{"content":"The golden rule of DevOps: if you do something more than twice, automate it. Bash scripting is your first automation superpower.\nYour first script Create a file hello.sh:\n#!/bin/bash echo \u0026#34;Hello, DevOps!\u0026#34; The first line (#!/bin/bash) is the shebang, it tells the system to run this with Bash. Then make it executable and run it:\nchmod +x hello.sh ./hello.sh Variables #!/bin/bash name=\u0026#34;DevOps Adda\u0026#34; echo \u0026#34;Welcome to $name\u0026#34; # Capture command output today=$(date +%F) echo \u0026#34;Today is $today\u0026#34; Use quotes around variables (\u0026quot;$name\u0026quot;) to avoid surprises with spaces.\nTaking input #!/bin/bash read -p \u0026#34;What\u0026#39;s your name? \u0026#34; user echo \u0026#34;Hi $user, let\u0026#39;s automate something!\u0026#34; Conditionals #!/bin/bash if [ -f \u0026#34;/etc/passwd\u0026#34; ]; then echo \u0026#34;The file exists.\u0026#34; else echo \u0026#34;Not found.\u0026#34; fi Common test flags: -f (file exists), -d (directory exists), -z (string empty), -eq/-ne/-gt/-lt (number comparisons).\nLoops #!/bin/bash # Loop over a list for service in nginx docker ssh; do echo \u0026#34;Checking $service...\u0026#34; done # Loop over files for file in *.log; do echo \u0026#34;Found log: $file\u0026#34; done # While loop count=1 while [ $count -le 3 ]; do echo \u0026#34;Attempt $count\u0026#34; count=$((count + 1)) done Functions #!/bin/bash greet() { echo \u0026#34;Hello, $1!\u0026#34; # $1 is the first argument } greet \u0026#34;World\u0026#34; greet \u0026#34;DevOps\u0026#34; A practical example: a backup script #!/bin/bash SOURCE=\u0026#34;/home/user/project\u0026#34; DEST=\u0026#34;/backups\u0026#34; STAMP=$(date +%Y%m%d-%H%M%S) mkdir -p \u0026#34;$DEST\u0026#34; tar -czf \u0026#34;$DEST/backup-$STAMP.tar.gz\u0026#34; \u0026#34;$SOURCE\u0026#34; echo \u0026#34;Backup created: $DEST/backup-$STAMP.tar.gz\u0026#34; Scheduling with cron Run scripts automatically on a schedule:\ncrontab -e Add a line (this runs the backup every day at 2 AM):\n0 2 * * * /home/user/backup.sh The five fields are: minute hour day-of-month month day-of-week. Use crontab.guru to decode schedules.\nGood habits Add set -e near the top so the script stops on the first error. Use set -u to catch undefined variables. Comment your scripts, future-you will thank you. #!/bin/bash set -euo pipefail Practice challenge 🏋️ Write a script that checks if a website is up:\n#!/bin/bash read -p \u0026#34;Enter a URL: \u0026#34; url if curl -s --head \u0026#34;$url\u0026#34; | grep \u0026#34;200 OK\u0026#34; \u0026gt; /dev/null; then echo \u0026#34;✅ $url is up!\u0026#34; else echo \u0026#34;❌ $url seems down.\u0026#34; fi What\u0026rsquo;s next? You can automate tasks now. Time to learn the technology that changed how we ship software: containers.\n👉 Next up: Docker for Absolute Beginners\n","permalink":"https://devopsadda.in/posts/bash-scripting-for-beginners/","summary":"Automate repetitive tasks by writing your first Bash scripts — variables, loops, conditionals, and cron jobs.","title":"Bash Scripting for Beginners"},{"content":"\u0026ldquo;It works on my machine\u0026rdquo; is the oldest excuse in software. Docker kills it for good by packaging your app and everything it needs into a portable container that runs the same everywhere.\nImages vs. containers An image is a blueprint, a snapshot of your app and its dependencies. A container is a running instance of that image. Think of an image like a recipe and a container like the actual dish you cook from it. One recipe, many dishes.\nInstalling Docker Grab Docker Desktop (Windows/Mac) or Docker Engine (Linux). Verify it:\ndocker --version docker run hello-world Essential commands docker pull nginx # download an image docker images # list local images docker run nginx # run a container docker run -d -p 8080:80 nginx # detached, map port 8080 → 80 docker ps # list running containers docker ps -a # include stopped containers docker stop \u0026lt;id\u0026gt; # stop a container docker rm \u0026lt;id\u0026gt; # remove a container docker rmi nginx # remove an image docker logs \u0026lt;id\u0026gt; # view container logs docker exec -it \u0026lt;id\u0026gt; bash # open a shell inside a container Writing your first Dockerfile A Dockerfile describes how to build your image. Here\u0026rsquo;s one for a simple Node.js app:\n# Start from an official base image FROM node:20-alpine # Set the working directory inside the container WORKDIR /app # Copy dependency files and install COPY package*.json ./ RUN npm install # Copy the rest of the app COPY . . # Tell Docker which port the app uses EXPOSE 3000 # The command to run when the container starts CMD [\u0026#34;node\u0026#34;, \u0026#34;server.js\u0026#34;] Build and run it:\ndocker build -t my-app . docker run -d -p 3000:3000 my-app Layers and caching Each instruction in a Dockerfile creates a layer. Docker caches layers, so copying package.json and installing dependencies before copying your whole app means dependencies only reinstall when they actually change. That\u0026rsquo;s why the order above matters.\nDocker Compose Real apps have multiple parts, an app plus a database, for example. Docker Compose runs them together with one file, docker-compose.yml:\nservices: web: build: . ports: - \u0026#34;3000:3000\u0026#34; depends_on: - db db: image: postgres:16 environment: POSTGRES_PASSWORD: secret volumes: - db-data:/var/lib/postgresql/data volumes: db-data: Then:\ndocker compose up -d # start everything docker compose ps # see what\u0026#39;s running docker compose down # stop and clean up Volumes \u0026amp; persistence Containers are ephemeral, delete one and its data is gone. Volumes store data outside the container so it survives restarts (notice db-data above).\nBest practices Use small base images (like -alpine) to keep things lean. Never bake secrets into images, use environment variables. Add a .dockerignore (like .gitignore) to skip node_modules, .git, etc. One process per container. Practice challenge 🏋️ Run an Nginx container mapped to port 8080. Visit http://localhost:8080 in your browser. Use docker exec -it \u0026lt;id\u0026gt; bash to peek inside. What\u0026rsquo;s next? Your app is containerized. Now let\u0026rsquo;s see where it actually runs, the cloud.\n👉 Next up: Cloud Computing Fundamentals\n","permalink":"https://devopsadda.in/posts/docker-for-beginners/","summary":"Understand containers, write your first Dockerfile, and run multi-container apps with Docker Compose.","title":"Docker for Absolute Beginners"},{"content":"The \u0026ldquo;cloud\u0026rdquo; is just someone else\u0026rsquo;s computers that you rent on demand. Instead of buying servers, you pay for compute and storage as you use it. This is where modern DevOps lives.\nWhy the cloud? No upfront hardware — spin up a server in seconds. Pay for what you use — scale up under load, scale down when quiet. Global reach — deploy close to your users worldwide. Managed services — let the provider run databases, queues, and more. The three service models Model What you manage Example IaaS OS, apps, data AWS EC2 (virtual machines) PaaS Just your app Heroku, App Engine SaaS Nothing — just use it Gmail, Dropbox A handy analogy: IaaS is renting a kitchen, PaaS is a meal-kit service, SaaS is ordering takeout.\nThe big three providers AWS — the largest, most services, great free tier. A solid place to start. Azure — Microsoft\u0026rsquo;s cloud, common in enterprises. GCP — Google\u0026rsquo;s cloud, strong in data and Kubernetes. The concepts transfer between all of them. Learn one well.\nCore building blocks (AWS terms) Compute EC2 — virtual machines you control. Lambda — run code without managing servers (serverless). Storage S3 — object storage for files, backups, static sites. EBS — disk volumes attached to EC2. Networking VPC — your private, isolated network in the cloud. Security Groups — virtual firewalls controlling traffic. Identity IAM — controls who can do what. Get this right; it\u0026rsquo;s security-critical. Regions and availability zones A region is a geographic location (e.g., us-east-1). Each region has multiple availability zones (isolated data centers). Spreading across zones keeps your app running even if one data center fails.\nThe shared responsibility model The provider secures the cloud infrastructure. You are responsible for securing what you put in it, your data, access policies, and configurations. Misconfigured permissions are the #1 cause of cloud breaches.\nStaying on the free tier (avoid surprise bills 💸) Sign up for the AWS Free Tier. Use small instance types (t2.micro / t3.micro). Set a billing alert the moment you create your account. Stop or terminate resources when you\u0026rsquo;re done experimenting. Billing → Budgets → Create a $1 alert. Future-you will be grateful. Your first hands-on win Create a free AWS account. Launch a t2.micro EC2 instance running Ubuntu. SSH into it: ssh -i key.pem ubuntu@\u0026lt;public-ip\u0026gt;. Install something (sudo apt install nginx). Terminate the instance when finished. What\u0026rsquo;s next? You understand where apps run. Now let\u0026rsquo;s automate getting them there with CI/CD.\n👉 Next up: CI/CD with GitHub Actions\n","permalink":"https://devopsadda.in/posts/cloud-computing-fundamentals/","summary":"Understand the cloud: compute, storage, networking, IAM, regions, and how to stay on the free tier.","title":"Cloud Computing Fundamentals"},{"content":"CI/CD is the heartbeat of DevOps. It means every time you push code, it automatically gets built, tested, and (optionally) deployed, no manual steps, no human error.\nWhat CI/CD actually means CI (Continuous Integration) — automatically build and test your code every time it changes. CD (Continuous Delivery/Deployment) — automatically release that code to staging or production. The payoff: catch bugs early, ship small changes often, and sleep better at night.\nWhy GitHub Actions? It\u0026rsquo;s built right into GitHub, free for public repos, and uses simple YAML files. Perfect for learning. The same concepts apply to GitLab CI, Jenkins, and others.\nHow it works Workflows live in .github/workflows/. Each workflow has:\nEvents — what triggers it (e.g., a push) Jobs — groups of steps that run on a virtual machine (runner) Steps — individual commands or actions Your first workflow Create .github/workflows/ci.yml:\nname: CI Pipeline on: push: branches: [ main ] pull_request: branches: [ main ] jobs: build-and-test: runs-on: ubuntu-latest steps: - name: Check out the code uses: actions/checkout@v4 - name: Set up Node.js uses: actions/setup-node@v4 with: node-version: \u0026#39;20\u0026#39; - name: Install dependencies run: npm install - name: Run tests run: npm test Commit and push this. Open the Actions tab on GitHub, you\u0026rsquo;ll watch it run live. 🎉\nUnderstanding the pieces Keyword Meaning on The event(s) that trigger the workflow jobs One or more jobs that run (in parallel by default) runs-on The OS of the virtual machine steps The ordered commands within a job uses A prebuilt action from the marketplace run A shell command to execute Adding a deploy step Once tests pass, you can deploy. Here\u0026rsquo;s a job that only runs on main after the build succeeds:\ndeploy: needs: build-and-test runs-on: ubuntu-latest if: github.ref == \u0026#39;refs/heads/main\u0026#39; steps: - uses: actions/checkout@v4 - name: Deploy run: ./deploy.sh needs makes deploy wait for build-and-test to pass first.\nSecrets Never hardcode passwords or API keys. Store them in Settings → Secrets and variables → Actions, then use them:\n- name: Deploy env: API_KEY: ${{ secrets.API_KEY }} run: ./deploy.sh Building a Docker image in CI A very common real-world pipeline:\n- name: Build Docker image run: docker build -t my-app:${{ github.sha }} . Tagging with github.sha gives every build a unique, traceable version.\nBest practices Keep pipelines fast — slow feedback defeats the purpose. Fail loudly — a red X should be impossible to miss. Run tests on pull requests, not just main. Cache dependencies to speed up runs. Practice challenge 🏋️ Add a workflow to one of your repos that runs a linter on every push. Watch it pass (and intentionally break it to watch it fail).\nWhat\u0026rsquo;s next? You can ship automatically. Now let\u0026rsquo;s manage the infrastructure itself as code.\n👉 Next up: Terraform for Beginners\n","permalink":"https://devopsadda.in/posts/cicd-with-github-actions/","summary":"Build your first automated pipeline that tests and deploys your code on every push using GitHub Actions.","title":"CI/CD with GitHub Actions"},{"content":"Clicking through a cloud console to create servers works once. But what about doing it consistently, 50 times, across three environments, with a full audit trail? That\u0026rsquo;s where Infrastructure as Code (IaC) comes in, and Terraform is the most popular tool for the job.\nWhat is Infrastructure as Code? Instead of manually creating resources, you describe them in code. Then a tool makes reality match your description. Benefits:\nRepeatable — same result every time. Versioned — your infra lives in Git alongside your app. Reviewable — changes go through pull requests. Documented — the code is the documentation. Why Terraform? Works across AWS, Azure, GCP, and 100s of other providers. Declarative, you say what you want, not how to build it. Huge community and module ecosystem. Install it here, then check:\nterraform version The core concepts Concept Meaning Provider The platform you\u0026rsquo;re managing (AWS, etc.) Resource A thing you create (a server, bucket, network) State Terraform\u0026rsquo;s record of what it has created Plan A preview of changes before applying Your first configuration Create a file main.tf:\nterraform { required_providers { aws = { source = \u0026#34;hashicorp/aws\u0026#34; version = \u0026#34;~\u0026gt; 5.0\u0026#34; } } } provider \u0026#34;aws\u0026#34; { region = \u0026#34;us-east-1\u0026#34; } resource \u0026#34;aws_s3_bucket\u0026#34; \u0026#34;my_bucket\u0026#34; { bucket = \u0026#34;devops-adda-demo-bucket-12345\u0026#34; tags = { Name = \u0026#34;Demo Bucket\u0026#34; Environment = \u0026#34;Learning\u0026#34; } } The core workflow terraform init # download the provider plugins terraform plan # preview what will be created/changed terraform apply # make it happen (type \u0026#39;yes\u0026#39; to confirm) terraform destroy # tear it all down when you\u0026#39;re done Always read the plan output before you apply. It tells you exactly what\u0026rsquo;s about to change.\nVariables (don\u0026rsquo;t hardcode) variable \u0026#34;region\u0026#34; { description = \u0026#34;AWS region to deploy into\u0026#34; default = \u0026#34;us-east-1\u0026#34; } provider \u0026#34;aws\u0026#34; { region = var.region } Outputs Print useful values after applying:\noutput \u0026#34;bucket_name\u0026#34; { value = aws_s3_bucket.my_bucket.bucket } Understanding state Terraform keeps a terraform.tfstate file mapping your code to real resources. Treat it carefully:\nNever edit it by hand. Don\u0026rsquo;t commit it to Git (it can contain secrets). On a team, store it remotely (e.g., an S3 backend with locking). Best practices Use modules to reuse configurations. Keep environments (dev/staging/prod) separate. Run terraform fmt to keep code tidy and terraform validate to catch errors. Always destroy learning resources to avoid charges. Practice challenge 🏋️ Write a config that creates a single S3 bucket. Run init, plan, then apply. Confirm it exists in the AWS console. Run destroy to clean up. What\u0026rsquo;s next? You can build infrastructure on demand. Now let\u0026rsquo;s orchestrate all those containers at scale.\n👉 Next up: Kubernetes 101\n","permalink":"https://devopsadda.in/posts/terraform-for-beginners/","summary":"Stop clicking in consoles. Define and provision your cloud infrastructure as code with Terraform.","title":"Terraform for Beginners"},{"content":"One Docker container is easy. But what happens when you have 50 of them, across many machines, that need to stay healthy, scale up under load, and recover from crashes? That\u0026rsquo;s the job of Kubernetes (often shortened to K8s).\nWhat Kubernetes does for you Scheduling — decides which machine runs each container. Self-healing — restarts containers that crash. Scaling — adds or removes copies based on demand. Load balancing — spreads traffic across your containers. Rollouts \u0026amp; rollbacks — ship updates safely. Practice locally first You don\u0026rsquo;t need a cloud cluster to learn. Install Minikube or kind to run Kubernetes on your laptop, plus kubectl, the command-line tool.\nminikube start kubectl version --client The key building blocks Object What it is Pod The smallest unit — wraps one (or a few) containers Deployment Manages a set of identical pods and their updates Service A stable network endpoint to reach your pods Namespace A way to group and isolate resources A useful mental model: a Deployment keeps the right number of Pods running, and a Service gives them a fixed address.\nYour first deployment Create deployment.yaml:\napiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:latest ports: - containerPort: 80 Apply it:\nkubectl apply -f deployment.yaml kubectl get pods # you should see 3 pods kubectl get deployments Exposing it with a Service Create service.yaml:\napiVersion: v1 kind: Service metadata: name: nginx-service spec: type: NodePort selector: app: nginx ports: - port: 80 targetPort: 80 kubectl apply -f service.yaml minikube service nginx-service # opens it in your browser Essential kubectl commands kubectl get pods # list pods kubectl get all # list everything kubectl describe pod \u0026lt;name\u0026gt; # detailed info kubectl logs \u0026lt;pod\u0026gt; # view logs kubectl exec -it \u0026lt;pod\u0026gt; -- bash # shell into a pod kubectl delete -f deployment.yaml Scaling and self-healing in action kubectl scale deployment nginx-deployment --replicas=5 Now try deleting a pod, Kubernetes immediately creates a replacement to maintain the desired count. That\u0026rsquo;s self-healing:\nkubectl delete pod \u0026lt;pod-name\u0026gt; kubectl get pods # a new one is already spinning up Rolling updates Change the image version and Kubernetes updates pods gradually, with zero downtime:\nkubectl set image deployment/nginx-deployment nginx=nginx:1.25 kubectl rollout status deployment/nginx-deployment kubectl rollout undo deployment/nginx-deployment # roll back if needed Don\u0026rsquo;t be intimidated Kubernetes is huge, and nobody learns it all at once. Master pods, deployments, and services first. Everything else builds on those three.\nPractice challenge 🏋️ Deploy the Nginx example above with 3 replicas. Scale it to 6. Delete a pod and watch Kubernetes recreate it. Clean up with kubectl delete. What\u0026rsquo;s next? Your apps are running and scaling. The final piece: knowing what\u0026rsquo;s actually happening inside them.\n👉 Next up: Monitoring with Prometheus \u0026amp; Grafana\n","permalink":"https://devopsadda.in/posts/kubernetes-101/","summary":"Run and scale containers in production with Kubernetes — pods, deployments, services, and your first kubectl commands.","title":"Kubernetes 101"},{"content":"You\u0026rsquo;ve built, shipped, and scaled your app. But is it healthy right now? Is it slow? About to run out of memory? Monitoring answers those questions, and it\u0026rsquo;s what separates a hobby project from a production system.\nThe three pillars of observability Pillar Question it answers Example tool Metrics How much / how many? Prometheus Logs What exactly happened? Loki, ELK Traces Where did the time go? Jaeger, Tempo We\u0026rsquo;ll focus on metrics, the best starting point.\nMeet the dynamic duo Prometheus collects and stores metrics by scraping your apps at intervals. Grafana turns those metrics into beautiful, readable dashboards. They\u0026rsquo;re the open-source standard for monitoring, and they pair perfectly.\nHow Prometheus works Your app exposes metrics at an endpoint like /metrics. Prometheus scrapes that endpoint every few seconds. It stores the data as time series. You query it with PromQL. A metrics endpoint looks like plain text:\nhttp_requests_total{method=\u0026#34;GET\u0026#34;,status=\u0026#34;200\u0026#34;} 1027 process_cpu_seconds_total 4.5 Quick start with Docker Compose services: prometheus: image: prom/prometheus ports: - \u0026#34;9090:9090\u0026#34; volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml grafana: image: grafana/grafana ports: - \u0026#34;3000:3000\u0026#34; A minimal prometheus.yml:\nglobal: scrape_interval: 15s scrape_configs: - job_name: \u0026#39;prometheus\u0026#39; static_configs: - targets: [\u0026#39;localhost:9090\u0026#39;] docker compose up -d Prometheus UI → http://localhost:9090 Grafana → http://localhost:3000 (default login: admin / admin) A taste of PromQL # Total HTTP requests http_requests_total # Per-second request rate over the last 5 minutes rate(http_requests_total[5m]) # Only 500 errors http_requests_total{status=\u0026#34;500\u0026#34;} Building a Grafana dashboard In Grafana, add Prometheus as a data source (http://prometheus:9090). Create a dashboard → add a panel. Enter a PromQL query like rate(http_requests_total[5m]). Pick a visualization (graph, gauge, stat) and save. You can also import community dashboards by ID from grafana.com/dashboards.\nAlerting Dashboards are great, but you can\u0026rsquo;t stare at them 24/7. Set alerts to notify you (via Slack, email, PagerDuty) when something\u0026rsquo;s wrong:\n\u0026ldquo;Alert me if error rate is above 5% for 5 minutes.\u0026rdquo;\nGood alerts are actionable and rare. Alert fatigue, too many noisy alerts, is real, so only alert on things that need a human.\nWhat good monitoring looks like Track the Four Golden Signals: latency, traffic, errors, and saturation. Build dashboards your whole team understands at a glance. Alert on symptoms users feel, not every tiny blip. Practice challenge 🏋️ Spin up Prometheus + Grafana with the Compose file above. Add Prometheus as a Grafana data source. Build a panel showing Prometheus\u0026rsquo;s own request rate. You did it! 🎉 That\u0026rsquo;s the full beginner DevOps journey, from \u0026ldquo;what is DevOps?\u0026rdquo; all the way to monitoring production systems. You now understand how modern software is built, shipped, run, and watched.\nKeep practicing, keep building projects, and revisit the Roadmap whenever you want to go deeper. Welcome to DevOps. 🚀\n","permalink":"https://devopsadda.in/posts/monitoring-prometheus-grafana/","summary":"You can\u0026rsquo;t fix what you can\u0026rsquo;t see. Learn observability with metrics, Prometheus, Grafana dashboards, and alerts.","title":"Monitoring with Prometheus \u0026 Grafana"},{"content":"There are hundreds of DevOps tools out there. Here\u0026rsquo;s the curated shortlist that actually matters when you\u0026rsquo;re starting out, grouped by what they do. Install these as you progress through the Roadmap.\n🐧 Operating System \u0026amp; Shell Tool What it\u0026rsquo;s for Linux (Ubuntu) The OS most servers run on. Learn it. Bash / Zsh The command-line shell where you\u0026rsquo;ll live WSL2 Run Linux on Windows without a VM 🔧 Version Control Tool What it\u0026rsquo;s for Git Track changes to your code GitHub / GitLab Host repos and collaborate 📦 Containers Tool What it\u0026rsquo;s for Docker Package apps into portable containers Docker Compose Run multi-container apps locally ☸️ Orchestration Tool What it\u0026rsquo;s for Kubernetes Run and scale containers in production kubectl The Kubernetes command-line tool Minikube / kind Run Kubernetes locally for learning Helm Package manager for Kubernetes ☁️ Cloud Providers Tool What it\u0026rsquo;s for AWS The largest cloud platform (great free tier) Azure Microsoft\u0026rsquo;s cloud, big in enterprises GCP Google\u0026rsquo;s cloud, strong in data \u0026amp; containers 🏗️ Infrastructure as Code Tool What it\u0026rsquo;s for Terraform Define cloud infrastructure as code Ansible Configure servers and automate tasks 🔁 CI/CD Tool What it\u0026rsquo;s for GitHub Actions Automate builds, tests, and deploys Jenkins Classic, powerful CI/CD server GitLab CI Built-in pipelines in GitLab 📊 Monitoring \u0026amp; Observability Tool What it\u0026rsquo;s for Prometheus Collect metrics from your systems Grafana Visualise metrics in dashboards Loki Aggregate and search logs 🧰 Handy Extras Tool What it\u0026rsquo;s for VS Code A great, extensible code editor curl / jq Make HTTP requests and parse JSON tmux Manage multiple terminal sessions Don\u0026rsquo;t try to install everything today. Add tools to your toolbox as you reach each stage of the Roadmap. One at a time. 🛠️\n","permalink":"https://devopsadda.in/tools/","summary":"A curated toolbox of the most important DevOps tools and what each one is for.","title":"Essential DevOps Tools"},{"content":"DevOps can feel overwhelming because there are so many tools. The secret? You don\u0026rsquo;t learn them all at once. You follow a path. Here\u0026rsquo;s the order that actually makes sense for a beginner.\nWork through these stages top to bottom. Each one builds on the last.\nStage 0 — Mindset \u0026amp; Fundamentals Before any tool, understand what DevOps is: a culture that brings development and operations together to ship software faster and more reliably.\nWhat DevOps is (and isn\u0026rsquo;t) The software delivery lifecycle Why automation matters 📖 Start here: What is DevOps?\nStage 1 — Linux \u0026amp; the Command Line Almost every server you\u0026rsquo;ll ever touch runs Linux. Get comfortable in the terminal.\nNavigating the filesystem File permissions, users, and processes Package managers, networking basics, and editing files 📖 Tutorial: Linux Basics for DevOps\nStage 2 — Version Control with Git Git is how teams collaborate on code. It\u0026rsquo;s non-negotiable.\nCommits, branches, and merges Pull requests and code review Working with GitHub / GitLab 📖 Tutorial: Git \u0026amp; GitHub Crash Course\nStage 3 — Scripting \u0026amp; Automation If you do something twice, script it. Bash is your first automation superpower.\nVariables, loops, and conditionals in Bash Writing reusable scripts Scheduling jobs with cron 📖 Tutorial: Bash Scripting for Beginners\nStage 4 — Containers with Docker Containers package your app so it runs the same everywhere. This is a game-changer.\nImages vs. containers Writing a Dockerfile Docker Compose for multi-container apps 📖 Tutorial: Docker for Absolute Beginners\nStage 5 — Cloud Fundamentals The cloud is where modern infrastructure lives. Pick one provider (AWS is a great start) and learn the core services.\nCompute, storage, networking, and IAM Regions and availability zones The free tier and how to avoid surprise bills 📖 Tutorial: Cloud Computing Fundamentals\nStage 6 — CI/CD Pipelines Continuous Integration and Continuous Delivery automate testing and deployment.\nThe anatomy of a pipeline Building your first GitHub Actions workflow Automating tests and deployments 📖 Tutorial: CI/CD with GitHub Actions\nStage 7 — Infrastructure as Code Stop clicking in consoles. Define your infrastructure in code with Terraform.\nWhat IaC is and why it matters Providers, resources, and state Provisioning real cloud resources 📖 Tutorial: Terraform for Beginners\nStage 8 — Container Orchestration with Kubernetes When you have many containers, Kubernetes keeps them running, scaled, and healthy.\nPods, deployments, and services kubectl basics Your first deployment 📖 Tutorial: Kubernetes 101\nStage 9 — Monitoring \u0026amp; Observability You can\u0026rsquo;t fix what you can\u0026rsquo;t see. Learn to watch your systems.\nMetrics, logs, and traces Prometheus and Grafana basics Setting up useful alerts 📖 Tutorial: Monitoring with Prometheus \u0026amp; Grafana\nYou made it 🎉 Once you\u0026rsquo;re comfortable with these stages, you\u0026rsquo;re genuinely job-ready for a junior DevOps or Cloud role. Keep building projects, keep automating, and keep things running smoothly.\nReady to begin? 👉 Jump into the first tutorial\n","permalink":"https://devopsadda.in/roadmap/","summary":"A step-by-step path from absolute beginner to job-ready DevOps engineer.","title":"The DevOps Roadmap for Beginners"},{"content":"Hey there, future DevOps engineer 👋 DevOps Adda is a beginner-first learning hub built for people who want to break into DevOps without drowning in jargon. No prior ops experience required, just curiosity and a willingness to type commands into a terminal.\n\u0026ldquo;Adda\u0026rdquo; means a gathering place, a spot where people hang out, swap ideas, and learn together. That\u0026rsquo;s exactly the vibe here.\nWhat you\u0026rsquo;ll find Hands-on tutorials that you can follow along with on your own machine A clear DevOps Roadmap so you always know what to learn next Beginner guides to Linux, Git, Docker, Kubernetes, CI/CD, Terraform, and the cloud A curated Tools page so you don\u0026rsquo;t waste time figuring out what to install Who this is for Students and fresh grads eyeing a DevOps or Cloud role Developers who want to understand how their code ships to production Sysadmins moving into modern automation and infrastructure-as-code Anyone curious about how software actually gets built, tested, and deployed How to use this site Start with the Roadmap to see the big picture. Work through the Tutorials in order, or jump to a topic you care about. Keep the Tools page handy as your setup checklist. Practice. Reading is good; breaking things in a terminal is better. About the author Built and maintained by Sai Kiran Pikili, a DevOps practitioner who enjoys turning messy infrastructure into clean, automated pipelines.\n🐙 GitHub 💼 LinkedIn ✍️ Medium DevOps is not a tool or a title. It\u0026rsquo;s a culture of collaboration, automation, and continuous improvement. Welcome aboard. 🚀\n","permalink":"https://devopsadda.in/about/","summary":"What DevOps Adda is, who it\u0026rsquo;s for, and how to get the most out of it.","title":"About DevOps Adda"}]