Integrating Containers into Your CI/CD Pipeline using Github Actions

Integrating containers into your CI/CD (Continuous Integration/Continuous Deployment) pipeline is no longer just an option but a necessity in modern software development. Developers now have powerful tools available to simplify their development processes and improve the scalability and reliability of their applications using containerization technologies such as Docker, Inc and Kubernetes . Containers encapsulate an application's dependencies and runtime environment, ensuring consistency across different environments, from development to production.

In this article, we'll explore the vital role containers play in optimizing CI/CD workflows, allowing for faster development cycles and more efficient delivery of software. You can automate the building, testing, and deployment processes, reducing the risk of errors and improving the overall quality of your software by integrating containers into your CI/CD pipeline. We'll discuss practical strategies and best practices for using containers within your pipeline, empowering you to make the most of containerization to speed up your software delivery lifecycle.

This article is the last part of my Docker Series. I've discussed about:

1. A beginner's guide to containerization
2. Creating custom Image of your application
3. Optimizing your multi-container application using Docker Compose

Check out my other writings on my medium! Now let's jump in:

1. What is CI/CD pipelines?
2. The benefits of CI/CD
3. Basic syntax of Github Actions
4. CI/CD workflow using Github Actions for containerization
5. Conclusion
6. Recommended resources

What is CI/CD pipelines?

CI/CD pipelines refers to the series of step of your code from development environment, to testing and staging, production, and finally in the user's hand. CI/CD aims to minimize the human error and maintain consistent process of how software is delivered by automate the whole process. CI/CD stands for Continuous Integration (CI) and Continuous Delivery or Continuous Deployment (CD).

Continuous Integration (CI) is a practice in software development where team members frequently integrate their code changes into a shared repository. Each integration is verified by automated build and tests to detect integration errors as quickly as possible. The primary goal is to ensure that the codebase is always in a working state, even with multiple developers working simultaneously. This process helps to detect and address conflicts or issues early on, reducing the chances of integration problems and making it easier to maintain and enhance the software over time.

Continuous delivery and continuous deployment is the next process after continuous integration. It automates into the next stages of the pipelines. Continuous delivery involves the automated deployment of verified code to a repository after automating builds and conducting unit and integration testing as part of CI. Therefore, for a continuous delivery system to function effectively, it's crucial to have CI integrated into your development pipeline from the outset. The final stage of CI/CD pipeline is continuous deployment. The difference between continuous delivery and continuous deployment is continuous delivery automates the process of preparing code changes for release, while continuous deployment automates the entire process, including the deployment to production, without manual process.

The benefits of CI/CD

1. increased efficiency: automation reduces manual errors and repetitive tasks, allowing developers to focus on writing code and delivering value to customers instead of managing deployment processes
2. improved quality: continuous integration ensures that code changes are regularly integrated and tested. It helps us catching bugs and issues early in the development process. Continuous delivery and deployment automate testing and deployment, improving software quality and reliability
3. enhanced collaboration: CI/CD encourages collaboration among team members by providing a centralized repository for code changes and ensuring that everyone is working with the latest version of the codebase
4. reduced risk: automated testing and deployment processes help mitigate the risk of introducing bugs or errors into production environments
5. scalability: CI/CD pipelines can easily scale to accommodate growing development teams and projects. It allows organizations to maintain productivity and efficiency as they expand

Basic syntax of Github Actions

GitHub Actions is a powerful tool for implementing CI/CD workflows directly within GitHub repositories. It allows developers to automate their software development workflows, including building, testing, and deploying applications, all within the GitHub platform. You can define custom workflows using YAML syntax directly within your repository. GitHub Actions provides a wide range of pre-built actions and integrations with popular development tools. Some basic syntax of Github Actions are:

1. name: specify your workflow's name to identify within your repository
2. on: Specifies the event or events that trigger the workflow. For example, push triggers the workflow when code is pushed to the repository, while pull_request triggers it when a pull request is opened or updated
3. branch: specify which branch that'll triggers the workflow when an event occurs
4. jobs: jobs are the individual units of work within a workflow. You can define one or more jobs. Each jobs have its own steps to execute. You can also named your job by directly specify the name
5. runs_on: specifies the type of runner environment where the job will execute, such as ubuntu-latest or windows-latest
6. steps: steps define the sequence of actions to be performed within the job. Each step typically corresponds to a specific action, command, or script to execute
7. uses: specifies the action to be executed within the step. Actions can be from the GitHub Marketplace, other repositories, or Docker containers
8. with: provides input parameters or configuration options for the action being executed. You can specify your environment variables here

CI/CD workflow using Github Actions for containerization

For context, my project is a REST API for a florist online shop. I deploy my project in a Virtual Private Server (VPS). I set my workflow into two jobs, build and deploy. The build job is used to update my Docker Image in the Docker Hub. While the deploy job is used to update the latest image in my VPS and run compose to update the deployment. Here's my Github Actions workflow:

name: CI/CD Pipeline
on:
  push:
    branches:
      - "master"

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v1

      - name: Login to Docker Hub
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKER_HUB_USERNAME }}
          password: ${{ secrets.DOCKER_HUB_ACCESS_TOKEN }}

      - name: Build and push Docker image
        uses: docker/build-push-action@v5
        with:
          context: .
          file: ./Dockerfile
          push: true
          tags: ${{ secrets.DOCKER_HUB_USERNAME }}/florist-backend:latest

  deploy:
    runs-on: ubuntu-latest
    needs: build
    environment: production
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Install SSH client
        run: sudo apt-get install -y openssh-client

      - name: Install sshpass
        run: sudo apt-get install -y sshpass
      
      - name: SSH into VPS
        run: |
          sudo sshpass -p "${{ secrets.VPS_PASSWORD }}" ssh -o StrictHostKeyChecking=no ubuntu@${{ secrets.VPS_IPV4 }} "echo 'Logged in to VPS successfully'"
      
      - name: Move into the repository and pull the lastest version
        run: |
          sudo sshpass -p "${{ secrets.VPS_PASSWORD }}" ssh -o StrictHostKeyChecking=no ubuntu@${{ secrets.VPS_IPV4 }} 'sudo docker pull ystnysn/florist-backend:latest'
      
      - name: Docker compose
        run: |
          sudo sshpass -p "${{ secrets.VPS_PASSWORD }}" ssh -o StrictHostKeyChecking=no ubuntu@${{ secrets.VPS_IPV4 }} 'cd backend/florist-gin; git checkout master; eval "$(ssh-agent -s)"; ssh-add ~/.ssh/githubvps; git pull origin master; sudo docker-compose up'

            

I specify the event to triggers my CI/CD is push into the branch master. I also use SSH Client and sshpass to login into my VPS. The sshpass needs to run everytime you run a command. You can debug your workflow by create a new step or command. The secrets variables can be configured in the settings of your repository > security > secrets and variables > actions

My CI/CD pipelines can't be successful because the pipes of SSH is broken. But it's okay because it has completed all the steps. As long as the log already says it listens to the final port then it's fine

Conclusion

In this article, we discuss the importance of integrating containers into CI/CD pipelines for modern software development. Containers encapsulate application dependencies and runtime environments, ensuring consistency across different environments. By integrating containers into CI/CD pipelines, developers can automate building, testing, and deployment processes, resulting in faster development cycles and more efficient software delivery. We explore the basic syntax of GitHub Actions and provide a CI/CD workflow example for containerization. The CI/CD workflow successfully completes all steps despite encountering issues with SSH pipes.

Recommended resources

1. What is CI/CD?
2. CI/CD explanation by Gitlab
3. Introduction of Github Actions by Docker
4. Github Actions documentation

I hope this article has provided valuable insights into streamlining software development processes and accelerating delivery cycles. Stay tuned for more upcoming writings. I'm also looking for any collaboration in backend related project. Please don't hesitate to approach me. Thank you for joining me on this journey, and I look forward to sharing more insights with you soon.