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

半日でわかるコンテナー技術 (入門編)
真壁徹
日本マイクロソフト株式会社
クラウドソリューションアーキテクト
2018/10/24
WebブラウザーとAzureで手を動かして学ぶ

自己紹介
{
“名前” : “真壁徹(まかべとおる)”,
“所属” : “日本マイクロソフト株式会社”,
“役割” : “クラウドソリューションアーキテクト”,
“経歴” : “大和総研 → HP Enterprise”,
“特技” : “クラウド & オープンソース”,
“資格” : “CNCF Certified Kubernetes Admin.”,
“Twitter” : “@tmak_tw”
}

アジェンダ
コンセプト説明と作業環境の確認
コンテナー技術基礎知識
アプリケーションのコンテナー化
さまざまなコンテナー実行基盤
Q&A

コンセプト
この半日の

コンテナー技術を学びたい、でも
環境が先か、体験が先か
端末にソフト導入の自由度とそれなりのスペックを要求される
(Docker for Windows/Mac、仮想化、メモリ量、etc)
企業で貸与されている端末で動かないケースも多い
必要であれば端末購入を申請したいが、説得材料に欠ける
コンテナー技術が自らの課題に効果的かどうか、体験、実感したい
気軽にコンテナー技術を試せる機会があれば…

おまかせください
WebブラウザーとAzureのみで体験しましょう
Azureの利用権と対応するWebブラウザーがあればOKです
Azure Cloud Shellとコンテナー技術対応サービスを活用します
コンテナー技術のコンセプトや動作、開発の流れを体験できます
利点や効果を実感できたら、端末など環境整備をご検討ください
(現時点ではまだ、端末上での開発が効率的です)

環境確認
手を動かす前に

ご確認ください
サポートするWebブラウザー、Azureサブスクリプションと権限
Azure Portal でサポートされるブラウザーとデバイス
Azureポータルにログインし、Cloud Shell を起動してください
リソースグループ作成権限の有無を確認してください
(az group create –n mytest –l japaneast)
※サブスクリプション所有者か共同作成者であれば確実
ポータル
上部の、ここ
対象: サブスクリプション持ち込みの方

もしもの時は
ハンズオンを進められない場合は
権限が足りなかったり、管理者が各種機能を無効化している場合は
Azureの無料アカウントを作成するもしくは、
Microsoft Learnで自習
(ラーニングパス: Azureでコンテナーを管理する)
対象: サブスクリプション持ち込みの方
2018/9末のMicrosoft Igniteで発表された自習サイト
保有サブスクリプションに影響を与えない「サンドボックス」で演習可能
コンテナーの他にも多様なテーマ、ラーニングパスあり

コンテナー技術基礎知識
第1部

実はすでにコンテナーを動かしていました
Azure Cloud Shellはコンテナーを使っている
20秒程度で起動
ブラウザーがあれば使える
$HOME以下はAzure Filesに永続化される
利用料金はAzure Files利用量に対してのみ

Azure Cloud Shellの仕組み
フロントエンドはJavaScript
ブラウザにXterm.jsがロードされる
Ubuntuコンテナーを生成
ユーザーごとにひとつのコンテナー
コンテナーイメージはユーザー共通
20分間無操作だと破棄される
永続化領域はAzure Filesへ
$HOMEの下が永続化される
ブラウザブラウザ
ユーザーコンテナー
Azure Files
Xterm.js Xterm.js
コンテナーイメージ
(Ubuntu 16.04 &
Tools)

起動してすぐ、多様な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)

Azure Cloud Shell提供の動機
ユーザーにどのような価値を提供したかったか
「踏み台サーバー」をなるべく不要に
ツールをインストール、アップデートしなくて済むように
(クラウド関連のツールは進化が早く、数も多い)
使いたいときに、すぐ、どこからでも
なるべく安価に

仮想マシンで実現できなかったか？
実現が難しかった理由
仮想マシンの作成と起動に時間がかかる (2分程度かかる)
ツールのインストール、アップデートに時間がかかる
ユーザーが個別に占有するリソース (特にメモリ、ディスク)が多く、
コスト高

Azure Cloud Shellとコンテナー
仮想マシンとカーネル、イメージを共有しているため、コンテナーは軽量
仮想マシン
OSカーネル
コンテナーイメージ (Ubuntu 16.04、ライブラリー、ランタイム、ツール)
読み取りのみ
ユーザー領域
書き込み可
ユーザー領域
書き込み可
ユーザー領域
書き込み可
ユーザーA
コンテナー
ユーザーB
コンテナー
ユーザーC
コンテナー 1度コンテナーホスト
にダウンロードされれ
ば、あとは差分のみ取
得する
ユーザー個別のリソー
スを小さくすることで、
速い起動と低コストを
実現できた

仮想マシンとの違い
ハードウェア
ハイパーバイザー (Hyper-V、vSphereなど)
仮想マシン仮想マシン
OSカーネル
OSカーネル
コンテナーコンテナーランタイム/ライブラリー
アプリ
ランタイム/
ライブラリー
ランタイム/
ライブラリー
アプリアプリ

Dockerとは
ハードウェア
ハイパーバイザー (e.g. Hyper-V)
仮想マシン
OSカーネル
コンテナーコンテナー
ランタイム/
ライブラリー
ランタイム/
ライブラリー
アプリアプリ
+周辺ツール
• UNIX、BSD、Linuxの世界でコンテナー
技術は昔からあった
• OSの各種リソース管理機能を活用して
リソースを分離する
• dotCloud(現Docker)社が自社PaaS向け
に作ったコンテナーの仕組みをOSSにし
てブレイク
• 従来のコンテナー技術より、アプリ開
発者視点でうれしい機能、周辺ツール
に力を入れている
• イメージ作成、配布の仕組み
• 差分イメージ形式
• 標準化の勢いでDockerの影響力は弱ま
りつつあるが、広く普及している

レジストリーとは
コンテナーイメージを格納するデータストア
Docker Hub
パブリックレジストリーの
代表格
Azure Container
Registry(ACR)
プライベートレジストリー
実装例
様々な公式イメージ
(ubuntu、nginx、etc)
ユーザー作成イメージ
ユーザー作成イメージ
docker push/pull/run
• レジストリーを指定しないと
Docker Hubに接続 (デフォルト)
• インターネット経由
• ユーザー個別にレジストリー
を作成し、指定
• Azureネットワークに閉じた
運用が可能

コンテナーを”Pull”、”Run”すれば環境ができる
“仮想マシン、OS、ランタイム、ライブラリー、アプリの導入” vs “docker run”
依存関係地獄から解放される
ひとつのOSに複数バージョンのランタイム/ライブラリーを分離して構築できる
多様な技術を混在させたいマイクロサービスアーキテクチャーに向いている
開発のサクサク感が増し、運用を「強くする」手段も増える
時は金なり、人間の待ち時間はコストが高い
短時間で元の環境に戻せる、再現できる = 回復力(Resiliency)を得る
うれしいところ

Azure Container Instances
環境の準備
演習

まずはコンテナーを1つ動かしてみましょう
はじめの一歩
Azure Container Instancesはコンテナー1つから使えるサービス
コンテナーを動かす仮想マシンや管理の仕組みを意識しなくていい
マイクロビリング (秒単位課金)
東日本リージョンでは2018年内提供予定
Azure リージョン別の利用可能な製品

以降の演習はすべてAzure Cloud
Shell上で行います

$ cd clouddrive
$ git clone https://github.com/ToruMakabe/conteriner-handson.git
$ cd conteriner-handson/primer/ch01/
演習用リポジトリを取得し、移動
$HOME/clouddrive 以下はAzure
Filesのファイルシェアとして参照で
きるため、作業ディレクトリとして
おすすめ (必須ではありません)

Azure Cloud Shellのエディタ環境
お好きなものを
emacs、nano、vim (アルファベット順)が入っています
簡易版Visual Studio Codeも使えます
“code” で
起動
メニュー
(ショートカットキーも
確認できます)

#!/bin/bash
export RG_CH01="prefix-cho-ch01"
環境変数設定ファイル(set_env.sh)を編集
ユニークになる英数字を考え、
編集、保存してください
(リソースグループ名、コンテ
ナーグループ名、Webサイト名
などで使います)
(参考情報: Azureの命名規則)
cho = container hands on の略

$ . ./set_env.sh
環境変数をセット
行頭の.(ドット) とス
ペースを忘れずに
もしCloud Shellのセッションが切れ
ても、このスクリプトを実行すれば
環境変数が再設定されます

$ cat ./create_rg.sh
#!/bin/bash
az group create -n $RG_CH01 -l westus2
$ ./create_rg.sh
リソースグループを作成
年内にjapaneastも使え
るようになる予定

常時起動コンテナー
(NGINX Webサーバー)
演習

$ 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
イメージを取得(後ほど
説明)

nginxイメージ (Docker Hub)
イメージ指定の詳細は第2部で説明します
https://hub.docker.com/_/nginx/
実行するイメージが何者かは、
必ず確認しましょう
(悪意が潜んだイメージかもし
れないため)

$ ./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
スクリプトを実行

$ curl 52.183.37.59
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
(以下略)
NGINX Webサーバーの起動を確認
IPアドレスは前スクリプト
の実行結果を参照

ポータルで俯瞰し理解を深めましょう
あまりにもあっさり作成されてしまうので
イベントやプロパティ、
ログを確認できます
sshできます
もちろんCLIでも各種操作が可能

おさらい
起動が早い
実行時のセットアップ項目やパラメーターが少なく済む
(NGINXがすでにセットアップされているイメージを使ったため)
仮想マシン要らず (意識しない)

バッチコンテナー
(Word Count)
演習

$ cat ./create_wc_container_on_aci.sh
#!/bin/bash
-g $RG_CH01 ¥
-n ${RG_CH01}-wordcount ¥
--image microsoft/aci-wordcount:latest ¥
--restart-policy OnFailure
(続く)
スクリプトの確認 (1/2)
Docker Hubにあるaci-
wordcountイメージを取
得(後ほど説明)
コンテナーの再起動を失敗時
に限定 (=アプリケーション
正常終了とともに停止)

microsoft/aci-wordcountイメージ (Docker Hub)
イメージ指定の詳細は第2部で説明します
https://hub.docker.com/r/microsoft/aci-wordcount/
実行するイメージが何者かは、
必ず確認しましょう
(悪意が潜んだイメージかもし
れないため)

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章で解説)

コンテナーの再起動ポリシー
終了時のふるまいを指定できる
Always: コンテナーグループ内のコンテナーを常に再起動する。これ
は既定の設定で、コンテナー作成時に再起動ポリシーが指定されてい
ない場合に適用されます。
Never: コンテナーグループ内のコンテナーを再起動しない。コンテ
ナーは最大で 1 回実行されます。
OnFailure: コンテナーで実行されたプロセスが失敗 (0 以外の終了コー
ドで終了) した場合にのみ、コンテナーグループ内のコンテナーを再
起動する。コンテナーは少なくとも 1 回実行されます。

(続き)
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)
コンテナーの状態を取得
コンテナーの実行ログを取得

$ ./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)]
スクリプトを実行
実行後にコンテナーは削除
ログに実行結果が残っている

クラウドでの「使い捨て」ニーズ
“Resource Central: Understanding and Predicting Workloads for Improved
Resource Management in Large Cloud Platforms” Microsoft, SOSP 2017

おさらい
プロセスの正常終了とともにコンテナーを削除することも可能
コンテナーは使い捨てバッチ基盤として活用できる

$ cat ./cleanup.sh
#!/bin/bash
az group delete -n $RG_CH01
$ ./cleanup.sh
おつかれさまでした
第1部の演習に使ったリソース
が、すべて消えます

アプリケーションのコンテナー化
第2部

.
├── Dockerfile
├── README.md
└── wordcount.py
0 directories, 3 files
aci-wordcountイメージはどう作られたか
このディレクトリでコンテナーをビルドすると、
Dockerfileに書かれた手順に従ってコンテナー
イメージが出来上がります

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
ベースイメージはpython:3.6.2-slim
Pyhton:3.6.2-slim
(Base Image)
wordcount.py
(User Application)
html2text, urllib3, sh
(Python Package)

#
# 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)
(Python Package)
debian:stretch-slim
(Base of Base Image)

レイヤーを重ねる
docker build
ベースイメージに必要なランタイム、ライブラリを重ねる
アプリケーションをコピーする
環境変数などパラメーターを渡す
コンテナー起動時に実行するコマンドを指定する
イメージが小さいと起動が速く、取り回しやすい
(alpine linuxなど軽量なベースイメージも人気)
Pyhton:3.6.2-slim
(Base Image)
wordcount.py
(User Application)
(Python Package)
debian:stretch-slim
(Base of Base Image)

$ 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サーバーを用意する必要があります

$ 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サーバーを用意する必要があります

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作成
端末

Azure上でビルドする方法
ACRのビルド機能を使うと気軽です
CI/CDパイプラインでビルドを自動化する
Azure Cloud ShellをDockerクライアントとし、Dockerサーバーを仮想
マシン上に作る
(docker machine)
Azure Container Registryのビルド機能を使う

ACR Task
ACRはイメージデータストアだけでなく、タスク実行機能を持つ
Azure CLIの az acr build コマンドで、
ACRへコンテナーイメージのビルドを指示
必要なファイルを転送し、ビルドされる
Azure Cloud Shellからでも実行できる
ビルド用の仮想マシンが不要
Azure Container Registry
ACR Task
Azure CLI
az acr build
Image作成
必要な
ファイルを転送

Azure Container Registry
演習

$ cd $HOME/clouddrive/conteriner-handson/primer/ch02/
(./set_env.shを開き、prefixを編集、保存)
$ . ./set_env.sh
演習用ディレクトリへ移動し環境変数を設定

#!/bin/bash
az group create -n $RG_CH01 -l westus2
$ ./create_rg.sh
リソースグループ(ACI向け)を作成
年内にjapaneastも使え
るようになる予定
ACIはACRに作ったイメージを
テストするために使います

$ 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を作成

ACRのリソースグループを分けた理由
コンテナーイメージはライフサイクルが長いため
Azureのリソースグループは論理的にリソースをまとめる単位です
その設計は自由
ライフサイクルが同じリソースをまとめるのはひとつの手
(作成/削除のタイミングが同じもの)
コンテナーは作って壊してを繰り返すが、そのイメージはライフサイ
クルが長いため、独立したリソースグループにすることが多い

$ 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言語)

$ 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言語のビルド
ツール入り
実行用ベースイ
メージは軽量に
ビルド用と実行用のベースイ
メージを分けて、実行イメージ
を軽くすることができます
(マルチステージビルド)
ビルドステージで作っ
た成果物をコピー

$ cat build_container.sh
#!/bin/bash
az acr build ¥
--registry $ACR ¥
--image disp-hostname:0.0.1 ¥
--context .
ビルド用スクリプトを確認
イメージ名をdisp-hostname
とし、タグ(:以降)でバージョ
ンを表現しています
ビルドに必要なファイルの場
所を指定します

$ ./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
ビルド用スクリプトを実行

ポータルで俯瞰し理解を深めましょう
あまりにもあっさり作成されてしまうので
もちろんCLIでも各種操作が可能
メニュー

$ cat ./create_disphostname_container_on_aci.sh
#!/bin/bash
PASS=$(az acr credential show -n $ACR -o tsv --query passwords[0].value)
-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のパスワー
ドを取得
先ほど作成した
イメージを指定

$ curl 52.183.2.214
[Hostname]
wk-caas-b481976ee77a4f1c89162bbd2f014ac5-8799c1322dbc159ae1ed91
[Messages]
Hello World!
コンテナー実行確認
コンテナー作成スクリプトの
実行結果でIPアドレスを確認
コンテナーらしいホスト名

アプリをバージョンアップしてみましょう
(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” を入れる

バージョンアップビルドスクリプトの確認と実行
$ 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” に

$ cat ./update_disphostname_container_v2_on_aci.sh
#!/bin/bash
-g $RG_CH02 ¥
--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
コンテナーバージョンアップ
タグを変更

$ curl 52.183.2.214
[Hostname]
wk-caas-b481976ee77a4f1c89162bbd2f014ac5-daac589b47b1f44c7953d1
[Messages]
Hello World! v2
コンテナー実行確認
バージョンアップした
実行コンテナーが変わったた
めホスト名も変わった

$ ./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に戻った

おさらい
Dockerコンテナーイメージのレイヤー構造
Dockerfileにビルド(イメージ作成)の手順を書く
コンテナーイメージはクラウド上でもビルドできる
ACRにはビルド機能がある
タグを活用することでバージョンアップ/戻しが楽

$ cat ./cleanup_rg.sh
#!/bin/bash
$ ./cleanup_rg.sh
第2部の演習に使ったACIリ
ソースが、すべて消えます
ACRは第3部でも使うため、消
さずに残しておきす

さまざまなコンテナー実行基盤
第3部

ACIは素材として便利、でも
シンプルさが特徴な反面、手厚さには欠ける
アプリやコンテナーに手を入れずHTTPS(TLS)化したい
スケールアウトしたい (コンテナーのレプリカを増やす)
バージョンアップ/戻しをもっと安全にしたい
(ステージング環境でテストしてから切り替えたいなど)
より手厚くサポートしてくれる基盤が欲しい
(コンテナーオーケストレーター)

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の仮想ノードと
しても利用可能

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

Azure Web App for Containers
Kubernetesまでは要らないWebアプリケーションに
歴史あるWebアプリケーションPaaS
PaaSらしく、構築、デプロイ、運用が非常に楽
HTTPS(TLS)化、自動スケールアウト、デプロイメントスロット切替
2017年、Dockerコンテナーのデプロイに対応
アプリの公開可能ポートが80/443のみ、という制約を受け入れられれ
ば、強力な選択肢
AKSは次回(応用編)のテーマとし、本日はこちらを演習

Azure Web App for Containers
演習

$ cd $HOME/clouddrive/conteriner-handson/primer/ch03/
(./set_env.shを開き、ch02と同じになるようprefixを編集、保存)
$ . ./set_env.sh
演習用ディレクトリへ移動し環境変数を設定

#!/bin/bash
az group create -n $RG_CH03 -l japaneast
$ ./create_rg.sh
リソースグループを作成

$ cat ./create_disphostname_container_on_appsvc.sh
#!/bin/bash
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の土台)を作成

(続き)
az webapp create ¥
-g $RG_CH03 ¥
-p ${RG_CH03}-appsvcplan ¥
-i ${ACR}.azurecr.io/disp-hostname:0.0.1
az webapp config container set ¥
-g $RG_CH03 ¥
--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の認証情報を設定

Webブラウザーで確認
HTTPS(TLS)化さ
れている
URLはWeb App作成スクリプトの出力
から (ポータルでも確認できます)

スケールアウト/自動スケール設定
ポータルで確認しましょう ([App Service] > [Web App])
後からインスタンス
数を変更できる
自動スケール設定も
可能

$ cat ./create_staging_slot.sh
#!/bin/bash
az webapp deployment slot create ¥
-g $RG_CH03 ¥
-s staging ¥
--configuration-source ${RG_CH03}-disphostname
(続く)
ステージングスロットを作成 (1/2)
先ほど作成したWeb Appのス
テージングスロットを作る

(続き)
az webapp config container set ¥
-g $RG_CH03 ¥
-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の認証情報を設定
コンテナーの新
バージョンを指定

Webブラウザーでステージングスロットを確認
URLはWeb App作成スクリプトの出力
から (ポータルでも確認できます)
バージョンが上がっている

$ cat ./swap_slot.sh
#!/bin/bash
az webapp deployment slot swap ¥
-g $RG_CH03 ¥
--slot staging ¥
--target-slot production
$ ./swap_slot.sh
スロットの入れ替え
ステージングスロットとプロダ
クションスロットを入れ替え

Webブラウザーで確認
入れ替わっている

おさらい
コンテナーをより使いやすくするためにオーケストレーターがある
Kubernetesがトレンドだが、アプリによっては、やや大げさ
Azure Web App for Containersは気軽に使えるPaaS基盤
HTTPS(TLS)化
スケールアウト、自動スケール
ステージングスロットを確認した上でリスク低く本番切り替え

$ cat ./cleanup.sh
#!/bin/bash
$ ./cleanup.sh

$ cd ../ch02
$ cat ./cleanup_acr.sh
#!/bin/bash
az group delete -n $RG_RGST
$ ./cleanup_acr.sh
おつかれさまでした (ACRも消します)

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

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

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

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

Plus de Toru Makabe

Plus de Toru Makabe (20)