Benutzer-Werkzeuge

Webseiten-Werkzeuge


docu:gitlab-ci

Dies ist eine alte Version des Dokuments!


GitLab CI/CD

Wenn in einem Code Repository eine Datei namens ​​.gitlab-ci.yml​​ existiert, so wird GitLab versuchen mit Hilfe der darin enthaltenen Anweisungen das Software in dem Projekt zu bauen, evtl. zu testen und bei Erfolg in eine Zielumgebung zu deployen. In der GitLab Instanz werden standardmäßig die Build-Processe über Kubernetes in der ICC ausgeführt. Für Spezialfälle können aber auch eigene Build-Runner angebunden werden. Einen Überblick über die Möglichkeiten des Gitlab-CI bietet https:​​docs.gitlab.com/​​ee/​​ci/​​README.html ===== Minimales .gitlab-ci.yml ===== Um ein Projekte für die Ausführung in der ICC vorzubereiten muss der Code als Docker-Image zur Verfügung stehen. Die folgende Vorlage illustriert dies anhand eine Golang-Projektes. Für andere Sprachen müssen die Anweisungen im Abschnitt job_build.script angepasst werden. Eine vollständige Dokumentation für die Build-Spezifikation findet sich hier: https://docs.gitlab.com/ee/ci/yaml/README.html Vorlage: <code> stages: - build before_script: - git config –global http.sslVerify true job_build: stage: build image: nexus.informatik.haw-hamburg.de/golang:1.8.3 variables: CGO_ENABLED: „0“ GOOS: „linux“ script: - glide install # no tests for now - go test gitlab.informatik.haw-hamburg.de/timadorus/timadorus-monitor/$(glide novendor) - go build -a -installsuffix cgo gitlab.informatik.haw-hamburg.de/timadorus/k8s-job-monitor - mkdir -p /$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME/ - mv ./k8s-job-monitor /$CI_PROJECT_NAMESPACE/$CI_PROJECT_NAME/ </code> ===== 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 Build-Prozess die notwendigen Zugangsinformationen mit sog. 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-on-ubuntu.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 ===== Es ist natürlich auch möglich Docker Images in einer Gitlab Pipeline zu bauen. Dazu ist die DOCKER_HOST Variable in der Gitlab Job Beschreibung zu setzen und das stable-dind images als „service“ im Job zu setzen. Beispiel für eine .gitlab-ci.yml aus https://gitlab.informatik.haw-hamburg.de/ail/haw-world/blob/master/.gitlab-ci.yml: <code> stages: - dockerize variables: DOCKER_HOST: „tcp:localhost:2375“ DOCKER_REGISTRY: „nexus.informatik.haw-hamburg.de“ SERVICE_NAME: „haw-world“

createImage: stage: dockerize image: nexus.informatik.haw-hamburg.de/docker:stable-dind services:

  1. nexus.informatik.haw-hamburg.de/docker:stable-dind

script:

  1. docker login -u $NEXUS_USER -p $NEXUS_PW $DOCKER_REGISTRY
  2. docker build -t $DOCKER_REGISTRY/$SERVICE_NAME:$CI_PIPELINE_ID .
  3. docker push $DOCKER_REGISTRY/$SERVICE_NAME:$CI_PIPELINE_ID

</code>

Deployment einer Applikation aus Gitlab in die ICC

den Artikel dazu finden Sie im entsprechenden Abschnitt der Dokumentation für die Informatik Computer Cloud.

Eigene Build Runner

docu/gitlab-ci.1511418061.txt.gz · Zuletzt geändert: 2017/11/23 07:21 von sage