So erstellen Sie eine effektive anfängliche Bereitstellungspipeline

Ich liebe es, Dinge zu bauen – welcher Entwickler tut das nicht? Ich liebe es, mir Lösungen für interessante Probleme auszudenken, Implementierungen zu schreiben und schönen Code zu erstellen. Was ich jedoch nicht mag, sind Operationen . Der Betrieb ist alles, was nicht zum Erstellen großartiger Software gehört – von der Einrichtung von Servern bis zur Auslieferung Ihres Codes an die Produktion.

Das ist interessant, weil ich als freiberuflicher Ruby on Rails-Entwickler häufig neue Webanwendungen erstellen und den Prozess wiederholen muss, die DevOps-Seite der Dinge herauszufinden. Glücklicherweise habe ich mich nach der Erstellung von Dutzenden von Anwendungen endlich für eine perfekte anfängliche Bereitstellungspipeline entschieden. Leider hat es nicht jeder so verstanden wie ich – schließlich hat mich dieses Wissen dazu gebracht, den Sprung zu wagen und meinen Prozess zu dokumentieren.

In diesem Artikel führe ich Sie durch meine perfekte Pipeline, die Sie zu Beginn Ihres Projekts verwenden können. Mit meiner Pipeline wird jeder Push getestet, der Master-Branch wird mit einem neuen Datenbank-Dump aus der Produktion für das Staging bereitgestellt, und versionierte Tags werden für die Produktion bereitgestellt, wobei Backups und Migrationen automatisch erfolgen.

Beachten Sie, dass es, da es meine Pipeline ist, auch rechthaberisch und für meine Bedürfnisse geeignet ist; Sie können jedoch alles, was Ihnen nicht gefällt, austauschen und durch das ersetzen, was Ihnen gefällt. Für meine Pipeline verwenden wir:

• GitLab zum Hosten von Code.
  • Warum: Meine Kunden ziehen es vor, dass ihr Code geheim bleibt, und die kostenlose Stufe von GitLab ist wunderbar. Auch das integrierte kostenlose CI ist großartig. Danke GitLab!
  • Alternativen: GitHub, BitBucket, AWS CodeCommit und viele mehr.
• GitLab CI zum Erstellen, Testen und Bereitstellen unseres Codes.
  • Warum: Es lässt sich in GitLab integrieren und ist kostenlos!
  • Alternativen: TravisCI, Codeship, CircleCI, DIY mit Fabric8 und viele mehr.
• Heroku zum Hosten unserer App.
  • Warum: Es funktioniert sofort und ist die perfekte Plattform für den Einstieg. Sie können dies in Zukunft ändern, aber nicht jede neue App muss auf einem speziell entwickelten Kubernetes-Cluster ausgeführt werden. Sogar Coinbase startete auf Heroku.
  • Alternativen: AWS, DigitalOcean, Vultr, DIY mit Kubernetes und viele mehr.

Old-School: Erstellen Sie eine Basis-App und stellen Sie sie in Heroku bereit

Lassen Sie uns zunächst eine typische Anwendung für jemanden neu erstellen, der keine ausgefallenen CI/CD-Pipelines verwendet und nur seine Anwendung bereitstellen möchte.

Es spielt keine Rolle, welche Art von App Sie erstellen, aber Sie benötigen Yarn oder npm. In meinem Beispiel erstelle ich eine Ruby on Rails-Anwendung, weil sie mit Migrationen und einer CLI geliefert wird, und ich habe bereits die Konfiguration dafür geschrieben. Sie können gerne ein beliebiges Framework oder eine beliebige Sprache verwenden, aber Sie benötigen Yarn, um die Versionierung vorzunehmen, die ich später mache. Ich erstelle eine einfache CRUD-App mit nur wenigen Befehlen und ohne Authentifizierung.

Und lassen Sie uns testen, ob unsere App wie erwartet läuft. Ich ging voran und erstellte ein paar Beiträge, nur um sicherzugehen.

Und stellen wir es in Heroku bereit, indem wir unseren Code pushen und Migrationen ausführen

 $ heroku create toptal-pipeline Creating ⬢ toptal-pipeline... done https://toptal-pipeline.herokuapp.com/ | https://git.heroku.com/toptal-pipeline.git $ git push heroku master Counting objects: 132, done. ... To https://git.heroku.com/toptal-pipeline.git * [new branch] master -> master $ heroku run rails db:migrate Running rails db:migrate on ⬢ toptal-pipeline... up, run.9653 (Free) ...

Testen wir es abschließend in der Produktion

Und das ist es! In der Regel verlassen die meisten Entwickler hier ihren Betrieb. Wenn Sie in Zukunft Änderungen vornehmen, müssen Sie die obigen Bereitstellungs- und Migrationsschritte wiederholen. Sie können sogar Tests durchführen, wenn Sie nicht zu spät zum Abendessen kommen. Dies ist ein großartiger Ausgangspunkt, aber lassen Sie uns etwas mehr über diese Methode nachdenken.

Vorteile

• Schnell einzurichten.
• Bereitstellungen sind einfach.

Nachteile

• Nicht TROCKEN: Erfordert die Wiederholung der gleichen Schritte bei jeder Änderung.
• Nicht versioniert: „Ich setze die Bereitstellung von gestern auf die Bereitstellung von letzter Woche zurück“ ist in drei Wochen nicht sehr genau.
• Kein Bad-Code-Proof: Sie wissen, dass Sie Tests durchführen sollten, aber niemand schaut zu, also könnten Sie es trotz gelegentlicher fehlerhafter Tests vorantreiben.
• Kein Beweis für schlechte Schauspieler: Was ist, wenn ein verärgerter Entwickler beschließt, Ihre App zu beschädigen, indem er Code mit einer Nachricht darüber drückt, dass Sie nicht genügend Pizzen für Ihr Team bestellen?
• Skaliert nicht: Jedem Entwickler die Möglichkeit zur Bereitstellung zu geben, würde ihm Zugriff auf die App auf Produktionsebene geben und gegen das Prinzip der geringsten Rechte verstoßen.
• Keine Staging-Umgebung: Fehler, die für die Produktionsumgebung spezifisch sind, werden erst in der Produktion angezeigt.

Die perfekte anfängliche Bereitstellungspipeline

Ich werde heute etwas anderes versuchen: Lassen Sie uns ein hypothetisches Gespräch führen. Ich werde „Dir“ eine Stimme geben und wir werden darüber sprechen, wie wir diesen Stromfluss verbessern können. Los, sag was.

Sag was? Warte – ich kann reden?

Ja, das meinte ich damit, dir eine Stimme zu geben. Wie geht es dir?

Mir geht es gut. Das fühlt sich komisch an

Ich verstehe, aber rollen Sie damit. Lassen Sie uns nun über unsere Pipeline sprechen. Was ist das Ärgerlichste am Ausführen von Bereitstellungen?

Ach, das ist einfach. Die Menge an Zeit, die ich verschwende. Haben Sie jemals versucht, nach Heroku zu pushen?

Ja, es ist schrecklich, zuzusehen, wie Ihre Abhängigkeiten heruntergeladen und Anwendungen als Teil des git push Pushs erstellt werden!

Ich weiß es schon gut? Das ist verrückt. Ich wünschte, ich müsste das nicht tun. Es gibt auch die Tatsache, dass ich Migrationen *nach* der Bereitstellung ausführen muss, also muss ich mir die Show ansehen und überprüfen, ob meine Bereitstellung durchläuft

Okay, Sie könnten das letztere Problem tatsächlich lösen, indem Sie die beiden Befehle mit && verketten, wie git push heroku master && heroku run rails db:migrate , oder einfach ein Bash-Skript erstellen und es in Ihren Code einfügen, aber trotzdem eine großartige Antwort, die Zeit und Wiederholung ist ein echter Schmerz.

Ja, es ist wirklich scheiße

Was wäre, wenn ich Ihnen sagen würde, dass Sie dieses Bit sofort mit einer CI/CD-Pipeline beheben könnten?

Ein was jetzt? Was ist das?

CI/CD steht für Continuous Integration (CI) und Continuous Delivery/Deployment (CD). Es war ziemlich schwierig für mich, genau zu verstehen, was es war, als ich anfing, weil alle vage Begriffe wie „Zusammenlegung von Entwicklung und Betrieb“ verwendeten, aber einfach ausgedrückt:

• Kontinuierliche Integration: Stellen Sie sicher, dass Ihr gesamter Code an einem Ort zusammengeführt wird. Bringen Sie Ihr Team dazu, Git zu verwenden, und Sie werden CI verwenden.
• Kontinuierliche Lieferung: Stellen Sie sicher, dass Ihr Code kontinuierlich versandbereit ist. Das bedeutet, schnell eine Read-to-Distribution-Version Ihres Produkts zu erstellen.
• Kontinuierliche Bereitstellung: Das Produkt wird nahtlos aus der kontinuierlichen Bereitstellung übernommen und einfach auf Ihren Servern bereitgestellt.

Oh, jetzt verstehe ich es. Es geht darum, meine App auf magische Weise in der Welt bereitzustellen!

Mein Lieblingsartikel zur Erklärung von CI/CD ist von Atlassian hier. Dies sollte alle Fragen klären, die Sie haben. Wie auch immer, zurück zum Problem.

Ja, zurück dazu. Wie vermeide ich manuelle Bereitstellungen?

Einrichten einer CI/CD-Pipeline zum Bereitstellen auf Push-to master

Was wäre, wenn ich Ihnen sagen würde, dass Sie dieses Bit sofort mit einem CI/CD beheben könnten? Sie können auf Ihre GitLab-Fernbedienung ( origin ) pushen und ein Computer wird gespawnt, um einfach Ihren Code an Heroku zu pushen.

Auf keinen Fall!

Ja Weg! Lassen Sie uns wieder zurück in den Code springen.

Erstellen Sie eine .gitlab-ci.yml mit den folgenden Inhalten und tauschen toptal-pipeline gegen den Namen Ihrer Heroku-App aus:

 image: ruby:2.4 before_script: - > : "${HEROKU_EMAIL:?Please set HEROKU_EMAIL in your CI/CD config vars}" - > : "${HEROKU_AUTH_TOKEN:?Please set HEROKU_AUTH_TOKEN in your CI/CD config vars}" - curl https://cli-assets.heroku.com/install-standalone.sh | sh - | cat >~/.netrc <<EOF machine api.heroku.com login $HEROKU_EMAIL password $HEROKU_AUTH_TOKEN machine git.heroku.com login $HEROKU_EMAIL password $HEROKU_AUTH_TOKEN EOF - chmod 600 ~/.netrc - git config --global user.email "[email protected]" - git config --global user.name "CI/CD" variables: APPNAME_PRODUCTION: toptal-pipeline deploy_to_production: stage: deploy environment: name: production url: https://$APPNAME_PRODUCTION.herokuapp.com/ script: - git remote add heroku https://git.heroku.com/$APPNAME_PRODUCTION.git - git push heroku master - heroku pg:backups:capture --app $APPNAME_PRODUCTION - heroku run rails db:migrate --app $APPNAME_PRODUCTION only: - master

Schieben Sie dies nach oben und beobachten Sie, wie es auf der Pipelines-Seite Ihres Projekts fehlschlägt. Das liegt daran, dass die Authentifizierungsschlüssel für Ihr Heroku-Konto fehlen. Das zu beheben ist jedoch ziemlich einfach. Zuerst benötigen Sie Ihren Heroku- API-Schlüssel . Rufen Sie es von der Seite „Konto verwalten“ ab und fügen Sie dann die folgenden geheimen Variablen in den CI/CD-Einstellungen Ihres GitLab-Repos hinzu:

• HEROKU_EMAIL : Die E-Mail-Adresse, mit der Sie sich bei Heroku anmelden
• HEROKU_AUTH_KEY : Der Schlüssel, den du von Heroku bekommen hast

Dies sollte dazu führen, dass bei jedem Push ein funktionierendes GitLab für Heroku bereitgestellt wird. Was passiert:

• Beim Drücken zum Meister
  • Die Heroku-CLI wird in einem Container installiert und authentifiziert.
  • Ihr Code wird an Heroku gepusht.
  • Eine Sicherung Ihrer Datenbank wird in Heroku erfasst.
  • Migrationen werden ausgeführt.

Sie können bereits sehen, dass Sie nicht nur Zeit sparen, indem Sie alles zu einem git push automatisieren, sondern auch bei jedem Deployment ein Backup Ihrer Datenbank erstellen! Wenn jemals etwas schief geht, haben Sie eine Kopie Ihrer Datenbank, auf die Sie zurückgreifen können.

Erstellen einer Staging-Umgebung

Aber Moment mal, kurze Frage, was passiert mit Ihren produktionsspezifischen Problemen? Was ist, wenn Sie auf einen seltsamen Fehler stoßen, weil sich Ihre Entwicklungsumgebung zu stark von der Produktionsumgebung unterscheidet? Ich bin einmal auf einige seltsame SQLite 3- und PostgreSQL-Probleme gestoßen, als ich eine Migration durchgeführt habe. Die Einzelheiten entziehen sich mir, aber es ist durchaus möglich.

Ich verwende ausschließlich PostgreSQL in der Entwicklung, ich passe niemals solche Datenbank-Engines an und überwache meinen Stack gewissenhaft auf mögliche Inkompatibilitäten.

Nun, das ist mühsame Arbeit und ich begrüße Ihre Disziplin. Dazu bin ich persönlich viel zu faul. Können Sie dieses Maß an Sorgfalt jedoch allen potenziellen zukünftigen Entwicklern, Mitarbeitern oder Mitwirkenden garantieren?

Errrr – Ja, nein. Da haben Sie mich erwischt. Andere Leute werden es vermasseln. Was ist Ihr Punkt, obwohl?

Mein Punkt ist, Sie brauchen eine Staging-Umgebung. Es ist wie Produktion, ist es aber nicht. In einer Staging-Umgebung proben Sie die Bereitstellung für die Produktion und erkennen alle Ihre Fehler frühzeitig. Meine Staging-Umgebungen spiegeln normalerweise die Produktion wider, und ich speichere eine Kopie der Produktionsdatenbank bei der Staging-Bereitstellung, um sicherzustellen, dass keine lästigen Sonderfälle meine Migrationen durcheinander bringen. Mit einer Staging-Umgebung können Sie aufhören, Ihre Benutzer wie Versuchskaninchen zu behandeln.

Das macht Sinn! Wie mache ich das?

Hier wird es interessant. Ich setze master gerne direkt für Staging ein.

Warten Sie, ist das nicht der Ort, an dem wir gerade die Produktion bereitstellen?

Ja, das ist es, aber jetzt werden wir stattdessen auf Staging setzen.

Aber wenn der master für das Staging bereitgestellt wird, wie stellen wir es dann für die Produktion bereit?

Indem Sie etwas verwenden, was Sie schon vor Jahren hätten tun sollen: Unseren Code versionieren und Git-Tags pushen.

Git-Tags? Wer verwendet Git-Tags?! Das hört sich nach viel Arbeit an.

Das war es sicher, aber zum Glück habe ich all diese Arbeit bereits erledigt und Sie können einfach meinen Code ausgeben und es wird funktionieren.

Fügen Sie Ihrer .gitlab-ci.yml Datei zuerst einen Block über die Staging-Bereitstellung hinzu. Ich habe eine neue Heroku-App namens toptal-pipeline-staging erstellt:

 … variables: APPNAME_PRODUCTION: toptal-pipeline APPNAME_STAGING: toptal-pipeline-staging deploy_to_staging: stage: deploy environment: name: staging url: https://$APPNAME_STAGING.herokuapp.com/ script: - git remote add heroku https://git.heroku.com/$APPNAME_STAGING.git - git push heroku master - heroku pg:backups:capture --app $APPNAME_PRODUCTION - heroku pg:backups:restore `heroku pg:backups:url --app $APPNAME_PRODUCTION` --app $APPNAME_STAGING --confirm $APPNAME_STAGING - heroku run rails db:migrate --app $APPNAME_STAGING only: - master - tags ...

Ändern Sie dann die letzte Zeile Ihres Produktionsblocks so, dass sie auf semantisch versionierten Git-Tags statt auf dem Master-Branch ausgeführt wird:

 deploy_to_production: ... only: - /^v(?'MAJOR'(?:0|(?:[1-9]\d*)))\.(?'MINOR'(?:0|(?:[1-9]\d*)))\.(?'PATCH'(?:0|(?:[1-9]\d*)))(?:-(?'prerelease'[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*))?(?:\+(?'build'[0-9A-Za-z-]+(\.[0-9A-Za-z-]+)*))?$/ # semver pattern above is adapted from https://github.com/semver/semver.org/issues/59#issuecomment-57884619

Wenn Sie dies jetzt ausführen, wird dies fehlschlagen, da GitLab intelligent genug ist, um nur „geschützten“ Zweigen Zugriff auf unsere geheimen Variablen zu gewähren. Um Versions-Tags hinzuzufügen, gehen Sie zur Seite mit den Repository-Einstellungen Ihres GitLab-Projekts und fügen Sie v* zu geschützten Tags hinzu.

Fassen wir zusammen, was jetzt passiert:

• Beim Pushen zum Master oder beim Pushen eines gekennzeichneten Commits
  • Die Heroku-CLI wird in einem Container installiert und authentifiziert.
  • Ihr Code wird an Heroku gepusht.
  • Ein Backup Ihrer Datenbankproduktion wird in Heroku erfasst.
  • Die Sicherung wird in Ihrer Staging-Umgebung abgelegt.
  • Migrationen werden auf der Staging-Datenbank ausgeführt.
• Beim Pushen eines semantisch mit einer Version gekennzeichneten Commits
  • Die Heroku-CLI wird in einem Container installiert und authentifiziert.
  • Ihr Code wird an Heroku gepusht.
  • Ein Backup Ihrer Datenbankproduktion wird in Heroku erfasst.
  • Migrationen werden auf der Produktionsdatenbank ausgeführt.

Fühlst du dich jetzt stark? Ich fühle mich mächtig. Ich erinnere mich, als ich das erste Mal so weit kam, rief ich meine Frau an und erklärte diese gesamte Pipeline in entsetzlichen Details. Und sie ist nicht einmal technisch. Ich war super beeindruckt von mir selbst und du solltest es auch sein! Großartige Arbeit, die so weit gekommen ist!

Jeden Push testen

Aber es gibt noch mehr, da ein Computer sowieso Dinge für Sie erledigt, könnte er auch all die Dinge ausführen, für die Sie zu faul sind: Tests, Linting-Fehler, so ziemlich alles, was Sie tun möchten, und wenn eines davon fehlschlägt, haben sie gewonnen nicht zum Einsatz übergehen.

Ich liebe es, das in meiner Pipeline zu haben, es macht meine Code-Reviews lustig. Wenn eine Merge-Anfrage alle meine Code-Checks besteht, verdient sie es, überprüft zu werden.

Fügen Sie einen test hinzu:

 test: stage: test variables: POSTGRES_USER: test POSTGRES_PASSSWORD: test-password POSTGRES_DB: test DATABASE_URL: postgres://${POSTGRES_USER}:${POSTGRES_PASSSWORD}@postgres/${POSTGRES_DB} RAILS_ENV: test services: - postgres:alpine before_script: - curl -sL https://deb.nodesource.com/setup_8.x | bash - apt-get update -qq && apt-get install -yqq nodejs libpq-dev - curl -o- -L https://yarnpkg.com/install.sh | bash - source ~/.bashrc - yarn - gem install bundler --no-ri --no-rdoc - bundle install -j $(nproc) --path vendor - bundle exec rake db:setup RAILS_ENV=test script: - bundle exec rake spec - bundle exec rubocop

Fassen wir zusammen, was jetzt passiert:

• Bei jeder Push- oder Merge-Anfrage
  • Ruby und Node werden in einem Container eingerichtet.
  • Abhängigkeiten werden installiert.
  • Die App ist getestet.
• Beim Pushen zum Master oder beim Pushen eines markierten Commits und nur, wenn alle Tests bestanden wurden
  • Die Heroku-CLI wird in einem Container installiert und authentifiziert.
  • Ihr Code wird an Heroku gepusht.
  • Ein Backup Ihrer Datenbankproduktion wird in Heroku erfasst.
  • Die Sicherung wird in Ihrer Staging-Umgebung abgelegt.
  • Migrationen werden auf der Staging-Datenbank ausgeführt.
• Beim Pushen eines semantisch mit einer Version gekennzeichneten Commit und nur, wenn alle Tests bestanden wurden
  • Die Heroku-CLI wird in einem Container installiert und authentifiziert.
  • Ihr Code wird an Heroku gepusht.
  • Ein Backup Ihrer Datenbankproduktion wird in Heroku erfasst.
  • Migrationen werden auf der Produktionsdatenbank ausgeführt.

Treten Sie einen Schritt zurück und staunen Sie über den Automatisierungsgrad, den Sie erreicht haben. Von nun an müssen Sie nur noch Code schreiben und pushen. Testen Sie Ihre App manuell in Staging, wenn Sie Lust dazu haben, und wenn Sie sich sicher genug fühlen, sie der Welt zu präsentieren, markieren Sie sie mit semantischer Versionierung!

Automatische semantische Versionierung

Ja, es ist perfekt, aber irgendetwas fehlt. Ich mag es nicht, die letzte Version der App nachzuschlagen und sie explizit zu markieren. Das erfordert mehrere Befehle und lenkt mich für ein paar Sekunden ab.

Okay, Alter, hör auf! Das ist genug. Du übertreibst es jetzt nur noch. Es funktioniert, es ist brillant, ruiniere nichts Gutes, indem du es übertreibst.

Okay, ich habe einen guten Grund für das, was ich tun werde.

Bitte, erleuchte mich.

Früher war ich wie du. Ich war mit diesem Setup zufrieden, aber dann habe ich es vermasselt. git tag listet Tags in alphabetischer Reihenfolge auf, v0.0.11 ist höher als v0.0.2 . Ich habe einmal versehentlich eine Veröffentlichung getaggt und dies für etwa ein halbes Dutzend Veröffentlichungen fortgesetzt, bis ich meinen Fehler sah. Da habe ich mich entschieden, das auch zu automatisieren.

Jetzt geht das schon wieder los

Okay, zum Glück haben wir die Leistungsfähigkeit von npm zur Verfügung, also habe ich ein passendes Paket gefunden: Führen yarn add --dev standard-version und fügen Sie Ihrer package.json -Datei Folgendes hinzu:

 "scripts": { "release": "standard-version", "major": "yarn release --release-as major", "minor": "yarn release --release-as minor", "patch": "yarn release --release-as patch" },

Jetzt müssen Sie noch eine letzte Sache tun, Git so konfigurieren, dass Tags standardmäßig gepusht werden. Im Moment müssen Sie git push --tags , um ein Tag nach oben zu pushen, aber dies automatisch bei regulärem git push zu tun, ist so einfach wie das Ausführen von git config --global push.followTags true .

So verwenden Sie Ihre neue Pipeline, wenn Sie einen Release-Lauf erstellen möchten:

• yarn patch für Patch-Releases
• yarn minor für kleinere Veröffentlichungen
• yarn major für Hauptversionen

Wenn Sie sich nicht sicher sind, was die Wörter „Major“, „Minor“ und „Patch“ bedeuten, lesen Sie mehr darüber auf der Website zur semantischen Versionierung.

Nachdem Sie Ihre Pipeline nun endlich fertiggestellt haben, lassen Sie uns noch einmal zusammenfassen, wie Sie sie verwenden!

• Code schreiben.
• Committen und pushen Sie es zum Testen und stellen Sie es für das Staging bereit.
• Verwenden Sie yarn patch , um eine Patch-Veröffentlichung zu markieren.
• git push , um es in die Produktion zu bringen.

Zusammenfassung und weitere Schritte

Ich habe gerade erst an der Oberfläche dessen gekratzt, was mit CI/CD-Pipelines möglich ist. Dies ist ein ziemlich vereinfachtes Beispiel. Sie können so viel mehr tun, indem Sie Heroku durch Kubernetes ersetzen. Wenn Sie sich für die Verwendung von GitLab CI entscheiden, lesen Sie die yaml-Dokumentation, denn es gibt so viel mehr, was Sie tun können, indem Sie Dateien zwischen Bereitstellungen zwischenspeichern oder Artefakte speichern!

Eine weitere große Änderung, die Sie an dieser Pipeline vornehmen könnten, ist die Einführung externer Trigger, um die semantische Versionierung und Freigabe auszuführen. Derzeit ist ChatOps Teil ihres kostenpflichtigen Plans, und ich hoffe, sie veröffentlichen ihn für kostenlose Pläne. Aber stellen Sie sich vor, Sie könnten das nächste Bild durch einen einzigen Slack-Befehl auslösen!

Wenn Ihre Anwendung komplex wird und Abhängigkeiten auf Systemebene erforderlich sind, müssen Sie möglicherweise einen Container verwenden. Lesen Sie in diesem Fall unseren Leitfaden: Erste Schritte mit Docker: Vereinfachen von Devops .

Diese Beispiel-App ist wirklich live, und Sie können den Quellcode dafür hier finden.