🎨 CI/CD Workflow with AWS and Docker

🎨 CI/CD Workflow with AWS and Docker

Introduction

Hello, I’m Take, an engineer working at a product development company in Tokyo.

In this article, I will illustrate the overall structure of a CI/CD workflow utilizing AWS ECR/ECS, Docker, and GitHub Actions. I won’t delve into specific setup steps but will focus on how these technologies are integrated and provide a visual explanation.

Key Technologies Used

VSCode: Editor for coding
GitHub Actions: Automates builds and tests upon code changes
Docker: Tool for containerizing applications
AWS ECR (Elastic Container Registry): Manages Docker container images
AWS ECS (Elastic Container Service): Manages containers and orchestrates them

Overall Process (tool:Excalidraw)

Developers make changes in VSCode and push them to GitHub.
GitHub Actions triggers, executing builds and tests, and uses Docker to create container images.
These images are stored in AWS ECR and then deployed via AWS ECS.

Detailed Explanation by Part

From Code Push to GitHub Actions

Developers push changes from their local branch to the GitHub repository with the following commands:

git add .
git commit -m “commit message”
git push origin HEAD

This triggers GitHub Actions, which automatically performs builds and tests, during which Docker creates a container image.

From GitHub Actions to AWS ECR

Once the build and tests succeed, the Docker image is uploaded to AWS ECR.

Think of ECR as a service that manages Docker images, offering secure access control and private networking. It’s a vital part of automating and securing the workflow from development to deployment.

From AWS ECR to ECS

The Docker image saved in ECR is then pulled by ECS, executing necessary initializations through an entrypoint.sh script.

“Pull” refers to the process of ECS retrieving container images from the ECR to start containers, managing applications with precise version control.

From ECS to Application Deployment

This section focuses on the concept of “kick,” which in ECS terms, means a specific task has started running.

It’s a step where the new task instances are launched based on task definitions, deploying the container images as live containers, ensuring the application operates as expected.

Conclusion

Thank you for reading this far! If you enjoyed this article, I’d really appreciate it if you could give it a ‘Like’ 🎉

Please follow and like us:
Pin Share