omuronの備忘録

個人的な備忘録

CloudFormation ドリフト対象外のリソースに注意

CloudFormation で作成したリソースは、作成したテンプレートと異なっている場合は、ドリフトとして検知することができます。

スタックのドリフトステータス ドリフトの検出により、スタックの実際の設定が、そのテンプレート設定と異なっていたり、ずれたりしていないか確認できます。

f:id:omron:20210914195621p:plain


ドリフトのステータスは、リソースごとに検出して表示されます。

f:id:omron:20210914200024p:plain

ここには以下の注意書きがあります。

現在、ドリフトの検出をサポートしているリソースのみがここに表示されます。すべてのスタックリソースを表示するには、スタックの詳細ページを確認します。 詳細はこちら

「ドリフトの検出をサポートしているリソースのみがここに表示されます。」と書いていますが、実際にはドリフト検出対象外のリソースも含まれているため、注意が必要です。
実際にサポートしているリソースについては 「 詳細はこちら」 のドキュメントを参照する必要があります。


今回作成していた AWS::EC2::EgressOnlyInternetGateway が、何もしてないのに壊れた(ドリフトになってた)ので調べると、対象外のリソースも関係なく表示されていたため、この罠を知りました。
マネージメントコンソールだけではなく、ドキュメントもちゃんと読みましょうというオチでした。

「AWSの基礎を学ぼう 第五十八回 AWS CodePipeline」 #awsbasics 受講メモ

awsbasics.connpass.com

CodeBuild はよく使うけど、CodePipeline はまだまだ慣れてません。

セッション

AWS CodePipeline おさらい

講師:アマゾン ウェブ サービス ジャパン、シニアエバンジェリスト 亀田氏

AWS CodePipeline 概要

  • 継続的デリバリーサビス
  • リリースプロセスをモデル化
  • AWS サービスだけではなくサードパーティのツールと統合
  • 同時に複数の並行処理も可能

CodePipeline の作成

  • パイプライン作成
    • 名前とロール設定
    • ソースプロバイダー
      • GitHub, CodeCommit, BitBucket...
      • GitLab は使えない
    • ビルド
      • CodeBuild, Jenkins, TeamCity, CloudBees
    • デプロイ
      • CodeDeploy, ECS, CFn, S3...
      • Lambda はできない
    • Custom アクション
      • テストなどを追加して失敗すればロールバックなど
      • Job Worker 作成
      • Lambda の実行
      • Step Functions の実行
    • Approval アクション
      • 承認プロセスを追加できる
    • 通知
      • SNS 経由で可能
        • Chatbot 経由で Slack へ
        • Webhooks で Slack/Teams など
  • GitHub と連携
    • Code シリーズの「設定」-「接続」から可能
  • パイプライン内で変数の引き渡し可能
  • 全てに対して VPC エンドポイントあり
  • Assume Role でクロス AWS アカウント連携可能

所感

CodePipeline は、Approval 入れたり CodeDeploy と連携して動かすところに価値を感じるので、簡単なデプロイ作業だと CodeBuild だけでシンプルに作ってしまいます。
CodePipeline は、パイプラインごとにお金が多少なりともかかるのも気になるところ...

CFn で、CodePipeline も含めて書くのが大変だったので、こういう言い訳のもとあまり使えないで今に至っています。
CDK だとそれなりに書きやすかったので、脱 CFn して CDK に慣れて CodePipeline にも慣れるようにがんばります。

「AWSの基礎を学ぼう 第五十七回 AWS CodeBuild」 #awsbasics 受講メモ

awsbasics.connpass.com

CodeBuild は好きなサービスの一つです。
よく利用しているサービスのお話を聞くのは初めてです!

セッション

AWS CodeBuild おさらい

講師:アマゾン ウェブ サービス ジャパン、シニアエバンジェリスト 亀田氏

AWS CodeBuild

  • フルマネージドなビルドサービス
  • 同時複数ビルド
  • イミュータブルな環境
    • 新規 Docker コンテナで実行
    • AWS CLI が入った Docker マネージドイメージが準備されている
      • 東京リージョンはまだだけど Windows もある
      • Docker イメージを自分で準備も可能
        • ECR とか Docker Hub とか
  • CloudWatch 連携
    • SNS 経由で通知可能

BuildSpec.yml

  • Version 0.2 が最新
  • run-as Linux ユーザーの指定
  • env 環境変数
    • SSM などに設定した値を環境変数に埋め込んで参照させるなど
  • proxy プロキシサーバー設定
  • batch バッチビルド設定
    • build-graph 依存関係のある複数ジョブ
      • 順番に実行
    • build-list 並行して実行
      • 同時に実行
    • build-matrix 並行して実行される異なる構成のタスク定義
      • 複数 yml 準備して、様々な環境を並行して実行
  • phases ビルドの各段階で実行するコマンドを記述
    • install pre_build build post_build
  • reports テストレポートの作成
    • テストレポートとコードカバレッジレポートの2種類
      • グラフで出力
      • テストレポート: Cucumber JSON, JUnitXML, NUnitXML, NUnit3 XML, TestNGXML, Visual Studio TRX
      • コードカバレッジレポート:Clover XML, Cobertula XML, JaCoCoXML, SimpleCovJSON
  • artifacts 成果物出力
  • cache キャッシュ設定
    • ソースキャッシュ
    • Docker レイヤーキャッシュ
    • カスタムキャッシュ

その他リソースとの連携

  • VPC エンドポイント利用で VPC アクセス可能
  • Session Manager でビルド環境へアクセス可能
    • 高度な機能の上書きオプションから Session Manager 経由でアクセス

所感

CodeBuild は好きなサービスですが、 phases でなにもかもやってしまって、 artifacts すら活用できてません。

ローカルキャッシュに癖があって、まともに効かない気がするのですが、みんなうまく使えてるんですかね...?
「5分以内のビルド、かつ、直近のビルドから15分以内、かつ同じホストで動かいとき」
しか動いてなさそうと聞いたことがあります。
S3 キャッシュを使うほうが無難とは思いますが、もっと気軽にキャッシュ使えるといいのにとは思いました。

batch 実行については全く知らなかったので、勉強になりました。
こんな色々な実行方法があったんですね。

アタッチできないロールがある

ECS Fargate をオートスケールしたい

ECS Fargate をオートスケールさせたいので、適切なマネージドポリシーを検索したところ
AWSApplicationAutoscalingECSServicePolicy というポリシーが見つかりました。

f:id:omron:20210905123734p:plain

これを CDK で利用するために以下のコードを実装しました。

import * as autoscaling from '@aws-cdk/aws-applicationautoscaling'
import * as iam from '@aws-cdk/aws-iam'

〜〜略〜〜

    // IAM Role
    const applicationAutoscalingRole = new iam.Role(this, 'ApplicationAutoscalingEcsRole', {
      roleName: 'application-autoscaling-role',
      assumedBy: new iam.ServicePrincipal('application-autoscaling.amazonaws.com'),
      managedPolicies: [
        iam.ManagedPolicy.fromAwsManagedPolicyName(
          'aws-service-role/AWSApplicationAutoscalingECSServicePolicy'
        ),
      ],
    })

アタッチできないエラーが発生

このコードをデプロイしてみると、以下のエラーが発生しました。

Cannot attach a Service Role Policy to a Customer Role.

「カスタマーロールに、サービスロールはアタッチすることができない」というエラーが発生。
このエラーが出たのが初めてだったので、ドキュメントを見てみると

Amazon Elastic Container Service 用の AWS マネージドポリシー - Amazon ECS

AWSApplicationAutoscalingECSServicePolicy

IAM エンティティに AWSApplicationAutoscalingECSServicePolicy をアタッチすることはできません。このポリシーは、ユーザーに代わって Application Auto Scaling がアクションを実行することを許可する、サービスにリンクされたロールにアタッチされます。

アタッチできないロールというのがあるんですね。
aws-service-role/ というパスも初めてみたので、このパスが付いているものが使えないと思われます。

別途ポリシーを設定して対応

アタッチできないので、このマネージドポリシーを参考にして必要なロールを抜き出して設定することにしました。

    // IAM Role
    const applicationAutoscalingRole = new iam.Role(this, 'ApplicationAutoscalingEcsRole', {
      roleName: 'application-autoscaling-role',
      assumedBy: new iam.ServicePrincipal('application-autoscaling.amazonaws.com'),
      /* // `aws-service-role` なのでアタッチできない
      managedPolicies: [
        iam.ManagedPolicy.fromAwsManagedPolicyName(
          'aws-service-role/AWSApplicationAutoscalingECSServicePolicy'
        ),
      ],
      */
    })
    applicationAutoscalingRole.addToPolicy(
      new iam.PolicyStatement({
        effect: iam.Effect.ALLOW,
        resources: ['*'],
        actions: [
          'ecs:DescribeServices',
          'ecs:UpdateService',
          'cloudwatch:DescribeAlarms',
        ],
      })
    )

この IAM を利用することで無事に ECS Fargate のオートスケールができました。

「JAWS-UG名古屋 コンテナサービスを学ぶ」 #jawsug_nagoya 受講メモ

jawsug-nagoya.doorkeeper.jp

後ほど YouTubeアーカイブ公開とのこと!

セッション

コンテナアップデート

講師:アマゾン ウェブ サービス ジャパン、シニアエバンジェリスト 亀田氏

  • 2020/07 AWS Copilot リリース
    • CLI のツールキット
    • プロダクションレディな環境構築、リリース、運用
    • CFn テンプレートを作成して実行
    • Application/Environment/Service に抽象化
      • App : Env と Service をまとめて管理
      • Env : Service を動かす設定
  • 2020/12 Lambda で OCI 準拠のコンテナの起動が可能に
  • 2021/03 ECS Exec
    • SSM で使ってシェル操作
    • エージェント方式、コンテナにエージェント入れる
    • インバウンドのポートを開ける必要なし、IAM で接続可能
  • 2021/05 App Runner
    • コンテナイメージあれば簡単に起動
    • VPC 外での起動
    • コンテナイメージ無しでも JS や Python であれば起動可能
  • 2021/06 Bottlerocket AMI
    • コンテナ実行向けに構築された Linux OS
      • ssh もシェルも無い
      • /etc もブートごとにリセットされる
  • 2021/06 ECS Anywhere
    • AWS 外で ECS を動かせる

Amazon ECS Capacity Providersをよるオートスケーリング入門

JAWS-UG名古屋 杉本さん

  • re:Invent 2019 で発表
    • ECS をいい感じでオートスケール
  • ASG をラッピングして抽象化するサービス
    • ECS on EC2 向け
    • インスタンスのオートスケールの管理が不要に
    • 細かい設定が使えるのがメリット

飛び込みLT1

大西勉さん

docs.google.com

飛び込みLT2

田中隆博さん

ECS を Fargate で構築した話

www.slideshare.net

  • クラウドなのにEC2使うの?コンテナは?
    • やってみる
  • Django アプリ構築
    • ECS Fargate + RDS
  • コンテナが起動しない
    • 調査が必要
    • docker exec はそのままだと使えない
    • enableExecuteCommand を CLI で有効化が必要
    • CLI のバージョンを最新にしないとできなかった

飛び込みLT3

織田繁さん

使って分かった Amplify が使いやすいと言われる理由

  • Amplify は爆速なお話
  • Nuxt.js を Git にコミットすると自動デプロイできる環境を簡単に構築
  • 非公開のサイトも簡単に作れる

所感

ECS を一応使ったりしているのですが、かなり難解ですよね。
マネジメントコンソールでそれっぽいのは作れても、CFn で構築しようとするとかなり辛くて、途中で諦めてしまいました。
CDK だったらだいぶ抽象化されているので作りやすいのですが、Copilot になると抽象化されすぎてて辛いイメージがあります。
Copilot で作って、Espresso で操作するのもありかなと試してました。
App Runner は VPC で使えるようになってからが本番ですかね。

という話でも LT しようかと思っているうちに時間がなくて聞くだけになってしまいました。
即興で LT できるのがみなさま素晴らしいです。

「AWSの基礎を学ぼう 第五十六回 AWS Batch」 #awsbasics 受講メモ

awsbasics.connpass.com

「Batch といえばバッチ処理でしょう」と勘違いしていた AWS Batch です。

セッション

AWS Batch おさらい

講師:アマゾン ウェブ サービス ジャパン、シニアエバンジェリスト 亀田氏

バッチコンピューティングとは

AWS Batch

  • コンテナイメージを用意すればスケーラブル/大規模バッチ処理可能
    • バッチ処理環境をコンテナ化できるのであればオススメ
    • 画像解析とか重くて大量の処理向け
      • 軽い処理はわざわざ使わなくていい
  • アーキテクチャ
    • ジョブ定義からジョブ作成
      • ジョブ作成時に定義を書換可能(ECS は書き換えできないけど Batch は可能)
    • ECR/Docker Hub/Nvidia GPU Cloud などからコンテナイメージ取得
    • ECS で処理
      • Fargate, Fargate Spot, EC2 オンデマンド, EC2 スポット
    • S3 や EFS, FSx for Lustre に処理結果を保存
  • ジョブ投入方法
    • Lambda (S3イベント経由とか)
    • Step Functions
    • CloudWatch Events
    • などなど...
  • ジョブ種類
    • 単一ジョブ
      • 1回のジョブ投入で1ジョブを作成
      • 大規模向けなのでこのケースはテストとかだけで使う
    • 配列ジョブ
      • 1回のジョブ投入で複数の子ジョブを作成
    • マルチノード並列ジョブ
      • 1回のジョブ投入で複数の子ジョブを作成
      • 複数コンテナ間で通信処理
  • ジョブ依存関係
    • 各ジョブに依存関係で前後関係を設定可能
      • ジョブ結果でフロー制御をしたければ Step Functions も利用する

所感

re:Invent 参加している時に「AWS Batch」が発表されて、セッションを受講したところ「思ってたのと違うな...」となった原因は、夜間バッチとかをイメージしていたためでした。
業務上、大規模計算とかしたいケースが思い浮かばないので、使うことはしばらくなさそうかな。 Fargate とか使っているのであれば、比較的容易に利用可能そうですね。

「JAWS-UG朝会 #24」 #jawsug_asa 受講メモ

JAWS-UG朝会 #24

jawsug-asa.connpass.com

今回は朝会の前にご飯食べて準備するぐらい早起きできました。

セッション

セッション① EC2 の起動するインスタンスタイプを制限する方法

株式会社サーバーワークス 小倉 大さん

www.slideshare.net

AWS Service Catalog

  • ポートフォリオから AWS サービスを起動
    • 制限かけるとリスクを最小化できる
    • CFn テンプレートから Service Catalog を通じてデプロイ
  • 「制約」メニューで制限をかける

IAM ポリシー

  • "Resource": "arn:aws:ec2:*:*:instance/*"
    • Condition で制限
      • ec2:InstanceType を限定する

AWS Config

  • AWS リソースの設定を評価、変更管理できる
    • desired-instance-type を追加する
      • パラメータの値のインスタンスタイプで限定する
        • 警告が出るだけで起動できる
        • 修復アクションで、ターミネートしてしまう
          • Systems Manager オートメーションで削除

セッション② 利用するリージョンを限定しよう 〜 「おひとりさまOrganizationsのススメ」

運用設計ラボ合同会社 波田野 裕一さん

speakerdeck.com

利用するリージョンを限定したい

  • 2019/05/05 香港リージョンGA
    • 新リージョンはデフォルト無効
    • 既存リージョンはオフにできない
  • Organizations のポリシー(SCP)を利用
    • 子アカウントなら root も制約可能
    • 組織ツリーを作り、SCP アタッチ

SCP で限定する

  • グローバルサービスは許可
  • 利用しているリージョンのみ許可

AWS: リクエストされたリージョンに基づいて、AWS へのアクセスを拒否する より

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllOutsideRequestedRegions",
            "Effect": "Deny",
            "NotAction": [
                "cloudfront:*",
                "iam:*",
                "route53:*",
                "support:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "eu-central-1",
                        "eu-west-1",
                        "eu-west-2",
                        "eu-west-3"
                    ]
                }
            }
        }
    ]
}

LT① AppSyncに全集中!subscriptionでハマったところ

北海道テレビ放送株式会社 三浦 一樹さん

speakerdeck.com

ライブコマース

  • 動画見ながらお買い物サイト
    • 動画に合わせて商品を切り替えたい
  • AppSync で実現
    • GraphQL のマネージドサービス
    • Subscription で WebSocket 貼れる
      • これを利用して再読み込み無しで更新させる

クォータは事前に確認しよう

  • AppSync の Subscription をきっかけの全ユーザーに Query
    • GraphQL API のスロットル 1000/s
      • Subscription はセッション貼るときに消費されるので問題なし
      • WebSocket 貼ってる数が多いとクォータにかかる

回避策

  • AppSync 上限緩和...DynamoDB の制限にかかりそうなので根本解決できず
  • APIG + Lambda + DynamoDB で再実装
  • Subscription で振ってくるデータだけで表示変更
    • これがあるべき姿

LT② ユーザ企業所属の初学者による「AWS認定のすゝめ」

小林未来さん

  • テレワーク環境構築で Workspaces と Site to Site VPN 作成
  • AWS 認定勉強
    • ベストプラクティスを知るため
    • 自信を持ってPJ推進したかった
  • まとめ
    • きちんと利用するきっかけになる
    • ユースケース学習ができ新ビジネスの足掛かりに
    • ユーザー企業が自走するきっかけに

所感

「ユーザー企業だから資格不要かー」という考えは甘えだと思い知らされました...
ベストプラクティス知るにはいい勉強になるのは確かですね。
プロフェッショナルの3時間試験と落ちた時に金額的にも痛くてチャレンジできずにいます。

他にも思うところはあるけど、仕事が始まっちゃうのでまたの機会に。