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

●発表の中で紹介しているUdemy講座：https://www.nextskill.co.jp/courses

===

Webアプリケーションのビルド・デプロイについて学んだりすると、「コンテナの場合はどうするの？」といった疑問を持つ方は少なくありません。

近年はアプリケーションの実行環境としてDockerなどのコンテナ技術を使うことが多く、開発環境などでふれたことがある方はとても多いです。

しかし、Dockerなどで開発環境を構築することができても、コンテナで本番などの環境を作るにはどうすればいいのか分からない、ということは少なくありません。

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

3/9の勉強会「改めて整理するWebアプリのビルド・デプロイの基本」に引き続き、ビルド・デプロイについての疑問を解消していきます。

イベントページ
https://studyco.connpass.com/event/277659/

Transcript

1. 改めて整理する Web アプリのビルド・デプロイの基本 【コンテナ編】
2. 自己紹介 • 名前：大嶋勇樹（Twitter：@oshima_123） ◦ 最近はよく「しま」と呼ばれています • キャリア ◦ 都内の某 IT 企業 -> フリーランスエンジニア -> 会社設立 ◦ “ ” 現在は 実務につき始めたエンジニアのスキルアップをサポート ◦ 研修・勉強会の開催・Udemy 講座の作成など • よく関わる技術分野 ◦ クラウド・コンテナ関連 (AWS、GCP、Docker、Kubernetes など) ◦ Web アプリのビルド・デプロイまわりの整備はよく担当
3. Udemy 講座の紹介 • 今日の発表と関連しそうなテーマでは、以下のような講座を出しています Linuxとネットワークの基礎から学ぶDocker入門 Linuxとネットワークの基礎知識からDockerを使った開発環境構築まで AWSコンテナサービス入門 AWSの基本からECS・Copilot CLI・CI/CD・App Runnerまで GitHub Actionsで学ぶCI/CD入門 ビルド・デプロイの基本からAPI自動テスト・AWSへの自動デプロイまで ↖️ 今日の発表は、こちらからも抜粋
4. 改めて整理する Web アプリのビルド・デプロイの基本 【コンテナ編】
5. 背景 近年はアプリケーションの実行環境として Docker などのコンテナ技術を 使うことが多く、開発環境などでふれたことがある方はとても多いです Web アプリケーションのビルド・デプロイについて学んだりすると、 「コンテナの場合はどうするの？」と疑問を持つ方は少なくありません
6. しかし... • Docker や Docker Compose を使ってコンテナでローカル開発環境の構築は できても、コンテナで本番などの環境を作る知見はないという方は多いです • 実際、コンテナで開発環境を構築する知識と、本番環境を構築する知識には ある程度違いがあると思います
7. そこで今日は... そこでこの勉強会では、 Docker などのコンテナ技術を使った ビルド・デプロイの基本を改めて整理します
8. アジェンダ • （復習）Web アプリケーションのビルド・デプロイの基本 • コンテナのビルド・デプロイの流れの基本 • コンテナを動かすプラットフォームの概要 • コンテナを使う／使わない・Dockerfile を書く／書かない
9. 前提知識 • Web アプリケーションの基礎知識があること （Web アプリケーションの実装経験か、サーバへのデプロイ経験があるのが目安です） • Docker と Docker Compose にふれたことがあること
10. （復習） Web アプリケーションのビルド・デプロイの基本
11. プログラムの実装からリリースまでのステップ • プログラムを実装してからリリースするまでには、例えば以下のような ステップがあります ここから、「ビルド」と「デプロイ」について簡単に復習します 実装・ 単体テスト テスト環境に デプロイ 本番環境に デプロイ ビルド テスト環境で テスト
12. Web アプリケーションの構成の基本 • Web アプリケーションの実装で作成するファイルとしては、主に 「静的コンテンツ」と「サーバサイドのプログラム」の 2 種類があります HTML Web サーバ ブラウザ アプリケーション データベース CSS Java・Ruby 等 JS 静的コンテンツ 固定の HTML や CSS、 ブラウザ用の JavaScript など サーバサイドのプログラム HTML や JSON を生成して返す （様々な言語で実装される） Web アプリケーションでは、静的コンテンツを Web サーバで配信・ サーバサイドのプログラムをサーバで実行します
13. ビルド • プログラムは、実装した形式でそのまま実行するとは限りません • 例えば Java のプログラムを動かす場合、以下のような変換をしたりします main.java main.javac コンパイル / トランスパイル 別の言語に変換 hoge.java hoge.javac app.jar パッケージング / バンドル / リンク 1 ファイルにまとめる 成果物（Artifact） java コマンドで 実行する対象 ソースコードをもとに、最終的に本番などのサーバで動かす形式に 変換することを「ビルド」と言います ※ プログラミング言語（実行環境）次第で、ビルドは不要な場合もあります
14. デプロイ • Web アプリケーションのサーバサイドは、ビルド成果物をサーバにアップ ロードして実行します 本番などの環境 アップロード ビルド ビルド成果物を本番などのサーバに配置することや、 配置したビルド成果物を実行することを「デプロイ」と言います サーバ （コンピュータ） app.jar 実行 java -jar app.jar
15. フロントエンドのビルド • 近年の Web フロントエンド開発では React や Vue.js などを使って、 「.jsx」や「.vue」といったファイルを実装することが多いです • これらのファイルは、JavaScript に変換してから Web サーバで配信します ソースコードを JavaScript に変換したり、JavaScript の複数の ファイルを 1 つにまとめたりするのが、フロントエンドのビルドです HTML Web サーバ ブラウザ CSS JS .vue .jsx 変換
16. Web アプリケーションのビルド・デプロイのまとめ • ここまでの内容を図にすると以下のようになります 本番などの環境 デプロイ ビルド Web サーバ を動かすサーバ （コンピュータ） ※ Web サーバとアプリケーションは 　 同じサーバ（コンピュータ）で動かすこともあります フロントエンドの ソースコード 成果物 ブラウザ データベース デプロイ ビルド アプリケーション を動かすサーバ （コンピュータ） サーバサイドの ソースコード 成果物
17. CI/CD • GitHub などへのソースコードの push をトリガーに、ビルド・自動テスト・ デプロイなどを専用の環境で実行する CI/CD を構築することも多いです ここまでで、「ビルド」と「デプロイ」の基本と、 CI/CD の概要を復習しました git push trigger deploy build test 本番などの環境 サーバ （コンピュータ） CI 環境 GitHub
18. コンテナのビルド・デプロイの流れの基本
19. コンテナとは • Docker などの「コンテナ」は、仮想化技術の一種です • コンテナにはゲスト OS がないため、VM よりとても軽量です VM (仮想マシン) コンテナ アプリケーション ミドルウェア・ ライブラリ ゲスト OS ホスト OS VM 型仮想化用ソフトウェア アプリケーション ミドルウェア・ ライブラリ ゲスト OS アプリケーション ミドルウェア・ ライブラリ ホスト OS コンテナ型仮想化用ソフトウェア アプリケーション ミドルウェア・ ライブラリ
20. コンテナ実行の基本 • コンテナを実行するときは、コンテナのもとになる「イメージ」が必要です • 例えば、Docker 公式の「ubuntu:22.04」というイメージをもとに、PC 上で コンテナを実行するときは、以下のような流れになります PC インターネット上の コンテナレジストリ (DockerHub など) コンテナ イメージ ubuntu:22.04 イメージ ubuntu:22.04 コンテナの 実行 (run) イメージの ダウンロード (pull)
21. イメージの自作と実行 • 自分たちが開発したアプリケーションをコンテナ化して実行するときは、 以下のような流れになります サーバ コンテナレジストリ コンテナ イメージ myapp:v1 イメージ myapp:v1 PC 等 イメージ myapp:v1 src Dockerfile イメージの 作成 (build) イメージのアッ プロード (push) コンテナの 実行 (run) イメージの ダウンロード (pull)
22. 例）AWS の場合 • AWS には ECR というコンテナレジストリのサービスがあります • 例えば AWS の EC2（サーバ）でコンテナを実行するときは、以下のような 流れになります コンテナ イメージ myapp:v1 イメージ myapp:v1 PC 等 イメージ myapp:v1 src Dockerfile EC2 ECR build push pull run
23. CI 環境でのビルド • 手作業での作業ミスや、特定の PC でしかビルドできない状況を防ぐため、 ビルドはビルド専用の環境（CI 環境）で行うのが望ましいです イメージ myapp:v1 CI 環境 イメージ myapp:v1 src Dockerfile build push コンテナレジストリ
24. コンテナのデプロイ • コンテナをデプロイする一番シンプルな方法は、サーバにログインして docker run や docker compose up などのコマンドを実行することです サーバ コンテナレジストリ コンテナ イメージ myapp:v1 イメージ myapp:v1 pull run
25. コンテナを動かすプラットフォーム • 実際には、本番などの環境でコンテナを動かすときは、Docker や Docker Compose を使わず、コンテナの各種プラットフォームを使うことが多いです どんな環境でコンテナを動かす場合でも、 この流れがまずおさえたい基本になります git push trigger build CI 環境 GitHub コンテナ レジストリ コンテナを動かす プラットフォーム コンテナ push run ・単なるサーバ ・Amazon ECS ・Kubernetes などなど イメージ イメージ
26. コンテナを動かすプラットフォームの概要
27. そもそもなぜコンテナを使うのか • ここで、本番環境でコンテナを使うメリットを確認しておきます サーバよりも起動が高速なため、 開発サイクルの高速化やオートスケールといった面で有利 環境構築済みのイメージを運搬して実行するため、 他の環境でテストした動作を本番でも保証しやすい サーバ内で環境を分離できるため、 1 つのサーバ内で様々なアプリケーションを動かしても競合しにくい ↖️ ここから、1 つのサーバ内で様々なコンテナを 動かすことを考えていきます
28. • 1 台のサーバを増強してたくさんのコンテナを動かす方針では、サーバの スペックの限界があります • また、サーバが 1 台停止するだけで、その中でコンテナとして動いている Web アプリケーションなどにアクセスできなくなってしまいます サーバ CPU 16 コア メモリ 64 GiB 1 台のサーバの限界 CPU 0.5 コア メモリ 1GiB CPU 1 コア メモリ 2GiB コンテナ A コンテナ B
29. • 複数台のサーバでたくさんのコンテナを使う方針であれば、コンテナの数が 増えても、その分サーバを増やすことで対応可能です • また、サーバ間でコンテナを冗長化させておけば、サーバが 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
30. 問題点 • 複数台のサーバでたくさんのコンテナを使うためには、どのサーバにどの コンテナを配置するのが適切か考えるのが大変です • 特にコンテナをオートスケールしたりさせることを考えると、手作業で サーバとコンテナを対応づけるようなことは現実的ではありません コンテナ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
31. • 「コンテナオーケストレーション」のツールを使えば、クラスタ（サーバの まとまり）に対して、コンテナを適当に配備（デプロイ）してくれます クラスタ サーバ 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
32. Kubernetes と Amazon ECS • コンテナオーケストレーションツールとしては、OSS の Kubernetes と Amazon ECS が定番の選択肢です • Kuberentes はエコシステムやカスタマイズ性が強力な一方で、 Amazon ECS のほうがバージョンアップなどの運用コストは低いです
33. • 複数のサーバでコンテナを動かす場合、コンテナとサーバの両方の考慮が 必要になります クラスタ サーバ サーバ サーバ サーバ管理の手間 Amazon ECS 配備 CPU などの負荷に応じて コンテナをオートスケール コンテナが増えるのに応じて サーバをオートスケール コンテナ A コンテナ B コンテナ A コンテナ B
34. サーバレスなコンテナ実行環境 • ECS on Fargate や Google Cloud Run などサーバレスなコンテナ実行環境を 使うと、サーバ管理なしでコンテナを実行できます クラスタ Amazon ECS on Fargate 配備 サーバを自前で管理するのに比べて制約が増える一方で、 サーバのスケーリングなどを自前で管理する必要がなくなります コンテナ A コンテナ B コンテナ A コンテナ B
35. コンテナのデプロイの流れ • コンテナのデプロイの流れの基本を再度確認すると、以下のようになります git push trigger build CI 環境 GitHub コンテナ レジストリ コンテナを動かす プラットフォーム コンテナ push 実行 ・単なるサーバ ・Amazon ECS ・Kubernetes などなど イメージ イメージ
36. コンテナのデプロイの流れ • コンテナのデプロイの流れの基本を再度確認すると、以下のようになります イメージのビルドからデプロイまでの流れは、定型的な設定の Web アプリケーションであれば単に手間になることがあります git push trigger build CI 環境 GitHub コンテナ レジストリ コンテナを動かす プラットフォーム コンテナ push 実行 ・単なるサーバ ・Amazon ECS ・Kubernetes などなど イメージ イメージ
37. PaaS • Heroku などの PaaS や AWS App Runner、Google Cloud Run のオプション などを使うと、イメージのビルドからデプロイまでを自動化できます 自力で Dockerfile を書く理由が特にない場合は、 このような PaaS などを使う選択肢もあります git push trigger build CI 環境 GitHub コンテナ レジストリ コンテナを動かす プラットフォーム コンテナ push 実行 ・単なるサーバ ・Amazon ECS ・Kubernetes などなど イメージ イメージ 自動で実行
38. コンテナの実行環境の整理 サーバありの コンテナ環境 アプリケーション フレームワーク ミドルウェア コンテナ サーバ サーバレスな コンテナ環境 アプリケーション フレームワーク ミドルウェア コンテナ サーバ PaaS など (Dockerfile 不要) アプリケーション フレームワーク ミドルウェア （コンテナ） サーバ ECS on EC2 GKE ECS on Fargate Google Cloud Run App Runner Heroku 例） 制約少ない 構築・運用コスト高 制約多い 構築・運用コスト低
39. コンテナを使う／使わない Dockerfile を書く／書かない
40. ローカル開発環境でのコンテナの利用について（1/2） • まずはローカル開発環境でのコンテナの利用についてです • ローカル開発環境では、データベースなどは OS に直接インストールせず、 コンテナで用意すると非常に便利です • 一方、ローカル開発環境でプログラミング言語の実行環境をコンテナ化して 便利かは、主に OS のパッケージのインストールの有無次第と考えています
41. ローカル開発環境でのコンテナの利用について（2/2） • Ruby・PHP などは、OS にパッケージをインストールする必要があることが 多いため、ローカル開発環境がコンテナ化されていると便利です ※ OS のパッケージというのは、例えば apt install や brew install などでインストールするものを指します • Java・Go・Node.js などは OS のパッケージのインストールは不要なことが 多く、ローカル開発環境をコンテナ化するメリットがないことも多いです OS のパッケージのインストールが不要な場合は、 言語（ランタイム）のバージョンに注意すれば十分なことも多いです ※ もしコンテナ化する場合でも、OS のパッケージのインストールが不要なら、Dockerfile は不要なことも多いです
42. 開発環境と本番環境でのコンテナの利用（1/2） • 開発環境でコンテナを使うことと、本番環境でコンテナを使うことは、別の 論点として考えるのが良いと思います 開発環境でコンテナを使うからといって、本番などの環境でも コンテナを使うべきとは限りません（その逆も言えます） ローカル開発環境は利便性のためにコンテナで動かすが、 本番としてはコンテナ以外の方式で実行する場合もある Java でローカル開発環境をコンテナにするメリットはあまりないが、 本番などの環境でコンテナとして動かしたい場合はある
43. 開発環境と本番環境でのコンテナの利用（2/2） • 開発環境と本番環境ではイメージ（Dockerfile）に求められる特性も違います 個人的な意見としては、入門としては、 開発環境と本番環境では Dockerfile は別々に書くのが良いと思います ※ さらに、Heroku などを使う場合、特に理由がなければ Dockerfile は開発環境の分だけで良いと思います 開発環境 本番環境 • 開発する時の利便性が重要なので 開発に使うツールなどが入ってい ても良い • 自動テストを実行するときに使う ライブラリもインストールする • デプロイの高速化やセキュリティ の観点から、イメージのサイズを 小さくするのが望ましい • 自動テストに使うライブラリなど はインストールしない
44. 改めて整理する Web アプリのビルド・デプロイの基本 【コンテナ編】
45. まとめ • 開発したアプリケーションをコンテナ化して実行するときは、イメージを ビルドして、コンテナレジストリに格納し、デプロイする • 本番などの環境でコンテナを動かすときは、コンテナを実行するための各種 プラットフォームを使うことが多い • 開発環境・本番環境のそれぞれで、コンテナを使う・Dockerfile を書くかは それぞれ検討するのが良さそう まずは学習目的でなんでもコンテナ化して動かしたりすると 分かることもあるので、色々試してみるのがおすすめです
46. 宣伝 • Udemy で「AWSコンテナサービス入門」という講座を出しています AWSコンテナサービス入門 AWS 自体の基本・コンテナサービスの基礎に始まり、 AWS Copilot CLI を使用した実践レベルの環境構築、 注目の新しいコンテナサービス App Runner まで、 手を動かして学ぶ講座です！ エラーの解決や疑問点なども、できるだけサポートします クーポン付き URL を共有させていただくので、 ハンズオンもしてみたい方は是非手に取ってみてください