46 lines
1.5 KiB
Markdown
46 lines
1.5 KiB
Markdown
# Containerisation
|
|
|
|
## Reverse proxy
|
|
|
|
The proxy receives all connections on TCP ports 80 and 443 and routes the
|
|
requests to services listening on high-numbered ports.
|
|
|
|
### Adding new services
|
|
|
|
New services are registered with the reverse proxy by adding a server
|
|
configuration file.
|
|
|
|
1. Add the configuration file.
|
|
2. Restart the reverse proxy.
|
|
|
|
### TLS
|
|
|
|
The proxy has a Let's Encrypt TLS certificate for each service that uses a
|
|
public domain name.
|
|
|
|
The proxy automatically renews the certificates using an HTTP-01 challenge:
|
|
Let's Encrypt requests a text file from the server to prove that the server is
|
|
controlled by the domain owner.
|
|
|
|
The proxy generates a separate certificate for each domain; certificates are
|
|
managed separately for each service.
|
|
|
|
## Systemd services
|
|
|
|
Each service is registered as a Systemd service: Systemd starts the containers
|
|
when the server boots; systemd auto restarts the containers when they stop.
|
|
|
|
Systemd also provides a unified interface for disabling/enabling services. The
|
|
exact implementation details of the service's containers is not important: they
|
|
can be standalone docker images or docker compose services.
|
|
|
|
## Standard service containerisation pattern
|
|
|
|
Each service will use docker compose to run its containers, even if the service
|
|
only uses a single container. This simplifies maintenance because each service
|
|
can use a similar docker and systemd setup.
|
|
|
|
Services can break from this pattern for a couple of reasons:
|
|
|
|
1. docker compose setup is too difficult.
|
|
1. The service needs to run directly on the host.
|