今日から使える Docker hands on Koda 2019-07-13 Docker-Compose GCPUG SHINSHU 

hello! ● 「Web」とか「Cloud」とかの技術者 ● 某メーカーの中でアプリ開発 ● 家で自分が使いたいなというサービスを創るのが趣味 ● プログラミングと温泉を愛してます 2 KODA (@koda3t) 

コンテナ型の仮想環境 開発〜運用までに使える万能ツール 3 

Dockerを取り巻く状況 4 ❖ 2016-07-23 GCPUG信州で「激アツ」な流行りの ツールと紹介 https://www.slideshare.net/koda3/gcpdocker ❖ 2019-07-13 現在では「既にあたりまえ」の ツールに ↓ 

“ ゴール 5 ✘ Dockerについての基本的な知識を得て、今日から実際にDocker やDocker-composeを使って開発ができるようになる 

Agenda 6 ● Dockerとは何か ● Dockerを使ってみる ● Dockerfileを書いてみる ● Docker-Composeとは ● Docker-Composeを使ってみる ● Cloudへデプロイしてみる 

1. Dockerとは 7 

確認 8 ★ 既にDockerを使っている人はどのくらい？ ★ コンテナ型の仮想化とかハイパーバイザ型の仮想化とか説明いる？ 

コンテナ型の仮想化 ✘ VMWereとかVirtualBoxとかで起動する仮想環境は「ハイパーバイ ザ型」 ✘ Dockerの仮想環境は「コンテナ型」 ✘ 「コンテナ型」は 9 1. 早い 2. 軽い 3. 管理しやすい 

Server Host OS Hypervisor GuestOS Bins/Libs App1 GuestOS GuestOS Bins/Libs App3 App2 Server Host OS Docker Bins/Libs App1 App2 Bins/Libs App3 Bins/Libs ハイパーバイザ型 コンテナ型 起動まで2分（OSを起動・初期化をする必要があり） 起動まで1秒 早 い 

Server Host OS Hypervisor GuestOS Bins/Libs App1 GuestOS GuestOS Bins/Libs App3 App2 Server Host OS Docker Bins/Libs App1 App2 Bins/Libs App3 Bins/Libs ハイパーバイザ型 コンテナ型 2250MB 550MB 軽 い 50MB 200MB 500MB 50MB 200MB 500MB 50MB 200MB 500MB 50MB 200MB 50MB 50MB 200MB 

Server Host OS Hypervisor GuestOS Bins/Libs App1 GuestOS GuestOS Bins/Libs App3 App2 Server Host OS Docker Bins/Libs App1 App2 Bins/Libs App3 Bins/Libs ハイパーバイザ型 コンテナ型 管理しやすい 作業手順書 初期セットアップ 更新作業 VMを保守していくな運用 （秘伝のタレ） Dockerfile Docker build コンテナは使い捨て バージョンアップはイメージ再生性 ビルドしたイメージを配布 DockerfileはGitで管理（Infrastructure as Code） 

Dockerの基本用語 ✘ Dockerイメージ ○ Dockerコンテナを作成するためのベースのイメージ ✘ Dockerコンテナ ○ 実際に動いている実態 ○ オブジェクト指向のClassとInstanceの関係に近い Nginx Image Site-A container Site-B container docker run --name sitea nginx Student(Class) Suzuki(Instance) Tanaka(Instance) Suzuki = new Student() 

Dockerの基本用語 ✘ Dockerfile ○ Dockerイメージを作るための手順が書いてあるFile ○ Linuxベースのイメージであれば、そのLinuxで環境を作るまで のコマンドを実行していくような感じ 

FROM buildpack-deps:jessie RUN groupadd --gid 1000 node \ && useradd --uid 1000 --gid node --shell /bin/bash --create-home node ENV NODE_VERSION 8.16.0 RUN ARCH= && dpkgArch="$(dpkg --print-architecture)" \ && case "${dpkgArch##*-}" in \ amd64) ARCH='x64';; \ ppc64el) ARCH='ppc64le';; \ s390x) ARCH='s390x';; \ arm64) ARCH='arm64';; \ armhf) ARCH='armv7l';; \ i386) ARCH='x86';; \ *) echo "unsupported architecture"; exit 1 ;; \ esac \ # gpg keys listed at https://github.com/nodejs/node#release-keys && set -ex \ && for key in \ 94AE36675C464D64BAFA68DD7434390BDBE9B9C5 \ FD3A5288F042B6850C66B31F09FE44734EB7990E \ 71DCFD284A79C3B38668286BC97EC7A07EDE3FC1 \ DD8F2338BAE7501E3DD5AC78C273792F7D83545D \ C4F0DFFF4E8C1A8236409D08E73BC641CC11F4C8 \ B9AE9905FFD7803F25714661B63B535A4C206CA9 \ 77984A986EBC2AA786BC0F66B01FBB92821C587A \ 8FCCA13FEF1D0C2E91008E09770F7A9A5AE15600 \ 4ED778F539E3634C779C87C6D7062848A1AB005C \ A48C2BEE680E841632CD4E44F07496B3EB3C1762 \ B9E2F5981AA6E0CD28160D9FF13993A75599653C \ ; do \ gpg --batch --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys "$key" || \ gpg --batch --keyserver hkp://ipv4.pool.sks-keyservers.net --recv-keys "$key" || \ gpg --batch --keyserver hkp://pgp.mit.edu:80 --recv-keys "$key" ; \ done \ && curl -fsSLO --compressed "https://nodejs.org/dist/v$NODE_VERSION/node-v$NODE_VERSION-linux-$ARCH.tar.xz" \ && curl -fsSLO --compressed "https://nodejs.org/dist/v$NODE_VERSION/SHASUMS256.txt.asc" \ && gpg --batch --decrypt --output SHASUMS256.txt SHASUMS256.txt.asc \ && grep " node-v$NODE_VERSION-linux-$ARCH.tar.xz\$" SHASUMS256.txt | sha256sum -c - \ && tar -xJf "node-v$NODE_VERSION-linux-$ARCH.tar.xz" -C /usr/local --strip-components=1 --no-same-owner \ && rm "node-v$NODE_VERSION-linux-$ARCH.tar.xz" SHASUMS256.txt.asc SHASUMS256.txt \ && ln -s /usr/local/bin/node /usr/local/bin/nodejs ENV YARN_VERSION 1.15.2 ： ： Sample: Node.jsのイメージの Dockerfile https://github.com/nodejs/docker-node/blob/7e47b378c42b03ae6afae704c5bf5b724aae2b92/8/jessie/Dockerfile ハンズオンのあとで、実際に Dockerfileを書いてみるので、こ こでは雰囲気がわかれば OK 

16 まとめ 1. ✘ Dockerは「早い」「軽い」「管理しやすい」仮想環境 ✘ DockerfileからDockerイメージ（型）を作る ✘ Dockerイメージから実際に動くコンテナ（実態）を起動する 

!. ハンズオン準備 17 

GitLab.comに Sign up 

GitLab？GitHubじゃないの？ ★ GitHubのようなもの ★ GitHubだとCIはCircleCIを選択したりとツールを繋げて使う ★ GitLabはCIが初めからついてる＆Dockerレジストリもついている ★ ハンズオンではDockerレジストリやコンテナを利用したCIを回したい ため、GitLabの方が簡単 ★ GitLabは、gitlab.comをSaaSで使う事もできるし、OSSなので社内に 環境を立てることもできるのでハンズオンで学んだ事を利用しやすい 

ハンズオン用のプロジェクトをFork https://gitlab.com/koda3t/hands-on-docker 

ForkしたサンプルをGitLabから入手 git clone https://gitlab.com/{account-name}/hands-on-docker.git 次のページから、Dockerコマンドを実行して試していきます。 クローンした中の `docker-command/README.md` に実行するコマンドを書いています。 

2. Dockerを使ってみる 22 

確認 23 ★ 既にDockerはインストール済？ ★ Hello-worldコンテナを起動したことある？ ★ Nginxコンテナは起動したことある？ 

Dockerをインストール ✘ Windows / Mac なら Docker Desktopを使うのが簡単 ✘ Linuxの場合は、公式の手順でインストール https://docs.docker.com/install/ 各プラットフォームのイ ンストール手順 

インストールできたか確認 25 以下を実行 $ docker -v $ docker ps 

Dockerコンテナを起動してみる 26 以下を実行 $ docker run hello-world 

Dockerコンテナを起動してみる 27 以下を実行 $ docker run --name nginx -p 80:80 nginx:alpine localhost にアクセスできたら 「Ctrl + C」で終了 

起動のパラメータを変えてみる 28 以下を実行 $ docker run -d --rm --name nginx2 -p 81:80 nginx docker run : Dockerコンテナを作成して起動する -d : デーモン起動 --rm: 停止時にコンテナを削除 --name: コンテナに名前をつける -p 81:80: コンテナの80ポートで起動しているサービスを、ホストの 81ポートで公開する nginx: nginxイメージを起動 

よく使うDockerコマンド 29 $ docker logs -f {container-name or container-id} - コンテナのログ（colsoleにはかれたもの）を確認 - 「-f」 は `tail -f` と同じオプションで、ログを監視して新たなログが出力されたら表示する - デーモン起動したコンテナのログを確認するのに便利 Tips - DockerではアプリケーションがConsoleに出力した内容をログファイルに保存していく - このログをカスタマイズすることも可能 - Logging Driver という仕組み - 例えば、ログローテーションするとか - `docker run` に --log-opt max-size=[0-9]+[kmg] --log-opt max-file=[0-9]+ といったオプション - ログをfluentdに連携するなどのオプションも取れる - Docker時代のアプリケーションは、アプリケーションはログの管理をしなくて良い（Consoleに出力すればOKで、ログの ローテーションなどはDockerが行う） - https://docs.docker.com/config/containers/logging/configure/ 

30 よく使うDockerコマンド $ docker pull {image-name}:{tag} - Docker imageを取得する - `docker run` のときに、指定のイメージが無ければ pull してくれるのであまり明示的にこの コマンドを使うことは無いかも Tips - DockerのImageはDockerHubで検索するといろいろある - pullするImageは、同じイメージでもTagで、バージョンを指定したりベースのOSを指定できる - 「alpine」のタグがあるものがあれば、容量が小さいので積極的に使おう - 例: nginxの通常のイメージは100MBくらいだけど、alpineを使えば20MBくらい - ただし、「alpine」だと動かない場合もあるので、その場合、Tagに「Slim」がついているものを探すと良い - 自分が開発するアプリ（Node.jsやJava）だと動かない事が多い、、、 - DBとかNginx、アプリが利用するものはalpineで問題ないことが多い 

よく使うDockerコマンド 31 $ docker images - 現在持っているDockerイメージを確認する $ docker ps - 現在動いているdockerコンテナを確認する $ docker ps -a - 停止したコンテナも含めてコンテナを確認する 

よく使うDockerコマンド 32 $ docker images - 現在持っているDockerイメージを確認する $ docker ps - 現在動いているdockerコンテナを確認する $ docker ps -a - 停止したコンテナも含めてコンテナを確認する Nginxコンテナが停止されている。 停止していたとしても、同じ名前のコンテナを起動することはできない。 `$ docker run --name nginx -p 80:80 nginx` ←失敗する 停止中のコンテナを起動しなおすか、停止しているコンテナを削除して再実行する （コンテナは使い捨てと考えると、基本は削除 →起動しなおしでOK） 

よく使うDockerコマンド 33 $ docker start {container-name or container-id} - 停止しているコンテナを起動 $ docker stop {container-name or container-id} - コンテナを停止 再びポート80でアクセスできる Nginx2 のコンテナは起動オプションで 「--rm」 をつけていたので、停止するとコンテ ナ自体が消える コンテナは使い捨てで使うほうが良いので、 「--rm」をつけることがオススメ 

よく使うDockerコマンド 34 $ docker run {Docker image} - Dockerコンテナを、指定のDocker imageを元に作成して起動する ★よく使うオプション★ -d デーモン起動 --rm 停止したタイミングでコンテナを削除 --name {コンテナ名} コンテナに名前をつける（省略すると、49個の形容詞と68名の著名な科学者もしくはハッカーの名前をランダムに組み合せる） -p {公開するポート}:{コンテナのポート} コンテナで開いたポートをホスト側で公開する -v {マウントするホスト側のファイル/ディレクトリ}:{コンテナ側のファイル/ディレクトリ} ホスト側のファイル・ディレクトリを、コンテナ内にマウントする 

よく使うDockerコマンド 35 docker run のよく使うオプションを試してみる docker run -d --rm --name nginx-volume -p 8080:80 -v `pwd`/www:/usr/share/nginx/html:ro nginx:alpine wwwディレクトリの中の index.html が表示 

よく使うDockerコマンド 36 $ docker exec --it {container id or name} sh - 指定のコンテナに入って、コマンドを実行する - `sh` がコマンド - シェルを起動しているので、中に入って操作できる コンテナ内での操作 

よく使うDockerコマンド 37 $ docker rm {container-name or container-id} - コンテナを削除 

よく使うDockerコマンド 38 $ docker rmi {image-name:tag or image-id} - Dockerイメージを削除 

39 まとめ 2. ✘ `docker run` コマンドで、DockerHubにあるImageを取得して起動できる ○ ハイパーバイザ型と違って一瞬で起動 ✘ コンテナへの操作はdockerコマンドで 

3. Dockerfileを書いてみる 40 

GitHubから入手したサンプルのディレクトリを移動 dockerfile ディレクトリへ 

Docker imageをbuildしてみる 42 $ docker build [-t {image_name} [:{tag_name}}} {dockerfileのディレクトリ} - Dockerイメージをbuildする - tagは指定しないと「latest」になる 

43 Build済のイメージを起動 

Dockerイメージのレイヤー構造 44 FROM node:10.16.0-stretch-slim RUN apt-get update && apt-get -y upgrade && apt-get -y install git WORKDIR /usr/app RUN git clone https://github.com/vuetifyjs/theme-blog.git WORKDIR /usr/app/theme-blog RUN yarn install VOLUME /usr/app/theme-blog EXPOSE 8080 CMD ["yarn", "run", "serve"] Image: node Image: node Add Git Image: node Add Git Git Clone Image: node Add Git Git Clone yarn install 

Dockerイメージのレイヤー構造 45 FROM node:10.16.0-stretch-slim RUN apt-get update && apt-get -y upgrade && apt-get -y install git WORKDIR /usr/app RUN git clone https://github.com/creativetimofficial/vuetify-material-dashboard.git WORKDIR /usr/app/vuetify-material-dashboard RUN yarn install VOLUME /usr/app/vuetify-material-dashboard EXPOSE 8080 CMD ["yarn", "run", "serve"] FROM node:10.16.0-stretch-slim RUN apt-get update && apt-get -y upgrade && apt-get -y install git WORKDIR /usr/app RUN git clone https://github.com/vuetifyjs/theme-freelancer.git WORKDIR /usr/app/theme-freelancer RUN yarn install VOLUME /usr/app/theme-freelancer EXPOSE 8080 CMD ["yarn", "run", "serve"] すでにレイヤーが あればそれを使う 

46 Dockerイメージのレイヤー構造 既にローカルにあるので キャッシュを使う （一瞬で終わる） 

47 Build済のイメージを起動 

dockerfileで良く使う記述 48 FROM {image}[:{tag}] - Dockerイメージのベースになるイメージを指定する ADD {hostのディレクトリorファイル} {コンテナのディレクトリorファイル} - ホストのディレクトリやファイルをコンテナに追加する RUN {Linuxのコマンド} - ベースになっているLinuxでコマンドを実行 - ベースイメージによってコマンドは変わる（apt, yum, apk…) WORKDIR {コンテナ内のディレクトリ} - コンテナで操作する際のカレントディレクトリ EXPOSE {ポート番号} - そのコンテナが開くポート VOLUME {コンテナ内のディレクトリ} - コンテナ保持するボリューム(永続化) - 指定が無いと、そのディレクトリは起動時に消えてしまう USER {実行ユーザ} - 実行するユーザを指定 ENV {Key}={Value} - コンテナ内の環境変数を設定 CMD [{コマンド}] - コンテナが起動したときに実行するコマンドを指定 

49 Infrastructure as Code ✘ コードでインフラ管理 ○ 作業手順書とかで、マニュアルでインフラを構築しない ○ コードを実行すれば、その環境を構築できる ✘ Dockerfileは環境構築の手順が書かれたコード ✘ これをGitで管理することで、インフラの変更の差分も管理できる 

Dockerfileを書いてみる 50 `dockerfile-test` ディレクトリに移動して、dockerfile を書きます - www ディレクトリをマウントした Nginx のイメージを作ってください - ブラウザでアクセスできることを確認してください 

FROM nginx:alpine ADD www /usr/share/nginx/html Sample: Dockerfile 

Docker Registry ✘ Dockerfileを使って作成したコンテナイメージを登録できる ○ DockerHub ○ プライベートなリポジトリ ○ Third Party(GitLab, Google, AWS….) ✘ 公開リポジトリにはイメージがいろいろある（MySQL、 Tensorflow…) ○ それを取得（Pull）すれば環境構築完了 ✘ 自分で作成したイメージをDockerレジストリで配布できる ○ インストールマニュアルとかいらない 

Docker Registry 使いたいイメージを取得するだけで 利用できる（環境構築完了） 作成したイメージ 自分たちで作成したイメージを リポジトリに登録して、環境を 配布することもできる 既にビルド済のイメージが 無数に登録されている 

GitLab の Docker Registry にイメージを登録 ✘ GitLabではプロジェクトを作るとDocker Registryがついてくる 

$ docker login registry.gitlab.com $ docker build -t registry.gitlab.com/ koda3t/hands-on-docker . $ docker push registry.gitlab.com/ koda3t/hands-on-docker Docker Registry 

✘ 登録したイメージが実際に使えることを確認してみてください ✘ 隣の人が作成したイメージが使える事を試してみてください 

https://blog.docker.com/2019/07/intro-guide-to-dockerfile-best-practices/ Intro Guide to Dockerfile Best Practices Tip #1: Order matters for caching Tip #2: More specific COPY to limit cache busts Tip #3: Identify cacheable units such as apt-get update & install Tip #4: Remove unnecessary dependencies Tip #5: Remove package manager cache Tip #6: Use official images when possible Tip #7: Use more specific tags Tip #8: Look for minimal flavors Tip #9: Build from source in a consistent environment Tip #10: Fetch dependencies in a separate step Tip #11: Use multi-stage builds to remove build dependencies (recommended Dockerfile) 

58 まとめ 3. ✘ dockerfileを書くことで簡単にDockerイメージを作成できる ✘ dockerfileはGitで管理しよう ○ Infrastructure as Code ✘ 作ったDockerImageはDocker Registryで配布する 

4. Docker-Composeとは 59 

複数のコンテナを組み合わせて構成される サービスを管理するツール 60 Docker-Compose 

61 なぜ Docker-Composeが必要か？ ✘ 最近のWebアプリケーションは、複数のサービスを組み合わせて 1つのサービスを構成する ○ Database(Postgres,MySQL),Redis,Memcached,S3,Minio ✘ Dockerでは1つのコンテナでは1つのサービスを扱う ○ 1つのコンテナに全てのサービスをインストールすることもで きるけどアンチパターン ✘ 複数のサービスの構成を管理するツールの登場 

62 docker-compose.yml ✘ 複数のDockerコンテナを組み合わせたサービスの構成を管理する ファイル ✘ docker-compose内に書かれたサービスは簡単に相互に通信できる ○ サービス名でアクセスできる ○ 外部にポートを公開する必要は無い 

Docker-Composeのイメージ docker内に仮想のネットワークができる 63 port:80のみホストで公開 

version: "3" services: vote: build: ./vote command: python app.py volumes: - ./vote:/app ports: - "5000:80" networks: - front-tier - back-tier result: build: ./result command: nodemon server.js volumes: - ./result:/app ports: - "5001:80" - "5858:5858" networks: - front-tier - back-tier worker: build: context: ./worker depends_on: - "redis" networks: - back-tier redis: image: redis:alpine container_name: redis ports: ["6379"] networks: - back-tier db: image: postgres:9.4 container_name: db volumes: - "db-data:/var/lib/postgresql/data" networks: - back-tier volumes: db-data: Sample: docker-compose.yml 

65 マイクロサービス時代の開発に ✘ マイクロサービス単位にdocker-compose化しておくと、各サービ スを連携させて作成するアプリケーションも簡単に環境構築可能 開発中のサービス 連携サービスA 連携サービスB 

66 まとめ 4. ✘ Docker-composeで開発に使うサービスをまとめて管理 ✘ 運用にもそのまま持っていける ✘ マイクロサービスの開発では、連携するサービス間でdocker-composeを共 有すると開発が捗る 

5. Docker-Composeを使ってみる 67 

68 Docker Composeをインストール ✘ WindowsやMacでDocker Desktopを使う場合は、一緒にDocker Composeがイ ンストールされる（ので何もしなくても使える） ✘ Linuxの場合は、公式のドキュメントに従いインストールする ○ https://docs.docker.com/compose/install/ 

69 Docker公式のDocker-composeを使ってみる git clone https://github.com/dockersamples/example-voting-app.git ↓ docker-compose up voting-app: 投票のWebアプリ redis: 投票結果を一時保持 worker: 投票結果をdbへ登録 db: 結果を保存するデータベース result-app: 投票結果を表示するWebアプリ 

Docker公式のDocker-composeを使ってみる 70 投票(voting-app) http://localhost:5000 結果(result-app) http://localhost:5001 

Docker公式のDocker-composeを使ってみる 71 各コンテナが動いている事がコンソールに表示されている 

Docker-composeのメリット ✘ 通常であれば、Pythonの環境、.Netの環境、Node.jsの環境をセッ トアップして、さらに、Postgres・Redisをインストールといった 作業が必要 ✘ さらに、各アプリが依存するライブラリのインストールなども必 要だが、Dockerfileに書いてあるので「docker-compose up」だけで開 発環境を構築できる（開発チーム全員が同じ環境） ✘ さらにさらに、Postgresのバージョンを変える必要がでたとき に、docker-composeの利用するイメージのバージョンを変更する だけでOK（複数バージョンを起動するといったことも簡単） 

docker-compose.ymlの説明 73 services : vote: build: ./vote command: python app.py volumes: - ./vote:/app ports: - "5000:80" networks : - front-tier - back-tier db: image: postgres:9.4 container_name : db volumes: - "db-data:/var/lib/postgresql/data" networks : - back-tier volumes: db-data: networks : front-tier : back-tier : サービス名 このdocker-composeの中で管理 するサービスを書くセクション サービスのDockerイメージは、 このディレクトリにあるdockerfile をビルドして作成する コンテナ起動時に実行するコマンド `vote` ディレクトリをマウント （マウントしたソースをビルド） 公開するポート このコンテナが所属するネットワーク （同一ネットワークに所属するとホスト 名で接続できる） サービスのDockerイメージ （イメージを指定しているのでBuildしない） データボリューム名（永続化） `db-data` という名前で、コンテナ内の `/var/lib/postgresql/data` ディレクトリを 永続化する Dockerで`db-data` という名前のデータボ リュームを管理する ネットワークの指定 back-tierは公開しないで、front-tier を公開している 

よく使うdocker-composeのコマンド 74 $ docker-compose up [-d] [{service_name}] - Docker-composeファイルにある各サービスを起動する - [-d] はデーモン起動 - サービス名を指定すればそのコンテナのみを起動し、指定しない場合は全てのサービスを起動する $ docker-compose build - docker-composeファイルにbuildの定義がある場合に、ビルドを実行する $ docker-compose logs [-f] {service_name} - docker-compose.ymlにかかれている サービス名でコンテナのログを確認 $ docker-compose down - 起動している全てのコンテナを停止する $ docker-compose exec {service_name} sh - サービスの中に入る（docker exec -it {container_name} sh と同等） $ docker-compose run --rm {service} - 指定のサービスを起動する 

Docker-composeでの環境変数の利用 ✘ docker-compose.yml内に「environment」で記載できる ✘ また「.env」というファイルに環境変数を書くとセットされる ✘ Gitにコミットしてはいけない、トークンなどは「.env」に書くこ とが多い POSTGRES_USER=postgres POSTGRES_PASSWORD=QKECmQBaPakGFzx2 .env 

Docker-Composeを使った開発 Develop CI Review 76 

Docker-Composeを使った開発 ✘ Docker-Composeを使うと各自の開発環境が揃う ○ Windowsで開発したけどLinuxで動かなかった。。。 ○ Node.jsやDBのバージョンが微妙にずれてた。。。 ✘ 開発で使っている環境で、CIを回せる ○ Jobを動かすサーバーに事前にミドルウェアをインストールし ておかなくても良い ○ 今回は簡単なのでGitLabCIを使うが、CircleCIやTravisCI、 Jenkinsでも基本は同じ 

ローカルでの開発 ✘ `develop-with-docker` ディレクトリにサンプル ○ Frontend と backend で開発をするアプリの例 ✘ README.md にセットアップなどのコマンドが書かれている ○ Docker-composeコマンドを使う ✘ 指定のコマンドを実行すれば起動できるので、バックエンド・フ ロントエンドと担当が別れていても、お互いの最新のコードを起 動して開発が進められる ○ モックとか作らなくて良い事が多い 

ローカルでの開発 ✘ dockerfile で ビルドしたイメージを使うのとは異なり、開発の 場合は、開発しているソースを各コンテナにマウントして使う 

ローカルでの開発 ✘ `docker-compose run --rm {service} {command}` ✘ {command} で実行するコマンドを指定できる ○ 省略するとdocker-compose.ymlに書かれたコマンドを実行 ○ それも書かれていなかったらDockerイメージのコマンドを実行 $ docker-compose run --rm backend yarn install --no-optional service command 

docker-composeのアプリを起動 Nginx Frontend (SPA by Vue) Backend (RestAPI) Database (Postgres) サンプルの構成 

CIとReview ✘ Dockerをしている場合、開発をしている環境と同じ環境でCIを実行 できる ✘ DockerやDocker-ComposeでCIを回す場合、Jobを実行するランナーに ミドルウェアをインストールする必要が無い ○ Dockerが無い場合、DBを使うテストではCIの実行環境にテストで使う バージョンのMySQLを事前にインストールしとかなければいけないとい う事がある ○ いろんなプロジェクトでJobのサーバーを使う場合、複数のバージョン のMySQLを使いたいということがあるが、対応できなくなる 

テストで docker-compose を使うという定義 .gitlab-ci.yml テストで実行するコマンド ローカルでの開発と同じコマンド GitLab CI では、 `.gitlab-ci.yml` を書く だけでCIが動き出し、MRと連携する 

テストで 使うDockerイメージ(Postgres, Node.js)をテストの度にPullしている。 事前にインストールする必要は無し。 

開発のフロー Issue Create MR Git push Develop CI Review Merge 

Issueに対応したブランチを作成 して開発 lintチェックや、テストが CIで成功し たもののみレビューする 

開発フローを試してみよう ✘ ForkしたプロジェクトでIssueを作る ○ 送信ボタンの色を変える ✘ IssueからMRを作成すると、同時にブランチも作成するので、ぼのブラ ンチで作業 ✘ できたらPush ✘ 自動テストが動いてレビューできるようになっている 

CI (Lint/Test) with Docker-compose ①DeployのJobを実行 Docker build と Image の push `docker-compose.yml`を 更新（1.0.2を使う） ソースコードのProject コードにTagをうつ Webapp:1.0.1 → WebApp:1.0.2 デプロイ用のProject デプロイ指示 デプロイのパイプラインの例 Docker Registry Update docker-compose.yml (git pull) Webappを開始 (docker-compose up) デプロイ完了通知 公開している環境 チャット サービス ②Deployの完了通知 ③確認 

89 まとめ 5. ✘ docker-compose.ymlで複数のコンテナをまとめて起動 ✘ 開発環境をdocker-compose.ymlで構築しておき、Gitに入れておけば、 メンバーは直ぐに開発が開始できる ✘ Docker-Composeで開発＆CI＆MR(PR)を効率的に回せる 

6. Cloudへデプロイしてみる 90 

Docker コンテナを実行するためのクラスタ 管理およびオーケストレーション システム 91 GKE 

92 GKE(Google Kubernetes Engine) ✘ Docker コンテナを実行するための強力なクラスタ管理およびオー ケストレーション システム ✘ Google Container Engine が名前が変わった ○ Google Container Engine の時も略称は GKE だった ✘ Amazon AWS / Microsoft Azure にも類似の Dockerコンテナをホ ストするサービスがある ○ ベンダロックインにならないので、積極的に使っていける！ ○ 各ベンダーのPaaSを使える共通のプラットフォームがDockerや Kubernetesになってきている 

93 Kubernetesって？ ✘ Dockerのデプロイ/オーケストレーションツール ○ 関連するコンテナのグルーピング ○ コンテナに割り振られるIPアドレスの管理 ○ コンテナ間のネットワークルーティング管理 ○ 複数のコンテナを利用した負荷分散 ○ コンテナに割り当てるストレージの管理 ○ コンテナの監視 

94 GKEのメリット ✘ 一度Dockerイメージを作って登録しておけば、クラスタ管理して くれるので、Dockerイメージ単位（≒マイクロサービス）にオー トスケールを行う ✘ コンテナの死活監視も k8s が行ってくれるので、運用が簡単 ✘ というのは、GKEのメリットというよりは、k8sのメリット ✘ k8sを扱うのは、一番カンタン＆コストが安い 

95 Docker Registry オートスケール ロードバランス GKEの動作のイメージ 

Place your screenshot here GKEを使ってみます クレジットカード登録が必要です。 操作によっては課金が発生する可能性もあります。 できる人だけで、、、 96 

97 たぶん事前にクレジットカードの登録が必要 GKEにクラスタの作成 

98 GKEにクラスタの作成 

99 GKEにクラスタの作成 

100 GKEにクラスタの作成 

101 GKEにクラスタの作成 

102 GKEにクラスタの作成 

103 Google Cloud SDKをインストール ✘ GKE用のツールをインストール ✘ https://cloud.google.com/sdk/#Quick_Start ✘ 公式から「install.sh」を取得して、実行するだけ（Mac） 

104 Google Cloud SDKを初期化 $ gcloud init ブラウザが起動してGoogleアカ ウントでログイン 操作するプロジェクト選択にな るので、先程登録したプロジェ クトを指定 

105 ハンズオンで作成したイメージをGoogle用にビルド ✘ `dockerfile-test` ディレクトリに移動して実行 $ gcloud auth configure-docker $ docker build -t gcr.io/eks-sample/eks-sample-web:v0.0.1 . $ docker push gcr.io/eks-sample/eks-sample-web:v0.0.1 

106 GKEにクラスタにPushしたDockerイメージをデプロイ 

107 GKEにクラスタにPushしたDockerイメージをデプロイ 

108 GKEにクラスタにPushしたDockerイメージをデプロイ 

109 GKEにクラスタにPushしたDockerイメージをデプロイ 先程、Google の Container Registoryに Push したイメージ 

110 GKEにクラスタにPushしたDockerイメージをデプロイ スクロールすると下部にデプロイボタン 

111 GKEにクラスタにPushしたDockerイメージをデプロイ 

112 GKEにクラスタにPushしたDockerイメージをデプロイ 

113 デプロイしたサービスにアクセス 

114 動いてる 

115 クリーンアップ 

116 まとめ 6. ✘ 自分で作成したDockerイメージをCloudにデプロイすることで簡単にWeb サービスを提供できる ✘ GKEはk8sがベースにあるので、負荷分散(オートスケール)、自動復旧な ど運用に手間がかからないようにできている ✘ k8sベースなので、他のクラウドに移る事も簡単なので積極的に利用で きる 

Have Fun Dockerを使ってサクサク開発しよう！ 117 

thanks! Any questions? You can find me at @koda3t 118