Schritt 5

Ziel

Meistens gibt es nicht nur einen Produktivserver, sondern zusätzlich noch einen Staging- und evtl. weitere Server zum Testen. Auf einem Staging-Server kann die Software unter Produktionsbedingungen ausgeführt werden ohne die Produktionsversion zu verändern. Dies dient dazu, Kunden eine Möglichkeit der Überprüfung und endgültigen Freigabe zur Übernahme in Produktion zu ermöglichen. Dabei können beispielsweise Mitarbeiter des Kunden involviert werden, die nicht Mitglied im Projektteam sind (z. B. Geschäftsleitung).

Es sollen jetzt zwei Nginx-Container auf dem Entwicklungsrechner betrieben werden. Einer enthält die aktuelle Entwicklungsversion, der andere die Staging-Version. Das Deployment auf die beiden Server wird über den Branch gesteuert: wenn es sich um den Branch staging handelt, wird auf Staging deployed, sonst auf Development.

Da alle Server nach wie vor auf derselben Maschine (Entwicklungsrechner) laufen, muss der Zugriff auf die beiden Server über einen Reverse Proxy gesteuert werden um Zugriffskonflikte zu vermeiden. Wir verwenden dafür den Reverse Proxy træfik, der ebenfalls als Docker-Container gestartet wird.

Außerdem sollen die beiden Server über GitLab-Environments ansprechbar sein.

Aufgabe

Ihnen ist beim Befolgen des GitLab-Flow sicherlich aufgefallen, dass sowohl die Pipelines des Main-Branches als auch der Feature-Branches die eine Beispieldatei aus den vorhergehenden Schritten überschreiben. Ändern Sie Ihre Pipeline so ab, dass verschiedene Nginx-Container genutzt werden, die über verschiedene URLs erreichbar und unter Operate > Environments im GitLab-Projekt einsehbar sind.

Nutzen Sie dafür das gegebene docker-compose.yml File. Hier wird mittels træfik und nip.io eine Umgebung aus zwei verschiedenen Nginx-Containern geschaffen. Für eine Erfolgreiche Bearbeitung der Aufgabe ist ein tieferes Verständnis dieser beiden Dienste nicht zwingend erforderlich. Wir empfehlen aber, dass Sie sich auch mit diesen Diensten auseinandersetzen und versuchen die Funktionsweise nachzuvollziehen.

# docker-compose.yml

services:
  traefik:
    container_name: traefik
    image: traefik:v2.0
    restart: always
    command:
      --api.insecure
      --entrypoints.http.address=:80
      --providers.docker
      --providers.docker.exposedbydefault=false
    network_mode: host
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
  staging:
    container_name: nginx_staging
    image: nginx
    restart: always
    labels:
      traefik.enable: true
      traefik.http.routers.staging.rule: Host(`staging.XXX.XXX.XXX.XXX.nip.io`)
  dev:
    container_name: nginx_dev
    image: nginx
    restart: always
    labels:
      traefik.enable: true
      traefik.http.routers.dev.rule: Host(`dev.XXX.XXX.XXX.XXX.nip.io`)

Ersetzen Sie im oben stehenden Beispiel XXX.XXX.XXX.XXX durch die IP-Adresse des localhost.

Nutzen Sie in Ihrer erweiterten Pipeline die Keywords rules oder only/except.

Sollten Sie keine Verbindung über die Routen herstellen können, beachten sie den Hinweis auf nip.io:

DNS Rebinding Protection

Some DNS resolvers, forwarders and routers have DNS rebinding protection which may result in failure to resolve local and private IP addresses. This service won't work in those situations.

Informieren Sie sich über mögliche Lösungsansätze, für eine FRITZ!Box kann z.B. dieser Workaround funktionieren.