Zenn
🛣️

MinIO S3 virtual hosted style への対応

に公開
S3
MinIO
tech

オブジェクトストレージサービスである AWS S3 がある。平たく言うと、s3://{BUCKET}/{OBJKEY} を指定するとファイルが取得できる。

内部的な表現では http://{ENDPOINT}/{BUCKET}/{OBJKEY} で表現されていた。様々な理由(*1)により http://{BUCKET}.{ENDPOINT}/{OBJKEY} というサブドメインでアクセスできるように発展した。前者を path-style access と呼び、後者を virtual-hosted-style access と呼ぶ。この違いは例えば SigV4 の認証などにも影響を与えるのだが、サードパーティ製の S3 互換ストレージを使う時にたくさん問題が出てくる。

まずは minio をデプロイするケースで考えよう。

minio 本体は virtual-hosted-style に対応している。環境変数MINIO_DOMAIN={ENDPOINT} に設定した上で、サブドメインとして呼び出されることを想定している。path-style でもアクセスできる。

呼び出し元から、名前解決できるようにするのが難しい。

数が限られているなら、それぞれ呼び出し元の hosts ファイルで指定してもよい。

docker compose では aliases で bucket 用の名前を設定できる。マニュアルにはそれと書かれていないけれども、ここにはドットを含めて書くことができる（例）。内部的には docker moby/libnetwork の機能である。docker inspect すると状況が見通しやすい。

$ docker inspect spark2-minio-1 | jq .[].NetworkSettings.Networks.[].DNSNames
[
  "spark2-minio-1",
  "minio",
  "polaris.minio",
  "828900fee499"
]

kubernetes で Ingress で使うDNSの名前空間があれば、自由に接続できるので問題ないだろう。問題は in-cluster での名前解決である。namespace内部でサブドメインを持つ方法で、標準で用意されている方法は pod subdomain を使う方法である。この方法では subdomain を指定した headless Service を作成する。典型的には StatefulSet が使っている。

minio single node でテストする際は、bucketname.subdomain の形が出来上がるように狙って pod 構築できるだろう。

multi node の場合は StatefulSet を使うだろうから、bucket 用の hostname を設定できない。bucket 用の入り口として envoy 等で bucketname.subdomain をいったん受け付けて、それから minio pod に proxy するのが自然だろう。ただし手動で組むのは、手間ではある。operator や helm を使いたくなるに違いない。

minio operator では BucketDNS というフラグが用意されているが、手元ではまだ期待通りには動作させられていない。BucketDNS 自体は、bucket 作成時に sidecar のフックを呼び出して、bucket 名に対応した Service を作成する機能になっている。bucketname から minio.{namespace}.svc.cluster.local へエイリアスする ExternalName Service が作成される。{bucketname}.minio ではなく {bucketname}.{namespace}.svc.cluster.local となる。in-cluster では通常の virtual hosted style にはならない。<bucketname>.minio.namespace.svc.cluster.local にしたかったようにみえる。設計意図と異なるようにみえるのだけれど、どうしたかったのだろう……？

bitnami minio helm chart は特に気にしていない様子で、 virtual hosted style は対応していない。

呼び出し元の問題もある。aws 提供のライブラリは、かなり慎重に移行を薦めようとしているように見える。むしろサードパティ製のライブラリで積極的に virtual hosted sytle に移行してしまった、かつ、path style 非サポートのものもある（例）。一方であるいは "vanity subdomain" と呼んでいるツールもある。

個人的意見としては、「DNS レベルでのルーティングがプログラムから制御しやすくなった」という意味では、「機能の開放」には違いないと考えてはいる。

*1) 経緯については https://aws.amazon.com/jp/blogs/news/amazon-s3-path-deprecation-plan-the-rest-of-the-story/ に詳しい。

参考:

Discussion