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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

第2章コンテナアプリケーション開発に必要なソフトウェア Dockerを構成する主要コンポーネント 1.Image OS/ライブラリ Dockerfile イメージ Build 2.Registry OS/ライブラリ
イメージ Ship OS/ライブラリレジストリ 3.Container OS/ライブラリ OS/ライブラリ OS/ライブラリ OS/ライブラリイメージ Run OS/ライブラリコンテナ

第2章コンテナアプリケーション開発に必要なソフトウェア 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からビルドして、コンテナイメージを作成する

第2章コンテナアプリケーション開発に必要なソフトウェア 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）して、イメージの共有を行う

第2章コンテナアプリケーション開発に必要なソフトウェア 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 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 ① ② ③ ④ ⑤ コンテナエンジン（dockerd）ハードウェアカーネルイメージをもとにコンテナを起動する

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

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

第3章コンテナアプリケーション開発のライフサイクル Build・Ship・Run Build / イメージビルド Dockerfileの作成 $ docker image
build イメージビルドコマンドの実行 Container Image イメージ生成 #ベースイメージのPull FROM centos:7 #epel-releaseインストール RUN yum -y install epel-release #nginxインストール RUN yum -y install nginx #index.htmlを/usr/share/nginx/index.htmlにコピー COPY index.html /usr/share/nginx/html #nginxのフォアグラウンド処理 ENTRYPOINT ["/usr/sbin/nginx", "-g", "daemon off;“] 「docker image build」コマンドでは、Dockerfileの上から順番に処理が実行されます。 Dockerfile

第3章コンテナアプリケーション開発のライフサイクル Build・Ship・Run Dockerfile、ビルド、イメージの関係性 #ベースイメージのPull FROM centos:7 #epel-releaseインストール RUN yum
-y install epel-release #nginxインストール RUN yum -y install nginx #index.htmlを/usr/share/nginx/index.htmlにコピー COPY index.html /usr/share/nginx/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 <missing> 4 weeks ago /bin/sh -c #(nop) LABEL org.label-schema.sc… 0B <missing> 4 weeks ago /bin/sh -c #(nop) ADD file:61908381d3142ffba… 203MB イメージ ① ② ③ ④ ⑤ ① ② ③ ④ ⑤ ① ② ③ ④ ⑤

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

第3章コンテナアプリケーション開発のライフサイクル Build・Ship・Run 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」オプションを指定すると上書き可能

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

第3章コンテナアプリケーション開発のライフサイクル Build・Ship・Run マルチステージビルド 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"]

第3章コンテナアプリケーション開発のライフサイクル Build・Ship・Run 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を実施

第3章コンテナアプリケーション開発のライフサイクル Build・Ship・Run コンテナイメージとセキュリティ脆弱性を持つコンテナイメージをもとに起動したコンテナは脆弱性を含むため、イメージを保護する必要があるパブリックなコンテナイメージレジストリにあるコンテナイメージが安全とは限らない OSSコミュニティの公式イメージだから安心できるとも限らない

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

第3章コンテナアプリケーション開発のライフサイクル Build・Ship・Run 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 | | | | | | | -->avd.aquasec.com/nvd/cve-2022-23218 | + +------------------+ + +---------------+---------------------------------------+ | | CVE-2022-23219 | | | | glibc: Stack-based buffer | | | | | | | overflow in sunrpc clnt_create | | | | | | | via a long pathname | | | | | | | -->avd.aquasec.com/nvd/cve-2022-23219 | + +------------------+----------+ +---------------+---------------------------------------+ | | CVE-2021-3999 | HIGH | | | glibc: Off-by-one buffer | | | | | | | overflow/underflow in getcwd() | | | | | | | -->avd.aquasec.com/nvd/cve-2021-3999 | +---------+------------------+----------+-------------------+---------------+---------------------------------------+ $ trivy image --severity HIGH,CRITICAL イメージ名

第3章コンテナアプリケーション開発のライフサイクル Build・Ship・Run Run / コンテナ実行以下コンテナのライフサイクルをベースに、Dockerコマンドを実行して体感

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

第3章コンテナアプリケーション開発のライフサイクル Build・Ship・Run データボリュームコンテナ複数のコンテナ間でボリュームを共有する仕組みの説明と実装コンテナホスト Container Container Container data-volume
share02 share01 データボリュームマウント /tmp/data /tmp/data /tmp/data

第3章コンテナアプリケーション開発のライフサイクル Build・Ship・Run Dockerをベースにコンテナのネットワークモデル（none/host/bridge）の説明と実装コンテナホスト Container none • コンテナにネットワーク・インターフェイスを持たせないモデル •
コンテナの内外通信が不可 2.ネットワークモデル eth0 コンテナホスト Container host • コンテナがコンテナホストのネットワーク・インターフェイスを共有するモデル • コンテナホストと同じネットワーク・インターフェイスとIPを持つ eth0

第3章コンテナアプリケーション開発のライフサイクル Build・Ship・Run Linuxのブリッジ機能を利用して仮想ブリッジ上のネットワークにコンテナを作成して、NATで外部ノード、インターネットにルーティング可能 bridge コンテナホスト eth0 wordpress-network br-xxxxx
Port:80 Port:3306 Port:8080

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

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

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

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

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

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

第4章コンテナオーケストレーション 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

第4章コンテナオーケストレーション 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クラスタ上でオブジェクトとして作成します

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

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

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

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

第5章 Kubernetesでコンテナアプリケーションを動かすまで Kubernetesでアプリケーションを動かす WordPress環境の構築(OSS Helm Chart) OSS Helm Chartでのデプロイを確認、他のOSS
Helm Chartを利用する場合のシミュレーション

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

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

ローカル開発環境の種別第6章ローカル開発の準備 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クラスタもすべてリモート

オフラインタイプ第6章ローカル開発の準備 Minikube プロキシタイプ Docker Desktop ライブタイプオンラインタイプ

Skaffoldを利用したローカル開発環境第6章ローカル開発の準備

Skaffoldを利用したローカル開発実践第6章ローカル開発の準備 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

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

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

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

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

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

GitOps 第7章コンテナアプリケーションにおけるCI/CD GitOpsは、コードとマニフェストのリポジトリを分けて、Kubernetesクラスタ上で稼働するGitOpsツールからマニフェストリポジトリの更新をトリガーにデプロイを実行するPull型の手法

GitOps 認証情報の内部管理第7章コンテナアプリケーションにおけるCI/CD Config Repository Pull型のため認証情報は内部管理、デプロイ先のクラスタが増えても管理が容易 Read Only Read
Write Git

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

Promotion

<詳細・お申し込み> 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 ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・‥…━━━❃

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

Thank You !!

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

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

Transcript

More Decks by cyberblack28

Other Decks in Technology

Featured