Devteds

I Replaced My Entire Dev Workflow with Claude Code. Here's What Actually Works.

contact@devteds.com (Chandra Shettigar) — Sat, 28 Mar 2026 00:00:00 GMT

Two months ago I switched from Cursor to Claude Code. Fully. Not “trying it on the side” but “this is how I code now.”

I’d been using Cursor for a while and it was fine. Good autocomplete, decent chat. But Claude Code changed how I think about the work itself, not just how I type it. The difference isn’t speed. It’s that I stopped thinking about writing code and started thinking about describing what I want built.

I use it across everything. At my day job, I use Claude (enterprise) on a large codebase that spans APIs, a React frontend, and a CMS across multiple product layers. On the side, I use it for the Devteds website (Astro + Tailwind), Wistale (an AI storybook product), Node.js services, and a Rails app with a Docker setup that’s genuinely painful on Mac when you’re juggling multiple worktrees and parallel containers. The range matters. What I’ve learned working on a large production codebase at work directly informs how I use Claude on smaller projects, and vice versa.

CLAUDE.md is the real product

If you’re using Claude Code without a CLAUDE.md file, you’re using maybe 30% of it.

CLAUDE.md is a markdown file at the root of your project. It gives Claude persistent context: your stack, your conventions, your file structure, where things live. It loads into every conversation automatically.

Writing it felt more like product design than configuration. I was defining how an AI agent should think about my project. What matters. What doesn’t. What the rules are.

For the Devteds site, mine includes the stack (Astro, Tailwind v4, TypeScript strict), URL conventions, where content and images live, the old Jekyll project path for migration reference, brand color, hosting details. Under 50 lines. Shorter is better. Every vague instruction dilutes the specific ones.

For my Rails project, the CLAUDE.md is different. It describes the Docker Compose setup, which containers talk to which, how to run migrations, which worktree maps to which branch. That project has a lot of moving parts and Claude needs to know the topology before it touches anything.

Skills: where it gets genuinely useful

A skill is a markdown file in .claude/skills/ that gives Claude a playbook for a specific task. You invoke it like a slash command. No SDK, no API, no build step. Just a folder with a SKILL.md and optionally some reference files. That’s the entire abstraction.

The first skills I built were for content (generating blog ideas, drafting posts). Those were useful. But the skills that actually changed how I work are the ones that wrap the development process itself.

/start-task is what I run at the beginning of every session. It checks the current code state, fetches latest from the repo, reads the roadmap, reviews recent commits, checks what’s deployed, and suggests what to work on next. It’s like a standup meeting with your codebase. Before this, I’d spend the first 10 minutes of every session figuring out where I left off. Now I just type /start-task and get a summary with clear next steps.

/wrap-up handles end-of-session bookkeeping. It updates the roadmap with what got done, stages and commits the right files, pushes to the remote, and optionally creates and merges a PR. All the stuff I used to forget or skip when I was tired at the end of a session. The roadmap used to get stale within a week. Now it stays current because closing the loop is one command.

/seo-review runs a Lighthouse audit, analyzes the scores, identifies specific fixes with priorities, and adds tasks to the roadmap. Instead of me squinting at Lighthouse reports and manually tracking what needs fixing, Claude reads the numbers and turns them into actionable work items. This one paid for itself immediately on the Devteds rebuild when we needed to hit 95+ across all categories.

/new-idea is for when I’m thinking about a product idea and want to pressure-test it quickly. It researches the competitive landscape, assesses technical feasibility, estimates MVP scope, and gives a verdict (worth exploring, park it, or pass). If it’s worth exploring, it adds a section to the roadmap. I built this because I was losing ideas in random notes. Now they either make it into the roadmap with context or get explicitly passed on.

I’ve built similar skills for Wistale and it’s been very efficient. The pattern is the same across projects: codify the process you already follow, but make it consistent and automatic. Good practices that you’d skip when you’re rushing now happen every time because the skill enforces them.

How these skills connect into a workflow

The real value isn’t any single skill. It’s that they chain together into a rhythm:

Start a session with /start-task. Know exactly where you are and what’s next.
Do the work. Claude handles the code, you handle the decisions.
If a new idea comes up mid-session, run /new-idea to capture and assess it without losing context.
Periodically run /seo-review to catch regressions.
End the session with /wrap-up. Roadmap updated, code pushed, nothing forgotten.

This loop keeps the project healthy. The roadmap is always current. Commits are clean. Performance doesn’t silently degrade. Ideas don’t get lost in a notes app somewhere.

Before skills, all of this was manual discipline. And manual discipline fails when you’re tired, or rushing, or juggling three projects.

What actually changed across projects

The Devteds rebuild was the most dramatic example. I migrated 12 Jekyll blog posts by pointing Claude at the old project directory and describing the new frontmatter schema. Ten minutes of my time, mostly reviewing output. Product pages for Wistale were describe-and-iterate. Lighthouse optimization went from a manual chore to a conversation.

But the Rails project is where Claude Code proved itself differently. That codebase has Docker containers for the app, the database, Redis, background workers. Running parallel worktrees means parallel sets of containers. On a Mac, that’s a mess. Claude handles the Docker Compose juggling, knows which port maps where, and doesn’t get confused when I switch branches. Before this, I kept a cheat sheet. Now Claude is the cheat sheet.

The Node.js projects are simpler but still benefit. Scaffolding, test setup, dependency management. The kind of work that’s not hard but eats time.

Where Claude Code falls apart

I want to be honest about the failure modes.

Visual design is still a human job. Claude can implement a design you describe, but it can’t originate one that feels polished. Every first version looked like a template. I pushed hard on spacing, typography, and visual hierarchy. Even then, I was making most of the aesthetic decisions.

Complex multi-step refactors get messy. When I asked Claude to restructure the entire layout system across multiple components simultaneously, it lost track of dependencies. Smaller, focused tasks worked much better.

It doesn’t know when to stop. Ask Claude to “improve” something and it’ll add error handling, type annotations, comments, and abstractions you didn’t ask for. I learned to be specific: “change X to Y” not “make this better.”

Context drift in long sessions. After 30+ exchanges, Claude starts losing track of earlier decisions. I start fresh sessions with /clear for each distinct task. CLAUDE.md carries the persistent context.

Why I switched from Cursor

Cursor is a good tool. The autocomplete is fast, the inline chat works well for small edits. I still open it occasionally for quick stuff, though that’s happening less and less.

But Claude Code operates at a different level. Cursor helps you write code faster. Claude Code helps you think about code differently. The terminal-first approach felt weird at first, then liberating. I describe what I want, Claude reads the project context, makes the changes across files, and I review the diff.

The skills system is what sealed it. There’s nothing like it in Cursor. Being able to type /start-task and get a full project status with recommendations, or /wrap-up and have all the session cleanup handled, that’s not autocomplete. That’s a development process.

The patterns that stuck

After two months across multiple projects:

Keep CLAUDE.md ruthlessly short. Project-level rules only. Task-specific stuff goes in skills.

One task per conversation. Don’t ask Claude to migrate blog posts AND redesign the footer in the same session.

Review every diff. The moment you stop reviewing is the moment Claude introduces a subtle bug or an unwanted “improvement.”

Build skills for your process, not just your code. The most valuable skills I’ve written don’t generate code at all. They manage the workflow around the code. Start-of-session, end-of-session, audits, idea capture.

Each project teaches you something new. The CLAUDE.md that works for a static site doesn’t work for a Rails monolith. The skills that help with one project’s workflow don’t map directly to another. You learn what Claude needs to know by watching where it gets confused.

What this actually means for solo developers

I don’t think Claude Code replaces developers. But it changes what “development” means day to day.

I spent more time this month on product decisions, content strategy, and design direction than on actual code. The code itself (Astro components, Tailwind styling, Docker configs, content migration) was mostly handled by Claude with my review.

For a solo developer running a product studio, that’s a real shift. I’m not faster at coding. I’m spending less time on code and more time on the things that actually differentiate the product.

The biggest surprise wasn’t the code generation. It was that skills turned my ad-hoc habits into a reliable process. I used to forget to update the roadmap. I used to let Lighthouse scores drift. I used to lose track of where I left off between sessions. Now there’s a command for each of those things, and it works the same way every time.

If you want to try it, start small. Add a CLAUDE.md to one project. Use Claude Code for one real task. Then write one skill for something you do repeatedly. See if it earns your trust.

That’s how it started for me. Two months later, I can’t imagine going back.

Multi-Container Local Development Setup using DevContainers in VSCode

contact@devteds.com (Chandra Shettigar) — Mon, 13 May 2024 00:00:00 GMT

As an application or web developer, it’s crucial to have an isolated yet seamless local development setup, especially when managing multiple applications or codebases across various microservice apps built on different programming languages, versions, or frameworks.

If you’ve used Docker for local development, you might be familiar with Docker Compose for handling multiple container setups. While this is helpful in many ways, it requires an extra step of entering a running container to execute ad hoc commands.

For instance, if you’re a Rails developer, you often need to run commands like rails generators, db migrations, rails runner, and especially the rails console. Similar challenges exist for most frameworks.

Imagine if you could open your editor in a container mode that loads the application environment and allow us to run application commands in the embedded terminal, without needing to run commands like docker run, docker exec, etc. This would make working within a containerized environment much easier.

One option that has worked well for my local development setup is the Dev Containers extension in VSCode. Not only does it allow you to load the application in VSCode within a container context, but you can also run dependency services (or other tiers of the application stack) as containers. The Dev Containers extension integrates smoothly with Docker Compose.

In this short tutorial, I’ll guide you through setting up a local development environment for an application that uses a database, both running as containers using Docker Compose and Dev Containers in VSCode. Here’s a quick breakdown of the steps you’ll learn in the tutorial:

Start by creating a Dev Container setup for your application
Create a web application using the Dev Container
Configure a multi-container setup with Dev Container for the application and database containers
Test and verify, mainly database container, using Docker Desktop
Link the application running as a container with the database running as another container
Conclude with a note on Multi-Stage Docker Build with DevContainer & Docker Compose

Setting up a reliable local environment can significantly enhance productivity for app developers. I hope this short video tutorial proves helpful!

VPC Basics for Kubernetes on Amazon EKS

contact@devteds.com (Chandra Shettigar) — Tue, 05 Mar 2024 00:00:00 GMT

As Kubernetes gains traction in the tech world, many companies leveraging AWS infrastructure are delving into Amazon EKS (Elastic Kubernetes Service) either to dip their toes or to dive in deep. Whether you’re diving headfirst into EKS, AWS’s managed Kubernetes cluster, or crafting your own Kubernetes setup on AWS, understanding the VPC and the networking requirements is essential.

For DevOps engineers and application developers, networking setups might not be your main focus, but understanding the basics can be incredibly helpful. In this article, I’ll give you a simple overview of AWS VPC and using it for Kubernetes on EKS. This won’t cover all the technical details, but it’s a friendly guide for anyone starting out with EKS or Kubernetes on AWS

VPC: Understanding the Basics

VPC, or Virtual Private Cloud, is a fundamental component of AWS that enables users to create a private section of cloud space within the larger public cloud environment. This private section is isolated from other users in the cloud and provides controls to manage access to and from the internet.

With VPC, users are allocated a specific range of IP addresses, allowing them to host a predetermined number of resources or compute instances (such as EC2 instances, Load Balancers etc.) within the confines of their VPC.

Moreover, VPC facilitates the creation of subnets, which are used to group resources and control access. Subnets enable users to designate which groups of resources can be publicly accessible via public IP addresses, which should be strictly internal with internet connectivity but no incoming connections (private subnets), and which are solely for internal communication (intra subnets). Users have the flexibility to create multiple subnets to suit their needs.

Additionally, VPC allows users to define auto-failover setups at both the VPC and subnet levels by distributing resources across two or more Availability Zones (AZs). In AWS, an AZ represents a distinct physical location within a region, and each AWS region typically consists of two or more AZs. For instance, if you choose “North Virginia” as the AWS region for your VPC, you would configure your setup to span at least two AZs within that region.

Kubernetes and Amazon EKS

Kubernetes, commonly known as K8S, is an open-source container orchestration platform that automates the deployment, scaling, and management of containerized applications. It provides a rich set of features for managing containerized workloads, including automated rollouts, self-healing, and scaling based on resource usage.

In Kubernetes infrastructure, two critical components play pivotal roles: the control plane and the worker nodes. The control plane serves as the brain of the Kubernetes cluster, orchestrating and coordinating various tasks. Conversely, the worker nodes constitute the deployment environment for containerized applications. Managing the control plane is often a complex undertaking in Kubernetes deployments, requiring meticulous attention to detail. This is where Amazon EKS steps in to alleviate the burden, particularly for users operating within the AWS ecosystem.

Amazon EKS, also known as Elastic Kubernetes Service, is AWS’s managed solution for Kubernetes. It simplifies the deployment, management, and scaling of Kubernetes clusters on AWS. With EKS, users can focus on developing and innovating their applications without worrying about managing the complexities of Kubernetes clusters, mainly the Control Plane part. Additionally, EKS seamlessly integrates with various AWS services like Load Balancers, IAM, and CloudWatch, making it easier to manage security, monitor performance, and distribute traffic efficiently.

VPC for Kubernetes on Amazon EKS

When configuring a VPC for a Kubernetes cluster on Amazon EKS, it’s beneficial to establish three types of subnets, each serving distinct purposes: Private Subnets, Public Subnets and Intra Subnets.

Private Subnets

Private subnets primarily host the worker nodes or the compute instances running the actual application containers. Even applications requiring external access for end-users or customers typically operate within private subnets. In most scenarios, applications need to communicate beyond the VPC boundaries, whether for downloading resources or sending HTTP requests. Therefore, making private subnets the primary environment for worker nodes is often preferred. While exceptions may exist, this setup generally ensures smooth operation.

Public Subnets

Public subnets accommodate resources that necessitate internet access, enabling users from the internet to interact with them. For instance, a website accessible via a web browser typically resides in a public subnet. In the Kubernetes context, containers rarely serve as direct public-facing web servers. Instead, public-facing applications are typically served through Reverse Proxies and Load Balancers. These Load Balancers can be deployed in public subnets.

Utilizing AWS Load Balancer service in Kubernetes via Kubernetes Ingress Controller seamlessly integrates with Amazon EKS. Placing Load Balancers in public subnets enables end-users to access the externally facing Load Balancer’s IP or hostname. The Load Balancer then proxies requests to the target container applications running within the worker node space in private subnets.

Intra Subnets

The control plane, the heart of the Kubernetes cluster, is ideally housed within intra subnets. From a security standpoint and best practices perspective, restricting internet access to intra subnets is advisable. This setup ensures that the control plane remains isolated and secure, minimizing potential vulnerabilities.

Conclusion

To wrap up, if AWS is your go-to cloud provider and you’re considering Kubernetes, EKS is a solid choice to kickstart your journey. While there are pros and cons to using EKS versus managing your Kubernetes cluster, EKS typically offers a hassle-free experience. In this brief article, I’ve provided a high-level overview of VPC requirements for Kubernetes. For those eager to dive deeper, I recommend delving into VPC intricacies and exploring EKS further.

DevOps Local Setup: Docker & Dev-Containers in VSCode

contact@devteds.com (Chandra Shettigar) — Wed, 15 Nov 2023 00:00:00 GMT

As an app developer or a DevOps, Platform, or Cloud Engineer, having a smooth and reliable local setup makes a huge difference in productivity gain. If you’ve ever wondered about improving your workstation setup for devops or cloud projects, this short video tutorial will definitely help you.

Imagine you’re working on a project that requires a few different CLI tools for managing applications & deployment environments and the cloud infrastructure such as AWS and Kubernetes. That’ll require you to set up your local environment with all the necessary tools and CLIs.

There are a couple of ways to go about it. One approach is to individually install all these tools on your machine, whether it’s a Mac, Windows, or Linux. The catch is that your teammates will likely do the same and there is a good chance that it may lead to variations in tool versions and operating systems and that’ll make workstation setups across the team inconsistent.

Alternatively, you can consider using Docker Containers. In this scenario, you create a Docker image containing all the necessary tools and have your entire team adopt the same Docker image. However, it’s easier said than done, as maintaining a uniform container environment setup can become quite challenging.

In this short tutorial, I will walk you through setting up local environment for devs in the DevOps, Platform or Cloud Engineering space. Here’s a quick breakdown of the steps you’ll learn in the tutorial:

Configuring the Dev Containers extension for our project
Installing tools such as AWS CLI and CDK using Dev Containers features
Installing additional CLI tools such as Terraform and Kubectl by editing Dockerfile
Using Docker Volume mount for managing keys such as AWS Auth Credentials
Testing AWS CLI from inside the Dev Container
Test running Terraform code against AWS S3 from inside the Dev Container

Setting up a reliable local environment can significantly enhance productivity for app developers, DevOps, Platform, and Cloud Engineers. I trust this short video tutorial proves helpful!

The Flipside of Microservices: Knowing When to Embrace or Pass

contact@devteds.com (Chandra Shettigar) — Wed, 23 Aug 2023 00:00:00 GMT

Many teams explore the idea of breaking their applications into smaller services. This brings up a question: are they doing this to create a complete Microservices system, or just trying out the idea of making smaller apps to make them easier to handle? But going into the world of Microservices can be complicated and tricky, needing careful planning and a lot of effort to set up the necessary tools and structure to make it work well.

However, at the heart of “Microservices” is a really interesting idea — it’s a way to create apps that can grow and adapt easily, especially when it comes to handling more users. But there’s still a puzzle to solve: are these Microservices good for everyone? suitable for all situations? And as time goes on, what problems might come up when it’s about keeping everything working smoothly?

Breaking Things Down

Microservices break down apps into smaller, specialized parts. This is great because you can work on one part without messing up the whole project. It speeds up development and lets teams work independently on different parts, which is awesome for scaling things up.

But, here’s the thing: Microservices mean lots of separate projects. That means separate repos, setups, and rules to manage. If you’ve got a bunch of these Microservices, it’s like trying to remember which remote controls belong to which gadgets. Keeping everything updated and in line can turn into a puzzle that’s not always fun to solve.

Real challenge is “how granualar should teams or companies go in breaking down the larger application or system?”. When a team that is responsible for a decent size application decides to break it down into many smaller size apps (with the idea of Microservices), that will soon become challenging for the long run.

Puzzle of Micro-Frontends

Picture this: you take the idea of “Microservices” and apply it to how the front part of a website works — the micro-frontends. Sounds cool, right? It offers flexibility and lets you reuse things.

Now, imagine this: instead of having just one big piece, you break it down into lots of tiny pieces. Each of these pieces has its own place to stay (code repository), its own way of being built (language, framework, version, etc.), and its own path to get out into the world (deployment). The process of working on them locally, testing them, and getting them ready to show to the world? It’s like getting caught in a web of complexity. And here’s the twist — it can become pretty tricky for the developers to keep up with all these small front-end pieces.

It’s like trying to keep track of a whole bunch of puzzle pieces, each with its own unique shape and place.

Tackling the Puzzle of Updates & Upgrades

Imagine being in a situation where you’re tasked with updating a foundational library that’s spread across multiple microservices. This whole affair is often triggered by the stringent demands of InfoSec or Security & Compliance standards. You’re looking at upgrades for Node or Ruby, possibly a shift in Rails, and don’t forget those client library upgrades to keep up with the shifting sands of services like RDS/MySQL/PostgreSQL, message brokers, and versions of other application dependencies.

But here’s the kicker: what looks like a simple update job can quickly turn into a complex process of testing and checking. Each of those microservices has its own set of needs and things it depends on. And this is where things get tricky — making sure that all these pieces fit together without causing chaos.

And let’s not even start talking about the sheer number of tasks that suddenly pile up on your to-do list. It’s not just one or two tasks — you’re looking at a bunch of them, all waiting to be taken care of. Now, the team that’s already familiar with these new microservices might handle it fine, but for those who are new, it can be a lot to handle. The flood of tasks, the growing list of releases, the planning, the constant testing — it can get pretty overwhelming.

It would be great if there is great deal of automation for testing, releases (CI/CD) and a great source code branching strategy, etc. but let’s be real — as nice as that sounds, turning this into reality isn’t all that easy.

Transition Troubles

Imagine this: organizations have to think about moving their code homes from one place to another. Why? Well, maybe to save money or to have better ways (features) of working together.

Now, hold on tight, because here comes the real head-scratcher. Moving a big bunch of code is already kind of complicated, right? But what if you’re not just moving one thing — you’re moving lots of smaller things, like these microservices? That’s like adding an extra layer of confusion. Going from one platform to another, or trying to put all your code in one place, is like trying to solve a really tough puzzle. And you can’t afford to lose any of the puzzle pieces. It takes super careful planning and making sure everything happens just right.

The Crucial Role of Appropriate Tools and Setup

Imagine this: someone using your app says something isn’t working right. Now, where do you start looking to fix it? Is it in a main part of the app, or could it be in a separate part that does its thing later? Figuring out what went wrong in the whole process can be like solving a puzzle. Finding the real reason might take some time. It might not seem like a big deal at first, but it could become a bigger problem later. It all depends on how many parts your app has, how they talk to each other, how well you’re keeping track of things, and how easily you can see what’s happening.

But here’s the bottom line: if you don’t have the right tools and setup to manage all these parts of your app, then going for the microservices way might not be a good idea. It’s like trying to go on a big trip without the things you need for the journey. It can make things much harder than they should be, and you might not get the good results you were hoping for.

Striking the Balance

Here’s the deal: Microservices and micro-frontends aren’t magical solutions. Yes, they bring some powerful tricks, but they also bring some complications. Finding the right balance between being organized and being able to handle things is super important. You don’t want too many of these small services, or it might end up causing more problems than it solves.

Picking the Right Way to Build

When you’re thinking about how to put together your project, you’ve got to think it through. Here are some extra tips for making the right choice, especially for teams that are in charge of one or a few parts of a big company system:

Size and Complication: Think about how big and complex your application is. If it’s not too huge, you might just need to keep it the way it is. Or maybe split it into 2 or 3 pieces. But don’t go wild. For big and complicated things, microservices work better.
Teams Doing Their Thing: If you’ve got different teams working on different parts, and they all want their space, microservices could be the way. But if your teams can cooperate without messing things up, keeping it all in one piece might be smoother.
Growing When Needed: If you’re planning for some parts of your app to grow a lot, extracting that as a separate service makes sense. But if growing isn’t a big deal and it doesn’t really add value to business, keeping everything together can be easier.
What You Know and Have: Think about what your team knows. Microservices ask for more knowledge about tricky things like distributed systems and how stuff is put together. Check if your team can handle it.
How Your Team Works: Take a look at how your team is set up and talks to each other. If your team is spread out and chatty, microservices could fit in. But if things are more centered, keeping it all as one might work better.
Right tooling and Infrastructure: Does your company have the right tooling (for build, deployments, code scanning, log analysis, transaction tracing, etc.)? If not, solve for that before attempting to break the app down into smaller sizes.

More Pointers

If there’s a real, real need for breaking a big application into small pieces, think about just doing it a bit — like 2 or 3 pieces, not going all-in for Microservices.
Microservices are something that needs a whole-company or org effort, not just a bunch of teams doing their own thing. You’ve got to think about finding problems, checking logs, and looking at how everything’s working together when stuff goes wrong, mainly in production
To take an example - when a team of 5 folks decides to break a big app into 20 tiny apps, guess what? You’ll need more folks to look after those 20 apps now.
If your team is responsible for one of the apps that is part of a larger enterprise level system, there is definitely need for interservice communications between your app and some of the related apps or components within that system. You may call it Microservices or simply Service Oriented Architecture. Communication can happen via REST or SOAP API calls, GraphQL or Message Brokers, etc. But within your app, need for breaking down the app to smaller size ones, is where you give enough thoughts.
Here’s food for thought: delve into the “majestic monolith” concept. Check out this link: The Majestic Monolith. This method shines for apps raking in revenue with bustling user bases, like Basecamp.

Create React.js App using Docker

contact@devteds.com (Chandra Shettigar) — Thu, 29 Jun 2023 00:00:00 GMT

While Docker may not have gained significant popularity in front-end development, I believe it can greatly benefit engineering teams, including front-end heavy devs. In my personal experience, front-end developers working with React.js or Angular tend to avoid using Docker.

In the past year, I have actively assisted developers in adopting Docker for their local front-end development environments. This has been particularly helpful in teams where developers are expected to work with multiple front-end apps, frameworks and node versions, etc. Docker’s ability to isolate development setups has made front-end app development smoother and more efficient.

By dockerizing the development environment, another notable advantage is the reduction in the necessity for specific node and build tool installations within the CI (Continuous Integration) environment. While the end result of the build process typically consists of front-end assets like JS bundles, CSS, images, and HTML files, which are ultimately shipped or pushed to a web server like Nginx or hosted on S3, it is important to note that the build pipeline still heavily relies on build tools. However, by dockerizing this process, the development environment is significantly simplified, alleviating the burden of manual tool installation and configuration. This streamlined approach ensures a more efficient and hassle-free build pipeline.

In this article, we will delve into the process of leveraging Docker to create a new ReactJS app.

Create React App

To begin, navigate to your projects directory by executing the following command:

# Navigate to your projects directory
cd ~/my-projects

Next, create a Dockerfile with the following content. This file will serve as the blueprint for building an image to be used as the builder image for creating the React app:

FROM node:20

RUN apt-get update

RUN npm install -g npm@9.7.2 && \
    npm install -g create-react-app

Once the Dockerfile is created, it’s time to build the builder image using the following command:

docker build -t react-app-builder .

To create a React app using the builder image built above, run the following command:

docker run  -it --rm \
            -v "$PWD":/app:rw \
            -w /app  \
            react-app-builder \
            npx create-react-app my-react-app --template=typescript

This command executes a Docker container based on the builder image (react-app-builder) with the necessary configurations. It mounts the current directory ($PWD) as a volume inside the container, sets the working directory to /app, and runs the command npx create-react-app my-react-app --template=typescript.

During this process, you may encounter an error related to initializing git which may not be an issue. The remaining directory structure of the React app will be created successfully.

The command npx create-react-app my-react-app --template=typescript will create a new React app and directory under /app/my-react-app. Since the /app directory is mapped to the host directory ~/my-projects, the resulting app directory will be located at ~/my-projects/my-react-app.

Creating the React app using Docker without the need for Node installation made the process straightforward. This approach can be applied to create apps with other frameworks too, like Angular, Vue.js, Ruby on Rails, and more. Docker provides a versatile solution that eliminates the requirement for specific tools on your local machine, making app creation hassle-free and applicable across various frameworks.

cd my-react-app

Now that we have completed the initial setup, we can proceed to create a Dockerfile specifically for the app. Follow these steps:

Delete the builder ~/my-projects/Dockerfile as it is no longer needed.
Create a new Dockerfile for the app at my-react-app/Dockerfile with the following content:

# Development stage
FROM node:20 as dev
RUN mkdir /app
WORKDIR /app
COPY package*.json ./app
RUN npm install
CMD ["npm", "start"]

# Build stage
FROM node:20 as build
RUN mkdir /app
WORKDIR /app
COPY package*.json ./app
RUN npm install
COPY . .
RUN npm build

# Production stage
FROM nginx:alpine as prod
COPY --from=build /app/build /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Here’s a quick overview of this Dockerfile:

It utilizes Docker’s multi-stage build approach, which allows us to differentiate the tooling and requirements for different stages: local development, build pipeline, and the final artifact deployment.
The development stage (dev) is intended for local development and sets up the necessary environment for running the app.
The build stage (build) is an intermediate stage that prepares the final artifact for deployment.
The production stage (prod) creates an Nginx image with the built React app. This image is used to run the React app as a container within any of the app’s environments.
You can refer to this article that explains the need and use of Multi-Stage Docker Builds: Multi-Stage Docker Build Tutorial

Build and Run Locally

Let’s build the app image locally and run it

Navigate to the my-react-app directory:

cd my-react-app

Build the app image targeting the dev stage in the Dockerfile:

cd my-react-app
docker build -t my-react-app-dev --target dev .

This command builds an image named my-react-app-dev specifically for the development stage.

Run the React app as a container:

docker run --rm -it -p 3000:3000 -v $PWD:/app my-react-app-dev

This command executes the app container and runs the command npm start as specified in the Dockerfile under the dev stage. The React app will be accessible at http://localhost:3000 in your browser. Note that the port 3000 inside the container is mapped to port 3000 on the host machine.

Additionally, the volume mount (-v $PWD:/app) ensures that the app code is mounted from the host to the container’s working directory. This allows you to make code changes on the host machine, and the changes will be reflected inside the running container.

You can now make code changes to your React app directly on the host machine, and the changes will be automatically reflected in the running container.

To build the Docker image for production and publish it to a Docker registry as part of your CI/CD pipeline:

docker build -t MYPRIAVTE_REGISTRY/my-react-app-deployable:v1.1 --target prod .

This command builds an image named MYPRIAVTE_REGISTRY/my-react-app-deployable:v1.1 specifically for the production stage. Replace MYPRIAVTE_REGISTRY with your private registry URL.

docker push MYPRIAVTE_REGISTRY/my-react-app-deployable:v1.1

This command pushes the image to the specified Docker registry. Replace MYPRIAVTE_REGISTRY with your private registry URL.

In local development, you also have the option to use docker-compose instead of the plain docker command, which can simplify the setup. Here’s an example docker-compose.yml file that should be placed at the root of the React app code directory, alongside the Dockerfile:

version: "3.8"

services:

  app:
    build:
      context: .
    ports:
      - "3000:3000"
    volumes:
      - .:/app

By using this docker-compose.yml file, you can run the React app locally with a single command: docker-compose up. The app will be accessible at http://localhost:3000 as before.

Summary

In this blog post, we explored how Docker can be used to create a React app and demonstrated the use of Multi-Stage Docker Build to separate the local development and build/deployment stages. The instructions provided in the Dockerfile can be customized to suit your specific needs, such as using different versions of npm or yarn, building more than just assets, and more.

To further expand your knowledge of Docker, I encourage you to try Dockerizing the application you’re currently working on or creating a new one using Docker. The following articles can help you get started with Docker in your local development environment:

A Beginner's Guide to Docker: Understanding the Basics

contact@devteds.com (Chandra Shettigar) — Sat, 01 Apr 2023 00:00:00 GMT

My goal is to make Docker basics easy to understand for beginners. If you’re new to Docker or not sure where to begin, start by using Docker to containerize your application in a development environment. Keep reading to learn more.

What is Docker?

“Docker is a tool that simplifies the process of creating, deploying, and running applications using isolated environments called containers”.

If you haven’t used Docker before, this may not make much sense now. If you’ve used Vagrant with any of the virtualization tools such as VirtualBox or VMWare, you can relate to this to an extent.

Let’s avoid comparing Docker to virtual machines and instead look at an example to understand the usefulness of Docker.

Say I’m building an API app using Node 19, Yarn for packaging, and I want it to run on a secure Linux OS (Alpine Linux). The thing is, I’m on a Mac with an older version of Node & Yarn installed, and I don’t want the new setup conflict with the currenly installed node or yarn. Plus, I need to make sure that the app runs on the same versions of OS, system libs, and Node no matter where it’s deployed - from my local machine to production. Also, in the staging & production environments, I should be able to run the application on shared servers without having to install any tools (OS, libs and runtime) specific this new application.

With Docker one can achieve this easily. To get started with Docker for our app, we first write a Dockerfile.

Dockerfile

Dockerfile contains a bunch of instructions, commands, and settings to package the app and create Docker Image. The image built will include everything you need to run your app, like the OS/libraries, runtime, application build files, and dependencies such as node packages, ruby gems, etc. Check out the example below for a Node Application.

# Base image from DockerHub (node image with alpine linux)
FROM node:19-alpine

# Directory inside the container to be used as workdirectory '/app'
WORKDIR /app

# Copy the package.json and yarn.lock files to the image
COPY package*.json yarn.lock ./

# Install any dependencies
RUN yarn install

# Copy the app code to image, under current work directory (. is /app)
COPY . .

# Start-up command: "yarn start".
CMD ["yarn", "start"]

This Dockerfile will be copied to the root directory of the application’s source code. And this file will be used to build a Docker Image for the application. Let’s take a brief look at the contents of the Dockerfile.

The first line FROM node:19-alpine sets the foundation in which node:19-alpine is a Docker Image from the DockerHub and it comes with all the OS, libs, runtime/nodejs and yarn installed. While there are many variants of Node image on DockerHub, we picked the one built on Alpine Linux OS.
Whether the app is run on local machine, physical server in prod or an isolated environment as container, we need a work directory. The line WORKDIR /app indicates that /app will be the work directory when the app is run as container using image built using this Dockerfile.
The line COPY package*.json ./ is to copy the package.json and lock file to the image so that we can run the command yarn install to install all the package dependencies. The next line RUN yarn install does that. These two instructions, COPY & RUN, are the build time instructions.
The line COPY . . is another build time instruction that copies all the files & directories from the current directory (application’s source code) to the current directory (same as the work directory) inside the image/container. Optionally, there may be command RUN yarn build.
The last line, CMD ["yarn", "start"] is for the runtime. When a container is started using the final Docker Image, yarn start will be run as boot up command.

Before starting to build Docker Image for the app, let’s quickly get an idea of Docker Engine and Docker CLI.

Docker Engine and CLI

Docker Engine is essentially a background process/service that can perform two primary actions:

Build a Docker Image, commonly referred to as Container Image, using the Dockerfile
Run containers using the Docker Images or Container Images

The Docker Client or Docker CLI interacts with Docker Engine to perform various tasks. Tasks such as building docker image, running container by providing an image, listing available docker images, listing actively running containers, stop/restart containers, etc.

Docker Engine can run on various machines, including local development machines, laptops, and virtual or physical application servers. It is compatible with several operating systems, such as Windows, macOS, and various Linux distributions. The machine or OS on which Docker Engine runs is commonly referred to as the Docker Host.

Build Application Image

To build a Docker Image, for your application, you use the following CLI command:

docker build -t myapp .

In the example above for a Node application, make sure to place the Dockerfile under the code directory, cd into the directory and run the command docker build ... command
The Docker CLI communicates with Docker Engine to build a docker image the application. The build command requires two inputs: (1) the image name (mostly referred to as the Image Tag) and (2) the directory where the Dockerfile is located. In this case, Image Tag is myapp and the current directory is used as the location of the Dockerfile

When running docker commands locally, the docker CLI communicates with Docker Engine through a Unix socket. However, the Docker Engine can also listen on a TCP port. This means that the Docker Engine can be located on a different machine than the one where the docker CLI command is executed.

Run Containers

Once we build a Docker Image using the docker build ... command, we can run a container using that image by executing the following CLI command:

# docker run <options> <docker-image> <optional-Start-up-command>
docker run --rm -it myapp yarn start

This command directs Docker Engine to:

Use the myapp image that we just built
Create a new container and in that container run yarn start command

If a startup command is already defined in the Dockerfile, it’s optional to specify it when running the container. In the above example, we included yarn start as the startup command in the Dockerfile, so we don’t need to specify it again when running the container with the command docker run --rm -it myapp.

After starting the container and the service with yarn start, it may not be accessible yet because the environment is isolated to the container. For instance, if the service is listening on port 3000 inside the container, the host machine where Docker is running doesn’t have access to that port by default. However, we can map the container port to a port on the host machine using the -p flag in the Docker run command.

For example, to map port 3000 in the container to port 3001 on the Docker host, we can use the following command:

docker run --rm -it -p 3001:3000 myapp

This command maps port 3001 on the host machine to port 3000 in the container, allowing us to access the service at http://localhost:3001 on the host machine’s browser.

Containers can be run using pre-built images, whether they are for the application or other software. These images can come from a local machine or a remote registry, with DockerHub being one of the most popular. In fact, many of the base images we use, like the node:19-alpine image in our example, are downloaded from DockerHub. Other popular remote registries include Gitlab Registry, Github Artifactory, AWS ECR, and more.

Docker Images vs Docker Containers

By now, you should have a grasp of the fundamental concepts of Dockerfile, Docker Engine, and Docker CLI, as well as how to build an image and run a container.

To summarize, Docker Images act as blueprints for containers, containing the code/files/builds, dependencies, runtime, system tools, libraries, and settings. Docker Containers (or containers in general) are dynamic, running instances of those images, providing an isolated and self-contained environment that runs the application and its dependencies.

Summary

Here is a longer answer of what docker is and I think it will make sense now.

Docker can be used by developers to run and package applications (web apps, APIs, background workers, etc) built using any programming language/framework such as Ruby & Ruby on Rails, Java & SpringBoot, and Node & Express, among others.
Docker allows developers to choose an OS foundation for the container, such as Ubuntu, Alpine, etc.
With Docker containers, applications can be built and run consistently across different systems, reducing compatibility issues.
When an application is built with Docker, a container image is also created. The container image built will have everything it needs to run the application, simplifying the deployment process.
The container image can then be provided to the Docker Engine to run the application locally, streamlining the development and deployment process.

I hope that helps get an idea of how Docker helps in the development and to an extent of deployments. But to realize the actual benefits, one should put this into practice and start using Docker, at least in the local development setup.

To learn more about Docker, try Dockerizing the application you’re working on or creating a new one using Docker. Here are some articles to help you get started with Docker in your local development environment.

Building Production-Ready Docker Images With Multi-Stage Builds

contact@devteds.com (Chandra Shettigar) — Wed, 11 Jan 2023 00:00:00 GMT

If you’re creating a container image (Docker image) for production, image size and security are two essential considerations. Fortunately, Docker’s Multi-Stage builds can help address both concerns.

In the development environment, container images often include development and build tools, as well as dependencies necessary for the development and build process. However, these tools and dependencies can increase the image size and pose a security risk.

By using Docker’s Multi-Stage Build feature, we can separate the development and build stage from the final production stage of creating container images. This way, the image built for production or deployment to any environment, will only contain the necessary components for the app to run in production.

In this short video tutorial, you’ll learn how to write a multi-stage Dockerfile to create both a local development and a production-ready, deployable Docker image.

Here’s a breakdown of the steps you’ll learn in the tutorial:

Containerize an existing web application using Ruby and Ruby on Rails
Start with a simple Dockerfile to build for local development and test running containers locally
Update the Dockerfile to add a multi-stage structure, starting with 2 stages for local development setup
Test running the container locally, built using a multi-stage Dockerfile
Add more stages to package and build a final, production-ready and deployable Docker image
Test running the production-ready image locally using Docker Compose

Create Ruby On Rails Application Using Docker

contact@devteds.com (Chandra Shettigar) — Thu, 30 Jun 2022 00:00:00 GMT

Thinking of creating a new Ruby on Rails application and possibly run it as container on Kubernetes, Amazon ECS, etc? If so, do your requirements align with the following:

I want to create a new Ruby on Rails application and build it using the latest stable Ruby and Ruby on Rails
I currently have an older version of Ruby installed for my other Rails applications and do NOT want to install a new version directly on my work machine for the new application
The new app will use a specific version of MySQL, and I already have an older version of MySQL installed on my local machine for other applications. Installing a new version may lead to conflicts or may not work at all
I require an isolated environment for my new Rails application and its database setup. While options such as RVM or rbenv exist for the Ruby portion, but I still need to solve for running multiple versions of MySQL servers
I have some experience in Docker but not a pro. Dockerizing an existing Rails application seems straightforward but creating a new Rails project without a specific Ruby or installed Rails, seems a bit complicated. I need a Get Started guide on creating a new Rails project using Docker

If your requirements align with the above, this post will guide you through creating a new Rails application using Docker without installing Ruby or Rails directly on your OS.

Prerequisite: Ensure that you have Docker Engine installed on your machine. I have Docker Desktop (Docker for Mac) installed on my machine; Docker version is 20.10.11

UPDATE: Check out this new short course on Dockerizing Rails Development Environment using Docker & DevContainers extension in VSCode.

Create project directory

mkdir my-rails-app
cd my-rails-app

Create a project directory on your host machine. At the end of this article, this directory will contain a Rails application code files & folders.

Ruby Version

Before we create a Rails project using a specific Ruby version, we should have an environment with that version of Ruby installed. I am going to use Ruby version 3.1.2.

Instead of installing Ruby on my machine or on OS directly, I will run a docker container using a Docker image containing Ruby 3.1.2 and then shell into the container.

docker run --rm -it -v $PWD:/app:rw ruby:3.1.2 /bin/bash

> ruby -v
ruby 3.1.2p20 ...
>
> gem -v
3.3.7
>
> bundle -v
Bundler version 2.3.7
>

Let’s breakdown the docker command in the above docker run ... command,

We run this command from inside the project directory my-rails-app and we mount the current directory to a path /app inside the container, with read-write (RW) permission. With this, when the container writes any files to /app, those get written to the project directory my-rails-app on host
We use the Docker Image ruby:3.1.2 from DockerHub. When this container is run, we should be able to run any ruby commands inside that container
Last part of the command is /bin/bash. This instructs the Docker Engine to run the command /bin/bash inside the container when the container starts up. This is how you would shell into a new container
The option -i enables an interactive session with container shell. The option -t allocates puedo-TTY. The option --rm ensures that the container is destroyed when we exit from the container shell

Once we’re inside the container shell, you may verify the ruby, bundler, gem, etc. And when you’re done, just type exit to end the session and that should delete the container.

Install Rails Gem

We will be installing the Rails gem inside the container while we’re still on the container shell. Let’s run the gem install ... command inside the container shell. If you exited from that shell, run the above docker run ... command again.

> gem install -v 7.0.3 --no-prerelease --no-document rails

Fetching tzinfo-2.0.4.gem
...
...
Successfully installed actioncable-7.0.3
Successfully installed rails-7.0.3
35 gems installed
>
> rails -v
Rails 7.0.3

We now have Rails 7 installed inside the container. However, if you exit from the container shell, you’ll lose this installation and you will have to run it again. That is because, on exiting the container shell the docker engine will delete the container and all its data.

Create a new project - Ruby on Rails

Now that we are inside the container shell, let’s create a new Ruby on Rails app; provide the directory /app as the project directory which maps to the current project directory, my-rails-app, where we ran docker run command to shell into container.

> rails new --skip-bundle --database=mysql /app

Initialized empty Git repository in /app/.git/
      create  app
      create  app/assets/config/manifest.js
      ...
      ...
      ...

> ls /app

Gemfile    Rakefile  bin     config.ru  lib  public   test  vendor
README.md  app       config  db         log  storage  tmp

It created a new rails project and the code is at /app inside the container. Because we have /app mounted from my-rails-app directory on the host machine, with read-write permissions, we would expect the project directory structure with all the files/folders is actually written to my-rails-app. And the folders and files inside the my-rails-app directory should NOT be deleted if I exit from the container shell.

Let’s exit from the container shell and list the content of my-rails-app directory on host.

> exit
exit
$
$
$ ls
Gemfile         app             db              storage
Gemfile.lock    bin             lib             test
README.md       config          log             tmp
Rakefile        config.ru       public          vendor

$

This is how you can create the Rails project structure using Docker, without having to install specific versions of Ruby or Rails on your work machine.

Next Steps

To run this new Rails application as a container, there are a few things we need to do first:

Create a Dockerfile that uses the same Docker image for ruby:3.1.2
Optionally, create a docker-compose.yml file to provide the container with run-time configurations
Run a MySQL database as a container instead of installing a MySQL server directly on the host machine
Build the Docker image for the Rails application
Finally, run the application and build some amazing things!

If you need more details on these steps, I’ve covered them in the following blog post titled Dockerize An Existing Ruby on Rails Application. Now that Rails project has been created, one should be able to follow the same instructions to Dockerize and Run as docker containers.

Dockerize An Existing Ruby On Rails Application

contact@devteds.com (Chandra Shettigar) — Wed, 15 Jun 2022 00:00:00 GMT

Whether it is a new Ruby project or an existing one, I Dockerize it first. I run pretty much all of the applications as containers on my local as it helps keeping local development setups isolated between the projects. While in production environment, some of those get deployed to Kubernetes or ECS and some go to non-container environments. Regardless, my local development environment is always runs as containers.

UPDATE: Check out this new short course on Dockerizing Rails Development Environment using Docker & DevContainers extension in VSCode.

This post will be useful to you if,

You want to dockerize the local development environment for your Rails application
Your organization or company is moving toward container deployments and you need to start to dockerize your applications
You know a little about docker or at least the theory part of it and you would like dockerize your Rails application but not sure where to start

If you’re looking to create a new Rails application using Docker, I suggest you read the following blog post first: Create Ruby on Rails application using Docker.

In this article, we’ll take a look at Dockerizing an existing Ruby on Rails application. Let’s get started.

The application we’re going to Dockerize is a simple blog application, written in Rails 7 and it uses MySQL database. Let’s get the code from GitHub.

git clone git@github.com:devteds/example-rails-app.git
cd example-rails-app

Dockerfile

The first thing we need is the Dockerfile. This is the file where we define all the necessary OS needs, libraries, work directory, and tools necessary to build the docker image for the application. Dockerfile will be placed at the root of the project folder. In this case, at example-rails-app/Dockerfile.

# example-rails-app/Dockerfile

FROM ruby:3.1.2

RUN mkdir /app
WORKDIR /app

RUN apt-get update -qq && \
    apt-get -y install build-essential

ADD Gemfile /app/Gemfile
ADD Gemfile.lock /app/Gemfile.lock

RUN bundle install

CMD [ "bundle", "exec", "rails", "s", "-b", "0.0.0.0" ]

A quick walkthrough of the Dockerfile:

It uses the base image from DockerHub ruby:3.1.2. This base image is built on Debian and has ruby, bundle, and basic OS libraries necessary to run a ruby application
Creates a directory for the app. This directory, /app, is where the application build/code will be copied to and where the rails commands will be run from when the container is run.
Installs some build tools. A most commonly used one is build-essential which Rails developers often need to install some gems
Copy the Gemfile and Gemfile.lock from the code on Host (Mac in my case) to the app directory inside the container image
Run bundle install. Bundler expects Gemfile and Gemfile.lock in the app directory and that’s why, in the previous step, we copied those files to container’s app directory. - We don’t yet need the source code copied to the container image
And last one is the command that will be run when a container is created using the image built from this Dockerfile. Here we run the rails server and have it listen on the default port 3000. One bit here is the address binding option which is set to 0.0.0.0 meaning that when rails server runs inside the container, it allows us access the service from the host (Mac in my case)

Build Docker Image

Our Dockerfile is ready and we can now build a Docker image. There are a couple of different ways we can go about to docker image. First and most common one is by using docker client and the command will look something the below,

docker build -t example-rails-app .

Instead, I am going to use Docker Compose. I prefer Docker Compose for most of local setup. It helps define the build inputs, container services, and dependencies better, mainly useful for local development environments

Create docker-compose.yml . This file will be placed at the root of the application code directory
Compose file is a YAML and starts with this version line. See the versioning details

Besides the version, the more common one you’ll see in docker-compose.yml is the services section. This is where you define all the container services.

# example-rails-app/docker-compose.yml

version: '3.8'

services:

  blog-app:
    build: .

The docker-compose.yml above has just one service, blog-app. The build is the directory relative to the current directory where you have the source code, Dockerfile and where you’ll run docker or docker-compose commands from.

This should be good enough for us to build the docker image.

docker-compose build

Above command builds an image. The image name will be example-rails-app_blog-app in which example-rails-app is the directory where you have the source code and blog-app is the service name as defined in the docker-compose.yml file.

The docker image we built has all the necessary OS libraries, ruby, directory structure, and bundled gems. What is missing in the image is the application code.

We don’t need to copy the source code to the image for running the application locally; instead, we could mount volume or directory between the host OS (Mac in my case) and the running container.

And there is one more thing missing, that is the database MySQL. Can we install MySQL as well in the same docker image? Beginners tend to do that but that’s not how you want to do it. Because database runs on a different host independent of your application in staging/production, let’s treat it the same way on local.

We can run MySQL also as a container. We don’t want to create a Dockerfile for MySQL or worry about the OS or libraries it requires. Instead, we will use the MySQL Docker image from DockerHub.

MySQL as Container

Let’s add a new service in the docker-compose.yml for the database: blog-db

# example-rails-app/docker-compose.yml

version: '3.8'

services:

  blog-app:
    build: .

  blog-db:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: password
      MYSQL_DATABASE: blog

Let’s take a quick look at the blog-db service:

This service uses the docker image from DockerHub mysql:5.7. Unlike the blog-app service, there is nothing to build for this service and it uses a pre-built docker image from DockerHub
Sets a few environment variables that mysql container reads before booting up mysql-server inside the container. Those environment variables, MYSQL_*, are specific to the docker image we used.
When the blog-db container starts up it creates a database, blog (value of MYSQL_DATABASE); it uses password (value of MYSQL_ROOT_PASSWORD) as root password.

That’s all for the blog-db service. If you would like to learn more about running MySQL as container, watch the following screencast blog: MySQL And PostgreSQL With Docker In Development

Runtime Configs for Application

Now that we have the database container service defined, let’s provide the database configuration to the application (blog-app) container or service. Similar to the blog-db service, let’s provide the environment variables for the application inside the container to read from. And then we will make this app read database configs from environment variables.

# example-rails-app/docker-compose.yml

version: '3.8'

services:

  blog-app:
    build: .
    environment:
      DB_USER: root
      DB_PASSWORD: password
      DB_NAME: blog
      DB_HOST: blog-db
      DB_PORT: 3306

  blog-db:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: password
      MYSQL_DATABASE: blog

The application that will run inside the blog-app container is supplied with a few environment variables for it’s database configs

It uses MySQL’s root user & password, as configured for the MySQL container service blog-db
DB_NAME is blog as configured in the MySQL container service blog-db. DB_PORT is the default, 3306 for mysql.
The value of DB_HOST is the name of database service blog-db. This is one of the reasons why I like docker-compose that it makes is easy to do service linking and works well when there involves inter-service communication between containers services. Among the services defined in docker-compose.yml, one service can talk to another using the service name as host name.

Now that the application is supplied with these environment variables, let’s update database.yml to read the configs from environment variables. Note, this is for local environment and there may be security concerns if you use environment variables like this in prod.

For developers that aren’t familiar with Rails, the database.yml, is the config file that a Rails application reads database configs from. It doesn’t have to hardcode all the values.

It’s nice that database.yml in Rails works nicely with embedded ruby (ERB). That makes it all easy to configure this.

# config/database.yml

default: &default
  adapter: mysql2
  encoding: utf8mb4
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  database: <%= ENV['DB_NAME'] %>
  username: <%= ENV['DB_USER'] %>
  password: <%= ENV['DB_PASSWORD'] %>
  host: <%= ENV['DB_HOST'] %>
  port: <%= ENV['DB_PORT'] %>

development:
  <<: *default

test:
  <<: *default

production:
  <<: *default

3 more things we need updated in the docker-compose.yml for the blog-app service,

Application Code: The docker image that we build will not have the source code and that because the Dockerfile does not have any instruction to copy the source code to the container image. More importantly, we don’t want the docker image to have the source code for running it locally. Instead we can mount our local directory (from the host machine, Mac in my case) to the work-directory inside the container when running the container or when running the service
Service Port: When we run the application using docker or docker-compose, it runs inside a container. Rails service listens at the port 3000 by default and but that port will NOT be available to host (Mac in my case), to browse from the browser. That means I cannot hit http://localhost:3000 from my browser. In order to allow that, we need a port map and provide the port that you want to access the service on your browser and the port at which the service inside the container listens to. Here is I set the host port as 3300 which maps to port 3000 of the container. And then I will be able to access the app service at http://localhost:3300
Service Dependency: we need the database service be ready before rails container starts up. Put that dependency using depends_on. Note: when mysql container status is Ready/Running, it is possible that the mysql server is not fully started up. That means, depends_on, may not work in all cases

# example-rails-app/docker-compose.yml

version: '3.8'

services:

  blog-app:
    build: .
    volumes:
      - .:/app:rw
    environment:
      DB_USER: root
      DB_PASSWORD: password
      DB_NAME: blog
      DB_HOST: blog-db
    depends_on:
      - blog-db
    ports:
      - 3300:3000

  blog-db:
    image: mysql:5.7
    environment:
      MYSQL_ROOT_PASSWORD: password
      MYSQL_DATABASE: blog

All set! Our docker-compose.yml has both the container services (blog-app and blog-db) defined.

docker-compose up

Leave the above command running in the foreground and run the following on another terminal window or tab to verify the container service status. This should list both the services with some details such as the service status and port-mapping information.

docker-compose ps

Now that both the services, the application blog-app and the database blog-db, are running, I should be able to hit the application from browser at http://localhost:3300.

But it will fails with an error on querying some tables in blog-db. That’s because we haven’t created any tables. Let’s run a script create necessary tables. In Rails, we manage all the database schema changes in the application code and run rails migration commands.

The application code has necessary schema migration code. Let’s run the command rails db:migrate to run those and create necessary tables. We can either run this command inside the container service that is already running that serves web requests or spin off a temporary container for blog-app service to run this command. I always prefer the latter and let’s do that.

Leave the docker-compose up running, and run the database migration and reload the page,

docker-compose run --rm blog-app rails db:migrate

The above command will create a new container for blog-app, using its definition from the docker-compose.yml and in that container it runs the rails db:migrate command and exit. The —rm makes the container be killed after the completion of the command it run.

You should now be able to hit the application from browser and it should respond 200OK.

Use the admin interface to populate some posts and verify the API response for posts.

Conclusion

That’s all about containerizing a Rails application along with running MySQL as container. Again, this is good for running your application locally using docker.

We have some more work to do in Dockerfile to make the docker image production-ready or even to be able to deploy on non-production environments on platforms such as Kubernetes, Amazon ECS, etc. I will create a separate post to cover some of the basics involved in creating a docker image for production.

I hope you found this post helpful. I appreciate you sharing with your network that may find it useful.

Docker On Amazon ECS Using CloudFormation

contact@devteds.com (Chandra Shettigar) — Fri, 03 Aug 2018 00:00:00 GMT

This tutorial will guide you through the process of deploying and running Docker containers on Amazon Elastic Container Service (ECS) with AWS Fargate using AWS CloudFormation stacks. To accomplish this, we’ll be creating Elastic Container Registry (ECR) and multiple CloudFormation stacks for groups of resources on the cloud, including VPC, subnets, load balancers, CloudWatch, ECS Cluster, container tasks, and services.

Here are the steps we’ll follow:

Containerize a simple REST API application by building a Docker image.
Use AWS CLI to create a repository on Amazon Elastic Container Registry (Docker Registry).
Push the Docker image to the repository on Amazon ECR.
Define and run a CloudFormation stack to create VPC and all network components.
Define and run a CloudFormation stack to create IAM roles.
Define and run a CloudFormation stack to create ECS Cluster, Load balancer, CloudWatch Log Group, and Security Groups.
Define and run a CloudFormation stack to deploy the Docker application, including creating a task for the container, a service to schedule the task, a load balancer target group for container services, and a load balancer listener rule for container service.

Upon completing this tutorial, you will be able to create ECS Fargate infrastructure using CloudFormation code, and deploy and execute Docker containers on ECS.

MySQL and PostgreSQL with Docker in Development

contact@devteds.com (Chandra Shettigar) — Thu, 12 Oct 2017 00:00:00 GMT

In this tutorial, we will go over the process of setting up and running MySQL and PostgreSQL databases using Docker Compose in a development environment. Docker Compose allows us to define container services for multiple versions of these databases in a YAML file, making it easy to create, configure, and manage them.

Here are the steps we will cover:

Define a Docker Compose YAML file for a simple MySQL container.
Test connecting to the containerized MySQL server using MySQL Workbench on the host OS.
Test connecting to the containerized MySQL server database using another container.
Test connecting to the containerized MySQL server database from within the container.
Run multiple MySQL databases of different versions as containers.
Configure volume mounts between the host OS and container to share the MySQL server configuration file.
Configure volume mounts between the host OS and container to share the data directory.
Manage containerized databases using a database management web tool, such as adminer.
Run a containerized PostgreSQL database along with multiple MySQL databases.

By the end of this tutorial, you will have a solid understanding of how to use Docker Compose to set up and manage multiple MySQL and PostgreSQL databases in a development environment. This knowledge will enable you to create complex, multi-database applications with ease.

Create AWS CloudFormation Stack for EC2 & RDS and Deploy Docker App

contact@devteds.com (Chandra Shettigar) — Sun, 23 Apr 2017 00:00:00 GMT

Learn how to create application stack using AWS CloudFormation and then deploy dockerized API application.

Stack is defined using YAML template that contains 4 resources to be created on AWS,

EC2 Instance to run the application on
EC2 Security Group that defines the possible inbound ports on the EC2 instance
RDS Instance for MySQL database
RDS Security Group that defines the possible sources the database can be reached from

Following are the steps to walk through,

Create a KeyPair on AWS account to be used for SSH access to EC2
Generate API keys and configure the AWS CLI on the local machine
Create a simple stack using CloudFormation and this stack will consist of an EC2 instance and necessary security group for the EC2 instance
Update the stack to install and configure docker on the EC2 instance
Update the stack to add RDS instance and necessary security group to the stack
Create Docker compose file to define the application to be deployed on EC2 instance with its database on RDS instance
Deploy the application on the EC2 instance (docker host) remotely from local