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

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

===

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

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

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

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

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

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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide