Eswara Manikanta’s Post

A Full-Stack CI/CD Pipeline for Python Microservices I’ve just completed the engineering of a streamlined CI/CD pipeline that transforms raw Python code into a production-ready, containerized artifact in under 20 seconds. In modern software delivery, speed is nothing without safety. This project focuses on building "Quality Gates" that ensure only verified code reaches the registry. Technical Implementation: Automated Quality Assurance: Integrated py_compile and unittest suites to enforce code integrity before the build stage. Optimized Containerization: Leveraged Docker to create lightweight, immutable environments, ensuring the "it works on my machine" problem is eliminated. Secure Pipeline Architecture: Implemented a Declarative Jenkins Pipeline with strict credential masking and post-build cleanup protocols (Workspace wiping & Docker logout). Versioned Delivery: Automated the tagging and pushing of images to Docker Hub, creating a seamless bridge between development and deployment. By automating these "table stakes" tasks, we allow engineering teams to focus on feature development while the infrastructure handles the validation. Tech Stack: Jenkins | Docker | Python | Docker Hub | Linux #DevOps #CloudNative #PythonDevelopment #Jenkins #Automation #SoftwareEngineering #SolaRoyal

Nothing teaches you OpenShift better than a broken tutorial... I was recently going through the "Foundations of OpenShift" tutorial by Red Hat, expecting a smooth "Import from Git" experience. Instead, I got a CrashLoopBackOff and a bunch of cryptic logs. It turns out the sample code was quite outdated. It relied on a deprecated tool called powershift-cli that just doesn't work with modern Python S2I images anymore. What I did to fix it: Dug into the logs: Found that the container was trying to run a command that no longer exists (powershift image). Forked the repo: Rewrote the run script to use a standard Django startup. Fixed the "hidden" bugs: Found some syntax errors in the background scheduler and added automatic migrations (no more 500 errors!). Handled the DB: Realized why the blog was empty (ephemeral SQLite storage) and documented it for anyone else trying this tutorial. It took a bit of debugging, but I honestly learned more about OpenShift's build process and S2I than I would have if the "Start" button had just worked. If you're stuck on Tutorial 4, feel free to use my updated repo: https://lnkd.in/dNfjEnGS #OpenShift #DevOps #Django #LearningByDoing #Kubernetes

🚀 Implemented a basic CI pipeline using GitHub Actions. On every push, the workflow: Triggers via event-based execution Runs on ubuntu-latest runner Uses a matrix strategy to test across Python 3.8 & 3.9 Checks out repo using actions/checkout@v3 Sets up Python via actions/setup-python@v2 Installs dependencies (pip, pytest) Executes tests using python -m pytest 📁 .github/workflows/first-actions.yaml 🎯 Ensures consistent builds, multi-version compatibility, and automated test validation on every commit (CI). 🔗 Repo: https://lnkd.in/gDpgTwG2 📝 Article: https://lnkd.in/gZwinuZ4 #GitHubActions #CI #DevOps #Python #Automation

🎉 I Just Built & Ran My First Docker Image – Here’s What I Learned 🐳 Hey everyone, After learning the basics of Docker containers in my previous posts, today I took the next big step. I moved from just using other people’s containers to building and running my own — and it feels amazing! As a Full Stack Developer learning DevOps, this was a real milestone for me. What I Built I created a simple Python Flask web application and packaged it into my very first custom Docker image. Here’s the flow I followed: Created a small Flask app (app.py) that shows a welcome message. Added a requirements.txt file. Wrote my first Dockerfile (using the 80/20 rule – only the important commands). Built the image with: docker build -t python-app-img . Ran the container with: docker run -d -p 5000:5000 python-app-img Opened http://localhost:5000 in my browser — and it worked! ✅ Real-World Value (Why This Matters). In real companies, you can’t keep installing dependencies and configuring servers manually on every machine. With one well-written Dockerfile: Every developer gets the exact same environment No more “It works on my machine” problems Faster onboarding for new team members Consistent and reliable deployments. This small Python app I built today is exactly the kind of practical exercise that helps you understand how production applications are containerized. My Key Takeaway Building your first Docker image is the moment you stop being just a user of technology and start becoming a creator of reliable systems. It’s not complicated once you do it step by step. If you’re also learning Docker or DevOps, tell me — what was your first Docker project? Or what’s the biggest challenge you’re facing right now? I read and reply to every comment. Let’s grow together! 👇 #Docker #Dockerfile #FirstDockerImage #DevOps #LearningInPublic #DockerBeginner #FullStackDeveloper #TechJourney #SystemEngineering #CloudComputing #80_20Rule

🐳 Docker Basics: Image, Container & Dockerfile (Easy Guide) Starting with Docker? Let’s understand the 3 most important concepts 👇 📦 Docker Image (Blueprint) 👉 A Docker Image is a template of your application 👉 It contains: - Code - Libraries - Dependencies - OS setup 💡 Think of it as a ready-made package 🚀 Docker Container (Running App) 👉 A container is a running instance of an image 👉 Features: - Lightweight - Fast - Isolated 💡 Image = Recipe 🍲 💡 Container = Cooked Food 🍛 📄 Dockerfile (Instructions File) 👉 A Dockerfile is a script with instructions to build an image 👉 It includes steps like: - Base image selection - Installing dependencies - Copying code - Running commands 💡 Example: FROM python:3.9 COPY . /app RUN pip install -r requirements.txt CMD ["python", "app.py"] 🔄 Simple Flow: Dockerfile → Image → Container 🔥 Master these 3 concepts to start your Docker journey! #Docker #DevOps #Containers #Programming #Cloud #Job #Hiring

“How much Python should a DevOps Engineer know?” 🤔 After working through different DevOps tasks, one thing became clear: It’s not about how much Python you know… It’s about how effectively you can use it in real scenarios. Here’s how I see it 👇 💡 Core Skills (Non-negotiable) ✔ Writing clean scripts ✔ Working with files & logs ✔ Handling errors properly 👉 This is the foundation for automation 💡 Practical DevOps Usage ✔ Calling APIs (cloud / tools) ✔ Parsing JSON & YAML ✔ Automating workflows 👉 This is where Python becomes powerful 💡 Advanced Usage (Context-driven) ✔ Building CLI tools ✔ Writing reusable modules ✔ Optimizing scripts for scale 👉 Needed when you're solving larger problems ⚡ Key Insight: In DevOps, Python is not a goal… 👉 It’s a tool to automate, integrate, and scale systems 🚀 For hands-on practice, I found this repo really useful: Check out Abhishek Veeramalla's work 🫡 : 👉 https://lnkd.in/dTqaK8fQ 🧠 Final Thought: Strong DevOps engineers don’t just “know Python”… They use it to eliminate manual work and improve systems How are you using Python in your DevOps workflow? #DevOps #Python #Automation #Cloud #Learning #Engineering

This my second hand on project demonstrates a complete Continuous Integration (CI) pipeline using GitHub Actions for a Python Flask application. The pipeline automates every step from code push to Docker image delivery ensuring fast, reliable, and consistent builds. Key Highlights: Trigger: On every push to the main branch, GitHub Actions automatically starts the workflow. Steps: Checkout Code – Clones the repository. Setup Python 3.9 – Configures the runtime environment. Install Dependencies – Installs Flask and pytest. Run Tests – Executes unit tests to validate the app. Build Docker Image – Packages the app using Docker. Push to Docker Hub – Publishes versioned images tagged with commit SHA. Outcome: Every commit produces a tested, containerized, and registry‑ready image. Optional Deployment: The Docker image can be deployed to Kubernetes, scaling to multiple replicas for high availability. Tools Used: GitHub Actions • Python 3.9 • Flask • pytest • Docker • Docker Hub • Kubernetes. The diagram visually shows the CI/CD flow: Developer pushes code → GitHub detects change → Actions workflow triggers. Sequential steps: Checkout → Setup Python → Install → Test → Build → Push. Final output: Docker image pushed to Docker Hub, ready for Kubernetes deployment. #Linkedin YouTubeLearningMateAmazon Web Services (AWS) #Project #handson

I thought Docker was just “run containers.” Turns out… that’s the least interesting part 🐳 While prepping for CKA course on YouTube by Varun Joshi, I went deeper—and a few concepts completely changed how I think about containerization. Here’s what actually clicked 👇 The problem Docker solves Before Docker, every environment was slightly different. Different Java versions. Different ports. Different configs. That’s how “works on my machine” became a real production issue 😅 Docker fixes this by packaging your app + dependencies into one consistent unit. How images actually flow Dockerfile → build → image → push → registry → run One pipeline. Repeatable everywhere. Also: • RUN = creates a new image layer • CMD = just metadata (no new layer) Small detail… big impact when debugging. Running containers (the right way) Three flags I now use daily: • -d → run in background • -p → port mapping (left = your machine) • --name → stop memorizing random IDs And base image matters more than you think: python:3.9 ≈ 1 GB vs python:3.9-slim ≈ 162 MB ⚡ Same app. Huge difference. CMD vs ENTRYPOINT (finally makes sense) • CMD = default, easily replaceable • ENTRYPOINT = fixed executable Best practice? Use both together. Multi-stage builds = game changer Keep build tools out of your final image. One small change: 495 MB → 162 MB Same output. ~67% smaller. Less size = faster deploys + fewer vulnerabilities. Big takeaway: Docker isn’t just about containers. It’s about consistency, repeatability, and control. Now moving into Kubernetes — Pods, Nodes, Clusters next 🚀 If you’re learning this stack too, what’s been your biggest “aha” moment so far? #Kubernetes #Docker #CKA #DevOps #CloudNative #K8s #ContinuousLearning #DevOpsEngineer #CNCF

🐳 Most Docker mistakes are invisible - until production breaks. Here are the Docker best practices I wish someone had told me earlier. Save this before your next deployment. 👇 ━━━━━━━━━━━━━━━━━━━━ 📦 1. STOP pulling bloated base images The #1 mistake: pulling a full OS image just to run a script. ❌ Bad - 1.2 GB image FROM python:3.11     # Full Debian OS + Python ✅ Good - under 60 MB FROM python:3.11-slim   # Minimal Debian, no extras FROM python:3.11-alpine  # Musl-based, ~22 MB Smaller image = faster pulls, faster CI, smaller attack surface. Always start slim. 🏎️ ━━━━━━━━━━━━━━━━━━━━ 🔐 2. NEVER bake secrets into your image ❌ Dangerous ENV DB_PASSWORD=supersecret123 COPY .env /app/.env ✅ Safe - inject at runtime services:  app:   env_file: .env   environment:    - DB_PASSWORD=${DB_PASSWORD} Your .env should always be in .dockerignore AND .gitignore. 🔒 ━━━━━━━━━━━━━━━━━━━━ 🏗️ 3. Multi-stage builds - ship only what you need FROM python:3.11-slim AS builder WORKDIR /app COPY requirements.txt . RUN pip install --prefix=/install -r requirements.txt FROM python:3.11-slim COPY --from=builder /install /usr/local COPY . . CMD ["python", "main.py"] Build tools never reach production. 🎯 ━━━━━━━━━━━━━━━━━━━━ ⚡ 4. Layer ordering - cache is your best friend ❌ Cache-busting every build COPY . . RUN pip install -r requirements.txt ✅ Dependencies cached separately COPY requirements.txt . RUN pip install -r requirements.txt COPY . . ━━━━━━━━━━━━━━━━━━━━ 🛡️ 5. NEVER run as root in production RUN adduser --disabled-password --gecos "" appuser USER appuser CMD ["python", "main.py"] ━━━━━━━━━━━━━━━━━━━━ 🧹 6. USE .dockerignore - always .git .env __pycache__ *.pyc node_modules ━━━━━━━━━━━━━━━━━━━━ 🎯 Quick wins checklist: ✅ Use slim or alpine base images ✅ Inject secrets at runtime, never bake in ✅ Multi-stage builds for heavy apps ✅ Layer ordering = cache hits = fast CI ✅ Non-root user in production ✅ Always maintain .dockerignore 💡 One rule: if you wouldn't commit it to GitHub, don't let it touch your Docker image. What's the Docker mistake you see most often? Drop it below 👇 #Docker #DevOps #Backend #Python #SoftwareEngineering #Containers #CloudNative

Improve your project's test coverage with CodeCov integration. Track what code is covered by tests, identify gaps, and ensure quality before merging. Perfect for Python developers working with GitHub actions.