Etherpad-lite: Konfiguration: Umgebungsvariablen unterstützen

Es gibt bereits einige inoffizielle Docker-Images, die dies unterstützen. Vielleicht einen Blick wert?

Wichtig wäre, das API-Schlüsselgeheimnis über eine ENV-Variable setzen zu können, damit man beim erneuten Deployment des Docker-Images nicht alle externen Dienste manuell auf einen neuen zufälligen API-Schlüssel ändern muss. Vielen Dank!

Implementiert. Der PR ist #3572.

Bitte beachten Sie, dass es eine kleine Etherpad-spezifische Bemerkung geben wird, da es sich um eine JSON-Datei zur Konfiguration handelt.
Auch beim Ersetzen einer Variablen, deren Wert ein boolescher Wert oder eine Zahl wäre, müssen Anführungszeichen verwendet werden. Etherpad kümmert sich dann um die Rückkonvertierung des Konfigurationsparameters vom String in den richtigen Typ.

Die Dokumentation befindet sich in https://github.com/ether/etherpad-lite/blob/3b6b12e8482bb641252c2aa8fff225d61cd5225b/settings.json.template.

   "port":   9001,          <-- Literal values. When not using substitution,
   "minify": false              only strings must be quoted: booleans and
   "skin":   "colibris"         numbers must not.

   "port":   ${PORT}        <-- ERROR: this is not valid json
   "minify": ${MINIFY}
   "skin":   ${SKIN_NAME}

   "port":   "${PORT}"      <-- CORRECT: if you want to use a variable
   "minify": "${MINIFY}"        substitution, put quotes around its name,
   "skin":   "${SKIN_NAME}"     even if the required value is a number or a
                                boolean.
                                Etherpad will take care of rewriting it to
                                the proper type if necessary.

Das sieht schon toll aus.

Jede Möglichkeit, auch die Einstellung der APIKEY.txt zu implementieren (wie hier erklärt: https://github.com/ether/etherpad-lite/wiki/HTTP-API ), ähnlich wie bei diesem Docker-Image: https://github .com/tvelocity/dockerfiles/tree/master/etherpad-lite ?

Oder gibt es eine andere Möglichkeit (mit einem Volume?), um zu verhindern, dass sich der API-Schlüssel ändert, wenn das Docker-Image neu erstellt/aktualisiert wird?

Mein Anwendungsfall: Ich habe Etherpad in Dokuwiki und Nextcloud integriert, und beide erfordern das Setzen des API-Schlüssels, und ich müsste ihn idealerweise nicht jedes Mal manuell ändern, wenn das Docker-Image aktualisiert wird.

Danke vielmals!

Das ist fantastisch! Danke für die Implementierung @muxator

Gibt es eine Möglichkeit, dies bald in einer markierten Version zu veröffentlichen, ohne auf andere Probleme zu warten, die für 1.8 vorgesehen sind?

Ich würde dies gerne von einem etherpad/etherpad Docker-Image verwenden können, ohne an das viel lockerere developer Tag anzuheften.

Danke noch einmal!

@muxator Hier ist etwas, das ich gemacht habe, um etherpad-lite auf Kubernetes auszuführen. https://github.com/gobengo/etherpad-lite

Die Konfiguration der Datenbankanmeldeinformationen ist in diesem Kontext am besten mit Umgebungsvariablen ( aus einem k8s-Geheimnis ) geeignet, für die diese Funktion erforderlich ist.

Da es aber noch keine Version mit dieser Funktion gibt, musste ich das 'latest'-Tag des Docker-Images verwenden .

Teilen Sie einfach den Anwendungsfall. Nochmals vielen Dank für das Hinzufügen. Freuen Sie sich darauf, es in 1.8 . zu haben

Hallo @gobengo , ich bin froh, dass dies eine neue Bereitstellungsmöglichkeit ermöglicht hat.

Eine grobe Aufschlüsselung der verbleibenden Probleme für den 1,8-Meilenstein sieht wie folgt aus:

1. Es gibt noch zwei verbleibende Sicherheitsprobleme, die vor der Veröffentlichung von 1.8
   1.a #3598, ein Problem mit der tar-Bibliothek in einer transitiven Abhängigkeit von npm
   1.b die clean-css Bibliothek erfordert einen größeren Versions-Bump, und dies erfordert einige Arbeit (siehe ~https://github.com/ether/etherpad-lite/pull/3597#issuecomment-483851384~ #3616)
2. die asynchrone Migration brachte viele wichtige Änderungen mit sich, aber es gibt noch zwei Probleme, die angegangen werden müssen (siehe #3568 und #3566).
3. Es gibt einige Feature-Arbeiten, die wahrscheinlich auf eine spätere Version verschoben werden könnten

Wenn Sie die Möglichkeit haben, an 1.a , 1.b oder 2 zu arbeiten , kann dies sehr hilfreich sein.
Vielen Dank!

Der Code für #3568 ist fertig - es erfordert meistens eine Änderung der Dokumentation.

Ich kann mir #3566 noch einmal anschauen. AFAIK der von mir vorgeschlagene Patch funktioniert, aber ich glaube, ich kann ihn so vereinfachen, dass er nicht die Verwendung von eval erfordert.