‫サービスのアップデート 私たちはまだそこにフォーカスしていませんが､ あなたはずっと､ サービスをアップデートする方法があると思い込んでいたのでしょう｡
‫アップデートは蓋を開けてみれば､ いろいろなことが起きているのだから､ それについて話をしよう｡ Swarmのアップデート機能は､ レプリカのローリングアップデートパターンが中心となっています｡
‫つまり､
‫複数のレプリカがあるサービスの場合､ デフォルトでレプリカを1つずつロールバックし､ updateコマンドで指定した新しい設定に置き換えて､
‫それぞれのコンテナを更新します｡
‫多くの人が「オーケストレーターはアップデートのダウンタイムを防ぐ」と言いますが､ 私は「これでダウンタイムを防げる」とは言いません｡
‫ダウンタイムを制限すると言うことです｡ どんなシステムでもダウンタイムを防ぐのがテストの仕事だからです｡
‫アップデートの方法をテストし､ ユーザーに影響を与えないかどうかを判断する必要があります｡
‫データベースを更新すると､ Webアプリケーションに影響があるのでしょうか？ おそらくそうでしょう｡
‫サービスを提供するアプリケーションごとに更新され､ 周囲のものに与える影響も異なります｡
‫それはオーケストレーターの仕事ではありません｡
‫オーケストレーターは､
‫こっちはデータベースのプロトコル､ こっちはRESTアプリケーションのプロトコルなんて簡単には判断できないんです｡
‫そのため､ それらとは異なる複雑な対処が必要になります｡
‫サービスのアップデートの場合､ 単なるREST APIや､ Webソケットやロングポーリングといった派手なことをしないWebフロントエンドであれば､
‫そのような非常にシンプルなものや静的なWebサイトであれば､ おそらく簡単にアップデートでき､ 問題ないでしょう｡
‫しかし､ データベースや永続的なストレージなど､ 永続的な接続を必要とする他のサービスでは......｡
‫というのは､ 何を更新しようとしても､ 常に課題としてつきまとうものです｡
‫だから､ 早めにテストし､ 頻繁にテストする｡
‫先ほども言ったように､ ほとんどのアップデートでコンテナに取って代わることは間違いないでしょう｡ ラベルやその他のメタデータをサービスで更新しない限り､
‫ロールスルーで各コンテナを全く新しいものに変えてしまうのです｡
‫ただ､ それは覚悟の上です｡ オプションも充実しています｡ 実際､ 私が最後に数えたところでは､
‫updateコマンドのオプションは少なくとも77個ありました｡ しかし､ やりたいことはほとんどすべて微調整が可能です｡
‫updateコマンドのオプションの多くは､ 実際には末尾に-rmと-addをつけただけのcreateオプションです｡
‫なぜなら､
‫複数の値に対して使用できるオプション､ 例えば公開するポートや環境変数であれば､ それらはたくさん使用できるからです｡
‫そうだろ？
‫ですから､ どれを追加し､ どれを削除するのか､ アップデートコマンドに指示できるようにする必要があります｡
‫それはすぐにでも確認できます｡
‫これには､ ロールバックやヘルスチェックのオプションも含まれます｡
‫これらのオプションを見て､ そのデフォルト値があなたのアプリケーションにとって理想的でないかどうかを確認し､ 異なる設定をテストして､
‫あなたとあなたのシステムにとってアップデートがより簡単になるかどうかを確認する必要があります｡
‫また､ スケールとロールバックのオプションが独立したコマンドとして用意されていることもおわかりいただけると思います｡
‫以前は--rollbackや-scaleで指定するオプションでしたが､ あまりに多くの人が頻繁に使うので､
‫Dockerはこれらをコマンドラインの一級市民として扱うようになったのです｡
‫今後､ さらに増やしていくかもしれないそうです｡
‫最後に､ いくつかの例に入る前に､ もしあなたがスタックをやっているなら､ 同じスタックへのスタックデプロイはアップデートです｡
‫実際､ スタックアップデートのための独立したオプションは存在しない｡
‫編集した同じファイルでスタックデプロイを行うだけです｡
‫そうすれば､ サービスコマンドやネットワークなど､ あらゆることがうまくいくようになります｡ 変更が必要な場合は､ その変更が適用されるように､
‫彼らと協力することになります｡
‫簡単な例を見てから､ コマンドラインに入りましょう｡
‫こちらは､ サービスのイメージを変えるという､ 一番よく使う例でしょう｡
‫アプリをアップデートして新しいイメージを構築するたびに､ イメージ名､ そしてサービス名を指定して､
‫サービスアップデート・コマンドを実行することになります｡
‫だからこの場合､ もしかしたら私のアプリケーションのタグが1になっていたかもしれません｡ 2. 0.
‫そして､ この場合､ 私は今､ 1を適用しています｡ 2. 1のイメージで､ サービスが､
‫ああ､ これは私のサービスで動いているのとは違うイメージだ､
‫と判断して､ 更新しに行きます｡ 次は､ 1つのupdateコマンドの中で､ 複数のことを同時に行う方法を紹介します｡
‫env-addで環境変数を追加し､ publish -rmでポートを削除することができます｡
‫また､ 同じupdateコマンドで環境変数の追加や削除､ Publish Portの追加もやりたい放題です｡
‫最後の1つは､
‫この新しいスケールコマンドとロールバックコマンドを､ 複数のサービスで同時に使用する方法を示しています｡ updateコマンドと比較すると､
‫複数のサービスに適用できることが利点の一つです｡
‫今回は､ 実はWebサービスとAPIサービスのレプリカの数を同時に変更することにしています｡
‫さっきも言ったけど､ Swarmのアップデートでは､ デプロイコマンドが違うんだよね｡
‫これは同じDockerスタックのデプロイで､ 編集したファイルを使って､ APIの他の部分と連携して､
‫必要な変更があるかどうかを判断し､ サービスの更新でそれをロールアウトするのが仕事です｡
‫わかりました｡ まずは実際にサービスを作って､ 更新コマンドで操作できるようにしましょう｡
‫docker service create -p 8088 80 name web, and we'll use Nginx, and we're going to specify the version like
‫we always should in production.
‫2017年の後半には､ サービスの作成・更新コマンドにデタッチオプションが追加され､ リアルタイムで同期している様子を見ることができるようになったのは良いことです｡
‫ですから､ これはアップデートコマンドにとって､ コマンドラインから実際にどのようにアップデートが展開されるかを確認するのに良いことでしょう｡
‫わかりました｡ ここで､ docker service ls を実行すると､ サービスが稼働していること､
‫1対1のレプリカがあることが確認できるので､ 問題ありません｡
‫では､ サービスをスケールアップして､ より多くのレプリカを使用できるようにしましょう｡ docker service scale
‫Web=5. そして､ そのうちの1台はすでに稼働しており､ 残りの4台はスタートしなければならないのを見ただけでしょう｡
‫私の場合は､
‫すでに画像をダウンロードしていたので､ すぐに終わったのですが､ 他のノードでは画像がダウンロードされるため､ 保留状態のまま数分かかるかもしれません｡
‫わかりました｡
‫そのNginxのイメージを変えて､ ローリングアップデートをしましょう｡
‫ここでは､ 古い画像を選んでいることがおわかりいただけると思います｡
‫さて､ Dockerはイメージが実際にどのようなものであるかは気にしていません｡
‫まったく別のアプリケーションになる可能性もありますから｡
‫ただ､ このサービスでは､ 別の画像に変えていることがわかるだけなんです｡
‫デフォルトでは､ ここを一度に通過することを覚えておいてください｡
‫まずそれを削除し､ 新しいものを作り､ そのものが問題なく､ 健康そうであれば､
‫次のものに取り掛かるというものです｡ 次の例では､ 公開ポートを変更することにします｡
‫しかし､ ポートを変えることはできません｡
‫実際には､ 追加と削除を同時に行う必要があります｡
‫つまり､ 今回の場合､ 最初に8088で公開したため､ docker Service update publish rm
‫8088を行う必要があるのです｡ 値を指定する必要がない｡ キーを指定するだけでいいんです｡ そして､ 新作の「9090」を発表します｡
‫次に値ですが､ この場合は80です｡ 先ほどと同じように更新作業をすることがわかります｡
‫最後の例は､ ヒントのようなものです｡ なぜなら､ リバランスというものにチャレンジすることが多いからです｡
‫また､
‫ノードの数を変えたり､ いろいろなものを移動させたりすると､ スウォーム内にたくさんのコンテナがある場合､ 実際には均等でないことがあります｡ コンテナの実行数がかなり少ないノードもあれば､
‫多いノードもあります｡
‫多くのものを変更する場合､
‫Swarmは使用するリソースの数ですべてのバランスを保つために､ ものを移動させません｡
‫しかし､ そのサービスに何も変更を加えなくても､ 強制的に更新することができます｡
‫そして､ タスクを再発行するのですが､ その際､ 最も使用頻度の低いノードを選ぶので､ リバランスの一種と言えます｡
‫小さなスウォームでは､ 何か大きなものを動かしたり､ ノードをたくさん追加したりすると､ 突然､ 何もしていない空のサーバーがたくさんできて､
‫それに手をつけなければならないことがよくあるんです｡
‫そこで､ サービスの1つか2つを選んで､ docker service update -- forceを実行します｡
‫この場合､ タスクを完全に置き換えてしまうことになります｡
‫もちろん､ スケジュールのデフォルトである､ コンテナ数､ 使用リソース数が最も少ないノードを探すという方法も使われます｡
‫それは､ ノードの作業量にムラがあるのを回避するための仕掛けみたいなものですね｡
‫この講義で作成したサービスを削除することで､ クリーンアップすることを忘れないでください｡