【ITニュース解説】Bitnami 映像搬家後：漏改 exporter 的坑，以及用原映像加上 pgvector

現代のソフトウェア開発と運用において、アプリケーションを「コンテナ」という形でパッケージ化し、それを「Kubernetes」のようなシステムで管理することは一般的だ。コンテナは、アプリケーションとその実行に必要な環境をひとまとまりにしたもので、どこでも同じように動作することを可能にする。そして、コンテナの実体となる「イメージ」は、「Docker Hub」のような「イメージレジストリ（リポジトリ）」に保存され、必要に応じてそこから取得して利用される。

今回取り上げる事例は、Bitnamiという組織が提供するPostgreSQLやRedisといった人気のデータベースのコンテナイメージをHelmというツールを使ってデプロイする際に直面した課題と、その解決策についてだ。Helmは、Kubernetes上でアプリケーションを簡単にデプロイ・管理するためのツールで、アプリケーションの構成情報やコンテナイメージの指定などが「チャート」と呼ばれるパッケージにまとめられている。

当初、開発者はHelmを使ってPostgreSQLやRedisをデプロイする際、Bitnamiが提供するデフォルトのコンテナイメージを利用していた。このデフォルト設定では、メインのデータベースコンテナだけでなく、データベースの状態を監視するための「metrics exporter」と呼ばれる補助的なコンテナや、データベースの初期設定や権限調整を行うための「初期化コンテナ（init container）」など、複数のコンテナが同時にデプロイされるようになっている。これらは全てBitnamiのイメージリポジトリから取得される。

しかし、ある時Bitnamiがコンテナイメージのリポジトリの場所を変更した。具体的には、以前のイメージが「bitnami/」というリポジトリパスから「bitnamilegacy/」という新しいリポジトリパスへ移行された。この変更に対応するため、開発者はまずメインのPostgreSQLやRedisのイメージが参照するリポジトリを新しい「bitnamilegacy/」に変更した。これで全ての問題が解決したと思い込んでいた。

ところが、後になって問題が発覚した。メインのデータベースコンテナのイメージリポジトリは変更したものの、それに付随するmetrics exporterや初期化コンテナが参照するイメージリポジトリは、古い「bitnami/」のままだったのだ。Bitnamiの公式発表では、「bitnamilegacy/」のリポジトリは過去のイメージを保持するためのもので、もはや更新やサポートはされないと説明されていた。このため、補助的なコンテナが古いリポジトリを参照し続けることは、セキュリティや安定性の面で望ましくなかった。

この問題から得られた重要な教訓は、「Helmチャートの設定ファイル（valuesファイル）を修正したとしても、それがデプロイされるすべてのコンテナのイメージに確実に反映されているとは限らない」ということだ。一つのチャートは複数のイメージを参照することがあり、メインのイメージだけを変更しても、サイドカーコンテナや初期化コンテナのイメージは元の設定のまま残ってしまう可能性がある。

この問題を解決し、将来の同様なミスを防ぐためには、実際に何がデプロイされるのかを事前に確認する作業が不可欠だ。そのために「helm template」というコマンドが役立つ。このコマンドは、指定されたチャートと設定ファイル（valuesファイル）に基づいて、実際にKubernetesに適用されるYAMLファイルを生成する。生成されたYAMLファイルの内容を詳しく確認することで、どのコンテナがどのイメージリポジトリを参照しているのかを正確に把握し、意図しないイメージが使われていないかをチェックできる。今回のケースでは、helm templateで生成されたYAMLを詳細に確認することで、metrics exporterや初期化コンテナのイメージリポジトリが正しく変更されていないことが判明し、設定を修正することができた。

次に直面したのは、別の要件、つまりPostgreSQLに「pgvector」という拡張機能を追加したいというものだった。この機能は、ベクトルデータを扱うためのもので、最近のAIアプリケーションなどで利用されることが多い。当初はBitnamiの公式イメージを使い続けたかったため、Bitnamiが提供するPostgreSQLイメージをベースに、このpgvector拡張機能を組み込んだカスタムイメージを自分でビルドすることにした。これは、全く別のPostgreSQLイメージに切り替えるよりも、変更範囲を最小限に抑えるための賢明な選択だった。

カスタムイメージのビルドには「Dockerマルチステージビルド」という技術が利用された。これは、Dockerfile内で複数のFROMステートメントを使ってビルドプロセスを段階的に分け、最終的なイメージには必要なファイルだけをコピーして含める方法だ。この方法を使うことで、pgvectorのビルドに必要なコンパイラや開発ツールなどを最終的なイメージに残さず、イメージのサイズを小さく保ち、セキュリティリスクを低減できる。

自己ビルドしたイメージは、本番環境に導入する前に徹底的にテストする必要がある。元のPostgreSQLイメージで作成したデータが新しいカスタムイメージで正しく読み込めるか、追加したpgvector拡張機能が期待通りに動作するか、既存のアプリケーションとの互換性があるかなどを、隔離された環境で検証することが重要だ。今回の事例では、新しいテスト用ボリュームを使って検証を行い、拡張機能が有効になり、既存のデータも問題なく読み取れることを確認した。

しかし、自分でイメージをビルドする選択には代償も伴う。自分でビルドしたイメージは、元のBitnami公式イメージのように自動的にセキュリティアップデートを受け取ることはできない。つまり、基盤となるOSやPostgreSQL本体にセキュリティパッチがリリースされても、それをカスタムイメージに適用するには、自分で再度ビルドし直す必要がある。これは、機能の追加と、基盤となる環境の継続的なメンテナンスという二つの異なる責任が、自己ビルドイメージの利用者に課されることを意味する。

短期的には問題を解決できたとしても、長期的な視点で見ると、継続的にメンテナンスされる公式イメージへの移行や、自己ビルドイメージの定期的なセキュリティ更新プロセスを確立することが不可欠となる。今回の経験は、コンテナイメージを扱う際に、設定の細部まで注意を払い、変更の影響範囲を正確に理解し、自己ビルドのメリットとデメリットを認識した上で、長期的な運用計画を立てることの重要性を示している。