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 に移動したと思いますが、満足できる段階にはなりませんでした。最終的には、Bash スクリプトを優先して Ansible を断念しました。
真剣な Discourse ホスティングを行っている人々が何をしているのか知りたいです。なぜなら、OS と Discourse のアップデートは手動で行うとかなりの時間がかかるからです…
これも404になります。プライベートリポジトリでしょうか？
なるほど。私はDiscourseをインストールするためのプレイブックを持っており、他の人がどのようにこの問題に取り組んでいるか興味がありました。あなたが言うように、アップデートの維持は時間がかかることがあります。
ああ、すみません、はい、プライベートリポジトリです。そんなことはほとんどしません！そのことの無益さに恥ずかしかったに違いありません… 
そのファイルはこちらです：
---
- 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
ご覧のとおり、現状ではほとんど役に立ちません。
OS、Discourse、ランチャーのクリーンアップを自動化するための共有スクリプトの開発、または（ボーナスポイントとして）各Discourseインスタンスの変更履歴に書き込むことに関心があれば、喜んでお手伝いします。私一人では、独自のAnsibleプレイブックを維持するほどの価値はありません。
興味はあります。私は#two-containerセットアップを使用しているので、それを考慮する必要があります。また、再起動はオプションにしたいです。不可能なことは何もなさそうですが、個人への負担を軽減するために、数人で協力できると役立ちます。
Communiteqでは、すべてにAnsibleを使用しています。
Literate Computing もすべてに Ansible を使用しています。
https://dashboard.literatecomputing.com/ を使用すると、(表示はされませんが) 私の Ansible スクリプトを使用できます。2 コンテナを認識し、Postgres のバージョンと pgvector のバージョンをチェックし、ディスク容量が逼迫した場合にクリーンアップを実行し、その他多くのことを行います。無料トライアル グループに参加して、無料で試すことができます。
彼らがDiscourseフォーラムを持っているのは素晴らしいですね！通常、これは良いオープンソースプロジェクトの兆候です。