Vorgeschichte
Eines schönen Tages musste ich eine Entwicklungsumgebung für mein Projekt bereitstellen. Vagrant hatte es bereits satt und wollte eine einzige Entwicklungsumgebung für alle Projektteilnehmer, die mit dem Produktionsserver identisch ist. Nachdem ich mir Informationen über den Hipster-Docker angehört hatte, beschloss ich, mich damit zu befassen. Als Nächstes werde ich versuchen, alle Schritte von der Installation eines Dockers in einem LAN bis zur Bereitstellung eines Produkts für KVM so detailliert wie möglich zu beschreiben.
Ursprünglicher Technologie-Stapel:- Hafenarbeiter
- Symfonie 4
- Nginx
- php-fpm
- postgresql
- Elasticsearch
- rabbitmq
- Jenkins
Eisen:- Laptop unter OS Ubuntu 16.04
- Produktionsserver auf KVM-Hosting
Warum habe ich neben dem technologischen Stapel auch den Eisenstapel aufgelistet?Wenn Sie noch nie mit einem Docker gearbeitet haben, kann es zu einer Reihe von Problemen kommen, die speziell mit der Hardware, dem Betriebssystem Ihres Laptops oder der Art der Hosting-Virtualisierung zusammenhängen.
Der erste und wahrscheinlich wichtigste Aspekt bei der Arbeit mit dem Docker ist das Betriebssystem Ihres Laptops. Der einfachste Weg, mit Docker zu arbeiten, ist auf Linux-Systemen. Wenn Sie unter Windows oder Mac arbeiten, haben Sie zu 100% einige Schwierigkeiten, aber diese Schwierigkeiten sind nicht kritisch. Wenn Sie "googeln" möchten, wie dies behoben wird, treten keine Probleme auf.
Die zweite Frage ist Hosting. Warum wird Hosting mit KVM-Virtualisierungstyp benötigt? Der Grund dafür ist, dass sich die VPS-Virtualisierung stark von KVM unterscheidet und Sie Docker einfach nicht auf VPS installieren können, da VPS Serverressourcen dynamisch zuweist.
Zwischensumme: Für den schnellsten Start auf dem Docker ist es am sinnvollsten, Ubuntu als lokales Betriebssystem und KVM-Hosting (oder als eigenen Server) zu wählen. Darüber hinaus wird sich die Geschichte genau auf diese beiden Komponenten stützen.
Docker-Compose für LAN
Installation
Zuerst müssen Sie das Docker selbst lokal installieren. Sie können die Installationsanweisungen auf der offiziellen Website sehen,
die auf die offizielle Dokumentation für Ubuntu verweist (Sie müssen Docker und Docker-Compose installieren) oder indem Sie den Befehl in der Konsole ausführen:
curl -sSl https://get.docker.com/ | sh
Dieser Befehl installiert sowohl Docker als auch Docker-Compose. Überprüfen Sie danach die Docker-Version mit dem folgenden Befehl:
docker --version
Ich beginne diese ganze Sache mit Docker Version 18.06.0-ce.
Die Installation ist abgeschlossen!
Bewusstsein
Um mit etwas weniger erfolgreich arbeiten zu können, müssen Sie eine Vorstellung davon haben, wie es funktioniert. Wenn Sie zuvor nur mit Vagrant oder ähnlichem gearbeitet haben, ist dies zunächst äußerst ungewöhnlich und unverständlich, dies ist jedoch zunächst nur der Fall.
Ich werde versuchen, eine Analogie für Vagrant zu ziehen. Jetzt können viele sagen, dass der Vergleich von Vagrant und Docker grundsätzlich falsch ist. Ja, ich stimme dem zu, aber ich werde sie nicht vergleichen. Ich werde nur versuchen, den Neuankömmlingen, die nur mit Vagrant gearbeitet haben, das Docker-Arbeitssystem zu vermitteln, um das anzusprechen, was die Neuankömmlinge wissen.
Meine Vision des Containers „an den Fingern“ lautet wie folgt: Jeder Container ist eine winzige isolierte Welt. Jeder Container kann sich so vorstellen, als wäre es ein winziger Vagrant, auf dem nur 1 Tool installiert ist, zum Beispiel Nginx oder PHP. Anfangs sind Container im Allgemeinen von allem isoliert, aber durch knifflige Manipulationen können Sie alles so konfigurieren, dass sie miteinander kommunizieren und zusammenarbeiten. Dies bedeutet nicht, dass jeder der Container eine separate virtuelle Maschine ist, überhaupt nicht. Aber es ist einfacher für das anfängliche Verständnis, wie es mir scheint.
Vagrant beißt einfach einen Teil der Ressourcen Ihres Computers ab, erstellt eine virtuelle Maschine, installiert ein Betriebssystem darauf, installiert Bibliotheken und installiert alles, was Sie nach dem Vagrant-Up in das Skript geschrieben haben. Letztendlich sieht es ungefähr so aus:
→
Schaltplan anzeigenDocker wiederum arbeitet radikal anders. Es werden keine virtuellen Maschinen erstellt. Docker erstellt Container (im Moment können Sie sie sich als mikro-virtuelle Maschinen vorstellen) mit seinem alpinen Betriebssystem und 1-3 Bibliotheken, die für das Funktionieren der Anwendung erforderlich sind, z. B. PHP oder Nginx. Gleichzeitig blockiert Docker die Ressourcen Ihres Systems nicht für sich selbst, sondern verwendet sie einfach nach Bedarf. Letztendlich wird es zur Veranschaulichung ungefähr so aussehen:
→
Schaltplan anzeigenJeder der Container verfügt über ein Image, aus dem er erstellt wird. Die überwiegende Mehrheit der Images ist eine Erweiterung eines anderen Images, z. B. Ubuntu xenial oder Alpine oder Debian, auf dem zusätzliche Treiber und andere Komponenten bereitgestellt werden.
Mein erstes Bild war für PHP-Fpm. Mein Bild erweitert das offizielle PHP-Bild: 7.2-fpm-alpine3.6. Das heißt, es nimmt im Wesentlichen das offizielle Image und liefert die Komponenten, die ich benötige, z. B. pdo_pgsql, imagick, zip und so weiter. So können Sie das Bild erstellen, das Sie benötigen. Wenn Sie möchten, können Sie es
hier verwenden .
Bei der Erstellung von Bildern ist meiner Meinung nach alles recht einfach, wenn sie beispielsweise auf der Basis von Xenial hergestellt werden, aber sie liefern ein wenig Hämorrhoiden, wenn sie auf der Grundlage von Alpine hergestellt werden. Bevor ich mit dem Docker anfing, hörte ich im Grunde nichts von Alpine, da Vagrant immer unter Ubuntu Xenial für mich arbeitete. Alpine ist ein leeres Linux-Betriebssystem, in dem es im Wesentlichen gar nichts gibt (extremes Minimum). Daher ist es zunächst äußerst unpraktisch, damit zu arbeiten, da es zum Beispiel nicht die gleiche apt-get-Installation gibt (an die Sie sich gewöhnt haben), sondern nur apk add und eine nicht ganz vernünftige Reihe von Paketen. Ein großes Plus von Alpine ist sein Gewicht. Wenn Xenial beispielsweise (abstrakt) 500 Säcke wiegt, beträgt Alpine (abstrakt) etwa 78 Säcke. Was betrifft das überhaupt? Dies wirkt sich auf die Erstellungsgeschwindigkeit und das Endgewicht aller Bilder aus, die am Ende auf Ihrem Server gespeichert werden. Nehmen wir an, Sie haben 5 verschiedene Container und alles, was auf Xenial basiert, hat ein Gesamtgewicht von mehr als 2,5 Gigs und alpine - nur etwa 500 Taschen. Daher sollten wir uns im Idealfall bemühen, dass die Behälter so dünn wie möglich sind. (Nützlicher Link zum Installieren von Paketen in Alpine -
Alpine-Paketen ).
Überall auf dem
Docker-Hub schreiben
sie , wie der Container mit dem
docker run gestartet wird, und aus irgendeinem Grund schreiben sie nicht, wie er über Docker-Compose gestartet werden kann, und über Docker-Compose wird er die meiste Zeit gestartet, da nur sehr wenig gejagt wird Starten Sie alle Container, Netze, offenen Ports und mehr manuell. Docker-Compose im Auftrag des Benutzers sieht aus wie eine Yaml-Datei mit Einstellungen. Es enthält eine Beschreibung aller Dienste, die gestartet werden müssen. Mein Build für die lokale Umgebung lautet wie folgt:
version: '3.1' services: php-fpm: image: otezvikentiy/php7.2-fpm:0.0.11 ports: - '9000:9000' volumes: - ../:/app working_dir: /app container_name: 'php-fpm' nginx: image: nginx:1.15.0 container_name: 'nginx' working_dir: /app ports: - '7777:80' volumes: - ../:/app - ./nginx/nginx.conf:/etc/nginx/conf.d/default.conf postgres: image: postgres:9.6 ports: - '5432:5432' container_name: 'postgresql' working_dir: /app restart: always environment: POSTGRES_DB: 'db_name' POSTGRES_USER: 'db_user' POSTGRES_PASSWORD: 'db_pass' volumes: - ./data/dump:/app/dump - ./data/postgresql:/var/lib/postgresql/data rabbitmq: image: rabbitmq:3.7.5-management working_dir: /app hostname: rabbit-mq container_name: 'rabbit-mq' ports: - '15672:15672' - '5672:5672' environment: RABBITMQ_DEFAULT_USER: user RABBITMQ_DEFAULT_PASS: password RABBITMQ_DEFAULT_VHOST: my_vhost elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch:6.3.0 container_name: 'elastic-search' environment: - discovery.type=single-node - "discovery.zen.ping.unicast.hosts=elasticsearch" - bootstrap.memory_lock=true - "ES_JAVA_OPTS=-Xms512m -Xmx512m" ports: - 9200:9200 - 9300:9300 working_dir: /app volumes: - ../:/app - ./data/elasticsearch:/usr/share/elasticsearch/data volumes: elasticsearch: postgresql:
docker-compose.yaml für SF4 ist eine bestimmte Reihe von Diensten: nginx, php-fpm, postgresql, rabbitmq (falls erforderlich), elasticsearch (falls erforderlich). Für die lokale Umgebung ist dies ausreichend. Damit alles funktioniert, gibt es nur minimale Einstellungen, ohne die nichts funktioniert. Am häufigsten sind dies Image, Volumes, Ports, Umgebung, Arbeitsverzeichnis und Containername. Alles zum Starten dieses oder jenes Images ist in der Dokumentation auf
hub.docker.com beschrieben . Es gibt nicht immer eine Beschreibung für Docker-Compose, aber dies bedeutet nicht, dass es nicht damit funktioniert. Es ist nur notwendig, alle eingehenden Daten vom Docker-Ausführungsbefehl an Docker-Compose zu übertragen, und alles wird funktionieren.
Zum Beispiel gibt es hier ein Bild für RabbitMQ. Wenn Sie DIESES zum ersten Mal sehen, verursacht es gemischte Gefühle und Emotionen, aber nicht alles ist so beängstigend. Tags sind in diesem Bild angegeben. Normalerweise Tags - repräsentieren verschiedene Bilder, verschiedene Versionen der Anwendung mit verschiedenen erweiterbaren Bildern. Zum Beispiel bedeutet das Tag 3.7.7-alpine, dass dieses Bild dünner ist als zum Beispiel 3.7.7, da es auf Alpine basiert. Nun und auch in den Tags werden meistens die Versionen der Anwendung angegeben. Normalerweise wähle ich die neueste Version und die stabile Version der Anwendung selbst und das Alpenbild.
Nachdem Sie ein Tag studiert und ausgewählt haben, sehen Sie häufig etwas in dieser Art:
docker run -d --hostname my-rabbit --name some-rabbit -e RABBITMQ_DEFAULT_USER=user -e RABBITMQ_DEFAULT_PASS=password rabbitmq:3-management
Und der erste Gedanke ist WTF? Wie übertrage ich das auf Docker-Compose?
Alles ist ziemlich einfach. Tatsächlich zeigt diese Zeile dieselben Parameter wie in der yaml-Datei an, nur abgekürzt. Zum Beispiel ist -e eine Umgebung, in die verschiedene Parameter übergeben werden. Es kann auch Einträge wie -p geben. Dies sind Ports, die in yaml als Ports bezeichnet werden. Dementsprechend müssen Sie nur die Abkürzungen für die Docker-Ausführung "googeln" und die vollständigen Namen in der Yaml-Datei anwenden, um ein unbekanntes Bild in einer qualitativ hochwertigen Weise zu verwenden.
Nun zurück zu docker-compose.yml, das ich oben als Beispiel zitiert habe.
In diesem Beispiel wird mein php7.2-Image als Erweiterung für das offizielle php7.2-fpm-alpine-Image verwendet. Wenn Sie jedoch nicht so viele zusätzliche Bibliotheken benötigen, können Sie Ihre Erweiterung für das offizielle Image erstellen und verwenden. Die restlichen Bilder für LAN sind vollständig original und offiziell.
Bild - Geben Sie an, welches Bild heruntergeladen werden soll. Zum Beispiel (rabbitmq: 3.7.7-management-alpine).
Ports - Geben Sie die Ports an, die der Container verwenden soll (siehe Bilddokumentation). Beispiel nginx Port ist standardmäßig 80. Wenn Sie Port 80 verwenden möchten, müssen Sie hier 80:80 angeben, und Ihre Site ist auf localhost verfügbar. Oder Sie können 7777: 80 angeben, und dann befindet sich Ihre Site unter der URL localhost: 7777. Dies ist erforderlich, damit mehrere Projekte auf demselben Host bereitgestellt werden können.
Volumes - Freigegebene Verzeichnisse werden hier angezeigt. Ihr Projekt befindet sich beispielsweise im Verzeichnis ~ / projects / my-sf4-app, und der PHP-Container ist so konfiguriert, dass er mit dem Verzeichnis / app zusammenarbeitet (wie in / var / www / my-sf4-app). Dementsprechend wäre es für den Container bequem, Zugang zum Projekt zu haben. Dementsprechend schreiben wir in Bänden
~/projects/my-sf4-app:/app (siehe dieses Beispiel in docker-compose.yml oben (ich habe es relativ angegeben ../:/app)).
Auf diese Weise wird der Ordner für den Container freigegeben und kann verschiedene Aktionen ausführen, z. B.
php bin/console doctrine:migrations:migrate . Es ist auch bequem, diese Verzeichnisse zu verwenden, um Anwendungsdaten zu speichern. In postgresql können Sie beispielsweise ein Verzeichnis zum Speichern von Datenbankdaten angeben. Wenn Sie den Container neu erstellen, müssen Sie weder einen Speicherauszug noch Fixtures rollen.
Arbeitsverzeichnis -
Gibt das Arbeitsverzeichnis des Containers an. In diesem Fall / app (oder analog zum Vagabund / var / www / my-sf4-app).
Umgebung - Hier werden alle Variablen für den Container übergeben. Beispielsweise werden für rabbitmq der Benutzername und das Passwort übertragen, für postgresql werden der Basisname, der Benutzername und das Passwort übergeben.
container_name ist ein optionales Feld, das ich jedoch lieber angeben möchte, um die Verbindung zu Containern zu vereinfachen. Wenn nicht angegeben, werden Standardnamen mit Hashes zugewiesen.
Dies sind die Hauptparameter, die angegeben werden müssen. Der Rest kann optional für zusätzliche Einstellungen oder gemäß der Dokumentation für den Container sein.
Um dies alles zu starten, müssen Sie den
docker-compose up -d in dem Verzeichnis ausführen
docker-compose up -d in dem sich die Docker-compose-Datei befindet.
Wie und wo soll das alles für LAN gespeichert werden?
Für LAN verwende ich den Docker-Ordner im Stammverzeichnis des Projekts.
Es enthält den Datenordner, in dem ich alle Informationen postgresql und elasticsearch speichere, sodass Sie beim Neuerstellen des Projekts keine Fixtures von Grund auf neu rollen müssen. Es gibt auch einen Nginx-Daddy, in dem ich die Konfiguration für den lokalen Nginx-Container speichere. Ich synchronisiere diese Ordner in docker-compose.yml mit den entsprechenden Dateien und Ordnern in den Containern. Auch meiner Meinung nach ist es sehr praktisch, Bash-Skripte für die Arbeit mit Docker zu schreiben. Das Skript start.sh startet beispielsweise Container, installiert Composer, bereinigt den Cache und migriert. Es ist auch praktisch für Projektkollegen, sie müssen nichts tun, sie führen nur das Skript aus und alles funktioniert.
Beispiel für ein Start.sh-Skript
Beispiel für ein Skript in
Php-fpm-command.sh
Beispiel für das Skript
Connect-to-php-fpm.sh #!/usr/bin/env bash docker exec -i -t --privileged php-fpm bash
Hier endet die lokale Entwicklungsumgebung. Herzlichen Glückwunsch, Sie können das fertige Ergebnis mit Ihren Kollegen teilen! )
Produktiv
Vorbereitung
Angenommen, Sie haben bereits etwas in ein LAN geschrieben und möchten es auf einem Produktionsserver oder einem Testserver ablegen. Sie haben Hosting auf KVM-Virtualisierung oder Ihren Server im nächsten Raum mit Klimaanlage.
Um ein Produkt oder eine Betaversion bereitzustellen, muss auf dem Server ein Betriebssystem (idealerweise Linux) und ein Docker installiert sein. Docker kann auf die gleiche Weise wie im LAN installiert werden, es gibt keine Unterschiede.
Die Produktivität von Docker unterscheidet sich geringfügig von LAN. Erstens können Sie nicht nur Passwörter und andere Informationen verwenden und Docker erstellen. Zweitens können Sie Docker-Compose nicht direkt verwenden.
Docker verwendet Docker-Schwarm und Docker-Stack für die Produktivität. Wenn es direkt an den Fingern liegt, unterscheidet sich dieses System nur in anderen Befehlen und in diesem Docker-Schwarm ist es ein Load Balancer für den Cluster (wieder ein bisschen abstrakt, aber es wird leichter zu verstehen sein).
PS: Ich rate Ihnen, das Einrichten eines Docker-Schwarms auf Vagrant zu üben (egal wie paradox dies klingen mag). Ein einfaches Rezept für das Training: Nehmen Sie einen leeren Vagrant mit demselben Betriebssystem wie im Produkt und konfigurieren Sie ihn zum Starten.
Um den Docker-Schwarm zu konfigurieren, müssen Sie nur einige Befehle ausführen:
docker swarm init --advertise-addr 192.168.***.** (ip- ) mkdir /app ( app) chown docker /app ( ) docker stack deploy -c docker-compose.yml my-first-sf4-docker-app
Lassen Sie uns dies alles etwas genauer betrachten.
Docker-Schwarm init --advertise-addr -
Startet Docker-Schwarm selbst direkt und fummelt an einem Link
herum, sodass Sie einen anderen Server an diesen "Schwarm" anschließen können, damit er im Cluster funktioniert.
mkdir / app && chown .. - Sie müssen alle erforderlichen Verzeichnisse erstellen, damit der Docker im Voraus arbeiten kann, damit er sich während des
Builds nicht über das Fehlen von Verzeichnissen beschwert.
Docker Stack Deploy -c Docker-Compose.yml My-First-SF4-Docker-App - Dieser Befehl startet die Assemblierung Ihrer Anwendung selbst, ein Analogon von Docker-Compose Up -d nur für Docker-Schwarm.
Um eine Assembly zu starten, benötigen Sie dieselbe docker-compose.yaml, die jedoch speziell für Productive / Beta bereits geringfügig geändert wurde.
version: '3.1' services: php-fpm: image: otezvikentiy/php7.2-fpm:0.0.11 ports: - '9000:9000' networks: - my-test-network depends_on: - postgres - rabbitmq volumes: - /app:/app working_dir: /app deploy: replicas: 1 restart_policy: condition: on-failure placement: constraints: [node.role == manager] nginx: image: nginx:1.15.0 networks: - my-test-network working_dir: /app ports: - '80:80' depends_on: - php-fpm volumes: - /app:/app - ./nginx/nginx.conf:/etc/nginx/conf.d/default.conf deploy: replicas: 1 restart_policy: condition: on-failure placement: constraints: [node.role == manager] postgres: image: postgres:9.6 ports: - '5432:5432' working_dir: /app networks: - my-test-network secrets: - postgres_db - postgres_user - postgres_pass environment: POSTGRES_DB_FILE: /run/secrets/postgres_db POSTGRES_USER_FILE: /run/secrets/postgres_user POSTGRES_PASSWORD_FILE: /run/secrets/postgres_pass volumes: - ./data/dump:/app/dump - ./data/postgresql:/var/lib/postgresql/data deploy: replicas: 1 restart_policy: condition: on-failure placement: constraints: [node.role == manager] rabbitmq: image: rabbitmq:3.7.5-management networks: - my-test-network working_dir: /app hostname: my-test-sf4-app-rabbit-mq volumes: - /app:/app ports: - '5672:5672' - '15672:15672' secrets: - rabbitmq_default_user - rabbitmq_default_pass - rabbitmq_default_vhost environment: RABBITMQ_DEFAULT_USER_FILE: /run/secrets/rabbitmq_default_user RABBITMQ_DEFAULT_PASS_FILE: /run/secrets/rabbitmq_default_pass RABBITMQ_DEFAULT_VHOST_FILE: /run/secrets/rabbitmq_default_vhost deploy: replicas: 1 restart_policy: condition: on-failure placement: constraints: [node.role == manager] elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch:6.3.0 networks: - my-test-network depends_on: - postgres environment: - discovery.type=single-node - discovery.zen.ping.unicast.hosts=elasticsearch - bootstrap.memory_lock=true - ES_JAVA_OPTS=-Xms512m -Xmx512m ports: - 9200:9200 - 9300:9300 working_dir: /app volumes: - /app:/app - ./data/elasticsearch:/usr/share/elasticsearch/data deploy: replicas: 1 restart_policy: condition: on-failure placement: constraints: [node.role == manager] jenkins: image: otezvikentiy/jenkins:0.0.2 networks: - my-test-network ports: - '8080:8080' - '50000:50000' volumes: - /app:/app - ./data/jenkins:/var/jenkins_home - /var/run/docker.sock:/var/run/docker.sock - /usr/bin/docker:/usr/bin/docker deploy: replicas: 1 restart_policy: condition: on-failure placement: constraints: [node.role == manager] volumes: elasticsearch: postgresql: jenkins: networks: my-test-network: secrets: rabbitmq_default_user: file: ./secrets/rabbitmq_default_user rabbitmq_default_pass: file: ./secrets/rabbitmq_default_pass rabbitmq_default_vhost: file: ./secrets/rabbitmq_default_vhost postgres_db: file: ./secrets/postgres_db postgres_user: file: ./secrets/postgres_user postgres_pass: file: ./secrets/postgres_pass
Wie Sie sehen können, unterscheidet sich die Einstellungsdatei für das Produkt geringfügig von der LAN-Datei. Es wurden Geheimnisse, Bereitstellungen und Netzwerke hinzugefügt.
Geheimnisse - Dateien zum Speichern von Schlüsseln. Schlüssel werden ganz einfach erstellt. Sie erstellen eine Datei mit dem Namen des Schlüssels - schreiben Sie den Wert hinein. Danach geben Sie in docker-compose.yml den Abschnitt Geheimnisse an und übertragen die gesamte Liste der Dateien mit Schlüsseln darauf.
Weitere Details .
Netzwerke - Dadurch wird ein bestimmtes internes Raster erstellt, über das Container miteinander kommunizieren. Im LAN - dies erfolgt automatisch, aber im produktiven Bereich - muss dies ein wenig manuell erfolgen. Außerdem können Sie zusätzliche Einstellungen außer den Standardeinstellungen festlegen.
Weitere Details .
Die Bereitstellung ist der Hauptunterschied zwischen LAN und Produkt / Beta.
deploy: replicas: 1 restart_policy: condition: on-failure placement: constraints: [node.role == manager]
Mindestanzahl an Kämpfern:
Replikate - Geben Sie die Anzahl der Replikate an, die Sie ausführen müssen (dies wird tatsächlich verwendet, wenn Sie über einen Cluster verfügen und den Load Balancer vom Docker aus verwenden). Sie haben beispielsweise zwei Server und haben diese über einen Docker-Schwarm verbunden. Wenn Sie hier beispielsweise die Nummer 2 angeben, wird 1 Instanz auf 1 Server und die zweite auf dem zweiten Server erstellt. Somit wird die Belastung des Servers in zwei Hälften geteilt.
restart_policy - Die Richtlinie zum automatischen "erneuten Anheben" des Containers für den Fall, dass er aus irgendeinem Grund
herunterfällt .
Platzierung - der Speicherort der Containerinstanz. Es gibt beispielsweise Zeiten, in denen alle Instanzen eines Containers auf nur einem von fünf Servern gedreht und nicht zwischen ihnen verteilt werden sollen.
Ich möchte die Dokumentation lesen!Wir haben also etwas besser verstanden, was docker-compose.yaml für LAN von der Produkt- / Beta-Version unterscheidet. Versuchen wir nun, dieses Geschäft zu führen.
Angenommen, Sie trainieren in Vagrant und haben im Stammverzeichnis des Servers bereits die konfigurierte Datei für das Produkt docker-compose.yml sudo apt-get update sudo apt-get -y upgrade sudo apt-get install -y language-pack-en-base export LC_ALL=en_US.UTF-8 export LANGUAGE=en_US.UTF-8 export LANG=en_US.UTF-8 curl -sSl https://get.docker.com/ | sh sudo usermod -aG docker ubuntu sudo apt-get install git sudo docker swarm init --advertise-addr 192.168.128.77 sudo mkdir /app sudo chmod 777 /app -R docker stack deploy -c /docker-compose.yml my-app git clone git@bitbucket.org:JohnDoe/my-app.git /app docker stack ps my-app docker stack ls docker stack services my-app
PS: Treten Sie nicht für Sudo und 777, natürlich lohnt es sich nicht, dies für die Produktivität zu tun. Dies ist nur für die Lerngeschwindigkeit.Wir sind also am meisten an den Zeilen interessiert, die mit dem Docker verbunden sind.Zuerst initialisieren wir den „Schwarm“ (Docker-Schwarm).Dann erstellen wir die für die Arbeit notwendigen Verzeichnisse.Laden Sie die Rübe mit unserem SF4-Code im Verzeichnis / app herunter.Danach gibt es drei Befehle: ps, ls und services.Jeder von ihnen ist auf seine Weise nützlich. Ich verwende ps am häufigsten, da es den Status der Container und einen Teil des Fehlers anzeigt, falls vorhanden.Angenommen, die Container sind gestiegen, aber einige von ihnen stürzen ständig mit einem Fehler ab, und im Docker-Stack ps my-app werden einige Neustarts angezeigt. Um den Grund für den Sturz zu erkennen, müssen Sie den Docker-Container ps -a ausführen. Dort wird ein Container angezeigt, der ständig fällt. Es wird viele Instanzen desselben Containers geben, zum Beispiel my-app_php-fpm.1. * Ein heftiger Hash *.Dementsprechend führen Sie jetzt, wenn Sie den Namen des Containers kennen, Docker-Protokolle my-app_php-fpm.1 aus. * Etwas heftiger Hash * und sehen Sie sich die Protokolle an. Korrigieren Sie den Fehler und starten Sie ALLES neu. Um alle Container zu knallen, können Sie dies tun: docker stack rm my-app
Danach haben Sie einen sauberen Schwarm ohne Behälter. Beheben Sie den Fehler - und stellen Sie den Docker-Stack erneut -c docker-compose.yml my-app bereit.