2021年7-10月の振り返りと11月の目標
2021年7-10月の振り返り
転職してから、非常に忙しかった・・・そのため、全くブログ更新ができなかった(言い訳です)。会社がブラックなわけでなく、逆にホワイトです。求められるテックスキルが高すぎる、毎日Inputすべき情報が多すぎるでアップアップの毎日でした。そんな中、仕事にも慣れてきたので、ブログを再開しました。今回は、最近読んだ本の感想を書きます。
1）喋りのスキルアップ
現職では人前で話すスキルについて、高いレベルが要求されます。プリセールス的な活動を行うので、「お客様に信頼されるようなトーク、説明」が必要となります。この3ヶ月、ロールプレイを何度も行い、動画で見直しをしました。自分のスキルの無さに驚きました。「説明するスキルUP目的」で下記2つの本を読みました。「WHY > How > What」や「ロジカルと感情の両面」などなどキーワードにまとめてありわかりやすかったです。とても読みやすく、すっと頭に入ってくる内容でした。今後も定期的に読み直したいと思います。（家庭で子供向けに練習中）
2)テック関連 AWS IAM関連
評判のよい本ということで購入。現場での使い方が想定されており、とても参考になります。IAMは知っているけど、再学習・整理したい場合には最適だなと。
3)テック関連 AWSのセキュリティ
AWSのセキュリティを整理するために購入。今年中には資格試験も受けてみようかなと。数あるAWSのセキュリティ関連サービスをさくっとまとめて読みたい場合には最適。実務に生かすには、これをベースにBlackBeltやドキュメントを深掘りする必要があります。まとめてあるのは、本当にありがたい。
4)テック関連 Web開発関連
今のロールは、顧客システムをクラウドへのマイグレーションを提案すること。システムの大半はWebシステムです。私がWebシステムの開発経験がないため、マイグレーションする際の注意事項が全くわからない。なので、自宅で簡単なWeb開発をできないかと思い探した本。インフラ屋がWebシステムを把握するにはちょうど良いかなと。
5)11月の目標
・技術ブログ 3本
・読書 2冊
Systems Manager Session Manager を利用してLinux系EC2へアクセスする！
過去にWindowsRDP編を記事にしたので、今回はLinux編。
プライベートサブネット上にLinuxOSのEC2を立てることになったので、上記Windowsと同じように「踏み台サーバ」無しで、リモートでメンテナンスできる環境を構築。その作業のメモ。
（やること）
・エンドポイントの作成
・com.amazonaws.ap-northeast-1.ssm
・com.amazonaws.ap-northeast-1.ec2messages
・com.amazonaws.ap-northeast-1.ssmmessages
各エンドポイントには、SGでインバウンド、HTTPSを許可。
・IAMポリシーをEC2に適用
・ポリシー「AmazonEC2RoleforSSM」を含むロールを作成し、EC2に適用。その際に信頼されたエンティティを「ec2.amazonaws.com 」「ssm.amazonaws.com 」の2つにする。
(参考サイト)
インフラエンジニア、初めてのLambda(前編)
コードを書いたことがないインフラエンジニア（私）が、独学でLambdaを触って、「ハマった部分」を記載。同じように初めて触る方の参考になればと。記事は２回（前編、後編）に分けます。
Lambdaの設定
Lambdaはサーバーレスでコードを実行できるサービスです。
AWS Lambda（イベント発生時にコードを実行）| AWS
「なんらかのイベント」をトリガーにLambdaを動作させるというもののようです（私の理解）。設定方法としては2つあります。
(1)Lambdaの設定画面でコードを直接入力する
(2)Lambdaが備えていないライブラリを実行したい場合は、「外部ライブラリ」と「コード」をパッケージ化してzip化したものをLambdaに登録
素人には(1)と(2)の区別をどうすればよいのか？がすぐにはわかりません。現時点(2021/7時点)での私の理解は、下記サイトのコードであれば(1)でよいのではと思ってます。間違っていれば別途訂正します。
Lambda — Boto3 Docs 1.18.2 documentation
いろいろなサイトをみるとサンプルコードが公開されています。その中で、「外部ライブラリ」の記述がなければ、(1)で実行できると思っています。
ここでハマったことの1つ目です。後述しますが、Lambdaを設定するコンソールの操作を間違っていたため、意図した通りLambdaが動作しませんでした。当初は操作の誤りという認識がなかったため、上記の(1)で動作しないので(2)でやる必要があるのか？と思い込んでました。
コードの中身
上述の通り、Lambdaは「なんらかのイベント」をトリガーとします。素人的には「そのトリガーを受け取ったLambdaが、コードに記載された値を実行する」と考えていました。この先入観をもって、世の中のサンプルコードを見ていたので中身を理解できなかったことが、ハマったことの2つ目です。
私の検証では、「CloudWatch Events」をトリガーにLambdaを動作させるというものでした。いくつかのサンプルコードでは、CloudWatch Eventsの中に「値」を入れてLambdaのコードは「変数」という構造でした。コードを書く人はこのような構造が多いんですかね。今回の検証内容を運用で利用する場合、Lambdaは1つだけ設定し、CloudWatch Eventsを複数作成するとなりますが、そちらの方が運用に最適だなと気付かされました。
（検証内容、参考にしたサイト）
CloudWatchアラームに定時ダウンタイム設定をいれる - Qiita
CloudWatchAlarmにLambdaでダウンタイム設定をいれてみた | DevelopersIO
本当に勉強になりました。ありがとうございました。
操作方法、コードの保存
ハマったことの3つ目です。操作方法です。Lambdaの設定画面で、コードを保存しました。その際にデフォルトの名前「lambda_function.py」から異なる名前にしました。拡張子を「.py」としなかったためコードが読まれませんでした。サンプルコードが記載されたサイトではコードの文字列がカラフルでしたが、私のLambdaの画面は「黒文字のみ」だったため、不思議でした。また、テスト機能にどんな値を入れて良いのかわからず、切り分けができませんでした・・・
以上が前編です。後編は実際の操作画面を記載します。
Run Commandでシェルを実行、その結果をメール通知
（やったこと）
・AWS Systems ManagerのRun CommandからEC2へPowerShellのコマンドを投げる
・その結果をAmazon SNSでメール通知
ここでいう「結果」とは、PowerShell実行の「成功」「失敗」であり、EC2上で実行されたPowerShellの結果が通知されるものではなかった・・・この検証を始めた目的は、「EC2上で実行されたPowerShellの結果を通知させる」だったので残念な結果となりました。
（流れ、手順）
- SNS、IAM関連の設定
下記サイトを参考に、SNS、IAMポリシー、ロールの設定を行います。私は「タスク5」の設定を間違ったため、「ハマり」ました。SNSからのメールが届かず何度も設定を見直しました。
- Systems Manager Run Command の設定
Systems Manager の画面より、Run Command を選択します。
Systems Manager
PowerShellで検索 
PowerShellを実行できるコマンド 
コマンド 
EC2を選択
以上で設定完了です。Run Commandを実行し、その結果を確認する画面が以下です。
結果 
メール
2021年7月の目標
ブログを書き始めたのは、以下が理由です。
- エンジニアとして、技術に関わり続けたい（マネジメントだけは嫌）
- エンジニアとして、手を動かしたい（週に2-3日は技術に触れたい）
- エンジニアとして、表現するスキルを向上させたい
正直、そんなにスキルがあるわけではないです。ここ5年はExcel、パワポ職人で「マネジメント」がメイン業務でした。エンジニアとしての在り方を考えるようになり、それがきっかけで転職することになりました。なので、（三日坊主になろうとも）自分の好きな「クラウドに関するインフラブログ」を書き始めました。ここら辺の話はおいおい。
2021年7月の目標
- 技術ブログを3本書く！（技術ブログ以外は別に1本）
- ブログの見やすさを向上させる！（図、または絵を一度はアップする）
- 技術本を4冊読む！（2冊は読み終わりたい）
「3.技術本を4冊読む！」ですが、以下の4冊を購入しました。読むだけにならないように・・・
EC2(Windows)のEBSを異なるEC2にマウントする
（やりたいこと）
- WindowsServer にEBS追加、ディスク拡張、ファイル作成
- 「1.」からEBSをデタッチ
- デタッチしたEBSを別Serverにアタッチ、ファイルがちゃんと見えるか？
（実現方法）
- EBSのアタッチ、デタッチ
- 別Server（WindowsOS） 上でディスクの有効化、ドライブの割り当て
（やったこと）
- 1台目のWindowsServerにEBSをアタッチ ①EC2ダッシュボードより、「Elastic Block Store＞ボリューム」を選択。 ②EBSボリュームを作成する。アクセスする「アベイラビリティーゾーン」は、1台目のWindowsServerと同じであること。 ③「アクション＞ボリュームのアタッチ」を選択して、1台目のWindowsServerにアタッチ。 ④1台目のWindowsServerにログインして、OS上でディスクの有効化、ドライブ割り当て。その後、OS上で該当ドライブに作成したテストファイルを保存。
- 1台目のWindowsServerからEBSをデタッチ ①EC2ダッシュボードより、「Elastic Block Store＞ボリューム」より、「アクション＞ボリュームのデタッチ」を選択して該当のEBSボリュームをデタッチ。
- 2台目のWindowsServerにEBSをアタッチ ①EC2ダッシュボードより、「Elastic Block Store＞ボリューム」を選択。 ②アクション＞ボリュームのアタッチ」を選択して、2台目のWindowsServerに該当のEBSボリュームをアタッチ。 ③2台目のWindowsServerにログインして、OS上でディスクの有効化、ドライブ割り当て。その後、OS上で該当ドライブ上に1台目で作成したファイルが存在することを確認。
（雑談）
オンプレ・仮想化環境において、１つのOSに複数のストレージボリュームをアタッチすることはよくあること。それがAWSでも可能なことが確認できた。その際は、EBSとEC2は同じアベイラビリティーゾーンである必要がある。
AWS Systems Manager でWindows Server にRDPする！
（やりたかったこと）
・プライベートサブネットのEC2(Windows)をRDPでメンテナンスする
・踏み台サーバは作りたくない
（実現方法）
・AWS Systems Manager(SSM)でWindows Server にRDPする
１．マネージドインスタンスにする
２．SSMセッションマネージャーを使う
（はまったこと）
●パブリックサブネットとプライベートサブネットで実現方法が異なっていた
・パブリックサブネットでインターネットにアクセスできれば「SSM」でアクセス可能
・プライベートサブネットでインターネットにアクセスできない環境であれば、「SSM＋VPCエンドポイント」でアクセス可能
（前提条件）
・VPC、プライベートサブネット、EC2を事前に作成する
・SSMを利用するAWS用のユーザ(ssmuser)を作成する
・パソコンにAWS CLI、SSMプラグインをインストールする
・SSM用のグループ(AWSSSMaccess-G)を作成、ssmuserを追加する
・AWSSSMaccess-Gに２つのポリシーをアタッチ
・AmazonEC2ReadOnlyAccess
・AmazonSSMFullAccess
（やったこと）
１．マネージドインスタンスにする
①EC2(Windows)にSSM Agentを入れる(大体はデフォルトで入っている)
②SSM APIへの通信経路を確保する。SSM AgentからSSM APIへアウトバウンド通信が発生する。これを確保する。SSM Agentからインターネットにアクセスできない場合、VPCエンドポイントを利用してSSM APIへの経路を確保する。VPCに３つのエンドポイントを追加、EC2からの接続(443)を許可するSGを作成し、エンドポイントにアタッチ。
・com.amazonaws.ap-northeast-1.ssm
・com.amazonaws.ap-northeast-1.ec2messages
・com.amazonaws.ap-northeast-1.ssmmessages
③EC2にIAMロールをアタッチする
・IAMポリシー「AmazonSSMManagedInstanceCore」をEC2用のIAMロールにアタッチ
２．SSMセッションマネージャーを使う(セッションマネージャーで直接アクセス)
①パソコン側の操作
・aws configure、ssmuser のAccess Key ID、Secret Access Key、を入力
・aws ssm start-session --target EC2のインスタンスID --document-name AWS-StartPortForwardingSession --parameters "portNumber=3389, localPortNumber=13389"
・コマンドプロンプト画面で「Waiting for connections...」と表示されれば、RDP画面を起動
・アクセス先を「localhost:13389」とする
・WindowsのID、パスワードを入力する
