Gibt es noch irgendwelche nativen oder allgemein akzeptierten Ansätze zur Verwendung von Umgebungsvariablen, um das Verhalten von Docker zu kontrollieren, d. h. auf eine Art und Weise?
Die einzige sprachunabhängige Methode, die ich gesehen habe, ist, den Befehl docker run mit den Variablen -e zu verschmutzen. Die wartungsfreundlichste Lösung, die ich gesehen habe, ist die Verwendung einer Kombination aus cat und sed, um die CLI-Parameter mithilfe einer .env-Datei zu generieren: Ссылка
Derzeit verwenden wir Vagrant for dev, einen von CI / CD gehosteten Provider für Test und Deploy sowie AWS Elastic Beanstalk als Inszenierungs- und Produktions-PAAS. Unsere App verfügt über mehr als 100 konfigurierbare Parameter, von denen die meisten auf Standardwerte festgelegt sind. In jeder Umgebung müssen jedoch noch etwa 10-20 solcher Parameter angepasst werden. Es scheint einfach zu hacky zu sein, um Docker mit einer riesigen Liste von Kommandozeilen-Variablen wie diesem laufen zu lassen.
Außerdem können Sie keine Variablen aus dem Docker-Host übernehmen (wie die vorinstallierten Redis- oder Postgres-Anmeldedaten des CI-Providers), ohne einen weiteren Hack.
Gibt es eine Lösung, die ich nicht gefunden habe? Oder ist das ein fehlendes Stück für Docker? Oder ist das irgendwie philosophisch gegen die Docker-Philosophie?
Docker 0.10.0 und neuer (8. April 2014) akzeptiert docker run --env-file <filename> , wodurch Sie die Arbeitsumgebung von docker mit .env -ähnlichen Dateien versorgen können.
Darüber hinaus können Sie dakers weiter interagieren lassen: --volumes-from kann alle Volumes aus dem referenzierten Container laden, und --link lässt den Container die Details der exponierten Ports des referenzierten Containers kennen.
Obwohl die Docker-Ausführungsreferenz im Moment etwas schwach ist, finden Sie alle Details im CLI Der Abschnitt für die Referenz sowie Containerverknüpfungsreferenz .
Ab was von dem Container gestartet werden soll. Normalerweise empfehle ich, ein Shell-Skript zu starten, das Standardumgebungsvariablen (in den Zeilen : ${ENV:=default_value} ) setzt, sie exportiert und dann exec s eine einzelne ausführbare Datei. Diese ausführbare Datei kann die gewünschte Anwendung im Vordergrund oder eine init-Ersetzung wie runit oder supervisord sein.
Ich würde nicht empfehlen, sshd in Ihrem Andockfenster auszuführen, wenn es nicht Teil des Systems ist (z. B. sollte ein Container für gitlab sshd enthalten, da es git-Repo-Zugriff über ssh bereitstellt). Für Wartungs- oder Debugging-Zwecke empfehle ich stattdessen nsenter .
Tags und Links docker environment-variables 12factor