※この記事は、個人技術ブログ CodeArchPedia.com の技術メモ（要約）です。
Kubernetes上でSpring Bootを動かす際、application.yaml内でJDBC URLを環境変数で組み立てようとして見事にハマりました。結論から言うと、YAML内での文字列結合はトラブルの元であり、Kubernetes側の仕組みに任せるのが正解です。
何が起きたか（課題）
- JDBC URLに${SQL_SERVICE_SERVICE_HOST}のような変数を埋め込んでみたものの、期待通りに展開されずアプリケーションが起動しなかった。
- Spring Bootの設定ロード優先順位と、Kubernetes側の環境変数置換処理のタイミングが食い違っていたのが原因。
- 結局、application.yamlの中で無理に文字列を結合しようとすると、設定が固定化されやすくポータビリティが低下するリスクがある。
どう解決したか（概要）
アプリケーション側のYAMLで細工するのではなく、KubernetesのDeployment定義にあるenvセクションで解決しました。
具体的には、Pod定義内で変数を参照する$(VAR_NAME)構文を利用します。これにより、Kubernetesが自動でホスト名を解決して環境変数SPRING_DATASOURCE_URLへ流し込んでくれるため、アプリケーションコードには一切手を加える必要がなくなります。
効果（Before/After）
- Before：application.yamlに環境依存の設定が混ざり、デプロイ先ごとにファイルを分ける必要があった。
- After：アプリケーション側のコードを変更することなく、Deploymentの記述だけで接続先を柔軟に制御できるようになった。
- 設定の外部化が徹底されたため、SecretやConfigMapとの連携も非常にスムーズに進むようになった。
🚀 詳細な設定とコードはこちら
具体的なDeploymentのYAML全文や、Spring Cloud Kubernetesを併用する場合のTipsなどは元のブログで公開しています。
👉 【K8s/SpringBoot】application.yamlで環境変数を連結するな！堅牢な設定のベストプラクティス