Memobase
💙
GitLab

11. Januar 2022

Weshalb GitLab?

Feature Memobase
Open Source gitlab.switch.ch
Integrierte CI Tests, Builds & Packaging
Runners 4 dedizierte Instanzen
Webhooks Deployments
Package Registries Maven-Registry
Container Registries Service-Images

Runners

  • CI-Workflow auf gitlab-Instanz von switch sehr langsam
  • Nutzung von eigenen, dedizierten Runners
  • Laufen als Docker-Containers auf mb-r1 - mb-r4
  • Statisches Set von gecachten Basis-Images
  • Dadurch nur kurze Wartezeiten bei Aufsetzen der Build-Umgebung

Git-Templates

  • Redundanzen vermeiden durch modulare CI-Definition
  • Zentrales Repository mit “Templates”
stages:
  - test
  - build
  - publish

include:
  - project: 'memoriav/memobase-2020/utilities/ci-templates'
    file: 'sbt-build/sbt-build.yml'
  - project: 'memoriav/memobase-2020/utilities/ci-templates'
    file: 'docker-image/docker-image.yml'
  - project: 'memoriav/memobase-2020/utilities/ci-templates'
    file: 'helm-chart/helm-chart.yml'

Autodeployment

Ziel: Vereinfachung des Deployment-Workflow auf k8s

Deployment auf Testumgebung

  1. Push von Commits auf master-Branch
  2. Container image (latest-Tag) wird in CI erstellt
  3. Webhook ruft Autodeploy-Service auf k8s-Cluster auf
  4. Cloning des Repositories durch Autodeploy-Service
  5. helm install in geklontem Repository

Deployment auf produktive Umgebung

  1. Push von Commits mit semver-kompatiblem Tag, bspw. 1.2.3
  2. Container image (Versions-Tag) wird in CI erstellt
  3. Chart wird in CI erstellt und auf lokaler Helm Registry publiziert
  4. Webhook ruft Autodeploy-Service auf k8s-Cluster auf
  5. Autodeploy-Service installiert Helm Chart direkt von Helm Registry