I've always wondered why this project needs to be so complex... I need to administer 10-20aps... why is it necessary to run 9 services to achieve this? A mail server? An OpenVPN server? Docker is still not advised for prod use.
Updating a fleet of embedded devices like routers (which can come online and go offline at any time) will generally be much easier using a pull-based update model. But if you’ve got control over the build and update lifecycle, a push-based approach like ansible might be appropriate.
Maybe I am missing somehing, but I would assume that base network infrastructure like routers, firewalls and switches have a higher uptime, availability and reliability than ordinary servers.
The problem with push is that the service sitting at the center needs to figure out which devices will need to be re-pushed later on. You can end up with a lot of state that needs action just to get things back to normal.
So if you can convince devices to pull at boot time and then regularly thereafter, you know that the three states they can be in are down, good, or soon to be good. Now you only need to take action when things are down.
Never analyze distribution of software and config based on the perfect state; minimize the amount of work you need to do for the exceptions.
Unattended upgrades fail and sit there requiring manual intervention (due to lack of transactional updates and/or multiple flash slots (root partitions and bootloader configuration)).
Pull style configuration requires the device to hold credentials in order to authorize access to download the new policy set.
It's possible to add an /etc/init.d that runs sysupgrade on boot, install Python and Ansible, configure and confirm remote logging, and then run `ansible-pull`.
But then log collection; unless all of the nodes have correctly configured log forwarding at each stage of firmware upgrade, pull-style configuration management will lose logs that push-style configuration management can easily centrally log.
Pull based updates would work on OpenWRT devices if they had enough storage, transactional updates and/or multiple flash slots, and scheduled maintenance windows.
This software has been used to run public wireless services in many Italian towns, in collaboration with local government institutions.
Docker not recommended for prod? I believe that the industry is going in a different direction :)
https://openwisp.io/docs/stable/docker/index.html
So if you can convince devices to pull at boot time and then regularly thereafter, you know that the three states they can be in are down, good, or soon to be good. Now you only need to take action when things are down.
Never analyze distribution of software and config based on the perfect state; minimize the amount of work you need to do for the exceptions.
Pull style configuration requires the device to hold credentials in order to authorize access to download the new policy set.
It's possible to add an /etc/init.d that runs sysupgrade on boot, install Python and Ansible, configure and confirm remote logging, and then run `ansible-pull`.
ansible-openwrt eliminates the need to have Python on a device: https://github.com/gekmihesg/ansible-openwrt
But then log collection; unless all of the nodes have correctly configured log forwarding at each stage of firmware upgrade, pull-style configuration management will lose logs that push-style configuration management can easily centrally log.
OpenWRT wiki > Sysupgrade: https://openwrt.org/docs/techref/sysupgrade
https://nixos.wiki/wiki/OpenWRT