[ENHANCEMENT] Separation of data, container-configs, and containers; FQDN-related scripts

[zenny]

Hi @cedwards:

Bastille integrates security and automation concepts learned over fifteen years working in DevOps.

👍

Bastille seems to be an interesting development with templating system like proxmox amidst several similar jail managment tools (iocage, iocell, cbsd, pot, focker, ezjail among others), but what I always miss in many of the deployment (including the first and second where I tried to contribute) are:

1. Separation of data (zpool/data) and container-configs (zpool/configs) from the containers (zpool/jails) [remove the prefix zpool in non-zfs systems] à la https://github.com/msimerson/Mail-Toaster-6/wiki/FreeBSD which was originally promoted by Late Paul (https://2010.asiabsdcon.org/papers/abc2010-P4A-paper.pdf) and proxmox in linux (only the config part). Usually this is important, at least in my case, when one needs to upgrade the containers and/or migrate to a different location. This makes things easier as one needs only to migrate the data and config parts, recreating anew containers in the different machine in different location.

File structure

- /data
-   /fqdn-hostname
-     /services-data
-       /service-name(s)
-        /serviceN-data

- /config
-    /fqdn-hostname
-       /services-configs
-         /service-name(s)
-          /serviceN-name

- /jails
-   /fqdn-hostname
-     /fqdn-containers
-       /service-containers
-         /container-name(s)

The /config directory above may be a sub-directory to /data to make it easier to migrate! Please refer to the msimerson/Mail-Toaster-6#447 for an explicit file structure.

Thus, one can just migrate the /config and /data in case needed. This can be achieved by creating a script to dump and export to a new container either using zfs send/receive or rsync or scp;

2. Ability to deploy a bunch of related containers in different zpools in case zfs is available;

3. Orchestratration of several machines from a single instance (project-fifo, portainer, CRIU among others) of management console, be it cli-based. 2 and 3 here also helps to compose multiple containers as a single service à la docker-compose or figure in the wiki of Mailtoaster-6 stated above in 1 (https://github.com/msimerson/Mail-Toaster-6/wiki); and

4. Deployment of several services like letsencrypt from a single/loadbalanced jail(s) running haproxy to run other services behind. Deployment of specific FQDN-related services with a single script (again in reference to MailToaster-6), something like:

# bastille create/destroy letsencrypt FQDN-hostname (to create and destroy relevant LE certificate in the public-facing single/load-balanced haproxy jails)
# bastille deploy/detroy mailserver (deploys similar to mailtoaster-6) FQDN-hostname CIFR
# bastille deploy/destroy webserver FQDN-hostname CIFR
# bastille deploy/destroy dbserver FQDN-hostname CIFR
# bastille deploy/destroy ALL FQDN-hostname CIFR
# bastille migrate mailserver/webserver/dbserver/ALL FQDN-hostname REMOTE-HOST new-CIFR

and so  on, where REMOTE-HOST is also bastille-configured host

I feel like they could be good resources to consider, at least 1 and 4 above. Just my two cents.

Cheers, and stay safe.
/z

[bmac2]

@cedwards comment on this one please. Would be a restructure of our file systems.

[bmac2]

@cedwards comment on this one please. Would be a restructure of our file systems.

[tschettervictor]

It would be a pretty big undertaking.

#895 will allow using a custom config, but as for keeping the data separate, it is probably best to mount any and all data that should persist outside the jail using nullfs mounts.