Commit ae97f391 authored by Nane Kratzke's avatar Nane Kratzke
Browse files

Finished Lab 05

parent f2f8f8dd
# Lab 05: Containerization
to be done
In diesem Lab lernen Sie die Tool-Chain kennen, um Applikationen als standardisierte Deployment Units (Container-Images) bereitstellen zu können. Dies funktioniert sowohl lokal auf einem Entwicklungsrechner (z.B. Ihrem Laptop) als auch im Rahmen von Deployment Pipelines (d.h. in Remote Building Environments wie bspw. Gitlab CI/CD).
Die Standardisierung von Deployment Units in Form von Containern ist ein zentrales Merkmal der Entwicklung Cloud-nativer Anwendungen.
Die hier vorgestellten Prinzipien können Sie daher problemlos auf weitere Cloud-native Projekte übertragen.
## Inhalt
......@@ -15,7 +17,7 @@ to be done
- [Aufgabe 03.2: Image Layer einsparen](#aufgabe-032-image-layer-einsparen)
- [Aufgabe 03.3: Kleinere Basis Images nutzen](#aufgabe-033-kleinere-basis-images-nutzen)
- [Übung 04: Push von einem Image in eine Registry](#übung-04-push-von-einem-image-in-eine-registry)
- [Übung 05: Pipeline zum Bau und Test eines Images](#übung-05-pipeline-zum-bau-und-test-eines-images)
- [Übung 05: Deployment-Pipeline zum Bau und Test eines Images](#übung-05-deployment-pipeline-zum-bau-und-test-eines-images)
- [Quellen und Referenzen](#quellen-und-referenzen)
- [Was sollten Sie mitnehmen ...](#was-sollten-sie-mitnehmen-)
......@@ -36,7 +38,7 @@ to be done
## Übung 02: Erstellung von einem Image
Sie werden in diesem Teil sehen, wie man Images baut. Häufig benötigt man Images für spezfische Dienste, wie bspw. Datenbanken, Webserver, usw. Hierfür bieten die Hersteller meist vorkonfigurierte Images an, die man nur noch mit einer kleinen Konfiguration (z.B. Access Credentials, Dateipfade, etc.) auf die spezifischen Bedürfnisse anpassen muss. Man kann aber auch Images auf Basis einer Standard Linux-Distribution aufsetzen. Sie werden beides am Beispiel eines kleinen Webservers sehen.
Sie werden in diesem Teil sehen, wie man Images baut. Häufig benötigt man Images für spezfische Dienste, wie bspw. Datenbanken, Webserver, usw. Hierfür bieten die Hersteller meist vorkonfigurierte Images an, die man nur noch mit einer kleinen Konfiguration (z.B. Access Credentials, Dateipfade, etc.) auf die spezifischen Bedürfnisse anpassen muss. Es lohnt sich hierzu öffentliche Image Repositories wie [Dockerhub](https://hub.docker.com) zu durchsuchen. Man kann aber auch Images auf Basis einer Standard Linux-Distribution aufsetzen. Sie werden beides am Beispiel eines kleinen Webservers sehen.
Klonen Sie sich bitte hierzu als Vorbereitung dieses Repository mittels:
......@@ -60,16 +62,18 @@ cd lab-containerization
![screenshot](index.html.png)
7. Beenden Sie den HTTP-Service in dem Sie in Ihrer Konsole CTRL-C drücken (Sie senden damit das SIGTERM Signal an den NGINX Server-Prozess und der Container wird terminiert).
Das war ja einfach.
Das war ja erstaunlich einfach.
### Aufgabe 03.2: HTTP-Service mittels eines generellen Basis-Images bauen
In Fällen von weit verbreiteten Diensten und Produkten wie NGINX, Apache, Redis, Memcached, CouchDB, MySQL, usw. finden sich häufig solche Basisimages der entsprechenden Projekte. Das geht meist sehr schnell und ist unkompliziert. Sie verlieren aber auch etwas Kontrolle und Konfigurationsmöglichkeiten. In Fällen spezifischerer Produkte oder selbst geschriebener Software sind Sie sogar ggf. gezwungen selber ein Image zu erstellen und die entsprechende Software darauf zu installieren. Man geht in diesen Fällen üblicherweise von einem Distributions Basis-Image aus (wie bspw. dem Ubuntu 18.04 LTS Image).
In Fällen von weit verbreiteten Diensten und Produkten wie NGINX, Apache, Redis, Memcached, CouchDB, MySQL, usw. finden sich häufig solche Basisimages der entsprechenden Projekte. Diese kann man meist sehr schnell und unkompliziert aufsetzen und nutzen. Sie verlieren aber häufig auch etwas Kontrolle und Konfigurationsmöglichkeiten.
In Fällen spezifischerer Produkte oder selbst geschriebener Software sind Sie sogar ggf. gezwungen selber ein Image zu erstellen und die entsprechende Software darauf zu installieren. Man geht in diesen Fällen üblicherweise von einem Distributions Basis-Image aus (wie bspw. dem Ubuntu 18.04 LTS Image).
Wir wollen nun denselben Service mit einem anderen Image bauen, um diesen generelleren Ansatz zu demonstrieren.
1. `cp Dockerfile.ubuntu Dockerfile`
2. Öffen Sie das `Dockerfile` in einem Editor und versuchen Sie es zu verstehen. Sie sehen es ist etwas länger, als das vorherige Image, aber Sie sollten die Wirkungsweise mittels der Kommentare nachvollziehen können.
2. Öffen Sie das `Dockerfile` in einem Editor und versuchen Sie es zu verstehen. Sie sehen, es ist etwas länger, als das vorherige Image, aber Sie sollten die Wirkungsweise mittels der Kommentare gut nachvollziehen können.
3. Bauen Sie nun das Image zu diesem Ubuntu-basierten `Dockerfile` mittels `docker build -t web:ubuntu .`.
4. Prüfen Sie wieder mittels `docker image list web*`, ob Ihr Image gebaut wurde. Sie sollten eine Ausgabe wie folgt (o. ähnl.) erhalten.
```
......@@ -78,14 +82,14 @@ Wir wollen nun denselben Service mit einem anderen Image bauen, um diesen genere
web nginx ca0547d1d208 minutes ago 133MB
```
5. Starten Sie dieses Image nun bitte mittels `docker run -p 8080:80 web:ubuntu`.
6. Prüfen Sie, ob Ihre Website ausgeliefert wird, in dem Sie [http://localhost:8080](http://localhost:8080) aufrufen. Sie sollten wieder dieselbe Webpage sehen, wie im vorherigen Teil.
6. Prüfen Sie, ob Ihre Website ausgeliefert wird, in dem Sie [http://localhost:8080](http://localhost:8080) aufrufen. Sie sollten wieder dieselbe Webpage sehen, wie bereits im vorherigen Teil.
## Übung 03: Vergleich von Imagegrößen
Sie haben in Übung 02 einen einfachen Webserver samt Inhalt als Docker Image erzeugt.
Sie haben in Übung 02 einen einfachen Webserver samt Inhalt als Docker-Image erzeugt.
- Einmal haben Sie auf dem von NGINX selbst bereitgestellten Image nur Ihren Inhalt (`web`-Verzeichnis) hinzugefügt.
- Im zweiten Fall haben Sie auf Basis eines Ubuntu 18.04 LTS Basis Images auch den Webserver NGINX installiert, den Inhalt hinzugefügt und den Entrypoint für den Container konfiguriert. Das war aufwändiger, Sie hatten aber dadurch letztlich mehr Kontrolle über die Konfiguration.
- Im zweiten Fall haben Sie auf Basis eines Ubuntu 18.04 LTS Basis Images auch den Webserver NGINX installiert, den Inhalt hinzugefügt und den Entrypoint für den Container konfiguriert. Das war zwar etwas aufwändiger, Sie hatten aber dadurch letztlich mehr Kontrolle über die Konfiguration.
Sie sehen also, dass bereitgestellte Community-Images häufig komfortabler sind. Doch wie sieht es mit dem Größenbedarf der resultierenden Images aus?
......@@ -103,7 +107,7 @@ web ubuntu 8032bb56c82d 57 minutes ago
web nginx ca0547d1d208 14 hours ago 133MB
```
Sie sehen, Ihr selbst gebautes Ubuntu Image ist etwas größer. Das ist nicht wirklich erstaunlich, denn die NGINX Macher wissen vermutlich besser als Sie und ich, wie man eine NGINX-Basisinstallation effizient konfiguriert. Doch Images lassen sich auch "shrinken". Sie sollten sich dazu ins Bewusstsein rufen, dass Container Overlay-Dateisysteme nutzen, und jede Anweisungszeile eines Dockerfiles ein Image-Layer (mit Platzbedarf) erzeugt. Man kann sich das zu nutze machen und Images auf mehrere Arten "kleiner" machen:
Sie sehen, Ihr selbst gebautes Ubuntu Image ist etwas größer. Das ist nicht wirklich erstaunlich, denn die NGINX Macher wissen vermutlich besser als Sie und ich, wie man eine NGINX-Basisinstallation effizient konfiguriert. Doch Images lassen sich auch "shrinken". Sie sollten sich dazu ins Bewusstsein rufen, dass Container Overlay-Dateisysteme nutzen, und jede Anweisungszeile eines Dockerfiles ein Image-Layer (mit Platzbedarf) erzeugt. Man kann sich das zu Nutze machen und Images auf mehrere Arten "kleiner" machen:
1. Indem man für den Betrieb unnötige Dateien nicht in den Layer mit aufnimmt.
2. Indem man unnötige Image-Layer einspart.
......@@ -241,14 +245,33 @@ __Hinweis:__ Dieser Teil kann auch mit dem Public [Gitlab.com](https://gitlab.co
Mittels dieser Tool-Chain lassen sich also Images in Registries zentral bereitstellen und für Deployments nutzen.
## Übung 05: Pipeline zum Bau und Test eines Images
## Übung 05: Deployment-Pipeline zum Bau und Test eines Images
Dieser Teil soll Ihnen zeigen, wie Sie mittels einer Deployment Pipeline Images automatisiert bauen können. Gitlab Deployment Pipelines haben Sie ja bereits in einem vorherigen Lab kennengelernt.
1. Arbeiten Sie hierzu mit dem NGINX-Image: `cp Dockerfile.nginx Dockerfile`
2. Öffnen Sie die `.gitlab-ci.yml` Datei in einem Editor und versuchen Sie diese nachzuvollziehen.
- Dort sind zwei Stages `test` und `build` mit jeweils einem Job definiert.
- In der `test`-Stage wird Ihr Container Image gebaut, gestartet und anschließend mittels `curl` abgerufen. Die herunter geladene Datei wird mit der `web/index.html` verglichen. Sind diese identisch ist der Container richtig konfiguriert.
- In der `build`-Stage wird das Container-Image für die Registry gebaut, entsprechend getagged und in die Registry gepushed. Gitlab CI blendet hierfür über mehrere Umgebungsvariablen wie `$CI_REGISTRY_USER`, `$CI_REGISTRY_PASSWORD` (Access Credentials), `$CI_REGISTRY` (URL der Registry) und `$CI_REGISTRY_NAME` (Repository) die erforderlichen Daten für Docker ein.
3. Kopieren Sie hierzu
- den `web`-Ordner samt Inhalt,
- das `Dockerfile`,
- und die `.gitlab-ci.yml`
in Ihr `image-test` Repository (z.B. mittels der WebIDE in Gitlab).
4. Committen Sie dann diese Änderungen (z.B. mittels der WebIDE in Gitlab). Dadurch wird die Pipeline automatisch angestoßen. Öffnen Sie dann in GitLab über __CI/CD -> Pipelines__ die Pipeline und verfolgen Sie deren Fortschritt. Die Pipeline sollte erfolgreich durchlaufen.
5. Öffnen Sie dann in GitLab über __Packages & Registries -> Container Registry__ die Registry Ihres Projekts. Dort sollten Sie nun auch einen `automatic` Tag sehen. Dieses Image wird nun immer dann aktualisiert, wenn Sie einen neuen Commit in das Repo pushen und die `test`-Stage erfolgreich bestanden wird.
Auf diese Art und Weise können Sie nun auch automatisiert im Rahmen von Deployment Pipelines Images bauen und bereitstellen.
## Quellen und Referenzen
- [Docker Playground](https://labs.play-with-docker.com/) (Online Lab)
- [Docker Playground](https://labs.play-with-docker.com/) (Online Lab, Registration erforderlich)
- [Docker Get Started](https://docs.docker.com/get-started/)
- [Docker Tutorials and Community Trainings](https://www.docker.com/play-with-docker)
- [Best Practices for Writing Dockerfiles](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/)
- [Building Docker images with GitLab CI/CD](https://docs.gitlab.com/ee/ci/docker/using_docker_build.html)
## Was sollten Sie mitnehmen ...
......@@ -257,4 +280,5 @@ Mittels dieser Tool-Chain lassen sich also Images in Registries zentral bereitst
2. Sie können Server-Dienste mittels TCP-Ports nach außen `EXPOSE`n.
3. Über `ENTRYPOINT` können Sie hierzu den Prozess starten, der durch den Container bereitgestellt werden soll (vermeiden Sie dabei Prozesse als Daemons zu starten).
4. Image-Größen lassen sich mittels **RUN-Chaining** und der Wahl kleiner Basis-Images signifikant reduzieren.
5. Mittels `docker login` kann man sich auf entfernten Image-Registries einloggen um dann mittels `docker push` und `docker pull` Images auf privaten Registries hochladen bzw. herunterladen zu können.
\ No newline at end of file
5. Mittels `docker login` kann man sich auf entfernten Image-Registries einloggen um dann mittels `docker push` und `docker pull` Images auf privaten Registries hochladen bzw. herunterladen zu können.
6. Mittels GitLab Deployment Pipelines können Sie Images automatisiert testen und erstellen.
\ No newline at end of file
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment