Docker for Windows & Web Apps for Containers 実践活用技法
•
12 likes•4,432 views
この資料では、Docker for Windows を使って Windows OS 上で Linux ベースのアプリを開発する方法、そして Web アプリを含む Docker コンテナをクラウド環境（Azure 環境）に展開する方法について解説します。 ※ 本資料では Docker の Linux コンテナのみを取り扱います。（Windows コンテナは取り扱いません。Windows OS で使い慣れたエディタや開発環境を使いつつ、Docker for Windows を活用して Linux 上でデバッグを行う、というシナリオを扱っています。） ※ 資料の概要は以下の blog エントリを参照してください。 https://blogs.msdn.microsoft.com/nakama/2018/09/27/dockerandazure/
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Docker for Windows & Web Apps for Containers 実践活用技法
Similar to Docker for Windows & Web Apps for Containers 実践活用技法 (20)
Docker for Windows & Web Apps for Containers 実践活用技法
- 1. Docker for Windows & Web Apps for Containers 実践活用技法 日本マイクロソフト株式会社 クラウドソリューションアーキテクト 赤間 信幸 https://blogs.msdn.microsoft.com/nakama/ @nakama00
- 2. p.2 Agenda ◼ Module 1 Docker & Docker for Windows 概要 Docker とは何か Docker の動作の仕組み Docker の利便性 最も基本的な使い方 Docker コンテナの起動と停止の仕組み ステートフルマシンの作り方 Dockerfile の作り方 利用上の Tips & Tricks ◼ Module 2 クラウド環境への Docker イメージの展開 VSTS による Docker イメージのビルド Web Apps for Containers への Docker イメージの展開 ◼ （注意） 本資料は以下のような開発を行いたいケースを想定して作られています Windows OS 上のエディタ（VS Code や Eclipse など）を使ってコーディングする 作ったアプリは Linux OS 上で動作させる
- 3. Module 1 Docker & Docker for Windows 概要
- 4. p.4 Docker とは何か ◼ 主に Linux 界隈で利用されている、コンテナ技術のデファクトスタンダード コンテナ技術とは... ◼ OS 上で実行されている各プロセスを、隔離して動作させるための技術 ◼ 仮想マシンと異なり、複数のアプリを共存させる際のリソースオーバヘッドが少ない 通常の OS プロセスと Docker コンテナ（Docker プロセス）の違いは... ◼ OS はプロセスを使ってメモリ空間を隔離するが、互いのプロセスを認識でき、共通のフ ァイルシステムを利用する ◼ Docker コンテナを使うと、互いのプロセスは（論理的に）隔離され、ファイルシステムも（ 偽装されて）自分専用のファイルシステムを利用する形になる 物理ハードウェア OS サーバ アプリ OS サーバ アプリ OS サーバ アプリ 物理ハードウェア OS （Linux） サーバ アプリ サーバ アプリ サーバ アプリ プロセス OS 仮想マシン Docker コンテナ 隔離 隔離 隔離 隔離 Web サーバや AP サーバなど 物理ハードウェア 物理ハードウェア OS （Linux） サーバ アプリ サーバ アプリ サーバ アプリ Docker コンテナ 隔離 隔離 OS （Linux） サーバ アプリ サーバ アプリ サーバ アプリ 通常のプロセス 仮想マシンと Docker コンテナの違い 通常のプロセスと Docker コンテナの違い • Docker では Windows コンテナと Linux コンテナの取り扱いが可能だが... • 本資料では、実際に現場で活用されることになる Linux コンテナに絞って 解説する（特に断りがない限り、コンテナ＝Docker の Linux コンテナ）
- 5. p.5 Docker の基本的な特徴① ディストリビューションの抽象化 ◼ Docker を利用すると、Linux のディストリビューションを抽象化できる （復習） Linux のディストリビューションとは... ◼ RHEL や Ubuntu、CentOS などは、共通の Linux カーネルをベースに、様々なツール やユーティリティを加えてパッケージ化されて作られている ◼ 代表的なものとして、Debian 系、Red Hat 系、Slackware 系などがある ひとことで Linux といっても、ディストリビューションが異なると、シェルやパッケージシ ステムなどが大きく変わるため、別 OS に近い状況となる ◼ このため、ソフトウェアも各ディストリビューションごとにパッケージやインストール手順 が用意されている Windows OS の場合、Home/Pro/Enterprise どれでも .msi パッケージだが... Linux OS の場合、ディストリビューションによりパッケージ管理方法がバラバラ ◼ 具体例） Linux 用 ASP.NET Core ランタイムの場合 RHEL, Ubuntu, Debian, Fedora, CentOS などでインストール パッケージや手順が全部バラバラ モノによってはバージョンによってもインストール手順が異なる Debian 系 Red Hat 系 Slackware 系 その他（軽量系） 商用 Linux - RHEL Oracle Linux - - コミュニティ Linux Ubuntu, Debian CentOS Fedora Slackware OpenSUSE Alpine Linux CoreOS パッケージ管理 deb 形式 RPM slackpkg -
- 6. p.6 Docker の基本的な特徴① ディストリビューションの抽象化 しかし Docker を使うと、同じマシン上で異なるディストリビューションを使ってアプリを 動作させることができる ◼ Linux 上でのシステム開発では、様々なミドルウェアやランタイムが利用される AP サーバ : Java/J2EE, Node.js, RoR, PHP, Perl, ASP.NET Core, etc... DB サーバ : MySQL, PostgreSQL, MariaDB, Oracle, SQL Server for Linux, etc... ◼ こうした様々なミドルウェアやランたむは、必ずしもすべてのディストリビューション上で の動作をサポートしているわけではない（うまくインストールできないことすらある！） ◼ Docker を利用すると、こうした状況を容易に簡単化することができる 同じ 1 台の Linux マシン上で... ▪ Node.js は CentOS ディストリビューション上で動作させる ▪ RoR は Ubuntu ディストリビューション上で動作させる Docker Engine Linux Kernel Linux サーバアプリ ミドルウェア イメージ ディストリ ビューション イメージ 自作の Web アプリ A Node.js CentOS 自作の Web アプリ B RoR Ubuntu OS カーネル（Linux カーネル）は どのディストリビューションでも共通 Docker コンテナ Docker コンテナ Docker コンテナ インフラ目線で考えると、 Docker を載せられるインフラを 用意しておけば、多彩なアプリを 受け入れ可能になる 仮想マシンと同様に 自分専用のディスク イメージを使って 動作する
- 7. p.7 Docker の基本的な特徴② オフィシャルイメージの活用 ◼ Docker Hub のイメージを活用すると、インストールやパッチ適用の手間が激減 Linux でシステムを構築する場合、一般的に以下の作業が非常に大変 ◼ OS （ディストリビューション）上へのミドルウェアやアプリのインストール作業 ディストリビューションごとに手順が異なり、微妙なバージョンずれで動作しなくなる ◼ アプリ展開後のパッチ適用作業 パッチ適用も標準化されていないため、手順書の作成なとが必要 Docker Hub 上にオフィシャル及びコミュニティベースの様々なイメージが作成・公開・ 共有されており、これらを活用するとインストールやパッチ適用の手間を激減できる ◼ アプリインストール済みのイメージが配布されているため、これを取得して、自分用のア プリや設定を加えて動かすだけでよい Docker Engine Linux Kernel 自作アプリや 設定ファイル ミドルウェア イメージ ディストリ ビューション イメージ 自作の Web アプリ Node.js CentOS 自分用の 設定ファイル Redmine Ubuntu Docker コンテナ Docker コンテナ Docker コンテナ Docker Hub から 公式イメージを 取ってきて使う Docker Hub https://hub.docker.com/ ※ Docker を活用したパッチ適用の容易化の詳細については後述 Windows では それほどでも ないが、Linux の 場合は圧倒的に 大変！
- 8. p.8 Docker の基本的な特徴③ 環境の抽象化 ◼ Docker を利用すると、Linux アプリのポータビリティを確保できるようになる 様々なサーバや環境に、同じ Docker コンテナイメージを展開できる ◼ 例1. 様々なクラウドへの同一イメージの配置 同じ Docker コンテナイメージを、AWS にも Azure にも配置できる ◼ 例2. 開発環境／テスト環境／運用環境への同一イメージの配置 開発環境でデバッグを終えた Docker イメージを、そのままテスト環境や運用環境で動 作させることができる これにより、アプリケーションやシステムのポータビリティを大幅に高めることができる ◼ ※ 環境ごとの差異（接続文字列など）は、環境変数の埋め込みなどにより吸収する ◼ ※ 実際にはコンテナ技術に加えて、オーケストレーション技術も必要（後述） 自作 アプリ PHP Module Apache httpd Debian Docker イメージ Docker Engine Linux Kernel 物理サーバマシン Docker Engine Linux Kernel 物理サーバマシン 自作 アプリ PHP Module Apache httpd Debian 自作 アプリ PHP Module Apache httpd Debian 自作 アプリ PHP Module Apache httpd Debian 自作 アプリ PHP Module Apache httpd Debian どちらのクラウドにも 展開可能！ 例1. クラウド環境の抽象化 例2. 配置環境の抽象化 Docker Engine Linux Kernel 物理サーバマシン Docker Engine Linux Kernel 物理サーバマシン 自作 アプリ PHP Module Apache httpd Debian 自作 アプリ PHP Module Apache httpd Debian 自作 アプリ PHP Module Apache httpd Debian 自作 アプリ PHP Module Apache httpd Debian 同じイメージを 利用可能 テスト環境 運用環境 （参考） （当然だが）カーネルバージ ョンや Docker Engine バージョンに 互換性がない場合には配置できない
- 9. p.9 Docker の基本的な特徴④ Docker for Windows による開発 ◼ Docker for Windows を利用すると、Windows OS 上での Linux アプリの開発 が非常に容易に行える Linux アプリを開発する際も、エディタやブラウザは Windows デスクトップを使った方 が便利 ◼ コーディングは Windows 環境、動作確認は Linux 環境で行えれば便利 Docker for Windows をインストールすると、以下のような環境が構築される ◼ Hyper-V + Core OS （Docker Engine が組み込まれた軽量 Linux OS） ◼ Windows 用 docker コマンドラインツール これらにより、Windows 上で実装したアプリを Hyper-V 上の Linux で動作確認できる ◼ Windows マシン 1 台で Linux アプリ開発ができるので便利！ 開発用マシン Hyper-V Windows 10 CoreOS Docker Image アプリケーション （Java など） STS Chrome VS Code ※ （参考）システム要件 • Windows 10 Pro または Enterprise （Hyper-V が使えること） • メモリは最低でも 8GB 以上を推奨 （Hyper-V 上の Linux の動作に必要 なメモリを確保するため）
- 10. p.10 Docker for Windows の基本的な利用方法 ◼ Docker for Windows による基本的なコンテナ作成と実行の流れは以下の通り 1. アプリを作成する 2. Dockerfile によりイメージの作成手順を記述する 3. Docker イメージを作成する 4. Docker コンテナを開始する 5. Docker コンテナを終了し、後片付けをする ◼ 以下では、すでに開発済みの Java Spring Boot アプリを、以下の形で Docker に載せて実行するケースを例に取って解説する Windows OS 上で、STS （Spring Boot 用 Eclipse）を使ってコーディング Linux OS 上の Java ランタイムを使ってアプリを実行 Windows OS 上の Chrome ブラウザから動作を確認する
- 11. p.11 Docker for Windows の基本的な利用方法 ◼ 1. Docker 上に載せる Java アプリケーションの作成 （本資料では、開発済みの Spring Boot サンプルアプリを利用する） 開発されたサンプルアプリは、以下のコマンドラインにより起動することができる ◼ java -jar ./target/azrefarc-springboot-0.0.1-SNAPSHOT.jar ◼ （参考） Spring Boot アプリのパッケージには Web サーバが組み込まれており、コマン ドラインから起動するとポート 8080 で呼び出すことが可能 ◼ ※ この方法では、Windows 版の Java 上で Spring Boot アプリが動作している ソースコード コンパイル Java パッケージファイル （azrefarc-springboot-0.0.1-SNAPSHOT.jar） java -jar ./target/azrefarc- springboot-0.0.1-SNAPSHOT.jar http://localhost:8080/ で 呼び出し ※（注意） この方法では、Windows 版の Java 上でアプリが動作している
- 12. p.12 Docker for Windows の基本的な利用方法 ◼ 2. Dockerfile の作成 （Docker イメージ構築手順の指定） 適当なフォルダ（通常はソースコードのルートフォルダ）にテキストファイルを作成 ◼ 名前は "Dockerfile" （先頭は大文字にすること） ◼ メモ帳などのテキストエディタを使って編集（エディタとして VS Code を使うと便利） Dockerfile に Docker イメージの構築手順を記述する ◼ Docker イメージ ≒ アプリを動かすためのディスクイメージ + 起動コマンドライン指定 ◼ 今回のケースの場合には... ① Docker Hub から OpenJDK のオフィシャルイメージを取得 ② アプリや設定をファイルコピー（イメージに追加） ③ 外部に公開するポートを指定（※ やや複雑なため、詳細は後述） ④ コンテナ起動時に実行するアプリの起動コマンドラインを指定 #① OpenJDK をベースにイメージ構築 FROM openjdk:8-jre-alpine #② 出来上がっている jar ファイルを、Docker コンテナのディスクイメージに取り込み COPY ./target/azrefarc-springboot-0.0.1-SNAPSHOT.jar /app/ROOT.jar #③ コンテナのポート 8080 を外に解放する予定であることを宣言 #※ EXPOSE コマンドを使っても、ホストからの接続には docker -p 引数が必要 EXPOSE 8080 #④ 特に引数指定がなかった場合には、コンテナ立ち上げ時に以下のコマンドを実行 CMD ["java", "-jar", "/app/ROOT.jar"] Dockerfile ① Docker Hub で配布されている、 OpenJDK 組み込み済みのディスク イメージを拾ってくる ② ディスクイメージ内に アプリをコピーする ③ この Docker イメージが起動された場合、自動起動 させるコマンドラインを指定 ※ CMD を使った場合は実行時に上書き可能（後述） メモ帳で編集してもよいが 、VS Code を使うと色がつ いてわかりやすい ざっくり 言えば...
- 13. p.13 Docker for Windows の基本的な利用方法 ◼ 2. Dockerfile の作成 （Docker イメージ構築手順の指定）（続き） （参考） 利用可能な Java ランタイムについて ◼ Docker Hub 上で、様々な Java ランタイムが公開・提供されている ◼ 商用でよく利用される Java ランタイムとしては以下の 3 つ ベースとなっているディストリビューションはそれぞれ異なるが... Docker であるため、特に気にする必要がない ◼ 通常は、以下のいずれかを利用すればよい openjdk:8-jre-alpine または openjdk:8-jdk-alpine ◼ 選び方のポイント JDK の種類 → 特にこだわりがなければ OpenJDK、必要に応じて他を選択 JRE/JRK の選択 → イメージを小さくするため、基本的に JRE を選択 ベースディストリビューション → イメージを小さくするため、Alpine Linux を選択 ◼ 詳細 → 以下のページがよくまとまっている 「最適な Java の Docker イメージを選びたい」 https://k11i.biz/blog/2018/05/17/base-docker-images-for-java/ ベースディストリビューション バージョン JRE/JDK Oracle Java Oracle Linux (RHEL ベース) 8 のみ JRE のみ OpenJDK Debian, Alpine Linux, Windows 7～11 JRE/JDK あり IBM Java Ubuntu, Alpine Linux 8～10 JRE/JDK/SFJ あり
- 14. p.14 Docker for Windows の基本的な利用方法 ◼ 3. Docker イメージの作成 Dockerfile ファイルと docker コマンドラインツールを使って、Docker イメージを作成 ◼ docker build -t <イメージ名> <Dockerfile へのパス> ◼ これにより、Windows OS 上で Linux のイメージファイルを作成することができる ◼ 初回実行時は Docker Hub からのイメージダウンロードに時間がかかる 作成されたイメージはローカルディスク上に保存される ◼ docker images コマンドにより確認できる C:¥Users¥nakama¥source¥repos¥AzRefArc.SpringBoot>docker build -t myjavaapp . Sending build context to Docker daemon 110.8MB Step 1/4 : FROM openjdk:8-jdk-alpine ---> cc2179b8f042 Step 2/4 : COPY ./target/azrefarc-springboot-0.0.1-SNAPSHOT.jar /app/ROOT.jar ---> Using cache ---> e5d742024522 Step 3/4 : EXPOSE 8080 ---> Using cache ---> 9fa6489ab147 Step 4/4 : CMD ["java", "-jar", "/app/ROOT.jar"] ---> Using cache ---> 137800a4d12c Successfully built 137800a4d12c Successfully tagged myjavaapp:latest SECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directories added to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions for sensitive files and directories. C:¥Users¥nakama¥source¥repos¥AzRefArc.SpringBoot> コマンドライン C:¥Users¥nakama¥source¥repos¥AzRefArc.SpringBoot>docker images REPOSITORY TAG IMAGE ID CREATED SIZE myjavaapp latest 137800a4d12c 12 hours ago 170MB openjdk 8-jdk-alpine cc2179b8f042 13 days ago 102MB 作成されたイメージファイル • 無指定の場合、自動的に "latest" タグが付与される • このため、正式名は "myjavaapp:latest" となる
- 15. p.15 Docker for Windows の基本的な利用方法 ◼ 4. Docker コンテナの起動 docker コマンドラインツールを使って、Docker コンテナを起動 ◼ docker run --name <コンテナ名> -it -rm -p <ホスト側ポート番号>:<コンテナ側ポート 番号> <イメージ名:タグ名> (上書きする実行コマンドライン) （参考） 主な Docker の起動オプションについて（株式会社ビヨンド様の blog） https://beyondjapan.com/blog/2016/08/docker-command-reverse-resolutions オプション 概要 備考 よく使うもの --name コンテナ名を付与する 無指定の場合は UUID 識別子 (68b89c08edda など) -it フォアグラウンド動作させ、コンソールへ出力する -p ホスト:コンテナ コンテナ内のポートをホスト側ポートにつないで公開 --rm コンテナ終了時にファイルシステムを消す デバッグしたい場合には消さずに残すとよい -e "key=value" 環境変数を設定する 必要に応じて使 うもの -d デタッチドモードで動作させる フォアグラウウンドで動作しない = Ctrl + C で止められない -c, -m など CPU やメモリの利用に制限をかける -v ホスト:コンテナ 共有ファイルシステムを利用する --restart=always コンテナが終了した際に、自動的にコンテナを再起動 C:¥Users¥nakama¥source¥repos¥AzRefArc.SpringBoot>docker run --name myjavaapp1 -it -p 5000:8080 myjavaapp:latest java -jar /app/ROOT.jar . ____ _ __ _ _ /¥¥ / ___'_ __ _ _(_)_ __ __ _ ¥ ¥ ¥ ¥ ( ( )¥___ | '_ | '_| | '_ ¥/ _` | ¥ ¥ ¥ ¥ ¥¥/ ___)| |_)| | | | | || (_| | ) ) ) ) ' |____| .__|_| |_|_| |_¥__, | / / / / =========|_|==============|___/=/_/_/_/ :: Spring Boot :: (v2.0.0.RELEASE) 2018-06-27 02:28:19.971 INFO 1 --- [ main] a.s.SpringBootSystemApplication : Starting SpringBootSystemApplication v0.0.1-SNAPSHOT on 68b89c08edda with PID 1 (/app/ROOT.jar started by root in /) コマンドライン 特に よく使う
- 16. p.16 Docker for Windows の基本的な利用方法 ◼ 5. Docker コンテナを終了し、後片付けをする フォアグラウンド動作している Docker コンテナは、Ctrl + C で停止させることができる ◼ この状態では、コンテナが停止している状態で、コンテナ自体は残っている コンテナ停止後、コンテナを削除することが可能 ◼ docker ps -a で、停止中のコンテナも含めたコンテナの確認が可能 ◼ docker rm <コンテナ名> にてコンテナを削除することが可能 コンテナ削除後、イメージを削除することが可能 ◼ docker images で、イメージの一覧を確認可能 ◼ docker rmi <イメージ名> にてイメージを削除することが可能 Ctrl + C で 停止させることができる ■ コンテナの一覧（停止のものも含む） docker ps -a ■ コンテナの削除 docker rm myjavaapp1 ■ イメージの一覧 docker images ■ イメージの削除 docker rmi myjavaapp コマンドライン 指定されている イメージのみ削除 （ダウンロードされた オフィシャルイメージ などは残る）
- 17. p.17 コンテナ コンテナ コンテナ Docker コンテナの起動と停止の仕組み ◼ イメージとコンテナの動きについては、以下のような仕組みになっている 一般的な仮想マシンとの対比で考えるとわかりやすい ◼ docker イメージ = 仮想マシンを動作させるためのディスク（起動コマンドつき） ◼ docker コンテナ = 仮想マシン ◼ docker コンテナの停止 = 仮想マシンの停止 ひとつの docker イメージから 複数の docker コンテナを起動 することができる ユーザー イメージオフィシャル イメージ オフィシャル イメージdocker build ユーザー イメージ オフィシャル イメージ プロセス 仕込まれている 起動コマンドにより プロセス開始 コンテナ ユーザー イメージ オフィシャル イメージ プロセス docker run docker run ひとつのイメージから 複数のコンテナを作って 起動させることが可能 docker stop docker start ユーザー イメージ オフィシャル イメージ docker stop docker start ユーザー イメージ オフィシャル イメージ すべてのプロセス停止 ディスクイメージは残る 再度、仕込まれている 起動コマンドにより プロセス開始 ディスクイメージを元に コンテナ（軽量仮想マシン）を 作成・起動する 同じイメージから コンテナを作っても 個別に扱われる Dockerfile を使って イメージを作成 docker rm コンテナ 削除 docker rmi イメージ 削除 docker rm
- 18. p.18 Docker コンテナの起動と停止の仕組み ◼ Docker コンテナのフォアグラウド動作について docker run または start に -it オプションをつけると、ターミナル接続した状態で起動 コンテナをターミナル接続した状態で起動（フォアグラウド動作）させた場合は... ◼ コンソールログが、コマンドラインにそのまま表示される ◼ Ctrl + C でプロセスを止めると、コンテナが停止する docker stop コマンドを使うことにより、コンテナを外部から止めることもできる ◼ 別コマンドプロンプトから、当該コンテナを停止させることもできる 具体例） ユーザー イメージ オフィシャル イメージdocker build myjavaapp:latest 開始 docker run --name myjavaapp1 -it -p 5000:8080 myjavaapp:latest インタラクティブモード ＆ ターミナル割り当て コンテナ停止 ① Ctrl + C でプロセ スを止めると、コンテ ナも停止状態になる ② 外部から docker stop myjavaapp1 と すると、プロセス停止 + コンテナ停止もう一つコマンド プロンプトを開く コンテナ ユーザー イメージ オフィシャル イメージ -d オプションでバックグラ ウンド動作させている場 合はこの方法で止める
- 19. p.19 Docker コンテナの起動と停止の仕組み ◼ 複数プロセスの起動について 通常は、1 コンテナ = 1 プロセスで動作させるが... 1 コンテナ内に複数プロセスを立てることもできる ◼ 例） 起動コマンドにより実行された PID = 1 のプロセスからの子プロセスの起動 ◼ 例） 外部から docker exec -it <コンテナ名> <コマンド名> で起動したプロセス 重要！ PID = 1 のプロセスが終了すると、自動的にコンテナが停止状態になる コンテナ（myjavaapp1） ユーザーイメージ （myjavaapp） オフィシャルイメージ （openjdk:8-jre-alpine） プロセス （PID=1） プロセス -it 起動コマンドにより 実行される PID = 1 のプロセス 外部からコンテナ内に 新しいプロセスを 立ち上げることが可能 プロセス 子プロセスを 起動可能 docker exec -it <コンテナ名> /bin/bash または /bin/sh docker run --name myjavaapp1 -it -p 5000:8080 myjavaapp:latest -it これらは同一の ディスクを共有して 動作する
- 20. p.20 Docker コンテナの起動と停止の仕組み ◼ コンテナの残留について docker stop コマンドを送る、あるいは PID = 1 のプロセスが停止すると、当該コンテ ナのプロセスがすべて停止される しかし、コンテナは残留する （= 仮想マシンをシャットダウンした状態に相当） ◼ 再度コンテナを起動することが可能（= 仮想マシンの起動に相当） ◼ コンテナが停止している状態の場合、docker exec コマンドで外部からプロセスを起動 することはできない （参考） docker commit コマンドを発行すると、イメージとして保存することができる ◼ ※ 普通は利用しない（イメージ構築は Dockerfile で自動化するのが基本であるため） ユーザー イメージ オフィシャル イメージdocker build myjavaapp:latest 開始 コンテナ停止 コンテナ ユーザー イメージ オフィシャル イメージ コンテナ（myjavaapp1） プロセス （PID=1） ユーザー イメージ オフィシャル イメージ 起動 ディスクへ 書き込み 変更 変更 docker rm コンテナ 削除 ユーザー イメージ オフィシャル イメージ 変更 docker commit 新しいイメージと して保存
- 21. p.21 Docker コンテナの起動と停止の仕組み ◼ 便利な処理コマンドについて 以下のようなコマンドをよく利用するため、適宜使うとよい 主な注意点として... ◼ コマンドライン引数は、ネットを検索すれば多数出てくるので、まず調べてみるとよい ◼ 一括処理は Linux と Windows とで記述方法が大きく異なる Linux Windows コンテナ起動 docker run -d --rm -v //c/temp:/temp:ro <コンテナ名> <コマンド> コンテナ内に入る docker exec -it <コンテナ名> /bin/bash または /bin/shbash コンテナ内の実行プロ セスを確認 docker exec -it <コンテナ名> ps ディスクイメージの出 力 docker create --name sql1 microsoft/mssql-server-linux:2017-latest docker export sql1 > sql1.tar コンテナ停止 docker kill $(docker ps -q) for /f %A in ('docker ps -q') do docker kill %A コンテナ全削除 docker rm $(docker ps -a -q) for /f %A in ('docker ps -aq') do docker rm %A イメージ全削除 docker rmi $(docker images -q) for /f %A in ('docker images -q') do docker rmi --force %A ※ イメージ全削除はオフィシャルイメージも全部消してしまうため注意
- 22. p.22 ステートフルマシンの作り方 ◼ 基本的に、コンテナインスタンスは使い捨てとし、データは保存しない ディストリビューションやランタイムにパッチが当たった際には、イメージを再構築＋再 展開する このため、コンテナインスタンスは使い捨てとするのが基本となる 結果として、コンテナインスタンスにはログデータなどを保存しないのが原則となる ユーザー イメージオフィシャル イメージ オフィシャル イメージdocker build コンテナ ユーザー イメージ オフィシャル イメージ プロセス docker run docker stop + docker rm コンテナ 削除 Dockerfile バージョンアップ （パッチ適用版の リリース） ユーザー イメージオフィシャル イメージ オフィシャル イメージdocker build コンテナ ユーザー イメージ オフィシャル イメージ プロセス docker run docker stop + docker rm コンテナ 削除 Dockerfile パッチ パッチ パッチ
- 23. p.23 ステートフルマシンの作り方 ◼ この点は以下の 2 つで問題になるが、それぞれ基本となる解決策がある ① ログ出力 ◼ ローカルディスクにログを保存しないのが基本となる ◼ ローカルディスクに一時保存したログデータを外部ストレージに非同期転送するか、最 初から Application Insights のような外部ログサービスを利用することで解決する ② データベースサーバ ◼ データベースサーバは Docker と非常に相性が悪いため、PaaS DB を使う ◼ 具体的には、SQL Database や MySQL/MariaDB/PostgreSQL as a Service などの PaaS を使う Web サーバ DB サーバ 運用管理 App Insights PaaS DB サービスDocker DB 部には Docker を使わないDocker Engine Linux Kernel コンテナ ユーザー イメージ オフィシャル イメージ プロセス コンテナ ユーザー イメージ オフィシャル イメージ プロセス ログデータは 外部保存 AP サーバに Docker を使う
- 24. p.24 ホストマシン ステートフルマシンの作り方 ◼ どうしてもデータの永続化が必要な場合には、以下のような方法を使う A. ホストマシンのディスク（フォルダ）を、コンテナに繋いで使う ◼ 例） ホストマシンの C:¥Users を /userdata にマウントして利用する場合 docker run -v C:/Users:/userdata1 -it centos:latest /bin/sh B. データ保存専用のボリュームを作成し、これをコンテナに繋いで使う ◼ 例） Docker 専用のボリュームを作成して繋いで使う場合 docker volume create myvolume docker run -v myvolume:/userdata2 -it centos:latest /bin/sh いずれの方法でも、コンテナを削除してもデータを残し続けることが可能 ◼ ただし、ホストマシン側のクラッシュには耐えられない → 前述の方法を使ってしまった 方が現実的にはラク ユーザー イメージ オフィシャル イメージdocker build myjavaapp:latest 開始 コンテナ（myjavaapp1） プロセス （PID=1） ユーザー イメージ オフィシャル イメージ 起動 変更 C:¥Users myvolume /userdata1 /userdata2 コンテナを消しても データが残る ※ 設定画面から 共有オプションの 指定が必要 （参考） 左記の方法以外に データボリューム コンテナを使う方法がある
- 25. p.25 Dockerfile の作り方 ◼ Docker イメージの作成方法としては、主に以下の 3 通りがある ① ホスト OS でコンパイルを行い、その結果だけを Docker 内にコピーする ② SDK を含む Docker 内にソースコードを持ち込み、当該環境内でコンパイルする ③ SDK を含む Docker 内にソースコードを持ち込んでコンパイルを行い、結果を実行 ランタイムだけを持つ Docker 内にコピーする コンテナ ユーザー イメージ 実行ランタイム イメージ ホストマシン ソースコード コン パイル バイナリ パッケージ ファイル 取り込み ユーザー イメージ 実行ランタイム イメージ 出力 コンテナ ユーザー イメージ SDK イメージ ホストマシン ソースコード ファイル 取り込み 出力 ユーザー イメージ オフィシャル イメージ コン パイル ユーザー イメージ SDK イメージ 実行時には 使わない Windows で コンパイル Linux で コンパイル コンテナ ユーザー イメージ SDK イメージ ホストマシン ソースコード ファイル 取り込み コン パイル コンテナ ユーザー イメージ 実行ランタイム イメージ ファイル 取り込み 出力 Linux で コンパイル イメージを 極小化 イメージが 大きい
- 26. p.26 Dockerfile の作り方 ◼ ① ホストマシンでコンパイルし、その結果だけをコンテナイメージ内にコピーする 最もオーソドックスな方法、通常はこの方法を利用すればよい 理由） Java や .NET の場合、コンパイルは Linux マシン上・Windows マシン上どちら であっても同じバイナリを出力するため コンテナ ユーザー イメージ 実行ランタイム イメージ ホストマシン ソースコード コン パイル バイナリ パッケージ ファイル 取り込み ユーザー イメージ 実行ランタイム イメージ 出力 Windows で コンパイル # OpenJDK をベースにイメージを構築 # jar バイナリを実行するだけであるため、JRE のみのイメージを利用 FROM openjdk:8-jre-alpine # すでに出来上がっている jar バイナリをホストマシンからからコンテナイメージに取り込み COPY ./target/azrefarc-springboot-0.0.1-SNAPSHOT.jar /app/ROOT.jar # コンテナのポート 8080 を外に解放する予定であることを示す EXPOSE 8080 # コンテナ起動時の実行コマンドを指定 CMD ["java", "-jar", "/app/ROOT.jar"] # ビルド方法 # C:¥Users¥nakama¥source¥repos¥AzRefArc.SpringBoot>docker build -t myjavaapp -f ./Dockerfile . # 実行方法 # docker run --name myjavaapp1 -i -p 5000:8080 myjavaapp:latest Dockerfile
- 27. p.27 Dockerfile の作り方 ◼ ② SDK を含むコンテナにソースコードを持ち込み、コンパイルして利用する ホストマシン側ではコンパイルできない場合や、ホストマシンとは異なる環境でコンパイ ルしたい場合に利用する ただし、この方法だとイメージが大きくなる → ③の方法を利用する # OpenJDK をベースにイメージを構築 # ビルドまで行うために jdk を利用 FROM openjdk:8-jdk-alpine # ホストマシンからコンテナにソースコードをコピー COPY . /source WORKDIR /source # 改行コード修正と実行権限の修正 RUN sed -i 's/¥r$//' mvnw RUN chmod 777 mvnw # ソースコードをビルド RUN ./mvnw clean package -DskipTests RUN mkdir /app RUN mv /source/target/azrefarc-springboot-0.0.1-SNAPSHOT.jar /app/ROOT.jar # コンテナのポート 8080 を外に解放する予定であることを示す EXPOSE 8080 # コンテナ起動時の実行コマンドを指定 CMD ["java", "-jar", "/app/ROOT.jar"] Dockerfile コンテナ ユーザー イメージ SDK イメージ ホストマシン ソースコード ファイル 取り込み 出力 コン パイル ユーザー イメージ SDK イメージ 実行時には 使わない Linux で コンパイル イメージが 大きい
- 28. p.28 Dockerfile の作り方 ◼ ③ コンテナでコンパイルした後、実行用のコンテナイメージを別途作成する マルチステージビルドと呼ばれる手法 実行イメージに不要なソースを残す必要がなく、サイズも極小化できる ユーザー イメージ オフィシャル イメージ コンテナ ユーザー イメージ SDK イメージ ホストマシン ソースコード ファイル 取り込み コン パイル コンテナ ユーザー イメージ 実行ランタイム イメージ ファイル 取り込み 出力 イメージを 極小化 # ビルドを行うために jdk を利用 FROM openjdk:8-jdk-alpine AS build # ソースコードをビルド COPY . /source WORKDIR /source # 改行コード修正と実行権限の修正 RUN sed -i 's/¥r$//' mvnw RUN chmod 777 mvnw RUN ./mvnw clean package -DskipTests # 最終イメージを作成 FROM openjdk:8-jre-alpine RUN mkdir /app WORKDIR /app COPY --from=build /source/target/azrefarc-springboot-0.0.1-SNAPSHOT.jar /app/ROOT.jar # コンテナのポート 8080 を外に解放する予定であることを示す EXPOSE 8080 # コンテナ起動時の実行コマンドを指定 CMD ["java", "-jar", "/app/ROOT.jar"] Dockerfile Linux で コンパイル JDK を利用 JRE を利用 ビルド用コンテナから コンパイル結果を コピー
- 29. p.29 Dockerfile の作り方 ◼ 主な Dockerfile コマンドについて よく利用する Dockerfile コマンドは下記の通り 細かい使い方についてはオフィシャルドキュメントやネットを参照するとよい コマンド 機能 FROM ベースイメージを指定 COPY ファイルをコピー WORKDIR 作業ディレクトリを変更 RUN コマンドを実行 EXPOSE 実行時に外部に晒すポート番号を指定 CMD コンテナ起動時に実行するコマンドを指定 ENV 環境変数を設定 VOLUME 外部のボリュームをマウント USER コンテナで利用するユーザ ID LABEL イメージへメタデータを追加 ADD ファイルをコピー (gzip などの展開や Web 取得機能つき) 特によく使うもの
- 30. p.30 Dockerfile の作り方 ◼ 注意！ コンテキスト（docker build 時のカレントディレクトリ）について Docker イメージをビルドする際、コンテキストを指定する必要がある ◼ docker build -t <イメージのタグ名> -f <Dockerfile> <コンテキスト> ◼ 例） docker build -t myjavaapp -f ./Dockerfile . Dockerfile 内の COPY コマンドなどは、コンテキストとして指定したディレクトリからの 相対パスとして実行される 具体例） ◼ 以下を実行した場合 ◼ C:¥Users¥nakama¥source¥repos¥ AzRefArc.SpringBoot>docker build -t myjavaapp -f ./Dockerfile . FROM openjdk:8-jdk-alpine # ホストマシンからコンテナにソースコードをコピー COPY . /source WORKDIR /source # ソースコードをビルド RUN ./mvnw clean package -DskipTests RUN mkdir /app RUN mv /source/target/azrefarc-springboot-0.0.1-SNAPSHOT.jar /app/ROOT.jar Dockerfile コンテナ ユーザー イメージ SDK イメージ ホストマシン ソースコード ファイル 取り込み コン パイル . （ドット） （カレント ディレクトリ） ファイル 取り込み mv コマンド mkdir コマンド
- 31. p.31 Dockerfile の作り方 ◼ その他の Dockerfile の作成例 参考） ASP.NET Core Web アプリケーションの場合 ◼ Web アプリプロジェクト内に Dockerfile ファイルを作成 ◼ マルチステージビルドを利用 ◼ 発行（publish）されたファイルのみをイメージに取り込んで利用する FROM microsoft/aspnetcore:2.0 AS base WORKDIR /app EXPOSE 80 FROM microsoft/aspnetcore-build:2.0 AS build WORKDIR /src COPY . /src RUN dotnet build . -c Release -o /app FROM build AS publish RUN dotnet publish . -c Release -o /app FROM base AS final WORKDIR /app COPY --from=publish /app . # ENTRYPOINT ではなく CMD で書いておく（コマンドラインでの上書きができる） CMD ["dotnet", "AzRefArc.AspNetCore.WebApp.dll"] # イメージビルド # C:¥Users¥nakama¥source¥repos¥AzRefArc.AspNetCore¥AzRefArc.AspNetCore.WebApp>docker build -t azrefarcaspnetcore . # イメージデバッグ コンテナ内ポート 80 をホスト側の 8080 へ接続 # docker run --name azrefarcaspnetcore1 -it -p:8080:80 azrefarcaspnetcore Dockerfile
- 32. p.32 Dockerfile の作り方 ◼ その他の Dockerfile の作成例 参考） 開発用のデータベースサーバを Docker で立てる場合 ◼ 開発中に利用するデータベースとして、PaaS のデータベースを使う方法もあるが... ◼ Docker コンテナを使い、各マシンでデータベースを立ち上げてしまう方法もある 具体的な Dockerfile の書き方 → ネット上の様々なサンプルを参照 ◼ SQL Server for Linux Windows 版コンテナの場合は環境変数を利用したデータベースアタッチが可能だが... Linux 版コンテナではこれがサポートされていないため、データベースアタッチの処理に 工夫が必要（以下の URL が参考になる） https://github.com/DataGrip/docker-env/tree/master/mssql-server-linux ◼ MySQL, PostgreSQL ネット上に多数情報が存在するため、探してみるとよい ホストマシン コンテナ コンテナ 開発環境（Eclipse など） ブラウザ（Chrome など） ユーザ アプリ ビルドして 実行 呼び出して 動作確認 開発用 DB JRE SQL Server for Linux クラウド上の PaaS DB 社内からだと TCP 接続が ブロックされる 場合あり！ 開発用の DB サーバを Docker で 立ててしまう ※ それぞれを単独で起動すると 相互通信できない → docker-compose を使う（次ページ）
- 33. p.33 利用上の Tips & Tricks ◼ Docker Compose によるマルチコンテナ構成について ひとつの物理 PC 内に、複数のコンテナを立てて利用することができる ◼ 例） Web アプリケーションの開発の際に、Web サーバと DB サーバを立てる ◼ このような構成をマルチコンテナ構成と呼ぶ 開発マシン上でのマルチコンテナの起動には、Docker Compose を利用すると便利 ◼ docker-compose.yaml ファイルに、マルチコンテナの構成を記述（→ 次ページ） ◼ docker-compose up により、マルチコンテナを起動 ◼ docker-compose rm で作成した全コンテナを削除 ホストマシン コンテナ コンテナ ブラウザ ブラウザ（Chrome など） ユーザ アプリ 呼び出して 動作確認 開発用 DB JRE SQL Server for LinuxDocker 用 ローカルブリッジ docker- compose docker-compose.yaml （マルチコンテナの構成ファイル） Docker-Compose を使うと 簡単に相互通信させられる （同じ内部ブリッジに接続、 内部 DNS サービスの利用が可能）
- 34. p.34 ◼ Docker Compose によるマルチコンテナ構成について（続き） 例） docker-compose.yaml ファイル ◼ DB コンテナ、アプリコンテナはそれぞれ Dockerfile で作成 version: '3.4' # docker-compose yaml ファイルのバージョンの指定 services: sqlserver: build: context: ./database dockerfile: ./Dockerfile container_name: sqldb1 ports: - "1433:1433" tty: true stdin_open: true app: build: context: . dockerfile: ./Dockerfile container_name: springbootapp1 depends_on: - sqlserver links: - "sqlserver:sqldb1" # コンテナ間接続を有効にする environment: # https://docs.microsoft.com/ja-jp/sql/connect/jdbc/building-the-connection-url?view=sql-server-2017 SPRING_DATASOURCE_URL: "jdbc:sqlserver://sqldb1:1433;databaseName=pubs" SPRING_DATASOURCE_USERNAME: "sa" SPRING_DATASOURCE_PASSWORD: "password" ports: - "5000:8080" tty: true stdin_open: true docker-compose.yaml 利用上の Tips & Tricks docker-compose.yaml （マルチコンテナの構成ファイル） Dockerfile （アプリサーバ用） Dockerfile （DB サーバ用） sqlserver コンテナを sqldb1 という名前で 呼び出せるようにする Docker イメージの 環境変数を上書き
- 35. p.35 利用上の Tips & Tricks ◼ Docker Compose によるマルチコンテナ構成について（続き） マルチコンテナの起動について ◼ docker-compose up コマンドにより、コンテナをまとめて起動することができる 注意！ 各コンテナのサービス起動待ち制御は、自力で作り込む必要がある ◼ docker-compose.yaml の depends_on で、コンテナの起動順序制御ができるが... ◼ コンテナ内のサービスの起動完了を待機してくれるわけではない ◼ もしコンテナ内のサービスの起動完了の待機が必要な場合には、エントリポイントの処 理の中に待機のためのコードを書く必要がある SQL Server の コンテナが起動 サービスが完全に 起動しきるより前に アプリのコンテナが起動 DB の前にアプリが起 動してしまい、起動に 失敗することがある 具体例）Docker Compose でMySQLが起動するまで待つ https://qiita.com/ry0f/items/6e29fa9f689b97058085 具体例）docker-composeでDBの起動完了を待ってからWeb アプリを実行する https://qiita.com/shiena/items/47437f4f7874bf70d664 具体例）Compose の起動順番を制御 http://docs.docker.jp/compose/startup-order.html
- 36. p.36 利用上の Tips & Tricks ◼ Docker Compose によるマルチコンテナ構成について（続き） その他の注意点について ◼ 初回実行について docker-compose up コマンドの初回実行時は、コンテナのビルドが行われるが... 2 回目以降は、イメージの再作成は特に行われず、コンテナインスタンスの作成だけが 行われる（＝ショートカットされる） コンテナイメージの再作成が必要な場合には、イメージの削除が必要 ◼ マルチコンテナの停止と再開について Ctrl + C で Docker Compose を停止すると、コンテナは削除されず、停止状態になる ここから docker-compose up を行うと、停止されているコンテナが再開される（＝コン テナインスタンスの再作成は行われない） コンテナインスタンスの再作成が必要な場合には、docker-compose rm によりコンテナ インスタンスを一度削除してからやり直す docker-compose up を行うと、 • 初回はイメージの作成が行われる • 2 回目はイメージ作成は省略される イメージ再作成のためには、イメージを 削除する必要がある
- 37. p.37 利用上の Tips & Tricks ◼ Dockerfile によるイメージ構築の途中で失敗した場合のデバッグについて コンテナインスタンスが動作中か停止中かで、利用できる手法が変わってくる コンテナインスタンスが止まっていない場合 ◼ コンテナ内にシェルを立ち上げて、中身を確認するのが簡単 コンテナインスタンスが止まってしまっている場合 ◼ ファイルコピーなどのケアレスミスが疑われる場合は、ファイルを取り出してみる ◼ そうでない場合は、いったんイメージをコミットし、別のコンテナインスタンスとして立ち上 げ直して中を見てみるとよい コンテナの 状態 デバッグ手法 コマンド 動作してい る コンテナ内にシェルで入って 確認する docker exec -it <コンテナ名> /bin/bash または /bin/sh CPU やメモリの利用状況を 確認する docker stats <コンテナ名> 停止してい る ファイルを取り出して確認する docker cp <コンテナ名>:/ファイルパス C:¥ローカルパス いったんイメージコミットして シェルで入る docker commit <コンテナ名> broken docker run -it broken /bin/bash または /bin/sh
- 38. Module 2 クラウド環境への Docker イメージの展開
- 39. p.39 クラウド環境への Docker イメージの展開 ◼ クラウド環境への Docker イメージの展開について解説する オーケストレーション技術の必要性 Docker イメージを利用する場合の CI/CD ワークフロー Azure Container Registry へのイメージ登録 VSTS ビルドによる Docker イメージのビルド Web Apps for Containers への Docker イメージの展開
- 40. p.40 オーケストレーション技術の必要性 ◼ 実際に Docker を使って『システム』を組み上げるには、周辺の自動化の仕組み が必要になる 例えば... ◼ 複数（台数・種類）の Docker イメージの一括配置 ◼ ロードバランサの自動構成、オートスケール機能 ◼ モニタリングと障害発生時の自動フェイルオーバの仕組み これらを行うサービスを、「オーケストレーション」サービスと呼ぶ ◼ 複雑なコンピュータシステム・ミドルウェア・サービスの配置・設定・管理を自動化するサ ービスのこと ◼ ベンダー固有のもの、Docker 社が提供するものなど様々なものがある オーケストレーション ツール 展開・管理サービス Mesos/Marathon, Docker Swarm, Google Kubernetes クラスタ状態管理 ZooKeeper, Consul, etcd ゲートウェイ（ロードバ ランス） nginx, HAProxy 展開・管理サービス ロードバランサ Docker Engine Linux Kernel 物理サーバマシン Docker Engine Linux Kernel 物理サーバマシン Docker Engine Linux Kernel 物理サーバマシン ロードバランサ Docker Engine Linux Kernel 物理サーバマシン Docker Engine Linux Kernel 物理サーバマシン Docker Engine Linux Kernel 物理サーバマシン サーバ負荷状況を見 てオートスケール 空きノードを見つけて 適切に展開 ロードバランサ も自動構成 1 つのシステムパッケ ージとして管理 障害監視を行い、障 害時は自動復旧
- 41. p.41 オーケストレーション技術の必要性 ◼ オーケストレーションサービスの動向について 2018 年 8 月現在、様々なサービスが存在している状況 ◼ 以下のようなまとめが詳しい Docker・Kubernetes 周辺の動向を整理してみた件 ▪ https://qiita.com/mamomamo/items/e4e9e44d9f77cd72b70a エンタープライズコンテナプラットフォーム、どれがええねん ▪ https://speakerdeck.com/jyoshise/entapuraizukontenapuratutohuomu- doregaeenen ◼ ざっくり言えば、以下のような傾向にある オープンなオーケストレーション技術は Kubernetes （クーベネティス）に収斂しつつあ る Kubernetes を PaaS 化した技術が各クラウドベンダーから提供されつつある ◼ 具体例） AKS （Azure Kubernetes Services）、Amazon EKS （Amazon Elastic Container Service for Kubernetes）、Google Kubernetes Engine など 一方、Kubernetes 自体には以下の難点がある ◼ 現時点ではまだ発展途上 （機能的にも信頼性的にも十分に枯れているとは言えない） ◼ MSA（マイクロサービスアーキテクチャ）向けプラットフォームであり、シンプルな Web- DB 型システムに使うには、やりすぎ感がある このため、Azure Web Apps for Containers などのシンプルな PaaS 系コンテナサー ビスを使った方が良い場合も多い
- 42. p.42 オーケストレーション技術の必要性 ◼ Kubernetes と Web Apps for Containers の違いについて Kubernetes は POD と呼ばれる単位で複数のサービスを一括展開できる ◼ このため、MSA （マイクロサービスアーキテクチャ）ベースで設計されたマイクロサービ スを一括して配置していくことができる（→ 次ページ参照） Azure Web Apps for Containers は、ロードバランサ + クラスタ化された Docker コン テナを構成することしかできない ◼ Web-DB 型システムにおける Web 部のように、物理 1 階層分の配置しかできない ◼ このため、必要となる予備知識がほとんどなく、すぐさまシンプルに使うことができる 出典） https://github.com/kubernetes/kubernetes/blob/release- 1.3/docs/design/architecture.md ロード バランサ http://app-a.azurewebsites.net/ http://app-b.azurewebsites.net/ B A A B B A Web Apps for Containers 共用 C C C D D D Docker アプリ を配置可能 ロードバランサ によるルーティン グと負荷分散 Kubernetes （AKS, EKS など） Azure Web Apps for Containers 複数のサービ スでインフラを 共用できる
- 43. p.43 オーケストレーション技術の必要性 ◼ （参考） マイクロサービスアーキテクチャ, Docker, Kubernates について 機械学習などのシステムでは、Polyglot な開発が必要になる場合がある ◼ システム全体を、区切りのよいマイクロサービスに分割した上で... ◼ フロントエンドは C#、AI は Python、バックエンドは Java など、最適な言語で開発し... ◼ これらを Web API でつないでシステム全体を開発していく このような Polyglot 型のマイクロサービスアーキテクチャベースのシステムでは、 Docker や Kubernates が非常に役立つ ◼ Docker : ひとつの仕組みで多 彩な言語やランタイムに対応 可能 ◼ Kubernates : マイクロサービ スから構成されるシステムを まとめて展開・管理できる 逆にいえば、上記のようなニース がない場合には、MSA, Docker, Kubernates は「やりすぎ」になっ てしまう場合もある ◼ このため、必要性がはっきり しない場合には使わない方が よいことも多い
- 44. p.44 Docker イメージを利用する場合の CI/CD ワークフロー ◼ Docker イメージを利用する場合の CI/CD ワークフローは、次ページの通り ビルドサーバにおいて、コンパイル作業と Docker イメージ作成を行う 成果物はコンテナレジストリに登録し、そこから自動配置を行う ◼ このワークフローにおいて、自動ビルドマシンの構築方法が複数通りある ① Windows マシンで自動ビルドマシンを構築する方法 ◼ 開発環境と同様に、Windows マシンでコンパイル + Docker イメージを作成する方法 ◼ ビルドマシンに Docker for Windows のインストールが必要 ◼ コンパイル + Docker イメージの作成方法は、開発環境の場合とほぼ同じ ② Linux マシンで自動ビルドマシンを構築する方法 ◼ ビルドマシンを Linux マシンにしてしまい、Docker をネイティブに使う方法 ◼ コンパイル作業を Linux 上で行う必要があることに注意が必要 ③ （参考） Windows マシンで自動ビルドマシンを構築するが、コンパイルは Linux Docker 上で行う方式 ◼ ①と②を組み合わせたような形 ◼ Dockerfile に若干の工夫が必要 ◼ これらについて、順に解説する
- 45. p.45 デベロッパー ソースコード レポジトリ 自動ビルド・リリース VSTS Git 変更 CI （自動ビルド）ソースコード ソースコード Docker イメージ コンパイル＋ イメージ作成 コンテナ レジストリ ACR DockerHub 上の 公式イメージ カナリア 環境 CD （自動配置） 静的コード 解析 Web Apps for Containers SQL Database テスト 環境 Web Apps for Containers SQL Database ステージング ・本番環境 Web Apps for Containers SQL Database Web Apps for Containers 実装環境 コンテナ利用時の CI/CD （DevOps） ワークフロー ユーザ F/B データベース 機能追加・ 修正の提案 お客様 運用 チーム 稼働状況データ テレメトリ データ Application Insights お客様からの F/B・クレーム受付 プロアクティブな データ解析 お客様・ 開発チーム （開発進捗確認） 通常は Windows PC Windows or Linux
- 46. p.46 ◼ 事前準備 ： ACR （Azure Container Registry）の作成 コンテナイメージを保存するためのプライベートリポジトリを ACR により準備する ◼ Azure ポータルサイトからコンテナを準備する コンテナにリポジトリを作成し、タグをつけてイメージをアップロードして使う ◼ 通常は、以下のように設計して使う コンテナ名 = VSTS アカウント名 リポジトリ名 = プロジェクト名やソリューション名 タグ = イメージのバージョン番号 azrefarc 106 107 108 23 24 VSTS ビルドによる Docker イメージのビルド ACR（Azure Container Registry） azrefarc.springboot コンテナ リポジトリ タグ azrefarc.aspnetcore azrefarc.azurecr.io/azrefarc.springboot:107 azrefarc.azurecr.io/azrefarc.springboot:106 イメージの参照名 （レジストリホスト/名前:タグ） azrefarc.azurecr.io/azrefarc.springboot:108 azrefarc.azurecr.io/azrefarc.aspnetcore:23 azrefarc.azurecr.io/azrefarc.aspnetcore:24 VSTS アカウント名 VSTS プロジェクト名や ソリューション名 イメージの バージョン番号
- 47. p.47 VSTS ビルドによる Docker イメージのビルド ◼ ① Windows マシンで自動ビルドマシンを構築する方法 いくつかの方法があるが、オンプレミスの物理マシンを使って構築する方法を推奨 ◼ A. オンプレミスの物理マシンを使って構築する方法 （推奨） ◼ B. オンプレミスの仮想マシン上に Nested Hyper-V を使って構築する方法 ◼ C. Nested Hyper-V をサポートする IaaS マシン上に構築する方法 以下は利用不可 ◼ Hosted VS2017 ビルドマシンの利用（※ Windows コンテナモードで Docker が動作し ているため） Docker for Windows は Nested Hyper-V をサポ ートしていないため A. 物理マシンそのものに Hyper-V + Docker for Windows と Java, Maven などをインストールして ビルドマシンにする（推奨） B. Nested Hyper-V を使い、仮想マ シンに Hyper-V + Docker for Windows, Java, Maven などをイン ストールしてビルドマシンにする （動作するが推奨しない）
- 48. p.48 VSTS ビルドによる Docker イメージのビルド ◼ ① Windows マシンで自動ビルドマシンを構築する方法（続き） オンプレミスの物理マシンで自動ビルドマシンを構築する場合は、以下の作業を行う ◼ Hyper-V を有効化し、Docker for Windows をインストール（Linux コンテナを利用） ◼ Java をインストールし、JAVA_HOME 閑居ぅ変数を設定 JAVA_HOME=C:¥Program Files¥Java¥jdk1.8.0_181 ◼ zip 形式の Maven をダウンロードして c:¥ などに展開し、M2_HOME 環境変数を設定 M2_HOME=C:¥apache-maven-3.5.4 ◼ ※ SonarQube のエージェントのインストールは不要 自動ビルドプロセスにより自動的にセットアップされるため ◼ さらに、VSTS Agent Pool 設定画面より、エージェントをダウンロードしてセットアップ ビルドエージェントの Capability を確認し、 Java や Maven が識別 されていることを確認
- 49. p.49 VSTS ビルドによる Docker イメージのビルド ◼ ① Windows マシンで自動ビルドマシンを構築する方法（続き） 自動ビルド定義について ◼ Dockerfile の構成方法によって、自動ビルド定義が変わる ◼ ここでは、以下の流れで自動ビルドを行う場合を考える ビルドマシン上（＝コンテナ外）でコンパイル Dockerfile を使い、ユーザーイメージを作成 ACR にアップロード ◼ この場合は、右図のような流れのビルド定義となる （参考・注意） コンパイル結果に関しては、成果物として 発行しておくとよい（トラブルシュートの容易化や UI 自 動テスト用のバイナリ発行のため） コンテナ ユーザー イメージ 実行ランタイム イメージ ビルドマシン ソースコード コン パイル バイナリ パッケージ ファイル 取り込み ユーザー イメージ 実行ランタイム イメージ Dockerfile コンテナ レジストリ ACR コンテナ外で コンパイル VSTS Artifact 成果物として 発行 コンパイル コンパイル 成果物発行 イメージ作成 イメージ作成 まずビルド 続いてプッシュ プッシュ出力
- 50. p.50 VSTS ビルドによる Docker イメージのビルド ◼ ① Windows マシンで自動ビルドマシンを構築する方法（続き） 利用する Dockerfile について ◼ 下記のような Dockerfile を利用する ◼ ソースコードの一部として Dockerfile を管理しておく # jar バイナリを実行するだけであるため、JRE のみのイメージを利用 FROM openjdk:8-jre-alpine # すでに出来上がっている jar バイナリをホストマシンからからコンテナ # イメージに取り込み COPY ./target/azrefarc-springboot-0.0.1-SNAPSHOT.jar /app/ROOT.jar # コンテナのポート 8080 を外に解放する予定であることを示す EXPOSE 8080 # コンテナ起動時の実行コマンドを指定 CMD ["java", "-jar", "/app/ROOT.jar"] Dockerfile
- 51. p.51 VSTS ビルドによる Docker イメージのビルド ◼ ① Windows マシンで自動ビルドマシンを構築する方法（続き） Docker タスクの設定について ◼ 設定の切り替えで、イメージ構 築とイメージプッシュが可能 イメージ名の設定に注意 ◼ $(Build.Repository.Name) :$(Build.BuildId) を利用 ◼ これにより、ビルドごとに異な るタグが利用されるようになる 注意 : latest タグを使わない ◼ Docker Hub では、最新のイ メージを常に同じ名前でプル できるようにするため、latest タグが使われることがよくある ◼ しかし Web App の場合、タ グ名が同じだとイメージをプ ルしない ◼ また、どのバージョンが環境 に配置されているのかを正し く管理する必要がある ◼ このため、latest タグは使わ ないようにする $(Build.Repository.Nam e):$(Build.BuildId) イメージのビルド イメージのプッシュ
- 52. p.52 VSTS ビルドによる Docker イメージのビルド ◼ ② Linux マシンで自動ビルドマシンを構築する方法 Linux マシンを自動ビルドマシンにする場合には、Hosted Pipeline の利用が可能 ◼ Hosted Ubuntu 1604 などの利用が可能（Docker も搭載されている） ◼ ここでは簡単のため、Hosted Pipeline を利用してみることにする 基本的な考え方は、Windows マシンを使う場合と同じ ◼ ローカルマシン上で Maven を動作させてコンパイルを実施 ◼ コンパイル結果を取り込んだ Docker イメージを作成して発行 実行環境として Hosted Ubuntu 1604 を選択 Linux OS 上で Maven を動作させてパッケージを作成 Docker イメージの発行と ACR への発行を実施
- 53. p.53 VSTS ビルドによる Docker イメージのビルド ◼ ③ （参考） Windows マシンで自動ビルドマシンを構築するが、コンパイルは Linux Docker 上で行う方式 （Java などであれば問題ないが）Linux 上にしかコンパイラがないような場合に便利 マルチステージビルドを行う Dockerfile を作り、Docker コンテナ内でコンパイルも行う ユーザー イメージ オフィシャル イメージ コンテナ ユーザー イメージ SDK イメージ ビルドマシン ソースコード ファイル 取り込み コン パイル コンテナ ユーザー イメージ 実行ランタイム イメージ ファイル 取り込み 出力 Dockerfile コンパイル イメージ作成 Linux で コンパイル イメージ発行 コンテナ レジストリ ACRプッシュ FROM openjdk:8-jdk-alpine AS build COPY . /source WORKDIR /source RUN sed -i 's/¥r$//' mvnw RUN chmod 777 mvnw RUN ./mvnw clean package -DskipTests FROM openjdk:8-jre-alpine RUN mkdir /app WORKDIR /app COPY --from=build /source/target/azrefarc-springboot-0.0.1-SNAPSHOT.jar /app/ROOT.jar EXPOSE 8080 CMD ["java", "-jar", "/app/ROOT.jar"] Dockerfile コンパイル イメージを 極小化 イメージ作成 イメージ作成 イメージ作成 イメージ発行
- 54. p.54 ACR 上にアップロードされたイメージのデバッグについて ◼ ACR 上の Docker イメージは、ダウンロードしてローカルで利用することができる まずはローカルにダウンロードして実行してみるとよい うまく動作しない場合には、一般的な方法でコンテナのデバッグを行う ■ ACR へのログイン処理（ユーザ名・パスワードはポータルから入手） docker login -u azrefarc -p qvx83jOaVIRbUE174/mYlJsK6gW5iMjR azrefarc.azurecr.io ■ Docker イメージのダウンロード docker pull azrefarc.azurecr.io/azrefarc.springboot:126 ■ ダウンロードした Docker イメージからのコンテナ実行 docker run --name myjavaappfromacr1 -i -p 5005:8080 azrefarc.azurecr.io/azrefarc.springboot:126 コマンドライン ID・Pass を 確認 イメージを 確認 コンテナ名 リポジトリ名 タグ名
- 55. p.55 Web Apps for Containers への Docker イメージの展開 ◼ Web Apps for Containers を利用すると、Docker イメージを Web Apps 上に載 せて実行することができる Linux ベースの App Service Plan （サーバインフラ）を使っている場合、Docker イメー ジを載せることができる 参考・注意点について ◼ 他のユーザとサーバを共用することは許されていない Web Apps for Windows の場合、Free, Shared のプランが用意されているが... Web Apps for Linux, Containers に関しては、Basic 以上のプランしか利用できない 理由） Docker は隔離性が低いため ◼ マルチコンテナも実行可能 右図では、1 アプリ = 1 つの コンテナとして構成しているが... 1 アプリ = 複数コンテナとして 構成することも可能 Docker Compose, Kuber nates でアプリを作成する ことにより実施 ※ 本資料では解説しない ホスト OS （Linux） Ubuntu Apache + ランタイム アプリ Ubuntu Apache + ランタイム アプリ ディストリ ビューション ミドル ウェア アプリ ディストリ ビューション ミドル ウェア アプリ Docker エンジンによるプロセス隔離 ロード バランサ ビルトインイメージを 利用する場合 独自のコンテナイメー ジを利用する場合 Web Apps for Linux, Container 各アプリを Docker エンジンにより隔離 MS が用意・ 保守 ユーザが用意
- 56. p.56 Web Apps for Containers への Docker イメージの展開 ◼ Docker イメージを Web Apps 上に展開する場合には、Web Apps 作成時に利 用するレジストリ／イメージ／タグを指定する これにより Docker イメージが 自動的に Web Apps にプルさ れ、アプリが起動する ◼ さらに、アプリケーション設定を 追加すると、当該コンテナの環 境変数に反映される データベース接続文字列など の情報を適宜追加する ◼ ※ コンテナ内で実行されている Web アプリのポート番号が特殊 な場合は WEBSITES_PORT で指定する Docker コンテナ配 置設定 接続文字列の上書 き設定 コンテナ内で実行さ れている Web サー バのポート番号
- 57. p.57 Web Apps for Containers への Docker イメージの展開 ◼ コンテナの設定内容や Docker ログは、ポータルサイトから確認できる コンテナ配置の設 定を確認 Docker ログの確 認が可能 Kudu にログインし、 /home/LogFiles/kudu/trace を確認することも可能
- 58. p.58 Web Apps for Containers への Docker イメージの展開 ◼ VSTS から Web Apps for Containers への自動リリースについて "Azure App Service Deploy" タスクには、Docker イメージの展開機能も備わっている 以下を設定 ◼ App type : Linux Web App ◼ Image Source : Container Registry ◼ Registry or Namespace : azrefarc.azurecr.io （下線部は適切なコンテナ名に変更） ◼ Image : azrefarc.springboot （適切なリポジトリ名に変更） ◼ Tag : $(Build.BuildId) ◼ Startup Command : 必要があれば設定
- 59. p.59 Web Apps for Containers への Docker イメージの展開 ◼ VSTS から Web Apps for Containers への自動リリースについて（続き） 注意点 : この配置タスクはイメージを Pull する指示を出すだけで、完了を待たない ◼ このため、実際には配置がうまくいかなかったにもかかわらず OK 扱いとなってしまう 場合がある このため、配置タスクの後で、PowerShell タスクなどを使ってサーバの動作確認を行 うようにしておくとよい Pull の指示を出すだけ → 実際には失敗する 可能性がある $maxRetry = 10; while ($maxRetry -gt 0) { try { Invoke-WebRequest -TimeoutSec 30 -Uri "http://azrefarc-springboot-webapp-docker- dev.azurewebsites.net/" break; } catch { Write-Host "通信エラー" $maxRetry--; if ($maxRetry -lt 1) { throw; } Start-Sleep 10 } } コマンドライン 実際に URL を呼び出 してみて、正しく Web サーバが起動している かを確認する
- 60. p.60 Web Apps for Containers への Docker イメージの展開 ◼ （参考） Web Apps for Containers の Tips & Tricks について 以下のページがよくまとまっているため、一読を推奨 ◼ Things You Should Know: Web Apps and Linux ◼ https://blogs.msdn.microsoft.com/waws/2017/09/08/things-you-should-know-web- apps-and-linux/ ◼ https://docs.microsoft.com/ja-jp/azure/app-service/containers/app-service-linux- faq 主なものとしては... ◼ コンテナは各 Linux マシンにダウンロードされて動作している 既定では、クラスタリングされているマシン間でディスクは共有されていない WEBSITES_ENABLE_APP_SERVICE_STORAGE オプションを有効化すると、 /home ディレクトリにディスクがマウントされ、データが永続化される ◼ サーバ増減やマシンクラッシュ時のノード移動の際は、データが消失する オートスケールなどでサーバ台数が増減したり、マシンクラッシュでノードが移動したり すると、コンテナのローカルディスクに書き込みしたデータは消失する ◼ コンテナの起動に時間がかかる場合はタイムリミットを変更する WEBSITES_CONTAINER_START_TIME_LIMIT を設定（既定値は 230 秒、最大 1800 秒）
- 61. p.61 利用条件： • 本書に関するすべての権利は、Microsoft Corporationおよびその関連会社（以下、マイクロソフト）が保有しています。本書 は情報提供のみを目的としており、本資料に記載されている情報は、本資料作成時点での情報となります。 • 状況等の変化により、内容は変更される場合があります。マイクロソフトによる事前の承諾がない限り、本書の全部または一 部を複製、改変、翻案、再頒布、公衆送信、貸与、譲渡したり、第三者に開示または共有することは、認められません。 • マイクロソフトは、本書の内容について何ら保証するものではなく、本書の使用に関連してお客様、お客様の関連会社、また は第三者に生ずる間接的、付随的、結果的な損害（営業機会や営業情報の損失などを含む）について一切責任を負いませ ん。 • 本書の中で例として使用されている企業、名前およびデータは、特に記述がない限り、架空のものです。 MICROSOFT CONFIDENTIAL © 2015 Microsoft Corporation. All rights reserved.