Webseiten veröffentlichen mit Gitlab
Gitlab kann u.a. auch dafür verwendet werden, Webauftritte mit eigenem Editor-Workflow zu erstellen bzw. zu managen. Dazu bietet Gitlab standardmäßig das Pages Feature an. Hierbei wird das Ergebnis, der fertige Webauftritt, unter der Pages-URL
https://BENUTZER.io.noc.ruhr-uni-bochum.de/PROJEKTNAME
bzw.
https://GRUPPENNAME.io.noc.ruhr-uni-bochum.de/PROJEKTNAME
veröffentlicht. Mit einfachen Mitteln kann die verwendete CI/CD-Pipeline, die für die Erstellung der Webseiten sorgt, so erweitert werden, dass diese auf einem entfernten Server veröffentlicht werden.
Eckdaten und Voraussetzungen
Um die fertigen Webseiten auf dem entfernten Server zu veröffentlichen wird ein SSH-Zugang zu diesem Server benötigt, da nicht die „normalen“ Zugangsdaten für diesen Server verwendet werden sollen (die Zugangsdaten müssen auf dem Gitlab-Server hinterlegt werden). Vollständiger Shell-Zugang mit installiertem rsync wäre optimal, in diesem Beispiel steht aber nur der minimale SFTP Zugang zur Verfügung.
Für das Beispiel wird mein Gitlab-Projekt talks verwendet, in dem ich viele meiner Vorträge archiviert habe, mit dem Ziel diese auf dem Homepage-Server der RUB zu veröffentlichen.
Zugang ermöglichen
Damit nicht die normalen Zugangsdaten für den Hompepage-Server im Gitlab hinterlegt werden müssen, wird ein SSH-Schlüsselpaar für genau diesen Zweck erzeugt:
user@work:~$ ssh-keygen -t ed25519 -C 'GitLab deployment key' Generating public/private ed25519 key pair. Enter file in which to save the key (/home/user/.ssh/id_ed25519): gitlab-deployment Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in gitlab-deployment Your public key has been saved in gitlab-deployment.pub The key fingerprint is: SHA256:FtulN3htxaX0VwaZixcYDOZ1nMT0q7xMH4iiL0x8rAc GitLab deployment key The key's randomart image is: +--[ED25519 256]--+ | oooB*=+| | o .ooB*o| | . . ...o*| | + +..o.o| | . S + +.o. | | E o oooo | | o +. . = . | | +... o o .| | .+. o . | +----[SHA256]-----+
Der Public-Key wird in der Datei authorized_keys im .ssh Unterverzeichnis im Homeverzeichnis auf dem Homepage-Server hinterlegt. Ein Test soll zeigen, ob der Zugang funktioniert. Der Befehl
sftp -i gitlab-deployment loginid@homepage.ruhr-uni-bochum.de
sollte ohne Passwort-Abfrage direkt mit dem Homepage-Server verbinden.
Gitlab Projekt modifizieren
Der Private-Key wird auf dem Gitlab-Server hinterlegt. Im Gitlab-Projekt wird dazu in Settings → CI/CD → Variables → Expand mittels Add Variable eine neue Variable mit dem Namen SSH_PRIVATE_KEY angelegt. In das Feld Value kann anschließend der Inhalt der vorhin erzeugten Datei gitlab-deployment kopiert werden. Zusätzlich werden noch drei weitere Variablen angelegt, um die Konfiguration vom Repository zu trennen:
- SSH_HOST:
homepage.ruhr-uni-bochum.de - SSH_USER: LoginID
- TARGET_DIR: Zielverzeichnis (in diesem Beispiel
talks)
Die Steuerdatei für das CI/CD (.gitlab-ci.yml) wird jetzt wie folgt erweitert (alles innerhalb des pages: Blocks):
Ein before-script: Block wird erstellt oder der vorhandene um die folgenden Zeilen erweitert:
- eval $(ssh-agent -s)
- echo "${SSH_PRIVATE_KEY}" | tr -d '\r' | ssh-add -
und im script: Block wird ganz unten der Befehl für die Auslieferung hinzugefügt:
- lftp -u ${SSH_USER}, -e "mirror -R ${CI_PROJECT_DIR}/public/ ${TARGET_DIR}/; quit" sftp://${SSH_HOST}
Die komplette Steuerdatei sieht im Beispielprojekt dann wie folgt aus:
pages:
stage: deploy
before_script:
- eval $(ssh-agent -s)
- echo "${SSH_PRIVATE_KEY}" | tr -d '\r' | ssh-add -
script:
- make -f rules pages
- lftp -u ${SSH_USER}, -e "mirror -R ${CI_PROJECT_DIR}/public/ ${TARGET_DIR}/; quit" sftp://${SSH_HOST}
artifacts:
paths:
- public
only:
refs:
- master
changes:
- public/*
- PDF/*
tags:
- pages
Sobald jetzt Änderungen übermittelt (git commit / git push) werden, wird auch die Zielseite immer aktualisiert.