DEV Community: Gbenga Kusade

SRE in Action: Understanding How Real Teams Use SLOs, SLIs, and Error Budgets to Stay Reliable Through Case Studies - Part 1

Gbenga Kusade — Sun, 16 Nov 2025 13:33:26 +0000

When people talk about Site Reliability Engineering (SRE), they often share abstract principles about SLIs, SLOs, and error budgets. But here's the problem: understanding the concepts isn't the same as knowing how to apply them.

The truth is, reliability challenges look radically different depending on where you sit. This article presents two SRE implementations from completely different perspectives, a complete walkthrough for beginners:

For startups (CompanyA): it's about moving fast without breaking everything as you scale.
For enterprises (CompanyB): it's about coordinating dozens of teams who can't agree on what "reliable" even means.

Both need SRE principles. But the implementation couldn't be more different.

Let's dive in.

CASE 1: How a FinTech Startup Moved from Firefighting to Measurable Reliability

What You will Learn

By the end of this case study, you will understand:

How to identify what metrics actually matter to users (SLIs)
How to set realistic reliability targets (SLOs)
What an error budget is and why it is your secret weapon
How to balance shipping features with maintaining reliability

No complex theory, just a startup's journey from chaos to confidence.

Meet CompanyA: A Growing Startup with Growing Pains

CompanyA is a x-year-old fintech startup providing digital wallets and payment APIs to small businesses across Africa. They recently crossed 1 million users, exciting news! But with growth came pain.

CompanyA Tech Stack

Frontend: React web app
Backend: Containerized services on AWS ECS
Database: PostgreSQL on RDS
Infrastructure: API Gateway + CloudFront CDN

The Problem

During high-traffic periods (Black Friday, salary week, etc.), things started breaking:

Payment success rates dropped to 96%
Users complained: "Transfers hang for minutes!"
Engineers were burning out from constant alerts
Every issue felt equally urgent
No one could agree on what "reliable" meant

If this sounds familiar, let us see how it was fixed. We will pick the process up step by step.

Step 1: Understanding SLIs (Service Level Indicators)

What is an SLI?

Think of SLIs as the vital signs of your service. Just like a doctor checks your heart rate and blood pressure, SLIs tell you what your users are actually experiencing.

CompanyA's Journey: Finding What Matters

The team started by asking: What does success look like from a user's perspective?

They mapped out the critical user journey:

For each step, they asked: What metric shows if this step is working well?

The SLIs They Chose

Why 95th Percentile?

Instead of looking at average response time (which hides problems), the 95th percentile shows: 95% of users experience this speed or better.

For Example:

Average latency: 1.5s (looks good!)
95th percentile: 5s (problem! 5% of users wait too long) The 95th percentile catches issues that averages hide.

Step 2: Setting SLOs (Service Level Objectives)

What's an SLO?

An SLO is your reliability target: a specific, measurable goal you commit to internally. It answers: How reliable should this service be?

CompanyA's Approach: Data-Driven Targets

They did not guess. They analyzed 3 months of real data to see:

What reliability were they currently achieving
Where users dropped off
What was realistically achievable

Here is what they decided:

Critical Decision: Why Not 100%?

CompanyA learned that chasing 100% is a trap:

It is impossibly expensive
It slows innovation to a crawl
Real-world systems have dependencies that fail

Instead, they accepted 0.1% failure (about 43 minutes of downtime per month). This is not giving up; it is being realistic.

The Golden Question

When setting SLOs, ask yourself:

What is the minimum reliability that keeps users happy and the business healthy? By setting the bar too low -> users leave. By setting the bar too high -> you never ship features

Step 3: Understanding Error Budgets

What is an Error Budget?

This is the game-changer concept. Your error budget is the amount of unreliability you can afford before breaking your SLO.

Think of it like this:

SLO says: "Be available 99.9% of the time"
That means you can be down 0.1% of the time
That 0.1% is your error budget

CompanyA's Error Budget Calculation

For their 99.9% availability SLO over 30 days:

Total time in month = 30 days × 24 hours × 60 minutes = 43,200 minutes
Allowed downtime (0.1%) = 43.2 minutes

This is their error budget: 43.2 minutes of downtime per month

The Policy That Changed Everything

CompanyA created a simple rule:

If the Error budget > 50% remaining -> Ship new features confidently

If the Error budget is 25-50% remaining  -> Review what's burning the budget, slow down risky changes

If the Error budget is < 25% remaining -> FREEZE new features, focus only on reliability

If the Error budget is exhausted (100% used) -> Complete feature freeze until the budget recovers the next month

Why This Matters

The error budget gave engineers objective authority to say "not now" when reliability was at risk.

Step 4: Building Visibility with Dashboards

Making It Real: The Dashboard

CompanyA built a simple Grafana dashboard that everyone (incl. engineers, product managers, executives, etc.) could understand:

The Architecture Behind It

What Made This Dashboard Effective

Single source of truth: No more "it works on my machine"
Real-time visibility: See problems as they happen
Clear status: Green/Yellow/Red, no ambiguity
Actionable alerts: Only fires when SLOs are actually at risk

Step 5: Using Data to Drive Improvements

Problem 1: Slow API Response Times

What the data showed:

P95 latency: 3.2s (breaching the 2.5s SLO)
Happened during peak traffic
Correlated with database query spikes

Root cause investigation:

Database connection pool maxing out
Repeated queries for the same data
No caching layer

Fixes implemented:

Increased connection pool size
Added Redis caching for frequent queries
Implemented query result pagination Result: P95 latency dropped to 1.8s

Problem 2: Success Rate Drops During Promotions

What the data showed:

Success rate dropped to 96% during Black Friday
Error budget consumed 40% in one week
Alerts everywhere

Root cause investigation:

System couldn't handle 5x normal traffic
No load testing before promotional launches
Services crashed under load

Fixes implemented:

Added load testing to CI/CD pipeline
Implemented auto-scaling based on request rate
Added circuit breakers to prevent cascade failures Result: Next promotion maintained 99.9% success rate

Problem 3: Alert Fatigue

What the data showed:

On-call engineers getting 50+ pages per week
80% of alerts resolved themselves
Team morale is suffering

Root cause investigation:

Alerts triggered on any spike, not SLO breaches
No distinction between warning and critical
Noisy metrics creating false positives

Fixes implemented:

Rewrote Prometheus alerting rules to focus on SLO breaches
Added "sustained for 10 minutes" threshold
Differentiated between "watch" and "act now" alerts

Result: Pages reduced by 65%, MTTR improved by 40%

Step 6: Understanding SLAs (Service Level Agreements)

What's an SLA?

An SLA is your external promise to customers, usually with financial consequences if you break it.

CompanyA's SLA Design

They created customer-facing SLAs backed by internal SLOs:

Internal SLO: 99.9% availability
Customer SLA: 99.5% availability (with buffer!)

Why the buffer?
- Protects against measurement differences  
- Gives room for maintenance windows
- SLO breach doesn't automatically mean SLA breach

The Customer Agreement

CompanyA Payment API - Service Level Agreement

Availability Guarantee: 99.5% uptime monthly
Sample Credit Structure:
- 99.0-99.49% uptime → 10% credit
- 98.0-98.99% uptime → 25% credit  
- Below 98.0% uptime → 50% credit

Exclusions:
- Scheduled maintenance (announced 48hrs ahead)
- Customer's infrastructure issues
- Force majeure events

Key Lesson

Your SLAs should be less strict than your SLOs.

This buffer means:

You have time to fix issues before customers are affected
You're not paying out credits for every tiny breach
You can meet customer expectations consistently

The Results: 6 Months Later

Metrics

Cultural Wins

Key Takeaways for Your Team

Start Small: You don't need to instrument everything. Pick one critical service and one user journey.
Use Real Data: Don't guess at SLOs. Look at 2-3 months of actual performance and user behavior.
Your Error Budgets Are Power: They transform reliability from a vague concept into something you can negotiate with data.
Dashboards Create Alignment: When everyone sees the same numbers, conversations shift from blame to improvement.
SLAs Need Buffers: Your internal targets (SLOs) should be stricter than your customer promises (SLAs).
Perfect Is the Enemy of Reliable: Chasing 100% uptime kills innovation. Accept some failure, measure it, and stay within budget.

Want To Try This With Your Team?

The template below can help

Week 1: Define

Pick one critical service
Map the user journey
Choose 2-3 key SLIs
Pull historical data

Week 2: Measure

Set realistic SLOs based on data
Calculate error budgets
Set up basic monitoring

Week 3: Monitor

Build a simple dashboard
Review daily: Are we within SLOs?
Document what's consuming the budget

Week 4: Improve

Hold a team review
Pick the top budget-burner
Plan improvements
Iterate!

Resources to Go Deeper

Google SRE Book - Free, comprehensive
Google SRE Workbook - Practical exercises
Prometheus Best Practices - Metrics collection
Grafana SLO Plugin - Dashboard tooling

Up Next!

In the next case study (final), we will explore how CompanyB, a big Telecom organization with both legacy and modern systems, applied these same principles across multiple teams and vendors.

Watch Out!

For your questions, thoughts, additions, or suggestions, please share in the comments section!

Breaking Things on Purpose: What I Learned from Netflix’s Chaos Monkey

Gbenga Kusade — Mon, 06 Oct 2025 07:56:16 +0000

When I first heard that Netflix built a tool designed to deliberately crash their own servers, I thought it was a joke. For most of us, system reliability means avoiding failures at all costs (patching bugs, adding monitoring, and building redundancy, etc.). But Netflix took a counterintuitive, almost radical approach: they built a tool that intentionally breaks their own systems.

That tool is called Chaos Monkey.

What is Chaos Monkey?

Chaos Monkey is part of Netflix’s "Simian Army," a suite of tools designed to test system resilience. Its job is deceptively simple: to randomly terminate production instances and virtual machines.

Imagine running critical services in the cloud, and without warning, one of your servers vanishes. That is Chaos Monkey in action. It sounds brutal, yes, it is!. Here is the catch: if your system can survive a random server failure in the middle of a busy workday, that is a strong sign you are on the right track toward true resilience.

Why Would You Break Your Own System?

In the real world, failures are inevitable. Servers crash, network cables get unplugged, and entire cloud regions can go dark. The absolute worst time to discover you are unprepared is during an actual crisis.

By deliberately injecting failure, Netflix forced its engineers to:

Design systems that inherently tolerate instance loss.
Write and practice recovery playbooks.
Build genuine confidence in their infrastructure.

In essence, Chaos Monkey transformed the fearful question, "What if it fails?" into a confident statement: "When it fails, we are ready."

The Core Lesson for System Reliability

At the heart of reliability engineering is accepting that failure is not an "if," but a "when." The true measure of a system is not whether it never breaks, but how gracefully it responds when it does.

Chaos Monkey embodies this mindset by:

Testing Assumptions: Do we truly have redundancy, or just a diagram that says we do?
Exposing Weak Spots: What happens when a critical dependency suddenly vanishes?
Forcing Resilience by Design: Teams can no longer hope for the best; they must build for the worst.

It is one thing to claim your system is reliable. Chaos Monkey demands proof.

Should You Unleash the Monkey?

If you are operating in the cloud, for example, the short answer is "not immediately". You do not start with Chaos Monkey on day one. First, you need a solid foundation:

Comprehensive monitoring and alerting.
Automated scaling and recovery processes.
Well-practiced incident response procedures.

Once these fundamentals are in place, a tool like Chaos Monkey becomes the ultimate test, validating your resilience under real-world pressure.

Summary

System reliability is not about building a fortress that never falls. It is about building a system that can take a hit, bounce back, and keep running. Netflix's Chaos Monkey is the ultimate expression of this philosophy.

Instead of fearing failure, they embraced it, trained for it, and emerged stronger. It is a powerful lesson for any system we build.

So, would you dare unleash Chaos Monkey on your production stack?

https://netflix.github.io/chaosmonkey/
https://www.oreilly.com/library/view/designing-data-intensive-applications/9781491903063/

Jenkins - Auto-build your dockerised local Environment on code commit

Gbenga Kusade — Sun, 31 Dec 2023 16:57:41 +0000

Previously, we set up a local JS and Python environment using docker and docker-compose. In this post, we will automate the build process in Docker using Jenkins. This will allow us focus more on our code while developing.

Please read the first part of this tutorial here if you haven't.

Let's get started!

What is Jenkins?

Jenkins is an open-source automation server. It's used to support building, deploying, and automating any project. Jenkins is a continuous integration and delivery (CI/CD) tool that is widely used interchangeably. Jenkins's capacity to divide tasks among several nodes is one of its most powerful features.

Setting up Jenkins

To follow along, clone the repository using the following commands.
git clone https://github.com/jagkt/local_dev_env.git
cd local_dev_env
Now you should have the following project structure to start with:
.
├── node
│ ├── index.js
│ └── package.json
└── py
│ ├── Dockerfile
│ ├── requirements.txt
│ └── main.py
├── LICENSE
├── Makefile
├── README.md
├── Jenkinsfile
└── docker-compose.yml

Here, Jenkinsfile is introduced to the project directory, this is where we will declare our declarative pipeline script telling Jenkins how to go about the build process. Also, the Jenkins service is added in the docker-compose.yml file with the following code.

jenkins:
    image: jenkins/jenkins:lts
    privileged: true
    user: root
    ports:
      - 8080:8080
      - 50000:50000
    container_name: jenkins
    volumes:
      - /home/${whoami}/jenkins:/var/jenkins_home
      - /var/run/docker.sock:/var/run/docker.sock
      - /usr/bin/docker:/usr/bin/docker

Here, the Jenkins service is defined by pulling the latest Jenkins image with root privileges. The container is run with host networking, and we tell Docker to redirect ports 8080 and 50000 to the host’s network. Also, we gave it a container name called Jenkins.

Finally, the /home/${whoami}/Jenkins (which will contain the Jenkins configuration) is mapped to /var/jenkins_home in the container. Ensure to create the Jenkins configuration directory on your host and change /home/${whoami}/ to your user’s home directory or the path you created the new directory. Also, the /var/run/docker.sock and /usr/bin/docker on the host are mapped to the /var/run/docker.sock and /usr/bin/docker respectively. This is to allow the Jenkins container to have access to the host docker daemon.

Now run the Jenkins service

Run docker-compose in the directory where you placed docker-compose.yml file.
$ docker-compose up -d jenkins

Allow Jenkins to use docker-compose commands

Because we will be using the docker-compose command in our Jenkins pipeline script, we need to ensure Jenkins can run the commands.

On your host, exec into the running Jenkins container.

docker exec -it jenkins /bin/bash

run the following commands inside the Jenkins container.

groupadd -g 997 docker
gpasswd -a jenkins docker
curl -L https://github.com/docker/compose/releases/tag/1.29.2/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose

#confirm the docker-compose is installed
docker-compose version

the last command output should be similar to this.

Jenkins Configuration

Now point a web browser at port 8080 on your host system and use the actual IP address or domain name for the server you are using Jenkins on. In our case http://localhost:8080. A page opens prompting you to Unlock Jenkins. Obtain the required administrator password in the next step.

Obtain the default Jenkins unlock password by opening the terminal and running the following command:

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

The system returns an alphanumeric code. Enter that code in the Administrator password field and click Continue.
The setup prompts to either install suggested plugins or Select plugins to install. It’s fine to simply install the suggested plugins.

The next step is the Create First Admin User. Enter the credentials you want to use for your Jenkins administrator, then click Save and Continue. Here, Jenkins user is used.

click “Save and Continue”
click “Start using Jenkins”

Create a Jenkins project

we need to create a pipeline that builds our images automatically. From the Jenkins dashboard:

select "New Item", on the pop-up window, enter the project name in the "Item Name" textboard, then select Pipeline and click "OK"

On the project's configuration page, under the "General" tab, scroll down to "Build trigger" and select "GitHub hook trigger for GITScm polling"

Scroll down to the Pipeline section, under "Definition", select "Pipeline script from SCM", and under SCM, select "Git".
fill in the "repository URL" and add your GitHub credential (you can generate a token on GitHub for authentication)

On the branch to build from, specify the branch name (in this case, the main branch).

Scroll to the script path and ensure Jenkinsfile is specified.

Finally, select "Manage Jenkins" on your dashboard and select "Plugins". Under the "Available Plugins", search for "Docker Pipeline" and install.

Jenkinsfile

The Jenkinsfile we added to the project directory contains the below declarative pipeline script.

pipeline {

    agent any

    stages {
        stage('Checkout Source') {
            steps {
                git branch: 'main ', url: 'https://github.com/jagkt/local_dev_env.git'
            }
        }

        stage('Docker Compose Build image') {
            steps {
                    sh "docker-compose build"
                    sh "docker-compose up -d py_app"
                    sh "docker-compose up -d node_app"
            }
        }
    } 
}

Here,

pipeline is Declarative Pipeline-specific syntax that defines a "block" containing all content and instructions for executing the entire Pipeline.
agent is Declarative Pipeline-specific syntax that instructs Jenkins to allocate an executor (on a node) and workspace for the entire Pipeline. Here, any agent is specified.
stage is a syntax block that describes a stage of this Pipeline. stage blocks are optional in Scripted Pipeline syntax. Here we have two stages build process: checkout source and image build process
steps is Declarative Pipeline-specific syntax that describes the steps to be run in this stage.
sh is a Pipeline step (provided by the Pipeline: Nodes and Processes plugin) that executes the given shell command. First, We build our images before running their containers.

Read more about Jenkins' declarative pipeline here. Also, ensure to set the checkout source URL to your GitHub project repository and specify which branch to build from.

Automatically Run Build on Code Commit

First, we need to get the hook URL of Jenkins. From the Dashboard, click "Manage Jenkins", then click "System"
Scroll down to the "Github" section, click "Advance" under the " Github server", and check the box for "Specify another hook URL for GitHub configuration". Click "Save"

As shown above, the URL is http://localhost:8080/github-webhook/. This will be used to add a webhook to the GitHub project repository. The challenge here is, how does GitHub determine the host where our Jenkins container is running?
A quick way to solve the challenge above is to make the Jenkins service accessible in the public domain. I recently wrote an article on how to quickly set this up using Localrun.

Read the article here

Obtain the domain given to you after running Localrun on your host. say for example we have https://2d70a750dc2554.lhr.life.
Go to your project repository on GitHub, click "Settings", click "Webhooks", and click "Add webhook".
Configure as shown below and click "Add Webhook".

Here, we have replaced http://localhost:8080/ with https://2d70a750dc2554.lhr.life/

Note: localrun domain is active for a few minutes. This means you need to update the webhook payload URL every time with the new domain to continue the auto-build process. Alternatively, you can use other services that provide longer time usage.

Now that the setup is completed, Jenkins will now run the build whenever you push/commit code to the main branch of your GitHub repository.

On your Dashboard, you can see your created pipeline, click on it, and you can see your build history or manually run your build.

Conclusion

I hope you now have a solid idea of setting up Jenkins to automate your local environment build process. In summary, we observed the following:

Created a Jenkins service and allowed it to access the host docker daemon.
configured Jenkins pipeline job to auto-build whenever we commit code changes to the GitHub repository.

If you experience difficulty while going through this tutorial, you can drop the challenge(s) faced in the comment section.

Reference

A quick way to access your local server on the internet

Gbenga Kusade — Thu, 14 Dec 2023 14:26:42 +0000

Sometimes you may need to test and market your locally hosted applications on the internet while developing in a local environment. Having a tool that allows you to create a tunnel between your local development environment and a remote server using some tunneling services that enables you to share your work, test and deploy hosted application without the need for public infrastructure comes in handy here.

You'll see how to quickly access your local webserver over the internet using Localhost.run in this tutorial.

Localhost.run

Using localhost.run is as simple as running the following ssh command in your terminal to connect an internet domain to an application running locally on port 8080

ssh -R 80:localhost:8080 ssh.localhost.run

you will be presented with the following similar output

Scan the QR code with your mobile and your local server will be accessible in your phone browser.

There are instances you can receive permission denied error due to some ssh key issue, to fix, do the following:

1. change directory to the current user home directory
Cd ~
2. Check if "id_dsa.pub" file exist in your ".ssh" folder
3. If exist, skip to step 5. if not, run ssh-keygen command to generate a public ssh key:
ssh-keygen
4. Follow the screen prompt until the key is generated
5. Add the generated public key to the authorized_key file, which contains public keys for public key authentication:
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
6. Run localhost.run command again:
ssh -R 80:localhost:8080 ssh.localhost.run

While this may seem like a straightforward approach, the free version is however time limited, and may not be suitable if you need to stay longer using it. You will need to create an account to stay longer.

Other services providing similar function include:

Ngrok: This provides about 2hours on the free account but requires account registration and adding your authtoken, and starting it is as simple as running ngrok http 8080

Cloudflare Tunnel: requires account registration
serveo.net

Note
Please know that following this tutorial may introduce a potential for reduced security and privacy. So, use cautiously!

References

Docker - Setup a local JS and Python Development environment

Gbenga Kusade — Sat, 02 Dec 2023 12:20:27 +0000

It is difficult to develop locally for modern systems because they typically incorporate various services. The process of setting up a local development environment has drawn concerns from certain developers. One major problem that affects developers is the "this works on my computer" problem, which arises when they develop an application that works well on their local computer but not at all when it is deployed to other environments. These situations make it more difficult to collaborate or deploy effectively.

This post is for you if you encounter the above problem during the development process. We'll use Docker to set up a local development environment in this tutorial. You will know how to create and configure a local development environment for Node.js and Python by the time you finish reading this post.

Prerequisites

Install the following:

Docker
docker-compose
git
Basic knowledge of setting up a NodeJS and Python project

Example Architectural Design

Suppose we have a set of services with the following architecture.

As we can see from the diagram, we have:

Node - A NodeJS service running on port 5000
Py - A Python service running on port 8000

Setting it up

We'll establish a basic Python and Node.js service setup as described above. To follow along, clone the repository using the following commands.



git clone https://github.com/jagkt/local_dev_env.git
cd local_dev_env

Now you should have the following project structure to start with:

.
├── node
│ ├── index.js
│ └── package.json
└── py
│ ├── Dockerfile
│ ├── requirements.txt
│ └── main.py
├── LICENSE
├── Makefile
├── README.md
└── docker-compose.yml

To spin up the services, run the script below from the project directory:



make up  
make run_con #check the services are up and running

you can access both py and node applications from the browser

py: http://localhost:8000 or node: http://localhost:5000

Now, let's deep dive into the project setup details.

Build a Docker Image for the Python Environment

Here, we’ll build a Docker image for the Python environment from scratch, based on the official Python image, and build a FastAPI application in it. First, let's create a package requirements.

Create a directory named “py” and inside the directory, create a requirements.txt file and copy the below dependencies to run the FastAPI application in it.



fastapi
uvicorn[standard]

Next, create a main.py with the FastAPI application code below:



from fastapi import FastAPI
app = FastAPI()

@app.get("/")
async def home():
    return {"message": "Hello from py_app!"}

@app.get("/hello/{user}")
async def greetings(user):
    return {"Hello": user}

Containerized our python environment

We must first create a Dockerfile with the instructions needed to build the image in order to generate a Docker image. After that, the Docker builder processes the Dockerfile and creates the Docker image. The Python service is then launched and a container is created using a simple docker run command.

Dockerfile

One way to get our Python code running in a container is to pack it as a Docker image and then run a container based on it. The steps are sketched below.

_credit: docker.com_

Now in the same project directory create a Dockerfile file with the following code:




# # Pull the official docker image
FROM python:3.11.1-slim
# # set work directory
WORKDIR /home/py/app
# # set env variables
ENV PYTHONDONTWRITEBYTECODE 1 \ 
    PYTHONUNBUFFERED 1 \
    PIP_NO_CACHE_DIR=1
# # install dependencies
COPY ./requirements.txt .
RUN pip install --upgrade -r requirements.txt 
# copy project
COPY . /home/py/app

Let's take a deep dive into the Dockerfile code.
FROM: specifies the slim version of the Python 3.11 base image to build a Docker image
WORKDIR: This command sets the active directory (/home/py/app) on which all the following commands run.
ENV variables are set to optimize the behavior of pip during the installation of the packages (in the requirements.txt file) in the Docker container.
-- PYTHONUNBUFFERED=1 -- Allow statements and log messages to immediately appear
-- PIP_DISABLE_PIP_VERSION_CHECK=1 -- disable a pip version check to reduce run-time & log-spam
-- PIP_NO_CACHE_DIR=1 – this is to disable cache to reduce the docker image size
COPY: This copies the requirements.txt file from the host to the container’s WORKDIR
RUN: invokes installing the container applications or package dependencies in the requirements.txt file
COPY: copies the application source codes from the host to the WORKDIR.

Now, Let’s create a container image, run the container, and test the Python application.
To build the container image, switch to the py directory and run the following command



docker build -t python-application:0.1.0 .

Check your image



docker image ls

Then, proceed to create a container. To access your application from your host machine, you need to do “port forwarding” to forward or proxy traffic on a specific port on the host machine to the port inside your container.



docker run -p 4000:4000 python-application:0.1.0

Check your container



docker container ls

Finally, access your application by running a curl command, testing with the browser, or running Postman.



curl http://127.0.0.1:4000



curl http://127.0.0.1:4000/hello/James

Build the Node Environment

First, create a new directory named "node" in the "local_dev_env" directory, and create an index.js file in it with the code below.



const express = require("express");
const app = express();
const PORT = process.env.PORT || 5000;

app.get("/", (req, res) => {
    res.send("Hello from node_app");
});

app.listen(PORT, () => {
    console.log(`Server running on port ${PORT}`);
  });

Also, create a new file name package.json with the code below in the node directory



{
    "name": "node",
    "version": "1.0.0",
    "description": "A sample nodejs application",
    "main": "index.js",
    "scripts": {
      "start": "node index.js"
    },
    "author": "admin@admin.com",
    "license": "MIT",
    "engines": {
      "node": ">=10.1.0"
    },
    "dependencies": {
      "express": "^4.18.2"
    }
  }

Now that we have our basic script to run the Node application, we'll create our base image. This time we will not be using the Dockerfile as we did earlier with the Python environment, but we will pull directly from the Docker Hub registry.
Because we have multi-container services, it's best to orchestrate our services from a single file rather than building the services individually from a Dockerfile, which could be a daunting task if we need to build many services. Therefore, spinning up our Node containers with Docker Compose can be pretty handy in these situations. Note that Docker compose does not replace Dockerfile. Rather, the latter is part of a process to build Docker images, which are part of containers.
Docker Compose allows us to operate the Node app alongside other services (assuming we have many services we need to spin up). In our case, it will be alongside our py service.

Docker Compose

In the "local_dev_env" directory, create a "docker-compose.yml" file with the code below:



version: '3'
services:
  py_app:
    build: ./py
    container_name: py
    command: uvicorn main:app --host 0.0.0.0 --reload
    environment:
      - FastAPI_ENV=development
      - PORT=8000
    ports:
      - '8000:8000'
    volumes:
      - ./py:/home/py/app 

  node_app:
    image: node:12.3-alpine
    container_name: node
    user: "node"
    environment:
      - NODE_ENV=development
      - PORT=5000
    command: sh -c "npm install && npm start"
    ports:
      - '5000:5000'
    working_dir: /home/node/app
    volumes:
      - ./node:/home/node/app:cached

As seen from the compose file, two services were defined: py and node.

You’ll see some parameters that we didn’t specify earlier in our Dockerfile. For example, The py service uses an image that's built from the Dockerfile in the py directory we created above using the build key. it is assigned a container name of "py" with the container_name key, and upon starting, it runs the FastAPI web server with the command key (uvicorn main:app --host 0.0.0.0 --reload).
The volumes key mounts the py directory in the project directory (./py) on the host to (/home/py/app) directory inside the container, allowing you to modify the code on the fly, without having to rebuild the image. The environment key sets the FastAPI_ENV and PORT environment variables, which tells FastAPI to run in development mode and listen on PORT 8000.
It then binds the container and the host machine to the exposed port, 8000 with the ports key. This example service uses the default port for the FastAPI web server, 8000.

Similar to the py service declaration, the node service uses most of the declared keys but instead of building its image from a Dockerfile, it uses a public node 12.3 alpine image pulled from the Docker Hub registry with the image key. The user key lets you run your container as an unprivileged user. This follows the principle of least privilege. The working_dir key is used to set the working directory in the container to /home/node/app.

Now, let us build and run our services
To jumpstart your services (py and node) containers, build the app with the compose file from your project directory, and run it.



docker-compose up -d

To verify that all services' images have been created, run the following command. The py and node images should be returned within the CLI.



docker image ls

To verify that all services are running, run the following command. This will display all existing containers within the CLI



docker container ls --all

Let us try one more thing, execute a bash command from the py container to list the contents in the directory (/home/py/app).



docker exec -it py bash
ls -l  #list the directory in the py container

Makefile

Here, we took an additional step and created a Makefile, which simplifies dealing with the tools by enabling us to use shortcuts rather than typing out lengthy commands. A command can be defined in the Makefile and used by using the syntax of the make command.

We can spin up all the containers, execute commands from within the container, check logs, and spin down the containers as shown below.



make up
make py # execute shell script from our py container
make py_log  #ouput logs from py container
make node_log #ouput logs from node container
make down  #spin down our services including network created

Conclusion

I hope you now have a solid idea of how to set up your local development environment from this tutorial. In summary, we observed the following:

Making images for Docker and running a container from a Dockerfile.
Spin up several Docker containers using docker-compose.
Using Makefile to simplify the execution of complicated commands

UPNEXT!: let us automate our build process. Click here to read.