インフラエンジニアBooks 30分でわかる「Dockerコンテナ開発・環境構築の基本」

30分でわかる
Docker
コンテナ開発・
環境構築の基本
#インフラエンジニアBooks
2022.5.12
Yutaka Ichikawa (@cyberblack28)

View Slide

Profile
Name
• Yutaka Ichikawa/市川豊
Belong
• Oracle Corporation Japan
• Solutions Architect
Role
• Principal Cloud Solution Engineer
SNS
• Twitter/GitHub/Qiita:cyberblack28
Blog
• https://cyberblack28.hatenablog.com/
Materials
• https://speakerdeck.com/cyberblack28/
Community
• Oracle Cloud Hangout Cafe #ochacafe
• CloudNative Days Tokyo #cndt2021 #o11y2022
Certified
• Certified Kubernetes Administrator
• Certified Kubernetes Application Developer
• Certified Kubernetes Security Specialist
• Kubernetes and Cloud Native Associate
Publications
New

View Slide

Agenda
• 第1章コンテナの世界に飛び込む前に
• 第2章コンテナアプリケーション開発に必要なソフトウェア
• 第3章コンテナアプリケーション開発のライフサイクル Build・Ship・Run
• 第4章コンテナオーケストレーション
• 第5章 Kubernetesでコンテナアプリケーションを動かすまで
• 第6章ローカル開発の準備
• 第7章コンテナアプリケーションにおけるCI/CD

View Slide

本書専用GitHubリポジトリ
https://github.com/cyberblack28/docker-development-environment-construction-basic

View Slide

第1章コンテナの世界に飛び込む前に

View Slide

1章のポイント
既存のアプリケーション開発
仮想化の仕組み
コンテナアプリケーション開発スタイル
従来のオンプレミスや仮想マシン環境で稼働させるアプリケーション開発の流れを確認し、開発における課題からコンテナアプリケー
ション開発によってどのように変化するかを理解
仮想マシンとコンテナの違いを理解
コンテナアプリケーション開発のライフサイクル Build（ビルド）Ship（シップ）Run（ラン）の概要を理解

View Slide

既存のアプリケーション開発
物理マシン
仮想マシン
仮想マシン（クラウド）
コンテナ
物理サーバでアプリケーションを稼働
VM 物理サーバ上に複数の仮想マシンでアプリケーションを稼働
クラウドをベースとしたスケーラブルな仮想マシンでアプリケーションを稼働
物理マシン・仮想マシンもノードとして束ねて、コンテナという小さい単位
でアプリケーションを稼働

View Slide

アプリケーション
コードをソースコードリポジトリに
コミット/プッシュ
CI/CDパイプラインによる
テスト、ビルド、デプロイ
Developer Code Repository CI/CD Pipeline
すべて自動化されている場合もあれば、手動で行う場合もあります。
本番環境
ステージング環境
検証環境
Operator
Infrastructure
Engineer
開発環境
OS/ライブラリ
VM
物理マシン仮想マシン
仮想マシン
（クラウド）

View Slide

OS/ライブラリとアプリケーションの分離
本番環境
ステージング環境
検証環境
開発環境
OS/ライブラリ
VM
物理マシン仮想マシン
仮想マシン
（クラウド）
アプリケーションは物理マシンや仮想マシンのOS/ライブラリ上で稼働
稼働するアプリケーションは実行環境に依存する
環境差異が原因で他の環境で稼働するけど、
本番環境で稼働しない等の障害が発生する
OSのパッチバージョンが異なる、このライブラリが無
かった、関係ないものがインストールされている…

View Slide

OS/ライブラリ
• 仮想マシンイメージがベンダー製品特有（ベンダー
ロックイン）
• 容量も重い（数ギガ～数十ギガ）
• 可搬性（Portability）が低い
• 運用負荷
Xen
Server
仮想マシン
イメージ
KVM
VMWare
ハイパーバイザー
ハードウェア
VMWare Xen/Server KVM
物理/仮想マシンにおける、OS/ライブラリのアップデートには人手
や時間を要するため、アプリケーションのリリースに影響する…
仮想マシン

View Slide

これまでのアプリケーション開発
OS/ライブラリが既に整っている実行環境にアプリケーションをデプロイするという形式
1.アプリケーション
• 環境差異による問題が発生
• OS/ライブラリ側に何かあるとアプリケーションに影響
2.インフラ
• 仮想マシンイメージがベンダー製品特有（ベンダーロックイン）
• 仮想マシンイメージの容量が重く可搬性（Portability）が低い
• 物理/仮想マシンの特性上、OS/ライブラリのアップデートに時間を要して、アプリケーションのリリースに影響する

View Slide

仮想マシンとコンテナの違い
ハードウェア
ハイパーバイザー
OS/Hyper Visor OS/Hyper Visor
カーネルカーネル
アプリケーションアプリケーション
ライブラリライブラリ
仮想マシン仮想マシン
ハードウェア
カーネル
OS/Hyper Visor OS/Hyper Visor
コンテナコンテナ
コンテナエンジン
各仮想マシンのカーネル上で実行、隔離性が高いが、起動
が遅く（数分）オーバヘッドが大きい。
カーネルを共有しているため、隔離性は低いが、起動が高速
（数秒）でオーバヘッドが小さい。
仮想マシンコンテナ
アプリケーションアプリケーション
ライブラリライブラリ

View Slide

OS/ライブラリとアプリケーションの統合
• OS/ライブラリとアプリケーションをパッケージイメージ化
• 技術としてはOSSのため、ベンダーロックインは発生しない
• イメージはこれまでの仮想マシンイメージに比べるとはるかに軽いのでポータビリティ性が高い
• 自動化との親和性もあり、運用負荷を軽減
OS/ライブラリ
コンテナイメージ
1.ビルド（Build）
ビルド（Build）
OS/ライブラリ

View Slide

• イメージをレジストリに保存して、共有
2.シップ（Ship）
OS/ライブラリ
OS/ライブラリ
OS/ライブラリ
イメージレジストリ
Push Pull
シップ（Ship）
イメージの共有
OS/ライブラリ
コンテナプラットフォーム

View Slide

• コンテナイメージを基にコンテナを起動
3.ラン（Run）
コンテナプラットフォーム上でイメージからコンテナを起動して、アプリケーションを稼働。
イメージもプラットフォームも特定ベンダー技術に依存しないため、ベンダーロックインも無い。
OS/ライブラリ
ラン（Run）
OS/ライブラリ
コンテナプラットフォーム
コンテナ
コンテナイメージ

View Slide

コンテナアプリケーション開発
OS/ライブラリとアプリケーションを統合して、軽量イメージ化して、コンテナプラットフォームにコンテナとしてデプロイする形式
1.アプリケーション
• OS/ライブラリとアプリケーションが一つに統合されているため、環境差異による問題が起きにくい
2.インフラ
• 仮想マシンイメージと仕組みが異なり、OSSベースでベンダーロックインもなく、軽量で可搬性（Portability）が高い
• OS/ライブラリのアップデートも容易なため、リリースサイクルを速め、スピード（Agility）が向上

View Slide

第2章コンテナアプリケーション開発に必要なソフトウェア

View Slide

2章のポイント
Dockerのアーキテクチャ
Dockerのアーキテクチャイメージ、レジストリ、コンテナを一つずつ理解し、Dockerをベースに Build（ビルド）Ship（シップ）
Run（ラン）というコンテナアプリケーション開発のライフサイクルを理解
Docker環境のセットアップ
クラウド環境、Dockerインストール、Docker Hubのセットアップを手順に従い実施

View Slide

Docker
コンテナランタイムとLinuxカーネルの機能（名前空間、cgroups）を利用してコンテナを作成して、コンテナイメージをもとに
アプリケーションを稼働させるOSSであり、Build/Ship/Runを実現

View Slide

Dockerを構成する主要コンポーネント
1.Image
OS/ライブラリ
Dockerfile イメージ
Build
2.Registry
OS/ライブラリ
イメージ
Ship
OS/ライブラリ
レジストリ
3.Container
OS/ライブラリ
OS/ライブラリ
OS/ライブラリ
OS/ライブラリ
イメージ
Run
OS/ライブラリ
コンテナ

View Slide

Dockerで実現するBuild/Ship/Run
1.Build
読み込み専用
（ReadOnly）
ベースイメージ
CentOS
イメージ層
Container
Image
FROM centos:7
RUN yum -y install epel-release
RUN yum -y install nginx
COPY index.html /usr/share/nginx/html
ENTRYPOINT ["/usr/sbin/nginx", "-g", "daemon off;“]
Dockerfile
①
②
③
④
⑤
⑤
④
③
②
①
$ docker image build
Build
Dockerfileからビルドして、コンテナイメージを作成する

View Slide

2.Ship
コンテナエンジン（dockerd）
ハードウェア
pull
コンテナ
レジストリ
CentOS
リポジトリ
Ubuntu
リポジトリ
Container
Image
push
tag:latest
tag:6.7
・
・
tag:latest
tag:14.04
・
・
Ship
Nginx
リポジトリ
tag:latest
tag:19.1
・
・
カーネル
run
build
Container
Image
Container
Image
$ docker image pull
$ docker image push
Dockerfile
レジストリにイメージのアップロード（push）とダウンロード（pull）して、イメージの共有を行う

View Slide

3.Run
pull
コンテナ
Image
Registry
Container
Image
push
Run
run
build
Container
Image
Container
Image
$ docker container run
Dockerfile
ベースイメージ
CentOS
イメージ層
書き込み可能
イメージ層
Container
Image
⑤
④
③
②
①
6
読み込み専用
（ReadOnly）
FROM centos:7
Dockerfile
①
②
③
④
⑤
コンテナエンジン（dockerd）
ハードウェア
カーネル
イメージをもとにコンテナを起動する

View Slide

第3章コンテナアプリケーション開発のライフサイクル Build・Ship・Run

View Slide

3章のポイント
Build / イメージビルド
Dockerfileを作成して、イメージのビルドを行う上で必要となる、Dockerfile書式の整理、イメージの軽量化、ビルドツールの理解
Ship / イメージレジストリ
イメージレジストリの紹介、イメージセキュリティとしてTrivyを理解
Run / コンテナ実行
コンテナの起動、停止、接続などDockerの基本コマンドを理解
永続化データとネットワークモデル
単体コンテナとしての永続化デートとネットワークモデルの整理と理解

View Slide

Build / イメージビルド
Dockerfileの作成
$ docker image build
イメージビルドコマンドの実行
Container
Image
イメージ生成
#ベースイメージのPull
FROM centos:7
#epel-releaseインストール
#nginxインストール
#index.htmlを/usr/share/nginx/index.htmlにコピー
#nginxのフォアグラウンド処理
「docker image build」コマンドでは、Dockerfileの上から
順番に処理が実行されます。
Dockerfile

View Slide

Dockerfile、ビルド、イメージの関係性
#ベースイメージのPull
FROM centos:7
#epel-releaseインストール
#nginxインストール
#index.htmlを/usr/share/nginx/index.htmlにコピー
#nginxのフォアグラウンド処理
ENTRYPOINT ["/usr/sbin/nginx", "-g", "daemon off;"]
Dockerfile
# docker image build -t cyberblack28/sample-nginx .
Sending build context to Docker daemon 29.18kB
Step 1/5 : FROM centos:7
・
・<省略>
・
---> 7e6257c9f8d8
Step 2/5 : RUN yum -y install epel-release
---> Running in 1a6ea01a9382
・
・<省略>
・
---> b58fcc402d22
Step 3/5 : RUN yum -y install nginx
---> Running in 9eacd9b3caa1
・
・<省略>
・
---> cc0ba96f9da7
Step 4/5 : COPY index.html /usr/share/nginx/html
---> 481e53617e12
Step 5/5 : ENTRYPOINT [“nginx”, “-g”, “daemon off;”]
---> Running in 33a4c5304825
Removing intermediate container 33a4c5304825
---> 124f75914199
Successfully built 124f75914199
Successfully tagged cyberblack28/sample-nginx:latest
ビルド
# docker image history cyberblack28/sample-nginx
IMAGE CREATED CREATED BY SIZE COMMENT
124f75914199 10 minutes ago /bin/sh -c #(nop) ENTRYPOINT ["/bin/sh" "-c… 0B
481e53617e12 10 minutes ago /bin/sh -c #(nop) COPY file:764d0af30d8866d5… 130B
cc0ba96f9da7 11 minutes ago /bin/sh -c yum -y install nginx 206MB
b58fcc402d22 11 minutes ago /bin/sh -c yum -y install epel-release 91.7MB
7e6257c9f8d8 4 weeks ago /bin/sh -c #(nop) CMD ["/bin/bash"] 0B
4 weeks ago /bin/sh -c #(nop) LABEL org.label-schema.sc… 0B
4 weeks ago /bin/sh -c #(nop) ADD file:61908381d3142ffba… 203MB
イメージ
①
②
③
④
⑤
①
②
③
④
⑤
①
②
③
④
⑤

View Slide

Dockerfileリファレンス
1.ADDとCOPY
ファイル tar形式
ファイル
ディレクトリ
リモート
ファイル
ADD
ファイル
ディレクトリ
COPY
ローカルにあるファイルやディレクトリをビルドするイメージに含める命令として、ADD命令とCOPY命令がある
• ローカルにあるファイル、ディレクトリ、tar形式ファイル、
リモートファイルを指定先（パス）に配置
• tar形式ファイルは自動展開される
• ZIP形式ファイルは解凍されない
• ローカルにあるファイル、ディレクトリを指定先（パス）に
配置
ビルド中、ファイルやディレクトリを配置する場合はCOPY命令を使用、リモートからのファイルおよびtarファイルを展開する場合は、
ADD命令を推奨

View Slide

2. CMDとENTRYPOINT
Dockerfileでコマンドを実行する命令としてCMD命令とENTRYPOINT命令があり、書式としてshellとexecの形式がある
DockerfileでCMD命令とENTRYPOINT命令で指定した内容も、「$ docker container run」コマンドのオプション、引数を実
行時に指定した場合、CMDとENTRYPOINTおよびshellとexec形式とで挙動が変わる（上書きされるされない）
項目説明
CMD（shell形式 / exec形式）コンテナ起動時に変更可能なデフォルトコマンド
「$ docker container run」実行時の引数等で上書き可能
ENTRYPOINT（shell形式）コンテナ起動時に実行を必須とするコマンド
「$ docker container run」実行時の引数等で上書き不可、ただし「--entrypoint」オプションを指定すると上書き可能
ENTRYPOINT（exec形式）コンテナ起動時に実行を必須とするコマンド
「$ docker container run」実行時の引数等で上書き不可、ただしexec形式の場合は引数だけ追加可能、「--entrypoint」オプションを
指定すると上書き可能

View Slide

イメージの軽量化
イメージはレイヤ数が増えるほど容量が多くなり、サイズが増えると以下の弊害が生じる
• イメージのビルド時間が増える
• イメージレジストリへのアップロード（Push）時間が増える
• イメージレジストリからのダウンロード（Pull）時間が増える
• ホストでのディスク消費
軽量化のチューニング方法を取り入れて軽量化を図る
• 軽量なベースイメージの利用
• 不要ファイルの削除
• 不要プログラムの削除
• 依存ライブラリの削除

View Slide

マルチステージビルド
App Build イメージ
ソースコード
Build
（Compile）
ビルドライブラリ
Execution イメージ
実行環境
Copy
Execution
イメージサイズ：Heavy イメージサイズ：Light
One Dockerfile Build
Stage1 Stage2
アーティファクトアーティファクト
コンパイル用のイメージとコンパイルして生成された成果物を展開するイメージ、つまりアプリケーションビルド用と実行用のイメージを分けて、1つのDockerfileで
行う手法。必要なものはコンパイルされた成果物（バイナリファイル等）であり、コンパイラ等を含むビルド資材は、実行用のイメージには不要。実行用のイメージ
には成果物を実行できる環境があればよいので、イメージの軽量化を実現。
#Stage1
#Goのビルドを実行するベースイメージを取得
FROM golang:1.16.4-alpine3.13 as builder
#ローカルのmain.goをイメージ内にコピー
COPY ./main.go ./
#main.goをソースからビルド（コンパイル）して、msbというビルド成果物を
生成
RUN go build -o /msb ./main.go
#Stage2
#alpineのベースイメージを取得
FROM alpine:3.13
#ビルドイメージからビルド成果物のmsbをコピーして配置
COPY --from=builder /msb /usr/local/bin/msb
#msbの実行
ENTRYPOINT ["/usr/local/bin/msb"]

View Slide

Ship / イメージレジストリ
Image Registry 参考URL 種別
Docker Hub https://hub.docker.com/ パブリックレジストリ
Docker Trusted Registry (DTR) https://docs.mirantis.com/docker-enterprise/v3.0/dockeree-products/dtr.html プライベートレジストリ
Red Hat Quay.io https://quay.io/ プライベートレジストリ
Amazon Elastic Container Registry（ECR） https://aws.amazon.com/jp/ecr/ プライベートレジストリ
Azure Container Registry（ACR） https://docs.microsoft.com/ja-jp/azure/container-registry/ プライベートレジストリ
Google Container Registry（GCR） https://cloud.google.com/container-registry?hl=ja プライベートレジストリ
Oracle Cloud Infrastructure Container Registry (OCIR) https://www.oracle.com/jp/cloud-native/container-registry/ パブリック/プライベートレジストリ
Harbor https://goharbor.io/ パブリック/プライベートレジストリ
GitHub Container Registry https://docs.github.com/ja/packages/getting-started-with-github-container-
registry/about-github-container-registry
パブリックレジストリ
GitLab Container Registry https://docs.gitlab.com/ee/user/packages/container_registry/ パブリック/プライベートレジストリ
主なイメージレジストリ
Docker Hubを利用して、イメージのPushとPullを実施

View Slide

コンテナイメージとセキュリティ
脆弱性を持つコンテナイメージをもとに起動したコンテナは脆弱性を含むため、イメージを保護する必要がある
パブリックなコンテナイメージレジストリにあるコンテナイメージが安全とは限らない
OSSコミュニティの公式イメージだから安心できるとも限らない

View Slide

Trivy
コンテナイメージの脆弱性を静的に診断するツールで、OSパッケージ情報、アプリケーションの依存関係などから脆弱性を検出、
Aqua Security社がOSSとして公開している
https://github.com/aquasecurity/trivy
主な特徴
• ワンバイナリでインストール、操作が簡単
• 脆弱性データベースから診断
• スキャンと結果出力が速い
• コンテナイメージだけでなくローイカルファイルシステムやリモートgitリポジトリなどサポート

View Slide

Container
Image
2022-03-03T07:19:27.161Z INFO Detected OS: debian
2022-03-03T07:19:27.162Z INFO Detecting Debian vulnerabilities...
2022-03-03T07:19:27.167Z INFO Number of language-specific files: 1
icn.ocir.io/orasejapan/ochacafe5-3:arm (debian 11.2)
====================================================
Total: 4 (HIGH: 1, CRITICAL: 3)
+---------+------------------+----------+-------------------+---------------+---------------------------------------+
| LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION | TITLE |
+---------+------------------+----------+-------------------+---------------+---------------------------------------+
| libc6 | CVE-2021-33574 | CRITICAL | 2.31-13+deb11u2 | | glibc: mq_notify does |
| | | | | | not handle separately |
| | | | | | allocated thread attributes |
| | | | | | -->avd.aquasec.com/nvd/cve-2021-33574 |
+ +------------------+ + +---------------+---------------------------------------+
| | CVE-2022-23218 | | | | glibc: Stack-based buffer overflow |
| | | | | | in svcunix_create via long pathnames |
+ +------------------+ + +---------------+---------------------------------------+
| | CVE-2022-23219 | | | | glibc: Stack-based buffer |
| | | | | | overflow in sunrpc clnt_create |
| | | | | | via a long pathname |
+ +------------------+----------+ +---------------+---------------------------------------+
| | CVE-2021-3999 | HIGH | | | glibc: Off-by-one buffer |
| | | | | | overflow/underflow in getcwd() |
+---------+------------------+----------+-------------------+---------------+---------------------------------------+
$ trivy image --severity HIGH,CRITICAL イメージ名

View Slide

Run / コンテナ実行
以下コンテナのライフサイクルをベースに、Dockerコマンドを実行して体感

View Slide

永続化データとネットワークモデル
Dockerにおける、コンテナホストとコンテナとの間でデータを共有する3つのマウント形式の説明と実装
コンテナホスト
Container
ファイルシステム
Dockerエリアメモリー
一時ファイルシステム
のマウント
バインドマウント
ボリューム
バインドマウント (bind mount)
コンテナホストのファイル・ディレクトリをコンテナ上でマウント
ボリューム (volume)
Dockerが管理するデータ領域をコンテナ上にマウント
一時ファイルシステムのマウント (tmpfs mount)
コンテナホストに保存したくないデータを一時的にデータ領域のメ
モリ上に保存
1.永続化データ

View Slide

データボリュームコンテナ
複数のコンテナ間でボリュームを共有する仕組みの説明と実装
Container
Container Container
data-volume share02
share01
データボリューム
マウント
/tmp/data
/tmp/data /tmp/data

View Slide

Dockerをベースにコンテナのネットワークモデル（none/host/bridge）の説明と実装
Container
none
• コンテナにネットワーク・インターフェイスを持たせないモデル
• コンテナの内外通信が不可
2.ネットワークモデル
eth0
Container
host
• コンテナがコンテナホストのネットワーク・インターフェイスを共
有するモデル
• コンテナホストと同じネットワーク・インターフェイスとIPを持つ
eth0

View Slide

Linuxのブリッジ機能を利用して仮想ブリッジ上のネットワークにコンテナを作成して、NATで外部ノード、インターネットにルーティン
グ可能
bridge
eth0
wordpress-network
br-xxxxx
Port:80 Port:3306
Port:8080

View Slide

第4章コンテナオーケストレーション

View Slide

4章のポイント
Kubernetesの概要
Kubernetesが登場した経緯、実現するコンテナオーケストレーションの役割を分散処理としての捉え方を説明
クラウドネイティブへの取り組み
2019年「KubeCon + CloudNativeCon North America 2019」で発表された事例を軸にクラウドネイティブの取り組み紹介
Kubernetesアーキテクチャ
Kubernetesクラスタを構成するControl PlaneとNodeの詳解
Kubernetesのリソース
基本となるKubernetesのリソースとラベルやkubectlコマンドの説明
Kubernetesクラスタの構築
Kubernetesクラスタ構築のセットアップ手順

View Slide

単一ホスト（シングルホスト）から複数ホスト（マルチホスト）
第2章から第3章まで、Dockerをベースに単一ホスト上でコンテナを実行&実習
第4章からは、Kubernetes&Dockerをベースに複数ホスト上でコンテナを実行&実習

View Slide

Kubernetes概要
Kubernetesは、Google社内のコンテナーオーケストレーションシステムであるBorgからインスパイアされて開発されたOSSのコンテ
ナーオーケストレーション。
読み方：クーバーネーティス、クーバネティス、クバネティス等
略称：K8s（Kubernetes）
8文字
現在は、CNCF(Cloud Native Computing Foundation)で管理され、多数の企業が参加するコミュニティで開発。

View Slide

Kubernetesの主な役割と実現
• コンテナのスケジューリング
• ローリングアップデート
• オートスケーリング
• 死活監視
• 頻繁なアプリケーションのデプロイを可能にするシステム基盤
• 無停止によるリリース、高可用なシステム基盤
• 負荷に応じた伸縮自在なシステム基盤
主な役割実現
• コンテナの自動修復
• サービスディスカバリ
• ロードバランシング

View Slide

Kubernetesは分散処理基盤
Kubernetesは、複数のサーバ（仮想マシン/ベアメタル）をクラスタとして1つに束ねて、その上でコンテナというプロセス、アプリケー
ションを稼働させる分散処理基盤と捉える
仮想マシン
ベアメタル
Kubernetes
コンテナ

View Slide

Control PlaneとNode
クラスタの制御を受け持ち、クラスタ全体に関わる管理を担う
Control Plane
コンテナランタイムが稼働して、Control Planeからの指示を受けて、コンテナの起動や削除などを担う。
Node
Control Plane
• kube-apiserver
• Etcd
• kube-controller-manager
• kube-scheduler
• cloud-controller-manager
Node
• kubelet
• kube-proxy
• Container Runtime

View Slide

Kubernetesのリソース
• Podの概要
• コンテナランタイム
• デザインパターン
サイドカー
アンバサダー
アダプター
Pod
• ReplicaSetの概要
• Deploymentの概要
ReplicaSet & Deployment
• Serviceの概要
• サービスタイプ
ClusterIP
NodePort
LoadBalancer
Service
• Ingressの概要
Ingress
• PersistentVolume & PersistentVolumeClaimの概要
PersistentVolume & PersistentVolumeClaim
• ConfigMapの概要
• Secretの概要
ConfigMap & Secret
• Labelの概要
Label
• Namespaceの概要
Namespace
• kubectlの概要
kubectl
• Reclaim Policy
Delete
Retain
Recycle
• Storage Class
• アクセスモード
RWO
ROX
RWX
この章で、Kubernetesの基本となるリソースの概要を掴んで、次章で実
際にセットアップしたKubernetesクラスタ上でオブジェクトとして作成します

View Slide

第5章 Kubernetesでコンテナアプリケーションを動かすまで

View Slide

5章のポイント
kubectlコマンド
Pod、Deployment、Service、ConfigMap、Secret、Multi Container Podなど前章で概要を学んだリソースをマニフェストか
ら登録、kubectlコマンドにおけるcreateとapplyの整理
Kubernetesでアプリケーションを動かす
NFSを作成して、実際にPersistentVolume/PersistentVolumeClaimを利用したWordPress環境の構築、WordPress
Podのスケールアウト/イン、アプリケーションの削除
マニフェストファイルの管理
WordPress環境構築に利用した複数のマニフェストを、Helmを利用してテンプレートに置き換えてマニフェストの効率化を体感、
OSSとして公開されているWordPressのHelm Chartを利用したデプロイを実践

View Slide

WordPress環境の構築(マニフェスト)
WordPress Pod数の増
減値を変更してスケール
アウト/インを実施
「$kubectl
delete」コ
マンドを実
行してアプ
リケーショ
ンの削除を
行い、従来
のアプリ
ケーション
のアンイン
ストールと
は違うこと
を体験

View Slide

WordPress環境の構築(独自Helm Chart)
「$kubectl
delete」コ
マンドと
「$helm
uninstall」
コマンドで
のアプリ
ケーション
削除の違い
を確認
マニフェストとHelm
Chartにおけるマニフェス
ト管理の効率化を確認

View Slide

WordPress環境の構築(OSS Helm Chart)
OSS Helm Chartでのデ
プロイを確認、他のOSS
Helm Chartを利用する
場合のシミュレーション

View Slide

第6章ローカル開発の準備

View Slide

6章のポイント
ローカル開発環境の構築
これまで学んできたBuild/Ship/Runをローカル開発環境で効率的に行う方法を学ぶ
Skaffoldを利用したローカル開発環境
Skaffoldを利用したローカル開発環境を構築して、ローカル開発環境におけるBuild/Ship/Runを実践

View Slide

ローカル開発環境の種別
Authors: Michael Hausenblas (Red Hat), Ilya Dmitrichenko (Weaveworks) (Tuesday, May 01, 2018) Developing on Kubernetes，Kubernetes Blog．
オフラインタイプ(pure off-line) プロキシタイプ(proxied)
ライブタイプ(live)
オンラインタイプ(pure on-line)
ローカルの開発マシン（ラップトップまたはデスクトッ
プ）内で完結
アプリケーション作成やイメージのビルドはローカル開発環
境、Kubernetesクラスタはリモート実装
開発もKubernetesクラスタもすべてリモート

View Slide

オフラインタイプ
Minikube
プロキシタイプ
Docker Desktop
ライブタイプ
オンラインタイプ

View Slide

Skaffoldを利用したローカル開発環境

View Slide

Skaffoldを利用したローカル開発実践
Dockerfile
Sample Application
Surce Code
Yaml
(Deployment/Service)
skaffold.yaml
Docker
Hub
Yaml
(Deployment/Service/values)
Helm
apiVersion: skaffold/v2beta10
kind: Config
build:
artifacts:
- image: docker.io/DOCKERHUB_REPO_NAME/practice-skaffold # 変更箇所 DOCKERHUB_REPO_NAME
docker:
dockerfile: ./Dockerfile
tagPolicy:
dateTime: {}
local:
push: true
deploy:
helm:
releases:
- name: practice-skaffold
chartPath: skaffold-helm
valuesFiles: [ skaffold-helm/values.yaml ]
artifactOverrides:
image: docker.io/DOCKERHUB_REPO_NAME/practice-skaffold # 変更箇所 DOCKERHUB_REPO_NAME
apiVersion: skaffold/v2alpha3
kind: Config
build:
artifacts:
- image: DOCKERHUB_REPO_NAME/practice-skaffold # 変更箇所 DOCKERHUB_REPO_NAME
docker:
dockerfile: ./Dockerfile
tagPolicy:
dateTime: {}
local:
push: true
deploy:
kubectl:
manifests:
- practice-skaffold-*
Helm & Skaffold
$ skaffold dev -f skaffold.yaml
Build Ship Run

View Slide

第7章コンテナアプリケーションにおけるCI/CD

View Slide

7章のポイント
継続的インテグレーションと継続的デリバリー
コンテナアプリケーション開発における、継続的インテグレーション（CI:Continuous Integration）と継続的デリバリー
（CD:Continuous Delivery）
CIOpsとGitOps
コンテナアプリケーション開発のCI/CDをベースとしたCIOpsとGitOpsの整理
コンテナアプリケーション開発におけるCI/CD環境
Docker、Kubernetes、Helm、GitHub、GitHub Actions、Argo CDを利用したGitOps環境の構築と理解

View Slide

継続的インテグレーション
ソースコードからアプリケーションをビルドするタイミングでテストを行い、完成した成果物（アーティファクト）を保存するまでの過程
を自動化して継続的に実行するプロセス
継続的デリバリー
継続的インテグレーションによって生み出された成果物（アーティファクト）をステージング環境や本番環境に配置し、安全にリリー
スするプロセス
• 早期バグの発見、対処、品質向上
• 自動化による検証時間の短縮
• 開発者がアプリケーションロジックに専念
• ヒューマンエラーの回避
• リリース作業の自動化による安全（人による判断/エンドユーザ影響を抑える）
• スピード（アジリティ）の向上
• ヒューマンエラーの回避

View Slide

CIOps
CIOpsは、既存のCI/CDツールと連携して、アプリケーションのデプロイを実行するPush型の手法

View Slide

CIOpsにおける課題
デプロイする側であるCI/CDツールなどに認証情報を持たせる必要がある
Read/Write
Read/Write
CI/CD
CI/CD
デプロイ先が多いほど認証情報の管理が煩雑になる可能性が高まる

View Slide

GitOps
GitOpsは、コードとマニフェストのリポジトリを分けて、Kubernetesクラスタ上で稼働するGitOpsツールからマニフェストリポジトリの
更新をトリガーにデプロイを実行するPull型の手法

View Slide

GitOps 認証情報の内部管理
Config
Repository
Pull型のため認証情報は内部管理、デプロイ先のクラスタが増えても管理が容易
Read Only
Read
Write
Git

View Slide

GitOpsの実装と実践
以下の環境を構築して、サンプルアプリケーションコードの更新、プルリクエストマージ、Kubernetesクラスタへのデプロイ、そしてブラ
ウザ確認まで、GitOpsによる自動化されたCI/CDを体験

View Slide

Promotion

View Slide

<詳細・お申し込み>
http://oracle.com/goto/emp-oradev
Developer Days
未来を創造する最新テクノロジーを今、あなたの手に。
ITに携わるすべての開発者とエンジニアにオラクルテクノロジー最新情報を
お届けするオンラインイベントを2日間開催！
❃━━━…‥・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・
DB Day : 2022年5月20日 (金) 13:00 ~
Cloud Day : 2022年5月27日 (金) 13:00 ~
オンライン開催
参加費：無料 (事前登録制)
ハッシュタグ： #oradev22
・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・‥…━━━❃

View Slide

今回は MLOps がテーマです。MLOpsの全体的なフェーズを俯瞰しながら、各フェーズでどのようなことを実施すべきかを
解説します。また、MLOpsを実現するためのプラットフォームやエコシステムなども紹介します。
OCHa Café 開催情報
MLOps を始めよう！
https://ochacafe.connpass.com/event/
#ochacafe
◼ 2022年6月8日（水）
◼ 19:00 – 21:00 ＊18:50 接続開始

View Slide

Thank You !!

View Slide

インフラエンジニアBooks 30分でわかる「Dockerコンテナ開発・環境構築の基本」

インフラエンジニアBooks 30分でわかる「Dockerコンテナ開発・環境構築の基本」

cyberblack28

More Decks by cyberblack28

Other Decks in Technology

Featured

Transcript