Bastille integrates security and automation concepts learned over fifteen years working in DevOps.
:+1:
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:
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.
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;
Ability to deploy a bunch of related containers in different zpools in case zfs is available;
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
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.
Hi @cedwards:
:+1:
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:
zpool/data
) and container-configs (zpool/configs
) from the containers (zpool/jails
) [remove the prefixzpool
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
The
/config
directory above may be a sub-directory to/data
to make it easier to migrate! Please refer to the https://github.com/msimerson/Mail-Toaster-6/issues/447 for an explicitfile 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;
Ability to deploy a bunch of related containers in different zpools in case zfs is available;
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
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:
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