Meliurwen
892c281b4a
|
4 years ago | |
---|---|---|
.gitlab/media | 4 years ago | |
nginx | 4 years ago | |
.env.example | 4 years ago | |
.gitignore | 4 years ago | |
README.md | 4 years ago | |
docker-compose.yml | 4 years ago | |
funkwhale.env.example | 4 years ago | |
nginx.env.example | 4 years ago | |
paths.env.example | 4 years ago | |
postgres.env.example | 4 years ago |
README.md
Funkwhale container stack
This is a rewriting of the official Funkwhale multi-container installation.
Why
The official docker-compose works, but is written in some very questionable way; creating serious issues in security, portability, modularity, readability and maintenability of the entire stack. The installation is also not automated, but requires extra steps (excluding configuration that doesn't count) to initialize for the first time the instance.
What changed
There has been a lot of changes, I will list the most notable ones:
Network
- Before: (see the appendix)
- the containers were all under the same network which gave them internet access;
- the
api
andnginx
(the reverse-proxy) services were exposing to the public (using theport
directive), respectively the5000/tcp
and80/tcp
ports; - the ports of
postgres
andredis
were not documented (noexpose
directive used).
- Now: (see the appendix)
- There are three distinct networks with precise purposes:
- An internal network (no Internet access) containing all the services;
- A network with Internet access with only the services that really need it, namely:
api
andceleryworker
; - An optional external network to hook the
nginx
service only (in case you have a main reverse-proxy on your server).
- the
api
andnginx
(the reverse-proxy) services no longer expose their ports to the public, they are only documented with theexpose
directive; - the ports of
postgres
andredis
services are now documented with theexpose
directive.
- There are three distinct networks with precise purposes:
Environment variables
Info: read this and this on the official Docker docs to understand the difference between
.env
file and env files imported withenv_file
.
- Before:
- All the environment variables for all services were mixed together inside the same
*.env
file (.env
); - The
.env
file (which is automatically loaded by Docker Compose to be used within the.yml
file), is also directly injected in all serivices with theenv_file
directive, exposing information to services that doesn't (and shouldn't) need it.
- All the environment variables for all services were mixed together inside the same
- Now:
- The environment variables are now separated in different files depending on the service or set of services that does need them; the
.env
file now has only variables concerning the configuration at the stack level, not service, except for theFUNKWHALE_HOSTNAME
variable which is passed inside the containers via theenvironment
directive. - The
env_file
is now used only when needed and import*.env
files containing variables only needed for the target service.
- The environment variables are now separated in different files depending on the service or set of services that does need them; the
Other
- Configurable paths for the volumes mounting point inside the containers has been removed, it's something that has no sense to exist and unnecessarily complicate things.
- Has been added the possibility to configure the
restart
andcontainer_name
directive on all the containers. - Has been added the possibility to configure the tag on all services and image on some (
nginx
,postgres
,redis
). - In the
funkwhale.template
has been removed all the unnecessary variables and replaced with static paths which reflects the static volume mountpoints I set for the service. - The
funkwhale_proxy.conf
andfunkwhale.template
has been moved to a dedicated subfolder callednginx
. - In case the system administrator has intention to hook the
nginx
service to the network of its main reverse-proxy which happens to have a companion (for example docker-gen) I've set some variables with dummy values already in thenginx.env
file. - The directives in the
docker-compose.yml
file now are no longer sorted randomly; the order is the same for all and follows a criteria that (arguably) makes more sense. - Except for
DJANGO_SECRET_KEY
andFUNKWHALE_HOSTNAME
which are mandatory variables to manually set, all the optional variables are left empty in the*.var
files by default and has a correspondent default value defined in thedocker-compose.yml
file (except forfunkwhale.env
). postgres
service image tag has been upgraded from11
to12.4
andredis
from to5
to6
.
What Didn't Change
- The overall stack structure remained the same, with the same container images.
- The name of the services (but they should be changed to a more generic ones,
like:
web
,api
,db
,cache
, etc...). - The extra manual steps necessary to initialize for the first time the app
- The extra manual steps necessary to partially initialize the database in case to upgrade to a new version (tables or columns has been added/removed)
- The extra manual steps in case of bump to a new version of the service that is not backward compatible (for example posgres likes to break compatibility at every major release).
How to Install
Configuration
These are the minimum number of variables you need to set in order to get the whole stack working.
- Remove the
.example
extension from all files (or copy new ones without it) - Set the
DJANGO_SECRET_KEY
variable infunkwhale.env
- Set the
FUNKWHALE_HOSTNAME
variable in.env
- (only if using a reverse proxy with docker-companion) set the dedicated variables in
nginx.env
Initialization (only first time)
Initialize the database:
docker-compose run --rm api python manage.py migrate
Create the superuser of the instance:
docker-compose run --rm api python manage.py createsuperuser
Run
Launch the whole stack:
docker-compose build --pull && docker-compose up -d
Resources
- FW GitLab istance - docker-compose.yml
- FW Docs - Docker installation
- FW Docs - Architecture
- FW Docs - Instance configuration