CI/CD
6 min read

From Docker Image to Automated Deployment: My CI/CD Learning Journey

How building a Docker-based GitHub Actions pipeline helped me understand CI/CD, container images, Docker Hub, EC2 deployment, secrets, and automation.

Before learning CI/CD, deployment felt like a sequence of commands that had to be repeated manually.

1. Build the application.
2. Create the Docker image.
3. Push it somewhere.
4. Connect to the server.
5. Pull the new image.
6. Restart the application.

Learning GitHub Actions helped me understand how many of these repetitive steps can be connected into an automated workflow.

Why I Started Learning CI/CD

As I continued learning DevOps, I realized that knowing Docker alone was not enough.

I wanted to understand what happens after code is pushed to Git.

That led me to CI/CD.

The basic workflow I wanted to understand was:

GitHub → GitHub Actions → Docker Build → Docker Hub → EC2 → Application

This simple pipeline became one of my practical learning projects.

Docker as the Deployment Unit

I used Docker to package the application and its runtime environment into a container image.

Instead of thinking about deployment as copying application files manually, I started thinking about creating a consistent artifact that could be deployed to a server.

The basic process was:

  1. Build the Docker image.
  2. Tag the image.
  3. Push the image to Docker Hub.
  4. Make the server pull the required image.
  5. Run the updated container.

This made the deployment process more predictable.

Introducing GitHub Actions

GitHub Actions allowed me to define the CI/CD workflow inside the repository.

The workflow could respond to changes in the repository and perform automated steps.

The concept became much easier to understand when I could see the pipeline execute instead of only reading about CI/CD.

The general flow looked like:

Git Push
↓
GitHub Actions
↓
Build Docker Image
↓
Push Image to Docker Hub
↓
Connect to EC2
↓
Pull New Image
↓
Restart Container
↓
Updated Application

Secrets and Credentials

Another important lesson was understanding that credentials should not simply be written directly into the workflow file.

For example, Docker credentials and server-related secrets should be stored using GitHub's secrets mechanism rather than committed into the repository.

"Automation should not come at the cost of security."

What Went Wrong

The first pipeline was not perfect.

One of the biggest practical lessons came when the workflow expected an EC2 server to be available, but the test server had already been terminated.

The pipeline configuration itself was not enough.

The infrastructure it depended on also had to exist and be reachable.

That helped me understand an important distinction:

CI/CD automation depends on infrastructure.

A pipeline can be correctly configured and still fail because the target environment is unavailable, credentials are incorrect, networking is blocked, or the application environment has changed.

What I Learned

Building this pipeline helped me understand several concepts together:

  • Docker images & Docker Hub
  • GitHub Actions & Workflows
  • SSH-based EC2 deployment
  • GitHub Secrets & Security
  • Deployment dependencies
  • Troubleshooting pipelines

More importantly, I started understanding why automation matters.

Instead of manually repeating the same deployment steps, the goal is to turn those steps into a reliable and repeatable process.

What's Next

I'm continuing to improve this workflow by learning Terraform, better AWS infrastructure design, monitoring, Kubernetes, and more advanced CI/CD practices.

My long-term goal is to build deployment systems where infrastructure and application delivery can be managed through reproducible automation rather than manual commands.

For me, CI/CD is not just about writing a YAML file.

It is about understanding the complete path from:

Code → Build → Artifact → Infrastructure → Deployment → Running Application

That is the part of DevOps I am currently learning and building toward.