‫サービスを使った秘密について見てきましたが､ 次はスタックを使った秘密を見てみましょう｡ このディレクトリの中に､ secrets sample 2というのがあって､
‫この中にComposeファイルと､
‫それからテキストファイルに格納されている2つのsecretsがあります｡
‫つまり､ 前回の講義と同じようなパスワードとユーザー名ですが､ 今回はこれをすべてComposeファイルに定義しています｡
‫ここでは､ いくつか異なる点があります｡
‫まず､ Composeファイルのバージョンが3である必要があります｡ 1. 秘密を持つためには､ .NETにいる必要があります｡
‫3の1リリース｡
‫だから､ スタックを使うためには3つ必要だったのですが､ シークレットでスタックを使うためには3つ必要なのです｡ 1 以降のもの｡
‫次に､ 一番下にあるroot secretsキーで､ secretを定義します｡
‫Composeファイルでシークレットを行うには､ シークレットごとにファイルを使用する方法と､ シークレットをあらかじめ作成しておく方法の2つがあります｡
‫ここではファイルを使用していますが､
‫他の方法で秘密を作成することもできます｡
‫そして､
‫その下にあるfile:の代わりにexternal:と書いて､ secretsリストの中のsecretの名前にするのです｡
‫Composeファイルに秘密とその場所を伝え､ それを必要とするサービスに実際に割り当てる必要があるのです｡
‫ここで言っているのは､ 私たちの秘密が欲しいコンテナだけが､ 私たちの秘密を手に入れるということですから､
‫これは重要なことです｡ もし､ 複数のサービスが存在する複雑なComposeファイルであれば､ サービスごとに異なるシークレットを設定することができます｡
‫まず､ 下のほうに全部定義して､ 各サービスで具体的に割り当てていくのです｡
‫これは実は､ サービスのもとで秘密を行うための略式､ あるいは簡単な方法と考えられていることをお伝えしておきます｡
‫実際には､ 標準的なLinuxのモードとユーザーIDの構文を使って､ アクセス権や許可されるユーザーなどを定義できる長いフォームがあります｡
‫そのため､ 非 root ユーザーでアプリケーションを実行する場合､ そのユーザーだけがアクセスできるようにこれらの秘密をターゲットにしたいと思うでしょう｡
‫しかし､ この最初の例では､ 簡単のために､ 短い形式を使用するだけです｡
‫必要なのは､ そのファイルを標準的なスタックのデプロイコマンドで使用することだけです｡ では､ docker-composeをデプロイして､
‫これをmydbと呼ぶことにします｡ 先ほどと同じように､ 実際に最初にネットワークが作成されているのがわかると思います｡
‫この場合､ 実際には最初にシークレットを作成し､ その後サービスを作成した｡
‫Docker secretを検索してみると､ この2つが含まれていることがわかります｡ 他のスタックコンポーネントと同じ命名規則に従っており､
‫スタック名とオブジェクト名の順で命名されています｡
‫前回の講義と同じように､ SQLサーバーに飛び込んで実際にそれらのファイルを探しても､
‫以前と同じようにそこにあるはずです｡ ただ､ 今はスタックファイルの中で管理されています｡
‫ここでいいのは､ もし私がスタックを削除したら､ 秘密もきれいに取り除いてくれることです｡ 先ほどの例では､ secretを削除したい場合､ docker
‫secret rmを実行して実際にsecretを削除する必要があったでしょう｡
‫最後に､
‫この例では､ このサーバーでテキストファイルを使用していること､ そして､ ここでは3ノードのswarmについて話していることを念のためお伝えします｡
‫しかし､ 本番環境や自分のローカルマシン以外の場所にいる場合は､ ファイルやbashの履歴ファイルなど､
‫そのホストにある可能性のある場所に秘密を残してはいけません｡
‫それだと､ そもそも秘密があることの意味がなくなってしまいます｡ どのような手順でスウォームに秘密を持ち込むにせよ､
‫秘密が残っていて簡単に手に入れられるようなことがないよう､
‫スウォームでの作業が終わったら後片付けをする必要があるかもしれませんね｡