Viele Anweisungen aus dem Internet beschreiben ein bestimmtes Minimum an Aktionen und damit ein Minimum an Befehlen und Möglichkeiten.
Ich beschloss, eine Auswahl von ein wenig beleuchteten Merkmalen, Merkmalen, zu treffen. Der Artikel behauptet nicht, einzigartig zu sein, er wird mir als Erinnerung helfen, und vielleicht wird er einigen Padawanern helfen, ihre Reise mit Docker-Compose zu beginnen.
Verwenden mehrerer docker-compose.yml-Dateien
Es gibt komplexe Konfigurationen, bei denen es eine bestimmte Grundschicht von Containern gibt, die beispielsweise immer benötigt wird. Und normalerweise kommt es vor, dass wir vom benachbarten Team \ ein anderes Projekt \ Internet nehmen und es nach Ihren Wünschen fertigstellen. Wenn jedoch mehrere Befehle vorhanden sind, kann der Basisteil in ein gemeinsames internes Repository verschoben werden. Und wir erhalten für die meisten Projekte ein identisches Basisteil, das ebenfalls versioniert ist.
Beschreiben wir ein Beispiel für eine grundlegende Docker-Compose-Base.yml.
Angenommen, dies ist ein benutzerdefiniertes Nginx-Image mit Zertifikaten, Optimierungen und Say-Metriken. Und Exporteur für Prometheus:
version: '2' services: nginx: image: nginx nginx-exporter: image: nginx/nginx-prometheus-exporter
Nun beschreiben wir ein Beispiel für unsere Anwendung docker-compose-app.yml:
version: '2' services: backend: image: internal.local/super-app:0.1.2
Zu Beginn brauchen wir das übliche Team mit einem Unterschied. Wir werden 2 Docker-Compose-Dateien angeben:
docker-compose up -d -f docker-compose-base.yml -f docker-compose-app.yml
Und voila, wir bekommen eine Reihe von Diensten, als ob sie in einer einzigen Docker-Compose-Datei beschrieben wären!
Es gibt auch eine zweite Option für die Verwendung mehrerer Dateien mithilfe der Extended-Direktive.
docker-compose-base.yml:
version: '2' services: nginx: image: nginx nginx-exporter: image: nginx/nginx-prometheus-exporter
docker-compose-app.yml:
version: '2' services: backend: image: internal.local/super-app:0.1.2 ### web: extends: # ( ) file: docker-compose-base.yml # service: nginx web-exporter: extends: file: docker-compose-base.yml service: nginx-exporter
Add-on von iSlava :
Sie können alle Erstellungsdateien in Umgebungsvariablen beschreiben und docker-compose up -d verwenden, ohne Dateien manuell anzugeben:
COMPOSE_PATH_SEPARATOR=: COMPOSE_FILE=docker-compose-base.yml:docker-compose-app.yml
Welche Option Sie wählen - Sie wählen. Alles einzeln wollte ich nur Optionen zeigen =)
Vererbung in Docker-Compose
Das folgende Beispiel erfordert die Version docker-compose > = 2.4
Auch ein ziemlich interessantes Feature, und tatsächlich werden nur wenige erwähnt.
Diese Funktionalität ermöglicht es uns, mehrere Dienste desselben Typs in der Docker-Compose-Datei zu beschreiben, ohne ihre Beschreibung zu duplizieren, nämlich zu erben.
Zum Beispiel haben wir eine Datei wie diese:
version: '2.4' services: backend: image: internal.local/super-app:0.1.2 ports: - 8080:8080 - 9090:9090 volumes: - ./conf/some.conf:/etc/app/some.conf:ro
Es bestand die Notwendigkeit, mehrere Container anzuheben, aber mit einigen Unterschieden können wir natürlich "sparen" und ändern, aber wir können dies tun:
version: '2.4' services: backend: &base-app # image: internal.local/super-app:0.1.2 ports: - 8080:8080 - 9090:9090 volumes: - ./conf/some.conf:/etc/app/some.conf:ro backend-2: <<: *base-app # ports: # - 8081:8080
Auf diese Weise haben wir die Möglichkeit, an einer Stelle zu wechseln, anstatt die Beschreibung jedes Containers zu bearbeiten.
Es gibt eine andere Option, um in den Stammbereich zu wechseln, zum Beispiel:
version: '2.4' services: x-backend: # "x-" , . &base-app image: internal.local/super-app:0.1.2 ports: - 8080:8080 - 9090:9090 volumes: - ./conf/some.conf:/etc/app/some.conf:ro backend: <<: *base-app # backend-2: <<: *base-app # ports: # - 8081:8080
Ressourcenlimits
Ab Version 2.2 können Sie Ressourcenbeschränkungen für Container verwenden, tatsächlich ab Version 2.1, aber es werden immer noch nicht alle ausgeliefert =)
Es gibt eine Nuance! In Version 3 werden diese Funktionen entfernt! Der Schwerpunkt liegt bereits auf dem Hafenschwarm.
Das einfachste Beispiel für eine CPU-Ressourcenbeschränkung, MEM:
version: '2.2' services: backend: cpus: 1.5 # . cpuset: '0,3' # . mem_limit: 1gb # 1 memswap_limit: 2gb # SWAP . oom_kill_disable: true # , OOM Killer , . image: internal.local/super-app:0.1.2 ports: - 8080:8080 - 9090:9090 volumes: - ./conf/some.conf:/etc/app/some.conf:ro
Bilder in ein Archiv packen
Leider ist es nicht immer möglich, Bilder in Ihre eigene oder Cloud-Docker-Registrierung zu pushen. Manchmal müssen Bilder aus einer Docker-Compose-Datei gesammelt und beispielsweise ein Dateiarchiv gesendet werden. Hände machen es manchmal lange, also habe ich ein einfaches Skript entworfen, plötzlich ist jemand nützlich:
#!/bin/bash dc=${1} if [ ! -z ${dc} ] && [ -f ${dc} ]; then echo "Saving docker images from file ${dc}..." images=`grep image: ${dc} | awk '{print $2}'` docker save ${images} | gzip > docker-images.gz echo "Success!" else echo "ERROR! You must set path to docker-compose.yml as argument!" fi
Speichern Sie in der Datei docker-compose-images-save.sh
Wir geben das Recht zur Ausführung:
chmod +x docker-compose-images-save.sh
Wir starten es und übergeben den Pfad zur Docker-Compose-Datei als Argument:
./docker-compose-images-save.sh /home/some_user/docker-compose-app.yml
Bei der Ausgabe gelangen wir in den Ordner, aus dem das docker-images.gz mit Bildern aufgerufen wurde - docker-images.gz
Auf jede Art und Weise können wir an einen Remote-Server senden.
Jetzt reicht es auf dem Remote-Server aus, Folgendes auszuführen:
gzip -cd docker-images.gz | docker load
Alle Bilder werden in die lokale Registrierung hochgeladen, danach können Sie sie hier sicher ausführen
docker-compose up -d , da sich alle Bilder in der lokalen Registrierung im Internet befinden, wird Docker nicht darauf zugreifen.
IPv6 weiterleiten
Bei bestimmten Aufgaben kann IPv6 äußerst nützlich sein. Nehmen Sie zumindest die Nuance, dass Roskomnadzor den gesamten Datenverkehr problemlos über IPv6 leitet, und derselbe Telegrammbot funktioniert problemlos.
Ich werde eine Situation betrachten, in der sich IPv6 nicht auf Ihrem Computer befindet, sei es eine virtuelle Maschine oder ein Server im Internet.
Stellen Sie sicher, dass IPv6 auf Systemebene aktiviert ist:
sysctl net.ipv6.conf.all.disable_ipv6
Der Wert sollte 0 sein, wenn nicht, ändern Sie:
sysctl -w net.ipv6.conf.all.disable_ipv6=0
Miredo installieren (Dies ist ein Dienst mit einem integrierten VPN zum Server, der uns öffentliches IPv6 gibt.)
apt-get install miredo -y
Überprüfen Sie, ob der Dienst ausgeführt wird:
systemctl status miredo
Wir überprüfen, ob wir die IPv6-Adresse erhalten haben:
ifconfig teredo
Wir schreiben in /etc/docker/daemon.json
{ "ipv6": true, "fixed-cidr-v6": "2001:db8:1::/64" }
Starten Sie den Docker neu:
systemctl restart docker
Nun, es bleibt NAT für IPv6 zu aktivieren, damit die internen Adressen unseres Containers über unsere Teredo-Schnittstelle nach außen gelangen können:
ip6tables -t nat -A POSTROUTING -o teredo -j MASQUERADE
Wir erhöhen den Docker-Container, den wir benötigen, und er kann über die IPv6-Adresse veröffentlicht werden.
Das obige Beispiel mit sysctl und iptables funktioniert bis zum Neustart. Wenn Sie dies fortlaufend tun müssen, sollten Sie die Anweisungen für Ihre Distribution lesen. Es gibt Unterschiede.
Ich hoffe, jemand, der die Informationen hier zur Verfügung gestellt hat, wird nützlich sein.