Hi Meta,
While there seem to be a few playbooks around for provisioning Discourse, there didn’t seem to be any for doing updates/upgrades, so in response to my own personal need I’ve created one.
Very happy to receive feedback, bug reports, pull requests, etc.
It looks interesting, now, I have a few observations, that I think can help to improve the playbook.
dist-upgrade? It would be safer just to use apt upgrade and leave the apt dist-upgrade for manual intervention, to ensure nothing breaks.autoremove and autoclean can bring some headaches with over enthusiastic packages removal.cd /var/discourse && git pull although nice, not needed. My understanding is that ./launcher rebuild app already does the git pull.I think the playbook could get a lot more powerful using variables, like choosing which upgrade process will be used. Adding conditionals for autoremove and autoclean. As well for the rebooting as it’s not always needed.
Thanks @marianord for your feedback. You make valid points.
I’ve been using apt dist-upgrade for years on all my servers without any issues or breaking anything. I found this answer on AskUbuntu, which was helpful in understanding the difference, and it didn’t seem to suggest any major risks to dist-upgrade. I am not using any special PPAs or apt pinning on any of my instances.
autoremove and autoclean are things I do periodically on my servers, and I wasn’t sure how frequently they should ideally be done, so I just figured do it at the end of each OS upgrade. Anyone know how often this should be done?
As for git pull I have always done this because the Discourse upgrade instructions say to do it. I can see there is a git pull going on in the ./launcher script but I assumed some of that was going on inside the Docker container, so you might also need a git pull outside the container to update the docker manager code?
The possible issue (is not common, but possible) is that by using anything else than apt upgrade you might break something else. Assuming you’d like a broader public to use that playbook giving the choice of using upgrade or dist-upgrade is a nice to have. I’d default it to apt upgrade and enable a variable to change it to apt dist-upgrade.
Why? Because apt upgrade is the only command that ensures it won’t break something upgrading other things. For example, let’s say someone is running Discourse with nginx as a reverse proxy. And for some hypothetical reason both nginx and Docker (or Redis, PostgreSQL, etc) use libhypothetical. Nginx doesn’t update it to the lastest version, but that other package does. If the library made breaking changes Nginx will stop working if the system is updated with anything else than apt upgrade, bringing the service down.
The issue with autoremove and autoclean is the same one as with apt dist-upgrade, if libhypothetical is a dependency of two packages, one updates and doesn’t needs it anymore apt might fail to know that the other package still needs it and remove it. Having old packages, for me, is not that big of an issue as they don’t usually take more than a couple hundred megabytes, until I get in there manually and remove them.
My understanding is that they updated the .launcher rebuild command and added the git pull that wasn’t there before. But people more knowledgeable about that can tell us definitively.
I’m in agreement above, the reboot seems unnessary and fairly dangerous to have in a script like this. In situations where the ansible script were automated, could be surprising if a user doing manual work on the server were kicked out for a reboot.
OK thanks @featheredtoast and @marianord
About half the time when I do updates on servers, the next time I log in the MOTD is ‘A reboot is required’, so I had decided that rebooting would probably be necessary most times I run the update.
Very easy to have two playbooks, one which does dist-upgrade, autoclean and reboot and one which does just plain upgrade, no autoclean, and no reboot, maybe?
I tend to trigger these playbooks manually, and watch the output, so they are not running on a cron job or on a daily basis, which I would agree is risky in terms of rebooting in the middle of work.
Note that due to the way Discourse works with client-side Ember code, users can be in the middle of writing a reply when the server reboots and they will probably not notice any interruption. Reboots take less than 15secs usually in my setup.
You can make it work with just one playbook using conditionals. And some more variables
Ansible is very flexible and I’m quite sure it is possible with conditionals. Happy to take a PR although I don’t want to overcomplicate what is a very simple playbook.
Overall I’m just looking for a playbook that suits my personal needs and I thought I’d share it with the rest of the Discourse community in case it helped anyone.
Maybe we could pool our ideas and make a suite of Ansible tools for managing and provisioning Discourses using Ansible (which seems to me the most lightweight tool for this purpose) which includes a variety of playbooks
See also this thread from a couple of years ago, the Ansible I have written for Discourse hasn’t been updated in a while but I hope to have time to improve it soon.
This is 404ing right now. Has it moved?
I think I moved it to https://github.com/bawmedical/ansible-tools/blob/main/playbooks/discourse-updater-playbook.yml however I never quite got it to a stage I was happy with. In the end I abandoned Ansible in favour of Bash scripts.
Would love to know what the serious Discourse hosting people are doing, because OS and Discourse updates do take a decent amount of time done manually…
This also 404s for me. Maybe a private repo?
Makes sense. I have a playbook for installing Discourse and I was curious how other people approached the problem. As you mention, keeping up with updates can be time-consuming.
Ah sorry yes it’s a private repo. I almost never do that! I must have been embarrassed about the uselessness of that stuff… 
Here’s that file:
---
- hosts: all
vars:
ansible_python_interpreter: auto_silent
tasks:
- name: Update server OS (apt update && apt dist-upgrade && apt autoremove && apt autoclean)
become: yes
apt:
update-cache: yes
upgrade: dist
autoremove: yes
autoclean: yes
# - name: Update Discourse code from GitHub (cd /var/discourse && git pull)
# become: yes
# git:
# repo: 'https://github.com/discourse/discourse_docker.git'
# dest: /var/discourse
# update: yes
# version: master
# register: gitcommit
# - name: Rebuild the Discourse container (cd /var/discourse && ./launcher rebuild app)
# become: yes
# shell: ./launcher rebuild app
# args:
# chdir: /var/discourse
# when: gitcommit.changed
# - name: Clean up stopped containers (cd /var/discourse && ./launcher cleanup)
# become: yes
# shell: echo Y | ./launcher cleanup
# args:
# chdir: /var/discourse
# - name: Reboot machine with default Ansible settings
# reboot:
# become: yes
As you can see it’s almost useless as it is.
If there was any interest in developing some shared scripts for automating updating OS, Discourse, launcher cleanup, and (for bonus points) writing in the Changelog of each Discourse instance, then I’d be up for helping. For just me it’s not quite worth maintaining my own Ansible playbooks.
I’m somewhat interested. I use a two-container setup, so I’d need to account for that. I’d also want to make the reboot optional. Nothing seems impossible, but it would be helpful to have several people to make it less of a burden on any individual person.
At Communiteq, we use Ansible for everything.
Literate Computing uses Ansible for everything too.
You can use (but not see) my ansible scripts if you use https://dashboard.literatecomputing.com/. It knows about 2-container, checks Postgres versiono and pgvector version, runs cleanup if disk space gets tight, and a bunch of other stuff. You can check it out for free by joining the Free Trial group.
I love that they have a Discourse forum! Usually a sign of a good open source project.