‫Docker Composeのコマンドラインを使ってローカルで開発するための秘訣はどうでしょうか｡ 今まではSwarmの話でしたね｡
‫でも､ 自分のマシンに戻ると､ swarmにはなかったDocker Composeがインストールされていますよね？
‫繰り返しになりますが､ Composeは制作ツールではありませんから｡
‫開発用に設計されています｡
‫以前と同じ秘密のサンプルディレクトリにいます｡
‫2つのパスワードファイルと､ swarmにあったDocker Composeファイルがあるのがわかると思います｡ スウォームでないことを証明するために､ docker
‫node lsを実行すると､
‫これはスウォームマネージャーではないことが分かります｡
‫私はスウォームに所属していないので､ スウォームのデータベースにアクセスすることも､ そこに秘密を入れることもできないのです｡
‫では､ 地方創生ではどのように対処すればよいのでしょうか｡
‫理想は､ やはり同じComposeファイルを使用することです｡
‫postgresの環境変数のように､ 同じオブジェクトをそのまま使うことができます｡
‫Dockerは､ テストと開発でこれをうまく機能させる方法を考えなければなりませんでした｡
‫docker compose up -d
‫とした後､ docker compose exec psql とした場合｡ そして､ cat on run secrets psql userを実行すると､
‫どうやって我々の秘密がそこに入ってきたのでしょうか？
‫なぜなら､ データベースがないからです｡
‫さて､ ここでちょっとしたマジックがあることが判明しました｡
‫まあ......魔法ではないんですけどね｡ Composeで実際に起こっていることは､ 安全ではないが､
‫機能するということを､ 裏に隠しているだけなのです｡
‫基本的には､ ハードディスクにある実際のファイルをコンテナに実行時にバインドマウントします｡
‫これは本当に､ バックグラウンドでその特定のファイルで-vを行うだけなのです｡
‫繰り返しになりますが､ これは全く安全ではありませんし､ そうあるべきものでもありません｡
‫この問題を回避するために､ 本番環境と同じプロセス､ 同じ環境変数の秘密情報で開発できるようにしただけで､
‫あとはローカルでもできるようにしただけなのです｡
‫つまり､
‫Swarmと同じように起動スクリプトを使い､ 同じように環境変数をコンテナに取り込んで開発できるようになったのですから､ 素晴らしいことです｡
‫そして､ それが私たちの本当の望みなのです｡
‫本番の環境とできるだけローカルで合わせたい｡
‫これを行うには､ Docker Composeの最新版が必要です｡
‫Docker Compose 11でしか使えないと思います｡
‫シークレットコマンドを使えるようにするための妥協点だと思ったので､
‫カッコイイと思ってもらえたらうれしいです｡
‫今､ 私は､ これがファイルベースの秘密でのみ動作することを指摘します｡
‫お話のあった外付けでは使えません｡
‫Composeファイルをリアルに見てみると､ 私のローカル開発ではファイルベースのものを使わざるを得ませんね｡
‫もし､ 実運用環境で外部ファイルを使用している場合､ 開発用に別のComposeファイルを用意し､
‫ここにfile属性を持たせて､ 同じディレクトリかどこかに､ 開発用の簡単なパスワードを使用したサンプルやダミーファイルを保存する必要があるかもしれません｡