Introduction

This repository is an example on how to build a Docker image and embed it as an Argo CD friendly Helm Chart for Catena-X NG.

Working with this repository

Conventional commits via pre-commit hook

Conventional commits are prepared for this repository but require manual steps after you have cloned this repository locally to your computer. The following is a possible solution based on node.js/npm. If you don't want to use that specific solution, there are several other toolings (based on go, python, php, bash, etc) listed here.

Prerequisites to use conventional commits:

• Node.js installed on your computer
• Execute npm install in repository root directory

After these steps you will get errors like this, when disrespecting conventional committing:

[feature/pre_commit_hook_conventional_commit][~/projects/cat-x/repos/k8s-helm-example]$ git commit -m "feat: Lalala"
⧗   input: feat: Lalala
✖   subject must not be sentence-case, start-case, pascal-case, upper-case [subject-case]

✖   found 1 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

husky - commit-msg hook exited with code 1 (error)

For further information about conventional committing, please refer to https://www.conventionalcommits.org/en/v1.0.0/#summary.

Example Application

The application we build for this example purpose provides a simple landing page for K8s cluster as cluster entry point and default backend. Therefore, we are leveraging nginx web server to serve static HTML content.

Folder Structure

Folder	Description
.github/workflows	Stores all GitHub relevant items like GitHub actions.
docker/*	Stores assets which are stored in docker image after build.
charts/*	Stores Helm Chart(s) which are used by Argo-CD to deploy this application on a K8s cluster.
html/*	Stores static HTML assets which are stored in docker image after build.

GitHub Workflows

This repository contains example workflows, that show some common tasks that you will need to take care of in your day-to-day work.

Check for conventional commits on pull request

When you create a pull request for this repository, a GitHub action will check if conventional commits were used. You should always check your commits as described above, which uses the same definitions. If you want to use this action, copy the file .github/workflows/commit-lint.yaml and place it in your repository's .github/workflows/ folder.

Docker build

A key step to get your application released and deployable, is to build a docker image for it. The necessary steps are executed in a docker build pipeline. Following steps are executed:

1. Check-out current branch content
2. Setup Docker build environment
3. Login the GitHub container registry
4. Extract metadata, build and push the Docker image to the registry
5. Sign the published Docker image

IaaS security scans with KICS

The iaas-security-scan workflow is running a static code analysis of IaaS. Our tool of choice for that is KICS. For repositories in our catenax-ng GitHub organization, it is mandatory to perform this kind of check, to comply with our quality gates. Findings will be present in the Security tab of your repository.

You can use the linked workflow 'as-is'. It is configured to run on changes the main branch and on a cron schedule.

You can find out more about IaaS security scans with KICS in our public documentation

Security vulnerability scans with trivy

The security-vulnerability-scans workflow is scanning your sources and your docker image for security vulnerabilities. This is done two jobs, that use trivy-action. For repositories in our catenax-ng GitHub organization, it is mandatory to perform this kind of check, to comply with our quality gates. Findings will be present in the Security tab of your repository.

To use this action, you need to adjust it slightly to your specific repository. The 'analyze config' job can be used 'as-is', since it is working on the repository, that was checked out at the beginning of the job. For the second job, which does the container image scanning, you need to adjust the image-ref property to the image name you are using for your container images. If you are building multiple images, you would need to add additional steps. You should also adjust the name of the container scanning job to your needs.

You can find more information about security vulnerability scans with trivy in our public documentation

Helm linting and testing

The helm-lint-and-test workflow will help you to comply with sane defaults of the helm community regarding your Helm charts.

It will run on every pull-request and provide you with feedback to your Helm chart. The chart-testing-action will lint your chart. This means, it will check your chart version and do schema validation on your Chart.yaml as well as your templates.

In a second step, a kind cluster will be created via kind-action. This cluster is then used to install your chart and run helm tests, that you defined in the templates/tests directory of your chart.

Helm chart release

The Release Charts workflow is used to package and release the helm charts defined in the /charts directory. It is using the chart-releaser-action to:

1. Package all the charts in the /charts folder
2. Creating a GitHub release with the packaged charts
3. Updating the index.yaml in the gh-pages branch. This file is needed to use GitHub pages as download source for the released chart.

You can use the workflow 'as-is', if you placed your charts in the /charts directory and have a branch called gh-pages. You can read more about how to release your helm chart in our public documentation

Helm Chart

For Catena-X open-source applications, we decided to use Helm as package manager for releases and deployments. This example repository contains a chart named k8s-helm-example to describe the deployment of our example application. We also release the k8s-helm-example chart, so we can use it as dependency in some other Helm charts.

Furthermore, we are using the Helm chart to deploy our example application via Argo CD to multiple kubernetes clusters. We achieve this, by providing multiple cluster/environment specific value-<env>.yaml file with our Helm chart. You can find out more about Catena-X Helm best practices in our public documentation.

Argo CD

Within Catena-X NG, Argo CD is used to deploy cloud applications to kubernetes clusters.

Argo CD is a cloud native GitOps tool running in a kubernetes cluster and monitoring Git repositories containing kubernetes deployment configuration. There are multiple possibilities, how you can define your kubernetes deployments, but we are focussing on deploying Helm charts via Argo CD.

To enable Argo CD to deploy your Helm chart, you need to create an Argo CD application

The following manifest shows an example, that will deploy the application defined in this repository.

project: default
source:
  repoURL: 'https://github.com/catenax-ng/k8s-helm-example.git'
  path: chart/k8s-helm-example
  targetRevision: main
destination:
  server: 'https://kubernetes.default.svc'
  namespace: k8s-helm-example
syncPolicy:
  automated: {}
  syncOptions:
    - CreateNamespace=true
    - Replace=true

A deployed application in Argo CDs web UI could look like the following:

You can find out more on how to deploy applications with Argo CD to Catena-X consortia kubernetes clusters in our public documentation. Additional documentation for specific challenges you may face can be found in our public documentation under the Base guides section.