Docker Archive - TekkieNinja

Reverse Proxy in Docker mit Let’s Encrypt-Zertifikaten

Florian Keßler — Fri, 09 Jun 2023 10:11:36 +0000

In diesem Blogbeitrag werden wir uns detailliert mit der Konfiguration eines Reverse Proxys in Docker mit Let’s Encrypt-Zertifikaten befassen und zeigen, wie diese in den Prozess integriert werden können. Wir werden gemeinsam Schritt für Schritt die erforderlichen Maßnahmen durchgehen, um einen sicheren und zuverlässigen Reverse Proxy aufzusetzen, der den Datenverkehr effizient verteilt und gleichzeitig eine verschlüsselte Kommunikation gewährleistet.

Egal, ob du bereits mit Docker vertraut bist oder gerade erst anfängst, dieser Blogbeitrag bietet dir eine umfassende Anleitung, um Reverse Proxy und Let’s Encrypt-Zertifikate erfolgreich zu implementieren. Tauche ein in die Welt des sicheren Datenverkehrs und erfahre, wie du deine Webanwendungen oder Websites vor potenziellen Bedrohungen schützen kannst.

Grundlagen

Ein Reverse Proxy agiert als Vermittler zwischen den Clients und den Servern. Er nimmt eingehende Anfragen entgegen und leitet sie an die entsprechenden Backend-Server bzw. App Container weiter. Dadurch können wir den Datenverkehr effizient verteilen, Lastausgleich betreiben und zusätzliche Sicherheitsschichten einführen.

Ein wichtiger Aspekt bei der Implementierung eines Reverse Proxys ist die Integration von Let’s Encrypt-Zertifikaten. Let’s Encrypt ist eine kostenlose und automatisierte Zertifizierungsstelle, die es Website-Betreibern ermöglicht, SSL/TLS-Zertifikate einfach zu erhalten und ihre Verbindung zu verschlüsseln. Durch die Verwendung von Let’s Encrypt-Zertifikaten stellen wir sicher, dass die Kommunikation zwischen den Clients und den Backend-Servern verschlüsselt ist und vor potenziellen Angreifern geschützt wird.

Voraussetzungen

Um den Reverse Proxy in Docker mit Let’s Encrypt-Zertifikaten erfolgreich zu implementieren, gibt es einige grundlegende Voraussetzungen, die erfüllt sein müssen. Stelle sicher, dass du die folgenden Anforderungen erfüllst, bevor du mit der Konfiguration beginnst:

Docker und Docker Compose: Da wir Docker und Docker Compose verwenden, um den Reverse Proxy zu erstellen und zu verwalten, musst du diese Software auf deinem System installiert haben. Falls du dies noch nicht getan hast, habe ich dir eine Anleitung verlinkt.
Grundkenntnisse von Docker: Um den Reverse Proxy in Docker effektiv zu konfigurieren, ist es wichtig, grundlegende Kenntnisse von Docker und seinen Kernkonzepten zu haben. Du solltest mit Begriffen wie Containern, Images, Dockerfiles und dem Docker-CLI (Command Line Interface) vertraut sein. Wenn du noch nicht mit Docker vertraut bist, habe ich dir eine Beitragsserie zu dem Thema Docker verlinkt.
Grundkenntnisse von Docker Compose: Docker Compose ist ein Tool, das es ermöglicht, mehrere Docker-Container als Dienste zu definieren und zu verwalten. Es erleichtert die Konfiguration und das Zusammenspiel von Containern. Um den Reverse Proxy mit Let’s Encrypt-Zertifikaten in Docker zu implementieren, ist es hilfreich, grundlegende Kenntnisse von Docker Compose zu haben. Du solltest wissen, wie man eine Docker-Compose-Datei erstellt, Dienste definiert und Umgebungsvariablen festlegt. Einen kurzen Crashkurs habe ich dir hier verlinkt.

Docker-Compose-Datei

Docker Netzwerk

Docker-Container können standardmäßig nicht von externen Quellen angesprochen werden. Daher müssen die Ports des Containers auf die des Host-Rechners gemappt werden. Auf diese Weise kann der Container über die IP-Adresse und den entsprechenden Port erreicht werden. Wenn jedoch bestimmte Dienste für das Internet freigegeben werden sollen, kann dies sehr aufwendig sein. Es erfordert nicht nur das Mappen der Container-Ports, sondern auch das Einrichten von Portfreigaben am Router. Dadurch entsteht eine größere Angriffsfläche für potenzielle Hacker. Zusätzlich können Container standardmäßig nicht direkt miteinander kommunizieren. Um sicherzustellen, dass der Reverse Proxy auf die verschiedenen Anwendungen zugreifen kann, muss zunächst ein separates Netzwerk erstellt werden, das unabhängig von den Containern ist.

docker network create proxy_network

Du kannst den Namen proxy_network nach Belieben ändern. Durch die Verbindung der Container mit diesem Netzwerk wird sichergestellt, dass der Proxy auf die Container zugreifen kann. Es ist ratsam, nur die Container mit diesem Netzwerk zu verbinden, auf die von außerhalb des Heimnetzes zugegriffen werden soll.

Nachfolgend werden wir die Datei Schritt für Schritt gemeinsam aufbauen, damit die Installation des Revers Proxy in Docker verständlich ist.

nginx-proxy

In der Docker-Compose-Datei beginnen die ersten beiden Zeilen wie in jeder anderen Datei. Die version gibt an, auf welcher Version die Datei aufbaut. Unter dem Abschnitt services definieren wir unsere Container. Zuerst wird der Reverse Proxy Container definiert.

version: '3'
services:

Wir haben uns für das Image von jwilder in der alpine Version entschieden, da es einen geringeren Angriffsvektor für potenzielle Angreifer bietet. Zusätzlich enthält es die empfohlenen Einstellungen der Mozilla-Organisation auf dem Intermediate-Level, um einen Kompromiss zwischen Sicherheit und Kompatibilität zu gewährleisten.

nginx-proxy:
    image: jwilder/nginx-proxy:alpine

Diese Zeile befasst sich mit den Labels, die dem Container zugewiesen werden sollen. Diese sind wichtig, da sie es dem nachfolgenden LetsEncrypt-Container ermöglichen, den Proxy-Container zu identifizieren.

    labels:
      com.github.jrcs.letsencrypt_nginx_proxy_companion.nginx_proxy: true

Anschließend legen wir den Namen des Containers fest.

    container_name: proxy

Im Abschnitt networks tragen wir den Namen des Netzwerkes ein, welches wir im Vorhinein erstellt haben. Durch diese Angabe wird der Container mit dem benannten Netzwerk verbunden.

    networks:
      - proxy_network

Um den Container von außen erreichbar zu machen, ist es wichtig, den Port 80 freizugeben, da er für eine HTTP-Verbindung erforderlich ist. Auf diese Weise kann LetsEncrypt das Ziel erreichen und ein gültiges Zertifikat erstellen. Über den Port 443 wird die verschlüsselte HTTPS Verbindung aufgebaut.

    ports:
      - 80:80
      - 443:443

Damit der Proxy unter anderem seine Konfiguration speichern und auf die generierten Zertifikate Zugriff hat, werden dem Container entsprechende Ordner bereitgestellt. Damit ist sichergestellt, dass diese auch nach dem beenden der Container weiter verfügbar sind.

    volumes:
      - /var/proxy/vhost.d:/etc/nginx/vhost.d:ro
      - /var/proxy/html:/usr/share/nginx/html:rw
      - /var/proxy/certs:/etc/nginx/certs:ro
      - /var/proxy/conf/:/etc/nginx/conf.d/
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/tmp/docker.sock:ro

Abschließend wird die Neustart Richtlinie des Container definiert. Diese definiert, dass der Container immer wieder neu gestartet wird, außer er wird manuell oder durch einen Fehler gestoppt.

    restart: unless-stopped

letsencrypt

Analog dem ersten Container werden wir nachfolgend die entsprechenden Abschnitte erklären. Um Zertifikate von Let´s Encrypt zu erstellen, verwenden wir das Image von nginxproxy.

  letsencrypt:
    image: nginxproxy/acme-companion

Diese Option definiert eine Abhängigkeit zum vorherigen Container, womit definiert wird, dass der Let´s Encrypt Container nach dem Proxy Container gestartet werden soll.

    depends_on:
      - nginx-proxy

Anschließend legen wir den Namen des Containers fest.

    container_name: proxy-acme

Im Abschnitt networks tragen wir analog aus dem Proxy Abschnitt das zuvor erstelle Netzwerk ein.

    networks:
      - proxy_network

Damit der Let´s Encrypt Container die Konfiguration des Proxys lesen und die generierten Zertifikate speichern kann, wird dem Container die entsprechenden Ordner bereitgestellt.

    volumes:
      - /var/proxy/vhost.d:/etc/nginx/vhost.d:rw
      - /var/proxy/html:/usr/share/nginx/html:rw
      - /var/proxy/certs:/etc/nginx/certs:rw
      - /var/proxy/acme:/etc/acme.sh
      - /var/proxy/conf/:/etc/nginx/conf.d/
      #- /var/proxy/acme_config/standalone.sh:/app/letsencrypt_user_data:ro # ggf. für die nächsten Abschnitte notwendig
      - /etc/localtime:/etc/localtime:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro

Standardmäßig erneuert der Container die Zertifikate 30 Tage vor Ablauf. Um eine Benachrichtigung per E-Mail zu erhalten, falls ein Zertifikat doch nicht korrekt erneuert wird, wird die nachfolgende Variable benutzt. Hier könnt ihr eure E-Mail Adresse eintragen.

    environment:
      - DEFAULT_EMAIL=EMAIL-ADRESSE

Gleichermaßen wie bei dem Proxy ist auch hier die Neustart Richtlinie definiert.

    restart: unless-stopped

In den beiden Containern haben wir das zuvor erstellte Proxy-Netzwerk verwendet. Um sicherzustellen, dass Docker Compose erkennt, dass es sich um ein extern erstelltes Netzwerk handelt, muss dieses zusätzlich global in die Compose-Datei eingebunden werden.

networks:
  proxy_network:
    external:
      name: proxy_network

Die vollständige Datei kannst du hier herunterladen.

Docker Compose Stack starten

Die obige Datei kannst du herunterladen und speichere diese z.B. unter dem Namen proxy-compose.yml ab. Anschließend kannst du den Stack mittels folgendem Befehl starten:

docker-compose --compatibility -f /PFAD/ZUR/COMPOSE/DATEI up -d

Die Container laufen im Hintergrund, damit kannst du den Reverse Proxy verwenden.

Konfiguration des Reverse Proxy in Docker mit Let´s Encrypt Zertifikaten

Mehrere Container unter einer Domain (Multipath)

Möchtest du mehrere Container unter einer einzigen Domain erreichen, beispielsweise tekkie.ninja/app1, tekkie.ninja/app2 oder einfach nur tekkie.ninja?
Dieses Ziel lässt sich wie folgt realisieren: Du erstellst eine Docker-Compose-Datei, in der die entsprechenden Container Zugriff auf das Proxy-Netzwerk haben. Der Standardcontainer, der aufgerufen wird, wenn tekkie.ninja aufgerufen wird, erhält die Umgebungsvariable VIRTUAL_HOST=…. Anschließend erzeugst du im Verzeichnis vhost.d eine Datei mit dem gleichen Namen wie die im Compose-File angegebene Domain. In dieser Datei gibst du die verschiedenen Pfade an und verweist auf die entsprechenden Container.

Ein Beispiel für eine solche Datei sieht wie folgt aus:

location /app1 { proxy_pass http://app1:8000; }

location /app2 { proxy_pass http://app2:8000; }

Dabei muss der Name des Containers die in der URL definierte app1 bzw. app2 ersetzen. Der Pfad wird entsprechend auf die Containernamen angepasst.

Weiterleitung einer Domaine

Wenn du beabsichtigst, eine Domain über einen Reverse Proxy mit einem SSL-Zertifikat zu betreiben, ohne sie direkt auf einen Container abzubilden, sind einige Schritte erforderlich. Abhängig vom Pfad deiner Compose-Datei ist es notwendig, eine separate *.conf-Datei in dem Konfigurationsverzeichnis des Proxys, laut obigen Beispiel /var/proxy/conf, zu erstellen.

Innerhalb dieser Konfigurationsdatei legst du verschiedene Parameter fest, darunter den Domänennamen, die IP-Adresse zusammen mit dem Port sowie den Pfad zu den Zertifikaten und Schlüsseln. Die markierten Abschnitte in der Datei müssen individuell an den jeweiligen Anwendungsfall angepasst werden. Für nähere Informationen zur Beschaffung eines Zertifikates empfiehlt es sich, den Abschnitt „SSL-Zertifikat ohne zugehörigen Docker-Container“ zu konsultieren.

# Specify domain to be forwarded upstream domainName { server IP_ADRESS:PORT; } server { server_name domainName; listen 80 ; access_log /var/log/nginx/access.log; # Do not HTTPS redirect Let'sEncrypt ACME challenge location ^~ /.well-known/acme-challenge/ { auth_basic off; auth_request off; allow all; root /usr/share/nginx/html; try_files $uri =404; break; } location / { return 301 https://$host$request_uri; } } server { server_name domainName; listen 443 ssl http2 ; access_log /var/log/nginx/access.log; ssl_session_timeout 5m; ssl_session_cache shared:SSL:50m; ssl_session_tickets off; ssl_certificate /PATH/TO/domainName.crt; ssl_certificate_key /PATH/TO/domainName.key; ssl_dhparam /PATH/TO/domainName.dhparam.pem; ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /PATH/TO/domainName.chain.pem; add_header Strict-Transport-Security "max-age=31536000" always; include /etc/nginx/vhost.d/default; location / { proxy_pass http://domainName; } }

Die Datei kann hier heruntergeladen werden.

SSL-Zertifikat ohne zugehörigen Docker-Container

Um SSL-Zertifikate unabhängig von Containern zu generieren, benötigt der ACME-Container Zugriff auf das Konfigurationsverzeichnis des Reverse-Proxy sowie auf die Docker-Sockets, wie in der Docker Compose-Datei angegeben.

Des Weiteren wird eine Datei in das Verzeichnis /app/letsencrypt_user_data eingebunden. Diese Datei ist eine ausführbare Bash-Datei und enthält z.B. folgenden Inhalt:

LETSENCRYPT_STANDALONE_CERTS=('web' 'app' 'tekkie')
LETSENCRYPT_web_HOST=('yourdomain.de' 'www.yourdomain.de')
LETSENCRYPT_app_HOST=('yourdomain.de' 'myapp.yourotherdomain.de' 'service.yourotherdomain.tld')
LETSENCRYPT_tekkie_HOST=('tekkieninja.de')

Dabei werden in der ersten Zeile verschiedene Zertifikate als Gruppe definiert. Dieser Gruppe können dann mehrere Domainnamen zugewiesen werden, wofür das Zertifikat gelten soll.

Befehlsergänzungen

Proxy Container

Um die Konfiguration neu zu laden, wird folgender Befehl verwendet:

docker exec -ti proxy nginx -s reload

ACME Container

Um die Zertifikatsprüfung erneut auszulösen, wird folgender Befehl verwendet:

docker exec proxy-acme /app/signal_le_service

Um die Erneuerung der Zertifikate zu erzwingen, nutzen wir den folgenden Befehl:

docker exec proxy-acme /app/force_renew

Offizielle Dokumentation

Die offizielle Dokumentation von jwilder kannst du hier finden.

Der Beitrag Reverse Proxy in Docker mit Let’s Encrypt-Zertifikaten erschien zuerst auf TekkieNinja.

Docker (-Compose) installieren

Florian Keßler — Sun, 23 Apr 2023 14:00:00 +0000

In dem folgenden Artikel werde ich Schritt für Schritt erklären wie man Docker (-Compose) installieren kann und was es zu Beachten gilt.

Bei der Recherche wie man Docker installiert fällt auf, dass oft von Docker-ce oder Docker-io die Rede ist. Beide Varianten beinhalten dasselbe Docker, aber auf unterschiedliche Weise. Docker-io geht nach dem Ansatz von Ubuntu/Debian und hat Paketabhängigkeiten, die separat installiert und aktualisiert werden können. Docker-ce hingegen lädt alle Abhängigkeiten separat herunter und enthält somit separate Bibliotheken. Im Folgenden werde ich beide Varianten der Installation von Docker zeigen, empfehle aber die Docker-io Version.

Docker-io

Alte Docker Versionen können mit folgendem Befehl deinstalliert werden:

sudo apt-get remove docker docker-engine docker.io

Zunächst müssen die Paketlisten aktualisiert werden:

sudo apt-get update

Mit folgendem Befehl kann man Docker installieren:

sudo apt install docker.io

Nach erfolgreicher Installation starten wir den Docker Daemon und tragen ihn in den Autostart ein, sodass Docker bei jedem Systemstart automatisch gestartet wird:

sudo systemctl start docker
sudo systemctl enable docker

Um zu überprüfen, ob Docker erfolgreich installiert wurde, kann folgender Befehl ausgeführt werden:

docker version

Docker-ce

Analog zu Docker-io müssen zunächst die Paketlisten aktualisiert werden:

sudo apt-get update

Als nächstes werden ein paar Voraussetzungen installiert, damit apt Pakete über HTTPS verwenden kann:

sudo apt-get install apt-transport-https ca-certificates curl software-properties-common gnupg-agent

Anschließend wird der GPG-Schlüssel für das offizielle Docker-Repository dem System hinzugefügt:

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

Danach kann das Docker-Repository zu den APT Quellen hinzugefügt werden. Allerdings muss hier der grün markierte Teil durch die aktuell installierte Ubuntu Version ausgetauscht werden:

sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu jammy stable"

Ubuntu 18.04 == bionic
Ubuntu 20.04 == focal
Ubuntu 22.04 == jammy

Danach müssen die Paketquellen erneut aktualisiert werden:

sudo apt-get update

Nach der Aktualisierung der Quellen kann Docker-ce installiert werden:

sudo apt-get install docker-ce

Um zu überprüfen, ob Docker erfolgreich installiert wurde, kann folgender Befehl ausgeführt werden:

docker version

Docker Compose installieren

Bevor Docker Compose installiert werden kann, muss die letzte stabile Version ermitttelt werden. Die unterschiedlichen Versionen können unter der Versionswebsite gefunden werden.

Nachfolgend wird mit der Version v2.17.3 gearbeitet. Sollte eine andere Version installiert werden, so muss nachfolgend ausschließlich die Versionsnummer ausgetauscht werden:

sudo curl -L "https://github.com/docker/compose/releases/download/v2.17.3/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

Mit diesem Befehl wird die gewünschte Docker Compose Version heruntergeladen. Um die Dateien ausführbar zu machen, wird folgender Befehl verwendet:

sudo chmod +x /usr/local/bin/docker-compose

Eine erfolgreiche Installation von Docker Compose kann wie folgt überprüft werden:

docker-compose --version

Ihr wollt mehr über Docker-Compose erfahren? In dem verlinkten Beitrag habe ich eine Einführung für dieses Thema verfasst.

Der Beitrag Docker (-Compose) installieren erschien zuerst auf TekkieNinja.

Docker-Compose erklärt

Florian Keßler — Sun, 23 Apr 2023 11:55:19 +0000

Docker Compose ermöglicht es, mehrere Container in einer einzigen Datei zu definieren und ihre Beziehungen untereinander zu definieren. Mit einem einzigen Befehl können dann alle Container gestartet werden. Dies ist besonders praktisch, da die Datei einfach geteilt werden kann, um eine einheitliche Serverumgebung zu gewährleisten.

Warum müssen verschiedene Container eigentlich miteinander verknüpft werden? Ein Docker-Container ist von Natur aus isoliert, es können keine Verbindungen nach außen oder nach innen aufgebaut werden. Es ist jedoch oft notwendig, dass Container miteinander kommunizieren müssen, zum Beispiel ein Webserver mit einer Datenbank oder ein Container mit dem Hostcomputer, auf dem er gestartet wurde.

Die Verknüpfung ermöglicht uns, bestimmte Ports freizugeben, um eine Verbindung von außen zu ermöglichen oder ein bestimmtes Verzeichnis mit dem Hostsystem zu teilen. Bei nur zwei Containern ist das noch einfach, aber in einer typischen Webumgebung müssen mehrere Container miteinander kommunizieren, wie zum Beispiel ein Webserver (z.B. Apache2), PHP und eine Datenbank.

Es wird schwierig, den Überblick über all diese verschiedenen Tools zu behalten. Docker Compose hilft uns, dies ganz einfach zu orchestrieren, auch wenn wir noch viele weitere Tools wie NodeJS, Cacheserver und Load Balancer hinzufügen.

Docker-Compose Dateiformat .yaml

Der zentrale Bestandteil von Docker Compose ist die YAML-Datei. In dieser Datei werden die Container definiert, die gestartet werden sollen, sowie ihre Beziehungen zueinander. Es können Verzeichnisse freigegeben, Ports freigeschaltet und Verknüpfungen hergestellt werden.

Auf der ersten Ebene der Datei werden die Namen der einzelnen Container festgelegt. Diese sind wichtig, da sie als Referenz auf andere Container verwendet werden können. In der nächsten Ebene werden die Eigenschaften jedes Containers beschrieben, von denen einige im Folgenden näher erläutert werden. Nachfolgend ein Beispiel:

container1:
image: image1

container2:
image: image2

Dieses Beispiel würde zwei Container starten, die jedoch nichts Besonderes tun würden, außer möglicherweise ihre definierten Images auszuführen. Um die Sache spannender zu gestalten, wird nachfolgend auf die verschiedenen Optionen von Docker-Compose eingegangen.

Eigenschaft image

Zunächst wird die wichtigste Eigenschaft betrachtet: image. Mit dieser Eigenschaft legen wir fest, auf welchem Docker-Image ein Container aufbauen soll. Docker sucht nach dem angegebenen Image im Docker-Hub, lädt es herunter und startet von diesem aus einen Container automatisch. Da viele moderne Tools (wie Webserver etc.) bereits vorgefertigte Docker-Images bereitstellen, kann damit viel Arbeit erspart werden.

Ein Beispiel wäre nachfolgend (analog zu dem obigen):

apache2:
image: httpd

Eigenschaft build

Im Vergleich zu image stellt Build das Gegenstück dar, wobei beide Eigenschaften exklusiv sind, das heißt, ein Container kann nur eine von beiden haben. Hier wird der Pfad zum Dockerfile angegeben – relativ zum Ort der docker-compose.yml Datei – das beim Starten des Containers ausgeführt werden soll. Mit dieser Eigenschaft ist es möglich, alle Container individuell anzupassen, indem für jeden ein eigenes Dockerfile angeben wird. Wenn sich das Dockerfile im selben Verzeichnis wie die docker-compose.yml Datei befindet, geben wir einfach einen „.“ an. Wenn das Dockerfile einen anderen Namen hat, kann der Name mit der Eigenschaft „dockerfile“ geändert werden.

Beispiel:

apache2:
build: ./apache2

Eigenschaft ports

Die Eigenschaft ports öffnet die angegebenen Ports in einem Container und verbindet sie mit einem Port auf dem Host. Dies ermöglicht es, dass zwei Programme, die denselben Port benutzen, auf demselben Server laufen können, indem man einem Programm einen anderen Port auf dem Host zuweist als dem anderen. Es gibt verschiedene Schreibweisen für diese Eigenschaft:

Eine einzelne Zahl öffnet einen einzelnen Port, und falls für den Host kein Port angegeben ist, wird ein zufälliger Port bestimmt.
Mit Doppelpunkten getrennte Zahlen mappen Ports von dem Host System in den Container.
Mit Bindestrich getrennte Zahlen öffnen eine Reihe von Ports.

Diese Eigenschaft ist nützlich, wenn Programme wie Webserver oder MariaDB in einem Container ausgeführt werden sollen und andere Container darauf zugreifen müssen. Dabei müssen die entsprechenden Ports, wie beispielsweise 80/443 für den Webserver oder 3306 für MariaDB, freigegeben werden.

Beispiel:

apache2:
image: httpd
ports:
- 80:80
- 443:443

Eigenschaft volumes

interne Volumes

Durch die volumes-Eigenschaft können Verzeichnisse (oder auch mehrere) vom Host im Container zugänglich gemacht werden. Der Pfad auf dem Host, wo das Verzeichnis zu finden ist, wird einfach angegeben. Optional kann auch ein Pfad angegeben werden, auf den das Verzeichnis im Container gemappt werden soll. Änderungen, die auf einer Seite vorgenommen werden (z. B. im Container), sind automatisch auch auf der anderen Seite (auf dem Host) verfügbar. Dies ist eine einfache Möglichkeit, Datenkonsistenz zu gewährleisten, da normalerweise Daten, die in einem Container gespeichert sind, beim beenden des Containers gelöscht werden. Wenn sie jedoch über ein solches Volume auf dem Hostrechner gespeichert werden, bleiben sie auch nach einem Container-Neustart erhalten.

Beispiel:

apache2:
image: httpd
volumes:
- /var/project_Blog/html:/var/www/html

externe Volumes

Das Verwenden eines externen Volumes unterscheidet sich sowohl in der Anwendung als auch darin, dass es zuvor angelegt werden muss. Ein externes Volume bleibt auch nach dem Beenden des Containers erhalten. Alle Volumes werden unter /var/lib/docker/volumes/VOLUME-NAME abgelegt.

Beispiel:

Zunächst wird ein externes Volume für MariaDB erstellt. Im Anschluss wird eine Docker Compose Datei gezeigt, die demonstriert, wie das externe Volume eingebunden wird.

docker volume create mariadbV1

Details zu dem gerade erstellten Volume kann mittels folgendem Befehl angezeigt werden:

docker volume inspect mariadbV1

version: '3'

services:
mariadb:
    image: mariadb
    container_name: mariadb
    ports:
      - 3306:3306
    volumes:
      - mariadb:/var/lib/mysql

volumes:
mariadb:
external: true
name:
mariadbV1

volumes_from

Die Eigenschaft volumes_from ähnelt sehr der vorherigen, ist jedoch nicht identisch. Sie ermöglicht es uns, alle Volumes, die wir in einem anderen Container haben, in diesen Container zu übernehmen. Das ist äußerst praktisch, um immer Zugriff auf dieselben Daten zu haben. Das ist zum Beispiel wichtig, wenn wir einen Container für einen Webserver und einen weiteren für PHP haben. Beide benötigen Zugriff auf die PHP-Dateien. Hier wird der Name des Containers angegeben, wie in der docker-compose.yml Datei.

Eigenschaft container Name

Durch die Verwendung von container_name kann einem Docker-Container ein spezifischer Name zugewiesen werden. Das ist besonders nützlich, wenn viele Container gleichzeitig laufen, da sonst zufällige Namen vergeben werden und es schwierig wird, den Überblick zu behalten.

Eigenschaft networks

Allgemeine Verwendung

Um Container miteinander zu verknüpfen, wird dies in Netzwerken realisiert. Netzwerke sind vergleichbar mit einem lokalen Netzwerk zu Hause, wo die einzelnen Geräte miteinander kommunizieren können, aber von außen (Internet / Router) nicht zugänglich sind. Ein Beispiel für die Verwendung von Netzwerken sieht folgendermaßen aus. Um Netzwerke nutzen zu können, muss der Block „networks“ auf der gleichen Ebene wie „services“ angelegt werden. In diesem Block spezifizieren wir das Netzwerk, das auch von den Containern verwendet werden soll. Hier ist ein Beispiel:

apache2:
image: httpd
ports:
- 80:80
- 443:443
networks:
- NETZWERKNAME
volumes:
- /var/project_Blog/html:/var/www/html

php-fpm:
image: php:fpm
volumes_from:
- apache2
networks:
- NETZWERKNAME

network:
- NETZWERKNAME:

Spezifische IP-Adressen

Um Container spezifische IP-Adressen zuweisen zu können, ist es notwendig, das Subnetz des erstellten Netzwerks festzulegen. Für IPv4-Netzwerke mit einem /29-Präfix sind beispielsweise 6 Clients möglich, wobei die .0-Adresse die Subnetz-Adresse und die letzte Adresse die Broadcast-Adresse ist. Hier ist ein konkretes Beispiel:

version: "3"

services:
pihole:
    ...
    networks:
      pihole_network:
        ipv4_address: 10.0.0.1

networks:
pihole_network:
    ipam:
      config:
        - subnet: 10.0.0.0/29

Gibt man keine spezifische IP-Adresse an, wird dem Container eine zufällige Adresse zugewiesen.

Eigenschaft environment / env_file

Durch die Verwendung von Environments können Kommandos innerhalb eines Containers ausgeführt werden. Im nachfolgenden Beispiel wird beim ersten Start des Containers eine Datenbank erstellt, zusammen mit einem Benutzer und einem Passwort für die Datenbank. Es wird auch ein Root-Benutzer für die Datenbank erstellt, da sonst das Bearbeiten oder Erstellen von Datenbanken nicht möglich ist.

version: '3'

services:
mariadb:
image: mariadb
container_name: mariadb
environment:
- MYSQL_ROOT_PASSWORD=---------------
- MYSQL_PASSWORD=---------------
- MYSQL_DATABASE=---------------
- MYSQL_USER=---------------

Wenn viele Variablen in einer Compose Datei stehen, kann dies schnell unübersichtlich werden. Außerdem kann es vorkommen, dass die Docker-Compose Datei mit einer anderen Person geteilt werden soll, aber nicht die Zugangsdaten. In einem solchen Fall ist die sogenannte env_file Eigenschaft nützlich. Damit können die oben gezeigten Werte in eine Datei ausgelagert werden. Die Datei sollte im gleichen Verzeichnis liegen wie die Compose Datei.

version: '3'

services:
apache2:
image: httpd
env_file:
- a.env
- b.env

Die Datei ist simpel im VAR=VAL-Format aufgebaut. VAR stellt den Variablennamen dar und VAL der entsprechende Wert. Sollten die selben Variablennamen in mehreren Dateien genutzt werden, so wird der letzte Wert aus der letzten Datei als entgültiger angenommen. Dadurch kann die Reihenfolge der Dateien im Compose File eine Rolle spielen.

Eigenschaft restart

Um die Neustart-Richtlinie für einen Container zu konfigurieren, kann die Eigenschaft restart verwendet werden. Der Wert des kann einer der folgenden sein:

no: Der Container wird nicht automatisch neu gestartet (Standard).
on-failure[:max-retries]: Der Container wird neu gestartet, wenn er aufgrund eines Fehlers mit einem Exit-Code ungleich Null beendet wird. Optional kann mit der Option :max-retries die Anzahl der Versuche des Docker-Dämons begrenzt werden, den Container neu zu starten.
always: Der Container wird immer neu gestartet, wenn er gestoppt wird. Wenn er manuell gestoppt wird, wird er nur neu gestartet, wenn der Docker-Daemon neu gestartet wird oder der Container selbst manuell neu gestartet wird.
unless-stopped: Analog zu always, außer dass der Container nicht neu gestartet wird, wenn er manuell oder anderweitig gestoppt wird, selbst wenn der Docker-Daemon neu gestartet wird.

Eigenschaft depends_on

Um die Beziehungen zwischen den Diensten in Docker Compose auszudrücken, können Abhängigkeiten definiert werden. Diese bestimmen das Start- und Stop-Verhalten der Dienste:

Wenn man docker-compose up ausführt, werden die Dienste in der Reihenfolge ihrer Abhängigkeiten gestartet. Im Beispiel werden db und redis vor web gestartet.
Wenn man docker-compose stop ausführt, werden die Dienste in umgekehrter Abhängigkeitsreihenfolge gestoppt. Im Beispiel wird web vor db und redis gestoppt.

version: '3'

services:
web:
image: httpd depends_on: - redis - db

redis:
image: redis

db:
image: mariadb

Aber ACHTUNG: depends_on wartet nicht darauf, dass db und redis lauffähig sind, bevor der Web-Dienst gestartet wird, sondern nur bis sie gestartet wurden.
Wenn man einen Stack im Schwarm-Modus mit einer Compose-Datei der Version 3 bereitstellt, wird die depends_on-Option ignoriert.

Eigenschaft deploy (Schwerpunkt Resourcen)

Um zu verhindern, dass der Kernel des Betriebssystems die Docker Engine bei einem Fehler eines Containers beendet, ist es empfehlenswert, die Ressourcen zu begrenzen. Dies kann durch Hinzufügen von Limits und Reservations in der deploy-Sektion der docker-compose-Datei erreicht werden.

Die Limits bestimmen die maximale Menge an Ressourcen, die ein Container verwenden kann, während die Reservations eine Mindestmenge an Ressourcen garantieren, die dem Container zur Verfügung stehen.

Folgende zwei Ressourcen Gruppen können beschränkt werden:

cpus: Diese Option gibt an, wie viel der verfügbaren CPU-Ressourcen ein Container nutzen kann.
memory:Diese Option gibt an, wie viel der verfügbaren RAM-Ressourcen ein Container nutzen kann.

Es ist auch möglich, die Optionen –cpu-shares und –memory-swap zu verwenden, um die Ressourcen auf andere Weise zu begrenzen. Weitere Informationen zu diesen Optionen finden in der Docker-Dokumentation.

Ab Compose Version 3 muss die Docker Engine im Swarm-Modus laufen, damit die Ressourcen Begrenzung greift. Wenn Sie jedoch den Kompatibilitätsmodus verwenden möchten, können Sie den Befehl „docker-compose –compatibility“ verwenden. Weitere Informationen dazu sind in der Docker-Dokumentation zu finden.

Grundlegende Befehle

Nach der Vorbereitung unseres docker-compose.yml-Files stellt sich die Frage: Wie starten oder beenden wir die konfigurierten Container? Hier sind einige Befehle, mit denen wir unsere Container verwalten können.

docker-compose up

Der erste Befehl ist docker-compose up. Dieser erstellt und startet die Container, die wir in unserem YAML-File definiert haben. Mit diesem einen Befehl können wir also alle unsere Container starten – genial.

docker-compose build

Der Befehl docker-compose build baut alle Container zusammen und taggt sie, damit sie beim nächsten Start schneller verfügbar sind. Wenn sich also etwas im Build-Verzeichnis oder im Dockerfile ändert, führen wir einfach diesen Befehl aus, um die Änderungen in unserer Docker Compose Umgebung zu integrieren.

docker-compose ps

Analog wie docker ps listet auch docker-compose ps die aktiven Container auf, die von Docker Compose verwaltet werden.

docker-compose start / stop

Mithilfe der Namen, die wir im docker-compose ps Befehl sehen können, können einzelne Container mit den Befehlen docker-compose start / stop gestartet bzw. gestoppt werden.

docker-compose rm

Mit dem Namen kann auch ein getaggtrn Container mit dem Befehl docker-compose rm entfernt werden. Wenn anschließend docker-compose up ausgeführt wird, dann wird der Container wieder neu erstellt.

Ich hoffe euch hat dieser Artikel zu Docker-Compose erklären gefallen. Habt Ihr Anmerkungen oder Wünsche? Dann teilt Sie mir gerne mit.

Der Beitrag Docker-Compose erklärt erschien zuerst auf TekkieNinja.

Dockerfile

Florian Keßler — Fri, 21 Apr 2023 14:01:00 +0000

Die Verwendung von Docker Images ist ein wichtiger Schritt in Richtung Docker, aber es gibt noch weitere nützliche Funktionen. Eine davon ist das Dockerfile, das es ermöglicht, das Image auf einfache Weise Schritt für Schritt zu erstellen. Es beschreibt, wie die Umgebung aufgebaut werden soll, ähnlich wie in anderen Umgebungen wie Vagrant.

Das Dockerfile ist eine einfache Textdatei, die den Aufbau des Docker Images beschreibt und als Schritt-für-Schritt-Anleitung fungiert, um das Image immer wieder auf dieselbe Art zu erstellen. Mit einem Dockerfile kann das Image leicht erstellt und Teamkollegen zur Verfügung gestellt werden, damit sie dasselbe Image erzeugen können.

Image aus dem Dockerfile erzeugen

Um ein fertiges Image aus einem Dockerfile zu erzeugen, müssen wir folgenden Befehl ausführen:

docker build

Dieser Befehl benötigt einen Kontext als Parameter, der das Verzeichnis enthält, in dem sich das Dockerfile befindet. Standardmäßig sucht Docker im Kontextverzeichnis nach der Datei. Wenn ein anderer Speicherort angeben werden soll, kann der Parameter -f verwendet werden.

Wenn ein Image aus dem Dockerfile erstellt werden soll, wird auf der Konsole in das Verzeichnis gewechselt, das das Dockerfile enthält, und geben den folgenden Befehl ein:

docker build -t tekkie/ninja-php-server

Durch die Verwendung des Parameters -t kann dem Image, das aus dem Dockerfile erstellt wird, einen Namen zuweisen, der später verwendet werden kann. Der Punkt am Ende steht für das aktuelle Verzeichnis und gibt an, dass das Kontextverzeichnis für das Erstellen des Images verwendet werden soll.

Aufbau eines Dockerfiles

Das Dockerfile ist einfach aufgebaut und besteht aus einer einzelnen Befehlszeile pro Zeile. Die Befehle werden durch die Konvention BEFEHL parameter getrennt, wobei der Befehl großgeschrieben wird. Kommentare können mit einem # am Anfang einer Zeile hinzugefügt werden.

Beim Bauen des Dockerfiles wird jeder Befehl in jeder Zeile nacheinander ausgeführt, um ein Zwischenimage zu erzeugen. Dieses Zwischenimage dient dann als Basis für den nächsten Befehl. Wenn ein Befehl erfolgreich ausgeführt wird, bleibt das Image erhalten. Das bedeutet, dass Docker beim nächsten Aufruf des build-Befehls an der gleichen Stelle weitermachen kann, solange sich im Dockerfile nichts ändert. Dies ist besonders nützlich, wenn aufwendige Befehle wie die Installation mehrerer Anwendungen ausgeführt werden müssen, da viel Zeit gespart werden kann.

Befehl FROM

Der entscheidende Befehl im Dockerfile lautet FROM und steht am Anfang. Er definiert klar, welches Image als Basis für das neue Image dienen soll. Dabei kann es sich um ein Basisimage wie ubuntu oder ubuntu:trusty handeln, oder um von Nutzern oder uns selbst erstellte Images wie tekkie/ninja-test-server.

Befehl MAINTAINER

Mit dem MAINTAINER Befehl kann der Autor des Images gesetzt werden.

MAINTAINER Tekkie Ninja

Befehl RUN

Einer der wichtigsten Befehle im Dockerfile ist der Befehl RUN. Mit diesem können wir den Parameter als Shell Befehl ausführen und damit quasi alles in unserer virtuellen Maschine tun. Der Befehl

RUN sudo apt-get install -y apache2

wird intern wie folgt übersetzt:

/bin/sh -c sudo apt-get install -y apache2

Eine weitere Möglichkeit, den RUN Befehl auszuführen, ist die sogenannte exec Syntax:

RUN [„executable“, „param1“, „param2“]

In den meisten Fällen werden die Dockerfiles eine Verkettung von vielen RUN Befehlen beinhalten. Hier ist es wichtig zu beachten, dass jeder RUN Befehl einen neuen Layer im Image erzeugt und damit Speicher verbraucht. Daher sollten wir die Anzahl der RUN Befehle möglichst gering halten und mehrere Dinge innerhalb eines Befehls erledigen.

Negativ Beispiel:

RUN sudo apt-get install -y apache2

RUN sudo apt-get install -y php8.2

RUN sudo apt-get install -y nodejs

RUN sudo apt-get install -y npm

Empfohlene Variante:

RUN sudo apt-get install -y apache2 php8.2 nodejs npm

Befehl CMD

Der Befehl CMD definiert den Standardbefehl, der in einem Container ausgeführt wird, wenn er aus unserem Image erzeugt wird. Es ist jedoch möglich, dass der Container diesen Befehl überschreibt. Ein Docker Image kann nur einen CMD Befehl haben. Wenn mehrere definiert sind, wird nur der letzte Befehl als gültig angesehen. Die Syntax von CMD ist identisch mit der Syntax von RUN.

Beispiel:

CMD echo "Hello world from Tekkie Ninja"

Befehl ADD / COPY

ADD und COPY sind zwei ähnliche Befehle, wobei ADD etwas mehr Funktionen hat als COPY. Nachfolgend wird nicht näher auf die Unterschiede der beiden Funtkionen eingegangen.

Beide Befehle ermöglichen es, eine Datei oder ein Verzeichnis vom Host-System in das Dateisystem des Images zu kopieren. Die Syntax ist einfach:

ADD directory /var/www/html/directory

Hier wird zuerst das Verzeichnis oder die Datei angegeben, die kopiert werden soll, und dann das Ziel. Die Syntax für den COPY-Befehl ist identisch. Beide Befehle haben auch eine alternative Syntax, die verwendet werden muss, wenn der Dateiname Leerzeichen enthält:

COPY ["directory", "/var/www/html/directory"]

Dank dieser Befehle können wir Konfigurationsdateien (z.B. die Apache2-Konfiguration oder eine php.ini) in unser neues Image kopieren.

Befehl WORKDIR

Jeder Befehl RUN, CMD, ADD und COPY bezieht sich standardmäßig auf das Root-Verzeichnis. Wenn dies geändert werden soll, kann dies mit dem Befehl WORKDIR erfolgen. Dieser setzt das neue Referenzverzeichnis für alle nachfolgenden Befehle fest oder bis zum nächsten Aufruf von WORKDIR.

Zum Beispiel:

WORKDIR /var/www

Es kann auch ein relativer Pfad angeben werden, der sich am letzten Aufruf von WORKDIR orientiert:

WORKDIR vhosts/tekkieninja.de

Nach den beiden oben genannten Befehlen wäre der neue Referenzpfad also var/www/vhosts/tekkieninja.de.

Der Beitrag Dockerfile erschien zuerst auf TekkieNinja.

Docker Images

Florian Keßler — Wed, 19 Apr 2023 13:28:49 +0000

Docker-Images stellen den Zustand eines Containers zu einem bestimmten Zeitpunkt dar. Wenn wir beispielsweise einen Docker-Container mit einem Ubuntu-Image starten, wird es erst einmal nicht viel tun. Wir können darin Apache2 installieren und diesen Zustand speichern. Von nun an wird jeder Container, der von diesem Image gestartet wird, Apache2 enthalten. Auf diese Weise bauen die Images aufeinander auf.

Grundlagen

Nehmen wir an, wir haben Apache2 in unserem Image installiert und nennen es „ninja-apache2-server“. Jetzt benötigen wir eine Möglichkeit, um eine Webanwendung auf verschiedenen PHP-Versionen zu testen. Wir können ein Image erstellen, das auf „ninja-apache2-server“ aufbaut und PHP 7.4 installiert, nennen es „ninja-php74-server“. Außerdem können wir ein weiteres Docker Image erstellen, das auch auf „ninja-apache2-server“ aufbaut, aber PHP 8.2 installiert, und nennen es „ninja-php82-server“.

Dies bietet uns mehrere Vorteile:

Wir können mit einem einfachen „docker run“-Befehl blitzschnell virtuelle Maschinen mit verschiedenen PHP-Versionen starten, ohne uns mit mehreren PHP-Versionen innerhalb einer Maschine befassen oder ständig eine andere PHP-Version installieren zu müssen.
Wenn wir unsere Grundlage ändern möchten (in diesem Fall z.B. die Apache2-Version), können wir dies zentral im „ninja-apache2-server“-Image vornehmen, dieses speichern und die darauf aufbauenden Images können diese Änderungen einfach übernehmen. Das spart natürlich viel Zeit, da wir die Änderungen nicht in jeder virtuellen Testmaschine einzeln anpassen müssen.

Dieses einfache Beispiel zeigt uns bereits den Mehrwert einer gut durchdachten Docker-Entwicklungsumgebung. Stellen wir uns das Ganze in einem echten Webumfeld mit Webserver, Datenbank, PHP, NodeJS, Plugins und ständig vielfältiger werdenden Tools vor, dann verwundert die rasant ansteigende Beliebtheit von Docker nicht mehr. Eine Übersicht aller Images ist unter folgendem Link einsehbar.

Zur Zusammensetzung des Namens eines Docker Images dient das folgende Beispiel: „tekkie/ninja-apache2-server:0.1“. Der Teil vor dem Schrägstrich („tekkie“) ist der Name bzw. Account des Autors, der das Image hochgeladen hat. Der Teil danach („ninja-apache2-server“) ist der Name des Images selbst. Zusammen bilden diese das sogenannte Repository. Ein Repository kann mehrere Versionen eines Images enthalten. Diese Versionen werden anhand von Tags unterschieden, welche hinter dem Doppelpunkt stehen. Wenn kein Tag angegeben wird, wird automatisch der Tag „latest“ vergeben. Unser PHP-Beispiel von oben hätten wir auch eleganter lösen können, indem wir ein Image „ninja-php-server“ erstellen und es mit den Tags „7.4“ und „8.2“ versehen.

Docker Images Verwaltung

Zunächst betrachten wir, wie wir herausfinden können, welche Images bereits auf unserem Host installiert sind. Hierfür verwenden wir den Befehl:

docker images

Falls wir ein bestimmtes Image nicht installiert haben, wird es beim Ausführen von „docker run“ automatisch heruntergeladen.

Wenn wir ein Image manuell herunterladen möchten – möglicherweise, weil wir im Zielnetzwerk keinen Zugriff auf das Internet haben -, können wir dies problemlos mit dem Befehl durchführen:

docker pull author/image:tag

Zuletzt können wir selbstverständlich auch ein vorhandenes Docker-Image löschen.

docker rmi author/image:tag

Beachten Sie hierbei das i bei rmi. Der „docker rm“-Befehl ist bereits für das Entfernen von Containern vorgesehen.

Docker Images aktualisieren

Um ein Docker-Image zu aktualisieren, z.B. wenn eine neue Softwareversion verfügbar ist oder sich die Anforderungen geändert haben, gibt es eine einfache Methode. Zunächst müssen wir einen Container aus dem vorhandenen Image starten (wie bereits im vorherigen Artikel erklärt). Die ID des Containers muss notiert werden, da sie später benötigt wird.

Dann können alle erforderlichen Änderungen innerhalb des Containers durchgeführt werden, z.B. die Installation von curl mit dem Befehl apt-get install curl.

Sobald die Installation abgeschlossen ist und alles funktioniert, kann der Container mit exit verlassen werden.

Jetzt wird die oben erwähnte Container-ID benötigt, um den Befehl

docker commit -m "curl installiert" -a "Tekkie Ninja" CONTAINER-ID tekkie/ninja-test-server:1.2

auszuführen.

Dieser etwas längere Befehl kann in seine Einzelteile zerlegt werden:

docker commit bedeutet, dass wir ein Image an das Repository senden möchten.
-m ermöglicht es uns, einen Kommentar zu diesem Commit hinzuzufügen (wie bei GIT), damit wir später wissen, was wir in welchem Commit geändert haben.
-a zeigt den Autor des Commits an, damit wir in einem Team wissen, wer was gemacht hat.
CONTAINER-ID ist die zuvor erwähnte ID des Docker-Containers, den wir zuvor verändert haben.
tekkie/ninja-test-server:1.2 ist der Name, unter dem wir das neue Image speichern möchten (wie bereits oben besprochen).

Docker Images taggen

Zuletzt gibt es noch einen Befehl, um ein Image nachträglich zu taggen. Wie zuvor erwähnt, wird standardmäßig immer das Tag „latest“ zugewiesen, aber wir möchten möglicherweise für unsere eigenen Zwecke ein anderes Tag verwenden. Hierfür benötigen wir die ID des Images, die wir mit dem Befehl „docker images“ in der Image-Liste finden können.

docker tag IMAGE-ID tekkie/ninja-test-server:neuerTag

Im folgenden Artikel werden wir uns genauer mit dem Dockerfile beschäftigen und einen genaueren Blick darauf werfen.

Hier gehts weiter.

Der Beitrag Docker Images erschien zuerst auf TekkieNinja.

Was sind Docker Container und wie funktionieren sie?

Florian Keßler — Sun, 16 Apr 2023 13:41:12 +0000

Docker Container sind eine der Hauptgründe, warum sich Docker so schnell verbreitet hat. Ein Docker Container ist eine einfach konfigurierbare, abgeschlossene Einheit, in der Anwendungen ausgeführt werden können. Ein Container kann als Frachtcontainer betrachtet werden, in dem sich ein Männchen befindet, das eine bestimmte Aufgabe ausführt. Innerhalb des Containers sieht es immer gleich aus, unabhängig davon, wo sich der Container gerade befindet. Unabhängig ob auf dem privaten Windows Rechner oder auf einem Server mit einem Linux Betriebssystem. Ein Dockerfile beschreibt den Container so, dass er auf einem anderen Rechner genau gleich aufgebaut werden kann.

Docker Images sind die Baupläne für Container, die über das zentrale Docker Hub mit anderen Entwicklern geteilt werden können. Aus den Images werden dann die jeweiligen Container gestartet, vergleichbar mit der objektorientierten Programmierung, wo aus einer Klasse mehrere Instanzen erzeugt werden. Wenn mehrere Container vorhanden sind, die miteinander kommunizieren sollen, können sie über das sogenannte Linking miteinander verknüpft werden. Dadurch können Kommunikationswege wie offene Ports oder gemeinsame Ordner festgelegt werden.

Ein weiterer Vorteil von Docker Containern besteht darin, dass sie nur so lange leben, wie sie etwas tun. Alles, was innerhalb des Containers passiert, verschwindet, sobald er beendet wird. Wenn jedoch mit persistenten Daten gearbeitet werden soll, können Ordner zwischen dem Host-Rechner und dem Container geteilt werden, um sicherzustellen, dass Änderungen auf beiden Seiten automatisch aktualisiert werden.

Den ersten Docker Container starten

Beginnen wir mit einem einfachen Schritt und starten einen Docker-Container. Container basieren immer auf einem Docker-Image, auch wenn sie von Entwicklern erstellt werden. Docker Hub bietet hunderte von verschiedenen Images für alle möglichen Situationen an. Ein Basisimage könnte beispielsweise die Grundfunktionalität von Ubuntu sein, die als ubuntu:22.04 bezeichnet wird. Die 22.04 ist dabei eine Art Version.

Wenn wir ein Docker-Container starten wollen, geben wir einfach den folgenden Befehl ein:

docker run ubuntu echo "Hello World"

Dies ist ein einfaches „Hello World“-Beispiel, aber man muss irgendwo anfangen. Was passiert eigentlich bei diesem Befehl?

Zunächst überprüft Docker, ob es das Image „ubuntu“ lokal gespeichert hat. Wenn nicht, wird es automatisch heruntergeladen. Da kein Tag angegeben wurde, wird automatisch das neueste Image genommen.
Docker startet einen Container aus dem angegebenen Image und führt den Befehl „echo ‚Hello World'“ innerhalb des Containers aus, der einfach nur „Hello World“ ausgibt. Docker beendet den Container wieder, da er seinen Zweck erfüllt hat.

Das hat zwar etwas gedauert, um nur „Hello World“ auf dem Bildschirm zu sehen, aber das Herunterladen des Images brauchte seine Zeit. Wenn wir den Befehl jetzt ein zweites Mal ausführen, wird die Ausgabe sofort angezeigt, da das Image bereits lokal gespeichert ist.

Run Parameter

Standardmäßig wird der Container sofort nach dem Ausführen des Befehls beendet. Wenn wir das Standardverhalten ändern möchten, gibt es verschiedene Parameter für den „docker run“-Befehl, die wir verwenden können. Hier sind einige davon:

-i sorgt dafür, dass der Container interaktiv ist. Das bedeutet, wir können während der Laufzeit damit interagieren.
-t bindet unsere Ein- und Ausgaben an diesen interaktiven Container.
-d sorgt dafür, dass der Container im Hintergrund weiterläuft (Daemon-Modus). Das ist nützlich für Container, die dauerhaft laufen sollen (beispielsweise Container, die Server enthalten oder Aufgaben, die einige Minuten oder Stunden dauern können).
-p bindet Ports von unserem Host an den Container. Ein Beispiel wäre „-p 80:5000“, das unseren Hostport 80 auf den Containerport 5000 mappt. Das kann sinnvoll sein, wenn wir denselben Container mehrfach aufrufen und die Ports andernfalls kollidieren würden.
-v verlinkt ein Verzeichnis auf unserem Hostrechner mit einem Verzeichnis innerhalb des Containers. So können Daten persistent gespeichert werden, da diese normalerweise mit dem Auslaufen des Containers verschwinden. Ein Beispiel wäre „-v ./folder:/var/folder“. Vor dem Doppelpunkt steht das Verzeichnis auf dem Hostrechner und danach das Verzeichnis innerhalb des Containers – genau wie bei den Ports.
-name gibt unserem Container einen Namen. Dieser wird andernfalls automatisch vergeben, ist aber nicht immer leicht zu merken. Namen können als Ersatz für die (sehr kryptische) Container-ID verwendet werden und machen daher durchaus Sinn. Hierbei ist zu beachten, dass die Namen auf dem Hostrechner eindeutig sein müssen. Wenn wir also einen neuen Container mit diesem Namen an.

Container auflisten und stoppen

Wenn wir Informationen über die aktuell ausgeführten Docker Container benötigen, können wir den Befehl

docker ps

verwenden. Dieser Befehl zeigt uns wichtige Eigenschaften wie die Container-ID, das Image, die zugeordneten Ports oder den Namen des Containers an.

Standardmäßig werden nur laufende Container aufgelistet. Wenn wir alle Container auf unserem Host anzeigen lassen möchten, verwenden wir einfach den Parameter -a.

Wenn wir einen laufenden Container beenden möchten, können wir den Befehl

docker stop NAME/ID

verwenden. Der Container wird dann gestoppt, aber er bleibt weiterhin vorhanden und behält den Zustand des Docker-Images bei, das beim Ausführen von docker run verwendet wurde. Wenn wir das Image aktualisieren, müssen wir docker run erneut ausführen, um die Änderungen wirksam zu machen.

Um den Container später wieder zu starten, verwenden wir einfach den Befehl

docker start NAME/ID

Container entfernen

Wie bereits erwähnt, muss ein Docker-Container entfernt werden, wenn er erneut mit dem gleichen Namen über den docker run Befehl gestartet werden soll. Hierfür kann der Befehl

docker rm NAME/ID

verwendet werden, allerdings muss der Container zuvor mit dem Befehl docker stop gestoppt werden.

Im folgenden Artikel werden wir uns genauer mit Docker Images beschäftigen und einen genaueren Blick darauf werfen.

Hier gehts weiter.

Der Beitrag Was sind Docker Container und wie funktionieren sie? erschien zuerst auf TekkieNinja.

Was ist Docker?

Florian Keßler — Sun, 16 Apr 2023 13:13:42 +0000

Docker ermöglicht es uns, Anwendungen in Containern auszuführen und damit komplexe Infrastrukturen zu erstellen. Diese Container können aufeinander aufbauen und miteinander kommunizieren, was uns die Erstellung von flexiblen und skalierbaren Systemen erleichtert. Im Gegensatz zu herkömmlichen virtuellen Maschinen müssen Container nicht jedes Mal ein vollständiges Betriebssystem mitbringen, sondern können nur die notwendigen Daten und Anwendungen enthalten. Das ermöglicht es uns, Serverumgebungen einfach auf unserem eigenen Rechner zu replizieren und Kompatibilitätsprobleme zu vermeiden.

Vorteile von Docker

Besonders in der Webentwicklung bietet Docker entscheidende Vorteile. Wir können die Serverumgebung, auf der unsere Webanwendung später laufen wird, genau auf unserem eigenen Rechner nachbilden, unabhängig vom verwendeten Betriebssystem. Das Teilen von Containern erfolgt über das Docker-Hub, wo wir eine Vielzahl von vorkonfigurierten Images finden können. Unter folgendem Link kann ein erster Überblick über die verschiedenen Images verschafft werden. In dieser Artikelreihe werde ich die Grundlagen von Docker und Docker-Compose erläutern und einige Beispiele geben, um Ihnen den Einstieg zu erleichtern.

Ein wichtiger Vorteil von Containerisierung ist, dass sie uns die Möglichkeit gibt, Cloud-Hosting-Anbieter zu nutzen. Wenn wir ein Image erstellen und konfigurieren, können wir den Anbieter einfach auffordern, einen Container mit genau dieser Konfiguration zu starten. Dies bietet Flexibilität und Effizienz bei der Skalierung und Verwaltung von Anwendungen.

Trennung von Anwendungen und Abhängigkeiten

Containerisierung bietet auch die Möglichkeit, Anwendungen und ihre Abhängigkeiten voneinander zu trennen, was die Wartung und Aktualisierung von Anwendungen erleichtert. Dies ist einer der Gründe, warum ich mich eingehender mit Containerisierung beschäftigt habe. Die Vielseitigkeit dieser Technologie ist beeindruckend und bietet eine großartige Möglichkeit, Anwendungen sicher und effektiv zu betreiben.

In dieser Blogserie geht es um die Grundlagen von Docker und Docker-Compose sowie um praktische Beispiele. Im Folgenden findest du Links zu den einzelnen Beiträgen, in denen ich speziell auf folgende Themen eingegangen bin:

Ich wünsche euch viel Spaß beim lesen!

Der Beitrag Was ist Docker? erschien zuerst auf TekkieNinja.