Tweet
Tweet

Slide 1

Slide 1 text

改めて整理する Web アプリのビルド・デプロイの基本 【コンテナ編】

Slide 2

Slide 2 text

自己紹介 ● 名前：大嶋勇樹（Twitter：@oshima_123） ○ 最近はよく「しま」と呼ばれています ● キャリア ○ 都内の某 IT 企業 -> フリーランスエンジニア -> 会社設立 ○ “ ” 現在は 実務につき始めたエンジニアのスキルアップをサポート ○ 研修・勉強会の開催・Udemy 講座の作成など ● よく関わる技術分野 ○ クラウド・コンテナ関連 (AWS、GCP、Docker、Kubernetes など) ○ Web アプリのビルド・デプロイまわりの整備はよく担当

Slide 3

Slide 3 text

Udemy 講座の紹介 ● 今日の発表と関連しそうなテーマでは、以下のような講座を出しています Linuxとネットワークの基礎から学ぶDocker入門 Linuxとネットワークの基礎知識からDockerを使った開発環境構築まで AWSコンテナサービス入門 AWSの基本からECS・Copilot CLI・CI/CD・App Runnerまで GitHub Actionsで学ぶCI/CD入門 ビルド・デプロイの基本からAPI自動テスト・AWSへの自動デプロイまで ↖️ 今日の発表は、こちらからも抜粋

Slide 4

Slide 4 text

改めて整理する Web アプリのビルド・デプロイの基本 【コンテナ編】

Slide 5

Slide 5 text

背景 近年はアプリケーションの実行環境として Docker などのコンテナ技術を 使うことが多く、開発環境などでふれたことがある方はとても多いです Web アプリケーションのビルド・デプロイについて学んだりすると、 「コンテナの場合はどうするの？」と疑問を持つ方は少なくありません

Slide 6

Slide 6 text

しかし... ● Docker や Docker Compose を使ってコンテナでローカル開発環境の構築は できても、コンテナで本番などの環境を作る知見はないという方は多いです ● 実際、コンテナで開発環境を構築する知識と、本番環境を構築する知識には ある程度違いがあると思います

Slide 7

Slide 7 text

そこで今日は... そこでこの勉強会では、 Docker などのコンテナ技術を使った ビルド・デプロイの基本を改めて整理します

Slide 8

Slide 8 text

アジェンダ ● （復習）Web アプリケーションのビルド・デプロイの基本 ● コンテナのビルド・デプロイの流れの基本 ● コンテナを動かすプラットフォームの概要 ● コンテナを使う／使わない・Dockerfile を書く／書かない

Slide 9

Slide 9 text

前提知識 ● Web アプリケーションの基礎知識があること （Web アプリケーションの実装経験か、サーバへのデプロイ経験があるのが目安です） ● Docker と Docker Compose にふれたことがあること

Slide 10

Slide 10 text

（復習） Web アプリケーションのビルド・デプロイの基本

Slide 11

Slide 11 text

プログラムの実装からリリースまでのステップ ● プログラムを実装してからリリースするまでには、例えば以下のような ステップがあります ここから、「ビルド」と「デプロイ」について簡単に復習します 実装・ 単体テスト テスト環境に デプロイ 本番環境に デプロイ ビルド テスト環境で テスト

Slide 12

Slide 12 text

Web アプリケーションの構成の基本 ● Web アプリケーションの実装で作成するファイルとしては、主に 「静的コンテンツ」と「サーバサイドのプログラム」の 2 種類があります HTML Web サーバ ブラウザ アプリケーション データベース CSS Java・Ruby 等 JS 静的コンテンツ 固定の HTML や CSS、 ブラウザ用の JavaScript など サーバサイドのプログラム HTML や JSON を生成して返す （様々な言語で実装される） Web アプリケーションでは、静的コンテンツを Web サーバで配信・ サーバサイドのプログラムをサーバで実行します

Slide 13

Slide 13 text

ビルド ● プログラムは、実装した形式でそのまま実行するとは限りません ● 例えば Java のプログラムを動かす場合、以下のような変換をしたりします main.java main.javac コンパイル / トランスパイル 別の言語に変換 hoge.java hoge.javac app.jar パッケージング / バンドル / リンク 1 ファイルにまとめる 成果物（Artifact） java コマンドで 実行する対象 ソースコードをもとに、最終的に本番などのサーバで動かす形式に 変換することを「ビルド」と言います ※ プログラミング言語（実行環境）次第で、ビルドは不要な場合もあります

Slide 14

Slide 14 text

デプロイ ● Web アプリケーションのサーバサイドは、ビルド成果物をサーバにアップ ロードして実行します 本番などの環境 アップロード ビルド ビルド成果物を本番などのサーバに配置することや、 配置したビルド成果物を実行することを「デプロイ」と言います サーバ （コンピュータ） app.jar 実行 java -jar app.jar

Slide 15

Slide 15 text

フロントエンドのビルド ● 近年の Web フロントエンド開発では React や Vue.js などを使って、 「.jsx」や「.vue」といったファイルを実装することが多いです ● これらのファイルは、JavaScript に変換してから Web サーバで配信します ソースコードを JavaScript に変換したり、JavaScript の複数の ファイルを 1 つにまとめたりするのが、フロントエンドのビルドです HTML Web サーバ ブラウザ CSS JS .vue .jsx 変換

Slide 16

Slide 16 text

Web アプリケーションのビルド・デプロイのまとめ ● ここまでの内容を図にすると以下のようになります 本番などの環境 デプロイ ビルド Web サーバ を動かすサーバ （コンピュータ） ※ Web サーバとアプリケーションは 　 同じサーバ（コンピュータ）で動かすこともあります フロントエンドの ソースコード 成果物 ブラウザ データベース デプロイ ビルド アプリケーション を動かすサーバ （コンピュータ） サーバサイドの ソースコード 成果物

Slide 17

Slide 17 text

CI/CD ● GitHub などへのソースコードの push をトリガーに、ビルド・自動テスト・ デプロイなどを専用の環境で実行する CI/CD を構築することも多いです ここまでで、「ビルド」と「デプロイ」の基本と、 CI/CD の概要を復習しました git push trigger deploy build test 本番などの環境 サーバ （コンピュータ） CI 環境 GitHub

Slide 18

Slide 18 text

コンテナのビルド・デプロイの流れの基本

Slide 19

Slide 19 text

コンテナとは ● Docker などの「コンテナ」は、仮想化技術の一種です ● コンテナにはゲスト OS がないため、VM よりとても軽量です VM (仮想マシン) コンテナ アプリケーション ミドルウェア・ ライブラリ ゲスト OS ホスト OS VM 型仮想化用ソフトウェア アプリケーション ミドルウェア・ ライブラリ ゲスト OS アプリケーション ミドルウェア・ ライブラリ ホスト OS コンテナ型仮想化用ソフトウェア アプリケーション ミドルウェア・ ライブラリ

Slide 20

Slide 20 text

コンテナ実行の基本 ● コンテナを実行するときは、コンテナのもとになる「イメージ」が必要です ● 例えば、Docker 公式の「ubuntu:22.04」というイメージをもとに、PC 上で コンテナを実行するときは、以下のような流れになります PC インターネット上の コンテナレジストリ (DockerHub など) コンテナ イメージ ubuntu:22.04 イメージ ubuntu:22.04 コンテナの 実行 (run) イメージの ダウンロード (pull)

Slide 21

Slide 21 text

イメージの自作と実行 ● 自分たちが開発したアプリケーションをコンテナ化して実行するときは、 以下のような流れになります サーバ コンテナレジストリ コンテナ イメージ myapp:v1 イメージ myapp:v1 PC 等 イメージ myapp:v1 src Dockerfile イメージの 作成 (build) イメージのアッ プロード (push) コンテナの 実行 (run) イメージの ダウンロード (pull)

Slide 22

Slide 22 text

例）AWS の場合 ● AWS には ECR というコンテナレジストリのサービスがあります ● 例えば AWS の EC2（サーバ）でコンテナを実行するときは、以下のような 流れになります コンテナ イメージ myapp:v1 イメージ myapp:v1 PC 等 イメージ myapp:v1 src Dockerfile EC2 ECR build push pull run

Slide 23

Slide 23 text

CI 環境でのビルド ● 手作業での作業ミスや、特定の PC でしかビルドできない状況を防ぐため、 ビルドはビルド専用の環境（CI 環境）で行うのが望ましいです イメージ myapp:v1 CI 環境 イメージ myapp:v1 src Dockerfile build push コンテナレジストリ

Slide 24

Slide 24 text

コンテナのデプロイ ● コンテナをデプロイする一番シンプルな方法は、サーバにログインして docker run や docker compose up などのコマンドを実行することです サーバ コンテナレジストリ コンテナ イメージ myapp:v1 イメージ myapp:v1 pull run

Slide 25

Slide 25 text

コンテナを動かすプラットフォーム ● 実際には、本番などの環境でコンテナを動かすときは、Docker や Docker Compose を使わず、コンテナの各種プラットフォームを使うことが多いです どんな環境でコンテナを動かす場合でも、 この流れがまずおさえたい基本になります git push trigger build CI 環境 GitHub コンテナ レジストリ コンテナを動かす プラットフォーム コンテナ push run ・単なるサーバ ・Amazon ECS ・Kubernetes などなど イメージ イメージ

Slide 26

Slide 26 text

コンテナを動かすプラットフォームの概要

Slide 27

Slide 27 text

そもそもなぜコンテナを使うのか ● ここで、本番環境でコンテナを使うメリットを確認しておきます サーバよりも起動が高速なため、 開発サイクルの高速化やオートスケールといった面で有利 環境構築済みのイメージを運搬して実行するため、 他の環境でテストした動作を本番でも保証しやすい サーバ内で環境を分離できるため、 1 つのサーバ内で様々なアプリケーションを動かしても競合しにくい ↖️ ここから、1 つのサーバ内で様々なコンテナを 動かすことを考えていきます

Slide 28

Slide 28 text

● 1 台のサーバを増強してたくさんのコンテナを動かす方針では、サーバの スペックの限界があります ● また、サーバが 1 台停止するだけで、その中でコンテナとして動いている Web アプリケーションなどにアクセスできなくなってしまいます サーバ CPU 16 コア メモリ 64 GiB 1 台のサーバの限界 CPU 0.5 コア メモリ 1GiB CPU 1 コア メモリ 2GiB コンテナ A コンテナ B

Slide 29

Slide 29 text

● 複数台のサーバでたくさんのコンテナを使う方針であれば、コンテナの数が 増えても、その分サーバを増やすことで対応可能です ● また、サーバ間でコンテナを冗長化させておけば、サーバが 1 台停止しても Web アプリケーションは全体としては停止しません 複数台のサーバでたくさんのコンテナを使う コンテナA CPU 0.5 メモリ 1GiB コンテナB CPU 1 メモリ 2GiB コンテナA CPU 0.5 メモリ 1GiB コンテナB CPU 1 メモリ 2GiB コンテナ A コンテナ B コンテナ A コンテナ B サーバ CPU 2 コア メモリ 4 GiB サーバ CPU 2 コア メモリ 4 GiB サーバ CPU 2 コア メモリ 4 GiB

Slide 30

Slide 30 text

問題点 ● 複数台のサーバでたくさんのコンテナを使うためには、どのサーバにどの コンテナを配置するのが適切か考えるのが大変です ● 特にコンテナをオートスケールしたりさせることを考えると、手作業で サーバとコンテナを対応づけるようなことは現実的ではありません コンテナA CPU 0.5 メモリ 1GiB コンテナB CPU 1 メモリ 2GiB コンテナA CPU 0.5 メモリ 1GiB コンテナB CPU 1 メモリ 2GiB コンテナ A コンテナ B コンテナ A コンテナ B サーバ CPU 2 コア メモリ 4 GiB サーバ CPU 2 コア メモリ 4 GiB サーバ CPU 2 コア メモリ 4 GiB

Slide 31

Slide 31 text

● 「コンテナオーケストレーション」のツールを使えば、クラスタ（サーバの まとまり）に対して、コンテナを適当に配備（デプロイ）してくれます クラスタ サーバ CPU 2 コア メモリ 4 GiB サーバ CPU 2 コア メモリ 4 GiB サーバ CPU 2 コア メモリ 4 GiB コンテナオーケストレーション Amazon ECS エンジニア 指示 配備 コンテナA CPU 0.5 メモリ 1GiB コンテナB CPU 1 メモリ 2GiB コンテナA CPU 0.5 メモリ 1GiB コンテナB CPU 1 メモリ 2GiB コンテナ A コンテナ B コンテナ A コンテナ B

Slide 32

Slide 32 text

Kubernetes と Amazon ECS ● コンテナオーケストレーションツールとしては、OSS の Kubernetes と Amazon ECS が定番の選択肢です ● Kuberentes はエコシステムやカスタマイズ性が強力な一方で、 Amazon ECS のほうがバージョンアップなどの運用コストは低いです

Slide 33

Slide 33 text

● 複数のサーバでコンテナを動かす場合、コンテナとサーバの両方の考慮が 必要になります クラスタ サーバ サーバ サーバ サーバ管理の手間 Amazon ECS 配備 CPU などの負荷に応じて コンテナをオートスケール コンテナが増えるのに応じて サーバをオートスケール コンテナ A コンテナ B コンテナ A コンテナ B

Slide 34

Slide 34 text

サーバレスなコンテナ実行環境 ● ECS on Fargate や Google Cloud Run などサーバレスなコンテナ実行環境を 使うと、サーバ管理なしでコンテナを実行できます クラスタ Amazon ECS on Fargate 配備 サーバを自前で管理するのに比べて制約が増える一方で、 サーバのスケーリングなどを自前で管理する必要がなくなります コンテナ A コンテナ B コンテナ A コンテナ B

Slide 35

Slide 35 text

コンテナのデプロイの流れ ● コンテナのデプロイの流れの基本を再度確認すると、以下のようになります git push trigger build CI 環境 GitHub コンテナ レジストリ コンテナを動かす プラットフォーム コンテナ push 実行 ・単なるサーバ ・Amazon ECS ・Kubernetes などなど イメージ イメージ

Slide 36

Slide 36 text

コンテナのデプロイの流れ ● コンテナのデプロイの流れの基本を再度確認すると、以下のようになります イメージのビルドからデプロイまでの流れは、定型的な設定の Web アプリケーションであれば単に手間になることがあります git push trigger build CI 環境 GitHub コンテナ レジストリ コンテナを動かす プラットフォーム コンテナ push 実行 ・単なるサーバ ・Amazon ECS ・Kubernetes などなど イメージ イメージ

Slide 37

Slide 37 text

PaaS ● Heroku などの PaaS や AWS App Runner、Google Cloud Run のオプション などを使うと、イメージのビルドからデプロイまでを自動化できます 自力で Dockerfile を書く理由が特にない場合は、 このような PaaS などを使う選択肢もあります git push trigger build CI 環境 GitHub コンテナ レジストリ コンテナを動かす プラットフォーム コンテナ push 実行 ・単なるサーバ ・Amazon ECS ・Kubernetes などなど イメージ イメージ 自動で実行

Slide 38

Slide 38 text

コンテナの実行環境の整理 サーバありの コンテナ環境 アプリケーション フレームワーク ミドルウェア コンテナ サーバ サーバレスな コンテナ環境 アプリケーション フレームワーク ミドルウェア コンテナ サーバ PaaS など (Dockerfile 不要) アプリケーション フレームワーク ミドルウェア （コンテナ） サーバ ECS on EC2 GKE ECS on Fargate Google Cloud Run App Runner Heroku 例） 制約少ない 構築・運用コスト高 制約多い 構築・運用コスト低

Slide 39

Slide 39 text

コンテナを使う／使わない Dockerfile を書く／書かない

Slide 40

Slide 40 text

ローカル開発環境でのコンテナの利用について（1/2） ● まずはローカル開発環境でのコンテナの利用についてです ● ローカル開発環境では、データベースなどは OS に直接インストールせず、 コンテナで用意すると非常に便利です ● 一方、ローカル開発環境でプログラミング言語の実行環境をコンテナ化して 便利かは、主に OS のパッケージのインストールの有無次第と考えています

Slide 41

Slide 41 text

ローカル開発環境でのコンテナの利用について（2/2） ● Ruby・PHP などは、OS にパッケージをインストールする必要があることが 多いため、ローカル開発環境がコンテナ化されていると便利です ※ OS のパッケージというのは、例えば apt install や brew install などでインストールするものを指します ● Java・Go・Node.js などは OS のパッケージのインストールは不要なことが 多く、ローカル開発環境をコンテナ化するメリットがないことも多いです OS のパッケージのインストールが不要な場合は、 言語（ランタイム）のバージョンに注意すれば十分なことも多いです ※ もしコンテナ化する場合でも、OS のパッケージのインストールが不要なら、Dockerfile は不要なことも多いです

Slide 42

Slide 42 text

開発環境と本番環境でのコンテナの利用（1/2） ● 開発環境でコンテナを使うことと、本番環境でコンテナを使うことは、別の 論点として考えるのが良いと思います 開発環境でコンテナを使うからといって、本番などの環境でも コンテナを使うべきとは限りません（その逆も言えます） ローカル開発環境は利便性のためにコンテナで動かすが、 本番としてはコンテナ以外の方式で実行する場合もある Java でローカル開発環境をコンテナにするメリットはあまりないが、 本番などの環境でコンテナとして動かしたい場合はある

Slide 43

Slide 43 text

開発環境と本番環境でのコンテナの利用（2/2） ● 開発環境と本番環境ではイメージ（Dockerfile）に求められる特性も違います 個人的な意見としては、入門としては、 開発環境と本番環境では Dockerfile は別々に書くのが良いと思います ※ さらに、Heroku などを使う場合、特に理由がなければ Dockerfile は開発環境の分だけで良いと思います 開発環境 本番環境 ● 開発する時の利便性が重要なので 開発に使うツールなどが入ってい ても良い ● 自動テストを実行するときに使う ライブラリもインストールする ● デプロイの高速化やセキュリティ の観点から、イメージのサイズを 小さくするのが望ましい ● 自動テストに使うライブラリなど はインストールしない

Slide 44

Slide 44 text

改めて整理する Web アプリのビルド・デプロイの基本 【コンテナ編】

Slide 45

Slide 45 text

まとめ ● 開発したアプリケーションをコンテナ化して実行するときは、イメージを ビルドして、コンテナレジストリに格納し、デプロイする ● 本番などの環境でコンテナを動かすときは、コンテナを実行するための各種 プラットフォームを使うことが多い ● 開発環境・本番環境のそれぞれで、コンテナを使う・Dockerfile を書くかは それぞれ検討するのが良さそう まずは学習目的でなんでもコンテナ化して動かしたりすると 分かることもあるので、色々試してみるのがおすすめです

Slide 46

Slide 46 text

宣伝 ● Udemy で「AWSコンテナサービス入門」という講座を出しています AWSコンテナサービス入門 AWS 自体の基本・コンテナサービスの基礎に始まり、 AWS Copilot CLI を使用した実践レベルの環境構築、 注目の新しいコンテナサービス App Runner まで、 手を動かして学ぶ講座です！ エラーの解決や疑問点なども、できるだけサポートします クーポン付き URL を共有させていただくので、 ハンズオンもしてみたい方は是非手に取ってみてください