投稿

ラベル(豆知識)が付いた投稿を表示しています

CDKのスタックにタグをつけるときは除外リソースの設定(excludeResourceTypes)に注意する

まえおき 久々のブログ投稿!最近はエンジニア関係ない業務が多く、ネタがあんまりない…。 久しぶりにCDKでリクエストがあって対応したけど、確認せず大丈夫だろうーと思ったら、大丈夫ではなかったので書いてみる。   やりたかったこと 全体のスタックにAというタグをつける タグの付け方はこちらの ドキュメント を参照 ただし、特定のAWSリソースについてはAタグではなくBタグをつけたい   やったこと 一番上のスタックについて、Bタグをつけるリソース以外にAタグを設定する Tags.of(MyStack).add('A', 'AA', exclude_resource_types=['AWS::Xxx::Zzz']) Bタグをつけるリソースに直接Bタグをつける Tags.of(MyResource).add('B','BB')   デプロイ結果 BタグのみをつけるリソースにAタグもBタグもついてしまう   理由と回避策  タグのPriority調整もしてみたが、結局解決できずサポートに問い合わせへ…。理由としては スタック にタグを付与するとデプロイ時にCloudformationがすべてのリソースにタグを付与してしまうらしい( exclude_resource_types が適用されない)。また、githubのレポジトリでも議論が行われていること( https://github.com/aws/aws-cdk/issues/16742 )。  スタック以下のレベルでタグを設定したり、逆に include_resource_types を設定する、Bタグをつけるリソースだけスタックを分離ことで回避できるらしい。前の2つはCDKで生成するリソースが多くあるので、別途分離もスタック構成のアーキテクチャを考慮しないといけないので、難しい…。  結局対応としては、これからCDK変更がほぼないこと、Bタグの適用は期間限定で必要なことから、コンソールから手でAタグを削除することになった。   まとめ  CDKでタグを扱うときはスタックレベルの動作に気を付ける必要があることがわかっ...

AWS CDKで生成されるCloudformationリソースの一部を削除したいとき

発生した課題  AWS CDKのL2 ConstructのSubnet( ドキュメント )を利用してSubnetを生成している。ConstructはCloudformationの AWS::EC2::Subnet , AWS::EC2::RouteTable , AWS::EC2::SubnetRouteTableAssociation を生成する。SubnetとRouteTableを生成し、その二つのアタッチまでやってくれる。 しかし、今の環境ではRouteTableを別途生成されたものを利用する必要があり、生成されたRouteTableを手で削除してテンプレートを修正しようとすると、RouteTableがないとエラーになり、修正ができなくなってしまった…。   解決策  すぐ思いつく方法としては、L1 ConstructのCfnSubnetで生成する方法である。ただ、今回はL2 Subnetのipv4CidrBlockを別のリソースで利用していて、広い範囲でコードを修正しないといけなかった。 (なんで、 AWS::EC2::Subnet はgetAttでipv4CidrBlockをゲットできないのか…ipv6はできるのに…?)  他の方法はないかと検索してみたら、githubのAWS CDKに同じ問題のissueがあり、そこで方法を探すことができた( https://github.com/aws/aws-cdk/issues/4308 )。 subnetA.node.tryRemoveChild('RouteTableAssociation') subnetA.node.tryRemoveChild('RouteTable')  上記のコードを追加し、再度デプロイを試したら、無事Subnetのみをデプロイすることができた。   コメント  AWS CDKのL2 Constructは、今回のRouteTableとAssociationやIAMの権限など普段使うことには便利ではある。しかし、実際の業務ではいろんな制約があるので、それをCDKに取り入れようとするとややこしくなる場合が多い。今回の場合も、無理やり削除している感があったり、最初にこのことに気づいたらL1 Constructを利用していただろう。L1 Co...

CloudFormationのスタック(Stack)を更新しても、更新されないリソース

まえおき  CloudFormationを使っているとスタック(Stack)の更新をすることがある。今までCloudFormation内をリソースを更新したときに、更新されなくて戸惑った3つの場合について書いてみる。   1. LambdaのコードをS3に保存した場合  当たり前かもしれないけど、その更新は最新のCloudFormationのテンプレートと旧テンプレートの差分より更新される。つまり、「 テンプレートに変更がないとスタック内のリソースに更新は発生しない 」ということだ。 AWS::Lambda::Function の Code 属性の記載方法には2つがある。テンプレート内に直接記載する方法とS3にファイルをアップロードし、そのバケット名とパスを記載する方法だ( 関連ドキュメント )。ここで更新時に問題になるのはS3にLambdaファイルを更新する場合だ。S3のファイルを更新しても、CloudFormationテンプレート内のコードは変わることなく、S3ファイルの変化の検知もしないので、Lambdaが更新されない。私は以下の2つの方法で更新した。   方法1 S3パスを更新する  シンプルな方法である。 AWS::Lambda::Function の Code 属性を変更すれば、テンプレートに変更点が発生するのでLambdaを更新するkとおができる。私は日付ごとにフォルダを作成、更新するLambdaをおきテンプレートを修正するようにしていた。しかし、当時はCI/CD環境ではなかったので、テストでLambdaに修正点があれば、都度S3にファイルをアップロードして日付を修正&デプロイまたはテンプレートをロールバック&デプロイする必要があった。ミスも多く発生していた。そこで、CI/CD環境を整えることと同時に方法2の方法を利用することにした。   方法2 SAMを利用する(おすすめ)  SAM(Serverless Application Package) を利用する方法だ。SAMテンプレートを書いて、コマンドを実行すると以下が実行される。 Lambdaファイルはランダム文字列のファイル名でS3にアップロードされる テンプレートをCloudFormationテンプレートに変換して、S3にアップロードし...

CloudFormationテンプレート内のStep functionsのState machine定義をS3に置けるようになった

イメージ
まえおき 今週あったチーム先輩(Aさん)との会話 私 :CloudFormationテンプレートにStepfunctionsを書こうとするとyamlにベタ書きしかできないんですよ。    これが私がCDKを押す理由の一つなんですよ。 Aさん:LambdaみたいにS3バケットに定義ファイルを置いてそのパスをyamlに書けばいいじゃん。 私 :あれ?私が調べたときはそれができなかったので、今あるテンプレートはすべてベタ書きにしているんですが…。 Aさん:うん?これでできないんだけ?(CloudFormationのドキュメントURLを共有) 私 :できるじゃん!?  送られてきた CloudFormationドキュメント を見ると、 DefinitionS3Location というプロパティがあった。おかしいな…調べたときは本当になかったんだようなーと思いずつ更新履歴を見ると、2020年5月20日更新。私が調べたのは1月ごろだったから、その時はなかったということだ。うーん、What's Newはほぼ毎日見るけど、使っているサービスのドキュメント更新履歴も頻繁にチェックしないといけないのかな…。とりあえず、試してみることにした。   DefinitionS3Locationを試してみる Step Functionsのテンプレートを準備  State Machineの定義はAWSドキュメントの Getting Started with Step Functions にあるコードから最後のstateを少し変えた簡単な以下のコードを利用する。 DefinitionSubstitutions も使ってみたかったので。 DefinitionSubstitutions はテンプレート内で同時に作成されるリソースをState Machine内で利用する場合に使う。例えば、Lambdaを作成して、それをState machineに入れるとか。(LambdaのARNが必要になる)    jsonファイルで保存し、S3のバケットに保存する。  これでStep Functions側の準備は終わり。   CloudFormationテンプレートを準備   CloudFormationの StepFunctions::StateMachi...

CloudWatch EventsはAmazon EventBridgeになるらしい

イメージ
まえおき  最近久々にCloudWatch Events(以下、Events)の画面を開いたら、以下のようなメッセージが出ていた。 グーグル翻訳先生に翻訳をお願いすると CloudWatch Events is now Amazon EventBridge Amazon EventBridge (formerly CloudWatch Events) provides all functionality from CloudWatch Events and also launched new features such as Custom event buses, 3rd party event sources and Schema registry to better support our customers in the space of event-driven architecture and applications. CloudWatch EventsがAmazon EventBridgeになりました Amazon EventBridge(以前のCloudWatch Events)は、CloudWatch Eventsのすべての機能を提供し、カスタムイベントバス、サードパーティイベントソース、スキーマレジストリなどの新機能も起動して、イベント駆動型のアーキテクチャとアプリケーションの領域でお客様をより適切にサポートします。 らしい。Amazon EventBridge(以下、EventBridge)がEventsの代わりになるということだった。いつから出たんだろう…。最近、画面のUIが変わりましたのメッセージが常にほぼどのサービスでも同じ感じで出ていたから全然気つかなかった…。今までは、EventBridgeというEventsと似ているサービスがあるということは知っていたけど、Eventsの機能で十分だったので特に気にしてなかった。調べてみると、ちょうど1年前に発表されたサービスだった。( Amazon EventBridge – SaaS アプリケーション用のイベント駆動型での AWS の統合 )   Cloudwatch EventsとAmazon EventBridgeの違い  全く同じサービスであるというと若...

Raspberry piで apt upgradeがconnection time outになるとき

まえおき このポストはQiitaに書いた Raspberry piで apt upgradeがconnection time outになるとき を移したものです。   背景 また、新しくRaspberry piフォーマットし、インストールしたので、いつもの儀式で sudo apt update と sudo apt upgrade を行いましたが、うまくいきませんでした。 大体以下のようなエラーでした。 Err:319 http://ftp.tsukuba.wide.ad.jp/Linux/raspbian/raspbian buster/main armhf sc3-plugins-server armhf 3.9.1~repack-3 Unable to connect to ftp.tsukuba.wide.ad.jp:http: 39% [Working] Fetched 204 MB in 3min 9s (1,078 kB/s) E: Failed to fetch http://ftp.tsukuba.wide.ad.jp/Linux/raspbian/raspbian/pool/main/c/cron/cron_3.0pl1-134_armhf.deb Could not connect to ftp.tsukuba.wide.ad.jp:80 (203.178.132.80), connection timed out E: Failed to fetch http://ftp.tsukuba.wide.ad.jp/Linux/raspbian/raspbian/pool/main/e/expat/libexpat1-dev_2.2.6-2_armhf.deb Unable to connect to ftp.tsukuba.wide.ad.jp:http:   解決 以下のファイルを開き、mirrorサイトを変更して解決しました sudo nano /etc/apt/sources.list 書いてあるURLをコメント処理して、新しいミラーサイトを入力します https://www.raspbian.org/RaspbianMirrors/ にミラーサ...

PythonのDict型をDynamoDB形式のJsonに変換する

pythonでDynamoDB関連操作をするとき、難しい点の一つは一つは以下のようなDynamoDBの独特なJSON形式だと思います。 { "id": { "N": 12345 }, "name": { "S": "TanakaTaro" } } Python用のAWS SDKであるBoto3にはDynamoDB形式のJsonをPythonのDictに変換できる TypeSerializer と TypeDeserializer があります。 https://boto3.amazonaws.com/v1/documentation/api/latest/_modules/boto3/dynamodb/types.html TypeSerializer PythonのDictをDynamoDB形式のJsonに変換します。個人的には変換結果で最初の{"M": ...}はなくしてほしいですが… TypeDeserializer DynamoDB形式のJsonをPythonのDictに変換します。こちらも一気に変換はできず、各Keyごとに変換が必要です。 まとめ&蛇足 TypeSerializerとTypeDeserializerはDynamoDBのデータをpythonで処理したいときや処理後にまたDynamoDBにアップロードしたいときに有効に利用できそうです。 ただ、そのまま利用するよりは、利用しやすくカスタム関数やクラスを作成したほうがよさそうです。 JavaScriptのSDKにもConverterというものがあるようです https://aws.amazon.com/jp/blogs/developer/announcing-the-amazon-dynamodb-document-client-in-the-aws-sdk-for-javascript/

StepFunctionのTimeoutSecondsについて

イメージ
StepFunctionsの state machineのテンプレートにはTimeoutSecondsという設定を設定できます。 https://docs.aws.amazon.com/ja_jp/step-functions/latest/dg/sfn-stuck-execution.html ここでは、StatesのTaskでTimeoutSecondsを指定していますが、States外でもTimeoutSecondsを指定できることがわかりました。ただ、自分が想定した動作とちょっと違ったです。   最初に想定していた動作 Statesの外でTimeoutSecondsを指定している場合は、各TaskのDefaultのTimeoutSeconds設定で動作する なので、TaskにTimeoutSecondsが書かれてなくでも指定された時間にタイムアウトが起きる 両方書かれている場合は、Task内の時間が優先される   実際の動作 動作確認コート 以下のようなStepFuncionsのState machine定義があるとします。 { "Comment": "A Hello World example of the Amazon States Language using Pass states", "StartAt": "Invoke_Lambda1", "TimeoutSeconds": 100, "States": { "Invoke_Lambda1": { "Type": "Task", "Resource": "arn:aws:states:::lambda:invoke", "Parameters": { "FunctionName": "arn:aws:lambda:us-east-1:XXXXXXXXXXXX:function:myTestFunction:$LATEST",...