Komplexe Szenarien: Hybrid, VM-Vorlagen, selbst gehostete Runner und Agents im Betrieb

Die Nordlicht Reisen GmbH betreibt eine Zahlungsdatenbank im eigenen Rechenzentrum; sie ist aus dem Internet nicht erreichbar, und Datenbankänderungen werden auf zwei Servern im Rechenzentrum ausgerollt. Die Anwendung selbst wird in Azure gebaut und getestet. Die Build-Rechner brauchen ein Werkzeug, das auf den gehosteten Rechnern fehlt, und das Team will die Rechner nicht mehr von Hand aufsetzen. Sie sollen das Zusammenspiel entwerfen: eine hybride Pipeline, ein selbst gebautes VM-Image und den Betrieb der Agents und Runner. Das sind die Fähigkeiten dieser Lektion: komplexe Pipeline-Szenarien, nämlich hybride Pipelines, VM-Vorlagen und selbst gehostete Runner und Agents.

Vorwissen: Die Arten von Agents und Runnern, ihre Kosten und Grenzen hat Lektion 4.2 verglichen, die Umgebungen und Prüfungen in YAML führt Lektion 4.7 aus, die Bereitstellungsstrategien Lektion 4.8. Warum fremder Code nicht auf einen selbst gehosteten Rechner gehört, steht in K3, Lektion 3.7.7. Diese Lektion zeigt, wie Sie die Mittel zusammensetzen und betreiben.

Nicht gegen Azure oder GitHub ausgeführt; aus der Referenz von Microsoft und GitHub: Alle Befehle und YAML-Dateien dieser Lektion stammen aus der Dokumentation und sind in diesem Kurs nicht ausgeführt worden.

Hybride Pipelines

Hybrid heißt hier: Ein Teil der Arbeit läuft in der Cloud, ein Teil in einem Netz, das die Cloud nicht erreicht. Die Frage ist immer dieselbe: Wer baut die Verbindung auf, und von wo?

Das Prinzip: Der Agent holt

Laut Microsoft kommuniziert der Agent immer selbst mit Azure Pipelines: Er fragt über eine HTTP-Langabfrage (long poll) die Jobwarteschlange ab, lädt einen Job mit einem kurzlebigen, auf den Job begrenzten Token herunter, führt ihn aus und meldet Protokolle und Ergebnis zurück. Alle Nachrichten laufen über HTTP oder HTTPS, die Nutzlast ist mit einem asymmetrischen Schlüsselpaar des Agents verschlüsselt, das bei der Registrierung ausgetauscht wird. Dieses Pull-Modell erlaubt ihm den Betrieb hinter einer Firewall ohne eingehende Verbindungen. Bei GitHub gilt dasselbe: Der Runner baut ausgehende HTTPS-Verbindungen über Port 443 auf (Lektion 4.2).

Für eine Bereitstellung braucht der Agent außerdem „line of sight“ zu den Zielen. Microsoft sagt dazu: Haben lokale Umgebungen keine Verbindung zum gehosteten Pool, was wegen Firewalls der Normalfall ist, müssen Sie selbst gehostete Agents auf Rechnern im Firmennetz einrichten, die das Ziel und das Internet erreichen. Gehostete Agents lassen sich per ExpressRoute oder VPN nicht ans Firmennetz binden.

Drei Wege zum Ziel im Firmennetz

1. Selbst gehosteter Agent oder Runner im Firmennetz. Er führt den Auslieferungs-Job aus; gebaut wird weiter im gehosteten Pool, das Artefakt wandert über Azure Pipelines (Aufgaben PublishPipelineArtifact@1 und DownloadPipelineArtifact@2) zum Agent.
2. Ein Pool im eigenen Netz. Scale Set agents liegen in Ihrem VNet; für Managed DevOps Pools delegieren Sie ein Subnetz Ihres virtuellen Netzes an den Dienst (Lektion 4.2). Bei GitHub sind larger runners mit Azure Private Networking das Gegenstück, und für Kubernetes ARC.
3. Umgebungs-VMs. Ein Agent läuft auf dem Zielrechner und ist als Ressource einer Umgebung registriert. Der Auslieferungs-Job läuft direkt dort.

Der dritte Weg in Azure Pipelines: Sie legen unter Pipelines, Environments eine Umgebung an, wählen als Ressource Virtual machines und kopieren das Registrierungsskript (es enthält ein PAT des angemeldeten Benutzers, das drei Stunden nach der Erzeugung abläuft und nur zum Installieren des Agents dient). Das Skript führen Sie auf jedem Zielrechner aus, Linux oder Windows; die Rechner erscheinen unter Resources der Umgebung. Mit Markierungen (tags) wählen Sie Rechner aus:

jobs:
  - deployment: VMDeploy
    displayName: Deploy to VM
    environment:
      name: VMenv
      resourceType: virtualMachine
      tags: windows,prod
    strategy:
      runOnce:
        deploy:
          steps:
            - script: echo "Hello world"

Mehrere Tags bedeuten: Der Job läuft nur auf Rechnern, die alle tragen. Ein Deployment-Job hat den Lebenszyklus preDeploy, deploy, routeTraffic, postRouteTraffic und danach on: success oder on: failure; bei Umgebungs-VMs läuft preDeploy auf dem Build-Agent, alles andere auf den registrierten VMs. Die Rechner müssen daher die Werkzeuge haben, die die Schritte brauchen (zum Beispiel die Azure CLI). runOnce führt die Schritte einmal je VM aus, ohne Parallelität; die Strategie rolling arbeitet mit Gruppen von bis zu fünf Zielrechnern, abhängig von maxParallel, das auch die Mindestzahl verfügbarer Rechner bestimmt (Lektion 4.8 und 4.9). Zum Entfernen einer VM aus der Umgebung führen Sie auf dem Rechner ./config.sh remove (Linux) bzw. ./config.cmd remove aus einer Administrator-PowerShell (Windows) aus.

Bereitstellungsgruppen (deployment groups) gibt es nur für klassische Release-Pipelines; für YAML nutzen Sie Umgebungen mit VM-Ressourcen.

Beide Welten, ein Muster