Repository files navigation

LightDevOps is a universal GitLab CI/CD pipeline as an easier alternative toGitLab's Auto DevOps. It automatically builds, tests and deploys the applicationto the Kubernetes cluster, only a Dockerfile and a Helm chart is needed.

In the Gitlab project, assuming that the Dockerfile is in the repository, Helmchart is in the./chart directory and theKubernetes clusteris also connected.

InSettings ->CI/CD -> underGeneral pipelines tab, set the path to theCI/CD configuration file:

https://lightdevops.cze.tech/cicd/gitlab-kube-BA-TA-DA.yaml

InSettings ->Repository -> underDeploy tokens tab,create a token with namegitlab-deploy-token and atleastread_registry scope.

Optionally set variableTEST_UNIT_COMMAND with docker image command that runsunit tests.

The next commit creates a pipeline that builds, tests and (in the case of thedefault branch) deploys the application to the Kubernetes cluster. To deploy onthe manual trigger, useDM instead ofDA in the URL.

Customization is done by CI/CD variables.

For an explanation of working with environments, seeEnvironments.

IfBUILD_ENVIRONMENTS is set totrue, all other variables are withinthe scope for the environment.

IfBUILD_ENVIRONMENTS is set totrue, all variables except forTEST_PRECOMMIT_ENABLEDare withinthe scope for the environment.

All variables are withinthe scope for the environment.

There are variants which define default values forvariablesBUILD_ENABLED,TEST_ENABLED andDEPLOY_ENABLED defined by letters infilename of CI/CD configuration file. Base variant without default values is:

gitlab-kube.yaml

and variant with enabled automatic build is:

gitlab-kube-BA.yaml

All available variants:

It is not possible to define a default value for the next stage without theprevious one, e.g. forTEST_ENABLED withoutBUILD_ENABLED.

There are two predefined environments,prod as a production environment andstag as a staging environment. ThevariablesENVIRONMENT_<0_to_9>_NAME can be used to define another 10 environments.

Deployment jobs are created for all defined environments. Creating a deploymentjob for certain environment only, e.g. production environment, is possible bysettingDEPLOY_ENABLED only forprod environment. In the case of the variantwith enabled deployment by default, it is possible to setDEPLOY_ENABLED withthe valuefalse (or anything instead ofauto andmanual) forstagenvironment.

The usual setup is automatic deployment to the staging environment and manual tothe production environment so it is possible to use the-BA-TA-DMvariant and setDEPLOY_ENABLED toauto forstag environment.

WithBUILD_ENVIRONMENTS it is possible to create separate build and test jobsfor each environment. This can be used when the environment settings aredirectly in the builded image (e.g. PWA or mobile applications).

Some values must be possible to set in the Helm chart, but these are standardconventions, so it is assumed that the chart does not need to be modified. Ifnecessary, it is possible to change keys that set these values with CI/CDvariables.

• When the deploy job failed witherror: You must be logged in to the server (Unauthorized) it is necessary inthe affected GitLab managed cluster, underAdvanced settings tab, clickClear cluster cache.

The application itself is a static web page where the CI/CD pipelines are in thecicd directory.

Requirements:

• Make
• pandoc
• gomplate

Build is done with:

make

then the output is in the./build/web directory.

The Dockerfile and Helm chart are also part of this repository so it can beeasily build and deployed to Kubernetes (e.g. from GitLab by the LightDevOpspipeline itself).

Run the image from Docker Hub:

docker run -p 80:80 czetech/lightdevops

Setup Helm repository:

helm repo add czetech https://charts.cze.tech/

Install Helm chart:

helm install lightdevops czetech/lightdevops \  --set ingress.enabled=true \  --set ingress.hosts[0]=<ingress-host>

see thechart for more options.

The source code is available athttps://github.com/czetech/lightdevops.