Set Up a Control Repository

Step Goals

After this part you will be able to

  • create and enable Users for SysEleven Code,
  • configure the settings on SysEleven Code for Multi-staging Pipelines,
  • create a control Repository in the style of SysEleven's Best Practice.

Introduction

To deploy Building Blocks to your Cluster, you’ll need a place where all configuration is stored. We use git repositories for that purpose.
This tutorial will show you how we recommend to structure a control repository - which is how we call the repositories that control the cluster state.

The tutorial focuses on the creation of a control repository on code.syseleven.de (or other GitLab instances). The steps taken that are specific to GitLab should be easily adaptable to other CI solutions, too.

Enabling SysEleven Login

Please refer to Cluster Authentication and create a Login Realm. Please state your wish to have it connected to SysEleven Code.
After your first Login to our Gitlab Instance wait for your permissions to be granted.

Project creation and settings

On code.syseleven.de, create a new project in your namespace, e.g. customer/myproject.
Please hold your prepared kubeconfig from the last step ready, which you want to use for the pipeline tasks.
There are two things to change in the repository settings (left menubar):

  • Disable the option „Skip Outdated deployment jobs“ in Settings → CI / CD → General Pipelines
  • Add the KUBECONFIG files for your cluster(s) in Settings → CI / CD → Variables (see picture underneath)
    • As Key, set KUBECONFIG
    • As Value, paste your base64 encoded KUBECONFIG file. This can e.g. be the Admin config you can download from metakube.syseleven.de
    • As Type, set File
    • As Environment Scope, set the environment the KUBECONFIG is for, e.g. development if it is the config for your development cluster. If you use one cluster for all environments, we recommend to use production.

Gitlab Sidebar

File structure

We recommend a parted structure when using a control repository. This means your root folder / will be populated with a file called .gitlab-ci.yml for global CI/CD definitions while all your Building Blocks and software will be handled in modules inside their own folder hierarchy. A possible structure could be:

/
└── syseleven-kube-prometheus-stack/
    ├── .gitlab-ci.yml
    ├── values-redis-ha-production.yaml
    ├── values-redis-ha-staging.yaml
    ├── values-redis-ha-development.yaml
    └── values-redis-ha.yaml
└── syseleven-redis-ha/
    ├── .gitlab-ci.yml
    └── ...
└── syseleven-ingress/
    ├── .gitlab-ci.yml
    └── ...
└── your_own_app_folder/
    ├── .gitlab-ci.yml
    └── ...
.gitlab-ci.yml

For now, you will need only a .gitlab-ci.yml file in your control repository. All other files will be added when deploying Building Blocks.

The Building Blocks need two stage definitions to work. diff is the stage for testing and validation tasks, while deploy takes care of the continuous deployment.
Copy the following to your .gitlab-ci.yml and you’re ready to deploy your first Building Block!

stages:
  - diff
  - deploy