Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

半日でわかる コンテナー技術 (入門編)

2,379 views

Published on

WebブラウザーとAzureで 手を動かして学ぶ
(Azure CLI acrbuildext extensionの廃止タイミングと重なり、スライドの手順では動きません。スクリプトはGitHub上のものを優先してください)

Published in: Technology

半日でわかる コンテナー技術 (入門編)

  1. 1. 半日でわかる コンテナー技術 (入門編) 真壁 徹 日本マイクロソフト株式会社 クラウドソリューションアーキテクト 2018/10/24 WebブラウザーとAzureで 手を動かして学ぶ
  2. 2. 自己紹介 { “名前” : “真壁 徹(まかべ とおる)”, “所属” : “日本マイクロソフト株式会社”, “役割” : “クラウド ソリューションアーキテクト”, “経歴” : “大和総研 → HP Enterprise”, “特技” : “クラウド & オープンソース”, “資格” : “CNCF Certified Kubernetes Admin.”, “Twitter” : “@tmak_tw” }
  3. 3. アジェンダ コンセプト説明と作業環境の確認 コンテナー技術 基礎知識 アプリケーションのコンテナー化 さまざまなコンテナー実行基盤 Q&A
  4. 4. コンセプト この半日の
  5. 5. コンテナー技術を学びたい、でも 環境が先か、体験が先か 端末にソフト導入の自由度とそれなりのスペックを要求される (Docker for Windows/Mac、仮想化、メモリ量、etc) 企業で貸与されている端末で動かないケースも多い 必要であれば端末購入を申請したいが、説得材料に欠ける コンテナー技術が自らの課題に効果的かどうか、体験、実感したい 気軽にコンテナー技術を試せる機会があれば…
  6. 6. おまかせください WebブラウザーとAzureのみで 体験しましょう Azureの利用権と対応するWebブラウザーがあればOKです Azure Cloud Shellとコンテナー技術対応サービスを活用します コンテナー技術のコンセプトや動作、開発の流れを体験できます 利点や効果を実感できたら、端末など環境整備をご検討ください (現時点ではまだ、端末上での開発が効率的です)
  7. 7. 環境確認 手を動かす前に
  8. 8. ご確認ください サポートするWebブラウザー、Azureサブスクリプションと権限 Azure Portal でサポートされるブラウザーとデバイス Azureポータルにログインし、Cloud Shell を起動してください リソースグループ作成権限の有無を確認してください (az group create –n mytest –l japaneast) ※サブスクリプション所有者か共同作成者であれば確実 ポータル 上部の、ここ 対象: サブスクリプション持ち込みの方
  9. 9. もしもの時は ハンズオンを進められない場合は 権限が足りなかったり、管理者が各種機能を無効化している場合は Azureの無料アカウントを作成する もしくは、 Microsoft Learnで自習 (ラーニング パス: Azureでコンテナーを管理する) 対象: サブスクリプション持ち込みの方 2018/9末のMicrosoft Igniteで発表された自習サイト 保有サブスクリプションに影響を与えない「サンドボックス」で演習可能 コンテナーの他にも多様なテーマ、ラーニングパスあり
  10. 10. コンテナー技術 基礎知識 第1部
  11. 11. 実はすでにコンテナーを動かしていました Azure Cloud Shellはコンテナーを使っている 20秒程度で起動 ブラウザーがあれば使える $HOME以下はAzure Filesに永続化される 利用料金はAzure Files利用量に対してのみ
  12. 12. Azure Cloud Shellの仕組み フロントエンドはJavaScript ブラウザにXterm.jsがロードされる Ubuntuコンテナーを生成 ユーザーごとにひとつのコンテナー コンテナーイメージはユーザー共通 20分間無操作だと破棄される 永続化領域はAzure Filesへ $HOMEの下が永続化される ブラウザ ブラウザ ユーザーコンテナー Azure Files Xterm.js Xterm.js コンテナーイメージ (Ubuntu 16.04 & Tools)
  13. 13. 起動してすぐ、多様なCLIツールを使える インストールする必要なし Docker CLI/Docker Machine Kubectl Helm DC/OS CLI MySQL クライアント PostgreSql クライアント sqlcmd ユーティリティ mssql-scripter iPython クライアント Cloud Foundry CLI Terraform Ansible .NET Core (2.1.4) Go (1.9) Java (1.8) Node.js (8.9.4) PowerShell Core (6.0.1)
  14. 14. Azure Cloud Shell提供の動機 ユーザーにどのような価値を提供したかったか 「踏み台サーバー」をなるべく不要に ツールをインストール、アップデートしなくて済むように (クラウド関連のツールは進化が早く、数も多い) 使いたいときに、すぐ、どこからでも なるべく安価に
  15. 15. 仮想マシンで実現できなかったか? 実現が難しかった理由 仮想マシンの作成と起動に時間がかかる (2分程度かかる) ツールのインストール、アップデートに時間がかかる ユーザーが個別に占有するリソース (特にメモリ、ディスク)が多く、 コスト高
  16. 16. Azure Cloud Shellとコンテナー 仮想マシンとカーネル、イメージを共有しているため、コンテナーは軽量 仮想マシン OSカーネル コンテナーイメージ (Ubuntu 16.04、ライブラリー、ランタイム、ツール) 読み取りのみ ユーザー領域 書き込み可 ユーザー領域 書き込み可 ユーザー領域 書き込み可 ユーザーA コンテナー ユーザーB コンテナー ユーザーC コンテナー 1度コンテナーホスト にダウンロードされれ ば、あとは差分のみ取 得する ユーザー個別のリソー スを小さくすることで、 速い起動と低コストを 実現できた
  17. 17. 仮想マシンとの違い ハードウェア ハイパーバイザー (Hyper-V、vSphereなど) 仮想マシン 仮想マシン OSカーネル OSカーネル コンテナー コンテナーランタイム/ライブラリー アプリ ランタイム/ ライブラリー ランタイム/ ライブラリー アプリ アプリ コンテナーイメージ
  18. 18. Dockerとは ハードウェア ハイパーバイザー (e.g. Hyper-V) 仮想マシン OSカーネル コンテナー コンテナー ランタイム/ ライブラリー ランタイム/ ライブラリー アプリ アプリ +周辺ツール • UNIX、BSD、Linuxの世界でコンテナー 技術は昔からあった • OSの各種リソース管理機能を活用して リソースを分離する • dotCloud(現Docker)社が自社PaaS向け に作ったコンテナーの仕組みをOSSにし てブレイク • 従来のコンテナー技術より、アプリ開 発者視点でうれしい機能、周辺ツール に力を入れている • イメージ作成、配布の仕組み • 差分イメージ形式 • 標準化の勢いでDockerの影響力は弱ま りつつあるが、広く普及している コンテナーイメージ
  19. 19. レジストリーとは コンテナーイメージを格納するデータストア Docker Hub パブリックレジストリーの 代表格 Azure Container Registry(ACR) プライベートレジストリー 実装例 様々な公式イメージ (ubuntu、nginx、etc) ユーザー作成イメージ ユーザー作成イメージ docker push/pull/run • レジストリーを指定しないと Docker Hubに接続 (デフォルト) • インターネット経由 • ユーザー個別にレジストリー を作成し、指定 • Azureネットワークに閉じた 運用が可能
  20. 20. コンテナーを”Pull”、”Run”すれば環境ができる “仮想マシン、OS、ランタイム、ライブラリー、アプリの導入” vs “docker run” 依存関係地獄から解放される ひとつのOSに複数バージョンのランタイム/ライブラリーを分離して構築できる 多様な技術を混在させたいマイクロサービスアーキテクチャーに向いている 開発のサクサク感が増し、運用を「強くする」手段も増える 時は金なり、人間の待ち時間はコストが高い 短時間で元の環境に戻せる、再現できる = 回復力(Resiliency)を得る うれしいところ
  21. 21. Azure Container Instances 環境の準備 演習
  22. 22. まずはコンテナーを1つ動かしてみましょう はじめの一歩 Azure Container Instancesはコンテナー1つから使えるサービス コンテナーを動かす仮想マシンや管理の仕組みを意識しなくていい マイクロビリング (秒単位課金) 東日本リージョンでは2018年内提供予定 Azure リージョン別の利用可能な製品
  23. 23. 以降の演習はすべてAzure Cloud Shell上で行います
  24. 24. $ cd clouddrive $ git clone https://github.com/ToruMakabe/conteriner-handson.git $ cd conteriner-handson/primer/ch01/ 演習用リポジトリを取得し、移動 $HOME/clouddrive 以下はAzure Filesのファイルシェアとして参照で きるため、作業ディレクトリとして おすすめ (必須ではありません)
  25. 25. Azure Cloud Shellのエディタ環境 お好きなものを emacs、nano、vim (アルファベット順)が入っています 簡易版Visual Studio Codeも使えます “code” で 起動 メニュー (ショートカットキーも 確認できます)
  26. 26. #!/bin/bash export RG_CH01="prefix-cho-ch01" 環境変数設定ファイル(set_env.sh)を編集 ユニークになる英数字を考え、 編集、保存してください (リソースグループ名、コンテ ナーグループ名、Webサイト名 などで使います) (参考情報: Azureの命名規則) cho = container hands on の略
  27. 27. $ . ./set_env.sh 環境変数をセット 行頭の.(ドット) とス ペースを忘れずに もしCloud Shellのセッションが切れ ても、このスクリプトを実行すれば 環境変数が再設定されます
  28. 28. $ cat ./create_rg.sh #!/bin/bash az group create -n $RG_CH01 -l westus2 $ ./create_rg.sh リソースグループを作成 年内にjapaneastも使え るようになる予定
  29. 29. Azure Container Instances 常時起動コンテナー (NGINX Webサーバー) 演習
  30. 30. $ cat ./create_nginx_container_on_aci.sh #!/bin/bash az container create ¥ -g $RG_CH01 ¥ -n ${RG_CH01}-nginx ¥ --image nginx ¥ --ip-address public スクリプトを確認 Azure CLIでACIコン テナーを作成 Docker Hubにあるnginx イメージを取得(後ほど 説明)
  31. 31. nginxイメージ (Docker Hub) イメージ指定の詳細は第2部で説明します https://hub.docker.com/_/nginx/ 実行するイメージが何者かは、 必ず確認しましょう (悪意が潜んだイメージかもし れないため)
  32. 32. $ ./create_nginx_container_on_aci.sh Name ResourceGroup Status Image IP:ports Network CPU/Memory OsType Location ----------------------- ----------------- -------- ------- --------------- --------- --------------- - ------- ---------- tomakabe-cho-ch01-nginx tomakabe-cho-ch01 Running nginx 52.183.37.59:80 Public 1.0 core/1.5 gb Linux westus2 スクリプトを実行
  33. 33. $ curl 52.183.37.59 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> (以下略) NGINX Webサーバーの起動を確認 IPアドレスは前スクリプト の実行結果を参照
  34. 34. ポータルで俯瞰し理解を深めましょう あまりにもあっさり作成されてしまうので イベントやプロパティ、 ログを確認できます sshできます もちろんCLIでも各種操作が可能
  35. 35. おさらい 起動が早い 実行時のセットアップ項目やパラメーターが少なく済む (NGINXがすでにセットアップされているイメージを使ったため) 仮想マシン要らず (意識しない)
  36. 36. Azure Container Instances バッチコンテナー (Word Count) 演習
  37. 37. $ cat ./create_wc_container_on_aci.sh #!/bin/bash az container create ¥ -g $RG_CH01 ¥ -n ${RG_CH01}-wordcount ¥ --image microsoft/aci-wordcount:latest ¥ --restart-policy OnFailure (続く) スクリプトの確認 (1/2) Docker Hubにあるaci- wordcountイメージを取 得(後ほど説明) コンテナーの再起動を失敗時 に限定 (=アプリケーション 正常終了とともに停止)
  38. 38. microsoft/aci-wordcountイメージ (Docker Hub) イメージ指定の詳細は第2部で説明します https://hub.docker.com/r/microsoft/aci-wordcount/ 実行するイメージが何者かは、 必ず確認しましょう (悪意が潜んだイメージかもし れないため)
  39. 39. FROM python:3.6.2-slim COPY * / RUN pip install html2text && pip install urllib3 && pip install sh ENV NumWords=10 MinLength=0 CMD python wordcount.py http://shakespeare.mit.edu/hamlet/full.html どんなコンテナーか https://github.com/seanmck/aci-wordcount 読み込んだ文章の単語数をカウ ントするPythonプログラム。 シェイクスピアのハムレットを 読むよう指定している このファイルはDockerfileといい、 コンテナーイメージの作成に使いま す (第2章で解説)
  40. 40. コンテナーの再起動ポリシー 終了時のふるまいを指定できる Always: コンテナー グループ内のコンテナーを常に再起動する。 これ は既定の設定で、コンテナー作成時に再起動ポリシーが指定されてい ない場合に適用されます。 Never: コンテナー グループ内のコンテナーを再起動しない。 コンテ ナーは最大で 1 回実行されます。 OnFailure: コンテナーで実行されたプロセスが失敗 (0 以外の終了コー ドで終了) した場合にのみ、コンテナー グループ内のコンテナーを再 起動する。 コンテナーは少なくとも 1 回実行されます。
  41. 41. (続き) az container show ¥ -g $RG_CH01 ¥ -n ${RG_CH01}-wordcount ¥ --query containers[0].instanceView.currentState.state az container logs ¥ -g $RG_CH01 ¥ -n ${RG_CH01}-wordcount スクリプトの確認 (2/2) コンテナーの状態を取得 コンテナーの実行ログを取得
  42. 42. $ ./create_wc_container_on_aci.sh Name ResourceGroup Status Image CPU/Memory OsType Location --------------------------- ----------------- --------- ------------------------------ --------------- - ------- ---------- tomakabe-cho-ch01-wordcount tomakabe-cho-ch01 Succeeded microsoft/aci-wordcount:latest 1.0 core/1.5 gb Linux westus2 Result ---------- Terminated [('the', 990), ('and', 702), ('of', 628), ('to', 610), ('I', 544), ('you', 495), ('a', 453), ('my', 441), ('in', 399), ('HAMLET', 386)] スクリプトを実行 実行後にコンテナーは削除 ログに実行結果が残っている
  43. 43. クラウドでの「使い捨て」ニーズ “Resource Central: Understanding and Predicting Workloads for Improved Resource Management in Large Cloud Platforms” Microsoft, SOSP 2017
  44. 44. おさらい プロセスの正常終了とともにコンテナーを削除することも可能 コンテナーは使い捨てバッチ基盤として活用できる
  45. 45. $ cat ./cleanup.sh #!/bin/bash az group delete -n $RG_CH01 $ ./cleanup.sh おつかれさまでした 第1部の演習に使ったリソース が、すべて消えます
  46. 46. アプリケーションのコンテナー化 第2部
  47. 47. . ├── Dockerfile ├── README.md └── wordcount.py 0 directories, 3 files aci-wordcountイメージはどう作られたか https://github.com/seanmck/aci-wordcount このディレクトリでコンテナーをビルドすると、 Dockerfileに書かれた手順に従ってコンテナー イメージが出来上がります
  48. 48. FROM python:3.6.2-slim COPY * / RUN pip install html2text && pip install urllib3 && pip install sh ENV NumWords=10 MinLength=0 CMD python wordcount.py http://shakespeare.mit.edu/hamlet/full.html Dockerfile https://github.com/seanmck/aci-wordcount ベースイメージはpython:3.6.2-slim Pyhton:3.6.2-slim (Base Image) wordcount.py (User Application) html2text, urllib3, sh (Python Package)
  49. 49. # # NOTE: THIS DOCKERFILE IS GENERATED VIA "update.sh" # # PLEASE DO NOT EDIT IT DIRECTLY. # FROM debian:stretch-slim # ensure local python is preferred over distribution python ENV PATH /usr/local/bin:$PATH (以下略) ベースイメージの中身も確認 https://github.com/docker- library/python/blob/88812635c8ad7ff06a8a3755616a1040df222f3c/3.6/stretch/slim/Dockerfile Pyhton:3.6.2-slim (Base Image) wordcount.py (User Application) html2text, urllib3, sh (Python Package) debian:stretch-slim (Base of Base Image)
  50. 50. レイヤーを重ねる docker build ベースイメージに必要なランタイム、ライブラリを重ねる アプリケーションをコピーする 環境変数などパラメーターを渡す コンテナー起動時に実行するコマンドを指定する イメージが小さいと起動が速く、取り回しやすい (alpine linuxなど軽量なベースイメージも人気) Pyhton:3.6.2-slim (Base Image) wordcount.py (User Application) html2text, urllib3, sh (Python Package) debian:stretch-slim (Base of Base Image)
  51. 51. $ docker pull microsoft/aci-wordcount Using default tag: latest latest: Pulling from microsoft/aci-wordcount aa18ad1a0d33: Pull complete 1b1ad4542c99: Pull complete f55f6bdb976a: Pull complete c91d00a04662: Pull complete 37de53ca9f34: Pull complete 905557d139be: Pull complete c13204906a3a: Pull complete Digest: sha256:c6b8a2641ef27bcc29bd465131ba5b80d5965dba42ddf1be6a2fe25ba331349c Status: Downloaded newer image for microsoft/aci-wordcount:latest $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE microsoft/aci-wordcount latest cb6dd82ba7c6 11 months ago 212MB レイヤーは確認できる (1/2) 1度取得したレイヤーは次から ダウンロードされない (注) Azure Cloud Shellではdocker pullするのに 別途Dockerサーバーを用意する必要があります
  52. 52. $ docker history cb6dd82ba7c6 IMAGE CREATED CREATED BY SIZE COMMENT cb6dd82ba7c6 11 months ago /bin/sh -c #(nop) CMD ["/bin/sh" "-c" "pyth… 0B <missing> 11 months ago /bin/sh -c #(nop) ENV NumWords=10 MinLength… 0B <missing> 11 months ago /bin/sh -c pip install html2text && pip inst… 6.76MB <missing> 11 months ago /bin/sh -c #(nop) COPY multi:5344d46158ade6b… 26.1kB <missing> 13 months ago /bin/sh -c #(nop) CMD ["python3"] 0B <missing> 13 months ago /bin/sh -c set -ex; apt-get update; apt-g… 6.51MB <missing> 13 months ago /bin/sh -c #(nop) ENV PYTHON_PIP_VERSION=9.… 0B <missing> 13 months ago /bin/sh -c cd /usr/local/bin && ln -s idle3… 32B <missing> 13 months ago /bin/sh -c set -ex && buildDeps=" dpkg-de… 67.5MB <missing> 13 months ago /bin/sh -c #(nop) ENV PYTHON_VERSION=3.6.2 0B <missing> 13 months ago /bin/sh -c #(nop) ENV GPG_KEY=0D96DF4D4110E… 0B <missing> 13 months ago /bin/sh -c apt-get update && apt-get install… 8.11MB <missing> 13 months ago /bin/sh -c #(nop) ENV LANG=C.UTF-8 0B <missing> 13 months ago /bin/sh -c #(nop) ENV PATH=/usr/local/bin:/… 0B <missing> 13 months ago /bin/sh -c #(nop) CMD ["bash"] 0B <missing> 13 months ago /bin/sh -c #(nop) ADD file:d7333b3e0bc6479d2… 123MB レイヤーは確認できる (2/2) (注) Azure Cloud Shellではdocker historyするのに 別途Dockerサーバーを用意する必要があります
  53. 53. Dockerイメージのビルド環境 開発端末でビルドするには Docker for Windows/Macともに 仮想マシン上のLinuxでビルドを行う (Linuxコンテナーの場合) 端末を仮想化するハードルがやや高い (リソース、運用ポリシー) クラウド側で気軽にビルドできないか? でもAzure Cloud Shellでは Docker in Dockerできない… 仮想化ハイパーバイザー (Hyper-V, xhybeなど) 仮想マシン Linux Docker Server (Engine) Docker Client docker build 必要な ファイルを転送 Image作成 端末
  54. 54. Azure上でビルドする方法 ACRのビルド機能を使うと気軽です CI/CDパイプラインでビルドを自動化する Azure Cloud ShellをDockerクライアントとし、Dockerサーバーを仮想 マシン上に作る (docker machine) Azure Container Registryのビルド機能を使う
  55. 55. ACR Task ACRはイメージデータストアだけでなく、タスク実行機能を持つ Azure CLIの az acr build コマンドで、 ACRへコンテナーイメージのビルドを指示 必要なファイルを転送し、ビルドされる Azure Cloud Shellからでも実行できる ビルド用の仮想マシンが不要 Azure Container Registry ACR Task Azure CLI az acr build Image作成 必要な ファイルを転送
  56. 56. Azure Container Registry 演習
  57. 57. $ cd $HOME/clouddrive/conteriner-handson/primer/ch02/ (./set_env.shを開き、prefixを編集、保存) $ . ./set_env.sh 演習用ディレクトリへ移動し環境変数を設定
  58. 58. $ cat ./create_rg.sh #!/bin/bash az group create -n $RG_CH01 -l westus2 $ ./create_rg.sh リソースグループ(ACI向け)を作成 年内にjapaneastも使え るようになる予定 ACIはACRに作ったイメージを テストするために使います
  59. 59. $ cat ./create_acr.sh #!/bin/bash az group create -n $RG_RGST -l japaneast az acr create ¥ -g $RG_RGST ¥ -n $ACR ¥ --sku Standard ¥ --admin-enabled true $ ./create_acr.sh リソースグループ(ACR向け)とACRを作成 ACRを作成
  60. 60. ACRのリソースグループを分けた理由 コンテナーイメージはライフサイクルが長いため Azureのリソースグループは論理的にリソースをまとめる単位です その設計は自由 ライフサイクルが同じリソースをまとめるのはひとつの手 (作成/削除のタイミングが同じもの) コンテナーは作って壊してを繰り返すが、そのイメージはライフサイ クルが長いため、独立したリソースグループにすることが多い
  61. 61. $ cat main.go (中略) func handler(w http.ResponseWriter, r *http.Request) { hostname, err := os.Hostname() if err != nil { panic(err) } fmt.Fprintln(w, "[Hostname]") fmt.Fprintln(w, hostname) fmt.Fprintln(w) fmt.Fprintln(w, "[Messages]") fmt.Fprintln(w, "Hello World!") } (以下略) 演習用アプリケーションの確認 ホスト名を取得 ホスト名を表示 メッセージを表示 コンテナーを実行するホスト名 とHello World!を表示するWebア プリケーションです(Go言語)
  62. 62. $ cat Dockerfile # build stage ARG GO_VERSION=1.11.1 FROM golang:${GO_VERSION}-alpine AS build-stage WORKDIR /tmp COPY ./ /tmp RUN go build -o main main.go # production stage FROM alpine:3.8 WORKDIR /root/ COPY --from=build-stage /tmp/main . EXPOSE 80 CMD ["./main"] Dockerfileの確認 ビルド用ベースイメー ジはGo言語のビルド ツール入り 実行用ベースイ メージは軽量に ビルド用と実行用のベースイ メージを分けて、実行イメージ を軽くすることができます (マルチステージビルド) ビルドステージで作っ た成果物をコピー
  63. 63. $ cat build_container.sh #!/bin/bash az acr build ¥ --registry $ACR ¥ --image disp-hostname:0.0.1 ¥ --context . ビルド用スクリプトを確認 イメージ名をdisp-hostname とし、タグ(:以降)でバージョ ンを表現しています ビルドに必要なファイルの場 所を指定します
  64. 64. $ ./build_container.sh The behavior of this command has been altered by the following extension: acrbuildext Sending build context (1.155 KiB) to ACR Queued a build with ID: ae1 (中略) 2018/10/23 06:40:20 Successfully populated digests for step ID: build 2018/10/23 06:40:20 Step ID: push marked as successful (elapsed time in seconds: 19.848761) Run ID: ae1 was successful after 1m7s ビルド用スクリプトを実行
  65. 65. ポータルで俯瞰し理解を深めましょう あまりにもあっさり作成されてしまうので もちろんCLIでも各種操作が可能 メニュー
  66. 66. $ cat ./create_disphostname_container_on_aci.sh #!/bin/bash PASS=$(az acr credential show -n $ACR -o tsv --query passwords[0].value) az container create ¥ -g $RG_CH02 ¥ -n ${RG_CH02}-disphostname ¥ --registry-login-server ${ACR}.azurecr.io ¥ --registry-username ${ACR} ¥ --registry-password $PASS ¥ --image ${ACR}.azurecr.io/disp-hostname:0.0.1 ¥ --ip-address public $ ./create_disphostname_container_on_aci.sh コンテナー作成スクリプトの確認と実行 ACRのパスワー ドを取得 先ほど作成した イメージを指定
  67. 67. $ curl 52.183.2.214 [Hostname] wk-caas-b481976ee77a4f1c89162bbd2f014ac5-8799c1322dbc159ae1ed91 [Messages] Hello World! コンテナー実行確認 コンテナー作成スクリプトの 実行結果でIPアドレスを確認 コンテナーらしいホスト名
  68. 68. アプリをバージョンアップしてみましょう (main.goを編集) (中略) func handler(w http.ResponseWriter, r *http.Request) { hostname, err := os.Hostname() if err != nil { panic(err) } fmt.Fprintln(w, "[Hostname]") fmt.Fprintln(w, hostname) fmt.Fprintln(w) fmt.Fprintln(w, "[Messages]") fmt.Fprintln(w, "Hello World! v2") } (以下略) “v2” を入れる
  69. 69. バージョンアップ ビルドスクリプトの確認と実行 $ cat ./build_container_v2.sh #!/bin/bash az acr build ¥ --registry $ACR ¥ --image disp-hostname:0.0.2 ¥ --context . $ ./build_container_v2.sh タグが “0.0.2” に
  70. 70. $ cat ./update_disphostname_container_v2_on_aci.sh #!/bin/bash PASS=$(az acr credential show -n $ACR -o tsv --query passwords[0].value) az container create ¥ -g $RG_CH02 ¥ -n ${RG_CH02}-disphostname ¥ --registry-login-server ${ACR}.azurecr.io ¥ --registry-username ${ACR} ¥ --registry-password $PASS ¥ --image ${ACR}.azurecr.io/disp-hostname:0.0.2 ¥ --ip-address public $ ./update_disphostname_container_v2_on_aci.sh コンテナーバージョンアップ タグを変更
  71. 71. $ curl 52.183.2.214 [Hostname] wk-caas-b481976ee77a4f1c89162bbd2f014ac5-daac589b47b1f44c7953d1 [Messages] Hello World! v2 コンテナー実行確認 バージョンアップした 実行コンテナーが変わったた めホスト名も変わった
  72. 72. $ ./create_disphostname_container_on_aci.sh $ curl 52.183.2.214 [Hostname] wk-caas-08128f904f9e45eaa8774731755a1047-8799c1322dbc159ae1ed91 [Messages] Hello World! コンテナーバージョン戻し タグ0.0.1のイメージを 使ったスクリプトを再実行 0.0.1に戻った
  73. 73. おさらい Dockerコンテナーイメージのレイヤー構造 Dockerfileにビルド(イメージ作成)の手順を書く コンテナーイメージはクラウド上でもビルドできる ACRにはビルド機能がある タグを活用することでバージョンアップ/戻しが楽
  74. 74. $ cat ./cleanup_rg.sh #!/bin/bash az group delete -n $RG_CH02 $ ./cleanup_rg.sh おつかれさまでした 第2部の演習に使ったACIリ ソースが、すべて消えます ACRは第3部でも使うため、消 さずに残しておきす
  75. 75. さまざまなコンテナー実行基盤 第3部
  76. 76. ACIは素材として便利、でも シンプルさが特徴な反面、手厚さには欠ける アプリやコンテナーに手を入れずHTTPS(TLS)化したい スケールアウトしたい (コンテナーのレプリカを増やす) バージョンアップ/戻しをもっと安全にしたい (ステージング環境でテストしてから切り替えたいなど) より手厚くサポートしてくれる基盤が欲しい (コンテナーオーケストレーター)
  77. 77. Containers in Azure Choice of developer tools and clients Azure Container Registry Docker Hub App Service Azureの歴史ある PaaSサービス GitやVisual Studio に限らずDockerコ ンテナーでのデプ ロイにも対応 Service Fabric マイクロソフトの 開発する分散処理 基盤 .NETアプリケー ションとの相性が いい Kubernetes Service Container Instance コンテナーオーケスト レーターの事実上標準 Ecosystem パートナーとの 協業 コンテナー1つから 使えるマネージド サービス AKSの仮想ノードと しても利用可能
  78. 78. Azure Kubernetes Service (AKS) API server Controller ManagerScheduler etcd Store Cloud Controller Self-managed master node(s) • コンテナーオーケストレーターの 事実上標準 • CNCF(Cloud Native Computing Foundation)がオープンな開発を リード • 可用性を高める仕組み • 拡張性を高める仕組み • 自己修復 • 構築や維持が負担が大きいが、 Azureはマネージドサービスとして 提供 • アプリによっては、やや大げさな 規模感 Customer VMs App/ workload definitionUser Docker Pods Docker Pods Docker Pods Docker Pods Docker Pods Schedule pods over private tunnel Kubernetes API endpoint Azure managed control plane
  79. 79. Azure Web App for Containers Kubernetesまでは要らないWebアプリケーションに 歴史あるWebアプリケーションPaaS PaaSらしく、構築、デプロイ、運用が非常に楽 HTTPS(TLS)化、自動スケールアウト、デプロイメントスロット切替 2017年、Dockerコンテナーのデプロイに対応 アプリの公開可能ポートが80/443のみ、という制約を受け入れられれ ば、強力な選択肢 AKSは次回(応用編)のテーマとし、本日はこちらを演習
  80. 80. Azure Web App for Containers 演習
  81. 81. $ cd $HOME/clouddrive/conteriner-handson/primer/ch03/ (./set_env.shを開き、ch02と同じになるようprefixを編集、保存) $ . ./set_env.sh 演習用ディレクトリへ移動し環境変数を設定
  82. 82. $ cat ./create_rg.sh #!/bin/bash az group create -n $RG_CH03 -l japaneast $ ./create_rg.sh リソースグループを作成
  83. 83. $ cat ./create_disphostname_container_on_appsvc.sh #!/bin/bash PASS=$(az acr credential show -n $ACR -o tsv --query passwords[0].value) az appservice plan create ¥ -g $RG_CH03 ¥ -n ${RG_CH03}-appsvcplan ¥ --sku S1 ¥ --is-linux (続く) App Service PlanとWeb Appを作成 (1/2) App Service Plan (Web Appの土台)を作成
  84. 84. (続き) az webapp create ¥ -g $RG_CH03 ¥ -p ${RG_CH03}-appsvcplan ¥ -n ${RG_CH03}-disphostname ¥ -i ${ACR}.azurecr.io/disp-hostname:0.0.1 az webapp config container set ¥ -g $RG_CH03 ¥ -n ${RG_CH03}-disphostname ¥ --docker-custom-image-name ${ACR}.azurecr.io/disp-hostname:0.0.1 ¥ --docker-registry-server-url ${ACR}.azurecr.io ¥ --docker-registry-server-user $ACR ¥ --docker-registry-server-password $PASS $ ./create_disphostname_container_on_appsvc.sh App Service PlanとWeb Appを作成 (2/2) 第2部で作成したイメージ を指定 ACRの認証情報を設定
  85. 85. Webブラウザーで確認 HTTPS(TLS)化さ れている URLはWeb App作成スクリプトの出力 から (ポータルでも確認できます)
  86. 86. スケールアウト/自動スケール設定 ポータルで確認しましょう ([App Service] > [Web App]) 後からインスタンス 数を変更できる 自動スケール設定も 可能
  87. 87. $ cat ./create_staging_slot.sh #!/bin/bash PASS=$(az acr credential show -n $ACR -o tsv --query passwords[0].value) az webapp deployment slot create ¥ -g $RG_CH03 ¥ -n ${RG_CH03}-disphostname ¥ -s staging ¥ --configuration-source ${RG_CH03}-disphostname (続く) ステージングスロットを作成 (1/2) 先ほど作成したWeb Appのス テージングスロットを作る
  88. 88. (続き) az webapp config container set ¥ -g $RG_CH03 ¥ -n ${RG_CH03}-disphostname ¥ -s staging ¥ --docker-custom-image-name ${ACR}.azurecr.io/disp-hostname:0.0.2 ¥ --docker-registry-server-url ${ACR}.azurecr.io ¥ --docker-registry-server-user $ACR ¥ --docker-registry-server-password $PASS $ ./create_staging_slot.sh ステージングスロットを作成 (2/2) ACRの認証情報を設定 コンテナーの新 バージョンを指定
  89. 89. Webブラウザーでステージングスロットを確認 URLはWeb App作成スクリプトの出力 から (ポータルでも確認できます) バージョンが上がっている
  90. 90. $ cat ./swap_slot.sh #!/bin/bash az webapp deployment slot swap ¥ -g $RG_CH03 ¥ -n ${RG_CH03}-disphostname ¥ --slot staging ¥ --target-slot production $ ./swap_slot.sh スロットの入れ替え ステージングスロットとプロダ クションスロットを入れ替え
  91. 91. Webブラウザーで確認 入れ替わっている
  92. 92. おさらい コンテナーをより使いやすくするためにオーケストレーターがある Kubernetesがトレンドだが、アプリによっては、やや大げさ Azure Web App for Containersは気軽に使えるPaaS基盤 HTTPS(TLS)化 スケールアウト、自動スケール ステージングスロットを確認した上でリスク低く本番切り替え
  93. 93. $ cat ./cleanup.sh #!/bin/bash az group delete -n $RG_CH03 $ ./cleanup.sh おつかれさまでした
  94. 94. $ cd ../ch02 $ cat ./cleanup_acr.sh #!/bin/bash az group delete -n $RG_RGST $ ./cleanup_acr.sh おつかれさまでした (ACRも消します)
  95. 95. Q&A お気軽に
  96. 96. © Copyright Microsoft Corporation. All rights reserved.

×