WORKDIR is also valid at build time, thus it makes sense to move it as towards
the top as possible.
This will come in hand in the next commits, when we will introduce support for
installing plugins while building the container.
Source: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#workdir
[...] you should use WORKDIR instead of proliferating instructions like
RUN cd … && do-something,
which are hard to read, troubleshoot, and maintain.
Supervision/management should not be done from inside the container, but
externally, by container managers.
The container now simply runs node on server.js.
The logs are now readable from docker logs <container_name>.
All the configuration values can be read from environment variables using the
syntax "${ENV_VAR_NAME}".
This is useful, for example, when running in a Docker container.
EXAMPLE:
"port": "${PORT}"
"minify": "${MINIFY}"
"skinName": "${SKIN_NAME}"
Would read the configuration values for those items from the environment
variables PORT, MINIFY and SKIN_NAME.
REMARKS:
Please note that a variable substitution always needs to be quoted.
"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.
Resolves#3543
This is a super simple start.
At minimum, configuration via environment variables (see #3543) needs to be
integrated in Etherpad to make this user-friendly.
Resolves#3524.
muxator