Microservices automatisiert in Azure betreiben – VSTS, Docker Swarm Mode, Traefik und Azure IaaS

Die meisten Software Hersteller benötigen zur Entwicklung und Wartung ihrer Produkte mehrere Umgebungen – seien dies Entwicklungsumgebungen, verschiedene Testumgebungen oder die produktive Umgebung. Heutzutage gibt es Bestrebungen, jede Codeanpassung direkt (Continuous Deployment) oder in kurzen Release-Zyklen und einer allfälligen, manuellen Bestätigung (Continuous Delivery) auf verschiedene Umgebungen oder allenfalls direkt in die Produktion zu überführen. Damit das möglich ist, sind Automatismen und die richtigen Frameworks bzw. Plattformen notwendig.

Mit Docker als Container-Plattform und Traefik als Reverse Proxy können mit minimalem Aufwand neue Umgebungen “gezaubert” werden. VSTS übernimmt dabei das Tooling für das Build – und Releasemanagement.

Dieser Blog setzt ein Setup eines Docker Swarm-Mode Clusters mit IaaS Ressourcen voraus. Dies wird nicht in diesem Artikel beschrieben (Bei Fragen dazu, dürfen Sie gerne mit uns Kontakt aufnehmen).

Umgebungen

Für die Produktentwicklung, bei der Code-Änderungen verschiedene Teststufen durchlaufen, braucht es typischerweise die folgenden Umgebungen:

  • dev: Entwicklungsumgebung
  • integration: Umgebung, welche durch Continuous Integration (CI) aktualisiert wird
  • release/hotfix: Bei Release Isolation (z.B. git flow)
  • acceptance: Umgebung für user acceptance tests (aka staging)
  • production: Produktive Umgebung

Ziel ist es, diese Umgebungen automatisch zu erstellen und das Deployment der Software automatisiert durchzuführen bzw. bereitzustellen (Manuelles Approval).

Prozessübersicht

Mit VSTS gibt es zwei Pipelines (Build und Release).

Buildpipeline

Die Buildpipeline ist für das automatisierte Testing sowie das Erstellen der Artefakte zuständig. In diesem Setup wird in dieser Pipeline ein Docker Image für den Microservice (Basis-Image & Binaries des Microservices) und die Konfiguration (Version, Namen des Images, etc.) erstellt, welche an das Releasemanagement weitergegeben wird.

Releasepipeline

Die Releasepipeline erstellt die Umgebung und deployed den Microservice auf Azure, indem sie das vom Build erstellte Docker-Image verwendet, um einen Docker Swarm-Mode Service  zu erstellen (https://docs.docker.com/engine/swarm/).

Buildpipeline

In der Buildpipeline werden folgende Tasks ausgeführt:

  1. Kompilierung des Source Codes
  2. Ausführen der automatisierten Tests
  3. Wenn die Tests erfolgreich waren, wird ein Docker-Image erstellt
  4. Das Docker-Image wird in die Azure Container Registry (https://azure.microsoft.com/en-us/services/container-registry/) hochgeladen
  5. Das eigentliche VSTS Build-Artefakt ist eine Konfigurationsdatei mit den Informationen über das erstellte Docker-Image (Name, Version)

Konfigurationsdatei
Die erstellte Datei ist eine Docker-compose Konfiguration (https://docs.docker.com/compose/compose-file/). Die Datei wird später von der Releasepipeline genutzt, um den Docker-Service zu erstellen.

Beispiel aus einem Build vom master-branch:

version: “3.5”
services:
    accountingservice:
      image: “novacaptach.azurecr.io/img-accountingservice-master:0.1.0
      environment:
          – ASPNETCORE_ENVIRONMENT=#{aspnetcore.environment}#
      deploy:
        placement:
          constraints:
            – node.role == worker
        labels:
          traefik.port: “#{traefik.port}#”
          traefik.enable: “#{traefik.enable}#”
          traefik.backend: “#{traefik.backend}#”
          traefik.frontend.rule: “#{traefik.frontend.rule}#”
networks:
  default:
    external: true
    name: traefik-net

Releasepipeline

Die Releasepipeline wird automatisch getriggert, sobald ein Build erfolgreich abgeschlossen wurde. Diese Pipeline ist dafür zuständig, die Services auf Azure bereitzustellen. Dies geschieht in den folgenden Schritten:

Je nach Umgebung und Setup kann es nötig sein, den automatischen Prozess zu unterbrechen und eine manuelle Bestätigung abzuwarten (Approval), die Installation zu einem bestimmten Zeitpunkt durchzuführen (Scheduled) oder sonstige Prozessschritte dazwischen zu schieben (Gates). Die Funktionalität kann in der VSTS-Release Konfiguration sehr einfach eingerichtet werden. Durch “Gates” wurde VSTS enorm flexibel. Gates erlauben momentan den Aufruf von Azure Functions, dem Azure Monitoring, einer Work Item Query (Prüfen des Counts) oder einer Custom REST API.

Danach loggt sich VSTS in den Swarm Manager ein und erstellt den Swam-Mode Service mit Hilfe der oben erwähnten Konfigurationsdatei.

Die drei letzten Schritte können in VSTS durch einen Task erledigt werden (Run a docker-command). Vorgängig muss allerdings noch die Konfigurations-Datei (aus dem Build) entsprechend der Zielumgebung angepasst werden. Dabei wird in einem VSTS Task (Replace Tokens – https://github.com/qetza/vsts-replacetokens-task) die Platzhalter “#{}#” mit den entsprechenden Werten ersetzt.

So kann beispielsweise eine fertige compose-Datei für den produktiven Release eines Service aussehen:

version: “3.5”
services:
    accountingservice:
      image: “novacaptach.azurecr.io/img-accountingservice-master:0.1.0”
      environment:
          – ASPNETCORE_ENVIRONMENT=production
      deploy:
        placement:
          constraints:
            – node.role == worker
        labels:
          traefik.port: “80
          traefik.enable: “true
          traefik.backend: “srv-accountingservice-production-master
          traefik.frontend.rule: “Host:accountingservice.apps.novacapta.ch
networks:
  default:
    external: true
    name: traefik-net

Durch den Befehl “docker stack deploy” und der Angabe des Konfigurationsfiles wird der Service nun in Azure erstellt oder aktualisiert.

Traefik

Traefik ist ein Reverse Proxy, Load Balancer und auch ein HTTPS Enabler (mit Hilfe von Let’s encrypt – https://letsencrypt.org/). Traefik läuft ebenso wie die oben beschriebenen Microservices im Swarm-Mode Cluster, unterstützt aber auch viele andere Provider.

https://docs.traefik.io/

Wir verwenden Traefik als Reverse Proxy, um unsere Services für die verschiedenen Umgebungen zu routen. Das Schöne daran ist, dass man sich um keine Ports kümmern muss und nur mit den Namen der Services arbeiten kann. Traefik überwacht die im Cluster vorhandenen oder neu erstellten Services. Einem Docker-Service können sogenannte Labels hinzugefügt werden, welche sich Traefik zunutze macht, um das Routing zu konfigurieren (traefik.port, traefik.backend, traefik.frontend.rule). Zudem wird der Zugriff von außen auf jeden Service automatisch HTTPS-enabled.

Voraussetzung für unseres Setup ist das einmalige Erstellen eines CNAME und eines Wilcard CNAME, welcher den Web-Traffic von apps.novacapta.ch bzw. *.apps.novacapta.ch auf die Azure Public-IP umleitet.

Fazit

VSTS, Azure, Docker und Traefik bilden ein kompetentes Gespann, mit welchem man die agile Produktentwicklung sehr gut im Griff hat. Eine sehr transparente, flexible und ausbaubare Lösung, die sich auch einfach skalieren lässt. Durch den Support verschiedenster Provider durch Traefik wäre auch ein Switch zu einem anderen Orchestrator (z.B. Kubernetes) nicht mehr aufwändig.

Bildnachweise

  • Microservices_Titelbild: Fotolia | Fotolia
By |2018-08-30T14:01:51+00:00August 30th, 2018|Azure|0 Comments

About the Author:

Senior IT-Architect

Leave a Reply

%d bloggers like this:

novaCapta verwendet Cookies, um die Funktionalität dieser Website zu verbessern. Durch die Nutzung dieser Seite stimmen Sie der Verwendung von Cookies zu. Weiterlesen

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close