Blog

Intro EC2 で Stable diffusion を実現するためのメモです。 EC2 自体の構築やセキュリティグループ、VPC などの設定は割愛しています。 GPU インスタンスを使用 stable-diffusion-webui を使用 python 3.10.6 を使用 nginx でリバースプロキシ 環境 イメージ：amazon linux 2023 インスタンスタイプ：g4dn.xlarge GPU 環境構築 NVIDIA ドライバーと CUDA をインストール 参考 https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/install-nvidia-driver.html https://docs.nvidia.com/cuda/cuda-installation-guide-linux/#amazon-linux-2023 dnf install kernel-devel-$(uname -r) kernel-headers-$(uname -r) kernel-modules-extra-$(uname -r) dnf config-manager --add-repo https://developer.download.nvidia.com/compute/cuda/repos/amzn2023/x86_64/cuda-amzn2023.repo dnf module install nvidia-driver:latest-dkms dnf install cuda-toolkit dnf install nvidia-gds stable-diffusion-webui の構築 インストール git clone https://github.com/AUTOMATIC1111/stable-diffusion-webui cd stable-diffusion-webui ln -s . stable-diffusion-webui # 起動スクリプト修正(shareオプションは使わない) vim webui-user.sh export COMMANDLINE_ARGS="--xformers --enable-insecure-extension-access" python 環境構築 python 3.

はじめに フロントエンドのセキュリティは、ウェブアプリケーションを安全に保つために非常に重要です。この記事では、フロントエンドで一般的に見られるセキュリティの脅威と、それに対する対策について詳しく説明します。 オリジンによるアクセス制御 同一オリジンポリシー(SOP)は、あるオリジンから読み込まれた文書やスクリプトが、異なるオリジンのリソースとどのようにやり取りできるかを制限するセキュリティメカニズムです。このポリシーは、悪意あるウェブサイトがユーザーのデータにアクセスするのを防ぎます。 // このスクリプトが実行されるオリジン: http://example.com try { // 異なるオリジン（http://another-origin.com）のリソースにアクセスしようとする fetch("http://another-origin.com/data.json") .then((response) => response.json()) .then((data) => console.log(data)) .catch((error) => console.error("アクセスできませんでした。", error)); } catch (error) { console.error("エラーが発生しました。", error); } このコードは、http://example.comからhttp://another-origin.comにあるdata.jsonを取得しようとします。しかし、同一オリジンポリシーのため、このリクエストはブラウザによってブロックされます。 対策と回避策 同一オリジンポリシーによる制限を回避する方法として、CORS（Cross-Origin Resource Sharing）があります。CORS は、異なるオリジン間でのリソース共有を可能にするためのメカニズムです。サーバー側で適切な CORS ヘッダーを設定することで、異なるオリジンからのリクエストを安全に許可することができます。 サーバー側で以下のように CORS ヘッダーを設定します。 Access-Control-Allow-Origin: http://example.com この設定により、http://example.comからのリクエストは、http://another-origin.comによって許可されます。 同一オリジンポリシーは、Web セキュリティにおいて非常に重要な役割を果たします。しかし、現代の Web アプリケーションでは、異なるオリジン間でのリソース共有が必要な場面も多くあります。そのため、CORS のような技術を適切に利用することが重要。 XSS reflected stored DOM-based 対策 CSP エスケープ サニタイズ URL スキームを http/https に限定 適切な dom api を使った対策 dom purify XSS クロスサイトスクリプティング(XSS)は、攻撃者が悪意あるスクリプトをウェブページに注入し、他のユーザーのブラウザ上で実行させる脆弱性です。 対策 CSP: コンテンツセキュリティポリシー(CSP)は、どのようなリソースがウェブページに読み込まれるべきかをブラウザに指示する方法です。 エスケープ: ユーザー入力をエスケープ処理することで、スクリプトとして解釈されるのを防ぎます。 サニタイズ: ユーザー入力から危険な要素を取り除くことで、XSS 攻撃を防ぎます。 URL スキームを http/https に限定: リンク生成時にスキームを制限することで、悪意あるリンクの利用を防ぎます。 適切な DOM API を使った対策: innerText のような安全な DOM API を使って、XSS 攻撃を防ぎます。 DOM Purify: DOM Purify を使用して、安全でない HTML をクリーンアップし、XSS 攻撃を防ぎます。 CSRF クロスサイトリクエストフォージェリ(CSRF)は、ユーザーがログインしているウェブアプリケーションに対して、ユーザーの意図しない操作を強制する攻撃です。

はじめに ECS タスクに SessionManager で接続する方法を紹介します。 設定の有効化・確認方法 # 確認する aws ecs describe-services --cluster クラスター名 --services サービス名 | jq '.services[].enableExecuteCommand' # 有効化する aws ecs update-service --region ap-northeast-1 --cluster クラスター名 --service サービス名 --enable-execute-command 接続方法 aws ecs execute-command --cluster クラスター名 \ --task タスクID \ --container コンテナ名 \ --interactive \ --command "/bin/sh" 接続出来ないときの対処法 SSMplugin がインストールされていない SSMpluginをインストールしてください。 ECS のタスクロールに SessionManager の権限が追加されてない マネージドポリシーAmazonSSMManagedInstanceCoreを利用するケースが多いと思いますが、以下の action 許可だけで接続自体は可能です。 data "aws_iam_policy_document" "session_manager_policy" { statement { sid = "1" effect = "Allow" actions = [ "ssmmessages:CreateControlChannel", "ssmmessages:CreateDataChannel", "ssmmessages:OpenControlChannel", "ssmmessages:OpenDataChannel" ] resources = ["*"] } } それでも接続できない場合は、AWS 公式のツールを利用してデバッグしてみてください。

Intro クレデンシャルをビルド中に削除しても、レイヤに残ってしまう件について実際に手を動かして確認してみます。 docker の環境構築についてはこちら 環境構築 事前準備 適当なディレクトリを作成し、Dockerfile を作成します。 シークレットにすべき内容を含むファイルを作成し、削除します。 ubuntu@test-vm-01:~/test$ cat Dockerfile FROM public.ecr.aws/nginx/nginx:1.25-alpine-slim RUN echo "this is secret" > /secret.txt RUN rm /secret.txt build ubuntu@test-vm-01:~/test$ docker build -f Dockerfile -t test:latast . イメージを保存し、レイヤを確認します。 ubuntu@test-vm-01:~/test$ docker save test:latast | tar -xC dump/ ubuntu@test-vm-01:~/test$ grep "this is secret" dump/blobs/sha256/26e6cd8b82ed33846375b5484f907ec7547b1b58919e607d7954f6ed9f36f5ab ... {"created":"2024-03-21T16:21:04.288826451+09:00","created_by":"RUN /bin/sh -c echo \"this is secret\" \u003e /secret.txt # buildkit","comment":"buildkit.dockerfile.v0"},{"created":"2024-03-21T16:21:04.637976236+09:00","created_by":"RUN /bin/sh -c rm /secret.txt # buildkit","comment":"buildkit.dockerfile.v0"}],"os":"linux","rootfs":{"type":"layers","diff_ids": ... まとめ クレデンシャルをビルド中に削除しても、レイヤに残ってしまうので、公開するイメージには含めないようにすることが重要です。

Intro 以前は、vagrant+virtualbox で仮想マシンを作成してましたが、m2 mac に端末を変えたため、multipass に切り替えました。 multipass は、Ubuntu の仮想マシンを簡単に作成できるツールです。multipass を使用することで、仮想マシンの作成、起動、停止、削除などの操作を簡単に行うことができます。 install $ brew install multipass ==> Installing Cask multipass ==> Running installer for multipass with sudo; the password may be necessary. Password: installer: Package name is multipass installer: Installing at base path / installer: The install was successful. 🍺 multipass was successfully installed! $ multipass version multipass 1.13.1+mac multipassd 1.13.1+mac 基本コマンド 詳しくは以下参照 https://multipass.run/docs/multipass-cli-client # 新規作成 $ multipass launch -n test-vm-01 Launched: test-vm-01 # 確認 $ multipass list Name State IPv4 Image test-vm-01 Running 192.

Intro trivy は、コンテナイメージの脆弱性診断を行うツールです。trivy を使用することで、コンテナイメージに含まれる脆弱性を検出し、セキュリティを向上させることができます。 docker の環境構築についてはこちら 環境構築 作業の大枠 Dockerfile に対して trivy で診断を行います。 問題なければ、イメージをビルドし、trivy で再度スキャンを行います。 事前準備 適当なディレクトリを作成し、Dockerfile を作成します。 $ mkdir test $ vim test/Dockerfile FROM public.ecr.aws/nginx/nginx:1.25-alpine-slim EXPOSE 80/tcp 診断 DockerFile を trivy で診断します。config コマンドを実行します。 $ docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v $(pwd)/test:/workdir aquasec/trivy config --ignorefile .trivy/.trivyignore --severity HIGH,CRITICAL . 2024-03-20T13:16:35.209Z INFO Misconfiguration scanning is enabled 2024-03-20T13:16:35.210Z INFO Need to update the built-in policies 2024-03-20T13:16:35.211Z INFO Downloading the built-in policies... 46.13 KiB / 46.

ChatGPT+Mermaid でシーケンス図を作成する ChatGPT と Mermaid を使って、シーケンス図を作成してみました。 ChatGPT と Mermaid を組み合わせることで、シーケンス図を簡単に作成できます。ChatGPT は自然な文章生成に優れており、Mermaid はシンプルな記法でシーケンス図を描画できます。この組み合わせにより、手軽に要約や説明を行いながら、視覚的な図を生成できます。AI が生成したテキストを元に、Mermaid を使ってシーケンス図を作成することで、複雑なプロセスやアルゴリズムを視覚的に理解しやすくなります。 簡単なバッチの図を作成してみました プロンプトでの指示 「“a"が"b"に対して"x"を非同期で要求し、その後"b"の状態を確認し続けるというプロセスを Mermaid のシーケンス図で作成してください。状態が変更されていない場合は、“a"が状態確認を継続し、状態が変更された場合は、“b"が"a"にその旨を通知するシーケンスも図に含めてください。」 回答 あなたが求めているシーケンス図は、以下のような形になります。 mermaid sequenceDiagram participant a participant b a->>b: xを非同期で要求 loop 状態確認 a->>b: bの状態を確認 opt 変更なし a->>a: 状態の確認を継続 end b-->>a: 状態変更あり end このシーケンス図は、“a"が"b"に非同期で"x"を要求し、その後"b"の状態を確認し続けるプロセスを表現しています。“b"の状態が変更されない場合、“a"は状態の確認を続けます。一方、“b"の状態が変更された場合、“b"は"a"にその旨を通知します。

CloudFrontFunction / LambdaEdge について CloudFront Functions は、Amazon CloudFront のサービスであり、Lambda@Edge より手前で動作し、シンプルな処理を高速かつ安価に実行できるように設計された機能です。従来の Lambda@Edge は、CloudFront のエッジロケーションで動作するカスタムの AWS Lambda 関数を作成して、リクエストまたはレスポンスを処理することができます。一方、CloudFront Functions はよりシンプルで軽量であり、Lambda@Edge よりも低いレイテンシと高いパフォーマンスを持っています。 CloudFront Functions を使用すると、よりユーザーに近いエッジロケーションでリクエストを処理できるため、レスポンス時間が短縮され、ユーザーエクスペリエンスが向上します。また、コスト面でも Lambda@Edge よりも経済的であるため、シンプルな処理には CloudFront Functions が適しています。 さらに、CloudFront Functions と Lambda@Edge を組み合わせて使用することも可能です。例えば、シンプルな処理やヘッダーの操作、URL の書き換えなどのタスクを CloudFront Functions で処理し、より高度な処理を必要とする場合には Lambda@Edge で追加の処理を行うことができます。 これにより、より効率的で高速なコンテンツデリバリーサービスを提供することができるため、AWS のクラウドインフラストラクチャを活用したウェブアプリケーションやコンテンツの配信を行う際に便利です。 比較表 特徴 CloudFrontFunction Lambda@Edge ランタイムサポート JavaScript (ECMAScript 5.1 準拠) Node.js、Python 実行場所 218 以上の CloudFront エッジロケーション 13 の CloudFront リージョンのエッジキャッシュ サポートされる CloudFront トリガー ビューアリクエスト、ビューアレスポンス、オリジンリクエスト、オリジンレスポンス ビューアリクエスト、ビューアレスポンス、オリジンリクエスト、オリジンレスポンス 最大実行時間 1 ミリ秒未満 5 秒 (ビューアトリガー)、30 秒 (オリジントリガー) 最大メモリ 2 MB 128 MB (ビューアトリガー)、10 GB (オリジントリガー) 合計パッケージサイズ 10 KB 1 MB (ビューアトリガー)、50 MB (オリジントリガー) ネットワークアクセス なし あり ファイルシステムアクセス なし あり リクエスト本文へのアクセス なし あり 料金 無料利用枠あり。リクエストごとに課金。 無料利用枠なし。リクエストと関数の実行時間ごとに課金。 まとめ・考察 どちらにするかは処理時間か鍵になりそうです。

はじめに docker で terraform を実行するための docker-compose.yml を作成しました。 メリット 環境の統一 Docker は環境の統一を容易にします。異なるプラットフォームや OS で作業している場合でも、Docker コンテナ内で Terraform を実行することで、実行環境を一貫させることができます。 バージョン管理 Terraform のバージョン管理は重要です。異なるプロジェクトや環境で複数の Terraform バージョンを使用する場合、Docker コンテナ内で Terraform を実行することで、各プロジェクトや環境ごとに適切な Terraform バージョンを管理することができます。 windows ユーザーは tfenv が使えないので、docker で管理するのが良いかと思います。 やること 環境変数のセット export AWS_DEFAULT_REGION=ap-northeast-1 export AWS_ACCESS_KEY_ID=xxxxxx export AWS_SECRET_ACCESS_KEY=xxxxxx docker-compose.yml ファイルの作成 version: "3" services: terraform: image: hashicorp/terraform:1.5.2 platform: linux/x86_64 volumes: - ~/.aws:/root/.aws - ./:/workdir working_dir: "/workdir" environment: - AWS_ACCESS_KEY_ID - AWS_SECRET_ACCESS_KEY - AWS_DEFAULT_REGION entrypoint: sh -c 'terraform init && terraform workspace select "${WORKSPACE}" 2>/dev/null || terraform workspace new "${WORKSPACE}" && terraform "${COMMAND}"' terraform の実行 # コードフォーマッターの実行 export WORKSPACE="prod" COMMAND="fmt" && docker-compose -p プロジェクト名 run --rm terraform # コード構文チェックの実行 export WORKSPACE="prod" COMMAND="validate" && docker-compose -p プロジェクト名 run --rm terraform # 実行計画の確認 export WORKSPACE="prod" COMMAND="plan" && docker-compose -p プロジェクト名 run --rm terraform

はじめに BitBucketPipelines で image の push を行っていましたが、cpu がマルチプラットフォームに対応しておらず、x86_64 のみしか対応していないため、イメージの push を CodeBuild で行うことにしました。 arm64 で ECS タスクを実行するとコストが 20％落ち、使い方によってはパフォーマンスが向上するらしい。 今まで [BitBucketPipelines]　→ [awsECR] 変更後 [BitBucketPipelines]　→ [awsCodeBuild]　→ [awsECR] 結果 コストが 20%ぐらい落ちた。パフォーマンスはまだサービスインしてないため分からない やること CodeBuild の設定 構成 /image/以下の Dockerfile を build して ECR に push する /image/以下に buildspec.yml を配置 Bitbucket から CodeBuild を実行するための script 用意 bitbuket-pipelines.yml の修正 CodeBuild の設定 data "aws_region" "this" {} resource "aws_codebuild_project" "ecr" { badge_enabled = false build_timeout = 20 // 20分 concurrent_build_limit = 1 // 並列実行数 encryption_key = "arn:aws:kms:${data.

Intro EFS バーストモードのクレジット枯渇対策メモ EFS をバーストモードで使用していて、クレジットが不足してきたため、私が取った対策をメモとして提供します。 技術要素 EFS aws EFS の 2 つのモード EFS には 2 つのモードがあります: バーストモード（汎用）とプロビジョンドモード。 バーストモードは、使用されているストレージの量に基づいてトラフィックを自動的に調整し、一時的なトラフィックの増加に対応できます。バースト可能な帯域幅はトラフィックの使用状況によって異なり、最低 105 Mbps のバーストが可能です。ただし、1 秒あたりの読み取り/書き込みリクエストの数には制限があり、制限を超えるとスループットが低下する可能性があります。 プロビジョンドモードでは、ボリュームのスループット、最小/最大/バースト、および書き込みスループットを設定できます。読み取りスループットは書き込みスループットの 3 倍です。プロビジョンドモードはトラフィックに基づいた自動スケーリングはありませんが、スループットの設定に基づいて必要なトラフィックに対応できます。 バーストモード（汎用）の注意事項と対策 バーストモード（汎用）の注意事項と対策 注意事項 1: バーストクレジット バーストモードは、ファイルの読み取り/書き込み操作から蓄積されたクレジットを消費し、NAS 上のデータ使用状況に基づいてクレジットを補充します。バーストモードの最低速度は 105 Mbps です。ただし、バーストクレジットが枯渇すると、スループットの性能が著しく低下し、マウントシステムからのファイル参照がタイムアウトする場合があります。 確認方法: メトリック名: BurstCreditBalance 最初に 2.3T のクレジットが提供されます。 バーストクレジットの枯渇を避けるためには、以下の対策を取ることができます: クレジットの回復を加速するために大量のデータを配置する。 プロビジョンドモードに切り替えて一定のスループットを確保する。 注意事項 2: リクエスト制限 バーストモードにはリクエストの制限があります。 リード用の最大 IOPS は 35,000、ライト用の最大 IOPS は 7,000 です。 バーストモードの最大 IOPS を超えると、スループットのパフォーマンスが低下します。したがって、高い IOPS が必要な場合は、プロビジョンドモードの使用を検討してください。 確認方法: メトリック名: PercentIOLimit 検討に基づく対策の取得 バーストモードに大量のデータを配置してクレジットの回復速度を加速するという戦略を採用しました。 10GB のファイルを配置する試み。 コスト: $3/月 コマンド: $ dd if=/dev/zero of=10GB_file_1 bs=10240k count=1000 確認方法: メトリック名: BurstCreditBalance 高いコストのため、プロビジョンドモードは使用していません。 スループット 33(Mib/s) / 最大読み取りスループット 99(Mib/s) コスト: $238/月 スループット 15(Mib/s) / 最大読み取りスループット 45(Mib/s) コスト: $108/月 スループット 5(Mib/s) / 最大読み取りスループット 15(Mib/s) コスト: $36/月

Intro デフォルトでは、EC2 インスタンスが終了すると、アタッチされた EBS ボリュームも削除されます。しかし、AWS CLI を使用してこれらを永続化する方法を探ってみましょう。 技術要素 EC2/EBS コマンド タグによってフィルタリングされた対象インスタンスのボリューム情報を取得します。 DeleteOnTermination が true である場合、ボリュームは永続化されていないことを意味します。 $ aws ec2 describe-instances --filters "Name=tag:Name,Values=xxxxx-prod-web01" | jq -r .Reservations[0].Instances[0].BlockDeviceMappings [ { "DeviceName": "/dev/sda1", "Ebs": { "AttachTime": "2023-04-18T04:59:14+00:00", "DeleteOnTermination": true, "Status": "attached", "VolumeId": "vol-xxxxxxxxxxxx" } } ] 設定ファイルを準備します。 DeleteOnTermination を false に設定します。 $ vim mapping.json [ { "DeviceName": "/dev/sda1", "Ebs": { "DeleteOnTermination": false } } ] インスタンスの設定変更 $ aws ec2 modify-instance-attribute --instance-id "i-xxxxxxxxxxxxxx" --block-device-mappings file://mapping.json タグでフィルタリングされた対象インスタンスのボリューム情報を取得します。 DeleteOnTermination が false であることを確認します。 $ aws ec2 describe-instances --filters "Name=tag:Name,Values=xxxxx-prod-web01" | jq -r .

Intro 以前は、GitHub や Bitbucket から個人の AWS へのデプロイ時にアクセスキーとシークレットキーを使用していました。しかし、これを管理するのが煩雑になったため、OIDC に切り替えました。 OIDC (OpenID Connect) は、認証と認可のためのオープンスタンダードです。OIDC を使用することで、AWS へのアクセスを安全に管理し、認証プロバイダを介してシームレスなアクセス体験を提供できます。OIDC を使用する場合、AWS へのアクセスにはアクセストークンが使用されます。 OIDC を導入することで、アクセスキーやシークレットキーを個別に管理する必要がなくなり、セキュリティと利便性が向上します。 やること Terraform で OIDC を設定する方法 GitHub Bitbucket OIDC を使用してデプロイする方法 シンプルな GitHub Actions と Bitbucket Pipelines の作成 技術要素 OIDC AWS Bitbucket GitHub Terraform What is OIDC? OIDC（OpenID Connect）は、OAuth 2.0 プロトコルを拡張し、Web アプリケーションやモバイルアプリケーションにおけるユーザー認証の仕組みを提供する認証プロトコルです。 Benefits of OIDC Git からのデプロイに OIDC を使用することで、いくつかの利点があります。それには、Git を介したデプロイのセキュリティの向上、トークンの有効期限の管理の容易化、MFA が有効化されていないアクセスキーの使用に関連するセキュリティリスクの回避などがあります。ただし、MFA が有効化されたアクセスキーを使用する場合は、デバイス管理などの要素を考慮する必要があるため、複雑な場合があります。OIDC を使用することで、ユーザーは ID プロバイダーの認証資格情報を使用できるため、認証情報の管理が簡素化され、セキュリティが向上します。 構築背景 以前は、AWS へのデプロイは手間がかかるものでした。CLI の代わりに管理コンソールからデプロイすることを考えるほどです。 以前のフローでは、キーの取得に不便さが伴いました： アプリから MFA トークンを確認してコマンドを実行する： $ aws sts get-session-token –serial-number arn:aws:iam::xxxxxx:mfa/xxxxxx –token-code xxxxxx 取得したキーをエクスポートするか、Git に登録する セッションの有効期限が切れるたびに定期的にコマンドを実行する… Terraform で OIDC を構築する Terraform での構築 GitHub Actions を使用するシナリオと Bitbucket Pipelines を使用するシナリオの 2 つを説明します。 GitHub Sample variable "aws_account_id" {} variable "github_repo_name" {} variable "oidc_token_url" { default = "https://token.

Intro PC の入れ替えに伴い、Lambda のローカル実行環境を再構築した。メモとして残しておきます。 PC リプレースのついでに Lambda のローカル実行環境を再構築。メモとして残しておく。 技術要素 Volta Lambda LocalStack TypeScript SAM 前提条件 Installing Volta Volta のインストール Volta は Node.js のバージョン管理に特化したツールです。プロジェクトごとに異なる Node.js のバージョンを切り替えることができ、Node.js のバージョンを手動でインストール・管理することなく、異なるバージョンを簡単に管理することができます。Volta は、他のバージョン管理ツールと比較して切り替えが簡単という利点があり、OS やシェルに依存しないため様々な環境で利用することができます。 $ curl https://get.volta.sh | bash $ echo 'export VOLTA_HOME="$HOME/.volta"' >> .zshrc $ echo 'export PATH="$VOLTA_HOME/bin:$PATH"' >> .zshrc Node.js と Yarn のインストール 利用可能なバージョンを確認するには、volta list node を使用します。特定のバージョンをインストールしたい場合は、volta install node@18.15.0 というフォーマットを使ってください。 $ volta install node success: installed and set node@18.15.0 (with npm@9.5.0) as default $ volta install yarn success: installed and set yarn@4.

Intro Terraform の Wrapper ツール、Terragrunt 導入の検証を行いました。 導入の検証 通常、私は Terraform を使用していますが、次のような不便さがありました： 各デプロイの影響範囲を最小限に抑えるために、Git リポジトリをより小さなものに分割する必要がありました。Terraform のバージョンアップが面倒でした。 コードからリソースの依存関係を理解するのが難しかったです。 depends_on が明示的に使用できない場所でデプロイ順序に注意する必要がありました。 導入後の課題 導入に関して、以下の 2 点について検証が保留されています。もし詳しい方がいたら相談に乗っていただけると幸いです。 Terraform の管理だけでなく、Terragrunt のバージョン管理も行う必要があります。バージョンアップのプロセスはどのように変わるのか もし Terragrunt の開発が停止した場合、スムーズに Terraform のコードに戻せるか 技術要素 terraform terragrunt aws Terragrunt とは Terragrunt は、Terraform を使用してインフラストラクチャを管理するための作業を簡素化するための Terraform Wrapper として知られるオープンソースのツールです。Terragrunt は Terraform が提供する機能を拡張し、モジュールのコード再利用、柔軟な構成、再利用性の向上を可能にします。特に、Terraform を使用して複数の環境やアカウントを管理する際に Terragrunt は非常に便利です。 インストール $ brew install tfenv # Installs Terraform (version specified in .terraform-version) $ brew install tgenv # Installs Terragrunt (version specified in .terragrunt-version) ###　フォルダ構成

Intro AmazonLinux2 を使用して NAT インスタンスを設定しました。構成プロセスに Packer と Ansible を使用しました。 AmazonLinux2 を使用して NAT インスタンスを設定します。 Amazonlinux2 が選択する理由 Lambda は外部から開始される着信接続をサポートしていないため、アクティブモードで FTP をサポートしません。 ECS は、プライベート IP アドレスの静的割り当てを許可していません。 Gateway タイプであるため、NAT プライベートゲートウェイと組み合わせることで静的割り当てを実現することは可能ですが、外部ソースからの着信接続を受け入れることはできません。 技術要素 Packer Ansible iptables CENTOS7（AmazonLinux2）では、デフォルトのファイアウォール管理システムはファイアウォールです。ただし、IPTables を紹介して、NAT インスタンスをセットアップします。 ファイル構造 $ tree . . ├── ansible.cfg ├── bin │ └── init.sh ├── inventory │ └── hosts ├── packer-template │ └── nat_instance.json ├── playbook │ └── setup.yml └── roles └── iptable └── tasks ├── main.yml └── templates ├── iptables-config.

背景 NFS から s3 へデータを移行して WEB ホスティングするように基盤移行を行った際、404 のオブジェクトが多数発生していた。 また、s3 のオブジェクト名・プレフィックス名には禁則文字というものが存在するうらしい。 何が対象なのか判断するために、ブラウザのコンソールログを取得する必要があった。 動作環境 環境・ツール $ sw_vers ProductName: Mac OS X ProductVersion: 10.15.2 BuildVersion: 19C57 $ python3 -V Python 3.7.3z $ pip3 list | grep -e chrome -e selenium chromedriver-binary 83.0.4103.39.0 selenium 3.141.0 install 手順 $ sudo pip3 install selenium $ sudo pip3 install chromedriver-binary==83.0.4103.39.0 技術要素 selenium web driver python ec2 ファイル構成 ./log/ (ログ出力先ディレクトリ) ./config.ini (設定ファイル) ./grep.py (実行ファイル) ./url.txt (検索対象のURLリスト) 実行準備 クローリング対象の URL を記載する $ vi url.

tags tags Recent Posts EC2(GPU インスタンス) に stable-diffusion-auto1111 を立ち上げる 2024-09-02 ECS タスクに SessionManager で接続する方法 2024-03-27 Docker のイメージをビルドするとき注意すること 2024-03-21 Trivy を用いたコンテナ Image,DockerFile への脆弱性診断 2024-03-21 multipass で ローカル docker 環境の構築 2024-03-20 chatgpt+mermaid でシーケンス図を作成する 2024-02-21 CloudFrontFunction と LambdaEdge の違い 2023-07-21 Docker から Terraform を実行する 2023-07-10 Codebuild 構築と Deploy フローの整備 2023-06-27 EFS バーストモードクレジット枯渇対策メモ 2023-05-03 AWS CLI を使った EC2 への EBS ボリュームの永続化 2023-05-01 Terraform のラッパーツール、Terragrunt の導入検証を行ってみた 2023-04-27 Lambda ローカル開発環境構築メモ (SAM | LocalStack | TypeScript) 2023-04-24 OIDC (Git to AWS)のデプロイメモ 2023-04-26 Packer と Ansible を使って Amazon Linux 2 に NAT インスタンスを作成する 2023-04-11 ブラウザのコンソールログを Selenium(ヘッドレスブラウザ)で取得する 2020-08-26