You have a containerized solution. You build it, deploy it, update it, and maintain it. Basically, you are managing the lifecycle. Unfortunately, you are doing that manually. This will work for a single container, maybe two. But imagine having 15 different container images to maintain! That is a lot of clicking and typing! The solution?
GitHub Workflows and Actions
GitHub Workflows and Actions are two Github features that enable users to automate tasks and workflows for their software development projects. They can help users save time, improve quality, and collaborate more effectively. So it sounds like a solution for our manual tasks!
A GitHub Workflow is a set of rules that defines when and how a certain action should be triggered. For example, a workflow can run tests, build code, deploy applications, or send notifications whenever a new commit is pushed, a pull request is opened, or a scheduled event occurs. A solution that is a wonderful addition to your Cloud Native Azure estate.
A GitHub Action is a reusable unit of code that performs a specific task within a workflow. For example, an action can check out a repository, install dependencies, run a script, or upload an artifact. Actions can be written in any programming language and can use any tool or framework. Actions are either created by GitHub, by the community, or by the users themselves. Actions are stored in repositories and can be referenced by workflows using the syntax owner/repo@ref.
Some of the benefits of using GitHub Workflows and Actions are:
One use case of GitHub Actions is automating the workflow of building, scanning, patching, pushing, and deploying containers. This can help developers streamline the process of delivering secure and reliable containerized applications to their customers.
Step 1: The first step is to create a Dockerfile that defines how to build the container image for the application. The Dockerfile specifies the base image, the dependencies, the commands, and the environment variables for the container. The Dockerfile should be stored in the repository along with the source code of the application.
Step 2: Next is to create the workflow. To create a GitHub workflow file that defines the steps to execute when certain events occur in the repository (such as a push or a pull request) the workflow file is written in YAML and stored in the repository's .github/workflows directory. The workflow file can specify the triggers, the jobs, the runners, and the actions for the workflow.
Step 3: The third step is to use GitHub Actions to build the container image from the Dockerfile. This can be done using the docker/build-push-action action, which can build and tag the image, log in to a container registry, and push the image to the registry. The action can also cache the image layers to speed up the subsequent builds. The action requires some inputs, such as the name of the image, the context directory, the Dockerfile path, and the registry credentials.
Step 4: Now we want to scan our container images for vulnerabilities; we will use Trivy. Scan the container image with Trivy, a tool that can detect vulnerabilities in the image. This can be done using the aquasecurity/trivy-action action, which can run Trivy on the image and generate a vulnerability report. The action can also fail the workflow if the image has critical or high-severity vulnerabilities. The action requires some inputs, such as the name of the image and the severity level, to fail.
Step 5: When vulnerabilities are detected, we want to patch the image (don’t forget to fix the vulnerability in the code for your next release!). To patch the image, we use Copa, a tool that can apply patches to the image without rebuilding it. This can be done using the copa/copa-action action, which can run Copa on the image and create a patched image. The action can also push the patched image to the registry. The action requires some inputs, such as the name of the original image, the name of the patched image, and the credentials for the registry.
Step 6: And finally, it is time for a deployment. This can be done using the Azure/k8s-deploy action, which can deploy the image to a specified AKS cluster and namespace. The action can also create or update the Kubernetes resources, such as deployments, services, and secrets. The action requires some inputs, such as the name of the image, the name of the cluster, the name of the namespace, and the credentials for the cluster.
Hopefully, the above helped you clarify the theme of Github Workflow and Actions. We provided the benefits and how it could serve you, as well as a use case that illustrated the steps to be taken. We understand that it appears to involve numerous steps. But don't worry about that!
Should you be interested in building and deploying a similar solution and need some assistance, we are here for you.
We can help you kickstart that experience and provide out-of-the-box example workflows ready to fine-tune. Feel free to reach out any time. Our experts are here for you to help!
Learn everything about Github Security in our newest e-book!
Download the e-book