🫡

＜ウェビナー参加＞AWS Partner: Containers on AWS

に公開
ECS
AWS Fargate
container
idea

目的

この記事の目的：夏にAWS Partner Networkに参加したので自分用メモとして残します🫡
参加目的：よく使われてるコンテナについて、基本を抑えたいとの思いから参加しました🫡

所感

  • 座学9、ハンズオン1　コンテナ入門
  • 混同されやすいECS、Fargate、 EKS、それぞれ違いを抑えられて良かった
  • ハンズオンが少なく、デモを見ているだけだったので、身についた感はあんまりない🧐
    • 実際モジュール４はコンテナ関係なく、ほぼWell-Architectの話だった
    • 以前参加した AWS Partner NetworkのウェビナーWell-Architectが良すぎた？🧐
  • EKS使ってるお客さんはいるのか？受託開発には少ないイメージ
  • AWS的にはサーバレス推し、「Fargateをまず使ってください」とのこと
    • 自分のイメージは、サーバレスはオーバースペックになりがちでコスト高になりがち
    • でも面倒なOS アップデートとかはやってくれるんだよなぁ👍
  • コンテナオーケストレーションと言えば、長らくDocker一強だったが、最近はより軽量高速なPodManなど新しいものもあるらしい。使ってみたい。（使ってみたい😏）
    • 自分が関わる案件で、確かにDockerImageビルドが遅いと感じることがあった。

内容

  • ラボ ECSを使ってコンテナ化されたアプリをビルド＆デプロイ

    • タスク 1: Amazon ECS クラスターを作成する
    • タスク 2: Amazon ECR でコンテナイメージを探します
    • タスク 3: タスク定義を確認する
    • タスク 4: AWS Fargate を使用して Amazon ECS サービスを作成する

    画面ポチるだけだった、復習はterraformでやった方がいいかも😅

資料

※Basic認証あり、要パスワード
(https://container-tech.partner-course.com/pdfs/20240910_apc_containers_tech_share.pdf)

アジェンダ

  • コースオリエンテーション
  • Module1: クラウドネイティブな開発
  • Module2: コンテナを使用する理由
  • Module3: アマゾン ウェブ サービスにおけるコンテナ (ECS, Fargate, EKS)
  • Module4: アマゾン ウェブ サービスでコンテナを実行する (W-A フレームワーク, ベストプラクティス)
  • Module5: 学習リソースの紹介

↑要点のみ

ーーーーーーーーーーーーーー

↓自分用備忘

メモ

コンテナ入門

広い意味でコンテナ

モジュール１

クラウドネイティブ→より早くデプロイ、より早く開発

コンテナができること　アプリのコンポネント化

モノリスのデメリット　マイクロのメリット　（API EP）

裏返し

迅速な更新

言葉の意味おさらい　各どこまで自動化

遅い、アプリ全体でデプロイやから

速い、バラバラやから

パフォーマンス信頼性向上

可観測性　　　　　トレースサービス間の連携状況

モジュール2

抽象化レベル　右に行くほど抽象的/使いやすい

コンテナとは、OS上のいちプロセスにすぎない
ネットワーク依存度は仮想マシンとそう変わらん。使ったほうがいい

設定って？prd devの設定だけど、環境変数で設定した方がいい。
コンテナの最大メリット可搬性(どこでも動かせる、どこでも同じ稼働)を損ねる

デモ

Dockerfileを元にコンテナを作成

docker -t（タグ付コマンド）

コンテナを使ってウェブページ表示する

Dockerfile→コンテナイメージ設計書

アクセスできた

ここで言うコンテナプラットフォームがDockerのこと

下のOSがUbuntuでもコンテナはALinux　できる。なぜ？カーネルに共通部分があるから。これがWindowsだとできない

レジストリ、コンテナイメージ保管所
githubみたいな

コンテナイメージはレイヤー構造　
コードは左、上から実行　　　コンテナは右、下から構成される

コンテナイメージは重くなりがち、　　なぜ？ReadOnlyなので

  • イメージレイヤー（ReadOnly）

    • ビルド時に作られる複数のレイヤー（ファイルシステムのスナップショット）
    • 読み取り専用のため、直接上書きや削除はできない

  • コンテナレイヤー（ReadWrite）

    • 実行時に作られる
    • 変更（ファイルの作成・削除など）はここで行われる

    🔸 なぜ「重く」なりやすいのか？

    ① レイヤーの積み重ねによる肥大化

    Dockerfileで RUN, COPY, ADD などの命令を使うたびに、新しいイメージレイヤーが作られます。

    各レイヤーは前のレイヤーのスナップショットに対する追加/変更内容を含んでおり、すべてが保持されるため、レイヤーが増えるとその分サイズも大きくなります。

    ② ReadOnlyであることによる「削除の難しさ」

    イメージレイヤーは読み取り専用のため、「ファイルを削除してサイズを減らしたつもりでも、実際はサイズが減っていない」ということがあります。

    たとえば：

    Dockerfile
コピーする編集する
RUN apt-get update && apt-get install -y build-essential \
 && rm -rf /var/lib/apt/lists/*

    このように rm -rf しても、それは「そのレイヤーで削除されたように見える」だけで、前のレイヤーではファイルが残っている状態になります。

    つまり：

    • 削除しても、以前のレイヤーには残っている
    • 結果として、最終イメージのサイズは変わらないことが多い

コンテナ特有のセキュリティは下2つ

  • オフィシャルイメージ使おう。
  • 定期的にスキャンしよう

モジュール3

コンテナの冗長化

複数サーバ上で動いてるコンテナを管理する

COP（管理レイヤ）と各コンテナ（実行レイヤー）は別レイヤー　用語覚えろ

ECSでFagate使う、EKSでEC2使う。もできる

これを意識
・コントロールプレーン
・データプレーン

6つ

  • ECSクラスター
  • コンテナ(EC2)インスタンス
  • ECSサービス：
    • コンテナを”タスク”という単位で管理する（コンテナのASGみたいな）
    • ALBとの連携、増えた分(タスク内コンテナ)へ負荷流す
  • タスク
    • 複数のコンテナのセット(1個だけでも可)
      • 例
        • 言語が違う複数のAPPのログを転送したい
        • ログ転送専門のコンテナを作れる
        • これを言語が違う複数のAPPとセットにする（サイドカーパターン）
  • タスク定義
    • タスクに対する設定が書いてるjsonファイル
      • 例
        • そのタスクのコンテナイメージはどこから取得する？
        • そのタスクへどれくらいのメモリを当てる？
  • ECSエージェント
    • コンテナインスタンス内にいるECSサービスからの指令の受け手実行役
    • デーモン的な

同じこと書いてる

用語クイズ

ECSがどういった基準でタスクを配置するのか

  • タスク配置　＝　スケジューリング　用語

デフォ：APPの要件で配置

ビンパック：コスト◯

コマンド：

  • 5つタスクを作って
  • t2.small　または　t2.medium
  • us-east-1d　以外(! = ≠)のAZに

実務では、インスタンスタイプの指定はよくある

タスクのデプロイの仕方

デモ

モジュール2で作ったイメージを利用

  • タスクろーる
  • タスク実行ロール

一つのクラスタ内で複数のASG仕様の場合、どのASGに重みをつけるか。

IP変わってる＝ALB使えてる

Fargate

データプレーンが、EC2ではなく、Fagate（サーバ管理不要）になる
とりあえずFagate使って、コスト見合わないならECSってのがよくある導入

設定方法はそんな変わらん、画面上タスク定義の中でFargateポチる

コンテナイメージ、→タスク定義、→それ実行　（ECSと同じ）

CPUメモリを選ぶのはFagateのみ

ラボ１

画面ぽちぽち

Amazon EKS

kubernetesとAmazon EKSはあくまで別

Amazon EKSの準拠元　オンプレで使うことが多い

APIサーバ：指示を受けて、コントローラマネジャ クラウドコントロラ スケジューラに指示出す
クラウドコントロラ：AWS内で他サービスと連携　kubernetesのAWSで使う為のプラグイン的な
etcd：Kubernetesクラスタ内の情報がある。今コンテナ何個起動してるとか
Pod：ECSで言うタスク的な
containerd：コンテナ内で実行されているランタイム（プログラムを実行するために必要な環境）
kubelet：ECSで言うECSエージェントみたいな

kubernetesと同じコマンドで操作できる

コントロールプレーンの可用性を高める

まとめると
Amazon EKSは何やってる？
kubernetesのコントロールプレーンを代行
＋他AWSリソースとの連携ができる

YAML宣言式

kind:Pod　→　Podを作りたい
spec: spacification
　　containers 　→　こんなコンテナ作りたい

ECSサービスに当たるもの

ReplicaSet：Pod数の維持
Deployment：更新をかける　ReplicaSetをラッピングして持ってる的な

デモ

Kubernetesのネットワーク

Serviceの役割：複数Podにアクセスする単一のEP作成
　　　　　　　　レイヤ４TCPレベルのELB

レイヤ７レベルのELB
ServiceへのELB

デモ

ServiceとIngressを作る ALBと連携させる

kubectl apply -f service.yaml

kubectl get svc

kubectl apply -f ingress.yaml

EKS？ECS？どっち使う？

親AWSはECS、その他AWSと連携が前提。純粋なコンテナオーケストレーションは EKSが勝つ

でも、Amazon EKSはkubernetesを知らないとできない

モジュール4

上記に加えてこれできる

コンテナ特有のセキュリティ

モジュール5

今日のまとめ

Discussion