コンテナを使う時に忘れてはいけないのがプライベートレジストリ。なぜ忘れてはいけないかというと、コンテナイメージは、いわば誰かが作ったイメージで、それを修正しようとすると、どうしても自分のイメージ保管庫、つまりプライベートレジストリが必要になる。コンテナを単に立てるだけなら要らないかもしれないが、コンテナを使いこなしていくためには絶対必要。お仕着せのイメージ、構成だけで何ができる？
いわば、アルプスの少女ハイジのストーリーに例えると、
- クララが単に立った話
なのか
- アルプスの少女との交流の話
なのかの違い。俗にいうクララが立つのは最終回１つ前。
視聴者はクララが立った（実は、ハイジのセリフではなく、これを言ったのペーターらしい。それに過去に何回か実は立っている）話にお金を払うのか、全体のストーリーに対してお金を払うのか。もし、クララが立ったことだけに満足しているのであれば、それは、もはや
- クララで立った
だけ。そういうのは週末にどこでやっているビジネスにならないITイベントでやって欲しい。
実際、コンテナを使っている人は、下手すると完全エアギャップでやっているので、構築の時点からプライベートレジストリを使っていたりする。一方、ベンダーのデモは、「クララが立った」レベルでいいので、プライベートレジストリまで用意していないことも。それで間に合っても、使う方はプライベートレジストリが絶対あるので、いざ、設計、構築はどうやるんですか？となる。そう、ベンダーに聞いてもイマイチで、それを知っている人を追加費用払って呼んでくるしか無い。（もし居ればだし、もし日本語が通じて会話ができればだし、を祈る限りであるが。）
コンテナのビジネスは、クララが単にたった、クララで立った勢とアルプスの少女ハイジの全体ストーリーを提供、必要とする勢の乖離が起きている気がしてならない。
閑話休題
以下で構築されているのが前提で説明。
https://www.blog.slow-fire.net/2025/02/19/純粋にk3sだけを作る%E3%80%821ip/
Bitnamiのイメージをプライベートレジストリにコピー
実は、k3s環境だと、dockerなどのCLIを入れなくてもk3sに含まれているctrコマンドでPullとPushができちゃう。
DBとWordpressのイメージをPullしてPushする。
REGISTRY=<プライベートレジストリIPアドレス>:5000
ARCH=$(dpkg --print-architecture)
ctr images pull --platform linux/${ARCH} docker.io/bitnami/mariadb:11.4.5-debian-12-r4
ctr images tag docker.io/bitnami/mariadb:11.4.5-debian-12-r4 ${REGISTRY}/bitnami/mariadb:11.4.5-debian-12-r4
ctr images push --platform linux/${ARCH} --plain-http ${REGISTRY}/bitnami/mariadb:11.4.5-debian-12-r4
ctr images rm docker.io/bitnami/mariadb:11.4.5-debian-12-r4
ctr images rm ${REGISTRY}/bitnami/mariadb:11.4.5-debian-12-r4
ctr images pull --platform linux/${ARCH} docker.io/bitnami/wordpress:6.7.2-debian-12-r3
ctr images tag docker.io/bitnami/wordpress:6.7.2-debian-12-r3 ${REGISTRY}/bitnami/wordpress:6.7.2-debian-12-r3
ctr images push --platform linux/${ARCH} --plain-http ${REGISTRY}/bitnami/wordpress:6.7.2-debian-12-r3
ctr images rm docker.io/bitnami/wordpress:6.7.2-debian-12-r3
ctr images rm ${REGISTRY}/bitnami/wordpress:6.7.2-debian-12-r3
ちなみに、このイメージ指定は、「誰が言ったんですか？どこに書いてあったんですか？サポートされますか？」と言う状態なんだが、ちゃんと以下に書いてある。「誰だか知らんけど、ここに書いてあるし、サポートされているはず。」
https://artifacthub.io/packages/helm/bitnami/wordpress
Chartのバージョンとコンテナイメージの名前をコピペしておく。イメージの名前は、Pullするときの名前で必要。
はい。誰が言ったか知らんけど、ここに書いてあるし、サポートされてます。
プライベートレジストリからWordpressをデプロイ
–set global.security.allowInsecureImages=true という設定の追加が必要になった。付けないと展開に失敗する。わかりやすくするために最小限の設定で記載する。
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
WPNAMESPACE=wp-test-deploy
WPHELMVER=24.1.12
helm fetch bitnami/wordpress --version=${WPHELMVER}
helm -n ${WPNAMESPACE} install wp-release wordpress-${WPHELMVER}.tgz --create-namespace \
--set ingress.enabled=true \
--set global.imageRegistry=${REGISTRY} \
--set global.security.allowInsecureImages=true
展開すると、以下の警告が出るが展開されている。
⚠ SECURITY WARNING: Verifying original container images was skipped. Please note this Helm chart was designed, tested, and validated on multiple platforms using a specific set of Bitnami and Tanzu Application Catalog containers. Substituting other containers is likely to cause degraded security and performance, broken chart features, and missing environment variables.
しかし、正しくプライベートレジストリで展開されている。
https://github.com/bitnami/charts/issues/30850 によると、去年の年末から仕様が変わったの様子。知らんかった。まぁ、コンテナのイメージって、セキュリティに気をつけないといけないし、コンテナでイメージのバージョンの固定はナンセンスで、常にアップデートをしたものを起動できる「仕組み」を作ることのほうが重要。プライベートレジストリにあるイメージを使われてしまうとリリース元は管理できないから、自己管理のオプトインをさせたのだと思う。
ちなみに、Helmのチャートも落としてきているが、もしかするとhelmチャートはオンラインでもいけるかも。ただ、完全エアギャップだとやはり、ヘルムチャートも落として置く必要はある。
このWordpressのChartは、結構複雑な構成（例えば、APコンテナのオートスケールとか）で3TierのWebデプロイメントができるので便利。また中身は、まんまWordpressなのでブログのバックアップを簡単にリストアしてデモができる。（ブログのリストアは、アップロード容量を拡張するためにちょっとゴニョが必要だが）
「誰が言ったんですか？どこに書いてあったんですか？サポートされますか？」にある程度、合致するエントリーになったが、「誰が言ったんですか？どこに書いてあったんですか？サポートされますか？」って言っている人って、エビデンスの利用目的が完全に間違っていると思う。