Sahil Sharma’s Post

🚀 Day 7/100 – Shell Scripting Basics Tired of running the same commands again and again? 😅 👉 That’s exactly why Shell Scripting exists. 🔍 What is Shell Scripting? Shell scripting is writing a series of Linux commands in a file that can be executed automatically. 👉 Instead of doing tasks manually, you automate them with scripts ⚡ ⚙️ Basic Example #!/bin/bash echo "Starting deployment..." git pull origin main docker build -t my-app . docker run -d -p 80:80 my-app echo "Deployment complete 🚀" 👉 Save → Run → Done ✅ 💡 Why Shell Scripting is Important in DevOps ✅ Automate repetitive tasks ✅ Reduce human errors ✅ Speed up deployments ✅ Glue different tools together 🛠️ Must-Know Concepts 🔹 Variables name="DevOps" echo "Hello $name" 🔹 Conditionals if [ -f "file.txt" ]; then echo "File exists" fi 🔹 Loops for i in 1 2 3 do echo "Run $i" done ⚠️ Common Mistakes ❌ Missing execution permission 👉 chmod +x script.sh ❌ Wrong shebang 👉 Always use #!/bin/bash ❌ Not handling errors 👉 Can break automation silently 📌 Real-World Use Case Deploying an app: Pull latest code Build Docker image Run container 👉 All in one script 📌 Key Takeaway 👉 Shell scripting = automation superpower for DevOps If you can script it… you don’t have to repeat it 🚀 💬 What’s the most useful script you’ve written so far? #DevOps #ShellScripting #Linux #Automation #100DaysOfDevOps #LearningInPublic

🚀 End-to-End Deployment Automation with Bash & Docker I recently worked on a hands-on DevOps challenge where I automated the deployment of a Django Notes application using a Bash script — and it was a great learning experience! 🎯 Objective: Build a complete deployment pipeline using simple Bash scripting. 🛠️ What I implemented: 🔹 Cloned the application repository 🔹 Installed all required dependencies 🔹 Built a Docker image for the application 🔹 Pushed the image to Docker Hub 🔹 Deployed the container on a VM 🔹 Verified the deployment by checking container status 💡 Key Takeaways: ✔️ Learned how to structure Bash scripts for real-world automation ✔️ Improved understanding of Docker workflows (build, tag, push, run) ✔️ Gained practical exposure to deployment on a virtual machine ✔️ Understood how small scripts can simplify repetitive DevOps tasks Thanks Shubham Londhe for the repo "django-notes-app". I am able to deploy this application on my ubuntu-server VM. It was a good learning experience. 😊 #DevOps #BashScripting #Docker #Automation #CloudComputing #Linux

 How many times have you pushed a workflow file only to have the CI fail because of a typo, a missing job reference, or a    circular dependency? PipeChecker catches those problems before they reach your repo.    🔍 What it checks:    ✅ Circular job dependencies (via Tarjan's SCC algorithm)    ✅ Missing needs / depends_on references    ✅ Hardcoded secrets & undeclared env vars    ✅ Unpinned GitHub Actions & Docker :latest tags    ✅ Empty or malformed pipelines    🛠 Built with Rust for speed, with support for GitHub Actions, GitLab CI, and CircleCI.    📦 Available on crates.io, npm, and as standalone binaries (Linux, macOS, Windows).    🔗 GitHub: https://lnkd.in/gXu_-a7e    Would love feedback from the DevOps / platform engineering community. What's the worst CI/CD config mistake you've shipped to    prod? 😅o    #Rust #DevOps #CICD #GitHubActions #PlatformEngineering #CLI #OpenSource

🚀 Automating Your Dev Workflow with GitHub Actions In today’s fast-paced development world, manual processes slow us down. That’s where GitHub Actions comes in — a powerful CI/CD tool that helps automate your entire software workflow right from your repository. 🔧 What are GitHub Actions? GitHub Actions allow me to define custom workflows that automatically build, test, and deploy my code whenever specific events occur (like a push, pull request, or scheduled trigger). 📌 What is a Workflow? A workflow is a configurable automated process defined using a YAML file inside the ".github/workflows" directory. It consists of: - Events → What triggers the workflow (e.g., push, PR) - Jobs → A set of steps executed on a runner - Steps → Individual tasks like running scripts or actions ⚙️ Why I use GitHub Actions: - Automates repetitive tasks (build, test, deploy) - Ensures consistent and reliable pipelines - Integrates seamlessly with repositories - Supports multiple environments (Linux, Windows, macOS) - Saves time and reduces human errors 💡 Simple Example Workflow: Whenever I push code, it automatically builds and tests my application — no manual effort needed! name: CI Pipeline on: push: branches: [ "main" ] jobs: build: runs-on: ubuntu-latest steps: - name: Checkout Code uses: actions/checkout@v3 - name: Set up Java uses: actions/setup-java@v3 with: java-version: '17' - name: Build Project run: mvn clean install 🎯 Real Impact: In my projects, GitHub Actions has helped streamline deployments, catch bugs early, and improve overall productivity. If you’re not using CI/CD yet, GitHub Actions is a great place to start! #GitHubActions #DevOps #CICD #Automation #SoftwareDevelopment #Java #SpringBoot #Angular #Cloud

The terminal used to intimidate me.  Now I'm building automation tools from scratch. 🖥️ I've finally finished my Bash module and here are  the lessons I've learnt and challenges I've faced. Bash is something you'll always hear when speaking  about DevOps. It's one of the most important  fundamentals that must be learnt. It's used in  automation, deployments, monitoring, backups and more. At first the syntax seemed like it was just too much  to understand — until a colleague gave me advice that  changed everything. He told me that learning syntax  whilst solving a real problem is far more effective  than memorising it. What got me through it was building first, breaking  it, then figuring out why. He was right, and it saved  me a lot of time. After completing the projects, some of the skills  I've learnt are to: → Write scripts with loops, conditionals & arguments → Automate file backups with rotation → Monitor directories and log changes with timestamps → Parse config files → Build interactive menu-driven system tools By the final challenge I had written a single script  that checks disk space, shows system uptime, runs  backups, and parses a config file — all from a menu  I built myself. That moment made it click. The terminal isn't  something to fear. It's just another tool —  and now it's one I actually understand. If you're going through similar struggles, feel free  to shoot me a message! Full project documentation on GitHub 👇 https://lnkd.in/eAp9m6Uj Next up: Git. Learning how to properly track, version,  and collaborate on code. Follow along if you're on a  similar journey — I'll be posting as I go. 🚀 #Bash #Linux #LearningToCode #100DaysOfCode #Bootcamp #DevJourney #ShellScripting #Git

🚀 Debugging a small issue that taught me a bigger DevOps lesson While working on my Flask-based Status API and setting up a CI pipeline with GitHub Actions, I ran into an issue that looked simple on the surface but made me think deeper about environments. I was trying to create the .github/workflows directory using a command I had seen commonly used: mkdir -p .github/workflows It kept failing with a syntax error. At first, I thought I had made a typo, but the real issue was more subtle — I was running this on Windows CMD, where that syntax doesn’t work the same way as in Linux. After digging into it, I fixed it by explicitly creating the directory structure: mkdir .github mkdir .github\workflows This small fix made me realize something important: DevOps is not just about tools like Docker or CI/CD pipelines, but about understanding how different environments behave and how small assumptions can break automation. 🔹 What this project covers: - Flask-based API with structured JSON responses - Dockerfile for containerizing the application - GitHub Actions pipeline triggered on every push - Automated dependency installation and Docker image build - Basic monitoring exposure using a /metrics endpoint 🔹 Key takeaway: Even a minor issue like directory creation can break an entire CI pipeline if the structure is not exactly what the system expects (.github/workflows in this case). Attention to detail really matters in automation. Still building, still learning — focusing on getting the fundamentals right. 🔗 Project Repo: https://lnkd.in/gCfZZM4M #DevOps #CI #Docker #GitHubActions #Python #Flask #LearningInPublic

⚡ Day 16 – Shell Scripting Fundamentals in DevOps Today’s focus was on making my scripts more interactive and reliable. I worked through: 🔹 User input with read — capturing numbers, strings, and service names directly from the terminal. 🔹 Conditional logic (if-else) — comparing numbers, checking strings, and handling multiple cases with elif. 🔹 File checks (-f) — writing a script that asks for a filename and confirms if it exists. 🔹 Service checks (systemctl) — building a script that asks for a service name and reports if it’s active or not. 🔹 Troubleshooting syntax errors — learning why spaces around [ ] and using the right operators (= for strings, -eq for numbers) are critical in Bash. 💡 Key takeaway: Shell scripting is unforgiving about syntax, but that’s what makes it powerful. Every space, operator, and quote matters — and mastering these details builds the foundation for automation in DevOps. #90DaysOfDevOps #Day15 #DevOpsKaJosh #TrainWithShubham #Linux #ShellScripting #LearnInPublic

Honestly? I thought Ansible was going to break me. Everyone kept saying "just automate it" like it was the easiest thing in the world. Meanwhile I was sitting there staring at YAML files. But here's what actually happened — I started small. Really small. Just ad-hoc commands. Nothing fancy. And the moment I ran one command and watched it execute across ALL my servers at once? I literally said "wait... that just worked?" out loud to nobody. Installed Git on every server in one shot. Created files and folders across the entire inventory like it was nothing. That feeling of control? Addictive. That's when I got brave enough to write my first real playbook. I set myself a challenge — install Tomcat on all my servers. No tutorials holding my hand. Just me, the Ansible docs, and a lot of trial and error. Here's what that journey looked like module by module: 🔹 get_url — to pull the Tomcat binary straight from the internet into /opt 🔹 unarchive — to extract it (and learned the hard way about remote_src: true when the file lives on the target server, not locally) 🔹 command — to rename the extracted folder cleanly 🔹 file — to set ownership and give executable permissions to startup.sh, catalina.sh, and shutdown.sh 🔹 template — to write a proper systemd service file 🔹 systemd — to reload and start the Tomcat service 🔹 lineinfile — to comment out lines in context.xml and inject credentials into tomcat-users.xml Every module was a new rabbit hole. Every error was a lesson. The best part? I didn't just copy-paste. I read the docs. I understood WHY each parameter existed. That shift — from "make it work" to "understand it" — that's where real learning happens. If you're sitting where I was a few weeks ago, thinking Ansible is too complex — Start with one ad-hoc command. Just one. The rest will follow. 🚀 #Ansible #DevOps #Linux #Automation #LearningInPublic #CloudEngineering

Jenkins is finally running locally. Here’s the breakthrough—and what it taught me: After 2 days of debugging exit-code 1, this worked on Ubuntu 24.04: sudo systemctl edit --full jenkins Set: ExecStart=/usr/lib/jvm/java-21-openjdk-amd64/bin/java \ -Djava.awt.headless=true \ -jar /usr/share/java/jenkins.war \ --webroot=/var/cache/jenkins/war \ --httpPort=8081 \ --enable-future-java Then: sudo systemctl daemon-reload sudo systemctl start jenkins ✅ Status: Active: active (running) --- ### 💡 What this taught me: 1. *Read release notes*   Jenkins 2.479 + Java 21 requires --enable-future-java 2. *Argument order matters*   JVM flags → before -jar   Jenkins flags → after .war 3. *Systemd is the source of truth*   Ubuntu no longer uses /etc/default/jenkins 4. *Local-first learning wins*   This cost me $0 and taught me more than AWS ever could --- Now running *Jenkins + Docker plugins locally for CI/CD practice* 💰 Cost: $0 📈 Value: Massive --- If you're learning DevOps: 👉 Break things locally. The errors are the curriculum. What’s the toughest config bug you’ve faced recently? #Jenkins #Ubuntu #Systemd #DevOps #BuildInPublic

Day 33/100: The Ultimate "Undo" Button – Git Rollbacks & Diffs ⏪ Today’s Focus: Over the last few days, I learned how to save my code with Git, but what happens when you make a mistake? What if you commit the wrong file, or a new feature completely breaks the project? Today, I focused on Git Rollbacks, learning how to inspect changes and safely travel back in time to fix errors. 🛠️ The Commands I Mastered: Before you can undo a mistake, you have to see it. Then, you need to choose the right way to remove it: git diff: The detective tool! Before I stage or commit anything, this command shows me exactly which lines of code I added (in green) or deleted (in red) since my last save. It is the perfect final sanity check. git reset [commit-hash]: The standard rollback. This moves the project's history back to a specific older commit, but it safely keeps all my current code changes in my working directory so I can edit them. git reset --hard [commit-hash]: The nuclear option! ☢️ This command doesn't just roll back the history; it completely wipes out any new code I wrote after that specific commit. It makes the files look exactly as they did at that moment in the past. Use with caution! Why It Matters: In real-world DevOps and software engineering, you will break things. Knowing how to use git diff prevents bad code from being committed in the first place, and mastering git reset ensures that even if bad code makes it into the repository, you can instantly revert the system back to a stable, working state! 🛠️ #100DaysOfDevOps #100DaysOfCode #Git #VersionControl #Linux #SysAdmin #DevOpsEngineer #TechJourney #DailyProgress #CloudComputing #CodingLife