Workshops in the cloud – what Ansible, Docker and the GitLab CI/CD offer you

As an open source program, Ansible is used for configuration management and the automation of administration tasks. It is characterized by a strict separation of code and parameters. The aim is to map infrastructure as code. By following the best practice guidelines, idempotence is guaranteed at all times.

This means that only incorrectly configured files are handled. The valid configuration is queried, but remains untouched after checking. This saves resources and time. Another advantage of Ansible is the wealth of modules provided for cloud, databases, package management and much more. Ansible is therefore predestined as a tool for the automated orchestration, configuration and administration of IT systems to set up the IT necessary for a training operation.

In the training courses we offer, the infrastructure is set up shortly before the workshop begins. This will then be in use for a few days and will be automatically deleted after the workshop. Because of this short-lived nature, we opted for a cloud-based solution. Version management is carried out using Git. Source files can be viewed directly on the web interface of our GitLab installation, so that the GitLab CI/CD is suitable for VM provisioning. When the GitLab Pipeline starts, the following gitlab-ci.yml file is initially read into the Git repository.

 stages:
  - command
  - only_after_setup
 
.command: &command
  stage: command
  tags:
    - docker
  image:
    name: atix-registry.infra.dev.atix/ansible_hcloud:latest
    entrypoint: ["sh", "-c"]
  script:
    - ansible localhost -m template -a "src=requirements.yaml.j2 dest=requirements.yaml"
    - ansible-galaxy install -r requirements.yaml
    - ansible-playbook --tags "$CI_JOB_NAME" ${VERBOSE:+-vvv} playbook_basic.yaml
    etc.
  when: manual
 
cleanup:
  <<: facts:="" setup:="" artifacts:="" paths:="" artifact.tar="" expire_in:="" week="" workshop:="" stage:="" only_after_setup="" tags:="" docker="" image:="" name:="" atix-registry.infra.dev.atix="" entrypoint:="" dependencies:="" setup="" script:="" tar="" ansible="" localhost="" template="" dest="requirements.yaml"" ansible-galaxy="" install="" requirements.yaml="" ansible-playbook="" hcloud.py="" playbook_workshop_specific.yaml="" when:="" manual="" wpml:html_fragment=""> --></:>

• “cleanup” deletes all VMs and domains of the respective training (e.g. Ansible, Kubernetes)
• “facts” shows all set up VMs, HCloud options (VM sizes, locations, volumes, etc.) and domains along with their properties
• “setup” triggers the provisioning of the workshop infrastructure, whereby Ansible tasks are carried out that are relevant for all training courses (e.g. firewall, SSH, domains)
• “workshop” is executed after “setup” in its own GitLab CI/CD stage and adapts the infrastructure to the requirements of the respective training. Additional software is installed and configured (e.g. kubectl for Kubernetes training) that is not required for other training courses (e.g. Ansible training).

Regardless of the job chosen, a Docker container is created, the required Ansible Galaxy roles are loaded into it and the Ansible playbook is executed to create the cloud resources. In the case of a setup, in one of the last steps the SSH configuration is made available to the training participants as a download on a password-protected web server (TLS secured with Let’s Encrypt certificates). For security reasons, USB sticks and sending as email attachments are deliberately avoided.

---
https://k8s.example.org
├── group0-roadwarrior
│   ├── .ssh
│   │   ├── config
│   │   ├── id_rsa
│   │   ├── id_rsa.pub
│   │   └── known_hosts
│   └── ssh.sh
├── group0-roadwarrior.tar
├── group0-roadwarrior.zip
├── group1-roadwarrior
│   ├── .ssh
│   │   ├── config
│   │   ├── id_rsa
│   │   ├── id_rsa.pub
│   │   └── known_hosts
│   └── ssh.sh
├── group1-roadwarrior.tar
└── group1-roadwarrior.zip
```