search

botan-party / gretel

Minecraft Spigot サーバを運用するための実行環境
MIT License
0 stars 1 forks source link

実行環境の見直し #22

Closed shokkunrf closed 2 years ago

shokkunrf commented 2 years ago

EC2 AmazonLinux2への依存が強いため、オンプレや他のVPSなどで実行するのが面倒

今後の方向性として、MinecraftのバージョンごとにDocker Imageを配布したい

usagiga commented 2 years ago

いくつかの点で Docker イメージの配布は難しいように思います。

TL;DR

Dockerfile / docker-compose.yml を配布しましょう。

課題

EULA

EULA に以下の記載があります。

https://account.mojang.com/documents/minecraft_eula

お客様は、当社ゲームを購入している場合、当社ゲームを自由に扱い、修正データ、ツール、またはプラグイン (以下総称して「Mod」といいます) を追加して変更することができます。「Mod」とは、お客様またはその他のユーザーが作成したオリジナルのものであって、著作権で保護される当社のコードまたはコンテンツの相当部分を含まないものを意味します。 お客様が Mod を Minecraft ソフトウェアと組み合わせた場合、その組み合わせを当社ゲームの「Mod バージョン」といいます。 …… お客様は、当社ゲームまたは当社のソフトウェアの Mod バージョンを頒布することはできません。

我々が提供する Docker イメージは、その内部に Spigot サーバーの jar を持つことになるとは思いますが、 その jar には Mojang 所有のコンテンツも含まれていますので、 EULA に抵触してしまいます。

Dockerfile だったら、我々の著作物だけを配布することになるので、 特に何にも抵触しないと思います。

Spigot のリリースモデル

実は、Minecraft と Spigot のバージョンは1対多で対応しています。 例えば、 MC 1.18.x に対応する Spigot は 3290-3368 の 78 バージョンあります。

我々は↑にあるJSONの更新を何らかの方法で常に追い続ける必要があります。 これ自体は日次バッチとかで回すことになろうと思いますが、それよりも楽な方法があります。 ユーザーが使うタイミングで毎回 docker build してもらうことです。

usagiga commented 2 years ago

次に、ベースイメージの選定ですが、これはDocker 公式の openjdk でよいと思います。

理由

Spigot が要求する Java のバージョン

Spigot はビルドするサーバーのバージョンに応じて、 特定のバージョンの Java を要求してきます。

ここで要求されるのは主に以下のバージョンです。

この中には LTS ではないものも含みます。

これの何が問題なのかというと、distroless のようなセキュアで軽量な Docker イメージではサポートされていない Java が要求されるケースがあることです。 https://github.com/GoogleContainerTools/distroless

若干 attack surface / サイズが大きくなりますが、Docker 公式の OpenJDK イメージは数多くの Java をサポートしつつ、 alpine や slim といった比較的軽量なものが用意されているので、これを使うのが最適解かと思います。 https://github.com/docker-library/docs/blob/master/openjdk/README.md#supported-tags-and-respective-dockerfile-links

aarch64 への対応

EC2 に加え、ECS Fargate でも Graviton2 が使えるようになりました。

https://aws.amazon.com/jp/blogs/news/announcing-aws-graviton2-support-for-aws-fargate-get-up-to-40-better-price-performance-for-your-serverless-containers/

これは従来の x86_64 のプロセッサに比べて性能・価格が優れています。 そうした点で、AWSユーザーを想定すると aarch64 に対応したいところです。

また、 Raspberry Pi 上で動作させるユーザーも意識したいです。

これらの点で、 aarch64 向けのイメージが欲しいと考えています。 openjdk には aarch64( arm64v8 と書かれている) 向けのイメージが存在しています。

shokkunrf commented 2 years ago

e289d2ff023393fe81be2c4ea70f2b6a806d7d6e Minecraft v1.18用のを作ってみました。 OpenJDKのAlpineがaarch64に対応していなかったため、Debian slimを利用しました。

作ってみたのにも関わらず今更の相談ですが、ユーザにDockerfileを選ばせるのではなく、Minecraftのバージョンから自動的にOpenJDKを選ぶようにするのはどうでしょうか？

以下の理由から、Alpineをベースイメージとして、Minecraftのバージョンによって適切なOpenJDKをインストールする形にしてもよいのではないかと考えています

usagiga commented 2 years ago

確かに。

複数の Dockerfile を扱うようなスクリプトを管理するよりも、 OpenJDK をバージョンに合わせてインストールするスクリプトを定義する方が楽なので、 そちらにしましょうか。

debian のパッケージに Java 11 と 17 しかなかったのは盲点でした。 debian のパッケージ管理はかなり厳格で安定志向なので、LTS以外はなくなってしまっているのでしょう。

見たところ alpine は古い Java のパッケージもかなり長くメンテナンスされているようですし、よさそうですね。 alpine:latest を使いましょうか。

shokkunrf commented 2 years ago

確認感謝:pray:

alpine:latestについて、半年に1回バージョンアップするのは面倒ですが、動作保証的な感覚でバージョン固定したほうがよいと考えています Alpineがバージョンアップ時に破壊的変更をしないならlatestでもよいのですが、どうなんですかね？

usagiga commented 2 years ago

そうなんですよね。肝心のopenjdkがcommunityレポジトリにあるので……

Alpine が破壊的変更をしないかというとそういうことはないです。 gretel に影響がありそうなのは、パッケージのバージョンが上がって発生するケースでしょうか。

gretel が依存するパッケージは少ないですが、保守的に倒しますか。

とはいえ、開発者体験を損なうのもつらいところです。 保守的に倒す場合は、向こう半年目処でこの辺りを整備しておきたいなと思っています。