MIS.W 公式ブログ

早稲田大学公認、情報系創作サークル「早稲田大学経営情報学会」（MIS.W）の公式ブログです！

トップ > カウントダウンカレンダー2021冬 > MIS.W SysAd係のこれまでとこれから【カウントダウンカレンダー2021冬8日目】

MIS.W SysAd係のこれまでとこれから【カウントダウンカレンダー2021冬8日目】

カウントダウンカレンダー2021冬 プログラミング研究会 Web班

これはMIS.W公式アドベントカレンダーの8日目です。前回は54代CG研のMaiなさんのデザインの話でした。

こんにちは，54代プログラミング研究会のtosukeです。SysAd係という係で，サークルにおけるインフラなどの管理をしています。今回はSysAd係の紹介も兼ねつつ，今年やったことの紹介をしていこうと思います。

バーチャル会員証

MIS.Wには会員証がありますが，対面でのサークル活動がほぼ不可能であった去年や今年では使う機会がほとんどありませんでした*1。 Twitterがサークル員同士の交流の場としてより重要になっていたので，OGP画像として会員証っぽいものを生成できれば交流の助けになるのでは？と考えました。 さて，問題はどこに実装するかですが，ちょうどSysAd係ではみすポータルという，会員情報を管理するためのWebアプリケーションをメンテナンスしていたので，この上に実装しました。

f:id:tosukee:20211219211204p:plain
会員証 as a Twitter Card

Reactで組み立てたSVGをlibrsvgを使ってラスタ画像にしているのですが，登録しているハンドルネームが長すぎるとはみ出してしまうので若干選定を間違えた感がありますね。バーチャル会員証のページを構成するUIコンポーネントもTailwindCSSを使って新調したのですが他の部分では使われておらず……もったいないですね。

シングルサインオンの改良

2年前の記事にもあるように，MIS.WではAuth0を使ったシングルサインオンが導入されています。 しかしSlackのメンバー管理は全手動であり，正確な会員管理が難しいため，その後Auth0のログインはみすポータルの情報を使うようになりました。

  1. ユーザーがAuth0にSlackを使ってログインする
  2. Auth0のRulesがみすポータルに「該当のIDのユーザーは会員として登録されているか」を問い合わせる
  3. 登録されていなかったらログインを弾く

この手法は理想的かと思われたのですが，思わぬ欠点がありました。みすポータルは後述する部室サーバーのKubernetes環境上にデプロイされているのですが，部室のサーバーはありとあらゆる理由で落ちます。例えば今年だけでも

  • 大学の空調工事で部室に人が入ったときにコンセントが抜けたままになってしまう
  • 大学のネットワークのメンテナンスでアクセス不能になる
  • 部室でゲームをしたときにコンセントが抜けたままに
  • 部室のモニターを移動したときにコンセントが(ry

などの理由で落ちました。つまり，このままでは部室サーバーにアクセスできないとAuth0のログインができず，MIS.Wにおけるあらゆるサービスにアクセスできなくなります。 これは非常に困るので，部室サーバーが長時間落ちそうな場合は該当のRuleを無効化することで暫定的な対応をしていましたが，問題解決のため，サインオンのフローを変更することにしました。(内部向け: MISW/sysad#7)

  1. みすポータルからAuth0に会員情報を定期的に同期する
  2. ユーザーがAuth0にSlackを使ってログインする
  3. Auth0のRulesが同期された会員の情報からログインしようとしているユーザーが会員の権限を持っているか調べる
  4. 登録されていなかったらログインを弾く

この方式にすることでたとえ数ヶ月の間部室鯖が落ちている状態であったとしても，会員情報に変化がない限り正しく動作します。 正確にはみすポータルから直接Auth0に情報を送るわけではなく，みすポータルから会員情報を吸い出すAPIとみすポータルから吸い出した会員情報を外部のサービスと同期するサービスを作成して同期を行っています。みすポータルには会員情報の管理の責務だけを持たせたいですからね。*2

Kubernetes(再)構築

さて本丸です。様々なアプリケーションがデプロイされているKubernetes環境ですが，2年前に構築されて以来証明書の更新を除きアップデートが滞った塩漬け状態であり，v1.16系のKubernetesが動作していました。 移行を考えた当時の最新バージョンはv1.22.4であり，「複数のマイナーバージョンをまたいだ移行をサポートしない」というKubernetesの制約を考えると，アップデートの作業を連続で6回も行う必要があり，非常に億劫です。 サーバーのOSも古くなっていたので，これを機に環境を再構築することにしました。構築にはkubeadmを使用しました*3。

ArgoCD

次はマニフェスト管理についてです。Kubernetesではクラスタに対してアプリケーションが要求するリソースをマニフェストと呼ばれる(主に)YAMLファイルで定義します。 旧環境ではGitOps風のマニフェストをGitリポジトリで管理する手法を使っていました。新環境でも概ねそれを踏襲していますが，いくつか異なる点があります。 その1つとしてマニフェストの適用方法があります。旧環境ではcluster-adminロールを付与したサービスアカウントを接続したSelf hostedなGitHub Actions Runnerの上でマニフェストをkubectl applyで適用するという*4方法を取っていて，新環境でもはじめはこの方法でマニフェストを適用していました。 しかし，kubectl applyには「手動でクラスタの状態変更した場合Gitリポジトリとの同期が崩れる」「(後述する)Helmでのマニフェストの中にはHelmのHookの動作を期待しているものがあるが当然kubectlはHookに対応していない」などの問題があるので，ArgoCDを導入しました。

f:id:tosukee:20211220024818p:plain
かっこいいダッシュボード付き

ArgoCDはApplicationという単位で各アプリケーションを管理でき，それぞれのリソースのヘルスチェックも行ってくれるので非常に便利です。 ダッシュボードも単にかっこいいだけではなく，各リソースの関係を繋いでグラフを表示してくれるのでKubernetesの理解にも役立つのではないでしょうか？

Renovate

旧環境が塩漬けになっていた要因の1つとして，外部のマニフェストのバージョン管理が手動だったという点を考えることができます。依存している外部のマニフェストのリリース情報はSlackのチャンネルに流れてきていたのですが，人間が追うには少々辛い状態でした。

f:id:tosukee:20211220051122p:plain
意外とアップデートの頻度が高い

そこで新環境ではRenovateを活用することにしました。今回はkustomizeのHelm連携を使ってマニフェストの依存を表現し，Renovateに監視させることにしました*5。

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: argocd

resources:
  - namespace.yaml
  - ingress.yaml
  - argocd-secret.yaml
  - misw-repo-secret.yaml

helmCharts:
  - name: argo-cd
    releaseName: misw
    namespace: argocd
    version: "3.27.1" # ここをRenovateが監視する
    repo: https://argoproj.github.io/argo-helm
    includeCRDs: true
    valuesFile: values.yaml

f:id:tosukee:20211220055458p:plain
全自動リリース監視

Renovateの機能はkustomization.yamlの中のhelmCharts項目の監視だけではありません。Regex managerなる機能を使うと正規表現を書くことでファイル中の任意の部分文字列をRenovateの監視対象にすることができます。この機能を使って

  • GitHub Actionsで使用しているCLIツール(kubectl, helm, kubeval)
  • Renovateのサポートしていない形で記述されているactions-runner-controllerのaction runnerのイメージ

のバージョン管理を行っています。先ほどの画像に出ていたhelm/helmのアップデートがそれにあたります。こうした機能を使うことで痒いところに手が届くのがRenovateの強みですね。

TODO List

振り返ると今年は様々な作業をしていましたが，作業量としては常に猫の手も借りたいという状態*6であったので，未来に託していきたい興味深そうな *7 タスクというものがあります。記事も相当長くなってきたのでここらで簡単に書き出しておきましょう。

アプリケーションの監視

現状でもMackerelを使ったサーバーの監視は行っていますが，アプリケーションが正常に動作しているかの監視は行われていません。公式サイトのように外部のサーバーで動作しているアプリケーションもあるのでこれらも同時に監視できると便利ですね。

Discord運用の半自動化

シングルサインオン周りに手を入れたときに構築した仕組みを使えば，みすポータルが持っている情報を公式Discordサーバーにロールとして同期させることもできそうです。

公式サイトの運用改善

公式サイトはレンタルサーバー上で運用されていますが，こちらも若干塩漬け状態になっているためより改善された運用方法を模索していきたいところです。

これらのタスクを私達と共にやっていきましょう！と言えるとよかったのですが，私は後数週間の内にMIS.Wから引退する立場です。これからはOBとして見守っていく立場になるとは思いますが，インフラの発展*8を楽しみにしていきたいですね。

明日は55代プログラミング研究会のELICXIRさんです。

*1:今年の早稲田祭で54代のみゅーさんが配ってくれたので55,56代の方でも目にしたことがあるかもしれません

*2:じゃあバーチャル会員証は責務外なんじゃないかと言われると反論できない

*3:kubesprayでも問題なかった気もします

*4:もはや呪文の類である

*5:旧環境と比較して「diffとしてマニフェストの変更を見ることができる」という便利な性質を失っています。マニフェストを生成してGit管理下に置く運用にすれば解決しますが，Renovateもその規約に従わせる必要があります。Renovateがファイルに変更を発生させた後に特定のコマンドを実行させるような機能があればよいのですが，ざっと調べたところそのような機能は存在しない(運用者の視点から考えても厳しいですね)ようなので恐らく専用のBotを作る必要があり，なかなか難しいという判断です。よさげな方法があったら教えて下さると幸いです

*6:後進の育成に励めという話ではありますが，いわゆる木こりのパラドックスというやつです

*7:別に興味深くはない雑多なタスクは私がやっておいたほうがいいでしょう

*8:または破壊と創成。これもデータ喪失がなければまたアリだと思っています