Heute muss jeder Softwareengineer mit einigen Technologien die früher kein Thema waren vertraut sein, um qualitative Projekte agil zu erstellen. Git, Containers, CI / CD, Unit-Test sind Beispiele, die schon jetzt im Alltag gebräuchlich sind.
Während Gitlab eine gesamte CI / CD Umgebung anbietet, erleichtert GitKraken die Teamarbeit mit Git. Zusätzlich kann der Cloud-Service AWS ECR die Qualitätskontrolle und Flexibilität stark erhöhen, wenn ein Team mit Docker Containers arbeitet. Bezüglich Programmiersprache wird golang immer populärer im DevOps Bereich. Aber die Frage ist: Was haben diese vier Technologien gemeinsam? Mit diesen Technologien arbeiten meine Arbeitskollegen und ich um unsere Projekte erfolgreich durchzuführen. In diesem Blogbeitrag erkläre ich, wie es gemacht wurde!
Eine kurze Einführung zum Gitlab
GitLab ist ein Open Source Code-Repository und eine kollaborative Entwicklungsplattform für grosse DevOps-Projekte und kann als Continuous Integration / Continuous Delivery (CI / CD) Programm verwendet werden. Zuerst beschreibe ich die Hauptkonzepte zum Thema CI/CD im GitLab.
Was sind Pipelines?
Pipelines sind die oberste Komponente von Continuous Integration, Delivery und Deployment. In einer Pipeline werden alle Prozesse durchgeführt.
Eine Pipeline enthält zwei Hauptkomponenten:
- Jobs definieren was zu tun ist, z.B. Code kompilieren oder testen
- Stages definieren, wann die Jobs ausgeführt werden sollen, z.B. die Test-Stage wird ausgeführt, sobald die Stage für „Code kompilieren“ fertig ist.
Bei Commit und Push Kommandos wird eine Pipeline automatisch gestartet.
Die Magie der gitlab-ci.yml
Die Datei gitlab-ci.yml ist verantwortlich für die Konfiguration aller Schritte der kontinuierlichen Integration. Diese Datei muss im Stammverzeichnis des Projekts liegen, basierend auf einer gleichmässigen Einrückung.
Und wieso Gitkraken?
Gitkraken ist ein innovativer Git-Client, welcher einen Überblick zu Branch-Struktur und Commit-Verlauf bietet.
Das Tool kann bei jedem Betriebssystem installiert werden, was ein grosser Vorteil für unseren Team ist, weil jeder Mitarbeiter mit einem unterschiedlichen Lieblings-Betriebssystem arbeitet.
Bei Gitkraken können Git-Kommandos mit ein paar Klicken ausgeführt werden. Somit werden Fehler schneller gefunden und schwerwiegende Merge-Konflikte vermieden.
Wir haben unsere internen Richtlinien für unsere Projekte definiert, z.B.: Nennung der Projekt-Branches muss folgende Kriterien erfüllen:
- Feature-Request Branches unterscheiden sich von Bugfix Branches
- Jeder Branch gehört zu einem Jira-Task
- Intuitiven Titel angeben
z.B.:
- feature/<JIRA-TASK-ID>-<TITLE>
- bugfix/<JIRA-TASK-ID>-<TITLE>
Die Richtlinie in Kombination mit Gitkraken macht die Projekt-Ansicht sehr übersichtlich: Bei uns ist es einfacher geworden Branches oder Commit, die nicht optimal definiert wurden, zu finden und zu korrigieren.
Was ist AWS Elastic Container Registry (ECR)?
Amazon Elastic Container Registry (Amazon ECR) ist ein AWS privates Repository von Docker Images. Es geht um eine vollständig verwaltete Docker-Container-Registry, mit der man Docker Images mit Sicherheit und einer hohen Verfügbarkeit deployen kann. AWS ECR ist ähnlich wie Docker Hub, aber privat.
Mit AWS ECR können wir mit der Funktion „Scannen von Images“ überprüfen, ob unsere Docker-Images Schwachstellen enthalten.
Die Funktion „Lebenszyklus-Richtlinien“ haben wir so konfiguriert, dass die alten Images täglich bereinigt werden.
Zum Thema Preis: Wir zahlen für AWS ECR nur die Datenmenge, die wirklich in Repositories gespeichert wurde. Das ist eine optimale Situation für unsere IT-Kleinfirma.
Bei AWS ECR verwenden wir noch ein sogenanntes “Amazon ECR Credential Helper” Open Source Projekt. Das Programm wurde mit Golang programmiert um unsere Anmeldedaten sicher zu behalten.
AWS ECR generiert verschlüsselte Anmeldedaten, die aufgrund der Sicherheitsqualität für nur 12 Stunden gültig sind. Das „Credential Helper Programm“ kann allerdings das laufende Passwort immer wieder verwenden, um auf den aktuellen Stand des Images zuzugreifen. Damit müssen wir uns nicht um das regelmässige Wechseln der Anmeldedaten sorgen.
Im GitLab ist es noch wichtig die AWS-Login-Variablen zu definieren:GitLab Projekt –> Settings –> CI / CD –> Variablen:
Alles klar, aber was machen wir damit?
AWS ECR, sowie das Credential Helper Programm, können wir in unserer Pipeline integrieren!
Bei unserer Pipeline sind drei Stages wichtig:
- build:wird immer durchgeführt
- test:wird immer durchgeführt
- docker:wird manuell durchgeführt
Beim Stage docker werden die nötigen Scripts durchgeführt um AWS ECR und den Credential Helper Programm mit Golang zu verwenden. Die Ausführung von docker Stage wird als manuell beim „when“ Parameter definiert, weil es nur dann durchgeführt werden soll, wenn ein Projekt-Upgrade auf dem Kunden Server benötigt wird.
Hier unten siehst du wie die Datei gitlab-ci.yml aussehen könnte:
stages
- build
- test
- docker
build:
stage: build
image: maven:3.6-openjdk-11-slim
script:
- echo "Building"
cache: &build-cache
key: build
paths:
- .m2/repository
artifacts:
paths:
- backend/target/*.jar
- frontend/target/*.jar
- "**/docker/**/*-min.js"
expire_in: 1 week
test:
stage: test
image: maven:3.6-openjdk-11-slim
script:
- mvn verify
cache:
<<: *build-cache
artifacts:
when: always
reports:
junit:
- target/surefire-reports/TEST-*.xml
- target/failsafe-reports/TEST-*.xml
docker:
stage: docker
image: docker:19.03.8-dind
when: manual
dependencies:
- build
script:
- apk add bash
- scripts/setup-aws-ecr.sh
- scripts/build-and-push.shBei docker Stage sieht man zwei Linux Shell Skripte, die unter dem scripts Verzeichnis liegen:
- setup-aws-ecr.sh
- build-and-push.sh
Bei setup-aws-ecr.sh Script wird Golang installiert und das AWS ECR Credential Helper Projekt wird geklont und gebaut. Die Anmeldedaten für das ECR Login werden in der Datei config.json gespeichert.
#!/bin/bash
set -e
ECR_LOGIN=/usr/local/bin/docker-credential-ecr-login
if [[ ! -x "$ECR_LOGIN" ]]; then
ECR_GIT_REPO=github.com/awslabs/amazon-ecr-credential-helper
ECR_GIT_REPO_PATH="/usr/lib/go/src/$ECR_GIT_REPO"
apk add git go
git clone "https://$ECR_GIT_REPO" "$ECR_GIT_REPO_PATH"
go build -o "$ECR_LOGIN" "$ECR_GIT_REPO_PATH/ecr-login/cli/docker-credential-ecr-login"
fi
mkdir -p ~/.docker
cat << EOF > ~/.docker/config.json
{
"credHelpers": {
"000000000000.dkr.ecr.eu-central-1.amazonaws.com": "ecr-login"
}
}
EOFBei setup-aws-ecr.sh werden die Images gebaut und nach Gitlab gepusht:
#!/bin/bash
set -ex
DOCKER_COMPOSE_ENV_FILE=.env-build
apk add docker-compose
if docker-compose --env-file "$DOCKER_COMPOSE_ENV_FILE" &> /dev/null; then
DOCKER_COMPOSE_PARAMS="--env-file $DOCKER_COMPOSE_ENV_FILE $DOCKER_COMPOSE_PARAMS"
else
# Rename the environment file since docker-compose does not support the CLI argument --env-file.
mv "$DOCKER_COMPOSE_ENV_FILE" .env
fi
# Build and push images:
docker-compose $DOCKER_COMPOSE_PARAMS build
docker-compose $DOCKER_COMPOSE_PARAMS push backend postgres proxy frontendFazit
Für eine komplete CI/CD Automatisierung und eine konkrete DevOps Strategie liegt ein langer Weg vor uns, aber die ersten Schritten wurden bereits gemacht. Das Ziel ist immer wieder neue Ideen zu implementieren und unsere DevOps-Umgebung zu verbessern. Somit erhöht sich unsere DevOps Maturität Schritt für Schritt.
Jedes Tool ist ein Bestandteil unseres DevOps Konzept geworden und hat uns täglich geholfen, da unser Team mit Containers und agilen Methoden arbeitet. Hoffentlich wurde dein Interesse zu diesen Tools geweckt.
