Day 69/90 — Ansible Playbooks & Modules 🚀 Today I moved beyond ad-hoc commands and wrote my first real Ansible playbooks as part of #90DaysOfDevOps! Here's what I built and learned: ✅ Wrote my first playbook to install Nginx, start the service, and deploy a custom HTML page ✅ Proved idempotency — ran the same playbook twice, second run showed changed=0 ✅ Practiced 7 essential modules: apt, service, copy, file, command, shell, lineinfile ✅ Understood the difference between command and shell modules ✅ Learned handlers — tasks that only trigger when something actually changes ✅ Used --check --diff for safe dry runs before applying changes The moment that clicked for me: running the same playbook twice and watching Ansible make zero changes the second time. That's idempotency — and it's what makes infrastructure automation reliable at scale. Ansible doesn't just run commands. It enforces desired state. 🔥 #90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham #Ansible #DevOps #InfrastructureAsCode #Linux #Automation #LearningInPublic
Anand Sen’s Post
More Relevant Posts
-
For Day 06 of the #90DaysOfDevOps challenge, I went back to the fundamentals of Linux: File I/O operations. In the world of DevOps, everything is a file. Whether you are debugging logs, updating Nginx configurations, or writing automation scripts, the ability to manipulate text quickly from the CLI is a superpower. 🛠️ What I Mastered Today: I practiced the art of file redirection and stream manipulation using basic but powerful commands: Redirection (> and >>): Learning the critical difference between overwriting a file and safely appending to it. The tee Command: A game-changer for redirection that allows you to write to a file and see the output in the terminal simultaneously. head & tail: Essential for inspecting massive log files without crashing your terminal session. 💡 The Command I’ll Use Every Day: tail -f <filename> There is no better way to watch a live application log and catch errors the moment they happen. 📂 Progress Log: Created: teecommand folder Pushed to GitHub: https://lnkd.in/gZTrv9rJ #90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham #Linux #Automation #CloudComputing #LearningInPublic
To view or add a comment, sign in
-
Recently I have created a custom github docker actions which is basically a Giphy PR Commenter Actions that improves the contributor experience by automatically posting a "Thank You" GIF on every new Pull Request. The action works through a Docker container that executes a shell script. It uses jq and curl to fetch a random GIF from the Giphy API based on specific tags and then interacts with the GitHub API to post the GIF as a comment on the respective PR. Problem: Everything was running well in the github hosted runner but suddenly when I switched to self hosted runner it gave me the below error `ERROR: permission denied while trying to connect to the docker API at unix:///var/run/docker.sock` I checked the test.yaml file where I was using the actions but everything was ok. I was using the right tags as well. Then I went to my host machine and check if its a permission related issue or not. Then I found that when executing a Docker action it needs to communicate with the docker daemon which listens to /var/run/docker.sock this unix socket but by default that is owned by root. Where my runner was operating under user codegen which is my ubuntu user. Fix: So, now the fix is pretty simple , give the user `codegen` the permission to talk with unix:///var/run/docker.sock. 1. Ran the command `sudo usermod -aG docker codegen` - Here I just updated the group membership 2. id codegen Result: uid=1000(codegen) gid=1000(codegen) groups=1000(codegen),4(adm),20(dialout),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),100(users),107(netdev),989(docker) - Here we can see The user codegen has been successfully added to the docker group. 3. Then I just restarted the runner and created a PR and it was performing the workflow perfectly . Takeaway: If you are practicing devops you need to have the core linux fundamentals. Look , it was part of CI/CD but it forced me to recall my linux fundamentals. #Linux #devops #CI_CD #Automation #Docker #SoftwareEngineering #DevOpsEngineer #CloudNative
To view or add a comment, sign in
-
-
Ansible is not just automation. It's documentation. A well-written playbook tells you: → What the server should look like → What steps were taken to get there → What can go wrong and how to handle it Compare that to a runbook written in Confluence that's 18 months out of date. Executable documentation > Static documentation. If your playbooks are readable by a junior engineer on their first day, you've done it right. #Ansible #DevOps #Automation #Infrastructure #Linux
To view or add a comment, sign in
-
🚀 Kubernetes Hands-on: Working with Namespaces I recently worked on implementing Kubernetes Namespaces to understand how workloads can be logically separated within a cluster. What I did: ✓ Created multiple namespaces: dev, staging, and prod ✓ Deployed resources inside specific namespaces ✓ Switched default namespace using CLI for efficient operations ✓ Verified resources using namespace-specific commands ✓ Performed cleanup by deleting namespaces and associated resources Why I did this: 🔹Namespaces are critical in real-world Kubernetes environments to: 🔹Isolate applications across different environments 🔹Avoid resource conflicts between teams 🔹Improve organization and access control Proof of Work: ✓ Successfully created and managed multiple namespaces ✓ Verified pods running in different namespaces ✓ Demonstrated namespace switching and cleanup using kubectl Key Learning: Proper namespace management ensures better control, scalability, and safer operations in production environments. special thanks to Ashutosh S. Bhakare sir for the guidance #Kubernetes #DevOps #CloudComputing #K8s #LearningByDoing #Containers #Linux #DevOpsJourney
To view or add a comment, sign in
-
🐳 Docker Essential Training — Engine v29 Hands-on Lab I just published my first guide from the Essential Training Series — a practical, hands-on Docker lab that I personally tested command by command before sharing. 📋 What's inside: • 8 exercises covering the core Docker fundamentals • Images, containers, networking, volumes • Multi-stage Dockerfiles & Docker Compose • Every issue I faced during testing is already fixed 🔧 Tested on: • Docker Engine v29 (latest — March 2026) • WSL2 on Windows — HP i3, 20GB RAM • Real commands, real errors, real fixes This is not a copy-paste from the docs. Every exercise was validated hands-on before being shared. 📎 PDF attached — free to download and use. 📁 Exercise files on GitHub: https://lnkd.in/dBpAXt7h 🚀 More coming soon: ✅ Docker (this one) ✅ Docker Compose ✅ K3s ⏳ Helm ⏳ GitHub Actions CI/CD ⏳ ArgoCD (GitOps) ⏳ Prometheus & Grafana ⏳ Loki + OpenTelemetry If this is useful — share it with someone learning DevOps 🙌 If it is not — drop a comment or send me your feedback. I am still improving it. #Docker #DevOps #Kubernetes #CloudNative #Linux #LearningInPublic #OpenSource
To view or add a comment, sign in
-
I’ve realized I remember technical concepts way better when I relate them to everyday life. So here’s how I think of CI/CD: Imagine ordering food 🍔 You place an order → it gets prepared step by step → checked → packed → delivered to your door. CI/CD is pretty similar. Code is committed → built → tested → validated → and then deployed. Same flow, just software instead of burgers 🤣 Ah, now im hungry 😭 That’s honestly how I make things stick in my head. How do you usually remember concepts like CI/CD? #devops #ci #cd #pipelines #linux #deployments
To view or add a comment, sign in
-
🚀 Learning & Implementing Ansible Automation Today I successfully set up an Ansible lab environment with a controller and multiple Ubuntu machines. I practiced configuring inventory, managing SSH connectivity, and running ad-hoc commands and playbooks. 🔧 What I worked on: Installed and configured Ansible on controller node Created and managed inventory groups Set up password & SSH key-based authentication Executed ad-hoc commands (uptime, package updates, system info) Created and debugged playbooks (YAML indentation matters!) Automated tasks like package management and system checks 💡 Key Learning: Ansible is agentless and powerful for managing multiple systems efficiently. Proper YAML structure and SSH configuration are critical for smooth automation. 🎯 Next Goal: Exploring advanced concepts like roles, variables, and automating real-world deployments (e.g., Nginx, user management, security tools). #Ansible #Automation #DevOps #Linux #SystemAdministration #Networking #LearningJourney
To view or add a comment, sign in
-
-
Apache was down on one server… while working perfectly on the others. Day 14 of #100DaysOfDevOps ✅ The task was to identify the faulty server, fix Apache, and ensure it was running on port 6300 across all app servers. From the jump host, I tested connectivity and quickly found that one server was refusing connections while the others were fine. The issue turned out to be a port conflict — another process was already using port 6300, preventing Apache from starting. Once the conflicting process was stopped, Apache started successfully and became accessible. Key takeaway: When a service fails to start, always check if the required port is already in use. Tools like ss and simple connectivity tests can help isolate the issue quickly. Day 14 complete. 86 to go 🚀 GitHub 👇 https://lnkd.in/dk8Frue7 #DevOps #Linux #Troubleshooting #Networking #Apache #100DaysOfDevOps #LearningInPublic #SRE #DevOpsEngineer
To view or add a comment, sign in
-
🚀 #100DaysOfDevOps by KodeKloud | Day 8 🔧 Day 8: Install Ansible (Automation Begins!) Today, I worked on setting up Ansible on a jump host to start exploring configuration management and automation. 💡 What I did: Installed Ansible 4.10.0 using pip3 Ensured installation was global so all users can run Ansible commands Verified setup using ansible --version Checked and confirmed proper PATH configuration ✅ What I learned: Why pip3 is used instead of package managers in some cases Importance of environment paths in Linux Difference between ansible vs ansible-core How Ansible acts as a control node to manage multiple servers 🔥 This was my first step into the world of automation with Ansible, and it already feels powerful! Looking forward to writing my first playbook soon 🚀 If you're starting your DevOps journey, I highly recommend KodeKloud for hands-on labs 👇 https://lnkd.in/deg5ZDcV #DevOps #Ansible #Linux #Automation #LearningInPublic #KodeKloud #CloudComputing #100DaysChallenge
To view or add a comment, sign in
-
-
Episode 7 of the DevOps Tools Engineer 2.0 Introduction series dives into exam objective #ContainerOrchestration. Learn how #DockerCompose & #PodmanCompose define and run multi-container applications for modern #DevOps workflows: https://lpi.org/4nh7 Linux Professional Institute (LPI) #DevOps #containerorchestration #dockercompose #podmancompose #microservices #services #networks
To view or add a comment, sign in
-
Explore content categories
- Career
- Productivity
- Finance
- Soft Skills & Emotional Intelligence
- Project Management
- Education
- Technology
- Leadership
- Ecommerce
- User Experience
- Recruitment & HR
- Customer Experience
- Real Estate
- Marketing
- Sales
- Retail & Merchandising
- Science
- Supply Chain Management
- Future Of Work
- Consulting
- Writing
- Economics
- Artificial Intelligence
- Employee Experience
- Workplace Trends
- Fundraising
- Networking
- Corporate Social Responsibility
- Negotiation
- Communication
- Engineering
- Hospitality & Tourism
- Business Strategy
- Change Management
- Organizational Culture
- Design
- Innovation
- Event Planning
- Training & Development