~~NOTOC~~
===== 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:

<code>
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]-----+
</code>

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:

<code>
 - eval $(ssh-agent -s)
 - echo "${SSH_PRIVATE_KEY}" | tr -d '\r' | ssh-add -
</code>

und im ''script:'' Block wird ganz unten der Befehl für die Auslieferung hinzugefügt:

<code>
 - lftp -u ${SSH_USER}, -e "mirror -R ${CI_PROJECT_DIR}/public/ ${TARGET_DIR}/; quit" sftp://${SSH_HOST}
</code>

Die komplette Steuerdatei sieht im Beispielprojekt dann wie folgt aus:

<code>
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
</code>

Sobald jetzt Änderungen übermittelt (''git commit'' / ''git push'') werden, wird auch die Zielseite immer aktualisiert.

==== Das Ergebnis==== 

  * https://ajobs.io.noc.ruhr-uni-bochum.de/talks

sieht exakt aus wie

  * https://homepage.ruhr-uni-bochum.de/andreas.jobs/talks