【ITニュース解説】Rehosting Bitnami Secure Images with Specific Tags

Bitnamiは、Webサーバーやデータベース、アプリケーションなどの様々なソフトウェアを、開発者がすぐに使える形にパッケージングして提供する企業だ。特に、ソフトウェアとその実行に必要なものがすべて詰め込まれた「コンテナイメージ」という形式でこれらを配布しており、開発者はこのイメージを使うことで、環境構築の手間を大幅に省き、素早くアプリケーションの開発やデプロイを行える。

最近、Bitnamiはこのセキュアなコンテナイメージの提供方法に関するポリシーを更新した。これまでのBitnamiイメージは、例えば「WordPressバージョン6.4.3」のように、具体的なバージョン番号が付けられたものが提供されており、開発者や運用チームは、安定していると確認された特定のバージョンのイメージを選んで利用することができた。

しかし新しいポリシーでは、セキュアなイメージはDocker Hub上の「bitnamisecure」という場所で提供されるが、そこでは常に「latest（最新）」という「タグ」が付けられたイメージしか入手できなくなった。タグとは、コンテナイメージのバージョンや種類を示すラベルのようなものだ。この「latest」タグのイメージは、Bitnamiによって「開発用」と位置づけられており、その中身は予告なく更新される可能性がある。

この変更は、ソフトウェア開発や運用において、いくつかの深刻な問題を引き起こす。 一つ目は、特定のバージョンを選べなくなることだ。開発者は、バグ修正や新機能のために特定のソフトウェアバージョンを使いたい場合が多い。また、本番環境で稼働するシステムでは、一度テストして安定性を確認したバージョンのソフトウェアを使い続けたいのが一般的だ。しかし、「latest」タグしか利用できないということは、開発者が望む特定の安定バージョンを選んで利用することが不可能になる。

二つ目は、システムの「再現性」が失われることだ。再現性とは、いつ、どこでビルドやデプロイを行っても、常に同じ結果が得られることを指す。同じ「latest」タグのイメージであっても、Bitnamiが中身を更新すれば、今日ダウンロードしたものと明日ダウンロードしたものでは内容が異なる可能性がある。これにより、今日正常に動作したものが明日も同じように動作する保証がなくなり、予期せぬエラーや動作の不一致が発生するリスクが高まる。

三つ目は、「CI/CDパイプライン」が不安定になることだ。CI/CDとは、継続的インテグレーション（Continuous Integration）と継続的デプロイメント（Continuous Deployment）の略で、ソフトウェア開発における一連の自動化されたプロセスを指す。コードの変更が自動的にテストされ、問題がなければ本番環境にデプロイされる、といった流れだ。このCI/CDパイプラインは、常に同じ環境でテストが実行されることを前提としているが、「latest」タグのイメージがいつの間にか変わってしまうことで、予期せぬ更新が自動テストに影響を与え、パイプラインが頻繁に失敗する原因となる。

四つ目は、本番システムの信頼性が低下することだ。本番環境で稼働するシステムは、一度安定性を確認したバージョンで固定し、意図しない変更が入らないように管理するのが基本だ。しかし、「latest」タグしか使えないと、アプリケーションのデプロイ時に常に最新版のイメージが使われることになり、まだ十分にテストされていない変更が本番環境に投入されるリスクが高まる。これにより、システムの安定性や信頼性が損なわれる可能性がある。

これらの問題は、Bitnamiが「セキュア」と謳うイメージであっても、実用上は非常に不安定で、予測可能なビルドや制御されたアップグレード、長期的なメンテナンスが必要なシステムには適さないことを意味している。

これらの問題に対処するために、「bitnami-secure-hosting」というGitHubリポジトリが開発された。このリポジトリの目的は、Bitnamiが「latest」タグのイメージをどのように作成しているかを分析し、その情報を使って、それぞれのセキュアなイメージに具体的なバージョン番号を付けてタグ付けし直すことだ。これにより、各イメージをデプロイ前に制御された環境でテストできるようになり、開発チームが「latest」タグという常に変化する名前に依存することなく、Bitnamiイメージを安全に使い続けられるようにすることを目指している。結果として、本番環境でのリスクを低減できる。

この「bitnami-secure-hosting」リポジトリは、以下の方法で問題を解決する。 まず、Bitnamiの公式セキュアレジストリ（docker.io/bitnamisecure）から、最新のセキュアイメージを定期的に取得する。レジストリとは、コンテナイメージを保存・配布する場所のことだ。 次に、取得したイメージの中身を詳しく調べ、「APP_VERSION」のような情報から、そのイメージがどの製品（例えばWordPress）のどのバージョン（例えば6.4.3）に対応しているかを見つけ出す。 そして、特定した製品バージョン情報に基づいて、イメージに適切なタグを付け直す。例えば、「latest」という漠然としたタグではなく、「wordpress-6.4.3」のように具体的なバージョン情報を含むタグを付与する。 最終的に、タグ付けし直したイメージを、開発者自身が管理するコンテナレジストリ（デフォルトではghcr.io/vaggeliskls）にアップロードする。これにより、開発チームは、安定性が確保された、具体的なバージョンが明記されたイメージに安全かつ予測可能にアクセスできるようになる。 この一連のプロセスは自動化されており、手動での介入なしに、イメージが常に最新の状態に保たれ、安全に利用できるようになっている。

具体的には、

1. Bitnamiの公式セキュアレジストリからコンテナイメージをダウンロードする。
2. ダウンロードしたイメージを解析し、そのイメージがどの製品のどのバージョンであるかを特定する。
3. 特定したバージョン情報に基づいて、イメージに新しいタグ（バージョン番号付きのタグ）を付ける。
4. 新しいタグが付いたイメージを、開発者が自分で管理するコンテナレジストリにアップロードし、安全に利用できるようにする。
5. このプロセスは自動で定期的に実行されるため、開発者が利用するレジストリ内のイメージは常に最新の状態に保たれる。

この記事の筆者は、Bitnamiの新しいアプローチは本番環境での利用には適さないと明確に述べている。Bitnami自身も「無料のセキュアイメージは開発用である」と説明している点がその根拠だ。 筆者はこのポリシー変更を、オープンソースコミュニティ全体にとって後退であると見ている。過去にもDockerが有料の「強化版イメージ」を導入した際に同様の懸念が浮上した経緯があるからだ。 筆者は、今回の変更が、Bitnamiが提供する無料の公式パブリックイメージの更新頻度やセキュリティへの注力が今後どうなるのか、あるいは有料ソリューションが優先され、コミュニティ向けの無料版が停滞するのではないか、といった疑問を抱いている。 Bitnamiイメージ自体の代替手段は存在しないわけではないが、問題の本質はもっと深いところにあると筆者は指摘している。 現代のITインフラで広く使われている「Kubernetes」（コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するシステム）、「Helmチャート」（Kubernetesアプリケーションを管理するためのパッケージマネージャー）、そしてCI/CDワークフローは、すべて予測可能で、しっかりとバージョン管理されたコンテナイメージに強く依存している。 これらの基盤が、イメージの予測可能性や信頼性を失うと、特に大規模なシステムでは、アプリケーションの再現性や全体の信頼性が大きく損なわれることになる。 結論として、今回のBitnamiのポリシー変更は、単にコンテナイメージの利用方法が変わるだけでなく、オープンソースの世界における本番環境レベルのデプロイメントに、長期的な課題を生み出すものだ、と筆者は指摘している。