Compose上でMastodonを動かしていたのだが、世の中の流れに合わせてKubernetes上に移動させた。docker-compose.ymlから自動的にKubernetesのマニフェストファイルに変換してくれるコマンドもあるけども、勉強のために手動で1個ずつ置き換えていった。Composeのローカルストレージ上に置いていたPostgreSQLのデータをNFSの共有ディレクトリに移動させた。NFSサーバーでディレクトリを共有する共有ディレクトリ上で新DBを初期化する移行元のDBサーバーでpg_dumpコマンドを用いてデータをエクスポートする新DBでエクスポートしたデータをインポートする同じCPUアーキテクチャ&バージョンであればDBのデータディレクトリをまるごとNFS上に持って行くだけでもデータベース移行出来るのだが、今回はDBバージョンが異なるのと、このタイミングで複数のDBを統合していたのを用途ごとに分割したかったので、上記のようなエクスポート&インポートを用いている。nfsvers=3`にして回避した。※NFSv4のACLベースのアクセス権の考え方に引っかかっていた模様。NFSv3まではrwxビットだけなので。/mnt/tank/share/nfs/k8s/postgres-mstdnblue-dataPV/PVCを作るNFSv3の共有ディレクトリをPodに引き渡すためのPVCであるが、大規模環境だとサイズや速度などで階層化しつつ均一なボリュームをまとめて作って適切にPVCで引きこむような設計をすると想像する。(その方がストレージ設計者とコンピューティングリソースの提供者の役割分担がはっきりしやすい&下のレイヤーを隠蔽しやすい)ただ、今回の個人用の環境だとどこにどのデータがあるかはっきりしたほうが良いので、NFSディレクトリの名前とannotationsを1対1で対応させてどのPVがどういうデータを持っていて、それをどのPVCで引きこむのか分かりやすいようにしている。名前でストレージ領域の用途が分かりやすくしたPV名前が体を表す的なPVC複数のテナントが相乗りするような環境だとPVが再利用されないようにしたり、データの隠匿/暗号化/リサイクル時の確実な消去なども求められるだろうなとも思ったがスルー。Redisの移行を考えるMastodonのRedis上には他の連合(フェデレーション)を結んでいるサーバーとのトゥートの伝搬等のキューイング情報やジョブ実行状態、ユーザーが最初にアクセスしたときのホームタイムラインなどのキャッシュが保持されている。今回は御一人様インスタンスでキャッシュやジョブ状態は飛んでしまって構わないとしたので、Redisの情報は引き継いでいかないことにした。Composeだとini形式(変数名=値が並んだテキストファイル)で各種プロセスに引き渡す環境変数を持っていたが、KubernetesだとConfigMapなりSecretなりにする必要がある。地道にYAML形式に書き直すことも考えたが、面倒くさかったのでいい手がないか調べたらこんな手順が。--from-env-file=sample.ini上記のコマンドを使ってConfigMapを作成したらenvFromでPodに引き渡すことが出来る。付きの環境変数として読み込むことができようになりました。(envFrom)https://qiita.com/tkusumi/items/cf7b096972bfa2810800Mastodonの各種プロセスを起動するSidekiq/Streaming/Webのセットはほとんど一緒で、/mastodon/public/systemを共有しながら、bundleなりnodeでプログラムが動いている感じの構成になる。DeploymentでNFS上のボリュームをマウントしたPodを起動して、外部公開するWebsocketなりHTTPなりのサービスエンドポイントをServiceとして定義してやれば良い。あたりに管理者の分担や責任分界線が出てきそう。それ以外はプロセスの種類ごとに分けてはみたものの、Serviceあたりでアプリケーションエンジニアとネットワークエンジニアの縄張り争いが出そうだなとも思った。マニフェストファイルの分け方には流儀があると感じたまとめKubernetes環境にアプリケーションを持って行くとしたら、元々Docker前提で綺麗に分かれているものでもそれなりに技量がいる。レガシーなアプリケーションを持ち込むとしたら作り直した方が早いという言説にも頷ける。AWS上のALBから、自宅環境のKubernetesクラスターまでトラフィックを持ち込んでいるところはこの記事では省略したがTailscaleを使っていたりする。今回のサーバにはVPN接続を受け付けるNICと、実際に内部でアクセスするためのNICの2つが接続されています。そのため、他のブログなどで書かれているようなブリッジ接続は実施していません。/usr/local/vpnserver/SoftEtherの自動起動設定softetherをubuntu18.04にインストールするhttps://qiita.com/rimksky/items/e169f9af83ce472b4ce3のページを参考にさせて頂きました。vpnserver.serviceSoftEtherのVPNサービスのセットアップWindows機にSoftEtherの管理ツールを導入して、そこからGUIで設定しています。初回ログイン時は管理者パスワードの設定を求められる以外は、後は初期セットアップウィザードで設定して回ればOK。80番ポートが空いていたのでstandaloneモードでCertbot自身が一時的にHTTPアクセスを受け付けてホスト名を検証する方式で設定します。imksoo@lainhv01:~$上記でサーバ証明書には複数のドメイン名を持たせるため、certbotコマンドの中でカンマ区切りで複数指定しています。SoftEtherが利用するサーバ証明書の更新を定期的に実施するUbuntuのCertbotが定期的にSSL証明書の更新をするやり方をパクりました。SystemdでTimer実行します。PrivateTmp=true後はTimerとServiceを有効化して実行しておきます。dashboardダッシュボードに外部からの通信を転送(port-forward)するコマンドを実行する。付けてバックグラウンドで実行させておく。&ログイン用のトークン文字列を取得する。アクセスするとログイン画面が出てくる。(プロトコルはhttps、ポート番号はport-forwardで指定した10443番などの数字)トークン文字列はかなり長いので途切れないように気を付けてコピペする。ログイン出来たらKubernetesの画面が表示される。