‫だから､ 発表はもういい｡
‫私のNodeから､ 力を入れて取り組んでいるトピックに迫りたいと思います｡ jsコースです｡
‫アプリの中で環境変数を扱っていて､ 環境変数に対して最適な方法をとっているかどうかよくわからないけど､
‫もっと簡単な方法がいいという場合､ チャットで手を挙げるようにすると､ コロンと手を振ってくれるんだ｡
‫というのも､ 私はかなり長い間､ そのことで悩んでいたからです｡
‫つまり､ コンテナだけでなく､ 分散コンピューティング全般において､ すべてのアプリが少なくとも一貫した方法で環境変数を扱えるようにすることです｡
‫サーバーのDNSの名前とか､ サーバーの秘密とか､
‫そういうのを全部コンテナに取り込むんです｡
‫ということで､ このテーマに興味を持たれた方が何人かいらっしゃるようですね｡
‫だから､ これは私のノードの一部となる｡ jsコースです｡
‫そして､ その一部を取り出して､ Webに情報を公開する方法を考えようと思っています｡
‫その方法はいくつかありますが､ 基本は12ファクターアプリからです｡
‫分散型アプリをより成功させる12の要素というコンセプトで､
‫クラウドやインターネットにおいて､ いかにアプリのさまざまなポイントを管理する必要があるか､
‫また､ 分散型アプリを書くためのベストプラクティスについて､ いかにさまざまな懸念を知る必要があるかを､
‫早くから学んでいた企業が考案したものです｡
‫あるサーバにデータベースがあって､ こっちにAPIがあって､ こっちにWebサイトがあって､ あっちにワーカージョブがあるとしたら､
‫それは分散アプリと言えるでしょう｡ 分散アプリの定義はいろいろありますが､ 一般に､
‫今日の私たちのほとんどは､ コンテナに関心があって､ それが仕事の一部で､ サーバで実行しているなら､
‫おそらく何らかの分散アプリを扱っているはずです｡
‫そこで面白いのが､ コンフィグ状態です｡
‫12ファクター・ドット・ネットに戻り､ これをチャットに放り込めば､ 後でざっと目を通してから､
‫アプリでそれを扱う必要があるときに各トピックに飛び込むことができるのは間違いありません｡
‫しかし､ 今日お話したいのはconfigで､ configは環境の設定を保存するためのものです｡
‫私のドッグコースやマスターコースを受講されている方はご存知だと思いますが､ イメージやアプリ自体に､
‫環境ごとに異なるハードコードされた設定をしてはいけません｡ 環境とは､ 開発テストサーバー､
‫ステージングサーバー､ 本番サーバー､ あるいは多くの方のように複数のレベルの本番環境や本番の複数のコピーといったマシンのことを指します｡
‫そこに､ Javaのメモリ設定や､ APIのパスワードが異なるような変更があるかもしれない｡
‫クラウドのストレージキーとなる可能性のあるさまざまなキー｡
‫例えば､ アプリの中で､ システムのどの部分にいるのかを示す小さなフラグを､ 簡単な環境変数に設定する必要があるかもしれません｡
‫12ファクターのルールの1つは､ 設定とコードの分離を厳密に行うことです｡
‫アプリは常にデータベースと同じサーバーで実行されるため､
‫ローカルホストのようなハードコードされた値を設定することは､
‫誰もが経験していることでしょう｡
‫なぜなら､ 環境が変わるとコードを変更しなければならないので､
‫そうしたくないからです｡
‫12因子アプリは､ 12因子の原則に従っていれば､
‫コンテナにするのは非常に簡単です｡
‫なぜかというと､ どのOS､ どのシステムもすべてその権利をサポートしているからです｡
‫こちらにJavaアプリがあり､ あちらにはGSMがなく､ こちらにデータベースアプリがあり､ データベースを保存しているMIMがあるとすると､
‫これらすべてをキャッシュします｡
‫それぞれ､ その値を消費する方法が異なるので､ 環境変数が正しい｡
‫起動するために必要な設定｡
‫それらはすべて異なるものです｡
‫それで､ かなりイライラすることがあります｡
‫だから､ すべての間で一貫しているのは環境変数だけなんです｡
‫どのシェルも対応しています｡
‫Windows Mac Linux どれも同じ機能をサポートしています｡
‫環境変数の設定やクリアの仕方が微妙に違うかもしれませんが､ 肝心な値は同じで全て同じです｡
‫そうですね｡
‫これが大前提であり､ ドクターやコンテナのエコシステム全体を通して､ 私たちが標準として採用しているものなのです｡
‫つまり､ 例えばアプリケーションにデモファイルやI and Iなどの設定ファイルがあり､
‫その値を取得する必要がある場合､ 環境変数とアプリに取り込む場所の間に中間層を書かなければならないのです｡
‫そうですね｡
‫そして､ 私の完成度の低いBHPアプリにその実例があります｡
‫GitHubにある私のPSPアプリの画像で､ 文字通りの簡単な例をお見せします｡
‫そして､ 皆さんの質問にお答えします｡
‫この中にあるのはDockerファイルとこの犠牲の上にあるもので､ いろいろありますが､
‫私が注目したいのは､ このレベルアプリではDockerファイルに設定した環境変数のデフォルト値です｡
‫ここで設定する理由と方法は､ デフォルトが制作環境で動作するように設定されていることが望ましいのですが､
‫このデフォルトが制作環境の平均的な値になるのか､ それとも開発環境の平均的な値になるのかは､ あなた次第です｡
‫docker runコマンド､ swarmやCubanネットワークデプロイメント､
‫Ducker compose GMOファイルなど､ 他の方法で設定したものを上書きすることになります｡
‫そうですね｡
‫これらのコマンドを実行する前に､ シェルでこれらを上書きすることもでき､ それらを吸い込むことができます｡
‫また､ Docker composeのようなものを使って､ PSPの世界で実際に動作する規格であるドットEMVファイルをギャンブルに設定することもできます｡
‫このように､ ここにあるものは､ アプリに入るものもあれば､
‫別のファイルに入るものもあります｡ 少し戻って､ 次の部分をお見せしましょう｡
‫つまり､ それらは今､ 画像がビルドされるときにドクターファイルに埋め込まれているのです｡
‫ドクターコンポーズファイルを見るときは､ これがローカル設定に使われることになりますね｡
‫開発をしているときに､ ここを見てみると､ 全部設定しているのと､ どちらかが違う設定をしているのがわかると思います｡
‫嫌なら上書きしなくていいんです｡
‫でも今回は､ 似たようなものを例として選んでいます｡
‫もし､ 画像にあるものを上書きする必要がなければ､ これらの多くをそのままにしておくかもしれません｡
‫そうなんですね｡
‫わかりました｡
‫コンテナ起動時に使用されるように設定します｡
‫そのため､ もし変更したい場合は､ コンテナを再起動する必要があります｡
‫コンテナを正しく削除する必要はないんだ｡
‫ただ､ 再起動が必要でした｡
‫だから､ Dr. そうすると､ 次のステップでは､ ローカルマシンや実稼働環境において､
‫特定のファイルへの書き込みが必要になります｡
‫そうですね｡
‫だから､ 私の子供が私のアプリケーションを起動するとき､ これらの環境変数はどこか別の場所にある必要があるのです｡
‫アプリケーションによっては､ 環境変数に保存しておくわけにはいきません｡
‫レガシーアプリや伝統的なアプリは､ デフォルトで環境変数を参照しないので､ レガシーアプリと呼ぶことにします｡
‫今､ 私が新しいアプリを作るなら､ そのアプリが環境変数を探し､ アプリが使う設定ファイルか何かがあるかもしれませんが､
‫私はそれらを自動的に環境変数で上書きすることを目標とします｡
‫つまり､ このアプリは賢いので､ もし環境変数がなければ､ このファイルにあるデフォルトを使う､
‫と言うことができるのです｡
‫しかし､ すでに環境変数が設定されている場合は､ それを使用することにします｡
‫swarmやCuban netに詳しい方なら､ secretやconfigureに入ると､ ファイル全体を上書きして､
‫パスワードやsecretを個別のファイルとして提供できることがお分かりいただけると思います｡
‫ですから､ アプリにもそれらを意識してもらうとよいでしょう｡
‫しかし､ もし自分のアプリを自分で作っていないなら､ あるいはDocker Hubや公式のオープンソースのものを使っているなら､
‫エントリーポイントのスクリプトを提供することに注目する必要があります｡
‫このスクリプトの実行方法は､ イメージの中で実行させたいエントリーポイントスクリプトを設定し､ それを起動時に実行させるというものです｡
‫これは､ bashスクリプトを使って､ 起動時に暴力的な変数とその他のハードコードされたデータを特定のファイルに書き込むという､
‫非常に単純な例です｡
‫そうですね｡
‫派手である必要はない｡
‫他の方法でも可能ですが､ Dockerの公式イメージにありがちです｡
‫このアプリは定番になりがちです｡
‫わかりました｡
‫この場合､ Dockerファイルかcomposeファイルで設定された環境変数を受け取り､
‫それをここに取り込んで､ ファイルに出力します｡
‫イメージの話です｡
‫これは､ HP FP M設定ファイルを期待するレガシーHPアプリのためで､ この場合､ 各環境に固有の特定の設定値をNPMに設定する必要があります｡
‫これは実際に､ FGMのシステムをどれだけ成長させたいか､ サブプロセスをどれだけ生み出させたいか､ そういうことなんです｡
‫そうですね｡
‫そのため､ 現地開発と生産では異なるでしょう｡ 生産では､ 大きく成長してほしいと思っています｡
‫そうですね｡
‫このように､ レガシーなアプリを使いこなすには､ この部分を変更する必要があります｡
‫今､ 公式の画像でこのようなものを見ることができますが､ それは私が学んでいる多くのものがそうであるからです｡
‫つまり､ 私の続編を見れば､ 彼らがどのようにやっているのかがわかります｡
‫そうですね｡
‫実行時に動的に変化する設定が必要です｡
‫公式のmy sequelのDockerファイルを見て､ 下にスクロールすると､ 環境変数も設定されていますが､ エントリーポイントのスクリプトもあり､
‫それをコピーして特定の場所にリンクさせ､ それをエントリーポイントとして使っていることがわかります｡
‫つまり､ このコマンドは､ CMBを見ることであり､ 実際には見ることができないのです｡
‫CMBは私の続編のためだけのもので､ 技術的にはその前にエントリーポイントがあり､ その後CMTに実行を渡します｡
‫このスクリプトが実行されると､ このスクリプトを見つけるには､
‫一つ上の階層に移動して､ hubを取得し､ この8つのポイントをクリックすると､
‫環境変数が表示されます｡
‫そしてこの中で､ 環境変数を取得して､ アプリで利用できるようにするようなことをします｡
‫実際､ 環境変数の末尾に小さなアンダースコアのファイルを追加すると､ そのファイルにあるものを環境変数に変換してくれるので､
‫APIキーなどの秘密が必要なすべてのアプリケーションにとって素晴らしいことです｡
‫また､ swarm secretやCuban entities secretsを使っている場合､ それらはファイルとして提供されます｡
‫Vaultや他のファイルベースのシステムも使えますが､ コンテナでは物をファイルとして使うことが多く､
‫Linuxでは一般的に物をファイルとして使います｡
‫つまり､ これらを個別のファイルとして渡すわけです｡
‫このちょっとしたシェルスクリプトはオープンソースなので､
‫コピーしてアプリに入れることができます｡ このスクリプトを使って､ テキストファイルから環境変数をコピーして､ それぞれ適切な名前の環境変数に貼り付けます｡
‫そうですね｡
‫また､ 固有の変数が異なる可能性があるため､ アプリを起動するたびに変更されることになります｡
‫そして､ それを書き換える､ そういう仕組みになっているのです｡
‫だから､ できればその手順を理解してほしい｡
‫まだまだたくさんありますよ｡
‫実は､ 「Let me get you real quick」があるんです｡
‫環境変数の扱い方については､ compose it's の記事の中に少しまとめてありますので､
‫こちらもリンクを貼っておきます｡
‫ああ､ これはライリーのサイトの上だ｡
‫そして､ 素敵なブログ記事を書いてあげました｡
‫まあ......いいと思います｡
‫でも､ 嘘をつけというのは､ あなた次第なんですよ｡
‫そして､ 博士について語られています｡ カンポス 特にデベロッパーの場合､ ローカルコンフィグに対応することが多いからです｡
‫コンフィグを自分専用にするにはどうしたらいいのでしょうか｡
‫そのひとつがオーバーライドファイルで､ 残念ながらこのHPの例ではオーバーライドファイルを持っていないのですが､
‫持っているはずです｡
‫それもここに加えるべきことでしょう｡
‫しかし､ ここではそれを牽制する｡
‫O'Reillyのリンクから､
‫3つの異なるものとComposeについて調べてみてください｡
‫Composeは､ 設定の管理や複製された部分の削減にとても役立ちます｡
‫これは本当に時間の節約になります｡ 何度も繰り返す必要がある同じ部分をcomposeファイルの一番上に置いて､
‫これは単なる賭けのようなものですが､ テンプレートにして､ 各サービスに適切なタイミングで挿入することができるのです｡
‫この方法以外にも､ コンポジットファイルの中で環境変数を使う方法など､
‫いろいろなことが書かれているので､ ぜひチェックしてみてください｡
‫マイケルが気に入ってくれるといいのですが｡
‫どうしたんだ､ マイケル｡
‫マイケル・アーレンズの呼びかけで
‫電話をしてください｡
‫そこでこの電話会議は何なんだ｡
‫博士 キャプテン
‫多くの場合､ 環境変数に入れるべきでないもの｡
‫誰を餌にしてるんだ｡
‫質問です｡
‫人々が何を考え出すか見るために｡
‫環境変数に入れるべきでないもの
‫DockerやCuban Entityなどのツールが､ ファイルに秘密を書き込む方法を作った理由の一つは､
‫秘密を環境変数にする必要がないためです｡
‫理想的には､ 自分のアプリを作成して管理する場合､ 環境変数から秘密を守ることです｡
‫環境変数が本質的に安全ではないからではなく､ 環境変数があるとそれを漏らす傾向があるからです｡
‫ログに残るのは､ 設定のどこかで環境変数のダンプを行うか､ あるいはそうしているからでしょう｡
‫もしあなたがP HPが好きでないなら､ P HPのテストコマンドPSP
‫EMVがありますし､ 私はそれがもう何と呼ばれているか入ってきました｡
‫時々エラーが発生すると､ アプリケーションをデバッグに設定してエラーになった場合､ これはドットネットの本当のことなのですが､
‫画面にたくさんのバリエーションが表示され､ 本番モードにロックし忘れたために環境変数が画面上に漏れる可能性があり､ あらゆる種類の環境変数が間違った人の手に渡る可能性があります｡
‫swarmやコミュニティでは､ 環境変数をファイルに保存して､
‫アプリにファイルから取得する方法を教えることができます｡
‫次のステップは､ secretやconfigファイルからアプリが必要とするファイルにそれらを取得することができるかどうかです｡
‫だから､ 環境変数を保存して､ 最終的にファイルに書き出す代わりに､ can figsを使って､
‫configureやsecretやファイルを保存して､ 私の続編やあなたのアプリケーションが必要とするファイルに直接移動させることができるんだ｡
‫そうですね｡
‫だから､ 技術的に環境変数に入ることはない｡
‫だから､ 少なくともサーバー自体にはない｡
‫そうですね｡
‫だから､ その話題は嬉しいですね｡
‫でも､ 環境変数の秘密や､ 基本的に環境に必要なすべてのものとその扱い方については､
‫1つの講座が書けるかもしれませんね｡
‫そうですね｡
‫さらに､ Vaultのようなものを使って､ 秘密のAPIを呼び出すとなると､
‫さらに複雑になりますね｡
‫だから､ 間違いなく､ そこにはたくさんの話があるのです｡
‫そして､ 誰かが彼らが好きな良いリソースを持っている場合は､ 自由に投げてチャットしたり､ 後でYouTubeのビデオのコメントにそれらを投げることを感じる｡
‫それでは､ マイケルさん､ よろしくお願いします｡
‫なぜ､ そうするのか｡
‫Stephen says Would you Ducker file not be in source control but I don't favor having production creds
‫such as user name password and source control.
‫そのため､ これらの値は､ Stevenのドクター・ファイル内のデフォルト値となっています｡
‫そのファイルに本当の機密を書き込むことはないでしょう｡
‫そうですね｡
‫ご覧のように､ この例のように､ ダガーファイルの中のものはすべて例やサンプルにすぎません｡
‫もし､ 単純な数字など､ 設定するだけで済むもので､ 合理的なデフォルトがある場合は､ このようにp
‫p p pとします｡ m. を設定し､ 必要に応じて上書きしてください｡
‫そうすれば､ いちいち手動で設定する必要がありません｡
‫しかし､ 特定のアプリや環境に特有なものについては､ ここにダミーの値を入れています｡
‫コードレポの中でそのようなことをするのは絶対にお勧めできません｡
‫秘密とURLと環境を入れて､ ドメイン名の設定とかを知っているんだ｡
‫わかりました｡
‫そうなんですが､ Duckerのファイル自体はアプリと一緒に入ってしまうんですよね｡
‫ああ､ そこに置いておきたいんだね｡
‫わかりました｡
‫いい質問ですね｡
‫つまり､ 暗号化されていない限り､ アプリがそのようなことを受け入れるなら､ ハッシュ化することができます｡
‫でも､ やっぱり入れておかない｡
‫私は環境設定を別の場所に保存していませんが､ デフォルトは必要です｡
‫Docker composeのコンポジットファイルでは､ ローカルの開発者がそのまま使えるようなデフォルトを設定することが多いですね｡
‫だから､ Docker compose upは彼らにとってはちょうどいいのでしょう｡
‫例えば､ 開発者の秘密が守られるような安全な場所にあるVファイルのドットを､ 他の場所から取得する必要があるかもしれません｡
‫しかし､ 地元の開発者であれば､ 必要なものはすべて地元で揃うのが理想的なので､ それを含めないよう､ 本当に努力しています｡
‫リモートAPIを必要とせず､ サンプルデータなどはローカルマシンに置くことができ､
‫心配するようなシークレットは必要なく､ すべてダミーの値を持っていて､
‫ローカルで購入すればいいのです｡
‫もちろん､ すべてのアプリがそのようなユートピアのようなことができるわけではありません｡
‫そのため､ 実行時に環境変数を設定する方法がたくさんあり､
‫環境変数を別の場所に保存しておいて､ 最後の瞬間に環境変数を通して取り込むことができます｡
‫今日はこのテーマでよかったと思います｡
‫EとVのファイルを実装する最も簡単な方法は何か見てみましょう｡
‫また､ 私の続編のアプリの例も右のように紹介しました｡
‫そして､ このスクリプトを見ると､ EMVファイルがないのです｡
‫これは何のために設計されているかというと､ secretやconfigを使う場合です｡
‫Docker swarmのネイティブなsecretやconfig機能､ config mapやコミュニティでのsecretを使っている場合､
‫これらのファイルから情報を取り出す方法として､ これを使うことができるでしょう｡
‫もし必要なら､ 環境変数に入れる必要はないかもしれませんが､ もし必要なら､ このちょっとしたシェルスクリプトを使って､
‫それを行うことができます｡
‫質問の答えになればいいのですが､ 私ならなりませんね｡
‫特定のファイルを作成する必要はありません｡
‫その通りです｡
‫もし､ swarm secretsがファイルを作ってくれるから､ swarm secretsをどうするかという話なら､ 私のDocker mastery
‫courseをURLでチェックしてみてください｡
‫Brett Fisher dot com slash talkerの説明のところに書いてある｡
‫そこもスウォーム講座でお話ししました｡