🚀 Day 12 of #90DaysOfDevOps – Breather & Revision In DevOps, speed is valuable—but clarity in fundamentals is what truly saves hours of debugging. Today was dedicated to revisiting everything from Days 01–11, strengthening core Linux concepts—from file operations to service management and permissions. 💡 Key Takeaways: 🔹 Service Health Matters Mastering systemctl and journalctl is essential. Troubleshooting starts with understanding what your services are telling you. 🔹 Permissions ≠ Shortcuts Using chmod 777 might feel quick, but it’s rarely correct. Real control comes from understanding chown and permission bitmasking. 🔹 The Power Trio grep, alias, and history are small tools with massive impact on daily efficiency. 🔥 Confidence Boost: One command I now fully trust during debugging: journalctl -u <service> -xe → My go-to for answering: “What actually went wrong?” Taking a pause to revise isn’t slowing down—it’s building a stronger foundation for what’s next. Excited to move into the next phase of the journey 💪 #90DaysOfDevOps #DevOps #Linux #LearningInPublic #DevOpsEngineer #CloudJourney #Consistency
DevOps Fundamentals: Strengthening Linux Concepts
More Relevant Posts
-
🐳 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
To view or add a comment, sign in
-
Day 6 of my DevOps roadmap — and today's topic hit different 🕐 [Writing this at 3:47 PM IST] Cron Jobs & Scheduling on Linux Here's what I built and learned today (as of 3:36 PM IST, Apr 18 2026): → Understood the crontab -e syntax — minute, hour, day, month, weekday → Scheduled a script to run every minute and watched it log live with tail -f → Faked per-second logging using a for loop + sleep inside a cron job → Built a real Daily System Health Reporter that: • Logs disk, memory, uptime & top 3 CPU processes • Auto-creates a dated log file (health-2026-04-18.log) every day • Redirects all output using exec > "$log" 2>&1 → Scheduled it to run every weekday at 8 AM → Learned date +%F for clean YYYY-MM-DD formatted filenames The moment tail -f showed entries ticking every second — that's when it clicked. Cron isn't just scheduling. It's your server working for you while you sleep. #Linux #DevOps #BashScripting #CronJobs #LearningInPublic #100DaysOfDevOps
To view or add a comment, sign in
-
Day 06 of #90DaysOfDevOps 🚀 Linux File I/O: A Core DevOps Skill Today I revisited the basics — this time thinking like an operator, not a student. Reading and writing files is part of daily DevOps work: → Tailing logs during an incident at 2 AM → Updating configs in deployments → Capturing script output for debugging → Managing YAML, Dockerfiles, and shell scripts What I practiced today: ✅ `echo "..." > file.txt` — overwrite with intention (one wrong `>` can wipe a config file) ✅ `echo "..." >> file.txt` — safe append for logs and configs ✅ `echo "..." | tee -a file.txt` — write AND display simultaneously ✅ `cat`, `head`, `tail` — inspect file contents at different granularities 💡 Command I'll use often: `tee` Perfect for scripts where output needs to be both visible and logged at the same time. 🔑 Key Insight: Every config, log, Dockerfile, and manifest is just text. Engineers who handle text efficiently troubleshoot faster and ship faster. #90DaysOfDevOps #DevOpsKaJosh #TrainWithShubham #Linux #DevOps
To view or add a comment, sign in
-
🚀 Running Kubernetes on WSL with Minikube (No Docker Needed!) 🚀 Recently, I set up Minikube on Windows WSL using containerd instead of Docker, and it was quite a learning journey. Here’s a nutshell version of what happened: The Challenges 1️⃣ Missing runtime tools – Minikube complained that crictl was missing. 2️⃣ Default Docker assumption – WSL didn’t have Docker, so Minikube couldn’t start. 3️⃣ Networking issues – Kubernetes required CNI plugins for pod networking. 4️⃣ Containerd config missing – WSL didn’t generate /etc/containerd/config.toml by default. The Fixes ✅ Installed crictl to satisfy Kubernetes runtime requirements. ✅ Configured containerd as the runtime (avoiding Docker entirely). ✅ Downloaded and installed CNI plugins in /opt/cni/bin to enable pod networking. ✅ Generated a default containerd config and started it in the background so Minikube could connect. How it Works Behind the Scenes Minikube talks to containerd through the CRI socket. Pods are sandboxed using the pause container. CNI plugins assign IPs, bridges, and routes to pods. Kubernetes components start on the bare-metal “none” driver, fully operational. 💡 Key Takeaways You don’t need Docker to run Kubernetes on WSL — containerd + CNI is enough. WSL lacks systemd, so manual setup of containerd config and background start is necessary. Understanding Minikube + containerd + CNI is a great way to learn Kubernetes internals. #Kubernetes #Minikube #containerd #DevOps #CloudNative #CNI #Linux #LearnInPublic
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
-
Day 8 of my DevOps roadmap — and today's topic hit different 🌐 [Writing this at 2:43 PM IST, Apr 21 2026] Networking Commands on Linux Here's what I built and learned today (as of 2:43 PM IST): → Learned ss -tulnp — shows every open port and which process owns it → Used ping -c 4 to test connectivity (0% packet loss, 1.2ms latency ✓) → Curled my own site korelium.org and saw the raw HTML come back in terminal → Built a network_audit.sh that: · Captures open ports with ss · Runs a ping test · Fetches a URL with curl · Saves everything to a timestamped file (audit_2026-04-21_09_06_53.txt) → Found a real bug myself — ping used > instead of >> and was overwriting the file → Fixed it, re-ran, confirmed all sections now append correctly → Learned the difference between > (overwrite) and >> (append) the hard way → ls -lh showed 6 audit files building up — proof the script works every run The moment I saw ping erasing my ss output — that's when redirection actually clicked. Not just running commands. Understanding what they do to your files. #Linux #DevOps #BashScripting #Networking #LearningInPublic #100DaysOfDevOps
To view or add a comment, sign in
-
-
Objective 703.2 of the Linux Professional Institute (LPI) DevOps Tools Engineer 2.0 exam covers Basic Kubernetes Operations, a key part of modern #DevOps. 🖥️⚙️ Explore this exam objective with Fabian Thorns and Uirá Ribeiro: https://lpi.org/5tqu #LPI #kubernetes #devops #cloudnative #containerorchestration #devopsengineer
To view or add a comment, sign in
-
-
🚀 Kubernetes Monitoring with CLI – Back to the Basics Today I spent time working directly from the command line to monitor and manage my Kubernetes workloads — and it reminded me of something important: 👉 If you want to master Kubernetes, you must be comfortable with Linux and the CLI. Here are a few commands I used while managing deployments: -kubectl rollout undo deployment web-app → Roll back to a previous version -kubectl rollout history deployment web-app → View deployment revisions -kubectl delete deployment web-app → Clean up resources 💡 These commands are not just for exams like CKAD/KCNA — they are real-world DevOps skills used in production environments. Working from the CLI gives you: ✔️ Better control over your cluster ✔️ Faster troubleshooting ✔️ Deeper understanding of how Kubernetes actually works 🔥 My advice: -Don’t rely only on dashboards and GUIs. Learn the terminal. Learn Linux. That’s where real power is. -I’m continuing to build and document real-world Kubernetes projects — next step: scaling microservices and adding ingress. Let’s grow together 💻☁️ #Kubernetes #DevOps #CloudComputing #Linux #CKAD #KCNA #AWS #LearningInPublic
To view or add a comment, sign in
-
-
Day 8. 90% of DevOps issues are solved in the Terminal. The question is… can you solve them fast enough? 🐧💻 I’ve seen this happen too often: A server goes down. Disk hits 100%. And suddenly… Even great engineers hesitate. Not because they don’t know the tech— 👉 but because they haven’t built Terminal Reflex So I spent weeks doing one thing: 👉 Turning scattered Linux commands into a clear, usable system Not just a cheat sheet… A Command Master-Map I can rely on under pressure. 📘 What’s inside this 13-page Deep Dive: 📦 The Survival Trio → df -h, du -sh, free -h → Diagnose storage & memory issues in seconds 🔍 The Pattern Hunter → grep with -i, -n, -v → Find 1 error in 10GB logs without losing your mind ⚙️ Process Control → ps -ef, kill -9 → Stop rogue processes before they crash your system 🔐 Permission Control → chmod, chown → Understand why 777 is dangerous 🌐 Networking Basics → ifconfig, netstat -an → See every connection your system is making 💡 The biggest realization: GUI makes things easier… 👉 CLI makes you reliable And in DevOps? Reliability > Convenience. 📥 Free Resource: I’m sharing my full 13-page Linux Command PDF below Built from real practice—not theory. 👉 Save it. Bookmark it. Use it when things break. 💬 Question for the community: What’s the first Linux command that made you feel like a pro? (Mine was grep -v — total game changer) Let’s help beginners level up 👇 #Linux #DevOps #SystemAdministration #CloudComputing #TechLearning #OpenSource #TerminalTips #LearningInPublic
To view or add a comment, sign in
-
🚀 #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
To view or add a comment, sign in
-
Explore related topics
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