BACK
When managing applications across different environments (such as development, QA, and production), maintaining separate Dockerfiles and start commands for each environment can become inefficient and hard to scale. In our CloudFront, ALB, and ECS setup with a three-tier architecture, we faced similar challenges, prompting us to optimize our deployment strategy.
Having separate Dockerfiles for each environment became cumbersome, especially when working with different AWS accounts and ECR repositories for each environment. We needed a more efficient solution to avoid redundancy and improve scalability.
Challenge:
We were using different ECR repositories for each environment due to separate AWS accounts. As a result, each environment had a hardcoded FROM line in its respective Dockerfile, pointing to the specific ECR repository.
Solution:
To solve this, we refactored the Docker build process to use a single Dockerfile across all environments. Instead of hardcoding the ECR repository in each Dockerfile, we passed the repository as an argument via the Buildspec file.
Before:
The Dockerfile had a hardcoded ECR repository for each environment:
FROM 123456789.dkr.ecr.eu-central-1.amazonaws.com/backend:node-16After:
We removed the hardcoded repository and passed the base image as a build argument. The Dockerfile now dynamically receives the base image from the build process:
ARG BASE_IMAGE
FROM ${BASE_IMAGE} as baseBuildspec Changes:
The Buildspec file was updated to pull the base image dynamically:
env:
parameter-store:
BASE_REPOSITORY: "BASE_REPOSITORY"
BASE_IMAGE_TAG: "BASE_IMAGE_TAG"phases:
pre_build:
commands:
– BASE_IMAGE=$AMAZON_ACCOUNT_ID.dkr.ecr.$AMAZON_DEFAULT_REGION.amazonaws.com/$BASE_REPOSITORY:$BASE_IMAGE_TAG
– docker pull $BASE_IMAGE
build:
commands:
– docker build –build-arg BASE_IMAGE=$BASE_IMAGE -t $IMAGE_REPO_NAME:$IMAGE_TAG .
This refactor allowed us to use a single Dockerfile across environments, significantly reducing complexity.
Challenge:
Each environment had different start commands (npm run start:dev, npm run start:qa, etc.), which required multiple Dockerfiles for each environment to define the correct CMD instruction. This was not scalable.
Solution:
To address this, we removed the CMD instruction from the Dockerfile and moved the start command to the ECS Task Definition. This allowed us to define the appropriate start command for each environment at the ECS level, using the same Docker image across environments.
Before:
The Dockerfile had an environment-specific CMD:
FROM 123456789.dkr.ecr.eu-central-1.amazonaws.com/backend:node-16
..
..
..
CMD ["npm", "run", "start:dev"]After:
We removed the CMD line, leaving the Dockerfile agnostic of the environment-specific start command:
ARG BASE_IMAGE
FROM ${BASE_IMAGE} as base
..
..
..
# Removed CMD from the DockerfileInstead, the ECS Task Definition specified the start command:
"containerDefinitions": [
{
"name": "backend-container",
"command": ["npm", "run", "start:dev"]
}
]This change allowed us to eliminate redundant Dockerfiles and ensured each environment could use the same Docker image with the appropriate start command.
Explore More
Experience the power of our cutting-edge technology firsthand
© 2025 TRINGAPPS, INC. ALL RIGHTS RESERVED
