Benutzer-Werkzeuge

Webseiten-Werkzeuge


docu:gitlab-ci

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
docu:gitlab-ci [2017/11/22 07:21]
sage
docu:gitlab-ci [2018/05/14 17:43] (aktuell)
sage [Während des Build-Prozesses Zugriff auf anderes Gitlab-Repo gewähren] Namen des Scriptes synchronisiert
Zeile 1: Zeile 1:
 +====== Gitlab CI/CD ======
 +
 +Gitlab bietet eine automatische Continous Build/​Continous Deployment Pipeline. Damit wird in jedem, entsprend vorbereiteten,​ Projekt nach einer Änderung des Git-Repositories automatisch der Code ausgechecked,​ gebaut, evtl. Tests durchgeführt und in ein ausführbares Format gebracht. Wenn diese Schritte erfolgreich sind, kann das fertige Programm auch in der [[:​docu:​informatikcomputecloud|ICC]] automatisch ausgeführt werden und Messdaten direkt in Gitlab beobachtet werden.
 +
 +Im Wurzelverzeichnis eines Projektes muss die Datei ''​.gitlab-ci.yml''​ existieren. Diese wird dann mit im gemeinsamen GitLab-Runner über Kubernetes innerhalb der ICC ausgeführt. Für Spezialfälle können auch eigene Runner angebunden werden. Siehe [[:​docu:​gitlab-ci#​eigene_build_runner|ensprechenden Abschnitt]] weiter unten.
 +
 ===== Minimales .gitlab-ci.yml ===== ===== Minimales .gitlab-ci.yml =====
  
Zeile 28: Zeile 34:
 ===== Während des Build-Prozesses Zugriff auf anderes Gitlab-Repo gewähren ===== ===== Während des Build-Prozesses Zugriff auf anderes Gitlab-Repo gewähren =====
  
-In der Regel werden für das Bauen von Software noch zusätzliche Komponenten wie Bibliotheken,​ Werkzeuge oder Daten benötigt. Diese werden zusammenfassend als Abhängigkeiten bezeichnet. Wenn diese Abhängigkeiten in zugriffsbeschränkten Repositories auf dem Gitlab zu Verfügung stehen, so können für einen Buil-Prozess die notwendigen Zugangsinformationen mit sog. Deployment ​Keys (https://​docs.gitlab.com/​ce/​ssh/​README.html#​deploy-keys) zur Verfügung gestellt werden.+In der Regel werden für das Bauen von Software noch zusätzliche Komponenten wie Bibliotheken,​ Werkzeuge oder Daten benötigt. Diese werden zusammenfassend als Abhängigkeiten bezeichnet. Wenn diese Abhängigkeiten in zugriffsbeschränkten Repositories auf dem Gitlab zu Verfügung stehen, so können für einen Build-Prozess die notwendigen Zugangsinformationen mit sog. //​**Deploy ​Keys**//  ​([[https://​docs.gitlab.com/​ce/​ssh/​README.html#​deploy-keys|https://​docs.gitlab.com/​ce/​ssh/​README.html#​deploy-keys]]) zur Verfügung gestellt werden. 
 + 
 +Hierzu müssen Sie 
 + 
 +  - Ein SSH Schlüsselpaar erzeugen. Dies sollte auf keinen Fall ihr persönliches Paar sein. 
 +  - Den öffentlichen Schlüssel legen Sie in dem Projekt **auf das zugegriffen werden soll** ​ als Deploy Key ab. Öffnen Sie dazu im Sidebar die Seite "''//​Settings | Repository//''"​ und erweitern den Abschnitt "''//​Deploy Keys//''"​. Legen Sie nun einen neuen Deploy Key an. Hier finden Sie auch einen Link auf detailierte Informationen zur Erzeugung und Formatierung der benötigten Schlüssel. 
 +  - Den private Schlüssel legen Sie in das Projekt **aus dem heraus zugegriffen werden soll** ​ als geheime Variable ab. Öffnen Sie dazu im Sidebar die Seite "''//​Settings | CI/​CD//''"​ und erweitern den Abschnit "''//​Secret variables//''"​. Legen Sie eine Variable mit dem Namen "​SSH_PRIVATE_KEY"​ an und füllen Sie deren Wert auf den private Key. 
 +  - In dem Projekt von dem aus zugegriffen werden soll fügen, Sie folgenden Abschnitt zur ''​.gitlab-ci.yml'' ​ hinzu (oder erweitern ihn, wenn Sie schon einen solchen Abschnitt haben: 
 + 
 +<​code>​ 
 +before_script:​ 
 +  # setup SSH if on ubuntu 
 +  - eval $(bash ./​scripts/​setup-ssh.sh "​$SSH_PRIVATE_KEY"​) 
 +</​code>​ 
 + 
 +  - Folgendes Script dem zugreifenden Projekt unter ''​scripts/​setup-ssh.sh'' ​ hinzufügen:​ 
 + 
 +<​code>​ 
 +#​!/​bin/​bash 
 +
 +# set up the SSH agent to access the repositories of the dependencies of 
 +# this project. Currently only works on Ubuntu or Debian machines. 
 +
 +# use: setup-ssh # 
 +# set the private key as project secret 
 +
 +SSH_PRIVATE_KEY="​$1"​ 
 +# check if this is actually ubuntu 
 +ID="​something else"​ 
 +test -f /​etc/​os-release && source /​etc/​os-release 
 +case "​$ID"​ in 
 +  debian|ubuntu) 
 +    # Install ssh-agent if not already installed, it is required by Docker. 
 +    which ssh-agent>/​dev/​null || ( apt-get update -y && apt-get install openssh-client -y ) 
 + 
 +    # Run ssh-agent (inside the build environment) 
 +    AGENT_SETUP=$(ssh-agent -s) ; echo "​$AGENT_SETUP"​ 
 + 
 +    # need info here too 
 +    eval $AGENT_SETUP>/​dev/​null 
 + 
 +    # Add the SSH key stored in SSH_PRIVATE_KEY variable to the agent store 
 +    echo -n "#"​ 
 +    ssh-add <(echo "​$SSH_PRIVATE_KEY"​) 
 +    echo -n "# Key loaded: ​ " 
 +    ssh-add -l 
 + 
 +    # For Docker builds disable host key checking. Be aware that by adding that 
 +    # you are susceptible to man-in-the-middle attacks. 
 +    # WARNING: Use this only with the Docker executor, if you use it with shell 
 +    # you will overwrite your user's SSH config. 
 +    mkdir -p ~/.ssh 
 + 
 +    [[ -f /.dockerenv |]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n">​ ~/​.ssh/​config 
 +  ;; 
 +  *) 
 +    echo "echo OS is $ID, which is unknown to mee, no setup done"​ 
 +    exit 0 
 +esac 
 +</​code>​ 
  
 ===== Docker Images in Gitlab Build bauen ===== ===== Docker Images in Gitlab Build bauen =====
docu/gitlab-ci.1511331713.txt.gz · Zuletzt geändert: 2017/11/22 07:21 von sage