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.
此链接目前返回404。是否已移动？
我认为我已将其移至 https://github.com/bawmedical/ansible-tools/blob/main/playbooks/discourse-updater-playbook.yml，但我从未完全达到我满意的阶段。最后，我放弃了 Ansible，转而使用 Bash 脚本。
很想知道专业的 Discourse 托管人员都在做什么，因为手动完成 OS 和 Discourse 的更新确实需要相当长的时间……
这个也 404 了。也许是私有仓库？
有道理。我有一个 安装 Discourse 的 playbook，我想知道其他人是如何解决这个问题的。正如你所说，跟上更新可能很耗时。
啊，抱歉，是的，这是一个私有仓库。我几乎从不这样做！我一定是为那些东西的无用感到尴尬…… 
这是那个文件：
---
- hosts: all
vars:
ansible_python_interpreter: auto_silent
tasks:
- name: 更新服务器操作系统（apt update && apt dist-upgrade && apt autoremove && apt autoclean）
become: yes
apt:
update-cache: yes
upgrade: dist
autoremove: yes
autoclean: yes
# - name: 从 GitHub 更新 Discourse 代码（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: 重新构建 Discourse 容器（cd /var/discourse && ./launcher rebuild app）
# become: yes
# shell: ./launcher rebuild app
# args:
# chdir: /var/discourse
# when: gitcommit.changed
# - name: 清理已停止的容器（cd /var/discourse && ./launcher cleanup）
# become: yes
# shell: echo Y | ./launcher cleanup
# args:
# chdir: /var/discourse
# - name: 使用默认 Ansible 设置重启机器
# reboot:
# become: yes
如你所见，它几乎是无用的。
如果有人对开发一些共享脚本以自动更新操作系统、Discourse、清理启动器，以及（作为奖励）写入每个 Discourse 实例的 Changelog 感兴趣，我很乐意帮忙。对我个人而言，维护自己的 Ansible playbook 并不值得。
我有点兴趣。我使用#two-container设置，所以需要考虑进去。我也想让重启成为可选的。似乎没有什么是不可能的，但有几个人一起做会比较好，这样就不会给任何人造成太大的负担。
在 Communiteq，我们使用 Ansible 来处理一切。
Literate Computing 也将 Ansible 用于所有内容。
如果您使用 https://dashboard.literatecomputing.com/，您可以使用（但看不到）我的 ansible 脚本。它了解 2 容器，检查 Postgres 版本和 pgvector 版本，在磁盘空间不足时运行清理，以及许多其他功能。您可以通过加入免费试用组来免费试用。
我喜欢他们有一个 Discourse 论坛！这通常是一个优秀开源项目的标志。