この記事は新歓ブログリレー2020の16日目(3/24)の記事です。
19の翠(sappi_red)です。普段はSysAd班で部内サービスを触ってます。
traPの部内サービス
traPではOSS[1]を利用した複数の部内サービスがあります(運用しているサービス一覧)。
ただ、これらは保守が行き届いているとは言い難い状態でした[2]。
そこでそれらの保守性を高めるために、1月ごろからそれらのAnsible化、Docker化、GitHub Actionsを利用した上でのGitHub Packagesの利用をするようにしていき、3月に遂にそれらの対応が完了しました[3]。
| 日付 | やったこと |
|---|---|
| 01/06 | Crowiの新バージョンのtraP用パッチの作成 & Dockerfileの作成 |
| 01/12 | Ghostの新バージョンのtraP用パッチの作成 & Dockerfileの作成 |
| 01/14 | テスト用にGhostのデータの抽出 |
| 01/18 | CrowiとGhostのAnsibleスクリプトの作成 |
| 01/20 | NextcloudのAnsibleスクリプトの作成 |
| 01/24 | テストインスタンスを立ててGhostとCrowiがアップデート後のもので利用できるか確認 |
| 01/26 | インスタンスを移行した上でGhostとCrowiのデータを注入しアップデートしたものを稼働 |
| 02/12 | CrowiとGhostのGitHub Packages利用 |
| 02/18 | NextcloudのGitHub Packages利用 |
| 02/23 | Nextcloudの新バージョンの稼働 |
| 02/24 | Giteaの新バージョンのtraP用パッチの作成 |
| 03/02 | GiteaのGitHub Packages利用 |
| 03/03 | GiteaのAnsibleスクリプトの作成 |
| 03/05 | テストインスタンスを立てた上でGiteaの新バージョンの動作確認やマイグレーション[4]の確認 |
| 03/07 | Giteaの新バージョンの稼働 |
Ansible
通常、サーバーに何かのプログラムを設定したりする場合は実際にサーバーの中に接続をして適当なコマンドを順次叩かなければいけません。
このAnsibleはその手順を自動化し、その手順でのミスを防ぐ、アップデートなどの適用を高速化し、手間を削減できます。
現在traPでは6つのサーバーが運用されていて、元々そのうち3つのサーバーは既にAnsible化されていました。今回新たに2つのサーバーをAnsible化したことによりAnsible化されていないサーバーは残り1つとなりました。
これらのAnsibleスクリプトはGitea上で管理されています。
Docker
Dockerはコンテナ仮想化によりどの環境でも同じような動作を保障するようなソフトウェアです。OSなどの違いを吸収してくれます。DockerfileというDocker Image[5]を生成するためのスクリプトを記述します。
GitHub Actions + GitHub Packages
GitHub ActionsはGitHubに存在するCI機能[6]で今回はDocker Imageの自動ビルドに利用しています。
このビルドされたImageはGitHub Packagesに登録されます。
GitHub PackagesはGitHubに存在するパッケージレジストリでライブラリやプログラムのバージョンを登録してアップロードすることなどが可能です。
先述のAnsibleを利用したデプロイの際には、GitHub PackagesからImageがダウンロードされ利用されます。
アップデートの手間
これまではアップデートをするためには、
- traP独自で変更を行っている箇所のパッチを元のプログラムにあてる
- そのパッチをあてたプログラムが正常に動作をすることを確認する
- 実際にアップデートを行った際に、データベースのマイグレーションが正常に動作するかどうかを実際のサービスを模した環境(これを作成するためにはどうすればよいかの調査も必要)で確認する
- アップデート時にどのようなコマンドや作業を行う必要があるかどうかの調査をする
といった複雑かつ面倒な手順を踏まなくてはいけませんでした。
これらの変更を行うことで、より安全でより高速でより快適なアップデートを行えるようになりました。
例としては、
- 本番を模したテスト環境を作成する際に、Ansibleを実行するだけで生成することができる
- 直接サーバーを触るわけではないので、間違えてコマンドを叩いてファイルやフォルダを消してしまうというような人為的なミスを減らすことができる
- アップデート時にサーバーでプログラムをビルドするわけではないので、サーバーに負荷がかかることで他のサービスの応答速度が一時的に遅くなるなどの影響が出にくい上、アップデートの実行の時間が短縮される
- 実際にサーバー内のファイルやプロセスを見ずとも、Ansibleのコードを読むことでどのようなプログラムが走ってどこに何のファイルがあるかが確認できる
- これはサービスで障害などが発生しその原因を調査する際に、ログファイルの場所の調査などの手間を省くことができる
などの利点が得られました。
まとめ
この変更をするためにテストサーバーを建ててAnsibleの記述があっているか確かめることやDockerfileを書くことなどが結構大変でしたが、その分大きなメリットを得ることができたのでよかったです。
このような技術やツールは個人ではなかなか手を出すことが少ないものだと思いますし、ぼくは入学時には存在すら知らなかったので、こういう技術に触れれて実際に利用できるというのはSysAd班のアドかなって思います。
明日は @OCTPOB さんの記事です。お楽しみに！
