How does juju handle accruing security updates ? Usually Ubuntu security updates come quite frequently, do I have to install them manually ? Or does juju this for me ?
When it’s a manual process, what’s your suggestion on the update cycle, how often should I update the underlying OS, how often the applications, how to make sure that the update process runs as smoothly as possible.
Thanks for your input 
Juju does not directly manage software updates beyond the initial deployment of the machines. During machine creation, there are settings in the juju model which affect whether security updates are applied as machines are deployed, and which image repository (i.e. daily or stable) the machines are built from.
A deployed ubuntu image has unattended-upgrades enabled by default, which will pull updates from the main distro repository as well as the daily security updates. It does not automatically include the -updates repository. The repositories used during unattended upgrades is managed by the /etc/apt/apt.conf.d/50unattended-upgrades file on each machine, and the file /etc/apt/apt.conf.d/20auto-upgrades defines whether Unattended-Upgrades are enabled. Hence, by default, you’ll receive security-related fixes installed on your systems daily.
Package and patch management at scale is typically addressed by our Landscape product. This can be consumed as a SaaS service or installed on premises within your private data center. Each machine in your juju model can then integrate with and register to Landscape via the landscape-client charm.
Updates of systems can then be manually managed or automatically scheduled via Landscape. Since services are typically restarted as updates are applied, It is recommended that any automated scheduling of system patches be configured to ensure clustered application machines are patched in series rather than in parallel to maintain full API uptime for services deployed in an HA fashion.
The update cadence for your systems is highly dependent upon your own internal availability management strategies. Daily updates allow for the most granular approach to knowing which packages may have affected stability during a given patching window, however that is conversely balanced with some organizational preferences where a weekly, monthly, or quarterly cadence may match expectations more reliably. Note that if you’re continuously deploying new machines in your juju models, those services on the newer machines may end up with software ahead of the rest of the system if you’re not consuming patches daily.
Thanks for your reply, that was really helpful. It’s pretty neat that this community seems to be really interested in helping people out, often if you ask something somewhere else the answers are rather short and incomplete, I am really happy that this is not the case here.
Hi Daniel,
I’ll let you know how I’ve done it so far… basically I keep it pretty simply and… every once in a while I’ll do the following two commands while my juju status points to a certain model I want to update
juju run --all -- sudo apt update
then if there’s updates it’s simply
juju run --all -- sudo apt upgrade -y
I’ll be straight forward though, this stuff is pretty much experimental servers in my own LXD cluster… and sometimes in AWS… both have handled this pretty well… and from time to time I’ll juju ssh into the nodes to see if I need to restart any for upgrades to take effect… but I am sure there are more programmatic ways others might share
As a suggestion (with the same caveats noted by @emcp regarding experimental nature and caution), I might recommend amending this to:
juju run --timeout=60m <target definition> -- 'sudo apt-get update && sleep $[ ( $RANDOM % 10 ) + 1 ]m && sudo apt-get full-upgrade -y -o Dpkg::Options::=--force-confdef -o Dpkg::Options::=--force-confold'
where <target definition> is something like --unit ubuntu/0 or --all or --application myapplication.
The random sleep will sleep 1-10 minutes on each unit to provide a pseudo-random offset. However, it is important that stateful applications like database clusters be patched one unit at a time to prevent introducing cluster inconsistency. This pseudo-random method will not prevent two units from sleeping the same amount of time and having multiple unit restarts simultaneously.