Von 0 auf Kubernetes - Aufbau einer Kubernetes-CI/CD-Infrastruktur per GitLab-Pipeline - Teil 4 - Das GitLab Playbook

Ansible, Terraform, GitLab und etwas Magie: Wie ich eine ganze Infrastruktur auf Knopfdruck erstelle.

In dieser Serie möchte ich euch zeigen, wie ihr automatisiert ein Kubernetes-Cluster aufbaut, ein GitLab mit GitLab-Runner installiert und eine eigene Docker-Registry zur Verfügung stellt. Das Ziel wird sein, dass ihr eure Anwendungen direkt aus dem GitLab heraus in eurem Cluster bauen und starten könnt.

Im vierten Teil dieser Serie erstellen wir ein Ansible-Inventory und schreiben mit dem Ansible-Playbook unsere erste ausführbare Einheit.

Rückblick

Im dritten Teil haben wir uns eine zweite Ansible-Rolle erstellt, die unsere docker-compose.yml aus dem zweiten Teil auf das Zielsystem kopiert und startet. Außerdem erstellten wir ein API-Token für GitLab, welches wir in einem späteren Teil für weitere Konfigurationen benötigen. 

Unser Ziel für diesen Teil

In diesem Teil erstellen wir ein Ansible-Inventory, in welchem wir unsere genutzten Server/VMs definieren, und schreiben unser erstes Ansible-Playbook, welches unsere beiden bisher geschriebenen Ansible-Rollen nutzt und damit die benötigten Services (GitLab, Traefik, Docker-Registry) starten kann.

Das Inventory

Um die genutzten Server besser verwalten zu können, sollten wir ein Ansible-Inventory erstellen. Hier werden wir die Server in zwei Gruppen einteilen. Zum einen gibt es die Gruppe gitlab, in der sich nur der erste Server (VM1) befindet. Auf diesem starten wir dann GitLab, Traefik und unsere Docker-Registry. Die zweite Gruppe rancher enthält alle restlichen Server. Diese werden später als Knoten des Kubernetes-Clusters verwendet.

Ihr erstellt also eine Datei namens inventory.yml im Verzeichnis ansible-setup mit folgendem Inhalt:

--- all: 
        children: 
            gitlab: 
                hosts: 
                    gitlab.example.com: 
                        ansible_user: ubuntu
                rancher: 
                    hosts:
                        vm2.example.com: 
                            ansible_user: ubuntu 
                        vm3.example.com: 
                            ansible_user: ubuntu 
                        vm4.example.com: 
                            ansible_user: ubuntu 

Hier müsst ihr ggf. den Namen des Users ändern.

Das erste Playbook

Nun können wir unser erstes Playbook erstellen. In diesem sammeln wir alles, was wir bisher getan haben. Wir nutzen beide Rollen und starten somit alle Services auf der VM1.

Dafür erstellt ihr euch eine Datei im Verzeichnis ansible-setup. Der Name dieser Datei ist beliebig, sollte allerdings sinnvoll gewählt werden. Aus diesem Grund nenne ich diese Datei gitlab.yml. Sie hat folgenden Inhalt:

--- 
    - name: setup gitlab 
        hosts: gitlab 
        become: true 
        roles: 
            - common 
            - gitlab 
        vars: 
            proxy: http://proxy-ip:proxy-port
        environment: 
            http_proxy: "{{ proxy }}" 
            https_proxy: "{{ proxy }}" 

Wie ihr seht, führen wir den einzigen Schritt dieses Playbooks nur auf der Gruppe gitlab und damit nur auf VM1 aus. Per become werden alle Tasks mit Sudo-Rechten ausgeführt. An dieser Stelle solltet ihr also nochmal überprüfen, ob eure benutzten User über diese Berechtigungen verfügen. Danach legen wir die Variable proxy fest. Im ersten Teil hatten wir innerhalb der Rolle common Tasks definiert, die diese Variable verwenden. Allerdings hatten wir proxy innerhalb der Rolle nirgends definiert. Durch das Setzen der Variable innerhalb des Schrittes des Playbooks wird diese anschließend in allen verwendeten Rollen bekannt sein. Per environment aktivieren wir die entsprechenden Umgebungsvariablen für den HTTP- und HTTPS-Proxy auf den Zielsystemen. Erst dadurch werden Tasks, wie das Herunterladen von Docker-Compose, funktionieren, da wir in der Rolle common den Proxy nur in "apt" und Docker hinterlegt haben. Damit wir die URL des Proxy nur an einer Stelle angeben müssen, benutzen wir hier direkt unsere Variable proxy.

Ein kleiner Test gefällig?

Wollt ihr eure bisherigen Fortschritte testen, so benötigt ihr eine lauffähige Ansible-Installation. Später werden wir die entsprechenden Befehle ausschließlich innerhalb unserer Pipeline ausführen, weshalb ihr eure Ansible-Installation nur zum Testen benötigen würdet.

Ihr könnt dieses Playbook über den Befehl ansible-playbook -i inventory.yml gitlab.yml ausführen. Nach dem erfolgreichen Durchlauf solltet ihr euer neues GitLab unter der URL gitlab.example.com erreichen können.

Zusammenfassung

In diesem Teil haben wir uns ein Ansible-Inventory erstellt und das erste Playbook geschrieben. Damit haben wir einen kleinen Meilenstein dieser Anleitung erreicht, da wir nun ein GitLab, eine Docker-Registry und Traefik mit nur einem Befehl auf der VM1 installieren können. Ebenfalls sind diese Services unter ihren entsprechenden Hostnames erreichbar. Im fünften Teil dieser Anleitung werden wir eine dritte Ansible-Rolle erstellen, in der wir ein RKE-Cluster auf der Gruppe rancher des Inventorys installieren werden.