Enterprise private Docker Registrierung Best Practices

Question

Dies ist eine Frage, die mir in den Sinn kam, als wir uns auf die Einführung unserer eigenen privaten Registrierung vorbereiten. Was ist eine Unternehmens Best Practice und warum?

Q1:

1. Run mehrere Register mit 1 S3 Speicher-Backend? Jede Registrierung hätte eine Einstellung, die dazu führt, dass sie auf die Ordner "dev", "qa" oder "prod" (oberste Ebene) im selben S3-Bucket verweist.

2. Führen Sie 1 Registrierung mit 1 S3-Speicher-Backend für alle Umgebungen von dev/qa/prod aus? Da der Sinn von Docker darin liegt, dass das Bild überall gleich ausgeführt wird, würden wir nur verschiedene Docker-Run-Parameter zur Verfügung stellen, da das Docker-Image selbst genau in env identisch ist, nur die von Ihnen übergebenen Argumente sind unterschiedlich.

3. Run 1 Registry und 1 S3 Speicher-Backend pro env

Q2:

Was ist die beste Praxis ein Bild von dev ganzen Weg zur Förderung der prod? Welche Werkzeugsätze sind beteiligt? Zum Beispiel haben wir ein zentrales Gitlab für unsere Dockerfiles. Wenn wir unsere neue Dockerfile einchecken, gibt es einen Hook, der Jenkins dazu veranlasst, das Image aus dieser Dockerdatei zu erstellen und es in der Registrierung zu überprüfen. Was wäre ein guter Weg, um die Bilder auf die nächste Ebene - qa, und schließlich prod?

Q3:

Wenn Sie einen Ihrer Basisbilder aktualisieren, was für ein guter Weg, um die Änderung auf andere Bilder in der Registrierung ausbreitet stromaufwärts, um sicherzustellen? Zum Beispiel aktualisieren Sie Ihre angepasste Basis-Ubuntu-Dockerdatei mit neuen Inhalten und möchten, dass die anderen Docker-Dateien, die dieses Basisimage verwenden, neu erstellt und in die Registrierung verschoben werden, damit die Änderung automatisch weitergegeben wird.

Q4:

Hat es eine Rolle in all den oben spielen, wenn Sie verschiedene AWS-Konten haben, 1 für DEV, eine für QA, eine für ART usw.

Answer 1

Wir entschieden uns für Ihre Option Nummer zwei . Ich beschreibe einfach, was wir verwenden, und obwohl wir keine große Unternehmensumgebung sind (einige hundert Container laufen zu einem bestimmten Zeitpunkt), wird es Ihnen vielleicht einige Ideen geben. Wir bleiben bei einem einzigen S3-Backend/Bucket (für ein einzelnes Konto) für alle unsere "Arten" von Bildern und benennen die Bilder entsprechend. Der Trick dabei ist, dass unsere "Entwicklungs" -Umgebungen im Grunde "Produktions" -Umgebungen sind. Dies ist von zentraler Bedeutung für unser gesamtes Design und unser Hauptgrund für die Verwendung von Docker: Unsere Entwicklungsumgebung soll die Produktionsumgebung so weit wie möglich widerspiegeln. Wir verfügen über mehrere Produktionsmaschinen für spezielle Hardware in einigen geografisch getrennten Rechenzentren und führen unsere Bilder zusätzlich zu diesen aus. Wir verwenden einen Standard-Git-Workflow, um Code und Änderungen voranzutreiben. Wir verwenden derzeit Bitbucket (und einen Spiegel mit unserem eigenen selbst gehosteten Gitlab) und führen Tests auf jedem Push durch, um mit Shippable (großer Fan von Lieferbar hier!) Zu meistern. Wir koordinieren alles mit einer benutzerdefinierten Software, die Webhooks auf einem "Head" -Server abhört, der dann das/docker/image erstellt und das Docker-Image an unsere private Registry sendet (an einem Punkt wurde es auch auf demselben "Kopf" gehostet) Server). Dann hakt diese benutzerdefinierte Software mit einem sehr einfachen benutzerdefinierten Server auf jedem Produktionsrechner, der die neuen Bilder aus der privaten Registry holt und den neuen Container anstelle des alten abstellt. Wir verwenden den unglaublichen und fantastischen nginx-proxy Reverse Proxy von Jason Wilder auf all unseren Docker-Maschinen, was diesen Prozess erheblich einfacher macht als ohne.Wenn Sie einige besondere Anforderungen an die Trennung dieser Dev/QA/Prod-Images voneinander haben, würde ich vorschlagen, dieses Backend so wenig wie möglich zu verwenden, um nur mehr mögliche Fehlerquellen zu vermeiden. Die wahre Stärke von Docker ist die Einheitlichkeit der Umgebungen, die Sie erstellen können. Wenn wir den Switch für die Aufgabe eines Containers von der Entwicklung zur QA in die Produktion "umdrehen", ändern wir lediglich die Portnummer, die der Container von unserem "dev/QA" -Port an die "production" -Portnummer anhört, und verfolgen diese Änderungen in unserem internen Tracker. Wir verwenden mehrere A-Datensätze in DNS, um "Lastenausgleich" zu erreichen, und mussten (noch) nicht auf tatsächliche Load-Balancer skalieren, aber wahrscheinlich würden wir die Load-Balancing-Funktion des nginx-proxy-Images verwenden, das wir so lieben viel, da es bereits ein eingebautes Feature ist.

Wenn wir aus irgendeinem Grund unser Basis-Image ändern müssen, nehmen wir die Änderungen in der Umgebung (Updates, was auch immer) vor und arbeiten dann FROM in unserer neuen Dockerfile. Diese Änderungen werden dann in das neue Image übernommen, das in unsere private Registry verschoben wird, die dann wie jedes andere "normale" Code-Push zur Produktion weitergeleitet wird. Ich sollte beachten, dass wir alle unserer Daten auf S3 (nicht nur unsere Endprodukt-Docker Bilder) spiegeln, falls etwas tragisches passiert und wir müssen einen neuen "Kopf" -Server (der selbst Docker für alle verwendet seine Funktionen). FWIW, das war für uns ein Preisbruch, da wir jetzt auf Commodity-dedizierte Hardware anstatt auf EC2 umsteigen konnten. Viel Glück!