Verwenden von Supervisor im Andockfenster

Ich bin nicht gefragt, über den Einsatz der Betreuer mit dockers, sondern will nur meinen Verständnis überprüft.

Ich verstehe, dass docker läuft ein einzelner Prozess, der, wenn er ausgeführt wird. Auch, supervisor verwendet, wenn wir brauchen, um mehrere Prozess innerhalb des Containers.

Habe ich gesehen, dass mehrere Beispiele, wo ein container ist, angefangen von der Basis-image-und mehrere Dienst installiert sind und der Behälter verpflichtet sich zu einem neuen Bild, alle ohne supervisor.

So, meine grundlegenden Zweifel war, was ist der Unterschied zwischen beiden Ansätzen.

Mein Verständnis ist, dass, wenn docker-container beendet wird, sendet es ein kill-signal an den Prozess mit PID 1 PID 1 befasst sich mit der Kind-Prozess und Stoppt alle Kind-das ist genau das, was getan wird, von Vorgesetzten, während wir installieren können mehrere Prozess ohne supervisor-nur ein Prozess kann ausgeführt werden, wenn docker run ausgestellt ist und wenn der container gestoppt wird nur die PID 1 gesendet werden Signale und andere laufende Prozess wird nicht gestoppt werden würde.

Bestätigen Sie bitte, wie viel mein Verständnis über die Verwendung von supervisord korrekt ist.

Dank

InformationsquelleAutor der Frage user3275095 | 2015-10-14

docker supervisord

46

während wir installieren können mehrere Prozess ohne Betreuer, nur ein Prozess kann ausgeführt werden, wenn docker run ausgegeben, und wenn der container gestoppt wird nur die PID 1 gesendet werden Signale und andere laufende Prozess wird nicht gestoppt werden würde.

Ja, obwohl es hängt davon ab, wie Sie Ihre Haupt-Prozess läuft (im Vordergrund oder hintergrund), und wie es erfasst die child-Prozesse.

Ist das, was in der Rubrik "Trapping-Signale in Docker Container"

docker stop Stoppt einen Laufenden container, indem Sie ihn SIGTERM signal, lassen Sie die Haupt-Prozess, und nach einer übergangszeit verwendet SIGKILL um die Anwendung zu beenden.

Das signal gesendet, um den Behälter erfolgt durch den Haupt-Prozess, der ausgeführt wird (PID 1).

Wenn die Anwendung im Vordergrund, d.h. die Anwendung ist der wichtigste Prozess in einem Behälter (PID1), könnte es handle Signale direkt.

Aber:

Den Prozess signalisiert werden, könnte der hintergrund und Sie können nicht senden Signale direkt. In diesem Fall eine Lösung ist das einrichten einer shell-script als entrypoint und orchestrieren die gesamte Signalverarbeitung, die im Skript.

Das Problem wird noch detailliert in "Andockfenster und die PID 1 zombie Sensenmann problem"

Unix ist so konzipiert, dass die übergeordneten Prozesse müssen explizit "warten" für das Kind", Beendigung des Prozesses, um zu sammeln, seine exit-status. Der zombie-Prozess bestehen, bis der parent-Prozess durchgeführt hat diese Aktion, mit der waitpid() Familie von Systemcalls.

Die Aktion der Aufruf von waitpid() auf einen Kindprozess, um die Beseitigung der zombie, nennt sich "ernten".

Den init Prozess-PID-1-hat eine Besondere Aufgabe. Seine Aufgabe ist es, "anzunehmen" verwaiste Kindprozesse.

Das Betriebssystem erwartet der init-Prozess zu ernten adoptierte Kinder auch.

Problem mit Docker:

Sehen wir, dass eine Menge Leute führen nur ein Prozess, der in Ihrem container, und Sie denken, dass, wenn Sie laufen dieses einzigen Prozesses, Sie sind fertig.

Aber wahrscheinlich ist dieser Prozess nicht geschrieben, Verhalten sich wie ein richtiges init-Prozess.

Das heißt, anstelle von richtig ernten verabschiedet Prozesse, es wahrscheinlich erwarten, dass ein anderes init Prozess, diesen job zu tun, und das zu Recht.

Über ein Bild wie phusion/baseimage-docker Hilfe die Verwaltung einer (oder mehreren) Prozess(en), während eine Haupt-init-konform.

Es nutzt runit statt supervisordfür die multi-process-management:

Runit ist es nicht zu lösen, der erntet problem. Vielmehr ist es zur Unterstützung mehrerer Prozesse. Mehrere Prozesse sind aufgefordert, für die Sicherheit (durch Prozess-und Benutzer-isolation).

Runit verbraucht weniger Speicher als Supervisord weil Runit ist in C geschrieben und Supervisord in Python.

Und in einigen Anwendungsfällen, Prozess startet im container sind vorzugsweise über die gesamte container neu gestartet.

Diesem Bild enthält eine my_init - Skript die kümmert sich um die "Ernte" Problem.

In baseimage-docker, empfehlen wir die Ausführung mehrerer Prozesse in einem einzigen container. Nicht unbedingt mehrere Dienste wenn.

Eine logische service kann aus mehreren OS-Prozesse, und wir bieten die Einrichtungen, um einfach tun.

InformationsquelleAutor der Antwort VonC
13

Update Sept 2016 für docker 1.12 (Q4 2016/Q1 2017)

Arnaud Porterie nur twitted:

[?] Nur zusammengeführt: mit docker run --initRick Grimes kümmert sich um alle Ihre zombies.

(commit eabae09)

Sehen PR-26061: "Hinzufügen init-Prozess für den zombie-Kampf-und Signalverarbeitung" (und PR-26736)

Dieser fügt ein kleines C-binary für den Kampf gegen zombies. Es ist montiert unter
/dev/init und ist vorangestellt, um die args vom Benutzer angegeben. Sie
aktivieren Sie es mittels daemon-flag, dockerd --init, wie es ist, deaktivieren Sie, indem
Standard für die Rückwärtskompatibilität mit vorhandenen.

Können Sie auch außer Kraft setzen der daemon-option oder geben Sie diese auf eine pro
container-basis mit docker run --init=true|false.

Sie können dies testen, indem Sie einen Prozess ausführen, wie dieses als pid 1 in einem
container und siehe den extra zombie, der sich in die Behälter, wie Sie es
ausgeführt wird.
```
int main(int argc, char ** argv) {
    pid_t pid = fork();
    if (pid == 0) {
        pid = fork();
        if (pid == 0) {
            exit(0);
        }
        sleep(3);
        exit(0);
    }
    printf("got pid %d and exited\n", pid);
    sleep(20);
}
```
Den docker-daemon hat nun die Möglichkeit,
```
--init
```
Ausführen eines init-innen Container, um Signale weiterleiten und ernten Prozesse

InformationsquelleAutor der Antwort VonC

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.