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 4 weeks ago /bin/sh -c #(nop) LABEL org.label-schema.sc… 0B 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 !!