master 追従の自動化とかタイミング


#1

当方 master 追従勢ですが、あまり高度な自動化をしておりません。
以下のような手順でアップデートしています。

  • (開発機で) github リポジトリを upstream に追従させる
  • (サーバで) シェルスクリプト実行
    • mastodon を止める
    • docker-compose pull
    • docker-compose run --rm web rails db:migrate
    • docker-compose run --rm web rails assets:precompile
    • git pull / git checkout 等
    • mastodon を起動

ただ、一度これでアップデートしたとき、 docker のリポジトリが master の HEAD に追い付く前だったのか妙なエラーが出たことがあるので、もしや GitHub の master だけ見てアプデするスクリプト書くとヤバいのでは……という疑念が芽生えました。

皆様、どのようにアップデートの機を見たり自動化したりしてますか?
どんどん自慢してください。


#2

私の場合、アップデートは「丹念に、丹念に、手作業で行います」と言う感覚でやっています。
アップデート前後は全サービスを止めるようにしています。

アップデートタイミングですが、「必要に応じて」と言う感じでやることが多く、最低限tag化される前は待つようになりました。そこから様子見をして、セキュリティインシデントが見受けられた場合に限り、急いでアップデートをする感じにしています。

もう少しスクリプト実装をきちんとさせれば、Hinemosの自動ジョブ化で月毎アップデートとかしたら面白いのかな~と画策はしています。
OSアップデートの手法ではありますが、自動化そのものは少し試してあそんでいます。応用するとマストドンにも使えるかなーと思ったり。
https://www.bluecore.net/?p=4460


#3

自分の場合は基本Release版が出たら、というタイミングでやる事が多いですが、
ユーザーにウケそうな機能(先日の例ならカスタム絵文字とかカスタムテーマとか)が追加されたら
masterにする、という感じでやっております。
不勉強なもので(最近はあまり無いですけど)アップデートの際にトラブる事が何度かあったので、
自動化なんてとてもとても・・・。


#4

自分の管理しているインスタンス(mstdn.jp, ma.mstdn.jp, edge.mstdn.jp)はcapistranoを用いたデプロイを行っています。サービスはsystemdで立ち上げているため、capistrano-systemdを用いてデプロイ後にサービスが再起動されます。

mstdn.jpは大規模インスタンス故、リリース版のみへの追随を行っています。デプロイも、マイグレーションファイルなどのチェックを行って安全性を確認した後、mstdn-jpブランチへ変更をマージした後に手でcapコマンドを叩くような形で行っています。

一方で実験インスタンスのedge.mstdn.jpではSlackを用いた自動追随・デプロイの仕組みをhubotで作成し、用いています。Slackで「master追随して」と発言するとGitHubのAPIを叩いて現在のmasterブランチをマージし、「edgeデプロイして」と発言するとcapistranoが動き、自動でデプロイされるような形です。たまにマージやデプロイに失敗することがあるのですが、その場合は手作業に切り替えて行います。


#5

こんにちは。さくらのクラウド非Docker弱小鯖です。
毎日のようにmaster追従していますが、手動です。
何が起こるかわからないので。1行ずつコピペしています。
サービスは停止しません。止めなくても問題は出ないので。


#6

documentation/Updating-Mastodon-Guide.md at master · tootsuite/documentation
知らなかった……(マニュアル読んでない顔)


#7

相当に大きなインスタンスだと、一部の大きなマイグレーション(カラムの型変更だとか)でたまに止めないといけなくなることがあるのですが、それほど大きくなければ気にしなくても大丈夫そうです。


#8

当インスタンス( https://mstdn.nere9.help )では管理者が複数いるのですが、未だに手作業でのアップデートをしています。(複数人いるならはよ自動化しろよといわれればそれはそうですが

Mattermostを身内で使っていて、そこのmastodonチャンネルで適当にアップデートするといったことを言ってからアップデート作業を開始します。タイミングは気が向いたときです。
各自がtootsuite/mastodonをupstreamに設定していて、ブランチを切ってmasterに合わせてからpush、ソースはGitlab( gitlab.ejone.co/kanikosen/mastodon )にあるのでそこにmerge requestを投げます。
merge requestをmergeしたら実際に動いているサーバにdevアカウントでログインして(devアカウントは1passwordで共有している)

(実サーバ上のgitにはreleaseブランチ以外は存在していない状態です)

  • git fetch
  • git merge origin master
  • docker-compose build
  • docker-compose run --rm web rails db:migrate
  • docker-compose run --rm web rails assets:precompile
  • docker-compose up -d
    を逐一実行、といった感じになっています。

自動化しないと…


#9

さくらのVPSで1コア512MBでお一人様インスタンス(https://don.crakac.com)を運用しています。
Dockerは使っていないです。

私は本家masterに新機能やバグ修正、パフォーマンス改善が入ったりしたら追従するようにしています。
hubotを使ってSlackのチャンネル上で完結するようにしています。

  • masterのコミット通知を受け取る
  • どういう変更があったか眺める
    • 翻訳だけだったら特に何もしない
  • hubotに以下のコマンドを投げ込む
    • デプロイしたいブランチを指定
    • 指定したブランチに本家masterをマージする
    • 更新用シェルスクリプトの実行
  • assets:precompileが通ることを祈る🙏

assets:precompileがメモリをどか食いするので、前回デプロイしたときから差分があるファイルをチェックして、必要なときだけ必要なコマンドを実行するようにしています。



#10

メインで使用しているお一人さまインスタンス(mastodon.matcha-soft.com)では、基本的には本家masterへ変更が入った際に様子を見つつ、これ以上変更が入らないと思われるタイミングで実施しています。(だいたい1日に1〜2回程度。ただし、本家masterに動きがない場合は除きます)

追従手段については、以下のような一連の流れを一括で行うシェルスクリプトを用意し、追従時にはこれを実行する形で更新作業を行っております。

  • git fetch
  • git checkout
  • git merge
  • bundle install
  • yarn install --pure-lockfile
  • db:migrate
  • assets:precompile
  • mastodon再起動

なお、別途WebUIを用意し、GitHub上での本家masterブランチのマージおよび上記シェルスクリプトの実行をWebブラウザ上からも行えるようにしてあります。

また、開発・検証用インスタンス(puredon.matcha-soft.com)においてもお一人さまインスタンスと同様のシェルスクリプトを設置し、ブランチの切り替えや更新内容の反映などを行いやすくしてあります。


#11

Herokuで運用してるぼっちインスタンスzundaonでは、Heroku Pipelinesでステージング用のアプリでざっと動作確認してから本番用のアプリにビルドしたアプリをコピーしています。

準備

PipelineのStaging段に試験用のアプリケーションを置いておき、GitHubのレポジトリをPipelineに連携しておいて、インスタンス用のブランチにpushがあった場合にビルドが走るように設定しておきます。

ワーキングコピーの用意。bundle install等は手元ではおこなわないので、gitだけ動くようにしておきます。

git clone git@github.com:ユーザー名/mastodon.git
cd mastodon
git remote add upstream https://github.com/tootsuite/mastodon.git
git checkout -b インスタンス用のブランチ
git push -u origin インスタンス用のブランチ

改造

インスタンス用のブランチに変更点をコミットします。動作試験のためにはbundle installできる環境が必要ですね。

git checkout インスタンス用のブランチ
vi いじるファイル
git add いじるファイル -m 'いじった理由'
git commit

Release Phaseでデータベースのマイグレーションが走るようにしておくと便利です。Procfileに下記のような行を加えておきます。

release: rake db:migrate

マージ、プッシュ、ビルド

git fetch upstream
git log upstream/master...master
git checkout master
git rebase upstream/master
git push
git checkout インスタンス用のブランチ
git merge master
git push

ビルドとマイグレーションを眺める。

heroku builds:output -a ステージングのアプリ名; heroku logs -t -a ステージングのアプリ名

ステージング用のアプリケーションをちょっと使ってみる。うまくいったら、本番用のアプリケーションにslugをプロモートして、マイグレーションと再起動を眺める。

heroku pipelines:promote -a パイプライン名; heroku logs -t -a 本番用のアプリケーション名

#12

mstdn.maud.io では master+α でdocker運用してます。

追随は作業環境で

git fetch tootsuite
git merge tootsuite/master
git push origin hota/master

して https://github.com/lindwurm/mastodon/tree/hota/master に送り込んだ後、

本番環境で

git pull
docker-compose build
docker-compose run --rm web rails db:migrate
docker-compose run --rm web rails assets:precompile
docker-compose up -d

をまとめてやってますね…本番環境は常にremoteと同じ状態であるようにしてます

追記: 追随のタイミングは tootsuite/master との差がだいたい (10commits | 24h)~50commits以内 の任意のタイミング(気まぐれ)です


#13

自分も @hota さんと基本同じような感じですが Hubot を使って Slack から GitHub のプルリクをマージしたりサーバー側も操作できるようにしてます!


#14

検証用インスタンス(実質お一人様)の https://testingmstdn.abcang.net は、CPU 2Coreでメモリ1GBのConoHaのサーバで動かしています。Dockerは使っていません。

master追従のタイミングはきまぐれで、だいたい1日に1, 2回、なんらかの機能が追加されたりバグが修正されたタイミングでやっています。翻訳やテストの追加だけの場合はやってないです。

作業は半手動でやっていて、いくつかのシェルスクリプトを実行するだけでmaster追従できるようにしています

  • follow-master.sh
    • tootsuite/mastodonをマージしてリポジトリ(abcang/mastodon/tree/testingmstdn)にpush
  • git-pull.sh
    • サーバにsshして、 abcang/mastodon/tree/testingmstdn をpullしてくる
  • package-install.sh
    • サーバにsshして、bundle install --deployment --without development testyarn install --pure-lockfileを実行
    • GemfileGemfile.lockpackage.jsonyarn.lockのどれかが更新された時だけ実行
  • assets-precompile.sh
    • サーバにsshして、RAILS_ENV=production bundle exec rails assets:precompileを実行
    • app/javascript/以下のファイルが更新されたときだけ実行
  • db-migrate.sh
    • サーバにsshして、RAILS_ENV=production bundle exec rails db:migrateを実行
    • db/以下のファイルが更新されたときだけ実行
  • restart-mastodon.sh
    • サーバにsshして、sudo systemctl restart mastodon-websudo systemctl restart mastodon-sidekiqsudo systemctl restart mastodon-streaming を実行

package-install.shassets-precompile.shdb-migrate.shは、マージしたときの変更ファイル一覧を見て実行するかどうか判断しています。また追従作業はMastodonを動かしたまま進めて、最後にrestartするという感じでやってます。


#15

うちのサークル用のインスタンス(といってもほぼ使われていないので事実上私の検証用になってしまっていますが) の https://mstdn.otyakai.xyz では、systemd-nspawnのコンテナで動かしています。コンテナ内外ともディストリはArchLinuxです。デプロイのタイミングはきまぐれです(クライアントを開発してるので、その都合で新規APIが生えたりしたときに追従しています)

更新作業はひとつのPythonスクリプト(update.py)にまとめていて、これを(SSHして手動で)実行すると

  • サークルのSlackのbot用チャンネル / https://mstdn.otyakai.xyz/@shibuya_rin でアップデートの告知
  • sidekiq/web/streaming の停止
  • データベースのpg_dumpでのバックアップ
  • 現在環境(~/live)のバックアップ
  • git pull
  • bundle install
  • yarn install --pure-lockfile
  • rails db:migrate
  • rails assets:precompile
  • sidekiq/web/streaming の開始

という処理が走るようになっています。

また、デプロイ中はサークルのSlackで随時進捗を伝えてくれるようにしています(メッセージの編集機能を利用)。