はむはー！最近は私たち人間に優しい気温になってきました。ずっとこれくらいの気温になっててほしいです。
今日、KMC の例会講座で「コンテナ、Docker、Kubernetes って何が嬉しいの？」というタイトルで例会講座を行いました。
コンテナや Docker、Kubernetes はアプリケーションを書いたりサーバーを触ったりしていると目にすることがあると思いますが、「なんか難しそう」「今の運用でうまくいってるしな」と敬遠する人も多いと思います。また、アプリケーションを使うときに README の通りに Docker コマンドを打って、よくわからないけど動いている、でもなんか普通に立ち上げた時と違ってよく分からん、といったこともあるでしょう。
そんな人達がコンテナ技術に触れるきっかけとなるよう、「コンテナとはなんなのか？Docker や Kubernetes は何をしてくれて、使うと何が嬉しいのか？」ということに焦点を置いて講座をしてみました。
コンテナ、Docker、 Kubernetes を使うとっかかりが欲しい人に、ぜひこの資料を読んでいただければと思います！
こんにちは！Webサービス勉強会2022を担当している ryokohbato (KMC ID: rhato, ID: ryokohbato) です。今回は、Webサービス勉強会2022の第0回、および第1回のレポートをお届けします。
Webサービスについて1年かけて学ぶ勉強会です。以下リポジトリで環境および資料を公開しています。
第0回は環境構築回でした。Node.jsなど必要なツールをインストールした上で、開発用サーバーを立てました。
また、Webサービス勉強会2022では、Dockerを使用した開発環境も提供しています。こちらを使用して環境を構築してくれた部員もいたようですね。
さて、いよいよ勉強会の本格始動です。Webサービス勉強会は、大きく3つのパートに分けられています。
今回のメインパートでは、「書いて覚えるHTML」と題して手を動かしながらHTMLに慣れてもらいました。第1回の資料は こちら です。手軽にリッチなUIを作れる楽しさが感じてもらえたと思います。
今回の勉強会では進捗管理シートを用意しています。みなさん演習もかなり解き進めてもらえたようで何よりです。
さて、演習の時間を利用して、Webサービス勉強会2022ではより発展的な内容を扱う講座、裏講座を開催しています。第1回の今回は「イチからWebpackのconfigを書いてTypeScriptをコンパイルする」と題し、TypeScriptをコンパイルするために必要な webpack.config.js と tsconfig.json の書き方を学びました。次回は、コンパイルのためになぜこんな複雑なことをしているのか、について扱う予定です。
Webサービス勉強会2022では、Botの開発やWebサービスの開発を学びます。興味のある方は、以下の入部案内を参考にメールやTwitterのDMなどでいつでもご連絡ください。お待ちしております！
こんにちはこんにちは！ 3DCG勉強会2022 担当の crashRT です。
普段は Motion Graphics と呼ばれる CG を用いた映像を制作しています。最近ではKMCの新勧用のビラを作ったり Webサービスの勉強を始めたりしました。
参加者に 3DCG制作を布教する 3DCG制作の雰囲気を知ってもらうことを目指して、毎週火曜日の20:30から開催している新入生向け 1 のイベントです。
初めて3DCGに触れる参加者が多いので基礎を中心にゆっくり進めながら、3DCG を制作していく上で必要な知識や技術などについて話していきます。現在は無料の Blender を扱っていますが、後半では CINEMA 4D も扱う予定です。
現在は、昨今の情勢もあり Discord というサービスを用いて遠隔で開催しています。
これまでに開催した回では以下のような内容を扱いました。
沼にハマってくれた新入生もいるようで、色々作ってくれています。また、5/7 (土) には1日で上回生が支援をかましつつ新入生にとりあえずモデリングしてもらう、「ラピッドモデリング祭り」と呼ばれるイベントを開催し、無事参加してくれた新入生に作り上げてもらうことができました。（気がついたら完成していた新入生もいてビビっています）
これまでの4回で基礎の部分はある程度カバーできたと思うので、次回からは少しずつレベルを上げていこうと考えています。
講座はすべて録画しているので、今からの参加でも全く問題ありません。質問もいつでも受け付けているので、気軽に参加してください！
まずは、KMCの Twitter や メール にご連絡ください。
KMCではパソコンで何かしたい人々を大募集しています。入部資格に制限はありません。興味のある人は下のリンクからどうぞ！！
こんにちは！現会長のryokohbato (KMC ID: rhato, ID: ryokohbato) です。普段はたまに雑用業務をしつつKMCライフを満喫しています。今回はKMCの新歓で使うために開発した、独自のSlackメッセージ転送システムについて紹介するよ！
現在のKMCではSlackが主な活動の場になっており、KMC Slackには部員のいろいろなことが書き込まれているわけですが、体験入部時にはアカウントがMCG (マルチチャンネルゲスト) に設定されているため、それらを見ることはできません。しかし今年の新歓では新たな試みとして、体験入部時にもその一部を見えるようにすることで、KMCの空気感を知ってもらおうという話になりました。
Slackにはreacji (リアク字)と呼ばれる機能があり、特定のリアクションが付けられた投稿を自動で別のチャンネルに転送することができます。これを使って、外部に見せても良い投稿をゲストアカウントからも見えるチャンネルに転送するようにすれば良さそうです。
ところが、この機能はSlackのゲストアカウントとの相性が悪いです。(当然といえば当然ですが、) ゲストアカウントからは見えないチャンネルからゲスト用チャンネルにreacjiで転送されたメッセージは、ゲストアカウントからは見えません。
そこで、reacji相当の機能を独自に開発することにしました。
そうしてできたのが、kmc-reacjiです！宗教上の理由によりオープンソースとなっております。
登録された部員が、自分の投稿に特定のリアクションを付けた場合に、全く同じ内容をゲスト用チャンネルに投稿します。テキストだけなく画像も転送されますが、画像はそのまま投稿するのではなく、Gyazo APIを使ってアップロードされた画像のリンクを投稿します。
転送が発生する条件は以下の通りとしました。
kmc-reacjiでは、「誰の投稿をどのチャンネルに転送するか」を src/transfer-rule.ts で管理しており、「システムへの登録」というのはこのファイルに自分のユーザーIDを記入することを指しています。
ここからは詳しい実装についてささっと書いていきたいと思います。ちなみに私は axios でAPIを叩くのが好きなので、有名な node-slack-sdk などは使わず、express でサーバーを立てて axios で Slack APIとGyazo APIを叩いています。
プログラムの全体的な動作は以下のような感じです。
プログラムの本体は src/kmc-reacji.ts で全てです。簡単に紹介します。
まずは express でサーバーを立てます。先頭で response.end(); していますが、これはSlack APIあるあるで、独自のUIを作ってユーザーに選択させる、みたいなものを作るときには3秒以内に応答する必要がある 1 のでそのクセでこう書いています。今回は応答が遅くなっても大丈夫なはずですが、わざわざ遅らせる意味もないので先頭で応答しておきます。
const express = require("express"); const app = express(); app.use(express.json()); app.use(express.urlencoded({ extended: true })); app.post("/", async (request: any, response: any) => { response.end(); // ここから先にプログラムが続く }
次に、転送するメッセージを取得します。絵文字リアクションが押されたメッセージのテキストを取得したいですね、絵文字リアクションイベントにはこの情報は含まれていないので、ts (タイムスタンプ) を使って頑張って取得する必要があります。それをしているのが下の部分です。
絵文字リアクションが押されたメッセージの投稿時間はイベントに含まれているので、この時間の1ms前から1ms後までの間に投稿されたメッセージを検索しています。 正直ここはもうちょっとなんとかしたい。。。
const requestBody = request.body; // 略 const target_channel: string = requestBody.event.item.channel; const target_ts: string = requestBody.event.item.ts; const latestTs = `${target_ts.split(".")[0]}.${Number.parseInt(target_ts.split(".")[1]) + 1}`; const oldestTs = `${target_ts.split(".")[0]}.${Number.parseInt(target_ts.split(".")[1]) - 1}`; const target_message = await axios.get("https://slack.com/api/conversations.history", { headers: { Authorization: `Bearer ${token.slack.user}`, "Content-Type": "application/json", }, params: { channel: target_channel, latest: latestTs, oldest: oldestTs, }, });
さて、次に必要なのは投稿時のアイコンとユーザー名の設定です。Nullish coalescing operator (??・Null合体演算子)、便利ですねー
const profile = target_user_info.data.user.profile; const icon_url: string = profile.image_original ?? profile.image_512 ?? profile.image_192 ?? profile.image_72 ?? profile.image_48 ?? profile.image_32 ?? profile.image_24 ?? ""; const user_name = target_user_info.data.user.name;
ちなみに、ユーザー名やアイコンを個別に設定してメッセージを投稿する場合、chat:write.customize permission を与えた上でBot User OAuth Tokenを使う必要があります。
さて、最後に画像をGyazo APIを使ってアップロードしていきます。ハマりポイントがたくさんあって大変でした。
まず、メッセージに添付された画像のデータを取得するには、url_private に書かれたURLにBot User OAuth Tokenを記載したAuthorizationヘッダを付けてGETリクエストを投げる必要があります。
以下のようにして、添付された全ての画像のデータをArrayBufferで受け取ることができます。(MIME typeがimage/から始まるものを画像と判断しています。)
const images_data: { data: any; mimetype: string }[] = await Promise.all( target_message.data.messages[0].files .filter((x: any) => /image\/.*/.test(x.mimetype)) .map(async (x: any) => { return { data: ( await axios.get(x.url_private, { headers: { Authorization: `Bearer ${token.slack.user}`, }, responseType: "arraybuffer", }) ).data, mimetype: x.mimetype, }; }) );
また、Gyazo APIのUploadを叩く際は、filenameを指定しないと動きません。
かなり適当にfilenameを決めてしまっていますが、とりあえず動くのでﾖｼ!
const gyazo_urls = await Promise.all( images_data.map((x) => { const form = new FormData(); form.append("access_token", token.gyazo); form.append("imagedata", x.data, { filename: `${target_ts}__kmc-reacji`, contentType: x.mimetype, }); return axios.post("https://upload.gyazo.com/api/upload", form); }) );
そんなこんなで完成です！メッセージに添付された画像データを取得するところでかなりハマってしまい、画像の転送が実装されるまでに1ヶ月以上かかってしまいました。。。
App Manifestも置いておきます。(event_subscriptions の request_url は隠しています)
display_information: name: kmc-reacji description: お試し用memoチャンネルにメッセージを転送 background_color: "#008000" features: bot_user: display_name: kmc-reacji always_online: true oauth_config: scopes: user: - channels:history - reactions:read bot: - channels:read - chat:write - chat:write.customize - chat:write.public - users:read settings: event_subscriptions: request_url: https://example.com/ user_events: - reaction_added org_deploy_enabled: false socket_mode_enabled: false token_rotation_enabled: false
継ぎ足しのソースコードで型定義も最悪なので、このあたりはなんとかしたいですね。今度Twitterへの転送機能も付けたいなー。
今年もKMCでは 新入生プロジェクト を開催します。また、今年の Webサービス勉強会 は私が担当します。今回紹介したようなBotの開発やWebサービスの開発に興味のある方は、以下の入部案内を参考にメールやTwitterのDMなどでいつでもご連絡ください。お待ちしております！
実際には、間違って転送してしまった際に転送されたメッセージを消去するための :cancel-transfer: という絵文字リアクションも実装していますが、chat.delete しているだけで大したことは何もないので省略します。
気になる方は 公式ドキュメントのこのあたり を読むと書いてあります。↩
ジェルばんは！ KMC-id: prime, id:PrimeNumber のそすうぽよだよ〜。
みなさん、Pietプログラミングを楽しんでいますか？
知らない人のために解説すると、Pietはドット絵がソースコードのプログラミング言語で、いわゆる「難解プログラミング言語」の一つです。
以下のような「ドット絵」がソースコードになっています！
Pietについてより詳しく知りたい人は以下のスライドを読むのがおすすめです。
www.slideshare.netPietの本家サイト（英語）: DM's Esoteric Programming Languages - Piet
Pietの仕様について、この記事を読むのに必要な部分だけ説明します。
Pietの画像は、内部的に17種の命令から構成された命令列として解釈されます。 Pietでは、実行時にただ一つのスタックを持ち、17種の命令はスタックを操作しつつ入出力や条件分岐を行います*1。
17種の命令はスタックに対する操作の違いにより、以下の通りに分類することができます。
rollは特殊な操作で、
例えば、スタックのサイズが9で、depth=8, count=3のときは次のような操作になります。
Pietにはヒープメモリに相当する概念はありませんが、このroll操作によって自由にスタックを操ることで、チューリング完全な計算能力を得ることができます。
さて、このroll操作を普通の配列上に実装したスタックで実装するとどうなるでしょうか？
当然、配列上のdepth個の要素すべてを移動しなければならないため、少なくともdepthに比例した計算量が必要です。実のところ、rollは配列上で で実現可能です。
簡潔な実装として、列のreverseを3回行って実現する方法があります。先ほどと同じ、depth=8, count=3のときは次のようにして実現できます。
実用上高速な方法はRustの標準ライブラリ実装のコメントを読むとわかりやすいです。 rust/rotate.rs at e1b71feb592ba64805689e2b15b9fa570182c442 · rust-lang/rust · GitHub
さて、スタックを保持するデータ構造を工夫することで、もっと高速にrollを行う方法はないでしょうか？
一つの方法として、平衡二分木を使う方法があります。平衡二分木を順序を持った列を管理するデータ構造だと思うと、以下の操作を行うことができます（はスタックのサイズ）。
スタックに対するpush, popはそれぞれinsert, eraseで実現できます。rollはsplit, concatenateを用いて次のように書くことができます（Rust風疑似コード、とする）
fn roll(tree: Tree, depth: usize, count: usize) { let (left, remain) = tree.split(depth); let (middle, right) = remain.split(count); left.concatenate(right.concatenate(middle)) }
したがって、平衡二分木を用いるとすべての命令をで処理することができます。めでたしめでたし。
ではなく、配列で実装したときと比べて、roll以外の操作がから
に悪化してしまっています。roll以外の命令を頻繁に実行する場合（実際、多くの場合はそうなります）、これはあまり嬉しくありません。
高速なPietの処理系には、さらに効率的なデータ構造が必要です。
今回紹介するデータ構造は id:joisino (KMC-ID: joisino) さんの考案したものです。この記事はjoisinoさんの許諾を得て執筆しています。
roll以外が償却定数時間になっているのが大きなポイントです。また、実用上も高速な実装が可能です。
スタックのtopからt個()を（配列等で実装した）通常のスタックで、残りをsplit/concatenateのできる平衡二分木で管理します。
push, pop 操作で ★ が起こるのは最悪でも 回 push, pop 操作を連続して行うごとなので、これで償却
になります
roll操作において、depthが通常のスタックに収まるほど小さい場合は、配列に対するroll操作のみで完結させることができ実用上高速です。
headに収まるという条件から、であることにも変わりはありません。
あらかじめ実装したものがこちらになります
平衡二分木の実装は赤黒木です。頻繁に木に対する変更を行うこと、rollを厳密（償却ではなく）に保つためには平衡二分木の操作が厳密
である必要があることから選択しました。
赤黒木の実装はlibrary/red-black-tree.cpp at master · ei1333/library · GitHubをもとに、いくらかの変更を施して利用しています。
漸近的計算量の改善だけでなく、実際にも速くなるか確かめたいところです。
比較対象には、配列（のみ）による実装と赤黒木（のみ）による実装を用意しました。
-std=c++17 -O2 -march=native -mtune=native -Wall -Wextraクエリ数Qを10万、30万、100万、300万、1000万と変えて実行時間を計測しました。
Q=1,000,000では他の実装よりも高速になりました！ しかし、Q=100,000では配列実装より遅く、Q=10,000,000では赤黒木実装より遅くなってしまいました。なぜでしょうか？
一般に、平衡二分木は間接参照を多用するため、現代のコンピュータではかなりオーバーヘッドが大きいことが知られています。 一方、配列実装ではメモリに対してシーケンシャルにアクセスするパターンが多いため、性能を出しやすいです。 そのため、漸近的計算量が悪くても、スタックの大きさが小さいうちは配列実装の方が高速になります。 スタックの大きさに応じて赤黒木を併用するかどうかを切り替えると、実用上良いかもしれません*2。
また、そもそも今回導入したデータ構造では全クエリを通しての漸近的計算量を改善するものではないため、赤黒木だけの実装と比べると定数倍勝負になってしまいます。 赤黒木のみの実装と比較すると、push/popの計算コストをrollに押し付けることでpush/popの償却計算量を改善しているため、rollの計算量は定数倍悪化しています。 赤黒木のみとどちらが速いかは、クエリ中のrollの比率によって変わってきます。 実際、rollの比率をベンチマークに用いた1/10から1/20にすると、Q=10,000,000でも赤黒木+配列のハイブリッドの方が赤黒木のみの実装より3割程度高速になりました。
赤黒木の代わりにB+木等を使うと、間接参照のオーバーヘッドを緩和できる可能性があるので、暇があれば試してみたいです（あるいは誰か実装してくれ頼む！）。 あるいは別のデータ構造（フィンガーツリーの亜種とか…？）で、よりよい性能を示すものがあるかもしれないので、それについても調べて（できれば実装もして）みたいです。
ではみなさん、よいPietライフを～！
皆さんごきげんよう、KMC7回生のKMCid:tronです。学生でなくなってしまいました。
さて、本日5月5日よりBoothにて音楽作品集「KMC Music Collection Vol.5」の販売を開始しました。
試聴は上記販売ページ、および以下の試聴動画より可能です。
収録曲には歌詞がついているものもあります。歌詞は付属のPDFでご確認ください。
KMCではパソコンで何かしたい人々を常時募集しています！！個人的にはDTMに興味がある人を特に募集したいです！！！ (※もちろんDTM以外に興味のある人や現在特に何か興味があるわけではない人も歓迎します！！) www.kmc.gr.jp
おはもに～。
id:utgwkk です。最近の京都は夏のような日もあって、計算機にはつらい季節になりつつありますね。
今日は、部員向けWebサービスを部内Kubernetes (以下、k8s) クラスタに移設した話をします。
KMCでは、サークルの部内サーバーでk8sクラスタを運用しています。KMCの部員であれば誰でも自由にアプリケーションをk8sクラスタ上で稼動させることができます。k8sクラスタを構築した経緯や技術的な詳細については、以下の記事をごらんください。
今回移設したWebサービスは、部員向けのイラスト投稿サービス (通称 God Illust Uploader、以下では神ロダと呼びます) です。KMCでは毎年お絵描きプロジェクトという勉強会・練習会を開催しており、課題を提出する場所や、描いたイラストを部員向けにアピールしたりする場所として神ロダが使われています。
移設前の神ロダの構成は以下のようになっています。
全てのソースコードやデータベースは部内のNFS上に設置されており、nginxとPassengerを経由してアプリケーションにリクエストが届く、という構成になっていました。また、部員だけが閲覧できるように前段には部内共通の認証機構が設置されていました*1。
モデルの関係は以下のようになっています。ありていに言えば簡単なpixivみたいなイメージです。
神ロダはしばらく前節のような構成で稼動していましたが、いくつかの課題を抱えていました。
神ロダの以前のデプロイ方法は以下のような流れでした。
git pull するこのうち最後の手順は make コマンドだけで完結するようにしてありますが、それでも自動化がされておらず手間でした。今からCapistranoに入門するのか？ できることならmainブランチの変更を自動でデプロイしてほしい！ と思いつつ月日が過ぎていきます。
言語処理系 (Python) のバージョンを上げるにあたって考慮すべきことがいろいろあります。
以下のような手順書を書いてバージョンアップを実施しましたが、やることが多い!! 異なるバージョンの依存ライブラリをそのまま使えるとは限らないのでvirtualenvを作りなおす必要があるとか、なぜかpoetryが壊れていたので直す*2とか、単にアップデートするだけでは終わらないのが大変です。また、この方法だとダウンタイムが出てしまうので、深夜にこっそりバージョンアップ作業をやっていました。
コンテナ化していたら、言語処理系のバージョンを上げるのはbase imageのtagを書き換えてデプロイするだけで*3完了するはずです。
ここでの依存モジュールとはPythonのライブラリのことではなく、imagemagickやWebP、ネイティブの依存ライブラリなどを指しています。言語処理系のバージョンもとくに管理していない*4ので、ちょっと sudo apt upgrade をかけたら壊れてた、ということもあるかもしれません。半分ぐらいは構成管理をサボっていただけなのですが……。
SQLiteは、MySQLやPostgreSQLなどのRDBMSに比べるとスキーマ変更の制約が強いです。具体的には、インデックスや外部キー制約を追加したあとに ALTER TABLE 句で削除することができません*5。単純な ALTER TABLE 句では実現できないスキーマ変更を反映するには、一度テーブルをコピーして作り直す必要があります。
使っているO/Rマッパー (SQLAlchemy) はSQLite向けのバッチでのマイグレーションに対応していますが、考慮することが増えるのでできるだけシンプルに済ませたいです。部内サービスだから気楽にやってよいはずなのですが、DBスキーマのリファクタリングが気軽にできないとなると困ります。
ここまで述べた課題を抱えつつ神ロダを開発・運用していたのですが、ある日やっていきが発生したので、やっていくことにしました。
まずは移行作戦について考えていきます。
何はともあれ、アプリケーションサーバーが動くDockerイメージがないとk8sクラスタにデプロイできません。したがってDockerfileを書く必要があります。
データベースはこの機にMySQLに移行できるとよいと考えましたが、いったんNFS上のSQLiteのデータベースファイルをマウントした状態で移行して、後からMySQLに差し替える作戦を取りました。一気にいろいろやると切り分けが困難になるので、区切りをつけてからやっていきます。
フロントエンドはいったんNFS上にデプロイする方針で考えていました。ただし後述するように、結局フロントエンド用のDockerイメージを用意する方針に切り替えることになります。振り返ってみると、NFS上にデプロイするためのスクリプトを整える必要がある・フロントエンド用のDockerfileを書くのとどちらが手間か・自動化しやすいか、という点ではDockerイメージを作る方針でよかったと思っています。
まずはアプリケーションが動くDockerfileを用意しました。これはそんなに難しいこともなく、淡々とDockerfileを書いて調整する、を繰り返すだけです。あわせて、Docker Composeを使ってアプリケーションを1コマンドで立ち上げられるように調整しました。
この時点ではアプリケーションサーバーだけなので単なるコマンドラッパーのような感じでしたが、MySQL化するにあたって環境構築をやりやすくしておくのがよいと考えてサクッとやりました。また、早いうちからDocker上で動くアプリケーションを用意しておくことで、Docker環境と手元環境との差異を潰していくことができます。
アプリケーションの設定 (DSNやシークレットなど) は元から環境変数で差し込めるようにしていたので、とくに手間にはなりませんでした。
Dockerfileができたので、ビルドパイプラインを整えていきましょう。GitHub Actionsでのdocker buildにはdocker/build-push-actionを使うのが便利です。push先のコンテナレジストリはGitHub Container Registryを使っています。
Dockerイメージのタグは、FluxCDのImage Update Automationとの兼ね合いから {commit hash}-{ビルド日時} という形式にしています。commitにバージョンのタグを付けたときだけビルドする、という方式も取れますが、そんなにセマンティックにやらなくてもよかろう、ということで楽な方法に倒しました。
- name: Extract metadata (tags, labels) for Docker id: meta uses: docker/metadata-action@v3.6.2 with: images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} tags: | type=raw,value={{sha}}-{{date 'YYYYMMDDHHmmss'}}
アプリケーションサーバーのDockerイメージができたので、デプロイを試せるようになりました。ここからk8s (kustomize) のYAMLをゴリゴリ書いていくことになります。
k8sの公式ドキュメントや部内wikiにYAMLの例があるのですが、イチから書くのは初めてなのでかなり 
id:nonylene さんにレビューしてもらいながらYAMLを整えていきました。最初はお試し用のnamespaceで作って、あとからdefault namespaceに移動する方針にしました。
kustomize自体はk8sのYAMLを生成するツールという感じで、生成されたYAMLが妥当かどうかはデプロイしてみないと分からない場合も多く、何度か書き直してはデプロイし直す、を繰り返しました。id:nonylene さんにk8s-lintというlinterを導入してもらってからは前もってエラーに気づきやすくなったと思います。
こうして試行錯誤して、いろいろなエラーを読み解きまくって、ついにアプリケーションサーバーをk8sクラスタ上にデプロイすることができました。よかったですね。
次はMySQL移行をやっていきます。
手元の開発環境をDocker化してdocker-compose.ymlを書いてあるので、開発環境にDBを追加するのは一瞬です。アプリケーションの実装を精査して、MySQLに移行できるように修正していきます。意図せず自分自身のカラムに外部キー制約を貼ってある*6のを発見して直す、などの地道な活動が行われました……。
いよいよMySQL化の準備ができたので、SQLiteのデータをdumpしてMySQL向けに修正したあと流し込んでいきます。移行手順は SQLite3のデータをdumpしてMySQLに移行する - Qiita を参考にしました。
実際にデータを流し込んでみると、いくつかのタグがユニーク制約違反でINSERTできませんでした。SQLiteでは COLLATION nocase (大文字小文字を区別しない) になっていたカラムが、MySQLでは COLLATION utf8mb4_0900_ai_ci になっており、記号などより多くの文字列の大文字小文字が同一視されるようになっていたためです。ところで「パパ」と「ハハ」が同一視されるのはどう考えてもおかしいと思うのですが、我々はMySQL上で大文字小文字とどのように向き合えばいいのか……。
INSERTできなかったデータは数件だったので、目視確認して既存の別のタグに貼り替えるなどの対応を行いました。
MySQLをk8sクラスタ上にデプロイしたあと、安全のためにk8s上のMySQLからバックアップ (mysqldump) をNFS上に保存するCronJobを書きました。crontab的なものもk8sにあって便利ですね。試運転してみて確かにバックアップができていることを見届けました。
ところで MYSQL_PASSWORD 環境変数の値はsecretに入っており、かつ同じ値をアプリケーションサーバーとDBで流用することを考えました。が、アプリケーションサーバーではDBの接続先をURL形式で指定する必要があるので MYSQL_PASSWORD 環境変数のままだと都合がよくありません。以下のように環境変数を設定してexecするラッパースクリプトを用意しました。
#!/bin/sh
set -e
export DB_URL=mysql+mysqlconnector://${MYSQL_USER}:${MYSQL_PASSWORD}@${MYSQL_HOST}:${MYSQL_PORT}/${MYSQL_DATABASE}
exec "$@"
他の環境変数をもとに環境変数の値を組み立ててセットする、みたいな機能があるとよいのですが、あるんでしょうか？ 誰か教えてください。
お試し用のnamespaceにひと通りデプロイできたので、default namespaceに移動します。基本的にはnamespaceを変えて回ればよいはず……と思ったらSealedSecretが復元できなくなってハマりました。
しばらく悩んでいたのですが、これはSealedSecretのスコープがkustomizeのnamePrefixを考慮したものになっていなかった*7のが原因でした。スコープを namespace-wide に変えたら復元できるようになりました。
namespaceを移動したことでMySQL向けのPersistent Volumeが作り直されてしまい、データがまっさらになりましたが、前段階でDBのバックアップを取っていたのでそれを流し込むだけで済みました。バックアップって便利ですね。
当初はフロントエンドをNFS上にデプロイすることを考えていましたが、ここまでくると全部Docker化してしまうとシンプルになるのでは？？ ということでやりました。
神ロダのフロントエンドはシングルページアプリケーションなので、nginxイメージにnginx.confを書いて、フロントエンドのビルド成果物をCOPYして配信すればOKでした。アプリケーションサーバーに比べるとかなりシンプルに済みました。
GitHub ActionsでDockerイメージをビルドする環境を整えたついでに、テストも走らせるようにしました。PRに対してテストが自動で走ると安心感が段違いですね。
docker-compose.ymlを用意しているのでCIでもそのまま使えばよい気もしますが、せっかくなのでGitHub Actions側にDB用のコンテナを用意します。GitHub Actionsのワークフローで使い捨てのMySQLを利用する（サービスコンテナ） | のりおが思考停止するブログ にあるような手順で用意すればよいですが、コンテナの準備完了を待たずにテストの直前でwait-for-it.shを走らせることで投機実行感を高めました。
このようにして部内k8sクラスタに部員向けWebサービスを移設し、ついでに開発環境やCI/CDパイプラインを整えることができました。部員向けWebサービスとしては初めてのk8s移行だったので、いろいろ調べたり教えてもらったり、足りない設定を整備していったりしつつの作業でなかなか大変でしたが、完成してgit pushするだけで全てがデプロイされる体験はライフチェンジングでした。
また、アプリケーションをコンテナ環境でも動くように実装を修正したり、異なるRDBMS間でデータを移行したりするのはたぶん初めてのことだったので、いろいろ罠を踏み抜くことができたのはよかったと思います。
KMCでは、部内k8sクラスタに部員向けサービスをデプロイしたい部員の方を募集しています。また、今年の新入生プロジェクトにはWebサービスの作り方を学べる勉強会があるようです。気になりますね～。
興味のある方は、以下の入部案内を参考にメールやTwitterのDMなどでいつでもご連絡ください。お待ちしております！
