1 Minute Tips

カテゴリー: aws

AWSの情報をまとめる

  • Amazon ECS Exec チェッカーを使用してもログインできない場合の対処

    Amazon ECS Exec チェッカーを使用してもログインできない場合の対処

    はじめに

    Amazon ECS（Elastic Container Service）は、コンテナ化されたアプリケーションのデプロイ、管理、スケーリングを簡素化するためのサービスです。しかし、ECS Exec機能を利用してコンテナにアクセスする際に、想定通りに動作しない場合があります。本記事では、Amazon ECS Exec チェッカーを使用しても異常が見られなかったが、依然としてログインできない場合の対処法について解説します。

    調査したこと

    以下の手順に従って、Amazon ECS Exec チェッカーを使用してテストを行いました。実行結果は以下の通りです。

    https://github.com/aws-containers/amazon-ecs-exec-checker

    $ ./check-ecs-exec.sh $cluster $task

    -------------------------------------------------------------
    Prerequisites for check-ecs-exec.sh v0.7
    -------------------------------------------------------------
      jq      | OK (/usr/local/bin/jq)
      AWS CLI | OK ([xx]/aws)

    -------------------------------------------------------------
    Prerequisites for the AWS CLI to use ECS Exec
    -------------------------------------------------------------
      AWS CLI Version        | OK (aws-cli/1.22.7 Python/3.7.2 Darwin/23.4.0 botocore/1.23.7)
      Session Manager Plugin | OK (1.2.463.0)

    -------------------------------------------------------------
    Checks on ECS task and other resources
    -------------------------------------------------------------
    Region : [xxx]
    Cluster: [xxx]
    Task   : [xxx]
    -------------------------------------------------------------
      Cluster Configuration  | Audit Logging Not Configured
      Can I ExecuteCommand?  | [xxx]
         ecs:ExecuteCommand: allowed
         ssm:StartSession denied?: allowed
      Task Status            | RUNNING
      Launch Type            | Fargate
      Platform Version       | 1.4.0
      Exec Enabled for Task  | OK
      Container-Level Checks | 
        ----------
          Managed Agent Status
        ----------
             1. RUNNING for "postfix"
             2. RUNNING for "http"
             3. RUNNING for "composer"
             4. RUNNING for "log-router"
        ----------
          Init Process Enabled ([xxx]:241)
        ----------
             1. Enabled - "http"
             2. Enabled - "composer"
             3. Enabled - "postfix"
             4. Disabled - "log-router"
        ----------
          Read-Only Root Filesystem ([xxx]:241)
        ----------
             1. Disabled - "http"
             2. Disabled - "composer"
             3. Disabled - "postfix"
             4. Disabled - "log-router"
      Task Role Permissions  | [xxx]
         ssmmessages:CreateControlChannel: allowed
         ssmmessages:CreateDataChannel: allowed
         ssmmessages:OpenControlChannel: allowed
         ssmmessages:OpenDataChannel: allowed
      VPC Endpoints          | SKIPPED ([xxx] - No additional VPC endpoints required)
      Environment Variables  | ([xxx]:241)
           1. container "http"
           - AWS_ACCESS_KEY: not defined
           - AWS_ACCESS_KEY_ID: not defined
           - AWS_SECRET_ACCESS_KEY: not defined
           2. container "composer"
           - AWS_ACCESS_KEY: not defined
           - AWS_ACCESS_KEY_ID: not defined
           - AWS_SECRET_ACCESS_KEY: not defined
           3. container "postfix"
           - AWS_ACCESS_KEY: not defined
           - AWS_ACCESS_KEY_ID: not defined
           - AWS_SECRET_ACCESS_KEY: not defined
           4. container "log-router"
           - AWS_ACCESS_KEY: not defined
           - AWS_ACCESS_KEY_ID: not defined
           - AWS_SECRET_ACCESS_KEY: not defined

    上記の結果より、Amazon ECS Exec チェッカーを使用しても異常は見られませんでした。

    すべてのチェックが問題なくパスしていることが確認できました。

    結論と対処法

    Amazon ECS Exec チェッカーを使用しても異常が見られなかったにもかかわらず、依然としてECS Execを利用してコンテナにログインできない原因は、タスク定義における pidMode が task に設定されているためであると判断しました。

    pidMode の設定変更

    pidMode を task から container に変更することで、この問題を解決できます。以下の手順で設定を変更してください：

    1. タスク定義の確認と編集： AWSコンソールまたはAWS CLIを使用して、問題のタスク定義を確認します。タスク定義のJSON内でpidModeがtaskに設定されている箇所を見つけ、該当行を削除


    2. タスクの再デプロイ： タスク定義を更新後、新しいタスク定義を使用してタスクを再デプロイします。これにより、更新された設定が適用されます。
    3. ECS Execの再試行： 設定変更後、再度ECS Execを試行して、コンテナへのアクセスが可能か確認します。

    参考情報

    https://github.com/aws/containers-roadmap/issues/2268

    まとめ

    Amazon ECS Exec チェッカーを使用しても異常が見られない場合でも、タスク定義の設定によってはECS Execが正常に動作しないことがあります。特にpidModeの設定に注意が必要です。本記事が、ECS Execのトラブルシューティングに役立つことを願っています。

  • GitHub Actionsを使ったDockerイメージのビルドとAmazon ECRへのデプロイ

    GitHub Actionsを使ったDockerイメージのビルドとAmazon ECRへのデプロイ

    GitHub Actionsを使ったDockerイメージのビルドとAmazon ECRへのデプロイ

    今回は、GitHub Actionsを使ってDockerイメージをビルドし、Amazon Elastic Container Registry (ECR)にデプロイする方法について解説します。GitHub Actionsを活用することで、コードの変更に応じて自動的にDockerイメージをビルドし、ECRにプッシュすることができます。

    GitHub Actionsとは

    GitHub Actionsは、GitHubに組み込まれた継続的インテグレーション・継続的デプロイメント（CI/CD）のためのプラットフォームです。ワークフローを定義することで、コードのビルド、テスト、デプロイなどを自動化できます。GitHub Actionsでは、YAMLファイルを使ってワークフローを定義し、GitHubリポジトリ内の`.github/workflows`ディレクトリに配置します。

    Amazon ECRとは

    Amazon Elastic Container Registry (ECR)は、AWSが提供するフルマネージド型のDockerコンテナレジストリサービスです。ECRを使用すると、Dockerイメージを安全に保存、管理、デプロイすることができます。ECRは、AWSの他のサービスとの統合が容易で、スケーラビリティと可用性に優れています。

    ワークフローの解説

    それでは、GitHub Actionsを使ってDockerイメージをビルドし、Amazon ECRにプッシュするワークフローを解説していきます。

        - name: Login to Amazon ECR
      uses: aws-actions/amazon-ecr-login@v1
    - name: Build and push to Amazon ECR
      uses: docker/build-push-action@v3
        with:
        context: .
        push: true
        tags: ${{ env.ECR_REPOSITORY }}:${{ env.GITHUB_SHA }}
        cache-from: type=gha
        cache-to: type=gha,mode=max

    1. Amazon ECRへのログイン

    最初のステップでは、`aws-actions/amazon-ecr-login@v1`アクションを使用してAmazon ECRにログインします。このアクションは、AWSの認証情報を使用してECRレジストリにアクセスするために必要なログイン処理を行います。これは、以下の`aws`コマンドに相当します:

    aws ecr get-login-password --region <region> | docker login --username AWS --password-stdin <ecr-registry>

    2. DockerイメージのビルドとECRへのプッシュ

    次のステップでは、`docker/build-push-action@v3`アクションを使用して、Dockerイメージのビルドとプッシュを行います。このアクションは、以下の`docker`コマンドに相当します:

    docker build -t <ecr-registry>/<repository>:<tag> . docker push <ecr-registry>/<repository>:<tag>

    `with`セクションでアクションの設定を行います:

    • `context: .`: Dockerfileが存在するディレクトリを指定します。ここでは、現在のディレクトリ（`.`）を指定しています。
    • `push: true`: ビルドしたイメージをレジストリにプッシュすることを指定します。
    • `tags: ${{ env.ECR_REPOSITORY }}:${{ env.GITHUB_SHA }}`: イメージにタグを付けます。ここでは、環境変数`ECR_REPOSITORY`（ECRリポジトリのURL）とGitHubのコミットハッシュ（`GITHUB_SHA`）を組み合わせたタグを使用しています。
    • `cache-from: type=gha`: キャッシュからイメージレイヤーを読み込むことを指定します。`type=gha`は、GitHub Actionsのキャッシュを使用することを示します。
    • `cache-to: type=gha,mode=max`: ビルドしたイメージレイヤーをキャッシュに保存することを指定します。`mode=max`は、キャッシュを最大限に活用することを示します。

    キャッシュの活用

    GitHub Actionsでは、キャッシュ機能を利用してビルドの効率化を図ることができます。`cache-from`と`cache-to`オプションを使用することで、以前のビルドで作成されたイメージレイヤーをキャッシュから読み込み、ビルド時間を短縮できます。また、ビルドしたイメージレイヤーをキャッシュに保存することで、次回以降のビルドでそれらのレイヤーを再利用できます。

    キャッシュ機能は、`docker`コマンドや`aws`コマンドには直接対応する機能がありませんが、GitHub Actionsではこの機能を活用してビルドの効率化を図ることができます。

    まとめ

    GitHub Actionsを使ってDockerイメージをビルドし、Amazon ECRにデプロイする方法について解説しました。GitHub Actionsのワークフローでは、`aws-actions/amazon-ecr-login@v1`アクションを使用してECRにログインし、`docker/build-push-action@v3`アクションを使用してDockerイメージのビルドとプッシュを行います。また、キャッシュ機能を活用することで、ビルドの効率化を図ることができます。

    GitHub Actionsを活用することで、コードの変更に応じて自動的にDockerイメージをビルドし、ECRにデプロイすることができます。これにより、開発者はコードの開発に専念でき、CI/CDパイプラインの管理を簡素化できます。

    ぜひ、GitHub Actionsを使ってDockerイメージのビルドとデプロイを自動化してみてください。開発の効率化と品質向上に役立つはずです。

  • AWSコマンドでCloudFrontのキャッシュを消す

    AWSコマンドでCloudFrontのキャッシュを消す

    AWSコマンドでCloudFrontのキャッシュを消す方法

    AWSコマンドラインインターフェース（CLI）を使用してCloudFrontのキャッシュを無効化（Invalidation）する方法を説明します。

    手順

    以下のコマンドを実行します。

    aws cloudfront create-invalidation --distribution-id <distribution-id> --paths "<path1>" "<path2>" ...

    パラメータの説明

    • <distribution-id>: キャッシュを無効化したいCloudFrontディストリビューションのIDを指定します。
    • "<path1>" "<path2>" ...: キャッシュを無効化したいオブジェクトのパス（複数可）を指定します。パスはダブルクォーテーションで囲みます。

    例

    ディストリビューションIDがEDFDVBD6EXAMPLEで、/index.htmlと/images/logo.jpgのキャッシュを無効化したい場合は、以下のようになります。

    aws cloudfront create-invalidation --distribution-id EDFDVBD6EXAMPLE --paths "/index.html" "/images/logo.jpg"

    すべてのオブジェクトのキャッシュを無効化したい場合は、"/*"を指定します。

    aws cloudfront create-invalidation --distribution-id EDFDVBD6EXAMPLE --paths "/*"

    注意点

    • Invalidationリクエストには料金がかかります。
    • Invalidationが完了するまでには数分かかる場合があります。
    • 無効化されたオブジェクトは、次のリクエスト時に再びキャッシュされます。

    これにより、指定したパスのオブジェクトのキャッシュが無効化され、次のリクエスト時に新しいバージョンのオブジェクトがCloudFrontにキャッシュされます。

    以上で、AWSコマンドを使用してCloudFrontのキャッシュを消す方法の説明を終わります。ご不明な点があればお気軽にお問い合わせください。

  • Resource handler returned message: “The runtime parameter of nodejs14.x is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (nodejs20.x) while creating or updating functions.

    Resource handler returned message: “The runtime parameter of nodejs14.x is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (nodejs20.x) while creating or updating functions.

    AWS CDKでLambdaランタイムのアップグレードエラーを解決する

    AWS Cloud Development Kit (CDK)を使用してサーバーレスアプリケーションをデプロイする際に、Lambdaランタイムのバージョンアップによるエラーに遭遇することがあります。本記事では、そのようなエラーの原因と解決策について説明します。

    問題の概要

    CDKでLambda関数をデプロイしようとしたところ、以下のようなエラーが発生しました。

    Resource handler returned message: "The runtime parameter of nodejs14.x is no longer supported for creating or updating AWS Lambda functions. We recommend you use the new runtime (nodejs20.x) while creating or updating functions. (Service: Lambda, Status Code: 400, Request ID: 9xxx)" (RequestToken: e3c5cxxxx, HandlerErrorCode: InvalidRequest)

    このエラーは、AWS LambdaがNode.js 14.xランタイムのサポートを終了し、Node.js 20.xへの移行を推奨しているために発生しています。

    原因の特定

    エラーの原因を特定するために、プロジェクトの依存関係を確認したところ、package.jsonファイルに@aws-cdk/coreなどのCDK v1のパッケージが含まれていました。

    "dependencies": {
  "@aws-cdk/core": "^1.x.x",
  // ...
}

    CDK v1はNode.js 14.xをデフォルトのランタイムとして使用していたため、これが原因でLambda関数のランタイムがNode.js 14.xになっていたのです。

    解決策

    この問題を解決するには、以下の手順を実行します。

    1. package.jsonファイルから、CDK v1の古いモジュール（@aws-cdk/coreなど）を削除します。
    2. CDK v2の新しいモジュール（aws-cdk-lib）をpackage.jsonファイルの依存関係に追加します。
    "dependencies": {
  "aws-cdk-lib": "^2.x.x",
  // ...
}
    1. CDKのコード内で、@aws-cdk/coreなどの古いモジュールをインポートしている箇所を、aws-cdk-libからのインポートに変更します。
    2. npm installを実行して、更新された依存関係をインストールします。
    npm install
    1. CDKアプリケーションを再度合成し、CloudFormationテンプレートを生成します。
    cdk synth
    1. 生成されたCloudFormationテンプレートを確認し、Lambda関数のランタイムがNode.js 20.xに更新されていることを確認します。
    2. CDKアプリケーションをデプロイします。
    cdk deploy

    これで、Lambda関数のランタイムがNode.js 20.xに更新され、エラーが解消されるはずです。

    予防策

    今回の問題を予防するには、以下の点に注意が必要です。

    1. CDKのバージョンを最新のものに保つ
      • CDKは常に進化しており、新しいバージョンではモジュールの構造や名前が変更されることがあります。定期的にCDKのバージョンを更新することで、最新のベストプラクティスに沿ったアプリケーションを構築できます。
    2. 依存関係を定期的に確認する
      • プロジェクトの依存関係に古いモジュールが含まれていないか、定期的に確認することが重要です。古いモジュールを使用し続けると、セキュリティの問題や非互換性の問題が発生する可能性があります。
    3. AWS公式ドキュメントを参照する
      • AWSのサービスは常に進化しており、サポートされるランタイムやベストプラクティスも変化します。定期的にAWS公式ドキュメントを確認し、最新の情報を把握することが重要です。

    まとめ

    AWS CDKを使用する際に、古いCDKバージョンの依存関係が含まれていることが原因で、Lambdaランタイムのバージョンアップによるエラーに遭遇することがあります。このようなエラーは、古いモジュールを削除し、新しいモジュールを使用することで解決できます。また、CDKとAWSのサービスの進化に合わせて、定期的にアプリケーションの依存関係を見直すことが重要です。

    本記事が、同様の問題に直面した開発者の助けになれば幸いです。

  • AWS S3バケットを安全に空にする方法：実践ガイド

    AWS S3バケットを安全に空にする方法：実践ガイド

    記事の導入

    はじめに、AWS S3バケットの内容を削除する必要がある一般的なシナリオを紹介します。例えば、プロジェクトの終了、リソースの再配置、テストデータのクリーンアップなどです。読者がこの記事を読むべき理由を説明し、AWS CLIの基本的な使用方法について簡単に触れます。

    必要なツールと前提条件

    AWS CLIのインストールと設定方法を説明し、AWSアカウントの適切な権限設定についても触れます。これには、S3バケットへのアクセス権限が含まれます。

    スクリプトの解説

    次に、汎用的なスクリプトを紹介します。まずは、スクリプト全体を示し、その後で重要な部分を分解して説明します。

    スクリプト

    #!/bin/bash

# バケット名を引数から取得
BUCKET_NAME="$1"

if [ -z "$BUCKET_NAME" ]; then
  echo "バケット名が指定されていません。"
  exit 1
fi

# バケットの中身をリストアップ
aws s3api list-objects --bucket "$BUCKET_NAME" --query 'Contents[].Key' --output text | while read -r line; do
  aws s3api delete-object --bucket "$BUCKET_NAME" --key "$line"
done

echo "$BUCKET_NAME の中身を全て削除しました。"

    スクリプトのポイント

    • バケット名の動的指定：バケット名をスクリプトの引数から取得し、汎用性を高めています。
    • 安全性の向上：バケット名が指定されていない場合にはエラーメッセージを表示し、スクリプトを終了させます。
    • 効率的な処理：aws s3api list-objects コマンドを使用してオブジェクトのキーを取得し、それぞれに対して削除コマンドを実行します。

    終わりに

    スクリプトの使用方法と実際の使用例を紹介し、注意点やバケット削除のセキュリティ面での考慮事項を解説します。また、AWSの他のサービスとの連携や、このスクリプトを自動化ツールに組み込む方法についても触れると良いでしょう。

  • GitHubでフォークしたリポジトリをオリジナルと同期する

    GitHubでフォークしたリポジトリをオリジナルと同期する

    GitHubで他のプロジェクトをフォークすることは、そのプロジェクトに貢献したり、自分のプロジェクトでそのコードを利用したりする際の一般的なアプローチです。しかし、時間が経過すると、フォークしたリポジトリはオリジナルのリポジトリから遅れをとってしまうことがあります。この記事では、フォークしたリポジトリをオリジナルのリポジトリと同期する方法を詳しく解説します。

    ステップ1: オリジナルリポジトリを追加

    最初に行うべきことは、オリジナルリポジトリをあなたのローカルリポジトリのリモートとして追加することです。これにより、オリジナルリポジトリの変更をフェッチできるようになります。

    git remote add upstream git@github.com:aws-samples/aws-cdk-examples.git

    ステップ2: オリジナルリポジトリの変更をフェッチ

    次に、upstreamリモートから最新の変更をフェッチします。これは、オリジナルリポジトリの最新のコミットをローカルに取得する操作です。

    git fetch upstream

    ステップ3: ローカルのブランチにチェックアウト

    オリジナルリポジトリの変更をマージする前に、同期したいローカルのブランチにチェックアウトします。

    git checkout master

    ステップ4: オリジナルの変更をマージ

    upstreamからフェッチした変更をローカルのブランチ（この例ではmaster）にマージします。

    git merge upstream/master

    ステップ5: 変更をGitHubリポジトリにプッシュ

    最後に、ローカルの変更をGitHubリポジトリにプッシュします。これにより、オリジナルリポジトリの最新の変更があなたのフォークにも反映されます。

    git push origin master

    これらの手順を実行することで、フォークしたリポジトリはオリジナルリポジトリの最新の状態と同期されます。これにより、常に最新のコードで作業を続けることができます。

    このプロセスは、GitHub上でのオープンソースプロジェクトへの貢献や、最新の変更を自分のプロジェクトに取り込みたい場合に非常に役立ちます。是非、この手順を自分のワークフローに取り入れてみてください。

  • AWSアカウント作成とMFA設定: 安全なクラウド環境構築のステップバイステップガイド

    AWSアカウント作成とMFA設定: 安全なクラウド環境構築のステップバイステップガイド

    はじめに

    AWSアカウントの作成からMFA（多要素認証）の設定まで、初心者でも簡単にフォローできる手順をご紹介します。正しいセットアップを行うことで、AWS環境を安全に保ちながら、EC2、S3などのサービスをフル活用することができます。

    MFAの設定とアカウントの利用開始

    セキュリティを強化するため、MFAの設定は必須です。MFAを設定することで、パスワードだけでなく、物理的なデバイスからのコードが必要になり、アカウントの安全性が向上します。

    1. MFAの追加：
      • IAMダッシュボードから「セキュリティ認証情報」を選択し、「MFAデバイスの追加」をクリック。
      • MFAデバイスタイプを選択し（例：仮想MFA）、デバイスのQRコードをスキャンします。
      • アプリケーション（例：Google Authenticator）で生成されたコードを入力して、MFAを有効化します。
    2. MFAポリシーの適用
      • 以下のポリシーをアタッチさせます。

    MFAポリシーについての説明

    {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowViewAccountInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetAccountPasswordPolicy",
                "iam:ListVirtualMFADevices"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowIndividualUserToSeeAndManageOnlyTheirOwnAccountInformation",
            "Effect": "Allow",
            "Action": [
                "iam:ChangePassword",
                "iam:CreateLoginProfile",
                "iam:DeleteLoginProfile",
                "iam:GetLoginProfile",
                "iam:ListAccessKeys",
                "iam:UpdateLoginProfile",
                "iam:ListSigningCertificates",
                "iam:ListSSHPublicKeys",
                "iam:GetSSHPublicKey",
                "iam:GetUser"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "AllowManageOwnVirtualMFADevice",
            "Effect": "Allow",
            "Action": [
                "iam:CreateVirtualMFADevice",
                "iam:DeleteVirtualMFADevice"
            ],
            "Resource": "arn:aws:iam::*:mfa/${aws:username}"
        },
        {
            "Sid": "AllowManageOwnUserMFA",
            "Effect": "Allow",
            "Action": [
                "iam:DeactivateMFADevice",
                "iam:EnableMFADevice",
                "iam:ListMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "arn:aws:iam::*:user/${aws:username}"
        },
        {
            "Sid": "DenyAllExceptListedIfNoMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:CreateVirtualMFADevice",
                "iam:ChangePassword",
                "iam:EnableMFADevice",
                "iam:GetUser",
                "iam:ListMFADevices",
                "iam:ListVirtualMFADevices",
                "iam:ResyncMFADevice",
                "sts:GetSessionToken"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false",
                    "aws:ViaAWSService": "false"
                }
            }
        }
    ]
}

    上記ポリシーは、IAMユーザーが自分のアカウント情報を表示・管理し、MFAデバイスを管理できるようにする一方で、MFAが有効でない場合には指定されたアクションを除いてすべてのアクションを拒否するように設計されています。このポリシーはセキュリティを強化し、MFAが有効でないときにアカウントに対する潜在的な不正アクセスを防ぐためのものです。

    • AllowViewAccountInfo & AllowIndividualUserToSeeAndManageOnlyTheirOwnAccountInformation: ユーザーが自分のアカウント情報やパスワードポリシーを取得し、ログインプロファイルを管理できるようにします。
    • AllowManageOwnVirtualMFADevice & AllowManageOwnUserMFA: ユーザーが自分のMFAデバイスを作成、削除、同期させることを許可します。
    • DenyAllExceptListedIfNoMFA: MFAが有効でない場合に、リストされている特定のアクションを除いてすべてのアクションを拒否します。これにより、MFAが有効になっていない限り、ユーザーが操作を行うことが防止されます。

    その後ログアウトし、再度ログインします。この時MFAコードの入力が求められます。

    MFA認証をパスすると、AWSの各サービスにアクセスできるようになります。（もちろん必要な権限のポリシーやロールはAttachされている必要があります。）

    アクセスキーの設定とAWS CLIの使用

    AWS CLIを使用するには、適切なアクセスキーの設定が必要です。IAMでアクセスキーを作成し、CLIでの認証に使用します。

    アクセスキーの作成：

    • IAMダッシュボードで「ユーザー」を選択し、作成したIAMユーザーに対して「セキュリティ認証情報」タブを開き、「アクセスキーの作成」を選択します。
    • 新しいアクセスキーが生成されるので、表示された情報を安全な場所に保存します。

    AWS CLIの設定：

    • AWS CLIがまだインストールされていない場合は、AWS公式サイトからインストールを行います。
    • ターミナルまたはコマンドプロンプトを開き、aws configureコマンドを実行します。
    • プロンプトに従って、先ほど生成したアクセスキーIDとシークレットアクセスキーを入力します。リージョン名（例：ap-northeast-1）と出力形式（例：json）も設定します。

    GitHub上のaws-mfaツールは、AWSの多要素認証(MFA)を容易に管理するためのコマンドラインツールです。このツールを使用することで、AWS CLIを使用する際に一時的なセキュリティ認証情報を簡単に取得し、MFA保護されたリソースへのアクセスを安全に行うことができます。

    aws-mfaツールの設定と使用方法:

    1. ツールのインストール: aws-mfaはPythonで書かれているため、Pythonがシステムにインストールされている必要があります。GitHubのリポジトリページに従って、aws-mfaをインストールします。
    2. AWS Credentialsの設定: ~/.aws/credentialsファイルに長期的なAWSアクセスキーを設定します。これは、aws-mfaが一時的な認証情報を生成する際の基礎となります。
    3. MFAデバイスのARN設定: MFAデバイスのAmazon Resource Name (ARN)を特定し、この情報をaws-mfaの設定に含めます。
    4. 一時的なセキュリティ認証情報の取得: コマンドラインからaws-mfaを実行し、MFAトークンコードを入力することで、一時的な認証情報を取得します。これにより、MFA保護されたAWSリソースへのアクセスが可能になります。

    MFAを利用したAWS CLIのセキュアな使用

    AWS CLIを使用する際にMFA認証を要求する設定は、セキュリティをさらに強化します。

    1. 一時セキュリティ認証情報の取得：
      • MFAデバイスが設定されているIAMユーザーでAWS CLIコマンドを実行するには、一時セキュリティ認証情報が必要です。
      • 以下のコマンドを使用して、一時セキュリティ認証情報を取得します。

        aws sts get-session-token --serial-number arn:aws:iam::<your-account-id>:mfa/<your-mfa-device-name> --token-code <mfa-code> --duration-seconds 3600
      • このコマンドは、MFAデバイスから取得したトークンコードとともに、セッショントークン、アクセスキーID、シークレットアクセスキーを返します。
    2. 一時認証情報の使用：
      • 取得した一時認証情報を利用して、AWS CLIコマンドをセキュアに実行します。
      • 一時認証情報は、指定された期間（この例では3600秒）のみ有効です。

    結論

    AWSアカウントの作成からMFAの設定、さらにはアクセスキーの生成とAWS CLIの使用まで、このガイドを通じて、AWS環境を安全に利用するための基礎を学びました。セキュリティはクラウド環境での作業において非常に重要です。適切な設定を行うことで、リソースの安全性を保ちつつ、AWSのパワフルなサービスを最大限に活用することができます。始めるのが初めてであれば、この記事をステップバイステップでフォローし、セキュアなクラウド環境の構築に挑戦してください。

  • AWS X-Ray と X-Amzn-Trace-Id の深掘り

    AWS X-Ray と X-Amzn-Trace-Id の深掘り

    AWS X-Ray は、アプリケーションの動作を可視化し、ボトルネックや問題点を特定するためのサービスです。X-Ray のトレース機能をフル活用するためには、X-Amzn-Trace-Id ヘッダの正しいフォーマットと使用が不可欠です。この記事では、このヘッダのフォーマットと、それを正しく使用するためのヒントや注意点について解説します。

    1. X-Amzn-Trace-Id のフォーマット

    ヘッダは以下の構成要素からなります：

    • Root：トレースのユニークな識別子。例: 1-<8桁の16進数のエポックタイムスタンプ>-<24文字のランダム値>
    • Parent：呼び出し元のサービスのセグメントID（オプション）。
    • Sampled：トレースデータをX-Rayに送信するかどうかを示すフラグ。通常、0（送信しない）または1（送信する）のいずれかの値を持ちます。

    2. エポックタイムスタンプと16進数

    Root の部分には、エポックタイムスタンプの16進数表現が必要です。この値は、UNIX時間（1970年1月1日からの秒数）を16進数に変換したものです。これにはシェルスクリプトを使用して簡単に取得できます：

    hex_time=$(printf '%x' $(date +%s))

    3. X-Ray への正確なログ表示のための注意点

    • 時間の正確さ：X-Amzn-Trace-Id のタイムスタンプが正確でないと、X-Ray には表示されますが、期待した時刻の範囲で表示されない可能性があります。
    • 16進数の確認：Root の3文字目は16進数でなければなりません。これを確認しないと、X-Ray はトレース情報を正しく処理できません。
    • トレースIDの生成：独自のアプリケーションやバッチ処理からリクエストを送る場合は、適切な X-Amzn-Trace-Id ヘッダを自分で生成する必要があります。

    4. サンプルのシェルスクリプト

    以下は、curl コマンドを使用して適切な X-Amzn-Trace-Id ヘッダを付与したリクエストを送るためのサンプルスクリプトです：

    bash
    #!/bin/bash

    # エポックタイムスタンプの16進数取得
    hex_time=$(printf '%x' $(date +%s))
    trace_id="Root=1-$hex_time-a5d9f372e21340000000000001;Sampled=1"

    # curl コマンド実行
    curl --location 'https://your-api-endpoint.com/path' \
    --header 'Content-Type: application/json' \
    --header "X-Amzn-Trace-Id: $trace_id" \
    --data 'YOUR_PAYLOAD_HERE'

    5. まとめ

    AWS X-Ray をフルに活用するためには、正確な X-Amzn-Trace-Id ヘッダの生成と送信が不可欠です。特に、エポックタイムスタンプの正確さや16進数のフォーマットが重要です。この記事の情報を使用して、X-Ray でのトレースデータの可視化を効果的に行うことができるでしょう。

  • AWS SAM CLIでDockerがUnreachableな場合の解決

    AWS SAM CLIでDockerがUnreachableな場合の解決

    はじめに

    AWS Serverless Application Model (SAM) は、サーバレスアプリケーションを簡単に作成、テスト、デプロイするためのフレームワークです。しかし、時々 sam build --use-container コマンドを使用したときに、”Docker is unreachable. Docker needs to be running to build inside a container.”というエラーメッセージが表示されることがあります。

    Dockerが実行中であり、Dockerのバージョン情報が正しく表示されているにもかかわらず、このエラーが発生することがあります。このブログでは、その問題の解決法について説明します。

     

    問題の再現

    以下のようなコマンドを実行してみました。

    $ sam build --use-container

    そして、以下のエラーが表示されました。

    Error: Docker is unreachable. Docker needs to be running to build inside a container.

    しかし、Dockerは実行中であり、バージョン情報も正しく表示されます。

    $ docker ps
    CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

    $ docker --version
    Docker version 23.0.5, build bc4487a

    解決法

    解決法は、Dockerのコンテキストを確認し、適切に設定することです。

    まず、現在のDockerのコンテキストを表示します。

    $ docker context ls

    次に、適切なDockerのエンドポイントに対する環境変数 DOCKER_HOST を設定します。

    $ DOCKER_HOST=unix:///Users/sumito.tsukada/.docker/run/docker.sock sam build --use-container

    これにより、Dockerが適切に認識され、SAM buildコマンドが正常に実行されるはずです。

    結論

    DockerとAWS SAM CLIの連携は、サーバレスアプリケーションの開発をスムーズに進める上で非常に便利です。しかし、時々ツール間の接続に問題が生じることがあります。そのような場合は、環境変数を適切に設定し直すことで問題が解決することがあります。ぜひ、この記事があなたの問題解決の一助となることを願っています。

  • AWS CloudWatch Logsからユーザーエージェントデータを分析し、OSとブラウザのシェアを視覚化する

    AWS CloudWatch Logsからユーザーエージェントデータを分析し、OSとブラウザのシェアを視覚化する

    イントロダクション:

    AWS CloudWatch Logsは、AWSリソース、アプリケーション、サービスのログデータを監視して保存するためのサービスです。

    この記事では、CloudWatch Logsからユーザーエージェントデータを収集し、PythonとGoogle スプレッドシートを使用してOSとブラウザのシェアを視覚化する方法を解説します。

    これはウェブサイトやアプリケーションのユーザー体験を最適化するために非常に有益です。

    手順1: CloudWatch Logsからログを取得する

    まず、CloudWatch Logsからユーザーエージェントデータを含むログを取得する必要があります。

    AWS Management Consoleにログインし、CloudWatch Logsのページに移動します。

    1. ロググループを選択し、ログストリームを開きます。

    2. クエリを使用してログデータをフィルターします。以下は、ユーザーエージェント情報を含むログエントリを抽出するサンプルクエリです。

    fields @timestamp, @message
    | parse @message /(?<ip>[\d\.]+) - - \[(?<timestamp>[^\]]+)\] "(?<http_method>[^"]+)" (?<status_code>[^ ]+) (?<size>[^ ]+) "(?<referrer>[^"]*)" "(?<user_agent>[^"]+)"/
    | stats count(*) by user_agent

    1. 上記のクエリをCloudWatch Logs Insightsのクエリエディタに貼り付け、実行します。

    2. 結果をCSVファイルとしてエクスポートします。

    手順2: Pythonを使用してログデータを解析する

    ログデータが得られたら、Pythonを使用して分析します。

    この記事では、user_agentsというPythonライブラリを使用します。

    このライブラリは、ユーザーエージェント文字列を解析して、デバイス、OS、ブラウザに関する情報を抽出するのに役立ちます。

    user_agents ライブラリをインストールします。

    pip install pyyaml ua-parser user-agents

    次に、以下のPythonスクリプトを使用して、ユーザーエージェント文字列からデバイス、OSバージョン、ブラウザ、ブラウザバージョンを抽出し、CSVファイルに出力します。

    import csv
    from user_agents import parse
    # ログファイルの読み込み
    with open('logs.csv', 'r') as file:
    logs = csv.DictReader(file)
    # 結果を保存するためのリスト
    results = []
    # 各ログエントリを処理
    for log in logs:
    user_agent = log['user_agent']
    count = log['count']
    # user_agents ライブラリでユーザーエージェント文字列を解析
    ua = parse(user_agent)
    device_type = 'Mobile' if ua.is_mobile else 'Tablet' if ua.is_tablet else 'PC'
    os = f"{ua.os.family} {ua.os.version_string}"
    browser = f"{ua.browser.family}"
    browser_version = f"{ua.browser.version_string}"
    # 結果をリストに追加
    results.append([device_type, os, browser, browser_version, count])
    # 結果を新しいCSVファイルに出力
    with open('parsed_logs.csv', 'w', newline='') as file:
    writer = csv.writer(file)
    writer.writerow(['Device', 'OS Version', 'Browser', 'Browser Version', 'Count'])
    writer.writerows(results)

    手順3: Google スプレッドシートでデータを視覚化する

    最後に、Google スプレッドシートでデータを視覚化します。

    1. Google スプレッドシートを開き、手順2で生成された parsed_logs.csv をインポートします。

    2. ピボットテーブルを作成します。これには、データ範囲を選択し、「データ」メニューから「ピボットテーブル」を作成します。

    3. ピボットテーブルエディターで、「行」に分析したいカテゴリ（例：Device, OS Version, Browser）を追加し、「値」に「Count」を追加して合計を計算します。

    4. ピボットテーブルのデータを選択し、「挿入」メニューから「グラフ」を選択して円グラフを作成します。これで、OSやブラウザのシェアを視覚化することができます。

    結論:

    CloudWatch Logsからのログデータ分析は、アプリケーションのパフォーマンスとユーザー体験を向上させるのに役立つ重要なステップです。

    このチュートリアルでは、Pythonのuser_agents ライブラリを使用してユーザーエージェントデータを解析し、Google スプレッドシートで視覚化する方法を紹介しました。

    この情報は、デバイスやブラウザの最適化、または特定のOSバージョン向けの機能開発に役立てれば幸いです。