Movatterモバイル変換

Docker for Windows & Web Apps forContainers 実践活用技法日本マイクロソフト株式会社クラウドソリューションアーキテクト赤間信幸https://blogs.msdn.microsoft.com/nakama/ @nakama00

p.2Agenda◼ 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 上で動作させる

Module 1Docker & Docker for Windows 概要

p.4Docker とは何か◼ 主に 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 コンテナ）

p.5Docker の基本的な特徴① ディストリビューションの抽象化◼ 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 - RHELOracle Linux- -コミュニティ Linux Ubuntu, Debian CentOSFedoraSlackwareOpenSUSEAlpine LinuxCoreOSパッケージ管理 deb 形式 RPM slackpkg -

p.6Docker の基本的な特徴① ディストリビューションの抽象化 しかし 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 EngineLinux KernelLinuxサーバアプリミドルウェアイメージディストリビューションイメージ自作のWeb アプリ ANode.jsCentOS自作のWeb アプリ BRoRUbuntuOS カーネル（Linux カーネル）はどのディストリビューションでも共通DockerコンテナDockerコンテナDockerコンテナインフラ目線で考えると、Docker を載せられるインフラを用意しておけば、多彩なアプリを受け入れ可能になる仮想マシンと同様に自分専用のディスクイメージを使って動作する

p.7Docker の基本的な特徴② オフィシャルイメージの活用◼ Docker Hub のイメージを活用すると、インストールやパッチ適用の手間が激減 Linux でシステムを構築する場合、一般的に以下の作業が非常に大変◼ OS （ディストリビューション）上へのミドルウェアやアプリのインストール作業 ディストリビューションごとに手順が異なり、微妙なバージョンずれで動作しなくなる◼ アプリ展開後のパッチ適用作業 パッチ適用も標準化されていないため、手順書の作成なとが必要 Docker Hub 上にオフィシャル及びコミュニティベースの様々なイメージが作成・公開・共有されており、これらを活用するとインストールやパッチ適用の手間を激減できる◼ アプリインストール済みのイメージが配布されているため、これを取得して、自分用のアプリや設定を加えて動かすだけでよいDocker EngineLinux Kernel自作アプリや設定ファイルミドルウェアイメージディストリビューションイメージ自作のWeb アプリNode.jsCentOS自分用の設定ファイルRedmineUbuntuDockerコンテナDockerコンテナDockerコンテナDocker Hub から公式イメージを取ってきて使うDocker Hub https://hub.docker.com/※ Docker を活用したパッチ適用の容易化の詳細については後述Windows ではそれほどでもないが、Linux の場合は圧倒的に大変！

p.8Docker の基本的な特徴③ 環境の抽象化◼ Docker を利用すると、Linux アプリのポータビリティを確保できるようになる 様々なサーバや環境に、同じ Docker コンテナイメージを展開できる◼ 例1. 様々なクラウドへの同一イメージの配置 同じ Docker コンテナイメージを、AWS にも Azure にも配置できる◼ 例2. 開発環境／テスト環境／運用環境への同一イメージの配置 開発環境でデバッグを終えた Docker イメージを、そのままテスト環境や運用環境で動作させることができる これにより、アプリケーションやシステムのポータビリティを大幅に高めることができる◼ ※ 環境ごとの差異（接続文字列など）は、環境変数の埋め込みなどにより吸収する◼ ※ 実際にはコンテナ技術に加えて、オーケストレーション技術も必要（後述）自作アプリPHP ModuleApache httpdDebianDockerイメージDocker EngineLinux Kernel物理サーバマシンDocker EngineLinux Kernel物理サーバマシン自作アプリPHP ModuleApache httpdDebian自作アプリPHP ModuleApache httpdDebian自作アプリPHP ModuleApache httpdDebian自作アプリPHP ModuleApache httpdDebianどちらのクラウドにも展開可能！例1. クラウド環境の抽象化例2. 配置環境の抽象化Docker EngineLinux Kernel物理サーバマシンDocker EngineLinux Kernel物理サーバマシン自作アプリPHP ModuleApache httpdDebian自作アプリPHP ModuleApache httpdDebian自作アプリPHP ModuleApache httpdDebian自作アプリPHP ModuleApache httpdDebian同じイメージを利用可能テスト環境運用環境（参考）（当然だが）カーネルバージョンや Docker Engine バージョンに互換性がない場合には配置できない

p.9Docker の基本的な特徴④ 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-VWindows 10CoreOSDockerImageアプリケーション（Java など）STSChromeVS Code※ （参考）システム要件• Windows 10 Pro または Enterprise（Hyper-V が使えること）• メモリは最低でも 8GB 以上を推奨（Hyper-V 上の Linux の動作に必要なメモリを確保するため）

p.10Docker 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 ブラウザから動作を確認する

p.11Docker 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.jarhttp://localhost:8080/ で呼び出し※（注意）この方法では、Windows版の Java 上でアプリが動作している

p.12Docker 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 を使うと色がついてわかりやすいざっくり言えば...

p.13Docker 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/JDKOracle 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 あり

p.14Docker 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.8MBStep 1/4 : FROM openjdk:8-jdk-alpine---> cc2179b8f042Step 2/4 : COPY ./target/azrefarc-springboot-0.0.1-SNAPSHOT.jar /app/ROOT.jar---> Using cache---> e5d742024522Step 3/4 : EXPOSE 8080---> Using cache---> 9fa6489ab147Step 4/4 : CMD ["java", "-jar", "/app/ROOT.jar"]---> Using cache---> 137800a4d12cSuccessfully built 137800a4d12cSuccessfully tagged myjavaapp:latestSECURITY WARNING: You are building a Docker image from Windows against a non-Windows Docker host. All files and directoriesadded to build context will have '-rwxr-xr-x' permissions. It is recommended to double check and reset permissions forsensitive files and directories.C:¥Users¥nakama¥source¥repos¥AzRefArc.SpringBoot>コマンドラインC:¥Users¥nakama¥source¥repos¥AzRefArc.SpringBoot>docker imagesREPOSITORY TAG IMAGE ID CREATED SIZEmyjavaapp latest 137800a4d12c 12 hours ago 170MBopenjdk 8-jdk-alpine cc2179b8f042 13 days ago 102MB作成されたイメージファイル• 無指定の場合、自動的に "latest" タグが付与される• このため、正式名は "myjavaapp:latest" となる

p.15Docker 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 : StartingSpringBootSystemApplication v0.0.1-SNAPSHOT on 68b89c08edda with PID 1 (/app/ROOT.jar started by root in /)コマンドライン特によく使う

p.16Docker 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コマンドライン指定されているイメージのみ削除（ダウンロードされたオフィシャルイメージなどは残る）

p.17コンテナコンテナコンテナDocker コンテナの起動と停止の仕組み◼ イメージとコンテナの動きについては、以下のような仕組みになっている 一般的な仮想マシンとの対比で考えるとわかりやすい◼ docker イメージ = 仮想マシンを動作させるためのディスク（起動コマンドつき）◼ docker コンテナ = 仮想マシン◼ docker コンテナの停止 = 仮想マシンの停止 ひとつの docker イメージから複数の docker コンテナを起動することができるユーザーイメージオフィシャルイメージオフィシャルイメージdocker buildユーザーイメージオフィシャルイメージプロセス仕込まれている起動コマンドによりプロセス開始コンテナユーザーイメージオフィシャルイメージプロセスdocker rundocker runひとつのイメージから複数のコンテナを作って起動させることが可能docker stopdocker startユーザーイメージオフィシャルイメージdocker stopdocker startユーザーイメージオフィシャルイメージすべてのプロセス停止ディスクイメージは残る再度、仕込まれている起動コマンドによりプロセス開始ディスクイメージを元にコンテナ（軽量仮想マシン）を作成・起動する同じイメージからコンテナを作っても個別に扱われるDockerfile を使ってイメージを作成docker rmコンテナ削除docker rmiイメージ削除docker rm

p.18Docker コンテナの起動と停止の仕組み◼ Docker コンテナのフォアグラウド動作について docker run または start に -it オプションをつけると、ターミナル接続した状態で起動 コンテナをターミナル接続した状態で起動（フォアグラウド動作）させた場合は...◼ コンソールログが、コマンドラインにそのまま表示される◼ Ctrl + C でプロセスを止めると、コンテナが停止する docker stop コマンドを使うことにより、コンテナを外部から止めることもできる◼ 別コマンドプロンプトから、当該コンテナを停止させることもできる 具体例）ユーザーイメージオフィシャルイメージdocker buildmyjavaapp:latest開始docker run --name myjavaapp1-it -p 5000:8080 myjavaapp:latestインタラクティブモード＆ターミナル割り当てコンテナ停止① Ctrl + C でプロセスを止めると、コンテナも停止状態になる② 外部から dockerstop myjavaapp1 とすると、プロセス停止+ コンテナ停止もう一つコマンドプロンプトを開くコンテナユーザーイメージオフィシャルイメージ-d オプションでバックグラウンド動作させている場合はこの方法で止める

p.19Docker コンテナの起動と停止の仕組み◼ 複数プロセスの起動について 通常は、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/shdocker run --name myjavaapp1-it -p 5000:8080 myjavaapp:latest-itこれらは同一のディスクを共有して動作する

p.20Docker コンテナの起動と停止の仕組み◼ コンテナの残留について docker stop コマンドを送る、あるいは PID = 1 のプロセスが停止すると、当該コンテナのプロセスがすべて停止される しかし、コンテナは残留する（= 仮想マシンをシャットダウンした状態に相当）◼ 再度コンテナを起動することが可能（= 仮想マシンの起動に相当）◼ コンテナが停止している状態の場合、docker exec コマンドで外部からプロセスを起動することはできない （参考） docker commit コマンドを発行すると、イメージとして保存することができる◼ ※ 普通は利用しない（イメージ構築は Dockerfile で自動化するのが基本であるため）ユーザーイメージオフィシャルイメージdocker buildmyjavaapp:latest開始コンテナ停止コンテナユーザーイメージオフィシャルイメージコンテナ（myjavaapp1）プロセス（PID=1）ユーザーイメージオフィシャルイメージ起動ディスクへ書き込み変更変更docker rmコンテナ削除ユーザーイメージオフィシャルイメージ変更docker commit新しいイメージとして保存

p.21Docker コンテナの起動と停止の仕組み◼ 便利な処理コマンドについて 以下のようなコマンドをよく利用するため、適宜使うとよい 主な注意点として...◼ コマンドライン引数は、ネットを検索すれば多数出てくるので、まず調べてみるとよい◼ 一括処理は 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-latestdocker export sql1 > sql1.tarコンテナ停止 docker kill $(docker ps -q) for /f %A in ('docker ps -q') do dockerkill %Aコンテナ全削除 docker rm $(docker ps -a -q) for /f %A in ('docker ps -aq') do dockerrm %Aイメージ全削除 docker rmi $(docker images -q) for /f %A in ('docker images -q')do docker rmi --force %A※ イメージ全削除はオフィシャルイメージも全部消してしまうため注意

p.22ステートフルマシンの作り方◼ 基本的に、コンテナインスタンスは使い捨てとし、データは保存しない ディストリビューションやランタイムにパッチが当たった際には、イメージを再構築＋再展開する このため、コンテナインスタンスは使い捨てとするのが基本となる 結果として、コンテナインスタンスにはログデータなどを保存しないのが原則となるユーザーイメージオフィシャルイメージオフィシャルイメージdocker buildコンテナユーザーイメージオフィシャルイメージプロセスdocker run docker stop+ docker rmコンテナ削除Dockerfileバージョンアップ（パッチ適用版のリリース）ユーザーイメージオフィシャルイメージオフィシャルイメージdocker buildコンテナユーザーイメージオフィシャルイメージプロセスdocker run docker stop+ docker rmコンテナ削除Dockerfileパッチパッチパッチ

p.23ステートフルマシンの作り方◼ この点は以下の 2 つで問題になるが、それぞれ基本となる解決策がある ① ログ出力◼ ローカルディスクにログを保存しないのが基本となる◼ ローカルディスクに一時保存したログデータを外部ストレージに非同期転送するか、最初から Application Insights のような外部ログサービスを利用することで解決する ② データベースサーバ◼ データベースサーバは Docker と非常に相性が悪いため、PaaS DB を使う◼ 具体的には、SQL Database や MySQL/MariaDB/PostgreSQL as a Service などのPaaS を使うWeb サーバ DB サーバ運用管理App InsightsPaaS DB サービスDockerDB 部にはDocker を使わないDocker EngineLinux Kernelコンテナユーザーイメージオフィシャルイメージプロセスコンテナユーザーイメージオフィシャルイメージプロセスログデータは外部保存AP サーバにDocker を使う

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 buildmyjavaapp:latest開始コンテナ（myjavaapp1）プロセス（PID=1）ユーザーイメージオフィシャルイメージ起動変更C:¥Usersmyvolume/userdata1/userdata2コンテナを消してもデータが残る※ 設定画面から共有オプションの指定が必要（参考）左記の方法以外にデータボリュームコンテナを使う方法がある

p.25Dockerfile の作り方◼ Docker イメージの作成方法としては、主に以下の 3 通りがある ① ホスト OS でコンパイルを行い、その結果だけを Docker 内にコピーする ② SDK を含む Docker 内にソースコードを持ち込み、当該環境内でコンパイルする ③ SDK を含む Docker 内にソースコードを持ち込んでコンパイルを行い、結果を実行ランタイムだけを持つ Docker 内にコピーするコンテナユーザーイメージ実行ランタイムイメージホストマシンソースコードコンパイルバイナリパッケージファイル取り込みユーザーイメージ実行ランタイムイメージ出力コンテナユーザーイメージSDKイメージホストマシンソースコードファイル取り込み出力ユーザーイメージオフィシャルイメージコンパイルユーザーイメージSDKイメージ実行時には使わないWindows でコンパイルLinux でコンパイルコンテナユーザーイメージSDKイメージホストマシンソースコードファイル取り込みコンパイルコンテナユーザーイメージ実行ランタイムイメージファイル取り込み出力Linux でコンパイルイメージを極小化イメージが大きい

p.26Dockerfile の作り方◼ ① ホストマシンでコンパイルし、その結果だけをコンテナイメージ内にコピーする 最もオーソドックスな方法、通常はこの方法を利用すればよい 理由） 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:latestDockerfile

p.27Dockerfile の作り方◼ ② SDK を含むコンテナにソースコードを持ち込み、コンパイルして利用する ホストマシン側ではコンパイルできない場合や、ホストマシンとは異なる環境でコンパイルしたい場合に利用する ただし、この方法だとイメージが大きくなる → ③の方法を利用する# OpenJDK をベースにイメージを構築# ビルドまで行うために jdk を利用FROM openjdk:8-jdk-alpine# ホストマシンからコンテナにソースコードをコピーCOPY . /sourceWORKDIR /source# 改行コード修正と実行権限の修正RUN sed -i 's/¥r$//' mvnwRUN chmod 777 mvnw# ソースコードをビルドRUN ./mvnw clean package -DskipTestsRUN mkdir /appRUN 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 でコンパイルイメージが大きい

p.28Dockerfile の作り方◼ ③ コンテナでコンパイルした後、実行用のコンテナイメージを別途作成する マルチステージビルドと呼ばれる手法 実行イメージに不要なソースを残す必要がなく、サイズも極小化できるユーザーイメージオフィシャルイメージコンテナユーザーイメージSDKイメージホストマシンソースコードファイル取り込みコンパイルコンテナユーザーイメージ実行ランタイムイメージファイル取り込み出力イメージを極小化# ビルドを行うために jdk を利用FROM openjdk:8-jdk-alpine AS build# ソースコードをビルドCOPY . /sourceWORKDIR /source# 改行コード修正と実行権限の修正RUN sed -i 's/¥r$//' mvnwRUN chmod 777 mvnwRUN ./mvnw clean package -DskipTests# 最終イメージを作成FROM openjdk:8-jre-alpineRUN mkdir /appWORKDIR /appCOPY --from=build /source/target/azrefarc-springboot-0.0.1-SNAPSHOT.jar /app/ROOT.jar# コンテナのポート 8080 を外に解放する予定であることを示すEXPOSE 8080# コンテナ起動時の実行コマンドを指定CMD ["java", "-jar", "/app/ROOT.jar"]DockerfileLinux でコンパイルJDK を利用JRE を利用ビルド用コンテナからコンパイル結果をコピー

p.29Dockerfile の作り方◼ 主な Dockerfile コマンドについて よく利用する Dockerfile コマンドは下記の通り 細かい使い方についてはオフィシャルドキュメントやネットを参照するとよいコマンド機能FROM ベースイメージを指定COPY ファイルをコピーWORKDIR 作業ディレクトリを変更RUN コマンドを実行EXPOSE 実行時に外部に晒すポート番号を指定CMD コンテナ起動時に実行するコマンドを指定ENV 環境変数を設定VOLUME 外部のボリュームをマウントUSER コンテナで利用するユーザ IDLABEL イメージへメタデータを追加ADD ファイルをコピー (gzip などの展開や Web 取得機能つき)特によく使うもの

p.30Dockerfile の作り方◼ 注意！コンテキスト（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 . /sourceWORKDIR /source# ソースコードをビルドRUN ./mvnw clean package -DskipTestsRUN mkdir /appRUN mv /source/target/azrefarc-springboot-0.0.1-SNAPSHOT.jar/app/ROOT.jarDockerfileコンテナユーザーイメージSDKイメージホストマシンソースコードファイル取り込みコンパイル. （ドット）（カレントディレクトリ）ファイル取り込みmv コマンドmkdir コマンド

p.31Dockerfile の作り方◼ その他の Dockerfile の作成例 参考） ASP.NET Core Web アプリケーションの場合◼ Web アプリプロジェクト内に Dockerfile ファイルを作成◼ マルチステージビルドを利用◼ 発行（publish）されたファイルのみをイメージに取り込んで利用するFROM microsoft/aspnetcore:2.0 AS baseWORKDIR /appEXPOSE 80FROM microsoft/aspnetcore-build:2.0 AS buildWORKDIR /srcCOPY . /srcRUN dotnet build . -c Release -o /appFROM build AS publishRUN dotnet publish . -c Release -o /appFROM base AS finalWORKDIR /appCOPY --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 azrefarcaspnetcoreDockerfile

p.32Dockerfile の作り方◼ その他の 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 など）ユーザアプリビルドして実行呼び出して動作確認開発用DBJRESQL Serverfor Linuxクラウド上のPaaS DB社内からだとTCP 接続がブロックされる場合あり！開発用の DBサーバをDocker で立ててしまう※ それぞれを単独で起動すると相互通信できない→ docker-compose を使う（次ページ）

p.33利用上の Tips & Tricks◼ Docker Compose によるマルチコンテナ構成について ひとつの物理 PC 内に、複数のコンテナを立てて利用することができる◼ 例） Web アプリケーションの開発の際に、Web サーバと DB サーバを立てる◼ このような構成をマルチコンテナ構成と呼ぶ 開発マシン上でのマルチコンテナの起動には、Docker Compose を利用すると便利◼ docker-compose.yaml ファイルに、マルチコンテナの構成を記述（→ 次ページ）◼ docker-compose up により、マルチコンテナを起動◼ docker-compose rm で作成した全コンテナを削除ホストマシンコンテナコンテナブラウザブラウザ（Chrome など）ユーザアプリ呼び出して動作確認開発用DBJRESQL Serverfor LinuxDocker 用ローカルブリッジdocker-composedocker-compose.yaml（マルチコンテナの構成ファイル）Docker-Compose を使うと簡単に相互通信させられる（同じ内部ブリッジに接続、内部 DNS サービスの利用が可能）

p.34◼ Docker Compose によるマルチコンテナ構成について（続き） 例） docker-compose.yaml ファイル◼ DB コンテナ、アプリコンテナはそれぞれ Dockerfile で作成version: '3.4' # docker-compose yaml ファイルのバージョンの指定services:sqlserver:build:context: ./databasedockerfile: ./Dockerfilecontainer_name: sqldb1ports:- "1433:1433"tty: truestdin_open: trueapp:build:context: .dockerfile: ./Dockerfilecontainer_name: springbootapp1depends_on:- sqlserverlinks:- "sqlserver:sqldb1" # コンテナ間接続を有効にするenvironment: # https://docs.microsoft.com/ja-jp/sql/connect/jdbc/building-the-connection-url?view=sql-server-2017SPRING_DATASOURCE_URL: "jdbc:sqlserver://sqldb1:1433;databaseName=pubs"SPRING_DATASOURCE_USERNAME: "sa"SPRING_DATASOURCE_PASSWORD: "password"ports:- "5000:8080"tty: truestdin_open: truedocker-compose.yaml利用上の Tips & Tricksdocker-compose.yaml（マルチコンテナの構成ファイル）Dockerfile（アプリサーバ用）Dockerfile（DB サーバ用）sqlserver コンテナをsqldb1 という名前で呼び出せるようにするDocker イメージの環境変数を上書き

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

p.36利用上の Tips & Tricks◼ Docker Compose によるマルチコンテナ構成について（続き） その他の注意点について◼ 初回実行について docker-compose up コマンドの初回実行時は、コンテナのビルドが行われるが... 2 回目以降は、イメージの再作成は特に行われず、コンテナインスタンスの作成だけが行われる（＝ショートカットされる） コンテナイメージの再作成が必要な場合には、イメージの削除が必要◼ マルチコンテナの停止と再開について Ctrl + C で Docker Compose を停止すると、コンテナは削除されず、停止状態になる ここから docker-compose up を行うと、停止されているコンテナが再開される（＝コンテナインスタンスの再作成は行われない） コンテナインスタンスの再作成が必要な場合には、docker-compose rm によりコンテナインスタンスを一度削除してからやり直すdocker-compose up を行うと、• 初回はイメージの作成が行われる• 2 回目はイメージ作成は省略されるイメージ再作成のためには、イメージを削除する必要がある

p.37利用上の Tips & Tricks◼ Dockerfile によるイメージ構築の途中で失敗した場合のデバッグについて コンテナインスタンスが動作中か停止中かで、利用できる手法が変わってくる コンテナインスタンスが止まっていない場合◼ コンテナ内にシェルを立ち上げて、中身を確認するのが簡単 コンテナインスタンスが止まってしまっている場合◼ ファイルコピーなどのケアレスミスが疑われる場合は、ファイルを取り出してみる◼ そうでない場合は、いったんイメージをコミットし、別のコンテナインスタンスとして立ち上げ直して中を見てみるとよいコンテナの状態デバッグ手法コマンド動作しているコンテナ内にシェルで入って確認するdocker exec -it <コンテナ名> /bin/bash または /bin/shCPU やメモリの利用状況を確認するdocker stats <コンテナ名>停止しているファイルを取り出して確認する docker cp <コンテナ名>:/ファイルパス C:¥ローカルパスいったんイメージコミットしてシェルで入るdocker commit <コンテナ名> brokendocker run -it broken /bin/bash または /bin/sh

Module 2クラウド環境への Docker イメージの展開

p.39クラウド環境への Docker イメージの展開◼ クラウド環境への Docker イメージの展開について解説する オーケストレーション技術の必要性 Docker イメージを利用する場合の CI/CD ワークフロー Azure Container Registry へのイメージ登録 VSTS ビルドによる Docker イメージのビルド Web Apps for Containers への Docker イメージの展開

p.40オーケストレーション技術の必要性◼ 実際に Docker を使って『システム』を組み上げるには、周辺の自動化の仕組みが必要になる 例えば...◼ 複数（台数・種類）の Docker イメージの一括配置◼ ロードバランサの自動構成、オートスケール機能◼ モニタリングと障害発生時の自動フェイルオーバの仕組み これらを行うサービスを、「オーケストレーション」サービスと呼ぶ◼ 複雑なコンピュータシステム・ミドルウェア・サービスの配置・設定・管理を自動化するサービスのこと◼ ベンダー固有のもの、Docker 社が提供するものなど様々なものがあるオーケストレーションツール展開・管理サービスMesos/Marathon, DockerSwarm, GoogleKubernetesクラスタ状態管理 ZooKeeper, Consul, etcdゲートウェイ（ロードバランス）nginx, HAProxy展開・管理サービスロードバランサDocker EngineLinux Kernel物理サーバマシンDocker EngineLinux Kernel物理サーバマシンDocker EngineLinux Kernel物理サーバマシンロードバランサDocker EngineLinux Kernel物理サーバマシンDocker EngineLinux Kernel物理サーバマシンDocker EngineLinux Kernel物理サーバマシンサーバ負荷状況を見てオートスケール空きノードを見つけて適切に展開ロードバランサも自動構成1 つのシステムパッケージとして管理障害監視を行い、障害時は自動復旧

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 ElasticContainer Service for Kubernetes）、Google Kubernetes Engine など 一方、Kubernetes 自体には以下の難点がある◼ 現時点ではまだ発展途上（機能的にも信頼性的にも十分に枯れているとは言えない）◼ MSA（マイクロサービスアーキテクチャ）向けプラットフォームであり、シンプルな Web-DB 型システムに使うには、やりすぎ感がある このため、Azure Web Apps for Containers などのシンプルな PaaS 系コンテナサービスを使った方が良い場合も多い

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/BAABB AWeb Apps forContainers共用CCCDDDDocker アプリを配置可能ロードバランサによるルーティングと負荷分散Kubernetes （AKS, EKS など） Azure Web Apps for Containers複数のサービスでインフラを共用できる

p.43オーケストレーション技術の必要性◼ （参考）マイクロサービスアーキテクチャ, Docker, Kubernates について 機械学習などのシステムでは、Polyglot な開発が必要になる場合がある◼ システム全体を、区切りのよいマイクロサービスに分割した上で...◼ フロントエンドは C#、AI は Python、バックエンドは Java など、最適な言語で開発し...◼ これらを Web API でつないでシステム全体を開発していく このような Polyglot 型のマイクロサービスアーキテクチャベースのシステムでは、Docker や Kubernates が非常に役立つ◼ Docker : ひとつの仕組みで多彩な言語やランタイムに対応可能◼ Kubernates : マイクロサービスから構成されるシステムをまとめて展開・管理できる 逆にいえば、上記のようなニースがない場合には、MSA, Docker,Kubernates は「やりすぎ」になってしまう場合もある◼ このため、必要性がはっきりしない場合には使わない方がよいことも多い

p.44Docker イメージを利用する場合の CI/CD ワークフロー◼ Docker イメージを利用する場合の CI/CD ワークフローは、次ページの通り ビルドサーバにおいて、コンパイル作業と Docker イメージ作成を行う 成果物はコンテナレジストリに登録し、そこから自動配置を行う◼ このワークフローにおいて、自動ビルドマシンの構築方法が複数通りある ① Windows マシンで自動ビルドマシンを構築する方法◼ 開発環境と同様に、Windows マシンでコンパイル + Docker イメージを作成する方法◼ ビルドマシンに Docker for Windows のインストールが必要◼ コンパイル + Docker イメージの作成方法は、開発環境の場合とほぼ同じ ② Linux マシンで自動ビルドマシンを構築する方法◼ ビルドマシンを Linux マシンにしてしまい、Docker をネイティブに使う方法◼ コンパイル作業を Linux 上で行う必要があることに注意が必要 ③ （参考） Windows マシンで自動ビルドマシンを構築するが、コンパイルは LinuxDocker 上で行う方式◼ ①と②を組み合わせたような形◼ Dockerfile に若干の工夫が必要◼ これらについて、順に解説する

p.45デベロッパーソースコードレポジトリ自動ビルド・リリースVSTS Git変更CI（自動ビルド）ソースコードソースコード Dockerイメージコンパイル＋イメージ作成コンテナレジストリACRDockerHub 上の公式イメージカナリア環境CD（自動配置）静的コード解析Web Apps forContainersSQL Databaseテスト環境Web Apps forContainersSQL Databaseステージング・本番環境Web Apps forContainersSQL DatabaseWeb Apps forContainers実装環境コンテナ利用時の CI/CD（DevOps）ワークフローユーザ F/Bデータベース機能追加・修正の提案お客様運用チーム稼働状況データテレメトリデータApplicationInsightsお客様からの F/B・クレーム受付プロアクティブなデータ解析お客様・開発チーム（開発進捗確認）通常はWindows PCWindowsor Linux

p.46◼ 事前準備： ACR （Azure Container Registry）の作成 コンテナイメージを保存するためのプライベートリポジトリを ACR により準備する◼ Azure ポータルサイトからコンテナを準備する コンテナにリポジトリを作成し、タグをつけてイメージをアップロードして使う◼ 通常は、以下のように設計して使う コンテナ名 = VSTS アカウント名 リポジトリ名 = プロジェクト名やソリューション名 タグ = イメージのバージョン番号azrefarc 1061071082324VSTS ビルドによる Docker イメージのビルドACR（Azure Container Registry）azrefarc.springbootコンテナリポジトリタグazrefarc.aspnetcoreazrefarc.azurecr.io/azrefarc.springboot:107azrefarc.azurecr.io/azrefarc.springboot:106イメージの参照名（レジストリホスト/名前:タグ）azrefarc.azurecr.io/azrefarc.springboot:108azrefarc.azurecr.io/azrefarc.aspnetcore:23azrefarc.azurecr.io/azrefarc.aspnetcore:24VSTSアカウント名VSTSプロジェクト名やソリューション名イメージのバージョン番号

p.47VSTS ビルドによる 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 forWindows, Java, Maven などをインストールしてビルドマシンにする（動作するが推奨しない）

p.48VSTS ビルドによる 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 が識別されていることを確認

p.49VSTS ビルドによる Docker イメージのビルド◼ ① Windows マシンで自動ビルドマシンを構築する方法（続き） 自動ビルド定義について◼ Dockerfile の構成方法によって、自動ビルド定義が変わる◼ ここでは、以下の流れで自動ビルドを行う場合を考える ビルドマシン上（＝コンテナ外）でコンパイル Dockerfile を使い、ユーザーイメージを作成 ACR にアップロード◼ この場合は、右図のような流れのビルド定義となる （参考・注意）コンパイル結果に関しては、成果物として発行しておくとよい（トラブルシュートの容易化や UI 自動テスト用のバイナリ発行のため）コンテナユーザーイメージ実行ランタイムイメージビルドマシンソースコードコンパイルバイナリパッケージファイル取り込みユーザーイメージ実行ランタイムイメージDockerfileコンテナレジストリACRコンテナ外でコンパイルVSTSArtifact成果物として発行コンパイルコンパイル成果物発行イメージ作成イメージ作成まずビルド続いてプッシュプッシュ出力

p.50VSTS ビルドによる 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

p.51VSTS ビルドによる Docker イメージのビルド◼ ① Windows マシンで自動ビルドマシンを構築する方法（続き） Docker タスクの設定について◼ 設定の切り替えで、イメージ構築とイメージプッシュが可能 イメージ名の設定に注意◼ $(Build.Repository.Name):$(Build.BuildId) を利用◼ これにより、ビルドごとに異なるタグが利用されるようになる 注意 : latest タグを使わない◼ Docker Hub では、最新のイメージを常に同じ名前でプルできるようにするため、latestタグが使われることがよくある◼ しかし Web App の場合、タグ名が同じだとイメージをプルしない◼ また、どのバージョンが環境に配置されているのかを正しく管理する必要がある◼ このため、latest タグは使わないようにする$(Build.Repository.Name):$(Build.BuildId)イメージのビルドイメージのプッシュ

p.52VSTS ビルドによる Docker イメージのビルド◼ ② Linux マシンで自動ビルドマシンを構築する方法 Linux マシンを自動ビルドマシンにする場合には、Hosted Pipeline の利用が可能◼ Hosted Ubuntu 1604 などの利用が可能（Docker も搭載されている）◼ ここでは簡単のため、Hosted Pipeline を利用してみることにする 基本的な考え方は、Windows マシンを使う場合と同じ◼ ローカルマシン上で Maven を動作させてコンパイルを実施◼ コンパイル結果を取り込んだ Docker イメージを作成して発行実行環境として Hosted Ubuntu 1604 を選択Linux OS 上で Maven を動作させてパッケージを作成Docker イメージの発行と ACR への発行を実施

p.53VSTS ビルドによる Docker イメージのビルド◼ ③ （参考） Windows マシンで自動ビルドマシンを構築するが、コンパイルはLinux Docker 上で行う方式 （Java などであれば問題ないが）Linux 上にしかコンパイラがないような場合に便利 マルチステージビルドを行う Dockerfile を作り、Docker コンテナ内でコンパイルも行うユーザーイメージオフィシャルイメージコンテナユーザーイメージSDKイメージビルドマシンソースコードファイル取り込みコンパイルコンテナユーザーイメージ実行ランタイムイメージファイル取り込み出力Dockerfileコンパイルイメージ作成Linux でコンパイルイメージ発行コンテナレジストリACRプッシュFROM openjdk:8-jdk-alpine AS buildCOPY . /sourceWORKDIR /sourceRUN sed -i 's/¥r$//' mvnwRUN chmod 777 mvnwRUN ./mvnw clean package -DskipTestsFROM openjdk:8-jre-alpineRUN mkdir /appWORKDIR /appCOPY --from=build /source/target/azrefarc-springboot-0.0.1-SNAPSHOT.jar /app/ROOT.jarEXPOSE 8080CMD ["java", "-jar", "/app/ROOT.jar"]Dockerfileコンパイルイメージを極小化イメージ作成イメージ作成イメージ作成イメージ発行

p.54ACR 上にアップロードされたイメージのデバッグについて◼ 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 を確認イメージを確認コンテナ名リポジトリ名タグ名

p.55Web 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, Kubernates でアプリを作成することにより実施 ※ 本資料では解説しないホスト OS （Linux）UbuntuApache +ランタイムアプリUbuntuApache +ランタイムアプリディストリビューションミドルウェアアプリディストリビューションミドルウェアアプリDocker エンジンによるプロセス隔離ロードバランサビルトインイメージを利用する場合独自のコンテナイメージを利用する場合Web Apps for Linux, Container各アプリを Dockerエンジンにより隔離MS が用意・保守ユーザが用意

p.56Web Apps for Containers への Docker イメージの展開◼ Docker イメージを Web Apps 上に展開する場合には、Web Apps 作成時に利用するレジストリ／イメージ／タグを指定する これにより Docker イメージが自動的に Web Apps にプルされ、アプリが起動する◼ さらに、アプリケーション設定を追加すると、当該コンテナの環境変数に反映される データベース接続文字列などの情報を適宜追加する◼ ※ コンテナ内で実行されているWeb アプリのポート番号が特殊な場合は WEBSITES_PORTで指定するDocker コンテナ配置設定接続文字列の上書き設定コンテナ内で実行されている Web サーバのポート番号

p.57Web Apps for Containers への Docker イメージの展開◼ コンテナの設定内容や Docker ログは、ポータルサイトから確認できるコンテナ配置の設定を確認Docker ログの確認が可能Kudu にログインし、/home/LogFiles/kudu/traceを確認することも可能

p.58Web 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 : 必要があれば設定

p.59Web 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サーバが起動しているかを確認する

p.60Web 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 秒）

p.61利用条件：• 本書に関するすべての権利は、Microsoft Corporationおよびその関連会社（以下、マイクロソフト）が保有しています。本書は情報提供のみを目的としており、本資料に記載されている情報は、本資料作成時点での情報となります。• 状況等の変化により、内容は変更される場合があります。マイクロソフトによる事前の承諾がない限り、本書の全部または一部を複製、改変、翻案、再頒布、公衆送信、貸与、譲渡したり、第三者に開示または共有することは、認められません。• マイクロソフトは、本書の内容について何ら保証するものではなく、本書の使用に関連してお客様、お客様の関連会社、または第三者に生ずる間接的、付随的、結果的な損害（営業機会や営業情報の損失などを含む）について一切責任を負いません。• 本書の中で例として使用されている企業、名前およびデータは、特に記述がない限り、架空のものです。MICROSOFT CONFIDENTIAL© 2015 Microsoft Corporation. All rights reserved.

Movatterモバイル変換

Change Language

Docker for Windows & Web Apps for Containers 実践活用技法

Embed presentation

Recommended

More Related Content

What's hot

Similar to Docker for Windows & Web Apps for Containers 実践活用技法

Docker for Windows & Web Apps for Containers 実践活用技法