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
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 :
Aber auch das Log der Testläufe kann jederzeit angezeigt werden:
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:
Welche Tools verwenden
Für die Nutzung unter Windows verwende ich verschiedene Tools:
- Als universelle Git-Shell: Git for Windows
- Unter PowerShell: Posh-Git
- Integriert in Entwicklungsumgebung: Visual Studio Code
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.
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
Dieser eine Runner ist so aufgelegt, dass er alle für mich relevanten Arten von PowerShell Skripten ausführen kann.
Meine Module und SnapIns:
- Windows PowerShell allgemein
- Microsoft Active Directory
- Microsoft Exchange
- Pester
- PSScriptAnalyzer
- VMware PowerCLI
- PowervRA
- Veeam Backup & Replication
- HPE 3Par
- HPE iLO / OA
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:
HTTPS
Ich verwende ein Microsoft CA signierten Zertifikat. Hierbei hat die folgende Vorgehensweise ohne Komplikationen funktioniert:
- In
gitlab.yml
:- Set the
port
option in section 1 to443
. - Set the
https
option in section 1 totrue
.
- Set the
- In the
config.yml
of gitlab-shell:- Set
gitlab_url
option to the HTTPS endpoint of GitLab (e.g.https://git.example.com
). - Set the certificates using either the
ca_file
orca_path
option.
- Set
- Use the
gitlab-ssl
Nginx example config instead of thegitlab
config.- Update
YOUR_SERVER_FQDN
. - Update
ssl_certificate
andssl_certificate_key
. - Review the configuration file and consider applying other security and performance enhancing features.
- Update
Quelle: GitLab Doku – Using HTTPS
Mit dem zusätzlichen HTTP zu HTTPS Redirect sieht meine Konfiguration so aus:
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-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:
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:
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…
No Responses