2020-05-01

AWSスクールのカリキュラム見てみた

インフラエンジニアのポートフォリオってなんやろなぁ〜と思ってポチポチやってたら最近はプログラミングスクールの亜種みたいな感じでAWSスクールなんかもあるのですね。

raise-tech.net

AWSのスクールって何を教えてくれるんだろうと思って見てみました。以下がカリキュラムになります。

WEBアプリケーション開発

f:id:ktt1:20200501140943p:plain

まずは4週でrailsの基本を学んじゃおうという凄い勢いのあるカリキュラムです。

ちなみに1コマ/週なので、きっとRubyとかは一切触らず、いきなりRails！

AWS上での環境構築

f:id:ktt1:20200501141110p:plain

次の4週でAWS登場ですね。

CWの監視までやるみたい。

IaCの実践

f:id:ktt1:20200501141117p:plain

そして8週間かけてIaC使って構築するみたいですね。

ServerSpecとか使ってテストもしっかりやるみたいですね。

お値段

f:id:ktt1:20200501141234p:plain

お値段は35万円くらいなんですね。

120分×16回なので、AWS公式研修とか考えるとこんなもんだろうとか思ったり、この内容でこの値段は高いなぁ。とか思ったりするいい感じのお値段な気がします。

もし受講相談されたら、progateのrubyとrails全部やって、aws紫本やってみてからカリキュラムを再読して受講するかどうか決めることをおすすめします。

Amazon Web Services 基礎からのネットワーク&サーバー構築改訂3版

作者:大澤文孝,玉川憲,片山暁雄,今井雄太
発売日: 2020/02/06
メディア: 単行本

VCSにSVNとかあるし、カリキュラム内容的にもSIer的なお固い案件にも対応できるようなカリキュラム対応になってそうですね。

というかこの内容で仕事あるんですね。

ネットワークエンジニアのスクールもあるみたい。

こちらはネットワークエンジニアスクール

www.netvisionacademy.com

あえてネットワークエンジニアになろうという心意気シブすぎない？堅実派なのかしら。いいと思います。

2020-04-26

codeシリーズを使ってCloudFormationの静的解析を凄く小さく始める

AWS DevOps

CFnのCI/CDパターンはいろいろあったりするのだけど、いきなり見たって分からんことも多い。 codeシリーズは触ったことなかったので、ひとまず小さく使って理解するを進めようということでcodecommit、codebuild、codepipelineを使って小さく静的解析してみた。

codecommitの設定

1.codecommitのレポジトリ作成

適当に「cfn-lint-demo」とでもつけてレポジトリ作成。ここは一瞬で終わります。

2.IAMの権限確認

利用するIAMユーザに以下の権限相当のものがなければ付与する。

AWSCodeCommitPowerUser

ここも一瞬で終わります。

3.gitの認証情報の設定

colenするときに必要な認証情報の発行しておきます。

権限付与したIAMユーザの「認証情報」タブの下の方にある「AWS CodeCommit の HTTPS Git 認証情報」からgitの認証情報を作成して控えておきます。

4.codecommitのレポジトリを git clone

ローカルからCodeCommitのリモートレポジトリをcolne。

git init
git clone

実行すると、認証情報を確認されるので、先程取得した認証情報を入力。

ここまででcolne完了しているが、ブランチ作成されていないと、codebuildの設定が出来ないので「readme.md」でも適当に作成して、リモートレポジトリにpushしておく。

これでcodecommitの設定はおわり。

codebuildの設定

1.ビルドプロジェクトの作成

codebuildのビルドプロジェクトの作成を押下し、ちゃきちゃき進めていく。

注意が必要そうな点だけ記載。ほかはデフォルト設定で進んでOK。

○ソース

リポジトリは先程作成したものを設定
ブランチはMasterを指定。

○環境

オペレーティングシステムはどっちでもいいが、今回はAmazonLinux2を選択。
ランタイムはスタンダードでOK。（後で設定ファイル内で設定します）

ビルドプロジェクトの設定はこれで完了。

2.buildspec.yamlの準備

ローカルレポジトリで以下の内容を記載したファイル名「buildspec.yaml」を作成し、リモートレポジトリへpush

version: 0.2
phases:
  install:
    runtime-versions:
      python: 3.7
    commands:
      - pip install --upgrade pip
      - pip install cfn-lint --user
      - cfn-lint -v
  build:
    commands:
      - cfn-lint --template *.yaml

ファイルで実行している内容としては、ランタイムをpythonに指定して、cfn-lintをインストールして、レポジトリ内のyamlに対してcfn-lintを実行。

CodePipelineの設定

1.パイプラインの作成

パイプラインの作成。先程作成したcodecommit、codebuildを連携させる。

○ソース

ソースプロバイダーはAWS CodeCommitを選択し、レポジトリは先程つくったもの、ブランチはMaster

○構築する

プロバイダーを構築はcodebuildを選択し、プロジェクト名には先程の作成したものを選択

○デプロイ

今回はスキップ

動作確認

ローカルで以下を記載した「cfn.yaml」を作成し、リモートレポジトリ(codecommitのレポジトリ)へpushする。

※IAMのCFnリファレンスの記載例

AWSTemplateFormatVersion: "2010-09-09"
Resources:
  RootRole:
    Type: "AWS::IAM::Role"
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          -
            Effect: "Allow"
            Principal:
              Service:
                - "ec2.amazonaws.com"
            Action:
              - "sts:AssumeRole"
      Path: "/"
  RolePolicies:
    Type: "AWS::IAM::Policy"
    Properties:
      PolicyName: "root"
      PolicyDocument:
        Version: "2012-10-17"
        Statement:
          -
            Effect: "Allow"
            Action: "*"
            Resource: "*"
      Roles:
        -
          Ref: "RootRole"
  RootInstanceProfile:
    Type: "AWS::IAM::InstanceProfile"
    Properties:
      Path: "/"
      Roles:
        -
          Ref: "RootRole"

CodePipelineのダッシュボードから動作を確認できる。

codecommit側はpushが成功すれば、成功と表示され、 CodeBuild側はlintのチェックが問題なければ、成功と表示され、エラー吐いてれば失敗と表示される。

今回は成功するはずなので、失敗も見てみたかったら、適当に一行目とかを削除して再pushしてみたら失敗する。

まとめ

動かしてみていろいろわかってきた。

CFnのCICDの次のステップで参考になりそうなサイト

dev.classmethod.jp

aws.amazon.com

AWS Code Build / Pipelineで攻めのサービス改善 from Yuji Kubota

www.slideshare.net

2020-04-19

インフラCI/CD系の良さそうな本とかwebサイトとかまとめ

DevOps

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

作者:Kief Morris
発売日: 2017/03/18
メディア: 単行本（ソフトカバー）

天下のオライリー様からまさになタイトルで出ている本。この本は購入済でざっと全体を斜め読み段階だが、IaCとは何なのか、何を解決するのか、導入の障壁とかなどについてわかりやすくまとまっていてこれからも重宝する予感たっぷり。

インフラCI実践ガイド Ansible/GitLabを使ったインフラ改善サイクルの実現

作者:中島倫明,佐々木健太郎,北山晋吾,齊藤秀喜,羽深修
発売日: 2018/06/18
メディア: 単行本（ソフトカバー）

これも購入済でざっくり斜め読み中。

こっちはあくまでインフラCIに特化しますよという本。オライリーIaC本はこちらでも紹介されており、こちらの本ではインフラCIに焦点あててるよということが紹介されている。ちなみに、インフラCIは成果物として、本番導入できる形で構成定義ファイル作成するところまでを意味している。

あと、IaCよりこっちの方が図とかたくさんあって読みやすい。

まだ試してないけど、演習を通してできるのがいいですね。

DevOps導入指南 Infrastructure as Codeでチーム開発・サービス運用を効率化する

DevOps導入指南 Infrastructure as Codeでチーム開発・サービス運用を効率化する (DEV Engineer’s Books)

作者:河村聖悟,北野太郎,中山貴尋,日下部貴章,株式会社リクルートテクノロジーズ
発売日: 2016/10/14
メディア: 単行本（ソフトカバー）

未購入。目次を読んだ感じだと、入門本なので同じような内容。

ひとまず個人でIaCを導入してみよう！という内容はこの本だけかも？

サーバ／インフラエンジニア養成読本 DevOps編 [Infrastructure as Code を実践するノウハウが満載！]

サーバ/インフラエンジニア養成読本 DevOps編 [Infrastructure as Code を実践するノウハウが満載! ] (Software Design plus)

作者:吉羽龍太郎,新原雅司,前田章,馬場俊彰
発売日: 2016/02/26
メディア: 大型本

未購入。養成読本ってことなので基礎的な内容がしっかり記載さている？

最終的には「Dockerによる仮想環境構築とKubernetesによるDockerクラスタ管理」までやるみたいなので、結構ボリュームあるかも？

この系の本を隅から隅まで楽しく読めた試しはない。

CloudFormationの全てを味わいつくせ！「AWSの全てをコードで管理する方法〜その理想と現実〜」

dev.classmethod.jp

cloudformationとは何なのかからTaskCatとかつかってCI/CD体制整えようまで書いてある。

わかりやすいんだよな。CFn触り初めのときから何回も検索引っかかっているページ

GitHub/CodeBuild/CodePipelineを利用してCloudFormationのCI/CDパイプラインを構築する

dev.classmethod.jp

code系サービス使って具体的にCFnのci/cd用意してみたよといった内容

インフラCICDの勘所

インフラCICDの勘所 from Toru Makabe

www.slideshare.net

読んでないけど、タイトルは興味そそる。

2020-04-11

超訳・AWS Configベストプラクティス

AWS

aws.amazon.com

AWS Management & Governance BlogでAWS Configのベストプラクティスが紹介されている。

読んでみたので、勝手に分類分け＆超訳してみました。

ひとまず、設定しとけの巻

1.Enable AWS Config in all accounts and Regions.
2.Record configuration changes to ALL resource types.
3.Record global resources (such as IAM resources) only in one Region.

すべてのアカウント＆リージョンで有効化するべし。

すべてのリソースタイプの構成変更を記録するべし。

ただし、グローバルリソースに関しては重複しちゃうから、お気に入りのリージョンだけで記録するべし。

はじめてのconfigで調べるとよく言われていることが書かれているよ。

構成履歴と構成スナップショットの保管の巻

4.Ensure that you have a secure Amazon S3 bucket to collect the configuration history and snapshot files.
11.Turn on periodic snapshots with a minimum frequency of once per day.

記録する構成履歴と構成スナップショットファイル保管用のS3は安全に運用するべし。

1日1回以上の頻度で定期的なスナップショットをオンにするべし。

マルチアカウントの巻

5.Specify an Amazon S3 bucket from another (central IT) account for centralized management of history files and snapshots.
6.Specify an Amazon Simple Notification Service (Amazon SNS) topic from another (central IT) account for centralized management of configuration and compliance notifications.
19.Use the data aggregation feature to aggregate resource configuration and compliance data into a central account.
20.Create an organizations-based aggregator to aggregate AWS Config data from your entire organization.

マルチアカウントで運用するときは集約するべし的なことが色々書かれている。

通知はさせておけの巻

7.Use Amazon CloudWatch Events to filter AWS Config notifications and take action.

CloudWatchEvents使って通知対応しているから設定するべし。

コンプラはしっかり設定しようの巻

8.Set the appropriate permissions for the IAM role assigned to AWS Config
9.If you prefer to create an IAM role for AWS Config yourself, use the AWS managed policy AWSConfigRole and attach it to the IAM role.
10.Ensure that the SNS topic permissions are restricted to only allow AWS Config to publish messages to it.

IAMRoleは適切なアクセス許可か確認するべし。

IAMRoleつくるときはAWS管理のAWSConfigRoleを活用するべし。

SNSトピックがconifgだけに制限されているか(適切に設定されているか)確認しよう。

変更発生後の確認方法の巻

12.Use the AWS CloudTrail Lookup API action to find the API events that occurred in the timeframe when the configuration change occurred.

構成変更が発生した場合はCloudTrailのlookup-eventsを活用して確認するべし。

カスタムルール作成についてのあれこれの巻

13.Create change-triggered custom rules for resource types supported in AWS Config.
14.Create periodic rules for resource types not supported in AWS Config.
15.Use the AWS Config Rule Development Kit (RDK) for authoring custom rules.
16.Use the AWS Config Rules repository, a community-based source of custom AWS Config rules.
17.Use Annotations.

サポートされているリソースは変更トリガーによる実行＆定期実行のカスタムルールが作れるよ。

サポートされていないリソースは定期実行のカスタムルールが作れれよ。

カスタムルール作るときはAWS Config Rule Development Kit（RDK）を使うべし。

AWS Config Rules RepositoryがGithubに公開されているから活用するべし。

カスタムルール作ったら、評価の基準はちゃんと書くべし。

AWS Config Rule Development Kit（RDK）は触ったことないから触ってみたい。

Conformance Packsは便利だから使っとけの巻

18.Use Conformance Packs.

Conformance Packsとは構成の評価ルール(Config Rule)と修復アクション(Remediation Configuration の集合をコードで定義・デプロイできる機能らしい。

知らなかった！これは便利そうなので是非使ってみたい。

終わり。let's config !

2020-04-04

CloudFormationで作成した大阪ローカルのS3リソースの差分確認方法

AWS

AWSCloudFormationの現状スタックとの変更スタックの差分状況について調べることの出来る機能としてドリフト機能というものをCloudFormationでは提供しています。

ドリフト機能では、主要なリソースにはまぁまぁ対応していますが、まぁまぁ対応していなかったりしたりします。対応していたらすごく便利なのですが、その反面対応していないと「マジ使えねぇえ！！」って気持ちになります。

ドリフト対象リソース一覧 https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/using-cfn-stack-drift-resource-list.html

S3に関しては「AWS::S3::Bucket」のみ対応との記載がありますが、大阪ローカルs3にはドリフト機能が現時点では対応していません。

「だけどドリフト状況を調べたいぜ！」ってという状態になってしまった私のような稀有な人はaws cliを使ってチマチマ調べるかコンソールとにらめっこの必要があります。以下のaws cliコマンドたちでバケットの状態については調べられるのでご参考に。パブリックアクセスに関するgetだけbacketから始まらないフェイントとか掛けてくるので、見落としがちだったりしたのはいい思い出。

aws --region ap-northeast-3 s3api get-bucket-acl --bucket <backetname>
aws --region ap-northeast-3 s3api get-bucket-encryption --bucket <backetname>
aws --region ap-northeast-3 s3api get-bucket-lifecycle-configuration --bucket <backetname>
aws --region ap-northeast-3 s3api get-bucket-versioning --bucket <backetname>
aws --region ap-northeast-3 s3api get-bucket-tagging --bucket <backetname>
aws --region ap-northeast-3 s3api get-bucket-request-payment --bucket <backetname>
aws --region ap-northeast-3 s3api get-bucket-logging --bucket <backetname>
aws --region ap-northeast-3 s3api get-bucket-notification-configuration --bucket <backetname>
aws --region ap-northeast-3 s3api get-bucket-policy --bucket <backetname>
aws --region ap-northeast-3 s3api get-bucket-policy-status --bucket <backetname>
aws --region ap-northeast-3 s3api get-bucket-replication --bucket <backetname>
aws --region ap-northeast-3 s3api get-bucket-website --bucket <backetname>
aws --region ap-northeast-3 s3api get-bucket-cors --bucket <backetname>
aws --region ap-northeast-3 s3api get-public-access-block --bucket <backetname>

2020-03-28

AWS Inspector 実行結果のSNS通知

AWS

Inspectorからの実行結果についてSNSで通知して欲しいなぁ。と思っていたら、さすがAWS、デフォルトで用意されていました。

SNS通知に関しては以下のイベントでフィルタリング出来るみたい

実行開始
実行完了
実行ステータスが変更されました
報告された結果

実行結果が変わったときに通知が欲しいなーと思ったので、「実行ステータスが変更されました」で試しにやってみた。

実行結果

おや。。。設定時に7通もメールが飛んでくる。

{"template":"arn:aws:inspector:***region***:***AWS Account***:target/***/template/***","newstate":"CREATED","time":"2020-03-12T08:14:32.758Z","event":"ASSESSMENT_RUN_STATE_CHANGED","target":"arn:aws:inspector:***region***:***AWS Account***:target/***"}

{"template":"arn:aws:inspector:***region***:***AWS Account***:target/***/template/***","newstate":"START_DATA_COLLECTION_PENDING","time":"2020-03-12T08:14:32.911Z","event":"ASSESSMENT_RUN_STATE_CHANGED","target":"arn:aws:inspector:***region***:***AWS Account***:target/***"}

{"template":"arn:aws:inspector:***region***:***AWS Account***:target/***/template/***","newstate":"COLLECTING_DATA","time":"2020-03-12T08:14:33.319Z","event":"ASSESSMENT_RUN_STATE_CHANGED","target":"arn:aws:inspector:***region***:***AWS Account***:target/***"}

{"template":"arn:aws:inspector:***region***:***AWS Account***:target/***/template/***","newstate":"EVALUATING_RULES","time":"2020-03-12T09:15:34.773Z","event":"ASSESSMENT_RUN_STATE_CHANGED","target":"arn:aws:inspector:***region***:***AWS Account***:target/***"}

{"template":"arn:aws:inspector:***region***:***AWS Account***:target/***/template/***","newstate":"DATA_COLLECTED","time":"2020-03-12T09:15:33.964Z","event":"ASSESSMENT_RUN_STATE_CHANGED","target":"arn:aws:inspector:***region***:***AWS Account***:target/***"}

{"template":"arn:aws:inspector:***region***:***AWS Account***:target/***/template/***","newstate":"START_EVALUATING_RULES_PENDING","time":"2020-03-12T09:15:34.177Z","event":"ASSESSMENT_RUN_STATE_CHANGED","target":"arn:aws:inspector:***region***:***AWS Account***:target/***"}

{"template":"arn:aws:inspector:***region***:***AWS Account***:target/***/template/***","newstate":"COMPLETED","time":"2020-03-12T09:15:47.927Z","event":"ASSESSMENT_RUN_STATE_CHANGED","target":"arn:aws:inspector:***region***:***AWS Account***:target/***"}

newsstateからわかる通り「実行ステータスが変更」って調査時の実行ステータスという意味で実行結果内容の変更時の通知って意味ではないのね。

"newstate":"CREATED"
"newstate":"START_DATA_COLLECTION_PENDING"
"newstate":"COLLECTING_DATA"
"newstate":"EVALUATING_RULES"
"newstate":"DATA_COLLECTED"
"newstate":"START_EVALUATING_RULES_PENDING"
"newstate":"COMPLETED"

もっといい感じにフィルタリング出来ないかと思って、少し調べてみたら、重要度別に通知してくれるの調べてくれている人がいました。

https://qiita.com/tomoki_s/items/30550f7fb569f6fb4ce9

これで十分そうなので、今度試してみよう。

2020-03-21

CloudFormationテンプレートリバース作戦(未解決)

AWS

CloudFormationテンプレートで作成したスタックに対して手動でガチャガチャ動かしてしまってー、履歴とかも取ってなくてー、タグとかも整理されているんだかいないんだかでー。というガバナンスガバガバ状態だけど、心を入れ替えてヤル気はあるんで既存リソースを活用して初めからIaCやり直したいっす！！って場合にはどんな対応があるか調べてみた。

対策１：CloudFormationのimport機能

https://aws.amazon.com/jp/blogs/news/new-import-existing-resources-into-a-cloudformation-stack

ガバナンスが効いている状態であれば、インポート機能を活用してテンプレートファイルを一致させつつみたいな感じ出来るが、最早そんなレベルではない場合はどうするか。

対策２：Former2

既存AWSリソースからCFnテンプレートを作成するサービスとしてはCloudFormerとFormer2があります。

CloudFormer：AWSの(永遠のベータ版)サービス
Former2：サードパーティのSaaS(OSS) (https://former2.com/)

2019のre:inventではAWSもこちらの利用を勧めていたりします。

https://dev.classmethod.jp/articles/cloud-formation-dop408/

Former2の使い方

以下が分かりやすいのでご参考に。

https://dev.classmethod.jp/articles/former2/

ReadOnlyなアクセスキーとシークレットキーをぶち込む必要があります。

Former2でスタック復元できるのか？

結論としては、「厳しい」と思いました。厳しいポイントは以下。

厳しかったポイント１：リソース依存関係問題

依存関係のありそうなリソースを連続して選択してテンプレート化すると、ref!などで依存関係を見てくれるのですが、選択方法にコツが入ります。

依存関係先がテンプレート内に記載あれば、そこを指定するが、なければ既存リソースの物理IDを拾いにいく形になっています。

具体的には - ①vpc - ②subnet の順番でリソース選択すれば、subnet側で!refを使って①の論理IDを拾いにいって汎用的なテンプレートが構築されるが、

①subnet
②vpc の順番でリソース選択すると、①subnetは既存vpcの物理ID情報をテンプレートに埋め込むといった形になります。

汎用的なテンプレートへのリバースにはリソース選択順番が肝といったわけです。

厳しかったポイント２：復元リソースを探し切れない

Former2の検索窓でタグ情報などを使って、リソースを一括して選ぶことが出来るのですが、Routetabelのrouteなどタグ情報などが全くつけれないリソースとかもあってそういうのは別途選択する必要がありそう。

まとめ

Former2でスタック復元は厳しいですね。

参考程度にはできるかもだけど。。。

CFnドリフト検出できるリソースはドリフト検出で確認＋ドリフト出来ないリソースはaws cliで状況確認みたいな超絶泥臭い対応しかないのかな

あとは使ったことないけどawsspecとかって使えるのか？