※当サイトの記事には、広告・プロモーションが含まれます。

結局のところ、アプリケーションの設定情報ってデプロイ時に解決するしか無さそうね...

nazology.kusuguru.co.jp

電気の流れは普通、電子という粒子が線路のような導線を移動することで起こります。

電子は動かず『電子のスピンだけ』が流れて情報伝達できる微小チップを開発 - ナゾロジー

しかしもし電子がほとんど動かず、「スピン」と呼ばれる性質だけがリレーのように次々と伝わって情報を運ぶとしたら――まるでSFのようだと思うでしょう。

電子は動かず『電子のスピンだけ』が流れて情報伝達できる微小チップを開発 - ナゾロジー

オランダのデルフト工科大学(TU Delft)で行われた最新の研究によって、電子自身ではなく、そのスピンのみが情報を運ぶ『スピン流』を、巨大な磁石を使わず安定的に発生させチップを開発することに成功しました。

電子は動かず『電子のスピンだけ』が流れて情報伝達できる微小チップを開発 - ナゾロジー

⇧ う~む、どのぐらいの距離まで伝達されるのか気になりますな...

まぁ、従来通りの日常的に利用に堪え得る情報伝達を実現となるまでは、時間がかかるとは思いますが...

結局のところ、アプリケーションの設定情報ってデプロイ時に解決するしか無さそうね...

「Git」のような「バージョン管理システム」で「ソースコード」を管理するとなった時に、昨今の「アプリケーション」において、

  1. データベースの認証情報
  2. 外部のREST APIの利用に必要な認証情報

などなど、「認証情報」系が必要になって来ることあるあるだと思うのですが、

www.playframework.com

ベストプラクティス

この秘密鍵にアクセスできる人なら誰でも、望み通りのあらゆるセッションを生成できることになり、望み通りのあらゆるユーザとして簡単にシステムにログインすることができます。このため、アプリケーションシークレットをソース管理システムに登録しないことを強くお勧めします。その代わりに、本番サーバに設定されるべきです。これは、本番のアプリケーションシークレットを application.conf に設定することは悪い習慣と見なされることを意味します。

https://www.playframework.com/documentation/ja/2.4.x/ApplicationSecret

⇧ 上記サイト様にありますように、「バージョン管理システム」で管理すること宜しくないですと。

継続的インテグレーション/継続的デリバリー(CI/CD:Continuous Integration/Continuous Delivery)」のような自動化の仕組みを利用できるような環境であれば、

docs.github.com

⇧ 上記のような機能を利用することもできるのだが、自動化が進んでいないような状況だと、

  1. 環境変数
    1. デプロイ(デリバリ)時に設定する
  2. 共有ファイル
    1. 本番環境用の設定ファイルを配置しておき、デプロイ(デリバリ)時に取得・差し替える

といった方法を取るしか無さそうね...

ちなみに、「Spring Boot」とかは、

spring.io

⇧ 設定ファイル系にハードコーディングしてしまっている...

「セキュリティ」的にどうなのかはさておき、顧客毎に「データベース」の「認証情報」が異なる場合に対応できないので、なかなかに厳しい...

毎回思うのは、公式で提供されている情報なのだから、本番環境で役に立たないサンプルということは注釈で説明を入れておいて欲しいのよね...

誤った知見が拡散されてしまうことになるのよね...

毎度モヤモヤ感が半端ない…

今回はこのへんで。