AWSでCloudFormationを使う時にAWS SAMで代替できる部分は全部AWS SAMでやっていこう！と思った(追記：主にLambdaとIAM) - でこてっくろぐ ねお
以前 AWSで作業する時は今後はずっとCloudFormationだけ使っていこうと思った - でこてっくろぐ ねお というエントリを書きましたが、最近はAWS SAMを使って色々作っており、これはめっちゃ便利だな、しかも思ってたよりも柔軟性が高い、という気持ちになったのでこのエントリを書いている。 (と思ったけど、DynamoDBは細かい制御が効かなかったので、以下は主にLambda + IAMについて書いていると考えてください) めっちゃ便利 CloudFormationと比較してとにかく記述量が圧倒的に少ない、圧倒的に読みやすい CloudFormationと比較して、IAM Role周りの設定がある程度隠蔽されていて嬉しい。IAM Role周りはいつも何を付与すればいいかが難しいし、後から見ても難しい AWS SAM Localが使えて簡単に手元で動作確認ができる これは小さいもの
Mackerel AWS Integration 用の CloudFormation テンプレートを書いた
昨年の年末から Mackerel の本格導入を始めました。 それに当たって AWS Integration 用の CloudFormation テンプレートを書いたので、 他のプロジェクトでも導入が簡単になるよう公開しました。 shogo82148/cf_mackerel 使い方 GitHub Pages でテンプレートを公開しているので、 template-body にテンプレートのURLを指定して、 新しいスタックを作成するだけです。 aws cloudformation create-stack --stack-name "MackerelIntegrationIamUser" \ --template-body https://shogo82148.github.io/cf_mackerel/mackerel.yaml \ --capabilities CAPABILITY_NAM
GitHub と AWS CodeBuild を連携させるサーバーレスなツールを作りました [中身編]
GitHub と AWS CodeBuild を連携させるサーバーレスなツールを作りました [中身編] 紹介編の続きです. 本記事では github-codebuild-integration の構成や実装などについて掘り下げてみます. このあと何回も github-codebuild-integration と書くと疲れそうなので、以下 gci と書きます. また、本記事中でコードやファイルに対して張られているリンクはすべて記事公開時点で最新の v0.1.1 のものです. 目次 gci リポジトリの中身の話 デプロイまわりの話 Amazon API Gateway じゃなくて Amazon SNS を選んだ理由 AWS SAM と node_modules の関係がエグい AWS Step Functions ええやん CloudFormation Lambda-backed カスタム・
![GitHub と AWS CodeBuild を連携させるサーバーレスなツールを作りました [中身編]](https://cdn-ak-scissors.b.st-hatena.com/image/square/970d70f8f80982393b2c63a4079d1b42d79931b5/height=288;version=1;width=512/https%3A%2F%2Ftoris.io%2Fimages%2F2017%2F08%2Fstep-functions.png)
私的 CloudFormation ベストプラクティス - 試行錯誤のおと
最近 CloudFormation を触っていて、よくある初期構築のベストプラクティスについて意見がほしいので自分の考える CloudFormation の設計や使い方についての考えを書いた。 CloudFormation のメリット CloudFormation を利用するためメリットはリソースの参照を簡単に記述できることと、べき等性の保証だと思っている。 以前、 EC2 インスタンスのプロビジョニングを Ansible で書いたことがある。 べき等性を確保したく、 サブネットの作成、 EBS のマウント、アンマウント、 EIP の付け替えなどの変更操作を Ansible だけで操作したい + その後のプロビジョニングの操作も Ansible にお任せしたいということを考えたときに、 Ansible の YAML ではなく以下のような Python のコードを書いた。 # ansible
CloudFormationのスタックポリシーでUpdate:*をDenyしててもやはり消える時は消える、という話及び削除への対処 - でこてっくろぐ ねお
このエントリで伝えたいこと CloudFormationのスタックポリシーでUpdate:*をDenyしてても安心はできない。消える時は消える 上記はある程度皆知ってるかもしれませんが、一応試してみた、及び考えられる削除に対する保護の方法を考えるという感じのエントリ スタックポリシーについて CloudFormationにおいて、一度作成したリソースが変更されたり削除されたり置換されたりするのを防ぐ方法があります。 スタックポリシーですね。例えば、以下のようなJSONをhoge_policy.json というファイルに保存し aws cloudformation set-stack-policy --stack-name hoge-stack --stack-policy-body=file://./hoge_policy.json のようなコマンドで適用すると、CloudFormatio
AWSのIPリストを取得してCloudFormationで使えるセキュリティグループの定義を出力する(golang編) - でこてっくろぐ ねお
やりたいこと 全世界のAWSのEC2からだけ許可するsecurity groupを作りたいとかそんな感じのやつ それにどれくらいの嬉しさがあるかと言うと、まぁ人それぞれだよね 以下のテンプレート部分を少し変えると、AWS WAFの定義で全世界のAWSのEC2からのアクセスを拒否するとかそういうのにも使えるよね 方法 以下のスクリプト使うとSecurity Groupの定義が一個ペロッと出力されるので後は勝手に使うといいと思います。 最大の問題は、このIPレンジは当然そのうち変わるので、本来はJSONファイルの変更を検知してlambdaを動かして最新の情報に追随させるみたいなことをやる必要があるんですが、まぁ何か雑にやりたい時はこういうのでもいいんじゃないですかね。 ちゃんとやりたい場合は以下クラスメソッドさんのエントリ参照 dev.classmethod.jp プログラム GitHub -
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
