GitLab CI/CD mit PowerShell – Teil 1 – Installation

Als meine PowerShell Skripte immer umfangreicher wurden und zu kleinen Projekten ausgeufert sind, wuchs der Wunsch nach einer besseren Versionskontrolle für meine Skripte. Somit musste ein Version Control System her. Ich bin sehr froh, dass damals meine Wahl auf GitLab gefallen ist. Dieses wirklich großartige Produkt bietet weitaus mehr als nur eine reine Versionskontrolle. Mit GitLab war ich bestens vorbereitet auf meinen nächsten Schritt im Bereich DevOps: GitLab CI/CD (Continuous Integration / Continuous Delivery) mit PowerShell

Einleitung zu GitLab CI/CD mit PowerShell

Bevor ich in das Thema einsteige, möchte ich noch ein paar einleitende Worte zu Versionkontrolle, Continuous Integration und Continuous Delivery verlieren.

Warum Versionskontrolle

Eine Versionkontrolle soll alle Änderungen am Code eines Projekts festhalten. Somit ist es jederzeit möglich auf beistimme Stände zu springen oder Stände miteinander zu vergleichen. Weiter wird natürlich auch festgehalten wer, wann und was geändert hat.

Wenn heutzutage über Versionskontrolle gesprochen wird, ist im Normalfall Distributed Version Control (DVC) gemeint. Das bestbekannteste Distributed Version Control System (DVCS) ist wohl GIT.

Warum Continuous Integration und Continuous Delivery

Dieses Thema kann man nun sehr ausführlich aus der Sicht eines echten Entwicklers mit umfangreichen Projekten betrachten, was den Rahmen vermutlich sprengen würde. Daher zeige ich hier nur meinen spezifischen Nutzen auf.

Für mich ist Continuous Integration in meinem Umfeld eine Qualitätskontrolle und dient zur Vermeidung von Fehlern.
Jeder Push in das Projekt löst vordefinierte Tests mit dem aktuellen Codes dieses Projektes aus.

Das Ergebnis wird dann in der GitLab Oberfläche für alle Nutzer visualisiert :

GitLab CI/CD mit PowerShell - Build Status

Aber auch das Log der Testläufe kann jederzeit angezeigt werden:

GitLab CI/CD mit PowerShell - Test Run

Continuous Delivery (Deployment) ist dann dafür zuständig den aktuellen Entwicklungsstand des Projektes in einen ausführbaren Zustand zu bringen. Dies kann z.B. das simple Kopieren der Daten an den benötigten Ort sein. Aber natürlich sind auch wesentlich komplexere Vorgänge denkbar.

Prozess von GitLab CI/CD:

GitLab CI/CD mit PowerShell - Flow

Welche Tools verwenden

Für die Nutzung unter Windows verwende ich verschiedene Tools:

Unter Linux bzw. in dem Beispiel unter Ubuntu verwende ich das Paket git-core:

sudo apt-get install git-core

Weitere Ressourcen

Ein guter Einstieg ist das Buch Pro Git. Erhältlich als Ebook oder als gedruckte Version auf Amazon.

progit2

Mein GitLab CI/CD Aufbau

Da ich es zu 90% nur mit PowerShell Projekten zu tun habe und Entwicklung nichts Betriebs kritisches ist, sieht der Aufbau sehr einfach aus:

  • Ein GitLab Server
  • Ein PowerShell Runner
  • Anbindung an das Microsoft Active Directory

 

GitLab CI/CD mit PowerShell - Aufbau

GitLab CI/CD mit PowerShell – Aufbau

Dieser eine Runner ist so aufgelegt, dass er alle für mich relevanten Arten von PowerShell Skripten ausführen kann.

Meine Module und SnapIns:

Basis Installation von GitLab 8.11

Ich habe für den GitLab Server als Betriebssystem wie empfohlen Ubuntu 16.04 x64 gewählt. Die Installation ist komplett ohne Zwischenfälle abgelaufen.

Vorbereitung Betriebssystem

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install htop ntp snmpd curl openssh-server ca-certificates postfix

Installation VIM Editor

sudo apt-get install vim
sudo update-alternatives --set editor /usr/bin/vim.basic

Instalaltion GitLab

curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash
sudo apt-get install gitlab-ce

Initialisierung GitLab

sudo gitlab-ctl reconfigure

Basis Konfiguration von GitLab 8.11

LDAP

Wie in dem Diagramm zu sehen arbeite ich mit einem Microsoft Active Directory.

GitLab integrates with LDAP to support user authentication. This integration works with most LDAP-compliant directory servers, including Microsoft Active Directory, Apple Open Directory, Open LDAP, and 389 Server. GitLab EE includes enhanced integration, including group membership syncing.

Quelle: GitLab LDAP Doku

Mit einem Domain Controller sieht meine Konfiguration so aus:

GitLab - LDAP

HTTPS

Ich verwende ein Microsoft CA signierten Zertifikat. Hierbei hat die folgende Vorgehensweise ohne Komplikationen funktioniert:

  1. In gitlab.yml:
    1. Set the port option in section 1 to 443.
    2. Set the https option in section 1 to true.
  2. In the config.yml of gitlab-shell:
    1. Set gitlab_url option to the HTTPS endpoint of GitLab (e.g. https://git.example.com).
    2. Set the certificates using either the ca_file or ca_path option.
  3. Use the gitlab-ssl Nginx example config instead of the gitlab config.
    1. Update YOUR_SERVER_FQDN.
    2. Update ssl_certificate and ssl_certificate_key.
    3. Review the configuration file and consider applying other security and performance enhancing features.

Quelle: GitLab Doku – Using HTTPS

Mit dem zusätzlichen HTTP zu HTTPS Redirect sieht meine Konfiguration so aus:

GitLab - HTTPS

Installation des Multi-Runner für GitLab CI unter Windows

Als erstes muss das Binary noch heruntergeladen werden: x86 oder amd64

Mehr Details zum Multi-Runner:

In meinem Fall verwende ich die 64Bit Variante, abgelegt unter „C:\Multi-Runner“.

Multi-Runner registrieren

cd C:\Multi-Runner
gitlab-ci-multi-runner-windows-amd64.exe register

Regierungsprozess Fragt nun einige Daten ab:

  • gitlab-ci coordinator: https://<GitLab Server>/ci
  • gitlab-ci token: Für einen Globalen Runner ist dies in der Admin Area zu finden

GitLab Runner - Token

  • gitlab-ci description: Hostname
  • executor: shell
  • gitlab-ci tags: Windows

Nun muss noch manuell eine weitere Zeile in die erzeugte Konfiguration (Im Pfad der EXE) eingetragen werden:

GitLab Runner - Config

Multi-Runner Dienst installieren

gitlab-ci-multi-runner-windows-amd64.exe install
gitlab-ci-multi-runner-windows-amd64.exe start

Der Dienst wir so als „Local System“ registriert. Dies in meinem Fall nicht ausreichend, also habe ich einen AD User mit den benötigten Rechten (vCenter, Veeam, etc.) erzeigt und starte den Dienst als dieser User.

Multi-Runner prüfen

Unter Admin Area > Runners ist nun der neue Windows Runner zu finden:

GitLab Runner

Nun ist die die das GitLab System inklusive einem Runner bereit für das erste Projekt.

Wie ein Projekt mit Continuous Integration / Continuous Delivery aufgebaut sein muss und welche Möglichkeiten GitLab CI/CD bietet werde ich im Teil 2 dieser Serie näher ausführen.

Stay tuned…

Leave a Reply