Ayush Katiyar’s Post

*From Manual Deployments to Full GitOps Control (ArgoCD on EKS)* I stopped deploying manually… and everything changed. No more kubectl apply. No more guessing what’s running in the cluster. I just completed Phase 2 of my self-directed DevOps journey—this time with GitOps on a live AWS EKS cluster. And here’s what surprised me… I pushed YAML to GitHub… and ArgoCD deployed everything automatically. No touch. No manual steps. Then I tested it. I changed replicas from 2 → 3 in one commit. Within 60 seconds, the cluster updated itself. So I tried breaking it. I manually scaled it down to 1. ArgoCD reverted it back to 3. That’s when it clicked: In GitOps, Git is the source of truth, not the cluster. I went further: → Upgraded nginx from 1.25 → 1.26 with zero downtime → Rolled back with a single commit → Used Kustomize to manage dev, staging, and prod from one base → Added a new environment with just a few lines using ApplicationSet → Synced secrets securely using ESO + AWS Secrets Manager (nothing exposed in Git) Every deployment? Tracked. Versioned. Traceable. 4 deployments. 4 commits. Full audit trail. No guesswork. No drift. Just clean, controlled infrastructure. This is what real-world DevOps feels like. Still learning. Still building. #DevOps #GitOps #Kubernetes #AWS #EKS #ArgoCD #CloudEngineering #InfrastructureAsCode #SRE #CloudComputing #TechJourney #LearningInPublic #BuildInPublic

Getting Started with GitHub Actions – My First Steps I recently started working with GitHub Actions and wanted to share a quick beginner-friendly overview for anyone getting started in DevOps or CI/CD. 🔹 What is GitHub Actions? GitHub Actions is a CI/CD tool that allows you to automate workflows directly from your repository. 🔹 Basic Concepts: • Workflow → Defined in .github/workflows/ • Events → Trigger (push, pull_request, etc.) • Jobs → Set of tasks running on a runner • Steps → Individual commands inside a job 🔹 Simple Example Workflow: name: CI Pipeline on: push: branches: [ "main" ] jobs: build: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v3 - name: Run a script run: echo "Hello, GitHub Actions!" 🔹 Why use GitHub Actions? - Seamless GitHub integration - Easy automation - Supports multiple environments - Great for CI/CD pipelines This is just the beginning. The next step is integrating with Docker, AWS, and Terraform #DevOps #GitHubActions #CICD #Automation #Cloud #AWS

After working with tools like GitHub Actions and Jenkins, I was able to build CI/CD pipelines, automate deployments, and interact with Kubernetes clusters efficiently. Question arrises:- If CI/CD is already handling deployments, why do we need GitOps tools likeArgo CD? GitOps is a modern approach to continuous delivery (CD) for Kubernetes and cloud-native applications. It uses Git repositories as the single source of truth for declaring the desired state of your system. Instead of manually deploying or configuring applications, everything (apps, infrastructure, policies) is written as declarative code (YAML/JSON) and stored in Git. A GitOps operator (like ArgoCD) continuously ensures the cluster matches what’s in Git. ** DVAO Principle 1. Declarative The desired state of the system is described declaratively (e.g., YAML manifests). Example: A Deployment manifest defines how many replicas and which container image. 2. Versioned & Immutable Desired state is stored in Git (or another versioned system). Every change is auditable and traceable. 3. Automated A controller (like ArgoCD) continuously watches Git and the cluster. If there’s drift (difference), it automatically applies changes. 4. Observable System health and deployment status are visible. Git history + dashboards + alerts provide observability. Special thanks to Shubham Londhe for explaining GitOps so clearly!🚀🚀 #Cloud #Devops #GitOps #ArgoCD #CICD #Kubernetes #AWS

Built a complete production-grade DevOps setup on AWS  from scratch and documented the entire journey 🚀 What I built and deployed: 🔹 Next.js app containerized with Docker 🔹 Automated CI/CD pipeline with GitHub Actions 🔹 AWS EKS cluster provisioned with eksctl 🔹 Kubernetes — Pods, Namespaces, Deployments, Services 🔹 Nginx Ingress Controller with AWS ELB 🔹 Helm Charts — custom and third party 🔹 Secrets encrypted and stored safely with Sealed Secrets 🔹 GitOps auto-deployment with ArgoCD 🔹 Auto Scaling with HPA + Cluster Autoscaler 🔹 HTTPS with cert-manager + Let's Encrypt 🔹 Full observability — Prometheus + Grafana + Alertmanager Every piece of this is running on real AWS infrastructure — not localhost, not theory. Documented the entire build process on YouTube and the  infrastructure code is open source on GitHub 👇 https://lnkd.in/g-xyMPpu https://lnkd.in/guFFsAAB #DevOps #Kubernetes #AWS #EKS #ArgoCD #Prometheus #Grafana #GitHubActions #Docker #Helm #CICD #NextJS

🚀 Day 7 of My DevOps Journey — GitHub Webhooks (Real-Time CI/CD) Until now, I was triggering Jenkins pipelines manually. Today, I automated the trigger itself. 👉 Push code → Pipeline runs automatically This is what real DevOps looks like. 🔹 What I Practiced: - Setting up GitHub Webhooks - Connecting GitHub → Jenkins - Configuring webhook triggers in pipeline - Testing end-to-end automation 🔹 Mini Project: I implemented a real-time CI/CD flow: ✔ Pushed code to GitHub ✔ Webhook triggered Jenkins build instantly ✔ Pipeline executed automatically ✔ Docker image built & deployed No manual steps. Fully automated 🔥 🔹 Real Issues I Faced: ❌ 403 error (No valid crumb included) ❌ 400 error (Bad webhook request) 🔹 How I Fixed It: ✔ Configured Jenkins security settings (CSRF / crumb issue) ✔ Verified webhook URL & payload ✔ Used tools like ngrok for local webhook testing 💡 Key Learning: “DevOps is not about speed — it’s about automatic reliability.” Now I understand: - Event-driven automation - How real CI/CD pipelines are triggered - Importance of secure integrations Next → AWS EC2 Deployment (taking pipelines to cloud ☁️) If you're building in DevOps, let’s connect 🤝 #DevOps #Webhooks #Jenkins #CICD #Automation #Cloud #AWS #LearningInPublic

I still remember the day someone asked me. "How does a real DevOps pipeline actually work in a company?" So I built it. From scratch. And recorded everything. 🎬 Here's what we cover in this video: 👉 3 environments — Dev, QA and Prod — and how code actually moves between them 👉 Branching strategy — not just for app code, but for Terraform (infra) too 👉 Deploying microservices on EKS using ArgoCD the GitOps way 👉 How a real microservices setup looks and behaves in production This is not a hello world project. This is how it works in real companies. 🏢 If you're learning DevOps and feel like the pieces don't connect yet — this one's for you. Watch here 👇 https://lnkd.in/gKPkmhMe Drop your questions in the comments. Happy to help! 🙌 #DevOps #AWS #EKS #ArgoCD #Terraform #GitOps #Kubernetes #Microservices #CI_CD #RealWorldProject

Week 4, Day 12 of my Cloud Computing journey with TechCrush Today marked an important step forward as we dove into the Git and GitHub workflow — the backbone of modern collaboration in software and cloud development. We also explored the fundamentals of CI/CD (Continuous Integration/Continuous Deployment) and how pipelines automate testing, building, and deployment processes for faster, more reliable releases. To make the concepts stick, here are some of the essential Git commands we worked with and what they do: ✅git init — Initializes a new local Git repository in your project folder. ✅git clone <repository-url> — Creates a local copy of a remote repository (e.g., from GitHub) so you can start working on it. ✅git add . — Stages all your changes (new, modified, or deleted files) for the next commit. ✅git commit -m "Your meaningful message" — Saves your staged changes to the local repository history with a clear description. ✅git push origin main (or your branch) — Uploads your committed changes to the remote GitHub repository. ✅git pull origin main — Fetches and merges the latest changes from the remote repository to keep your local copy updated. ✅git branch and git checkout -b <branch-name> — Creates and switches to a new branch for isolated feature development (a best practice to avoid messing with the main codebase). We wrapped up the session with our bi-weekly assessment, and I'm happy to report it went very well!😎 Grateful for these sessions that are building a strong foundation in cloud technologies and DevOps practices. #CloudComputing #Azure #Git #GitHub #CICD #DevOps #LearningInPublic #TechJourney

Every DevOps engineer has been there — you know a command exists, you used it last week, but you just can't remember the exact syntax. So I built kli.st to fix that. kli.st indexes 5,000+ commands across 20 tools (Docker, Kubernetes, Terraform, Helm, ArgoCD...) and makes them searchable in plain English via Gemini AI. But the real project is what runs underneath: Kubernetes bare-metal on Proxmox VE — no managed cluster, configured from scratch Cilium (eBPF) — replaced kube-proxy, full L7 observability via Hubble ArgoCD — GitOps, zero manual kubectl in production Argo Rollouts — Blue/Green with automated Prometheus analysis + rollback in <60s GitHub Actions — 3 pipelines, push to dev triggers everything automatically HashiCorp Vault — no secrets in Git, ever Velero + Kopia — automated backups to GCS, full cluster restore from scratch Prometheus + Grafana — same metrics that power dashboards also gate deployments Thesis project for DevOps & Cloud Infrastructure. Built it like production — because it is. kli.st #kubernetes #devops #gitops #cicd #argocd #cilium #vault #prometheus #cloudnative

🚀 Excited to share a simple overview of a CI/CD pipeline I’ve been working with! From code commit to deployment, everything is automated to ensure quality, security, and speed. 🔹 Developers push code to GitHub 🔹 Jenkins handles CI & CD pipelines 🔹 Dependencies are checked using OWASP Dependency-Check 🔹 Code quality is analyzed with SonarQube 🔹 Container images are built using Docker 🔹 Security scanning is done with Trivy 🔹 Deployment is automated via Argo CD to Kubernetes 🔹 Monitoring and alerts with Prometheus and Grafana 💡 This setup helps: Catch issues early Improve code quality Ensure secure deployments Deliver faster and more reliably Always learning and improving—open to feedback and suggestions! #Devopsinsider #DevOps #CICD #Automation #Kubernetes #Cloud #SoftwareDevelopment

I've used GitHub Actions, GitLab CI, and Azure DevOps. Here's why I keep coming back to ArgoCD for production deployments — and when I don't. The problem with push-based CI/CD: Your pipeline pushes to the cluster. If something drifts — a manual kubectl apply, a failed rollback, a config change — your pipeline doesn't know. Your cluster is now lying to you. ArgoCD flips this. The cluster pulls from Git. Git is truth. If your cluster doesn't match Git, ArgoCD self-heals. You get drift detection out of the box. What I love about it in practice: → Rollbacks are just Git reverts — no pipeline magic needed → Every deploy is visible, auditable, and reproducible → Works beautifully with Helm + Kustomize → The UI is genuinely useful for oncall When I DON'T use ArgoCD: → Stateful apps with complex DB migrations (timing matters) → Very small teams where GitOps overhead > benefit → Non-Kubernetes workloads (wrong tool for the job) The honest take: ArgoCD isn't magic. It requires discipline in how you structure your repos. But once it clicks, going back to push-based deployments feels like deploying by FTP. Have you made the GitOps shift? What broke when you did? #ArgoCD #GitOps #Kubernetes #CICD #DevOps ☢️