AWS Builder Center

🐳 Day 18/30: Containers & Docker β€” How Do We Package an Application So It Runs Consistently Everywhere? ☁️

What happens when an application works perfectly on a developer’s laptop but fails after deployment? πŸ€” Discover how Docker and containers help package applications with their dependencies for more consistent deployments. πŸš€ Explore Dockerfiles, images, containers, and how AWS services like Amazon ECR, Amazon ECS, and AWS Fargate help run containerized applications. Follow our college examination portal as it takes another step toward a scalable, production-ready cloud architecture! ☁️

Series: Cloud Computing (25 articles)

  1. …
  2. 19
    🐳 Day 18/30: Containers & Docker β€” How Do We Package an Application So It Runs Consistently Everywhere? ☁️ This article
Tech Enthusiast | Exploring AWS, Data Structures & Web Dev

🐳 Day 18/30: Containers & Docker β€” How Do We Package an Application So It Runs Consistently Everywhere? ☁️

πŸš€ Mission 18: Pack It Once, Run It Anywhere!

Imagine this: our college examination portal is finally working perfectly on a developer’s laptop. Students can register for exams, upload documents, and check their application status.
The developer is happy. The testing team is happy. Everything works!
But when the team deploys the application to a server in the cloud, something goes wrong. 😱
A library is missing. A software version is different. A configuration setting has changed.
The application that worked perfectly yesterday is suddenly failing today!
The developer looks at the screen and says:
β€œBut it works on my machine!” 😭
If you have ever heard this sentence in software development, you already understand the problem we are solving today.
Welcome to Day 18 of our 30-Day Cloud Computing & Cloud Architecture Challenge!
Today, we will discover how containers and Docker help us package applications so they can run more consistently across different environments.
Let’s continue the journey of our college examination portal! πŸŽ“

🧩 1. The Problem: Why Does an Application Work on One Machine but Fail on Another?

Every application depends on more than just its source code.
It may require:
  • A specific programming language runtime, such as Python or Java
  • Particular software libraries and dependencies
  • Supporting tools and system packages
  • Configuration settings
  • A compatible operating environment
Imagine our college portal requires Python 3.12 and a particular version of a library.
The developer’s laptop has everything configured correctly. However, the cloud server has a different version of Python and an older library.
The result? Unexpected errors!
1
2
3
4
5
6
7
8
9
10
11
Developer's Laptop
|
| Application works! βœ…
|
v
Cloud Server
|
| Different dependencies ❌
|
v
Application fails!
The problem is not necessarily the application code. The environment in which the code runs may be different.
So, what if we could package the application together with its required dependencies?
What if we could create a consistent package and run it in development, testing, and production?
That is where containers enter the story. 🐳

πŸ“¦ 2. What Is a Container?

A container is an isolated environment in which an application runs with its required software dependencies and configuration.
Think of it like a carefully packed travel suitcase. 🧳
Before travelling, you pack your clothes, shoes, toiletries, and other essentials. You do not need to search for each item again at your destination.
Similarly, a container packages an application and the components it needs to run.
For our college examination portal, we might package:
  • The portal’s application code
  • Its language runtime
  • Required libraries
  • Application startup instructions
The application can then run in a compatible container environment without requiring the team to manually install every application dependency on each machine.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
πŸ“¦ Application Package

β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ College Portal Code β”‚
β”‚ Required Libraries β”‚
β”‚ Runtime Dependencies β”‚
β”‚ Startup Instructions β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
|
v
🐳 Container
|
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”
v v v
Testing Staging Production
Important: Containers improve consistency, but they do not eliminate every possible environment problem. Host operating system compatibility, configuration, permissions, networking, and external services can still affect an application.

🐳 3. What Is Docker?

Docker is a popular platform and ecosystem for building, distributing, and running containers.
Instead of manually preparing an application environment on every server, developers can define how the application should be packaged and use Docker tools to build and run it.
Let’s understand the three important terms you will hear repeatedly.

🧱 A. Dockerfile β€” The Recipe

A Dockerfile contains instructions for building a container image.
Think of it as a recipe. It tells Docker which starting image to use, which files to copy, which dependencies to install, and how the application should start.
For example, imagine our college portal has a simple Python application.
1
2
3
4
5
6
7
8
9
10
11
FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY . .

CMD ["python", "app.py"]
What does this Dockerfile do?
  • FROM selects a base image with Python.
  • WORKDIR sets the working directory inside the image.
  • COPY copies application files into the image.
  • RUN installs the required Python packages.
  • CMD defines the default command used to start the application.
This example assumes that requirements.txt and app.py exist and that the application is designed to start with that command.
In a real project, the team should also consider dependency pinning, a suitable .dockerignore file, non-root execution, secrets management, and image security.

πŸ–ΌοΈ B. Docker Image β€” The Blueprint

A Docker image is the packaged template used to create containers.
It contains the application files, dependencies, and filesystem layers required by the application.
Think of it like a cake recipe that has already been prepared into a reproducible package.
One image can be used to create multiple containers.
1
2
3
4
5
Docker Image
|
β”Œβ”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”
v v v
Container A B Container C
For example, we could create several containers from the same college portal image to handle application requests.
The containers would use the same image, while each running container would have its own runtime state.

▢️ C. Docker Container β€” The Running Application

A container is a running instance of an image.
Here is a simple way to remember the difference:
  • Dockerfile: Instructions for building the image
  • Docker image: The packaged application template
  • Docker container: The running instance created from that image
Let’s see it in action.
Build an image:
1
docker build -t college-portal .
Run a container:
1
docker run --name college-portal-app college-portal
These commands are illustrative. The application must be correctly configured to run in the container, and a real web application may also require port publishing, environment variables, networking, or other settings.
You have now seen the basic Docker workflow! πŸŽ‰

πŸ–₯️ 4. Containers vs Virtual Machines: What Is the Difference?

Yesterday, in Day 17, we explored monolithic applications and microservices. Before that, on Day 7, we learned about virtual machines and virtualization.
Now, a new question appears:
If virtual machines already let us run applications in isolated environments, why do we need containers?
Let’s compare them.

🏒 Virtual Machines

A virtual machine runs on virtualized hardware and normally includes its own guest operating system.
A hypervisor manages virtual machines and their access to the underlying hardware.
1
2
3
4
5
6
7
8
9
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ Physical Server β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚ Hypervisor β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚ VM 1 β”‚ VM 2 β”‚
β”‚ Guest OS β”‚ Guest OS β”‚
β”‚ Application β”‚ Application β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
Virtual machines provide strong isolation boundaries and can run different operating systems, subject to the hypervisor and hardware architecture.

🐳 Containers

Containers isolate applications and their processes while sharing the host operating system kernel.
They do not normally need a separate guest operating system for every application.
1
2
3
4
5
6
7
8
9
10
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ Physical Server β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚ Host OS β”‚
β”‚ Kernel β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚ Container 1 β”‚ Container 2 β”‚
β”‚ Application A β”‚ Application B β”‚
β”‚ Dependencies β”‚ Dependencies β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
Because containers share the host kernel, they are often faster to start and use fewer resources than comparable virtual machines. However, the actual resource usage depends on the workload and configuration.
A container is not simply a smaller virtual machine. The underlying isolation mechanisms are different.
FeatureVirtual MachineContainer
Operating systemUsually includes a guest OSShares the host kernel
Typical startupOften slowerOften faster
Resource overheadGenerally higherGenerally lower
Isolation modelVirtualized hardware and guest OSProcess and operating-system-level isolation
Common useRunning different OS environments and isolated workloadsPackaging and running applications consistently
Can containers and virtual machines work together?
Absolutely! In cloud environments, containers often run on virtual machines. For example, a container platform may schedule Docker containers on a fleet of EC2 instances.
This brings us to AWS. ☁️

☁️ 5. How Does Docker Fit Into AWS?

Docker helps us package the application. AWS provides services and infrastructure that can store, run, scale, and manage containerized applications.
Three important AWS services to know are:

πŸ“š Amazon ECR β€” Where Container Images Are Stored

Amazon Elastic Container Registry (Amazon ECR) is a managed container image registry.
Think of it as a secure warehouse for our college portal’s container images.
When the team builds a new version of the portal, it can push the image to ECR. An authorized container service can then retrieve that image to run the application.

πŸš€ Amazon ECS β€” Where Containers Are Managed

Amazon Elastic Container Service (Amazon ECS) is a managed container orchestration service.
It helps us deploy and manage containerized applications, including services that need multiple running tasks.
For example, our college portal could run several application containers behind a load balancer.

βš™οΈ AWS Fargate β€” Run Containers Without Managing the Underlying Servers

AWS Fargate is a serverless compute engine for containers that works with Amazon ECS and Amazon EKS.
With Fargate, AWS manages the underlying compute infrastructure for supported container workloads, so the team does not need to provision and manage the underlying EC2 instances for those tasks or pods.
Fargate does not remove the need to configure the application, networking, IAM permissions, monitoring, or scaling policies.
And what about Amazon EKS?
Amazon Elastic Kubernetes Service (Amazon EKS) is AWS’s managed Kubernetes service. It is another option for running and orchestrating containers, especially when a team wants to use the Kubernetes ecosystem.
For our beginner-friendly college portal, we can start with the simpler conceptual path of Docker, ECR, and ECS.

πŸ—οΈ 6. Our College Portal Architecture Evolves!

Remember our journey?
We started with a basic cloud application. Then we added databases, networking, IAM, load balancing, Auto Scaling, CloudFront, serverless processing, and asynchronous messaging.
In Day 17, we explored how a growing application might evolve from a monolith into microservices.
Today, we make another improvement: we package our application into a container image.
Here is the simplified deployment workflow.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
πŸ‘©β€πŸ’» Developer
|
v
Application Code
|
v
Dockerfile
|
v
Build Docker Image
|
v
Amazon ECR
Image Registry
|
v
Amazon ECS
Run Container Tasks
|
v
Application Load
Balancer
|
v
Students' Browsers
In a real architecture, the load balancer routes requests to a suitably configured ECS service. ECS manages the desired number of tasks, while the tasks run on a supported compute option such as AWS Fargate or Amazon EC2.
The architecture also needs networking, security groups, IAM roles, logging, health checks, and connections to the portal’s database and storage services.

🎯 What Have We Improved?

1. Consistent packaging
The team builds an image containing the application and its required dependencies.
2. Repeatable deployments
Testing and production can use the same versioned image, reducing differences caused by manually installing software.
3. Easier scaling
An orchestration service can run multiple copies of the containerized application when the workload requires more capacity.
4. More predictable releases
The team can identify and deploy specific image versions instead of relying on undocumented changes made directly on servers.
5. A foundation for microservices
Different services can be packaged and deployed independently when the application architecture benefits from that approach.
Remember, containers do not automatically make an application highly available. We still need suitable deployment, health-check, scaling, and failure-recovery configurations.

🧠 7. When Should We Use Containers?

Containers are especially useful when:
  • Developers need consistent application environments.
  • Applications must move between development, testing, and production.
  • A team wants repeatable deployment processes.
  • Multiple services need independent packaging and release cycles.
  • An application needs to run multiple instances across a cluster.
  • Teams want to use container orchestration tools such as Amazon ECS or Amazon EKS.
But containers are not the answer to every problem.
A small application may be perfectly fine running directly on a virtual machine. A serverless function may be a better fit for short, event-driven tasks. Containers also introduce responsibilities around image maintenance, vulnerability scanning, orchestration, and operational monitoring.
The goal is not to use the newest technology. The goal is to choose the right technology for the problem.

πŸ§ͺ 8. Your Day 18 Challenge

Imagine you are part of the team building our college examination portal.
The application works on the developer’s laptop but fails after deployment because the server has different software dependencies.
Your mission is to design a simple container-based deployment process.
Answer these questions:
  1. What information would you put in the Dockerfile?
  2. What is the difference between a Docker image and a running container?
  3. Where would you store the built image in AWS?
  4. Which AWS service could manage the containerized application?
  5. What additional configuration would you need to make the application secure and highly available?
Bonus challenge: Sketch the path from application code to a running container in AWS.
Share your architecture or answers in the discussion! πŸ’¬

πŸŽ‰ Final Thoughts: From Virtual Machines to Containers

Today, we learned that an application is more than just code. It also depends on a runtime, libraries, and a compatible environment.
Docker helps package these components into an image, and containers run instances of that image. On AWS, Amazon ECR can store our images, while Amazon ECS or Amazon EKS can orchestrate our containerized workloads.
Most importantly, we discovered that virtual machines and containers are not competitors that must replace one another. They solve related but different problems and are frequently used together.
Our college portal is becoming more portable, repeatable, and easier to deploy. But there is another challenge ahead.
We now know how to package an application into containers. How do we manage hundreds of containers, replace unhealthy ones, and keep the correct number running?
That is where container orchestration becomes important.

πŸ”₯ Coming Up: Day 19/30

Container Orchestration β€” How Does AWS Manage Hundreds of Containers?
We will explore Amazon ECS, Amazon EKS, container scheduling, service health, and scaling as our college portal grows.
Stay curious, keep building, and remember:
Great cloud architecture is not just about running an application. It is about making that application reliable, repeatable, secure, and ready to grow. β˜οΈπŸš€
#CloudComputing #AWS #Docker #Containers #AmazonECS #AmazonECR #AWSFargate #CloudArchitecture #30DaysOfCloud

Series: Cloud Computing (25 articles)

  1. …
  2. 19
    🐳 Day 18/30: Containers & Docker β€” How Do We Package an Application So It Runs Consistently Everywhere? ☁️ This article
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article