Docker ist heutzutage quasi überall. Auch wir setzen natürlich auf Containerisierung, sowohl beim Bau von Anwendungen, als auch beim Deployment. Aber was passiert nun, wenn die Infrastruktur mal nicht verfügbar ist?

Was ist passiert

Montagmorgen, kurz nach 8, ein Kunde ruft an: „Wir können kein Deployment machen – könnt ihr mal schauen?“

Ein schneller Blick in die GitLab CI und die Ursache ist klar: Die Docker Registry liefert beharrlich 503er (Service Unavailable) zurück. Okay, besser als ein Timeout, aber warum?

Die Ursache

Eine massive Störung bei AWS. Davon betroffen ist nicht nur die Infrastruktur hinter der Docker Registry, sondern auch viele andere Dienste, etwa Atlassian, Salesforce und Slack.

Alle diese Dienste nutzen im Hintergrund die Cloud-Infrastruktur von AWS – und steht diese nicht zur Verfügung, gehen schlicht die Lichter aus.

Die Lösung

Eine einfache Lösung für Docker-Nutzer gibt es leider nicht, auch Alternativen, etwa quay.io sind betroffen. Wir verwenden unsere Gitlab-Instanz auch als Image-Cache, aber das Ziehen neuer Images ist in dieser Situation nicht möglich. Das Bauen mit gecachten Images funktioniert, neue Versionen oder bislang nicht gecachte Images zu nutzen aber nicht.

Auf Docker zu verzichten ist realistisch betrachtet auch nicht möglich; zumindest aber nicht sinnvoll, so ehrlich muss man sein.

Unterm Strich bleibt damit eigentlich nur festzustellen, dass Abhängigkeiten immer kritisch hinterfragt werden müssen. Direkte Abhängigkeiten zu AWS lassen sich lösen, etwa dadurch dass man seine Software selbst hostet. Aber die Abhängigkeiten der Abhängigkeiten lassen sich nicht so einfach ändern.

Neben der Verfügbarkeit ist das im übrigen auch ein Problem der Sicherheit, wie sich in der letzten Zeit immer wieder durch Supply-Chain-Angriffe auf NPM zeigt.