EC2インスタンスの起動/停止のAWS CLI
ちょっと起動したり、止めたりしたいとき用
EC2インスタンス一覧の情報の取得
aws ec2 describe-instances --output=table --query 'Reservations[].Instances[].{InstanceId: InstanceId, PrivateIp: join(`, `, NetworkInterfaces[].PrivateIpAddress), GlobalIP: join(`, `, NetworkInterfaces[].Association.PublicIp), Platform:Platform, State: State.Name, SecurityGroupId: join(`, `, SecurityGroups[].GroupId) ,Name: Tags[?Key==`Name`].Value|[0]}'
インスタンスの起動
aws ec2 start-instances --instance-ids <インスタンスID>
インスタンスの停止
aws ec2 stop-instances --instance-ids <インスタンスID>
いろんなデプロイ戦略整理
デプロイ方式 | ざっくり説明 | デプロイ失敗時の影響 | ロールバック方法 | デプロイ所要時間 |
---|---|---|---|---|
インプレースデプロイ | 現行環境から次期環境に一気にかえる | 全部使えなくなる | 再デプロイ | 少 |
ローリングデプロイ | 現行環境は動かしつつ、少しづつ次期環境に変えていく | 更新した部分だけ使えない | 再デプロイ | 中 |
カナリアデプロイ | 現行環境の一部を次期環境に変更して、一部ユーザにで変更状況をテストしてから、問題ないか確認する | 更新した部分だけ使えない | 再デプロイ | 中 |
ブルー・グリーン | 現行環境と次期環境を両方保持して、問題ないか確認してから次期バージョンに更新する | 更新した部分だけ使えない | URLをスワップさせる | 大 |
イミュータブルデプロイメント | 環境は使い捨て前提 | 全部使えなくなる | 再デプロイ | 大 |
レッド・ブラックという方法もあり、LB配下のリソースをいっきに変えるらしいが、インプレースとどう違うのかは確認中
CloudFormationのドリフト監視
CloudFormationのドリフト監視のConfigルール
ガバナンスの取れない組織でIaC使う際の永遠のテーマのひとつである「勝手に手動変更」の監視方法としてAWS Configでマネージドのルールが用意されているみたいです。
テンプレートからでもサクッとつくれるけど、CFnからサクッと作成構築用
AWSTemplateFormatVersion: "2010-09-09" Description: "" Resources: IAMRole: Type: "AWS::IAM::Role" Properties: Path: "/" RoleName: "CloudFormationDiff" AssumeRolePolicyDocument: "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Sid\":\"\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":[\"config.amazonaws.com\",\"cloudformation.amazonaws.com\"]},\"Action\":\"sts:AssumeRole\"}]}" MaxSessionDuration: 3600 ManagedPolicyArns: - "arn:aws:iam::aws:policy/service-role/AWSConfigRole" - "arn:aws:iam::aws:policy/AWSCloudFormationFullAccess" Description: "Allows CloudFormation to create and manage AWS stacks and resources on your behalf." ConfigConfigRule: Type: "AWS::Config::ConfigRule" Properties: ConfigRuleName: "cloudformation-stack-drift-detection-check" Description: "cloudformation stack drift detection check" Scope: ComplianceResourceTypes: - "AWS::CloudFormation::Stack" Source: Owner: "AWS" SourceIdentifier: "CLOUDFORMATION_STACK_DRIFT_DETECTION_CHECK" InputParameters: cloudformationRoleArn: !Sub arn:aws:iam::${AWS::AccountId}:role/${IAMRole} MaximumExecutionFrequency: "TwentyFour_Hours"
スタックに対してドリフト検出を定期的にかけるような感じなので、ドリフト検出対象外のリソースはもちろん通知されないみたい。 はやくすべて検出対象になって欲しい。
というより、手動変更を防ぐ対策の方が大切なんだよなぁ。
CloudFormationでよく使うAWS CLIコマンドまとめ
スタック作成関係
※注意※IAMのcapabilitiesはFULLでつけている
- スタックの作成(ローカルにテンプレートある場合)
aws cloudformation create-stack --stack-name <スタック名> \ --template-body <ローカルのパス file:///home/testuser/mytemplate.yaml> \ --capabilities "CAPABILITY_IAM" "CAPABILITY_NAMED_IAM" "CAPABILITY_AUTO_EXPAND" \ --parameters ParameterKey=<パラメータキー>,ParameterValue=<パラメータ値>
- スタックの作成(S3にテンプレートある場合)
aws cloudformation create-stack --stack-name <スタック名> \ --template-url <3SのURL> \ --capabilities "CAPABILITY_IAM" "CAPABILITY_NAMED_IAM" "CAPABILITY_AUTO_EXPAND" \ --parameters ParameterKey=<パラメータキー>,ParameterValue=<パラメータ値>
- スタック作成状況の確認(最新イベントを3だけ表示)
aws cloudformation describe-stack-events \ --stack-name <スタック名> \ --max-items 3
- 作成完了しているスタック名前一覧を取得
aws cloudformation list-stacks --stack-status-filter CREATE_COMPLETE \ --output table --query "StackSummaries[*].StackName"
変更セット関係
- スタックの変更セットの作成
aws cloudformation create-change-set --stack-name <スタック名> \ --change-set-name=<変更セット名> \ --template-url <S3のURL> \ --capabilities "CAPABILITY_IAM" "CAPABILITY_NAMED_IAM" "CAPABILITY_AUTO_EXPAND" \ --parameters ParameterKey=<パラメータキー>,ParameterValue=<パラメータ値> \ ParameterKey=<パラメータキー>,ParameterValue=<パラメータ値>
- 変更セットの中身確認
aws cloudformation describe-change-set --stack-name <スタック名> \ --change-set-name <変更セット名>
- スタックの変更セットの実行
aws cloudformation list-change-sets --stack-name <実行する変更セット名>
スタック削除関係
- スタックの削除
aws cloudformation delete-stack --stack-name <スタック名>
- 依存関係を考慮した複数スタック削除
aws cloudformation delete-stack --stack-name <削除スタックAの名前> aws cloudformation wait stack-delete-complete --stack-name <削除スタックAの名前> aws cloudformation delete-stack --stack-name <削除スタックAと依存関係のあるスタック名>
AWS DevOps Professional 下調べ
AWSDevOps対策下調べ
直近の活動はDevOps関係主体になりそうなので、これを機にAWSDevOpsプロを取得してしまおうということで下調べ。
10月までには取りたいっすなー
試験範囲
Domain | %of Examinatio |
---|---|
SDLC の自動化 | 22% |
構成管理およびInfrastructure as Code | 19% |
監視およびロギング | 15% |
ポリシーと標準の自動化 | 10% |
インシデントおよびイベントへの対応 | 18% |
高可用性、フォールトトレランス、およびディザスタリカバリ | 16% |
学習教材
日本語字幕あるみたいでgood
- AWS公式 模擬試験
受講前の最終確認用
- BlackBelt、ユーザガイド、よくある質問
試験範囲対象のサービスを中心に見たことないものあれば。
- ホワイトペーパー
鉄板
- Udemy
よく見る人。ハンズオンもあるんですね。
- サンプル問題日本語訳
サンプル問題は英語のみ。回答なしなので、有志の方の解説を頼りにやります。
- Wizlabz
Udemyみたいなサイト。暇があったらやってみるかも。優先度低め。
先人の知恵
2019年2月に更新されているみたいなのでそれ以降で参考になりそうな方たちのサイトまとめ
- 2019年3月18日 最終更新
- 2019年6月17日 最終更新
- 2020年1月18日 最終更新
- 2020年2月1日 最終更新
旧バージョンのS3のクロスリージョンレプリケーションが使いたいとき
旧バージョンのS3のクロスリージョンレプリケーションはレプリケーション元S3バケットからオブジェクトを削除すると、レプリケーション先のオブジェクトも消えてしまいます。
やり方(2020/5/22時点)
CloudFormationから設定しましょう。
CRRルールのバージョンダウングレードは不可なので既に設定してしまっている場合はCRRのルールを全部消して、CRRをCFnで再設定しましょう。 https://docs.aws.amazon.com/AmazonS3/latest/API/API_DeleteMarkerReplication.html
多分時期にCFnから作っても現行バージョンに変わるでしょう。おしまい。
SREとは何かについていい感じの"まとめ"の"まとめ"
流行りのSRE(Site Reliability Engineering)について色々と考えなければならない状況になっているのでどんなものかについて調べたときにいい感じだったサイトについてまとめてみた。
SRE NEXT 2020 サイト信頼性エンジニアリングの原則
googleのSREチームの人のLT。
SRE本家の中の人がざっくり紹介してくれているのでweb記事も色々落ちてるけど、これ聞いておけば良い気がする。
hbstudy #74 「SRE大全: 序章」
オライリーのSRE本の翻訳者の方のSRE勉強会の動画。
SRE本翻訳裏話とかあって楽しい。少し長いが、読む前に流してでもいいから聞いたほうがいいと思う。内容も小難しくなく、スピーカーの方も面白いので結構あっという間に終わる。
https://www.youtube.com/watch?v=P1CXOb6VtOw:hbstudy #74 「SRE大全: 序章」
ざざっとSRE本についての読書感想を知りたい場合
いい感じにまとめられている気がします。
SRE始めるにあたっての具体的なツールとか
現役SRE担当の方によるツール紹介
同じ方が書かれているcodezineでのSREについての紹介も分かりやすくて良いと思います。
SRE本
言わずもがなの有名本
SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
- 発売日: 2017/08/12
- メディア: 単行本(ソフトカバー)
英語なら無料でwebで読めちゃう