Alexander Dahl
a5e773d9b6
Although cc88073a79 ("Fix signal handling") fixed the signal handling
and signals don't end up in `entrypoint.sh` anymore, there's still no
clean graceful shutdown. The reason is runuser. It runs as PID 1 and
prosody only runs as child process. A SIGTERM sent to runuser lets
runuser forward SIGTERM to the child process. However it does not wait,
but send SIGKILL right after it. (Confirmed by looking at runuser source
code in util-linux.)
The output on `docker stop [prosodycontainer]` is therefore:
Session terminated, killing shell...mod_posix warn Received SIGTERM
portmanager info Deactivated service 'c2s'
...killed.
The additional messages in between prosody log output come from runuser.
This is obviously no graceful shutdown.
Because prosody fordibs running as uid 0 (root) we have to run it as
unpriviledged user. The docker best practices recommend to use *gosu*
and gosu lists some alternatives. Instead of installing gosu to the
image, we use *setpriv* from the already installed util-linux now. The
version in Debian buster, on which the prosody image is based currently,
is recent enough to already contain setpriv.
After that, prosody itself runs with PID 1, but as unpriviledged user
now, and the output of `docker stop` looks like this:
mod_posix warn Received SIGTERM
portmanager info Deactivated service 'c2s'
general info Shutting down...
general info Shutdown status: Cleaning up
general info Shutdown complete
Link: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#entrypoint
Signed-off-by: Alexander Dahl <post@lespocky.de>
Docker build scripts for Prosody build server
This is the Prosody Docker image building repository. It is used by our build server to build and publish Docker images for stable releases and nightly builds.
Note: Using this Dockerfile outside of our build server is not a supported use-case. There are many alternative Dockerfiles for Prosody available which can be used for this:
Published images
For images please see here: Prosody on Docker.
Running
It works by copying in a recently built deb file and running the install on the system.
Docker images are built off an Debian 10 (buster) base.
docker run -d --name prosody -p 5222:5222 prosody/prosody
A user can be created by using environment variables LOCAL, DOMAIN, and PASSWORD. This performs the following action on startup:
prosodyctl register local domain password
Any error from this script is ignored. Prosody will not check the user exists before running the command (i.e. existing users will be overwritten). It is expected that mod_admin_adhoc will then be in place for managing users (and the server).
Ports
The image exposes the following ports to the docker host:
- 80: HTTP port
- 5222: c2s port
- 5269: s2s port
- 5347: XMPP component port
- 5280: BOSH / websocket port
- 5281: Secure BOSH / websocket port
Note: These default ports can be changed in your configuration file. Therefore if you change these ports will not be exposed.
Volumes
Volumes can be mounted at the following locations for adding in files:
- /etc/prosody:
- Prosody configuration file(s)
- SSL certificates
- /var/log/prosody:
- Log files for prosody - if not mounted these will be stored on the system
- Note: This location can be changed in the configuration, update to match
- Also note: The log directory on the host (/logs/prosody in the example below) must be writeable by the prosody user
- /usr/lib/prosody-modules (suggested):
- Location for including additional modules
- Note: This needs to be included in your config file, see http://prosody.im/doc/installing_modules#paths
Example
docker run -d \
-p 5222:5222 \
-p 5269:5269 \
-p localhost:5347:5347 \
-e LOCAL=romeo \
-e DOMAIN=shakespeare.lit \
-e PASSWORD=juliet4ever \
-v /data/prosody/configuration:/etc/prosody \
-v /logs/prosody:/var/log/prosody \
-v /data/prosody/modules:/usr/lib/prosody-modules \
prosody/prosody:0.9
Building
Use the build-docker.sh script as follows:
./build-docker.sh /path/to/built-image.deb version_tag [, ...version_tag2, ...]
Where argument 1 is a pointer to the build deb file that you'd like to make an image from and 'version_tag' is the tag you'd like to push to the Docker registry with.
You can specify multiple tags by adding additional tag names to the end of the command. This is useful where a for example release 0.10.4 is made which also consitutes 'latest', '0.10-nightly', '0.10.4', '0.10' images.
After running the script will clean up any images generated (but not the base images - for efficiency purposes).