Run systemd inside development docker container

fgrsnau commented 8 years ago

Hades will be deployed as a bunch of systemd units to the production systems and the following commits prepare the dev environment to behave similar.

A systemd system manager is spawned and all the unnecessary units are removed.

Additionally, the dev environment creates a separate 'hades' database. Instead of using the mysql_fdw the foreign data is fetched from the local database using postgres_fdw – making the dev environment completely independent.

$ sudo -g docker docker build -t hades-base -f base.dockerfile .
[...]
$ sudo -g docker docker build -t hades-dev -f development.dockerfile .
[...]
$ sudo -g docker docker run -t --privileged --name hades hades-dev
$ sudo -g docker docker exec -ti hades bash -l
root@878e5eba299e:/# systemctl
UNIT                               LOAD   ACTIVE SUB     DESCRIPTION
-.mount                            loaded active mounted /
dev-mqueue.mount                   loaded active mounted POSIX Message Queue File System
etc-hostname.mount                 loaded active mounted /etc/hostname
etc-hosts.mount                    loaded active mounted /etc/hosts
etc-resolv.conf.mount              loaded active mounted /etc/resolv.conf
hades-agent.service                loaded active running Hades agent (Celery Worker)
hades-auth-dhcp.service            loaded active running Hades DHCP service for authenticated use
hades-auth-dns.service             loaded active running Hades DNS service for authenticated user
hades-database.service             loaded active running Hades database service (PostgreSQL)
hades-http.service                 loaded active running Hades http server (nginx)
hades-networking.service           loaded active exited  Hades networking
hades-portal.service               loaded active running Hades portal (Flask app on uWSGI)
hades-radius.service               loaded active running Hades RADIUS service (FreeRADIUS)
hades-unauth-dns.service           loaded active running Hades DNS service for unauthenticated us
hades-vrrp.service                 loaded active running Hades VRRP service (keepalived)
rc-local.service                   loaded active exited  /etc/rc.local Compatibility
systemd-journald.service           loaded active running Journal Service
systemd-tmpfiles-setup-dev.service loaded active exited  Create Static Device Nodes in /dev
systemd-tmpfiles-setup.service     loaded active exited  Create Volatile Files and Directories
-.slice                            loaded active active  Root Slice
system.slice                       loaded active active  System Slice
systemd-journald-dev-log.socket    loaded active running Journal Socket (/dev/log)
systemd-journald.socket            loaded active running Journal Socket
basic.target                       loaded active active  Basic System
graphical.target                   loaded active active  Graphical Interface
local-fs.target                    loaded active active  Local File Systems
multi-user.target                  loaded active active  Multi-User System
paths.target                       loaded active active  Paths
slices.target                      loaded active active  Slices
sockets.target                     loaded active active  Sockets
swap.target                        loaded active active  Swap
sysinit.target                     loaded active active  System Initialization
timers.target                      loaded active active  Timers
systemd-tmpfiles-clean.timer       loaded active waiting Daily Cleanup of Temporary Directories

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

34 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files

Currently there is a small problem with the database: The first invokation somehow fails. Nevertheless, the database is running stable:

root@878e5eba299e:/# journalctl --unit=hades-database
-- Logs begin at Thu 2016-04-28 21:11:19 UTC, end at Thu 2016-04-28 21:20:17 UTC. --
Apr 28 21:11:21 878e5eba299e systemd[1]: Starting Hades database service (PostgreSQL)...
Apr 28 21:11:21 878e5eba299e systemd[1]: Started Hades database service (PostgreSQL).
Apr 28 21:11:24 878e5eba299e hades[61]: LOG:  database system was shut down at 2016-04-28 21:02:2
Apr 28 21:11:24 878e5eba299e hades[61]: FATAL:  the database system is starting up
Apr 28 21:11:24 878e5eba299e hades[61]: FATAL:  the database system is starting up
Apr 28 21:11:24 878e5eba299e hades[61]: FATAL:  the database system is starting up
Apr 28 21:11:25 878e5eba299e hades[61]: LOG:  MultiXact member wraparound protections are now ena
Apr 28 21:11:25 878e5eba299e hades[61]: LOG:  database system is ready to accept connections
Apr 28 21:11:25 878e5eba299e hades[61]: LOG:  autovacuum launcher started
Apr 28 21:11:25 878e5eba299e hades[61]: FATAL:  pg_hba.conf rejects connection for host "::1", us
Apr 28 21:11:26 878e5eba299e hades[61]: ERROR:  relation "radusergroup" does not exist at charact
Apr 28 21:11:26 878e5eba299e hades[61]: STATEMENT:  SELECT count(*) AS count_1
Apr 28 21:11:26 878e5eba299e hades[61]: FROM radusergroup
Apr 28 21:11:27 878e5eba299e hades[61]: ERROR:  relation "dhcphost" does not exist at character 3
Apr 28 21:11:27 878e5eba299e hades[61]: STATEMENT:  SELECT count(*) AS count_1
Apr 28 21:11:27 878e5eba299e hades[61]: FROM dhcphost
Apr 28 21:11:27 878e5eba299e hades[61]: ERROR:  relation "radgroupreply" does not exist at charac
Apr 28 21:11:27 878e5eba299e hades[61]: STATEMENT:  SELECT count(*) AS count_1
Apr 28 21:11:27 878e5eba299e hades[61]: FROM radgroupreply
Apr 28 21:11:28 878e5eba299e hades[61]: LOG:  received smart shutdown request
Apr 28 21:11:28 878e5eba299e hades[61]: LOG:  autovacuum launcher shutting down
Apr 28 21:11:28 878e5eba299e hades[61]: LOG:  shutting down
Apr 28 21:11:28 878e5eba299e hades[61]: FATAL:  the database system is shutting down
Apr 28 21:11:30 878e5eba299e hades[61]: FATAL:  the database system is shutting down
Apr 28 21:11:31 878e5eba299e hades[61]: FATAL:  the database system is shutting down
Apr 28 21:11:32 878e5eba299e hades[61]: FATAL:  the database system is shutting down
Apr 28 21:11:32 878e5eba299e hades[61]: FATAL:  the database system is shutting down
Apr 28 21:11:34 878e5eba299e hades[61]: FATAL:  the database system is shutting down
Apr 28 21:11:35 878e5eba299e hades[61]: LOG:  database system is shut down
Apr 28 21:11:36 878e5eba299e hades[61]: 2016-04-28 21:11:36 ERROR    __main__        Can't drop p
Apr 28 21:11:36 878e5eba299e hades[61]: LOG:  database system was shut down at 2016-04-28 21:11:3
Apr 28 21:11:36 878e5eba299e hades[61]: LOG:  MultiXact member wraparound protections are now ena
Apr 28 21:11:36 878e5eba299e hades[61]: LOG:  database system is ready to accept connections
Apr 28 21:11:36 878e5eba299e hades[61]: LOG:  autovacuum launcher started

sebschrader commented 8 years ago

A few minor things I noticed:

The table_options and join_options Jinja2 macros are not needed in schema_fdw.sql.j2
The safe_inet_cast and safe_macaddr_cast are not needed in schema_fdw.sql.j2
This is debatable, but I would use exec python3 -m hades.common.su instead of su and then exit
There is a trap missing in run_init_database_schema to stop the postgres database, a trap - … to delete registered traps is present however

fgrsnau commented 8 years ago

Thanks, I’ll fix these.

fgrsnau commented 8 years ago

I tried to address all the mentioned issues. Additionally I redesigned the database initialization a bit. The first substep is to initialize the database cluster and in the second step the database is created and the schema is populated. Both substeps have now meaningful traps (if there are problems with the hades database it can be dropped by passing --clear to init-postgres-database without affecting other databases inside the cluster).

Between both steps the development Dockerfile will create the local radius database. (For populating the schema of the hades database the foreign data source has to be set up correctly.)

sebschrader commented 8 years ago

Thanks for addressing the issues.

I do have a minor objection though. The command names were intended no to use any specific product. Your changes introduce init-postgres-cluster and init-postgres-database.

Could we go with e.g. init-database-system and init-database-schema instead?

fgrsnau commented 8 years ago

Done

agdsn / hades

Run systemd inside development docker container #24