[Terraform] 誤解されがちなignore_changesの動き・機密情報はstateに保持されるのか？ | DevelopersIO
[Terraform] 誤解されがちなignore_changesの動き・機密情報はstateに保持されるのか？ どうも、ちゃだいん（@chazuke4649）です。 「なんかいい感じに無視してくれるignore_changes、正しい動きを理解してる？雰囲気で理解してることない？」 詳しい人から教えてもらってめっちゃ驚いたのでブログに書きます。 先にまとめ ignore_changesはあくまでTerraformコードによるstateの変更を無視するだけ。state上の値が以後変更されないことを保証するものではない 現にその値がTerraform外で変更された場合、terraform applyによってstateの値は実体に合わせ更新されうる ignore_changesに指定した場合の各AWSリソースの動きの違い SSM Parameter Store は手動で変更したらstateは更
![[Terraform] 誤解されがちなignore_changesの動き・機密情報はstateに保持されるのか？ | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/8a77b081e14c8d61a2e80498092f8ffb9b60da03/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2019%2F05%2Fterraform-eyecatch.png)
Step FunctionsからECS RunTaskしようとしたら「ECS.AccessDeniedException」と出た時の対処法 | DevelopersIO
こんにちは。AWS事業本部コンサルティング部に所属している今泉（@bun76235104）です。 みなさん、Step Functionsを使っていますか？ Workflow Studioで視覚的にステートマシンを組み立てるのが非常に楽しくて私は大好きです！ 今回はAWSマネジメントコンソールからStep FunctionsでECE RunTaskのタスクを設定した時に以下のようなエラーが出た時の対処法を書かせていただきます！ User: arn:aws:sts::${アカウントID}:assumed-role/${ロール名}/hogehoge is not authorized to perform: iam:PassRole on resource: arn:aws:iam::${アカウントID}:role/${タスク実行ロール名} because no identity-based p
SESでバウンスメールを確認する方法をいくつか試してみた | DevelopersIO
こんにちは、コンサル部＠大阪オフィスのTodaです。 Amazon Simple Email Service(以降SES)は任意のアプリケーションからメール配信をする際、おすすめのサービスになります。 メール配信はエンドユーザ様から指定頂いた、メールアドレスに対しておこないますが、入力ミスによる受信失敗(バウンスメール)、迷惑メール報告(苦情メール)が発生する場合があり管理が必要になります。 今回は、簡易に運営者側でバウンスメールに気づける方法を試してみます。 バウンスメール対策の重要性 SESではサービスを利用して送信したメールの中でバウンスメールと苦情メールの計測をしており、一定以上になった場合、レビュー対象や配信の停止がおこなわれます。処理を維持をするためバウンスメールの対応が必要になります。 ■ バウンスに関するよくある質問 から引用 https://docs.aws.amazon
S3イベント通知→SNS→SQSをTerraformで作る | DevelopersIO
S3イベント通知機能で、S3へのファイルアップロードをSNS→SQSへ通知する処理をTerraformで作成する機会がありましたので、レポートします。 作成するリソースの概要 もちろんですが、S3、SNS、SQSを作成します。SNSについてはトピックとサブスクリプションが必要です。 各リソース間のアクセス許可が必要です。 S3イベント通知からSNSトピックへイベントを送信するには、SNSトピックのアクセスポリシーでS3がSNSメッセージを発行するのを許可する必要があります。 SNSからSQSへメッセージを渡すのにも、SQSキューのアクセス許可設定にてSNSからのメッセージ送信を許可する必要があります。 コード内容解説 S3 resource aws_s3_bucket main { bucket_prefix = "event-notification" acl = "private" f
VPC内での名前解決を有効にする Route53 のプライベートホストゾーンを使ってみた | DevelopersIO
コンサル部＠大阪オフィスのYui(@MayForBlue)です。 Route53のプライベートホストゾーンを使ったことがなかったので、今回初めて触ってみました。 そもそもプライベートホストゾーンとは プライベートホストゾーンは、Route53の機能のひとつで、VPC内のみで名前解決をしてくれるものです。（VPC内のサーバー間で名前解決したい場合など） 対して、VPC外で名前解決をするのはパブリックホストゾーンとなります。 プライベートホストゾーンの使用 やってみる テキストだけ読んでもよくわからないので早速やってみます。 今回はパブリックサブネットとプライベートサブネットにEC2を1台ずつ用意します。 Route53のプライベートホストゾーンでプライベートサブネットのIPアドレスを名前解決できるように設定し、パブリックサブネットのEC2からプライベートサブネットのEC2の名前解決ができるこ
Terraform構成をビジュアライズできるツール Pluralithを使ってAWS構成図を自動作成してみる | DevelopersIO
CIに組み込むことで真価を発揮するツールかと思うので、Localは検証・実運用はCIといった使い分けをするのが良さそうです。 やってみた 今回はLocalで試してみます。 Pluralith CLIのインストール 利用にはユーザー登録が必要です。 以下のページからユーザー登録します。 Pluralith サインインができたら以下のページに遷移します。 Localで試したいため、Local Setupを選択します。 Download CLIでバイナリをダウンロードして、macの場合は以下のコマンドでcliを利用できるようにします。 mv pluralith_cli_darwin_amd64_v0.2.2 pluralith mv pluralith /usr/local/bin/ chmod +x /usr/local/bin/pluralith ブラウザで表示されているAPI Keyを使っ
TerraformのAWS Provider Version 5がGAになりました | DevelopersIO
TerraformのAWS Providerのversion 5がGA（一般提供開始）になりました。アップデート内容を確認していきましょう。 リソースタグ・デフォルトタグが改良された リソースタグは、各リソースで定義するタグのことです。 デフォルトタグという機能は、デフォルトタグを設定したAWS Provider経由で作成したリソース全てに簡単に共通のタグを付けられる機能です。 Terraformなら簡単に全AWSリソースに共通タグを設定できます | DevelopersIO これらタグまわりが改良されました。 ゼロ値("")が使えるようになった これまで、ゼロ値(""、いわゆる空文字)をタグ値に使った場合、一部リソースではそのタグがそもそもセットされないことがありました。 また、一度ゼロ値じゃない値が入ったタグを作成した後、ゼロ値にコードを修正してapplyした際に、その変更が反映されな
stateファイル(tfstate)をS3からTerraform Cloudに移行してみる | DevelopersIO
「tfstateはTerraform Cloudで管理したいな。どうやって移行すればいいんだろう。」 AWSで Terraformを使っていると、stateファイル管理用のリソース(S3やDynamoDB)が増えてきて管理が大変になることがあると思います。 そんな時はTerraform Cloudでstateファイルを管理すると楽です。 Terraform Cloudで管理することで、stateファイル管理用のリソースを自分で作成する必要がなくなります。 ちなみに、stateファイルの管理自体はFreeプランでも可能です。 今回は、stateファイルの管理をS3からTerraform Cloudに移行してみます。 やってみた 移行前(stateファイルをS3管理) 検証用にstateファイルをS3管理するパターンでAWSリソースを作ってみました。 terraform { required_
Amazon Inspector v2 検出結果を AWS Chatbot で通知させてみる | DevelopersIO
このブログは 2021/12/20 時点の Amazon Inspector v2 および AWS Chatbot を試しています はじめに re:Invent 2021 にて Amazon Inspector v2 がリリースされました。 ECRスキャンが可能になったり、Organizations 連携が可能になったり、 とても便利になりました。 このブログでは Inspector v2 による 「EC2スキャンもしくは ECRスキャンの検出結果」 を AWS Chatbot 経由で Slack通知させてみます。 今回は 2種類の通知方法を試してみます。「Inspector からの通知(図1)」と「Security Hub からの通知(図2)」です。 Inspector v2 はデフォルトで Security Hub と統合可能です。 (図1) Inspector からの通知 (図2)
リソースベースポリシーの Principal に存在しないプリンシパルを指定すると Invalid principal in policy などのエラーが発生する | DevelopersIO
リソースベースポリシーの Principal に存在しないプリンシパルを指定すると Invalid principal in policy などのエラーが発生する Invalid principal（無効なプリンシパル）は、多くの場合「存在しない AWS アカウント」か「存在しない IAM ユーザー/IAM ロール」を指すかと思います。 Invalid principal in policy がでた コンバンハ、千葉（幸）です。 IAM ロールの信頼ポリシーを編集する際に、ダミーの値として存在しない AWS アカウント番号を入れたことがありました。 ↑信頼ポリシーの編集時には IAM Access Analyzer によるポリシー検証が自動で行われますが、そこでは特に指摘事項は検出されていません。 そのままポリシーの更新を実行するとエラーが出ます。 信頼ポリシーを更新できませんでした。 I
GitHub ActionsにAWSクレデンシャルを直接設定したくないのでIAMロールを利用したい | DevelopersIO
こんにちは！コンサル部のinomaso(@inomasosan)です。 前回と前々回でGitHub ActionsからECSのCI/CDやIAMポリシーの最小権限作成を試してみました。 [初心者向け] GitHub ActionsからECS FargateにCI/CDしてみた GitHub ActionsからECSとECRへのCI/CDを最小権限で実行したい 今回はGitHub ActionsでAWSの一時的なクレデンシャル(アクセスキーID、シークレットアクセスキー)を利用したいので、IAMユーザーの代わりにOIDCプロバイダとIAMロールを設定していきます。 IAMユーザーのクレデンシャルだとダメなの？ IAMユーザーで発行したクレデンシャルは永続的に利用可能です。 GitHubではAWSのクレデンシャルをSecretsにより秘匿化できますが、AWS外のサービスに永続的なクレデンシャル
ALBアクセスログ保存先のS3バケットポリシー設定時にでてくる3種類のService Principalをまとめてみた | DevelopersIO
「delivery.logs.amazonaws.com」と「logdelivery.elb.amazonaws.com」、そして「logdelivery.elasticloadbalancing.amazonaws.com」を整理します。 はじめに 清水です。ALBのアクセスログはS3に保存されます。この際に書き込み先のS3バケットではバケットポリシーにてアクセス制御がなされます。バケットポリシーの内容についてはApplication Load Balancerのユーザガイドに記載されていますが、過去から現在までに以下3つのService Principalを使ったS3バケットポリシーが記載されてきました。 delivery.logs.amazonaws.com logdelivery.elb.amazonaws.com logdelivery.elasticloadbalancing.
Amazon EventBridge SchedulerでECS Fargateのタスクを定期起動・定期停止してみた | DevelopersIO
「Event Bridge Schedulerを使えば、ECS FargateのサービスをLambda無しで定期起動・定期停止できる」 夜間など使わない時間は検証環境のECS Fargateを止めて料金節約したいことがあると思います。 ECS Fargate サービスの自動起動停止に関しては、Instance Schedulerも対応しておらず自前でLambdaを書くなどする必要がありました。 先日リリースされたEvent Bridge Schedulerを使えば、Lambdaを書かずに簡単に定期起動・定期停止を実現できます。 前提 定期停止と定期起動は以下を指しています。 定期停止: ECS Fargateサービスのタスク数(desiredCount)を0にする 定期起動: ECS Fargateサービスのタスク数(desiredCount)を元の数に戻す そのため、1つのサービスあたり
Web API サーバ負荷試験のすすめ方 – 観点を整理、負荷を試算、対象を選定 | DevelopersIO
負荷試験対策ミーティング ここでは、チームメンバーを集めて、システム要件の再確認と、バックエンドのアーキテクチャを再確認をまず行います。すなわち、「求められているもの=要件」と、「提供できるもの=アーキテクチャ」の確認です。ここの認識が揃っていないと、的はずれな負荷試験を実施してしまうことになりかねません。立場や役割にかかわらず、サービス全体として考えるべきです。 負荷試験の目的 負荷試験を行うことによって、何を示したいのか決めます。今回は、以下の目的を定めます。 サービスリリース後、想定されるピーク時のリクエストを受けた場合でも、問題なく稼働を続けられることを確認する システムのスループット限界値を確認する 負荷試験の観点 たいていのWebシステムの場合、昼夜を問わず稼働し続けるものとなるでしょう。今回例にとったシステムも24時間365日、リクエストを受け付けるものとします。この場合、観
Terraformで構築したECSをCodePipeline等でローリング更新するとタスク定義のリビジョンがずれる問題をdataを使って回避する | DevelopersIO
Terraformで構築したECSをCodePipeline等でローリング更新するとタスク定義のリビジョンがずれる問題をdataを使って回避する 「CodePipelineでECSをローリング更新した時に、Terraformと実際のリビジョンがずれてplanやapply時に差異が出る」 TerraformでECSを管理して、デプロイは他のツールを使っているパターンがあると思います。(例: CodePipeline,GithubActions,CircleCI等) TerraformでECSを作成して、コンテナのデプロイにはCodePipeline(ローリング更新)を使っていました。 CodePipelineとTerraformタスク定義のリビジョンがズレてしまって、Terrformを変更していないのに terraform plan の際に差分が出てしまうことがありました。 結論: data
GitHub Actionsを使ってGitHubリポジトリをCodeCommitリポジトリへミラーリングする | DevelopersIO
CodeCommitからCodePipelineを動かす必要があるけど、GitHubでコードを管理したいケースがあったのでやってみます。ミラーリング自体は多くの記事がでていたのですが、CodePipelineと連携したときの動きを確認したいこともあり試してみました。 前提 CodeCommitのリポジトリを作成済み GitHubのリポジトリを作成済み CodeCoommit用のIAMユーザーを作成済み やってみる CodeCommitのSSHキーをアップロードする GitHubからCodeCommitへミラーリングする際の認証情報としてSSHキー使用するためアップロードが必要です。 今回は以下のシェルでパッと作成してアップロードしました。ここで作成する鍵はパスフレーズなしで作成します。 シェルで指定したIAMユーザーの認証情報タブから、 AWS CodeCommit の SSH キー 欄を
TerraformでCodePipeline + CodeCommit作る際にトリガーでちょっとハマった話 | DevelopersIO
「TerraformでCodePipelineを作ったが、ファイルの変更してもCodepipelineがトリガー(発火)してくれない」 TerraformでCodeCommitをソースとしたCodePipelineを作っていました。 コンソールからパイプラインの作成はできて、手動トリガーでの実行もできたのですがCodeCommitのファイル変更時にCodePipelineが発火してくれないことがありました。 結論から書くと、CodePipeline用のEventBridgeの定義の作成が漏れていました。 (マネジメントコンソール上からCodePipelineを作ると自動的に作成されます。) 少しはまったので、サンプルコードを含めてブログにします。 事象・原因 以下のようにCodepipelineを作成していました。 しかし、Codecommitでファイルを変更してもパイプラインが動きません
Terraform ベストプラクティスを整理してみました。 | DevelopersIO
こんにちは。クラメソのスジェです。 ほとんどのサービスにはベストプラクティス（=best practices）というのがあります。 そのサービスを利用する際、このベストプラクティスを守るとより効率的に性能を100%活用することができます。 もちろんterraformにもこのようなベストプラクティスがあります。 今回はこのベストプラクティスについて整理してみました。 参考資料 本記事は下記の資料を参考にして作成しました。 本記事ではほとんどのプロジェクトに活用できる程度の項目を紹介しています。つまり、ベストプラクティスについて軽く説明している感じなので、詳細な内容までは上記の資料をご参照ください。 また、紹介した資料以外にもベストプラクティスを調べてみたら、たくさんの資料がありますので、そちらもあわせて確認することをお勧めします。 読む前に 実際にベストプラクティスをプロジェクトに適用しよう
エッジでJavaScriptを実行するCloudFront Functionsのユースケースまとめ | DevelopersIO
エッジで軽量なJavaScriptを実行するAmazon CloudFront Functionsのユースケースをまとめました AWSはエッジ環境で軽量なJavaScriptによる処理を実行可能な新サービス「Amazon CloudFront Functions」を発表しました。 Introducing CloudFront Functions – Run Your Code at the Edge with Low Latency at Any Scale | AWS News Blog エッジで爆速コード実行！CloudFront Functionsがリリースされました！ | DevelopersIO 以前から存在するLambda@Edgeは機能が豊富な一方で、処理が重く、利用費も高めだったのに対して、 CloudFront Functionsは機能を絞り込んでいる一方で、高速に動作し
CodeDeployを使用したECS-FargateのBlue/Green Deploymentをしてみた。 | DevelopersIO
はじめに Blue/Green Deploymentとは？ Blue/Green Deploymentでは、2つの環境を作成します。1つの環境(Blue)は現在のアプリケーションバージョンを実行し、もう1つの(Green)は新しいアプリケーションバージョンを実行します。Green環境でのテストが完了すると、アプリケーショントラフィックはGreen環境に転送されて、Blue環境は非推奨になります。 この記事では、CodeDeployを使用したFargateのblue/green deploymentをしてみました。 やってみた Application Load Balancer の作成 Target Groupsの作成 EC2 コンソールで、Load Balancingで Target Groupsを選択しておきます。 Create target group を選択して、以下の設定で2つのT
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
