Linux Networking Commands for DevOps

🐳 Docker Compose Essential Training — Engine v29 | Compose v5 Hands-on Lab I just published Guide #2 of the Essential Training Series — a practical, hands-on Docker Compose lab that I personally tested command by command before sharing. 📋 What's inside: • 8 exercises covering the core Docker Compose fundamentals • Services, networks, volumes and environment management • Build workflows with Dockerfile and live reload • Health checks and correct startup ordering • Profiles for optional services • Scaling services and resource limits • Debugging with logs, exec and compose config 🔧 Tested on: • Docker Engine v29.4 — Compose v5.1.2 (latest) • 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/dhVQ5BVN 🚀 More coming soon: ✅ Docker ✅ Docker Compose (this one) ✅ 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. #DockerCompose #Docker #DevOps #Kubernetes #CloudNative #Linux #LearningInPublic #OpenSource

🐳 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

My First Step into DevOps: Building a Containerized DNS Core The Goal: I recently moved my home DNS filtering (Pi-hole) onto a Raspberry Pi 3B. While the standard approach is to use a simple one-line installation script, I chose to deploy it using Docker Compose. I wanted to move away from "point-and-click" setups and actually learn how to manage infrastructure as code. --- The Learning Curve: Getting Pi-hole to run correctly in a container was a massive learning experience. It forced me to move past the surface level and solve real-world engineering problems. - Container Networking: This was my biggest hurdle. In the default Docker Bridge mode, Pi-hole couldn’t "see" individual device IPs. I had to pivot to Host Networking for transparency, which meant learning to manually resolve Port 53 conflicts with systemd-resolved using ss and lsof. - The "Ephemeral" Logic: I learned the hard way how Docker handles state. I spent hours troubleshooting why my .env changes weren't reflecting, only to discover that once a persistent volume is created, it takes precedence during recreation. It shifted my mindset from "editing files" to "managing a service lifecycle." - Linux Fundamentals: The project required more than just Docker. I had to master GPG repository signing, understand how shell expansion works in docker.sources, and use chmod a=r to harden my security—skills that are often skipped in basic tutorials. - Resource Management: Running on a Pi 3B meant being intentional with storage. I learned to use docker system prune and image auditing to keep "ghost" data from filling up my SD card. --- When it clicked: The real win wasn't getting the dashboard to turn green. It was the moment I finally untangled a subnet origin conflict that was dropping my DNS traffic. That struggle taught me more about traffic flow and Docker logic. I’ve documented every step of this journey from the initial ssh-keygen to the final healthcheck logic in my GitHub repo: https://lnkd.in/eC2diMju #DevOps #Docker #Pihole #HomeLab #LinuxAdmin #Networking #LearnInPublic

We literally used sudo in the last lecture… And no one asked why. That’s the problem. Most people learning Linux for DevOps don’t actually learn things… They just follow along. Run this command. Copy that step. It works - so they move on. Until one day… Production says: Permission denied. And suddenly: – Commands stop working – Logs are inaccessible – Panic starts Because now it’s not about what to type It’s about who you are in the system User? sudo user? root? That difference decides everything. I’ve seen engineers who know Docker, Kubernetes, CI/CD… But still get stuck on something as basic as privileges. Not because it’s hard - But because no one explained it properly. So instead of just using sudo again… We stopped. And broke it down: – What actually happens when you run sudo – Why switching to root is risky – When to use su vs sudo in real systems Because DevOps is not about running commands. It’s about understanding control. And in Linux… control starts with privileges. If you’ve ever used sudo without thinking… You should probably watch this one. Link in comments 👇 #Linux #DevOps #CloudComputing #SystemDesign #AWS #DevOpsEngineer #LinuxCommands #TechCareers #Programming

Manual deployments taught me the most valuable lesson about automation. As a beginner, I got assigned what seemed like a simple task: deploy our app to the Linux server. No big deal, right? Wrong. I found myself doing this over and over for every single project. Creating directories, setting up services, configuring nginx... rinse and repeat. Hours of manual work. Countless errors. The same tedious steps every time. After probably my 3rd deployment disaster, something clicked. Instead of accepting this pain, I decided to build a script that would handle the entire process. Now our DevOps team just runs the script, fills in a few prompts, and boom – deployment complete. What used to take hours and generate tons of errors now takes 10 minutes with minimal mistakes. The real lesson? Sometimes the most frustrating tasks are actually showing you exactly what needs to be automated. That boring, repetitive work you're avoiding – what if it's actually your next breakthrough waiting to happen? #DevOps #Automation #Linux #Deployment #TechTips #SoftwareDevelopment #LearningInTech #Scripts

If you're starting your Linux journey, mastering a few basic commands can make a huge difference 🚀 Here’s a quick cheat sheet to get you comfortable with the terminal 👇 🔹 1. Navigation Commands 📂 pwd → Present Working Directory 📂 ls → List files and folders 📂 cd <dir> → Change directory Example: pwd ls cd /home/user 🔹 2. File & Directory Management 📁 mkdir <name> → Create a directory 📁 touch <file> → Create a file 📁 cp <src> <dest> → Copy files 📁 mv <src> <dest> → Move/rename files 📁 rm <file> → Delete files Example: mkdir project touch app.txt cp app.txt backup.txt mv app.txt new_app.txt rm backup.txt 🔹 3. Viewing File Content 📖 cat <file> → Show file content 📖 less <file> → View file page by page 📖 head -n 5 <file> → First 5 lines 📖 tail -n 5 <file> → Last 5 lines 🔹 4. Permissions & Ownership 🔐 chmod +x file.sh → Make file executable 🔐 chown user:user file → Change ownership 🔹 5. Search & Filters 🔍 find . -name "file.txt" → Search files 🔍 grep "text" file.txt → Search inside file 🔹 6. System Info & Monitoring ⚙️ top → Real-time processes ⚙️ df -h → Disk usage ⚙️ free -m → Memory usage 🔹 7. Package Management (Ubuntu/Debian) 📦 sudo apt update → Update packages 📦 sudo apt install <pkg> → Install package 💡 Pro Tip: Combine commands using pipes | to unlock real power. Example: ps aux | grep nginx 🚀 Why Learn Linux Commands? Work faster without GUI Essential for DevOps & Cloud Automate tasks like a pro Debug systems efficiently 🔥 Start small. Practice daily. Soon, the terminal won’t feel intimidating — it’ll feel powerful. #Linux #DevOps #Cloud #Shell #Automation #Learning #Engineering

🚀 Day 20 of 30 – Debugging in Terraform (TF_LOG) When I first started learning Terraform, one big question I had was: 👉 How do you actually see what Terraform is doing under the hood? Turns out — Terraform has a powerful built-in logging system you can enable with a single environment variable. 🔹 What is TF_LOG? TF_LOG is an environment variable that controls Terraform’s logging verbosity. ✔ Helps debug failed plans ✔ Understand provider behavior ✔ Identify state-related issues ✔ No code changes required 🔹 Log Levels (highest → lowest) TRACE ← most detailed DEBUG INFO WARN ERROR ← least detailed 🔹 Enable Logging (Linux / Mac) export TF_LOG=INFO terraform plan 👉 Logs will be printed directly in your terminal 🔹 Store Logs to a File export TF_LOG=INFO export TF_LOG_PATH=terraform.txt terraform plan 👉 Logs will be saved in terraform.txt 👉 Useful for debugging & sharing with teams 🔹 Practical Example resource "local_file" "foo" { content = "foo!" filename = "${path.module}/foo.txt" } Run: export TF_LOG=DEBUG terraform apply 👉 You can see: • How path.module is resolved • File creation steps • Internal Terraform execution flow 🎯 Key Takeaway When Terraform behaves unexpectedly: 👉 Don’t guess 👉 Don’t assume Check the logs first — TF_LOG is your best friend 📅 Tomorrow: Terraform format #30DaysOfTerraform #Terraform #DevOps #CloudEngineering #AWS

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

🔐 Day 4 of #100DaysOfDevOps — Linux file permissions Today's task: a backup script existed on a production server but no one could run it. One missing permission bit was the culprit. Here's what I learned: Every Linux file has a 10-character permission string like -rw-r--r-- It's split into 3 groups: → Owner (the user who created it) → Group (a team sharing access) → Others (everyone else) Each group gets 3 bits: r (read=4), w (write=2), x (execute=1) The fix was one command: chmod a+x /tmp/xfusioncorp.sh or chmod 755 /tmp/xfusioncorp.sh a = all users | +x = add execute permission Before: -rw-r--r-- (no one can run it) After: -rwxr-xr-x (everyone can run it) Why does this matter in DevOps? → Automation scripts fail silently when permissions are wrong → CI/CD pipelines break if deploy scripts aren't executable → Every cloud server you ever manage will need this The numeric equivalent: chmod 755 Meaning: owner gets rwx (7), group gets r-x (5), others get r-x (5) "r = read, w = write, x = execute. Three bits. Three groups. That's all of Linux permissions." #DevOps #Linux #BashScripting #chmod #CloudEngineering KodeKloud

🚀 #100DaysOfDevOps by KodeKloud | Day 4 🔐 Day 4: Script Execution Permissions Today I worked on a simple yet important Linux concept — file permissions and how they impact script execution. 🧩 Task I had to grant executable permissions to a script: /tmp/xfusioncorp.sh on App Server 1, ensuring that all users can execute it. 🛠️ Steps I followed 1️⃣ Switched to root user from jump host: sudo -i 2️⃣ Connected to App Server 1: ssh stapp01 3️⃣ Checked existing permissions: ls -l /tmp/xfusioncorp.sh 4️⃣ Granted proper permissions: chmod 755 /tmp/xfusioncorp.sh 5️⃣ Verified the result: -rwxr-xr-x ⚠️ Issues I encountered ❌ Initially used: chmod a+x But it resulted in: r--r-x--x 👉 The owner didn’t have proper execute permission in expected format 👉 This caused the task validation to fail 💡 Learned that just adding execute (x) is not always enough — sometimes I need to explicitly set correct permission structure ✅ Key Learning ✔ File permissions matter more than they look ✔ Understanding rwx is crucial for Linux & DevOps ✔ Always verify using ls -l before submitting ✔ When in doubt, chmod 755 is a safe and common approach 🔥 Small task, big learning! If you're starting your DevOps journey, I highly recommend KodeKloud for hands-on labs 👇 https://lnkd.in/deg5ZDcV #DevOps #Linux #KodeKloud #LearningInPublic #CloudComputing #100DaysChallenge