Samriti .’s Post

🐳 Day 5/25 – Writing Your First Dockerfile #25DaysOfDocker 🚀 Today I learned how to write my first Dockerfile — and honestly, it’s simpler than most people think. A Dockerfile is nothing but a set of instructions to build your application image. 🧠 Think of it like this: Dockerfile = Recipe Docker Image = Packed Meal Container = Served & Running Meal 🔑 Basic Dockerfile Structure: FROM python:3.9 WORKDIR /app COPY . . RUN pip install -r requirements.txt CMD ["python", "app.py"] 📌 What each command does: FROM → Base image WORKDIR → Sets working directory COPY → Copies project files RUN → Installs dependencies CMD → Runs the application ⚠️ Common beginner mistakes: ❌ Forgetting .dockerignore ❌ Using heavy base images ❌ Installing unnecessary packages ❌ Not optimizing layer order 🎯 Key Takeaway: A Dockerfile is not just a file — It’s the foundation of your container strategy. Writing it cleanly means: ⚡ Faster builds 🔐 Better security 📦 Smaller images Mr. Bean is now officially building containers 😄 📌 Day 6 coming up: Docker Commands You Must Know #Docker #DevOps #Containers #CloudNative #LearningInPublic #25DayChallenge #MrBean #BeginnerFriendly

I used to be a "Manual Explainer." 🗣️ Happy Ansible Tuesday! For a long time, I felt like I was using Ansible "the wrong way." While everyone else was struggling with massive, nested JSON blocks in the uri module, I started writing my own custom Python modules for our internal APIs. I didn't care if it wasn't the "standard" path; it allowed for true idempotency and much cleaner playbooks than a series of hacked-together curl requests. But my "cleaner code" created a new problem: I became a human encyclopedia. Because I skipped the docstrings, I was the only person who knew how to use my modules. My Slack was a constant stream of "What’s the argument for this?" and "What does this return?" I realized that writing the logic is only half the battle. If your code doesn't explain itself to the rest of the team, you haven't actually automated anything, you've just moved the work from the terminal to your inbox. The "Wrong Way" Benefits: 🛠️ Custom Logic: Native modules for niche APIs don't exist; build your own. ✨ Cleaner Playbooks: Replace 50 lines of uri tasks with 5 lines of custom module code. 🛡️ Real Idempotency: You control exactly how the module checks state before making changes. I stopped worrying about doing it "right" and started focusing on making it documented. ❓ Question of the Day: PDF below. It focuses on the specific CLI command used to view those module examples—something that only works if you've written your docstrings correctly! 👇 I've dropped a breakdown on how to use Antsibull to automate your custom module documentation in the comments! #Ansible #DevOps #Automation #SoftwareEngineering #Python #DamnitRay #QOTD 

Built & Pushed My First Docker Image I took a solid step forward in my Docker journey by creating my first Docker image, running it successfully, and pushing it to Docker Hub. What I built: I created a Python + Flask based Docker image that runs a small web service. When the container starts, the application: - Runs a Flask web server - Displays the current date & time - Shows the container hostname (to prove it’s running inside Docker) - Listens on port 5000 This experience helped me clearly understand: - How Docker images are built - How dependencies are installed inside the image - How ENTRYPOINT and CMD work together - How containers are isolated from the local environment Image details: Docker Image: kuberanit/date-api:v1 How to test it yourself: If anyone wants to try it out, you can pull and run the image using: docker pull kuberanit/date-api:v1 docker run -p XXXX:5000 kuberanit/date-api:v1 (Note: Instead of XXXX, use any open port that is available in your host machine.) Then open your browser: http://localhost:5000 You should see the app running live. What this image demonstrates: - A reproducible Python environment - Dependency management using requirements.txt - A containerized web service that runs the same everywhere - A beginner-friendly but real Docker workflow Learning Docker step by step and finally seeing the app work inside a container feels really rewarding. Onward to more containerized projects. #Docker #DevOps #Containers #Python #Flask #LearningByDoing #DockerHub #CloudNative

𝗗𝗼𝗰𝗸𝗲𝗿 𝗝𝗼𝘂𝗿𝗻𝗲𝘆: 𝗠𝗼𝘃𝗶𝗻𝗴 𝗳𝗿𝗼𝗺 "𝗛𝗲𝗹𝗹𝗼 𝗪𝗼𝗿𝗹𝗱" 𝘁𝗼 𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗠𝘆 𝗢𝘄𝗻 𝗜𝗺𝗮𝗴𝗲𝘀 🏗️ Now that I understand the "what" of Docker, I’ve been diving deep into the "how." Specifically, how to take a raw 𝗙𝗮𝘀𝘁𝗔𝗣𝗜 application and package it into a predictable, reproducible image using a 𝗗𝗼𝗰𝗸𝗲𝗿𝗳𝗶𝗹𝗲. I’m realizing that writing a Dockerfile isn’t just about making the code run; it’s about being an architect for your app's environment. 𝐇𝐞𝐫𝐞 𝐚𝐫𝐞 𝐚 𝐟𝐞𝐰 𝐭𝐡𝐢𝐧𝐠𝐬 𝐈’𝐦 𝐟𝐨𝐜𝐮𝐬𝐢𝐧𝐠 𝐨𝐧 𝐭𝐨 𝐛𝐮𝐢𝐥𝐝 𝐚 𝐬𝐨𝐥𝐢𝐝 𝐟𝐨𝐮𝐧𝐝𝐚𝐭𝐢𝐨𝐧: 📜 𝗧𝗵𝗲 "𝗥𝗲𝗰𝗶𝗽𝗲" 𝗠𝗶𝗻𝗱𝘀𝗲𝘁: I’ve been practicing how to structure instructions like 𝗙𝗥𝗢𝗠, 𝗪𝗢𝗥𝗞𝗗𝗜𝗥, and 𝗖𝗠𝗗. It’s a shift in thinking—instead of configuring my laptop, I’m documenting exactly how a server should set itself up. ⚡ 𝗟𝗮𝘆𝗲𝗿 𝗖𝗮𝗰𝗵𝗶𝗻𝗴: This was a fascinating discovery. I learned that the order of commands in a Dockerfile matters immensely. By copying my 𝘳𝘦𝘲𝘶𝘪𝘳𝘦𝘮𝘦𝘯𝘵𝘴.𝘵𝘹𝘵 before my source code, I can leverage Docker’s cache. Now, if I change a line of Python code, I don’t have to wait for every library to re-install. It’s a small optimization, but it makes the dev loop so much faster. 🧪 𝗣𝗿𝗲𝗰𝗶𝘀𝗶𝗼𝗻 𝗼𝘃𝗲𝗿 𝗦𝗽𝗲𝗲𝗱: I’m trying to avoid the "it just works" trap. I’m spending time understanding why we use 𝘴𝘭𝘪𝘮 images versus full ones and how to keep my images lightweight and secure. I’m still very much in the "trial and error" phase—my terminal has seen plenty of build errors today! But each error is teaching me something new about how containers actually breathe. 𝗡𝗲𝘅𝘁 𝗼𝗻 𝗺𝘆 𝗹𝗶𝘀𝘁: Learning how to orchestrate multiple containers to work together. For those who use Docker daily: What’s a "rookie mistake" you see in Dockerfiles that I should try to avoid early on? #LearningInPublic #Docker #BackendDevelopment #Python #CodingJourney #SoftwareEngineering #DevOps

🎁 I’ve put together a clean, beginner-friendly Docker Images & Containers Cheat Sheet + Guide — and I’m sharing it! This covers everything I wish I had when I started: ✅ Dockerfile essentials ✅ Building, tagging & optimizing images ✅ Running & managing containers ✅ Using volumes, logs, exec, and sharing code ✅ Full Django workflow example ✅ CMD vs ENTRYPOINT demystified Whether you're new to containers or brushing up, this guide is designed to be clear, practical, and production-relevant. 🐳 🧠Want the cheat sheet? I’m happy to share — and I’ll be posting more tech tips like this, so feel free to follow along! #Docker #Containers #DevOps #Python #Django #LearningInPublic #SoftwareEngineering #CheatSheet

✍ Documenting and Containerizing My First Docker Project 🐳📄 Today I didn’t just build a Docker image I also documented the entire workflow in a clean README. This project shows: A Python app running inside a Docker container Environment variables controlling runtime behavior A clear Dockerfile and .dockerignore A step-by-step README to build and run the image From: docker build -t docker-basics:1.0 . docker run --rm -e STUDENT_NAME=Alice docker-basics:1.0 To a fully reproducible setup anyone can run. This is what DevOps is about: build once, run anywhere, and document so others can follow. Learning by doing. One container at a time. 🚀 #Docker #DevOps #Python #OpenSource #LearningJourney #TechSkills

Copilot-style code suggestions are becoming a normal part of daily development. I’ve noticed more teams treating automated suggestions as a default workflow, especially for repetitive backend tasks: CRUD endpoints, SQL queries, and boilerplate around REST APIs. For me, the value isn’t “writing code for me” — it’s reducing context switching and helping me explore patterns I might not reach quickly on my own. The downside is that it can also hide weak understanding. I’ve started treating suggestions like untrusted input: read it, test it, and make sure I can explain it. How do you balance speed with staying sharp? #python #git

Giving inline coding agents “X-ray vision” for repo changes AI coding agents often run stateless, so they can’t browse GitHub history or make sense of noisy git logs. They know what changed, but not why or where. Built git-commit-tracker to solve this - a lightweight tool that analyses any commit and surfaces the commit message (intent) + impacted files (scope). AST-based parsing, works across all file types, and supports local or remote repos. Install: pip install git-commit-tracker GitHub: https://lnkd.in/gE53z8GT PyPI: https://lnkd.in/g88KPAeG #python #opensource #aiengineering #devtools #git #automation

At NetworkNuts, we had a requirement to deploy a simple Retrieval Augmented Generation (RAG) application built in Python on top of Kubernetes using a microservice architecture. It had three core components: 1. Ingestor service: to process and embed data 2. Query service: to respond to user questions 3. Qdrant ran in a separate container to store vector embeddings from its official container image from Dockerhub. This setup was functional for internal testing, but not scalable or user-ready. Here is what we changed: 1. Refactored the Python code into independent microservices using FastAPI 2. Deployed Qdrant as its own service using the official container image 3. Built a customer-facing UI using React and Node.js, served through NGINX 4. Integrated with OpenAI Embeddings API to generate vector representations 5. Connected to OpenAI’s Language Model API for response generation The result: A modular, scalable, and production-ready RAG application that is designed for reliability, easier deployments, and real customer interaction. Diagram for reference:

RUN vs CMD vs ENTRYPOINT: While working on Docker image optimization and CI/CD pipelines, I finally got real clarity on the difference between RUN, CMD, and ENTRYPOINT — something that often causes confusion (and broken containers 😅). Here’s the simple mental model that helped me: 🔹 RUN Used at build time. Installs packages, prepares the image, creates layers. Example: installing OS packages or Python dependencies. 🔹 CMD Defines the default command when a container starts. Can be easily overridden at runtime. Great for apps like Flask, Django, Node.js. 🔹 ENTRYPOINT Defines the main executable of the container. Harder to override — makes the container behave like a CLI tool. 💡 Key takeaway: "RUN builds the image, CMD runs the container, ENTRYPOINT defines its behavior." Understanding this helped me: - Fix containers exiting immediately - Optimize Dockerfiles - Design cleaner, production-ready images for CI/CD pipelines Always learning, always breaking things — and fixing them better 💪 #Docker #DevOps #Containers #CICD #LearningByDoing #CloudEngineering