この文書では、整地鯖が提供するサーバー群について、開発者が必要そうな情報をまとめています。
ここでの「開発者」とは、以下のような個人を想定しています。
- 整地鯖に関わる Web サービスを作っている人
- 整地鯖の Minecraft サーバーを開発し、管理まで面倒を見ている人(単発の Pull Request だけにとどまる場合、恐らくそこまで知らなくて良いことが多いはずです)
- これから整地鯖のインフラに関わっていきたいと思っている人
なお、VM の仕組みや Linux の基本的な使い方などはこの文書ではカバーしないため、各自必要とあらば学習をしてください。Kubernetes や Docker に関しても日本語で詳しく書かれたものが世にあるためそちらを参照してください。不明点や追記すべき点についてはこちらの README への追記や Discord での会話などでカバーするものとします。
整地鯖の本番環境は3台のベアメタルマシンで稼働しており、それぞれの上に Proxmox が搭載されています。
ハードウェアの構成については詳しくは説明しませんが、合計するとおよそ <40 core vCPUs、<300GB memory のリソースがあり、ネットワークストレージには 10Gbps の伝送速度をもつ NAS が合計で 7TB 分の SSD を搭載しており、アプリケーションの永続ストレージとして利用できます。
管理の都合上、新しいサービスあるいは Minecraft サーバーを立ち上げる場合、選択肢としては大きく3つ考えることができます。上から順に開発者フレンドリーです。
この方法は、フロントエンドのアプリケーションを TypeScript / JavaScript で作成する場合に最適です。データベースなどをもつ必要がないシンプルなアプリケーションであれば、整地鯖上のリソースを使う必要がなく管理コストがない上記のようなマネージドサービスを使うのが便利でしょう。それぞれのサービスの使い方や違いについては公式ドキュメントに従ってください。
ただし、フロントエンドだとしても「実はフロントエンドは SSR があって尚且つ整地鯖の中にあるコンポーネントやデータベースに直接接続したい」などの要件がある場合、この方法は現実的でない場合があります。次の方法を検討してください。
この方法が最も「汎用的」な方法です。SSR なフロントエンドを置いて CDN を噛ませても良いですし、整地鯖の DB や Minecraft API に接続するのも比較的簡単です。「ほぼ全自動」なデプロイ方法が確立されているので、一度学習コストを挟めばガシガシ新しいアプリケーションを生やすことができますし、基盤側に自分で欲しい機能を拡張することもできます。メトリクスやログを取る仕組みがあるのでそちらを使うこともできます。
この方法を取る場合、次のセクションに進んでやり方を勉強しましょう。
旧来の VM 方式です。独自プラグインを複数含むようなマイクラ鯖を立ち上げる時は現時点で運用方針が定まっているのはこの方法だけなので選択肢に上がります。 鯖自体が増えることも多くはないため、基本的には必要がない限り新しい VM を作ることはないでしょう。そのためこのガイドでも大きくは取り上げないこととします。
Kubernetes 上にアプリケーションをデプロイする際に必要な情報は大きく分けて
- 想定する CPU / メモリー消費量
- アプリケーションのコンテナイメージ取得先(コンテナレジストリの接続情報)
- (Web アプリケーションなら)使いたいポートや FQDN など
- ストレージ永続化必要性の有無
です。Kubernetes では、「この YAML に書かれた通りにアプリケーションを実行し続けてください」と命令を送ることでデプロイが行われます。 そのために書かれる YAML ファイルのことを、マニフェスト(宣言書)と呼びます。具体的には以下のようなファイルを指します。
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80これを Kubernetes クラスターに登録しておくことによって、nginx:1.14.2 のアプリケーションが常に実行され続けるように管理が行われます。例えばアプリケーションが起動に失敗した場合や、接続チェックに失敗した場合などにはコンテナプロセスの再起動あるいは再作成をすることで正常性を担保し、必要とあらば複数起動することで冗長性を確保することもあります。
アプリケーションの設計方針の1つとして「The Twelve-Factor App」と呼ばれる概念があります。ソフトウェア設計の基本の1つであるため、覚えておくようにしましょう。また、それに幾つかの近代的な要素を加えた「Beyond the Twelve-Factor App」もあるため、可能な限り読んでおいてください。特に重要な点を示します
- アプリケーション全体の動作に関わるようなステートを変数のスコープで終わらせない
- システム上必要な構成設定は極力環境変数で管理できるようにする
- Graceful Shutdown やオートスケーリングの足枷にならない作りにする
ほかにも、アプリケーションのパフォーマンスやエラーの状況がわかるような可観測性を意識したり、集計がしやすいフォーマットでアプリケーションログを出力するなど、重要な話は多岐にわたります。
整地鯖の Kubernetes クラスターには Argo CD がインストールされていて、所定の Git リポジトリにマニフェストを登録しておくだけで勝手にデプロイが行われるようになっています。
Argo CD は GitHub SSO を経由して Web 上でも動作を確認できます。こちらの YAML に最初に読み込む Git リポジトリが記されているので確認すると、./seichi-onp-k8s/manifests/seichi-kubernetes/apps/root には Application リソースと AppProject リソースがあります。これが、Argo CD で管理対象に入るリポジトリ及びそのパスを示しています。詳しくは ./seichi-onp-k8s/README.md あたりにも説明があります。
文字だけでは説明が難しい部分もあるので、一旦はマニフェストを書いて Git の所定の場所に配置することと、Argo CD というツールが自動的にデプロイ処理を請け負ってくれることだけ理解しておけば大丈夫です。