Ansible playbook for updating Discourses

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.

  • Why always use dist-upgrade? It would be safer just to use apt upgrade and leave the apt dist-upgrade for manual intervention, to ensure nothing breaks.
  • Using 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?

1 Like

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.

1 Like

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.

1 Like

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.