‫さて､ ここまでで秘密や特徴､ 仕組みなどを説明してきましたが､ 実際に使ってみるとどうでしょう｡
‫3ノードのスウォームを先ほどと同じようにセットアップしています｡
‫レポにあるsecrets
‫sample 1のディレクトリにいます｡
‫そして､ 入っているのは1つのテキストファイルだけです｡ そして､ そのテキストファイルには､ 単なるユーザー名であって､ 実はパスワードすらないのです｡
‫実際にSwarmの中で秘密を作るには､ 2つの方法があるんだ｡
‫そして､ その1つはファイルを与えることであり､ もう1つはコマンドラインで値を渡すことである｡
‫では､ まずこのファイルを使ってみましょう｡ docker secret create. そして､ 秘密のデータベースで名前をつける必要があるんです｡
‫そして､ これをpsqlユーザーと呼ぶことにします｡
‫当然ながら､ ファイルと同じ名前である必要はありません｡ でも､ それはそれでいいんです｡
‫そして... 他のオブジェクトの場合と同様に､ IDを吐き出します｡ そして､ もう1つ作りましょう｡ 実際にパスワードを入れてみましょう｡
‫そして今回は､ 実際にコマンドラインからエコーしてみます｡
‫何をやっているかというと､ 実はコマンドラインでechoを使ってパスワードを入力し､ それをcreationコマンドにechoしているのです｡
‫最後のダッシュは､ 標準入力から読み込むように指示していることに注意してください｡ これはechoコマンドで与えているものです｡
‫さて､ この2つには欠点があると言わざるを得ません｡
‫1つ目は､ 実際にホスト上のサーバーのハードディスクにパスワードを保存していることです｡
‫そして､ それは本当にしたくないことなのです｡
‫つまり､ 自分のマシンのそのローカルなコマンドラインから､ リモートAPIを使うことになるのかもしれません｡ そして､ その方法でファイルを渡すのです｡
‫そして､ 2つ目は､ 実際にルートユーザーのBashファイルの履歴にアクセスしています｡
‫つまり､ 技術的には､ もし誰かがrootに入ることができれば､ 実際にこのパスワードを取り出すことができるわけです｡
‫自社で生産システムを扱う場合､ この2つの潜在的なセキュリティ上の懸念を回避するための様々な方法を検討する必要があります｡
‫つまり､ ここにあるのは...｡ 今､ docker secrets ls を実行すると､ その中に両方があることがわかります｡
‫今､ 私は実際に検査することができますが､ 私は決してパスワードや実際の秘密を見るつもりはありません｡
‫では､ ユーザーをやらせてください｡
‫情報が出てこないんですよね｡ だって､ こんなに簡単に情報が手に入るなら､ 本当はそんなに秘密でもなんでもないでしょう｡
‫そうだろ？
‫つまり､ ここで目指すのは､ 一度システムに入れた秘密は､ データベースに保存されることです｡ そして､ 解読された秘密にアクセスできるのは､
‫それを割り当てたコンテナやサービスだけになります｡
‫では､ 今からそれをやってみましょう｡
‫手動でサービスを作ってみる｡
‫docker service create. psqlと呼ぶことにします｡ そして､ その秘密をマップ化するのです｡ 基本的に､ このcreateコマンドは､ この特定の名前と呼ばれるこの秘密を取るように言っています...
‫シークレットのIDも使えるし・・・｡ を作成し､ それをこのサービスに割り当てることで､ このサービス内のすべてのコンテナにこの秘密が表示されるようにします｡
‫わかりました｡
‫そして､ そこにユーザーを入れて､ パスワードのためにもう一度やらなければならないのです｡
‫なるほど｡
‫つまり､ コンテナ内のファイルとして表示されるように､ サービスに秘密をマッピングしているのです｡
‫しかし､ このイメージから作成するpostgresデータベースには､ これらの秘密をどのように使用するかは教えてくれません｡
‫そこで､ 通常は画像の構成に手を加える必要があります｡
‫そして今回は､ Docker Hubの公式イメージでは､ 環境変数を使うという規格に落ち着きました｡
‫しかし､
‫postgresのパスワードのようなものを渡す代わりに､ ファイルで使用するのは難しいでしょう｡
‫実際にファイルを環境変数にキャットアウトしなければならないので､ ちょっと面倒なんです｡
‫だから､ ファイルを指定すれば...という規格になっているんです｡ と､ これが道筋になるのだろう...｡ ということは､ ランシークレット､ そして名前ということになりますよね？
‫そこでpsql pass､ シークレットという名前になります｡
‫そうすると､ 実は画像の起動時に､ この環境変数が記入されているかどうかを調べることになるんです｡
‫そして､ もしそうなら､ そのファイルを取り込んで､ 環境変数に格納します｡ そのファイルの実際の内容｡
‫これは､ ファイルの中にある秘密を消費する実に簡単な方法なのです｡
‫しかし､ 使用する画像にはこの規格が必要だということです｡
‫また､ ユーザーに対しても同じことをすることができます｡
‫これで納得してもらえるといいのですが｡ サービスを作成すると､ 新しいコンテナのスケジューリング要求を発行するときに行う典型的なことを行うつもりです｡
‫Postgresデータベースを1つ作成し､ その2つの秘密の場所に関する環境変数を渡します｡
‫そして､ tempfsの中で､ 実際にファイルのように見えるものをマッピングすることになります｡
‫しかし､ 繰り返しになりますが､ これは本当にただのRAMファイルシステムかtmpfsなのです｡
‫何が見えるか､ 見に行こう｡
‫そこで､ docker service ps psqlを実行すると､ どのノードで実行されているかがわかるはずです｡
‫さて､ このノードで実行中です｡
‫コンテナの中を見るためにexecを実行してみましょう｡
‫docker exec -it.
‫そして､ そのサービスの特定のコンテナ名､ そしてbashです｡
‫わかりました｡
‫これで､ run secretsでlsを実行すると､ 2つのファイルがあることがわかるはずです｡
‫そして､ psql userでcatをすると､ 値が表示されます｡ うまくいった｡
‫そして､ そのpsqlのログを見れば､ 実際に動作していることがわかるのです｡ だって､ そうでなかったら... もしこれらのファイルがなければ､
‫実際のデータベースは再作成され続け､ データベースを作成するためのパスワードとユーザー名がないため､
‫動作しないことになります｡
‫もう一度docker service psを実行すると､ データベースのシナリオで正しく動作していない場合､ 実際にデータベースが失敗していることがわかります｡
‫そして､
‫再起動を繰り返し､ ここに新しいコンテナが作成されるのを見ることができるのです｡
‫そこで､ 実際にそこに割り当てたので､ 実際にdocker service updateを使ってsecretを削除することができます｡
‫そこで､ docker service update --secret-rm.
‫secret-addもあります｡ しかし､ これらの秘密の1つを削除すると､ 実際に起こることは､
‫コンテナを再展開することです｡ なぜなら､ 秘密はサービスの不変の設計の一部であるからです｡
‫コンテナ内の何かをサービスのために変更する必要がある場合､ サービスはコンテナ内に入り込んで何かを変更することはないでしょう｡
‫実際にコンテナを停止して､ 新しいコンテナを再展開します｡
‫もちろん､ それはデータベースにとって理想的ではありません｡ ですから､ データベースのパスワードをどのように更新するか､
‫別のプランを考える必要がありそうです｡
‫それについては､ また後日お話します｡
‫とりあえず､ 既存のサービスに削除や追加をすることができることだけは知っておいてほしいです｡
‫それをやるとコンテナが再作成されるだけです｡