Launcher-Neuaufbau schlägt mit Docker 19.03.0 aufgrund des Docker-Netzwerkparameters fehl

Unterstützung
1

Mit dem Rollout von Docker-Version 19.03.0 startet der Discourse-Launcher die Instanz nach einem Rebuild nicht mehr und meldet folgende Fehlermeldung:

/usr/bin/docker: --network ist keine gültige MAC-Adresse.
Siehe '/usr/bin/docker run --help'.

Dies ist der ausgeführte Befehl (einige Einträge aus Sicherheitsgründen geändert):

+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=2 -e UNICORN_SIDEKIQS=1 -e RUBY_GLOBAL_METHOD_CACHE_SIZE=131072 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET=/var/run/postgresql -e DISCOURSE_DB_HOST= -e DISCOURSE_DB_PORT= -e DISCOURSE_HOSTNAME=discourse.mydomain.com -e VIRTUAL_HOST=discourse.mydomain.com -e DISCOURSE_DEVELOPER_EMAILS=admin@mydomain.com -e DISCOURSE_SMTP_ADDRESS=mail.mydomain.com -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME=discourse@mydomain.com -e DISCOURSE_SMTP_PASSWORD=MySuperDuperPass -h vps-discourse -e DOCKER_HOST_IP=172.17.0.1 --name discourse -t --expose 80 --mac-address --network reverse-proxy --network reverse-proxy local_discourse/discourse /sbin/boot
/usr/bin/docker: --network ist keine gültige MAC-Adresse.
Siehe '/usr/bin/docker run --help'.

Ich nutze dies hinter einem Reverse-Proxy (der im Netzwerk namens reverse-proxy läuft). Es hat immer funktioniert, bis heute. Es scheint, als würde ein Wert für die MAC-Adresse erwartet, der nicht bereitgestellt wird.

2

Mal sehen..

root@endoffice-a:/var/discourse# docker --version
Docker version 19.03.0, build aeac949

Ich habe gerade einen ./launcher rebuild app ausgeführt, der erfolgreich war:

+ /usr/bin/docker run --shm-size=512m -d --restart=always -e LANG=en_US.UTF-8 -e RAILS_ENV=production -e UNICORN_WORKERS=8 -e UNICORN_SIDEKIQS=1 -e RUBY_GLOBAL_METHOD_CACHE_SIZE=131072 -e RUBY_GC_HEAP_GROWTH_MAX_SLOTS=40000 -e RUBY_GC_HEAP_INIT_SLOTS=400000 -e RUBY_GC_HEAP_OLDOBJECT_LIMIT_FACTOR=1.5 -e DISCOURSE_DB_SOCKET=/var/run/postgresql -e DISCOURSE_DB_HOST= -e DISCOURSE_DB_PORT= -e LETSENCRYPT_DIR=/shared/letsencrypt -e UNICORN_SIDEKIQ_MAX_RSS=1000 -e DISCOURSE_HOSTNAME=discourse.codinghorror.com -e DISCOURSE_DEVELOPER_EMAILS=jatwood@codinghorror.com -e DISCOURSE_SMTP_ADDRESS=smtp.mailgun.org -e DISCOURSE_SMTP_PORT=587 -e DISCOURSE_SMTP_USER_NAME={redacted} -e DISCOURSE_SMTP_PASSWORD={redacted} -e LETSENCRYPT_ACCOUNT_EMAIL={redacted} -e DISCOURSE_CDN_URL=https://discourse-cdn.codinghorror.com -h endoffice-a-app -e DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared -v /var/discourse/shared/standalone/log/var-log:/var/log --mac-address 02:72:e3:65:d5:32 local_discourse/app /sbin/boot

Beachten Sie, dass --mac-address angegeben ist und einen Wert hat, aber die Zeile mit --network ist spezifisch für Ihre Einrichtung und weicht von einer standardmäßigen Discourse-Standalone-Installation ab.

3

@codinghorror Das ist alles gut und schön, aber wenn standardmäßige Standalone-Installationen die einzige vorgesehene Betriebsart für Discourse sind, warum wird dann die Unterstützung für die yml-Containerkonfiguration in ./containers bereitgestellt und werden Beispiele dafür in ./samples enthalten? Die von mir verwendete Datei ist vollständig mit Anweisungen zum Betrieb kommentiert, speziell in diesem Bereich:

# any extra arguments for Docker?
# docker_args:

Das Einzige, was ich verwende, ist:

docker_args: "--network reverse-proxy"

Was wiederum seit einem Jahr einwandfrei funktioniert. Offensichtlich hat sich also etwas geändert. Bitte verstehen Sie, dass ich nicht konfrontativ sein möchte (das wäre ziemlich albern, da ich um Hilfe bitte), aber ich möchte durchaus betonen, dass ich Optionen verwende, die über die Discourse-Beispiele bereitgestellt werden.

Vielleicht könnte es mir helfen, wenn ich verstünde, wie diese MAC-Adresse generiert wird, um auf ein Problem mit einer Umgebungsänderung hinzuweisen – das ist meine Hoffnung.

Ich sehe dies im Launcher:

     if [ -z "$SKIP_MAC_ADDRESS" ] ; then
      mac_address="--mac-address $($docker_path run $user_args -i --rm -a stdout -a stderr $image /bin/sh -c "echo $hostname | md5sum | sed 's/^\(..\)\(..\)\(..\)\(..\)\(..\).*$/02:\1:\2:\3:\4:\5/'")"
     fi

Ich werde das analysieren und sehen, ob ich herausfinden kann, was los ist.

UPDATE: Und beim Betrachten dessen sehe ich, dass ich --skip-mac-address verwenden kann. Dadurch startet meine Instanz problemlos, also scheint der Prozess, der die MAC-Adresse ermittelt, das Problem zu sein.

4

Zusammenfassend lässt sich sagen: Der Build-Vorgang schlägt unter allen Umständen nicht fehl, aber beim Build-Vorgang (./launcher rebuild myinstance) schlägt der letzte Schritt des Startens des Containers fehl, da die MAC-Adresse aus irgendeinem Grund nicht gesetzt ist.

Allerdings kann ich danach einfach ./launcher start myinstance ausführen, und dann startet er problemlos, und die MAC-Adresse ist ebenfalls vorhanden. Seltsam, das ist alles.

5

Ich habe das gleiche Problem.
@codinghorror Hier sind die Schritte zur Reproduktion und ein Hinweis zur Behebung dieses Regression

Schritte zur Reproduktion:

  1. In der Container-Konfiguration (App) setzen:
    docker_args: "--network reverse-proxy"
  2. Neu aufbauen
    ./launcher rebuild app
  3. Fehler sehen
    /usr/bin/docker: --network ist keine gültige MAC-Adresse

Dies ist ein Fehler, der durch den Commit bfc79e7 eingeführt wurde (GitHub - discourse/discourse_docker: A Docker image for Discourse · GitHub)
merge_user_args wird von set_template_info aufgerufen, aber set_template_info wird beim Rebuild zweimal aufgerufen (run_run und run_bootstrap)
Somit haben wir statt user_args gleich $user_args $docker_args stattdessen $user_args $docker_args $docker_args.

Docker erlaubt es nicht, dasselbe Netzwerk mehrfach zu konfigurieren.
docker: Netzwerk "reverse-proxy" wird mehrfach angegeben

Vielen Dank, diesen Commit zurückzunehmen oder merge_user_args idempotent zu machen.

6

Danke für die Detektivarbeit! :male_detective: @saj, es sieht so aus, als hättest du diesen Commit zusammen mit @deargle mitunterschrieben.

8

Hier ist ein Patch –

Nach Anwendung dieses Patches und Setzen des Schlüssels docker_args in der Container-Definition sieht der finale Argumentvektor für docker run ungefähr so aus:

/usr/bin/docker run --shm-size=512m -d --restart=always -e ... -h saj-launcher-testing-app -e DOCKER_HOST_IP=172.17.0.1 --name app -t -p 80:80 -p 443:443 -v /var/discourse/shared/standalone:/shared -v /var/discourse/shared/standalone/log/var-log:/var/log --mac-address 02:07:fa:c6:c4:82 --network foonet local_discourse/app /sbin/boot
10

Cool! Also, gut, dass ich das nicht geträumt habe. Danke euch, dass ihr euch darum kümmert.