Github Actions

In the last week, I continued my Cloud Natives Foundation course, I learned about Continuous Integration, Github Actions, and Cloud Computing offerings (Iaas, Paas, Faas). I also learned a bit about Cloud Foundry - a Paas offering.

Cloud Computing Services

Kubernetes offers functionalities that provide automation, portability, extensibility, flexibility, self-healing, etc. An application release needs to be carried out in the sandbox, staging and production environments, which in turn represent three Kubernetes clusters. In addition, an application is usually replicated across multiple regions to deliver a service to consumers with minimal latency. Therefore, the number of Kubernetes clusters would scale exponentially.

All these clusters would need to be configured, managed, upgraded and deployed.

An organization would need to dedicate a team to manage these clusters. In the case, that an organization cannot maintain these resources on their own, cloud computing services become essential. Examples of such services include:

Platform as a service (Paas)

Infrastructure as a service (Iaas)

On-Premise Services

Function as a service (Faas)

Unlike Cloud Foundry (a Paas offering), deploying an application with Kubernetes is manual and not sustainable. There is a need to build a delivery pipeline. A delivery pipeline will ensure that changes to an application can be deployed quickly.

The delivery pipeline consists of continuous integration (to build, test and package applications) and continuous delivery (deploying an application). The packaged application will be tested in the sandbox, staging will be used to simulate the production environment and then the package will be deployed to production manually.

Continuous Integration

Continuous integration means that a team merges with the master branch multiple times a day. There is a fully automated build and test process, however, the deployment process is manual.

Build stage - The application code is compiled along with its dependencies. For example, in a docker file, the following would represent the build stages:

# use pip to install any application dependencies
RUN pip install -r requirements.txt

# execute command  on the container start
CMD [ "python", "app.py" ]

Test stage - the application goes through testing to ensure that the application works as intended. For example, in Python, you could use the frameworks pytest and pylint for testing.

Package stage - The application code is compiled into a container image. For example, with docker you would run the following commands:

# build an image using a Dockerfile
docker build -t python-helloworld .

# store and distribute an image using DockerHub
docker push pixelpotato/python-helloworld:v1.0.0

There are many tools that can be used to automate continuous integration stages in an application such as Jenkins, CirlceCI, Concourse, Spinnaker, etc. In the past week, I got to try out Github Actions to build, test and package an application. Some teams at RH also use Github Actions to automate continuous integration.

Github Actions

Github action is an event-driven workflow that can be configured to execute when a new commit is made or a similar event occurs (e.g. a pull request, someone opens a new issue, etc.).

Once a commit is made, the developer can receive immediate feedback on whether it passed the quality check. This is implemented in a YAML file and placed in a folder called .github/workflows/.

I tested building and pushing a docker image for a Python web application. I began by adding the .github/workflows folders to my local repository:

$ mkdir -p /.github/workflows

Then I added the following YAML file. I got the file from Github and made some changes:

## workflow to build and push docker image for a python web ## application
name: Docker Build and Push

# event should be triggered on push and pull requests
on:
  push:
    branches:
      - 'main'
  pull_request:
    branches:
      - 'main'

# A workflow run is made up of one or more jobs that can run #sequentially or in parallel
jobs:
  docker:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest
    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      -
        name: Checkout
        uses: actions/checkout@v3
      -
        name: Set up QEMU
        uses: docker/setup-qemu-action@v2
      -
        name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v2
      -
        name: Login to DockerHub
        uses: docker/login-action@v2
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}
      -
        name: Build and push
        uses: docker/build-push-action@v3
        with:
          context: .
          file: ./Dockerfile
          platforms: linux/amd64
          push: true
          tags: gotirh/python-helloworld:latest

This YAML consists of the name of the workflow which is Docker Build and Push. The workflow is set to run when push or pull requests are triggered. The job will run on the latest version of ubuntu. And it will perform the following steps:

• Check out the current branch on Github,

• Set up QEMU (to enable the execution of different multiarchitecture containers)

• Set up Docker BuildX ( to use extended Docker CLI build capabilities)

• Log in to Docker Hub (using account credentials that are entered in the Git repository)

• It will build and push the docker image with the tag (gotirh/python-helloworld:latest) using instructions from my Dockerfile

To include secrets in my Github repository, I navigated to settings > security > Secrets > New repository secret. I added my docker hub username and password.

Finally, I pushed the repository along with the .yml file to Github. The build failed initially because I needed to extend my Github Personal Access Token to include workflows. Once I enabled it, the build was successful and the docker image was pushed to my docker hub account.

Lessons

I found it very interesting to see how you could automate the process of building and pushing a repository to a docker hub account. You could also test your code before merging to a master branch all on Github! And all of these are the reasoning behind continuous integration!

This week I am looking forward to completing the Cloud Natives Foundation course. I am also looking forward to trying out more use cases of Github Actions.