Auto Scalingとは？ EC2を利用して、自動的にサーバを増減してパフォーマンスを最適化してくれるサービスです。 詳細は こちら をごらんください 概要 目次 AMIを作成 ターゲットグループの作成 ロードバランシングの作成 Auto Scalingの起動設定を作成 Auto Scalingグループの作成 テスト イメージ図 ALBはAZが複数必要なので2つ作成しました。 作成 1. AMIを作成 EC2インスタンスを作成 とりあえずAmazonlinuxのt2.microでEC2インスタンスを作成しました。 httpdの設定 sudo su - yum install httpd systemctl start httpd systemctl enable httpd vi /var/www/html/index.html ========== <h1>hello world!!!!</h1> ========== ブラウザからwebサイトが見えることを確認 http://[IPアドレス]/index.html EC2インスタンスのイメージを作成 設定を行った、EC2インスタンスにチェックをいれて アクション > イメージ > イメージの作成 からAMIを作成する AMIの設定 イメージ名と説明を入れて作成を行います 作成中 ステータスがpendingになっています 作成完了 ステータスがavailableになりました 2. ターゲットグループの作成 移動 EC2 > ロードバランシング > ターゲットグループ からターゲットグループの作成を行います ターゲットグループの作成 ターゲットグループ名とターゲットの種類、 またヘルスチェックのパスを先ほど作成した /index.html に指定します ターゲットグループが作成されました 3. ロードバランシングの作成 移動 EC2 > ロードバランシング > ロードバランサー からロードバランサーの作成を行います ロードバランサーの種類 今回はwebサーバを作成してロードバランシングしたいので、ALBを作ります ロードバランサーの設定 ALBはAZが2つ必要なので、2つ設定します。 セキュリティ設定 ↑でリスナーを443(https)にしていたらこちらで証明書などの設定が必要なのですが、 今回はAutoScalingがメインなので80番ポートで通信させます セキュリティグループの設定 ALBに来るアクセスに対してのセキュリティグループの設定です。 一旦、今あるものをここでは使ってますが、 80番ポートがあいていればOKです ターゲットグループの設定 先程作成したターゲットグループを選択します。 するとグレーアウトになっている部分はデフォルトで入ります。 ターゲットの登録 通常であればターゲット(インスタンス)が存在していれば登録が出来るのですが、 現在はまだ出来ていないので登録できません 確認 作成したALBの設定が認識通りか確認してください 作成完了 ALBが作成されました 4. Auto Scalingの起動設定を作成 移動 EC2 > AUTO SCALING > 起動設定 から起動設定の作成を行います 起動設定の作成 起動名はわかりやすいものを。 AMIは 今回は一番最初に作成したEC2インスタンスのAMIを使います インスタンスタイプは t2.micro 追加設定は特に何もせず、デフォルトのままいきます セキュリティグループは現在あるものを使用し、キーペアも今あるやつを使いました。 ここらへんはEC2などでも設定するので何も触らず進めます 起動設定が完了しました 5. Auto Scalingグループの作成 移動 EC2 > AUTO SCALING > AutoScalingグループ からAutoScalingグループの作成を行います 起動設定の選択 AutoScalingグループ名を記載します。 また、起動設定に切り替えて先ほど作成した起動設定を選択します 設定の構成 VPCはALBをおいたVPC。 また、サブネットもALBで設定した2つのAZのサブネットを記載します 詳細オプションを設定 ロードバランシングは↑ですでに作成しているので、既存のロードバランサーにアタッチします。 また、ターゲットグループも作成しているので、既存のロードバランサーターゲットグループにアタッチを行います。 ほかはデフォルトで行きます グループサイズとスケーリングポリシー スケーリングしてもらいたいので、グループサイズの最大キャパシティとスケーリングポリシーを変更しました 通知設定 通知はさせないので、設定しません。 タグ設定 タグも必要ないので設定しません 確認 今の設定が問題ないことを確認して設定を作成します 作成完了 作成出来ました ELBへのヘルスチェックも確認します EC2 > ロードバランシング > ターゲットグループ > Autoscaling-ALB-TargetGroup > ターゲット から ターゲットの確認ができます。 ターゲットが healthy になってることを確認します 接続確認 本来なら、Route53にALBを紐付けて・・・みたいなことをしたいのですがそこまで用意できなかったので、 localのサーバでALBのIPを確認し、それに対してブラウザで表示できるか確認します EC2 > ロードバランシング > ロードバランサー > Autoscaling-ALB > 説明 のDNS名をコピーします。 そのDNS名をlocalのサーバで以下のように確認すると、IPアドレスが出てきます。 dig [DNS名] +short ========== xx.xx.xx.xx xx.xx.xx.xx ========== ↑で出てきたIPアドレスをコピーしてブラウザから http://[IPアドレス]/index.html で確認します。 下記のように表示できたらOKです。 6. テスト AutoScalingは負荷がかからないと台数が増えないので 内部でCPUを使うように適当なスクリプト作成します AutoScalingグループで確認 台数が3台になっています。 EC2インスタンスで確認 同じく新しいサーバが2台増えています ターゲットグループで確認 ターゲットグループ配下にいるサーバが3台に増えました 負荷をかけるとサーバが増えることを確認できました。 勉強後のイメージ 結構セキュリティグループとかヘルスチェックとかでつまづいたりした。 画像がもしかしたらちぐはぐな所あるかもですが、いい感じに読み替えてください。 なんとなくイメージはわかってたけど、ちゃんと増えるんだなってのはわかってよかった。

前提 AWS OpenSearch ServiceでサポートするElasticsearch 7.10.2時点までの内容になります。 理解のステップ 以下のステップにより専用マスターノードに関しては3つが推奨な理由が大体理解できる流れです。 マスターノードとは何か、他にどんなノードタイプがあるのかを把握する。 専用マスターノードとは何か把握する。 quorumとは何か把握する。 理想のquoram数を出す式がdedicated master nodes / 2 + 1の理由を把握する。 これまでマスター候補ノード(master-eligible node)はなぜ奇数台にするべきだったのか把握する。 Elasticsearch7.xでのマスター候補ノード設定の仕様変更を把握する。 マスターノードとは？ ノードが持つロールの内の1つであるmasterの役割をするノード。 masterのロールは、インデックスの作成または削除、クラスターの一部であるノードの追跡、どのシャードをどのノードに割り当てるかを決定するなど、クラスター全体のアクションを担当します。 その他のノードのタイプ データノードはもちろん、Igectノードなどがあります。以下公式ページ参照。 専用マスターノード(Dedicated master nodes)とは ノードは複数のロールを同時に担うことができますが、専用マスターノードはMasterのロールしかしか担当しないノードのことです。 複数のロールを担当するノード [Data, Master] 専用マスターノード [Master] Amazon OpenSearch Service では専用マスターノードを利用することを推奨している つまりAWSが推奨する世界では、Dedicated Master Node は Master-Eligible Nodeと同じとみなして良いです。 理由はAZ構成などに関連しています。詳細は以下のAWS公式ドキュメント参照。 quorumとは何か？ マスターのロールを持つ全ノードにおいて、障害が発生した際などに新たなMasterの選出やクラスタ構成変更をすることがあります。この変更の決定をするために参加するべきノードの最小数をquorumと呼びます。quorum数以上で合意しているなら実行、そうで無いならば実行できません。 理想のquorum数を出す式がdedicated master nodes / 2 + 1の理由 Elasticsearchではdedicated master nodes / 2 + 1の式で出る値をquorumの値にするべきと推奨されています。 その理由は、ネットワーク上の障害が発生した際の「スプリットブレイン」と呼ばれるマスターノードらが分断されるときに、分断されたそれぞれでバラバラに構成変更が実行されてしまうという問題が起きないようにすることが目的です。 Master-eligible Node(マスターノード候補)の数が奇数台が良い理由 偶数台では結局1台分が無駄になることが理由です。 以下はquorumの設定がElasticsearch7.xで自動で設定されるようにmaster nodes / 2 + 1としている際のマスターノード台数とノードの障害発生時のクラスタ復旧に対応する表です。 1台障害発生 2台障害発生 master2台 復旧不可 復旧不可 master3台 復旧可能 復旧不可 master4台 復旧可能 復旧不可 ポイントなのはmaster3台でも4台でも障害発生数におけるクラスタ復旧具合に違いが無いことです。 master4台で2台障害が発生してもquorumが3なので4-2(=2)台では復旧ができません。master3台で1台障害ならばquorumは2なので3-1(=2)で復旧可能です。 このことから偶数台ではその1つ少ない奇数台と同じ耐障害性の能力なので専用マスターノードであるならば1台分のノードが無駄と言えます。 Elasticsearch7.xからはquorumを自動で決定してくれるようになった Elasticsearch7.x 以前ではquorumはユーザーが自分で設定する必要がありました。Elasticsearch7.x からはquorumを安全な形で自動で算出するようになりユーザーは考慮をしてなくても良くなりました。 これについては以下の記事が非常にわかりやすく説明されています。 しかし、上述したマスターノードが偶数台では1台が無駄になってしまうこと自体は変わりありません。 結論 ここまでをまとめると以下なります。専用マスターノードが3つが推奨な理由がわかります。 1つ => 耐障害性なし 2つ => quorumが1ではスプリットブレインのリスクあり。quorumを2にして回避しても、1ノードの障害時にマスターを決めることができず障害になる、というリスクを抱える。 3つ => 推奨 4つ => Elasticsearch6以下ではスプリットブレインの障害リスクあり。Elasticsearch7からは耐障害性は3つと同等になるが専用マスターノードとしては1台が無駄である。 5つ以上 => 4つでのElasticsearch7の場合の理由と同じく、耐障害性の観点では専用マスターノードとしては無駄になる。このとき、パフォーマンスの観点ではシステム規模によって必要になる。 参考

概要 Trend Micro Cloud One - Workload Security は、「ホスト型」のサーバセキュリティ対策製品となります。 そのため、保護対象となるサーバにエージェントをインストールする必要があります。このエージェントは、「Deep Security Agent（DSA）」と言い、　Cloud One - Workload Security に製品名が変更される前の Deep Security as a Service（DSaaS）からの名残でそのような名前になっています。 Deep Security Agent（DSA）のインストール方法 1. DSA のインストールスクリプトを取得する 1 . Cloud One - Workload Security の管理コンソール（DSM：Deep Security Manager）にログインします。 https://cloudone.trendmicro.com/ 2 . 画面上部にある「サポート情報」をクリックし、表示されたメニュー内から「インストールスクリプト」をクリックします。 3 . 「プラットフォーム」を「Linux 版 Agent のインストール」、「セキュリティポリシー」を「Base Policy > Linux Server」に設定して、「クリックボードにコピー」をクリックします。これで、インストールスクリプトがクリップボードにコピーされます。 2. DSA のインストールスクリプトをサーバで実行する 保護対象サーバの任意の場所にファイルを作成して、上記で作成 & コピーしたインストールスクリプトを貼り付けます。 [centos@localhost ~]$ sudo vi script 2 . 作成したファイルに実行権限を付与して、インストールスクリプトを実行します。 [centos@localhost ~]$ sudo chmod 777 script [centos@localhost ~]$ sudo ./script エラーメッセージ等が表示されなければ DSA のインストールは成功です。 3. Deep Security Manager（DSM）で保護対象を確認する 1 . Cloud One - Workload Security の管理コンソール（DSM：Deep Security Manager）にログインします。 https://cloudone.trendmicro.com/ 2 . 画面上部にある「コンピュータ」をクリックし、表示された一覧内にエージェントをインストールした保護対象サーバが表示されていることを確認してください。 これで、DSA を保護対象サーバにインストールすることができました。 参考資料 インストールスクリプトの使用 https://help.deepsecurity.trendmicro.com/10/0/ja-jp/Add-Computers/ug-add-dep-scripts.html

IAMロールの作成 Lambda関数の新規作成画面からカスタムロールを新規作成できなくなっているようなので、あらかじめIAMのメニューからロール、ポリシーを作成します。以下の権限が必要となります。 LambdaからEC2を停止/起動するための権限 CloudWatchLogsにログを出力するための権限 ロール作成時、信頼されたエンティティはLambdaを選択し、以下のポリシーで作成します。通常はec2:DescribeInstancesの権限は不要ですが、今回はNameタグをキーにインスタンスIDを取得してからEC2を停止するので付与しています。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:*:*:*" }, { "Effect": "Allow", "Action": [ "ec2:StartInstances", "ec2:StopInstances", "ec2:DescribeInstances" ], "Resource": "*" } ] } Lambda関数の作成 ランタイムはPython3.8、実行ロールは事前に作成したIAMロールを選択します。 Lambdaが作成できたらlambda_function.pyのコードを以下のように修正して「Deploy」ボタンを押して保存します。 printの2行はログに出力させるためのものです。 import boto3 def lambda_handler(event, context): # valiables instance_name = event["InstanceName"] # get instance id client = boto3.client("ec2") instance_id = client.describe_instances( Filters=[{"Name": "tag:Name","Values": [instance_name]}] )["Reservations"][0]["Instances"][0]["InstanceId"] # start / stop ec2 if event["Action"] == "start": response = client.start_instances(InstanceIds=[instance_id]) elif event["Action"] == "stop": response = client.stop_instances(InstanceIds=[instance_id]) print(event) print(response) 全然知らなかったのですが、Lambdaではデフォルトではlambda_function.pyのlambda_handler関数が呼ばれるようになっています。ランタイム設定のハンドラを見ればわかります。 なので、初めからあるlambda_function.pyのファイル名を変えてしまうと中身のコードが正しくても動かなくなりますし、コードはlambda_handler関数の中に記述する必要があります。def lambda_handler(event, context):の1行はお決まりのコードだと理解しておけば問題なさそう。 Python の AWS Lambda 関数ハンドラー また、def lambda_handler(event, context):の第1引数のeventでイベントを渡しています。 コードの中で利用する値をJSON形式で渡すことができるようです。今回のコードでいうと、以下の2か所をJSONで渡すことにしています。（こうすることで、コードに直接パラメータを埋め込む必要がなくなり汎用性が高まるのだと理解） event["InstanceName"] event["Action"] InstanceNameはNameタグの値、Actionはstart/stopのいずれかを渡す想定です。 このあたりは、クラスメソッドさんの以下の記事を参考にしています。 できるだけシンプルな仕組みで簡単にEC2の自動起動・停止を実現したい！ Lambda関数の実行 「Test」ボタンを押すとJSONで渡す値（イベント）を指定する画面になります。 イベント名は「StartStopEC2」として、JSONの中身は以下のように書き換えて作成します。 まずは起動(start)から。 { "Action": "start", "InstanceName": "AmazonLinux01" } テストイベントが作成できたらもう一度「Test」ボタンを押すと関数が実行されます。 Function Logsを見ると、もともとstoppedだったのがpendingになっていることがわかります。 EC2の画面を見てみると「実行中」に変わっていました。 Test → Configure test eventからテストイベントの設定を開いて、今度はstopに変更して保存します。 再度テストを実行してみると、今度はもともとrunningだったのがstoppingになっていることがわかります。 EC2の画面では「停止中」になっていて、しばらくすると「停止済み」となりました。 CloudWatch Eventsにスケジュールを登録 スケジュールに従ってLambda関数を実行するにはCloudWatch Eventsを利用します。CloudWatchのメニューの中にあるイベント → ルールから登録できます。とりあえずの動作確認が目的なので、スケジュールは5分おきに実行するように指定しています。cronの書き方は以下の公式ドキュメントを見ればだいたいわかります。 ルールのスケジュール式 ターゲットの入力の設定では「定数(JSON テキスト)」を選択し、ActionとInstanceNameの項目を入れたJSONを渡してあげます。以下は、EC2を起動させる場合のJSONですが、テストイベントの時と同じようにstartをstopに変えてあげればEC2を停止するルールを作成することができます。 {"Action": "start", "InstanceName": "AmazonLinux01"} つまり、ルールを2つ作成して、EC2起動は平日の朝の9時、EC2停止は平日の20時といった形で設定することになります。 ルールを登録してしばらく待つと、停止済みだったEC2が起動してきました。 ログもCloudWatch Logsに出力されていました。 まとめ python(boto3)でコードを書くのが敷居が高いイメージがあり、なかなかちゃんと触る機会がなかったのですが、やってることはWindowsのタスクスケジュラやLinuxのcronと変わりはないので、基本的な使い方を覚えてしまえばサーバレスならではのメリットを享受できそうだと感じました。 ここまで書いておきながらなんですが、EC2起動/停止はLambdaでコードを書かなくてもSSM Automationで実現できるので、また試してみて投稿したいと思います！ 参考リンク Python の AWS Lambda 関数ハンドラー できるだけシンプルな仕組みで簡単にEC2の自動起動・停止を実現したい！ ルールのスケジュール式

概要 やりたいこと EC2 のメモリ使用率・ディスク使用率などを CloudWatch で監視したい 各種サービスやアプリケーションが出力するログも CloudWatch に送信したい ただし管理コンソールや AWS Systems Manager を使わないで、Ansible と CloudFormation だけで構成・更新したい 上記 3. で試行錯誤したので、備忘録を記事にしました。 環境 Ansible 2.9 と 2.10 で動作しました。3.x は未使用です Amazon Linux 2 を使用します 予備知識 まず CloudWatch の全体像について、以下の動画で勉強させていただきました。 【AWS】CloudWatch メトリクスを中心に6つの観点から徹底解説！｜くろかわこうへい【渋谷で働いてたクラウドエンジニアTV】 【AWS Black Belt Online Seminar】Amazon CloudWatch｜Amazon Web Services Japan 公式 CloudFormation で EC2 に IAM Role をアタッチする 監視対象の EC2 インスタンスが CloudWatch にメトリクスやログを送信するためには、適切な IAM ロールが必要です。 ec2-iam-role-stack.cfn.yaml AWSTemplateFormatVersion: '2010-09-09' Parameters: MyEc2KeyName: Type: "AWS::EC2::KeyPair::KeyName" Resources: # CloudWatchに送信するためのIAMロール定義 MyIamRole: Type: "AWS::IAM::Role" Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Principal: Service: - "ec2.amazonaws.com" Action: - "sts:AssumeRole" Path: "/" # EC2に適用したい管理ポリシーのARNをここに列挙する ManagedPolicyArns: - arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy # 上で定義したIAMロールをEC2インスタンスに適用するために # IAMインスタンスプロファイルを定義する MyInstanceProfile: Type: "AWS::IAM::InstanceProfile" Properties: Path: "/" # 上で定義したIAMロールを関連付ける Roles: - !Ref MyIamRole # 監視対象のEC2インスタンス MyEc2Instance: Type: "AWS::EC2::Instance" Properties: ImageId: ami-00d101850e971728d InstanceType: t2.micro KeyName: !Ref MyEc2KeyName # 上で定義したIAMインスタンスプロファイルをアタッチする IamInstanceProfile: !Ref MyInstanceProfile EC2 インスタンス、IAM インスタンスプロファイル、IAM ロール、管理ポリシーという 4 種類のリソースの関係が分かりにくいのでクラス図を作ってみたら、下図のようになりました。 IAM ロールと管理ポリシー 適用したい管理ポリシーの ARN を、AWS::IAM::Role の ManagedPolicyArns プロパティに列挙します。 AWS::IAM::ManagedPolicy | AWS User Guide AWS::IAM::Role | AWS User Guide 上記の arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy は、メトリクスやログを CloudWatch に送信するために必要な管理ポリシーです。 これ以外にもアタッチしたい管理ポリシーがあれば、ここに並べて指定します。 例えば S3 へのアクセスが必要なら arn:aws:iam::aws:policy/AmazonS3FullAccess などを追加します。 参考： 管理ポリシーとインラインポリシー｜AWS ユーザーガイド 管理ポリシーの ARN が分からない場合は、AWS 管理コンソールの「サービス」→ 「IAM」→「ポリシー」に名前の一部を入力すれば簡単に見つけることができます。 下図は「s3」でポリシーを絞り込んで「AmazonS3FullAccess」を選択し、表示された ARN をクリップボードにコピーする例です。 IAM インスタンスプロファイル IAM ロールを直接 EC2 インスタンスにアタッチすることはできないので、アタッチするための IAM インスタンスプロファイルを定義して、AWS::IAM::InstanceProfile の Roles プロパティに IAM ロールを関連付けます。 AWS::IAM::InstanceProfile | AWS User Guide EC2 インスタンス 上で定義した IAM インスタンスプロファイルを、監視対象の AWS::EC2::Instance の IamInstanceProfile プロパティにアタッチします。 AWS::EC2::Instance | AWS User Guide Ansible で統合 CloudWatch Agent を構成する CloudWatch Agent 用の Ansible ロールを作成します。 roles/ ├── cloudwatch_agent/ │   ├── handlers/ │   │   └── main.yml │   ├── tasks/ │   │   └── main.yml │   └── templates/ │   └── config.json.j2 テンプレート（設定ファイル） Gunicorn と Nginx のログ、およびディスクとメモリの使用率を収集して CloudWatch に送信するための定義の例です。 templates/config.json.j2 { "agent": { "metrics_collection_interval": 60 }, "logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "/var/log/gunicorn/access.log*", "log_group_name": "gunicorn.access", "log_stream_name": "{local_hostname}" }, { "file_path": "/var/log/gunicorn/error.log*", "log_group_name": "gunicorn.error", "log_stream_name": "{local_hostname}" }, { "file_path": "/var/log/nginx/access.log*", "log_group_name": "nginx.access", "log_stream_name": "{local_hostname}" }, { "file_path": "/var/log/nginx/error.log*", "log_group_name": "nginx.error", "log_stream_name": "{local_hostname}" } ] } } }, "metrics": { "append_dimensions": { "AutoScalingGroupName": "${aws:AutoScalingGroupName}", "ImageId": "${aws:ImageId}", "InstanceId": "${aws:InstanceId}", "InstanceType": "${aws:InstanceType}" }, "metrics_collected": { "collectd": { "metrics_aggregation_interval": 60 }, "disk": { "measurement": [ "used_percent" ], "metrics_collection_interval": {{ cw_interval_default }}, "resources": [ "*" ] }, "mem": { "measurement": [ "mem_used_percent" ], "metrics_collection_interval": {{ cw_interval_default }} }, "statsd": { "metrics_aggregation_interval": 60, "metrics_collection_interval": 10, "service_address": ":8125" } } } } 紛らわしいですが、Ansible (Jinja2) のプレースホルダーは {{ cw_interval_default }} だけで、{local_hostname} と ${aws: … } は CloudWatch Agent が使用するプレースホルダーと変数です。 agent セクション CloudWatch Agent の全体的な設定です。 "run_as_user": オプションを追加して実行ユーザーを指定することができます。省略すると root で実行されます。 logs セクション 収集するログファイルの設定です。 "file_path": オプションでログファイルのパスを指定します。*（アスタリスク）と **（スーパーアスタリスク）を使用することができます。 agent セクションで root 以外の実行ユーザーを指定した場合は、読み取り権限のないログファイルを収集することができなくなります。 metrics セクション カスタムメトリクスの定義と収集の設定です。 内部で使用する collectd と StatsD という 2 つのサービスの設定を含みます。 "namespace": オプションでメトリクスの名前空間名を指定することができます。省略すると CWAgent になります。 設定ファイルを編集するための詳細情報は、以下のページを参照にさせていただきました。 CloudWatch エージェント設定ファイルを手動で作成または編集する｜AWS ユーザーガイド CloudWatch エージェントの設定方法｜myn’s diary ウィザードを使用すれば、質問に答えるだけの対話方式で設定ファイルを作成することができます。以下を参考にさせていただきました。 ウィザードを使用して CloudWatch エージェント設定ファイルを作成する｜AWS ユーザーガイド CloudWatch で EC2 のメモリ・ディスク使用率を監視する｜Wedding Park ブログ 新しいCloudWatch Agentでメトリクスとログの収集が行なえます｜DevelopersIO タスク Amazon Linux 2 に CloudWatch Agent をインストールして、上記テンプレートの設定ファイルを配置する例です。 tasks/main.yml - name: Install or update Amazon packages yum: name: - amazon-cloudwatch-agent - amazon-linux-extras - amazon-linux-extras-yum-plugin state: latest - name: Install collectd from Amazon Extras Library shell: amazon-linux-extras install collectd changed_when: false - name: Enable and start collectd service service: name: collectd enabled: yes state: started - name: Enable and start amazon-cloudwatch-agent service service: name: amazon-cloudwatch-agent enabled: yes state: started - name: Deploy CloudWatch Agent configuration file from templates template: dest: "/opt/aws/amazon-cloudwatch-agent/bin/config.json" src: "{{ role_path }}/templates/config.json.j2" notify: - "cloudwatch agent config changed" 2 番めの shell モジュールを使った collectd のインストールは、AWS 公式ドキュメントに合わせて amazon-linux-extras コマンドを使用していますが、yum でインストールしても問題ないと思います。 3 番目と 4 番目の service モジュールで各サービスを起動して自動起動に設定します。 最後に template モジュールで設定ファイルを /opt/aws/amazon-cloudwatch-agent/bin/ に配置し、ファイルに変更があればハンドラを実行します。 設定ファイルを /opt/aws/amazon-cloudwatch-agent/etc/ に配置して Playbook を実行するとファイルが削除されてしまうため、設定ファイルに変更がなくても changed になってハンドラが実行されてしまいました。 これを避けるために、ウィザードの出力先と同じ bin/ に設定ファイルを配置するようにしました。 ハンドラ 設定ファイルをの変更をトリガーとして実行されます。 handlers/main.yml - name: Fetch configuraton file and restart CloudWatch Agent shell: ./amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:config.json -s args: chdir: "/opt/aws/amazon-cloudwatch-agent/bin/" listen: "cloudwatch agent config changed" amazon-cloudwatch-agent-ctl コマンドを実行して、設定ファイルの定義を CloudWatch Agent に反映します。 -a オプションで実行するアクション（fetch-config）を指定 -c オプションで設定ファイルのパスを指定 -s オプションでサービスを再起動して、設定ファイルの内容を反映します amazon-cloudwatch-agent-ctl コマンドについては以下を参照してください。 コマンドラインを使用して CloudWatch エージェントを起動する｜AWS ユーザーガイド Playbook 以上のロールを既存の Playbook に追記するか、以下のように Playbook を作成して ansible-playbook コマンドで実行します。 my_playbook.yml - hosts: all become: yes roles: - role: common - role: cloudwatch_agent テンプレートで使用する変数は、どこかで cw_interval_default = 60 のように定義されているものとします。 確認 Playbook が完走すると、EC2 インスタンスがメトリクスとログを CloudWatch に送信し始めるので、AWS 管理コンソールにログインして確認することができます。 カスタムメトリクス 送信されたカスタムメトリクス名が CloudWatch → メトリクス → エクスプローラー → メトリクス に表示され、選択することができます。 ログ 送信されたロググループ名が CloudWatch → ログ → ロググループ に表示され、選択すると各 EC2 インスタンスの一覧が表示され、さらにインスタンスを選択するとログの内容が表示されます。 トラブルシューティング 意図したとおりに動作しない場合は、SSH でインスタンスにログインして、以下を確認してみてください。 まず /opt/aws/amazon-cloudwatch-agent/ に移動する Ansible で配置した bin/config.json が存在するか、内容が意図したとおりかを確認する etc/amazon-cloudwatch-agent.toml（実行時に成宇精される）の内容が config.json の内容と一致するを確認する logs/ 内のログを読む SSH 端末から手動で bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:bin/config.json -s を実行して、出力されるメッセージを読む bin/amazon-cloudwatch-agent-ctl -a status を実行して、CloudWatch Agent のサービスの動作状態を確認する

はじめに Aurora(PostgreSQL)からRedshiftのデータを参照する方法を整理。 データ連携方法 ①dblinkのみで連携 ②postgres_fdwのみで連携 ③postgres_fdwとdblinkで連携 ※postgres_fdwとdblinkの違いは参考URLの記事を参照。 環境 【Redshift】 インスタンス：dc2.large × 1ノード ※Redshiftのバージョンは2021/4/10時点での最新バージョンを使用 【Aurora】 PostgreSQL12.4 Redshiftにテーブル「tbl_red1」を作成し、当該テーブルをAuroraから参照。 ①dblinkのみで連携 事前準備 dba=> #拡張モジュールをインストール dba=> create extension dblink; CREATE EXTENSION dba=> \dx List of installed extensions Name | Version | Schema | Description ---------+---------+------------+-------------------------------------------------------------- dblink | 1.2 | public | connect to other PostgreSQL databases from within a database plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language データ取得 dba=> SELECT * FROM dblink('host=xxxx port=5439 dbname=dbr user=reduser1 password=xxxx',$REDSHIFT$SELECT col1, col2 FROM public.tbl_red1$REDSHIFT$) AS t1 (col1 varchar, col2 varchar); col1 | col2 ------+------ 111 | AAA 222 | BBB (2 rows) ※dblink_connectを使った実行も可能。（下記参照） PostgreSQLガイドdblink PostgreSQLガイドdblink_connect ②postgres_fdwのみで連携 事前準備 dba=> #拡張モジュールをインストール dba=> create extension postgres_fdw; CREATE EXTENSION dba=> \dx List of installed extensions Name | Version | Schema | Description --------------+---------+------------+-------------------------------------------------------------- plpgsql | 1.0 | pg_catalog | PL/pgSQL procedural language postgres_fdw | 1.0 | public | foreign-data wrapper for remote PostgreSQL servers dba=> #外部サーバ情報を作成 dba=> CREATE SERVER srv_redshift FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host 'xxxx', port '5439', dbname 'dbr', sslmode 'require'); CREATE SERVER dba=> \des List of foreign servers Name | Owner | Foreign-data wrapper --------------+----------+---------------------- srv_redshift | auruser1 | postgres_fdw dba=> #ユーザマッピング情報を作成 dba=> CREATE USER MAPPING FOR auruser1 SERVER srv_redshift OPTIONS (user 'reduser1', password 'xxxx'); CREATE USER MAPPING dba=> \deu List of user mappings Server | User name --------------+----------- srv_redshift | auruser1 データ取得 dba=> CREATE FOREIGN TABLE tbl_red1 (col1 char(3),col2 varchar(3)) SERVER srv_redshift; CREATE FOREIGN TABLE dba=> select * from tbl_red1; col1 | col2 ------+------ 111 | AAA 222 | BBB (2 rows) ③postgres_fdwとdblinkで連携 事前準備 上記①と②の事前準備を実施 データ取得 dba=> SELECT * FROM dblink('srv_redshift',$REDSHIFT$SELECT col1, col2 FROM public.tbl_red1$REDSHIFT$) AS t1 (col1 varchar, col2 varchar); col1 | col2 ------+------ 111 | AAA 222 | BBB (2 rows) 参考URL RedshiftとAurora(PostgreSQL)でdblinkを貼る方法 外部データとの連携 ～FDWで様々なデータソースとつなぐ～ PostgreSQL dblink & postgres_fdw PostgreSQL9.3 新機能を検証してみた Vol.2

AWS Cloud9を使おうとしたらこんな画面のエラーが出た。 エラー画面 画面上のオレンジの部分のエラーメッセージは以下 This is taking longer than expected. The delay may be caused by high CPU usage in your environment, or your T2 or T3 instance is running out of burstable CPU capacity credits, or there are VPC configuration issues. Please check documentation. 原因 AWS Cloud9を使うにはパブリックサブネットを指定しないといけなかったのですが、このエラーが出た時はプライベートサブネットの設定になっていて、 0.0.0.0/0 (デフォルトゲートウェイ)をインターネットゲートウェイ側に向けるパブリックサブネットの設定にして(赤く囲ったところを追加した)解決。 VPCのルートテーブルの設定を変更して無事作成できました。 シンプルな問題だったのですが、自分はハマったのでメモとして残しておきます。 AWS Cloud9の設定要件はここに載ってます。 https://docs.aws.amazon.com/ja_jp/cloud9/latest/user-guide/vpc-settings.html

開発 エディタ 個人的なおすすめは、Visual Studio Code です。 以降は、VS Code を利用する前提で書いていきます。 なお、settings.json に次の記事の設定をしておくとよいです。 cfn-lint cfn-lint は入力した値の整合性をチェックしてくれます。 導入手順は⬇︎の記事に書かれていたので、割愛します。 例えばやって見た結果は存在しない属性などがあると次の通り、警告を出してくれる様になります。 自動補完 CloudFormation template schema を利用することで、自動補完してくれます。 入力のミスも防いでくれますし、必須のパラメータもわかるのでとても便利かと思います。 このような拡張機能を利用していかないと一から作成するには時間がかかりますし、そもそも無理です。 拡張機能からインストールすることが可能であり、反映にはVS Codeを再起動する必要があります。 利用方法は簡単。例えば、vpc と打ち、vpc を選択すると、 vpc のパラメータを表示してくれます。 テスト cfn-nag テンプレートのセキュリティ的な問題を開発プロセスの初期段階で気づくことができます。 インストール手順は⬆︎のGitHubに公開されている通りで、例えばMACの場合は、brewで必要なものをインストールする。 brew install ruby brew-gem brew gem install cfn-nag cfn_nag_scan で実行した結果、⬇︎の通り VPC Flow log が添付されている必要があるというWarningsが表示されました。 $ cfn_nag_scan --input-path vpc.yaml ------------------------------------------------------------ vpc.yaml ------------------------------------------------------------------------------------------------------------------------ | WARN W60 | | Resources: ["myVPC"] | Line Numbers: [9] | | VPC should have a flow log attached Failures count: 0 Warnings count: 1 CloudFormation Guard 独自に定義したポリシーへの適合性をチェックするツールです。 試されて見たい方は、classmethodさんが試して見たシリーズを書かれている様なので、そちらから。 TaskCat 複数リージョンに同じテンプレートでデプロイする際に簡単にテストできるツールです。 こちらも試されて見たい方は、classmethodさんが試して見たシリーズを書かれている様なので、そちらから。 その他 former2 既存のリソースをテンプレート化してくれる大変優秀なツールです。 former2のサイトにアクセスする。 1.Introduction Setup >> Introduction より、利用するブラウザの拡張をインストールする。（私は今回、Chrome を利用しました。） 2.Credentials ReadOnlyAccess を付与したIAMロールもしくはIAMユーザを準備して認証情報を取得しておき、credentials を設定します。 Access Key Secret Access Key 3.Parameters 今回は特別設定していません。 要するにCloudFormationParametersです。 4.Settings 今回はデフォルトの状態から、Enable Related Resourcesをonの状態にしました。 テンプレート化したいリソースを選択すると、先程Enable Related Resourcesをonにしたことより、関連するリソースも拾ってくれるので、「Add Selected」 で追加し、「Generate」をクリックします。 もう見ての通りですが、これでテンプレート化してくれました。 ちなみにですが、画面上部から「Import」からスタック、変更セットを作成できますが、ReadOnlyAccessではできないので相当なIAMポリシーが必要になるのでご留意を。 CloudFormationを一から作成するには難易度が高いので、コンソールで作成してそこからテンプレート化していくのにおすすめかと思います。

プログラミング勉強日記 2021年4月10日 IAMとは 　IAMはIdentity and Access Managementの頭文字をとったもので、読み方は「アイアム」。AWSのサービスにアクセスして操作し、認証や認可を設定・管理する機構のこと。 　IAMはユーザやグループごとに権限を分けることができる。AWSアカウントで契約したサービスにアクセスして操作できる権限を付与した人をIAMユーザという。IMAユーザごとに細かくアクセスと操作の権限を設定することができて、IAMユーザをグループにまとめると権限をまとめて管理することができる。 　IAMの役割はユーザの認証と認可。アクセスしようとしているのがどのIAMユーザかを特定するのが認証で、IAMユーザのアクセスと操作の権限のみを許可するのを認可という。 IAMの3つの機能 IAMユーザとIAMグループ 　登録・権限設定したIAMユーザで通常の操作を行う。複数のIAMユーザをIAMグループとしてまとめることもでき、グループでまとめて権限の設定を行うことができる。 IAMロール 　IAMユーザは、AWSサービスへのアクセスや操作の権限を付与するもの。IAMロールは、AWSで開発しているアプリのコンテンツやサービスに操作権限(IAMポリシー)を付与する仕組みのこと。 　IAMロールを使用すると、コードに認証パスワードなどの情報を記述する必要がなくなり、セキュリティを高めることができる。 IAMポリシー 　IAMユーザやIAMロールに付与する操作権限をIAMポリシーにJSON形式で記述する。 参考文献 AWSのIAMとは？3つの機能でできることをやさしく解説

はじめに この記事では Docker で Python の Web フレームワーク、Django を動かすだけのハンズオン記事です。 ベストプラクティスや間違いがあれば 書き直していく予定です。 環境 ヤマダにペペロンチーノをこぼされた初代 Surface Book 実装 RAM 8GB エディション Windows 10 Pro バージョン 20H2 OS ビルド 19042.867 Chrome 89.0.4389.90（Official Build） （64 ビット） Docker とは ざっくり、コンテナと呼ばれる単位で環境を構築・管理することができるツール OS レベルの仮想化によって動作して アプリケーションとその動作環境をコンテナという単位で保存しておくことができる。 どこが凄いかと言えば、アプリケーションの環境をコンテナという単位で可搬することが可能なところ。 Docker 以前 Docker 以前は アプリケーションに使われるライブラリやその他パッケージをドキュメント等に残し 同じ環境を作る操作を環境ごとにやる必要があった。 同じ環境を作る操作を誤ったり、間違えたりするとキチンと動作しなかったり 想定とは違う動作になったりする為 同じ環境を作る操作以外にも環境構築の不具合に悩まされ、時間を取られるということがよくあった。 そこで一度作った環境をコンテナという単位でパッケージ化して 他の端末やサーバで扱えるようにしようとできたのが Docker である。 Docker 以後 どんなことが可能になったかをざっくり言うと まずは開発環境の標準化が容易になり、環境セットアップ資料というモノから解放された(極端なことを言うと) 開発環境を他の人と共有するという概念が生まれた。 ※以前にも仮想マシンという形で環境を共有することは可能でしたが Docker ほど簡単ではなかった。 環境のローリングアップデートがコンテナオーケストレーションによって簡単にできるようになった。 ※とはいえ、Docker 技術にキャッチアップするのは割と難しい。現役のエンジニアでもそこそこ難しいところ。 ハンズオンセットアップ ざっくり、流れを説明 AWS 上に EC2 を構築 Visual Studio Code で Remote SSH をインストール Remote SSH の設定 EC2 に Docker をインストール EC2 に Docker-Compose をインストール Python3 のセットアップ pip3 で Django をインストール Django ローカルホストで実行 AWS 上に EC2 を構築 まずはコンソールを開いて。。。 と以前から CloudFormation の記事で EC2 の構築をやっているので 今回は IaC で構築します。 VPC を構築 まずは EC2 を置くためのサブネットを切る為に VPC を CloudFormatin で構築します。 CloudFormation の管理画面を開きます。 スタックの作成をクリック vpc_network.yml AWSTemplateFormatVersion: 2010-09-09 Parameters: VpcCidrBlock: Description: VpcCidrBlock Type: String Default: 10.0.0.0/21 Resources: MainVpc: Type: AWS::EC2::VPC Properties: CidrBlock: !Ref VpcCidrBlock EnableDnsHostnames: true EnableDnsSupport: true Tags: - Key: Name Value: MainVpcfromCF IGW: Type: AWS::EC2::InternetGateway Properties: Tags: - Key: igw Value: igw-cf AttachGateway: Type: AWS::EC2::VPCGatewayAttachment Properties: VpcId: !Ref MainVpc InternetGatewayId: !Ref IGW Outputs: MainVpc: Value: !Ref MainVpc Export: Name: MainVpcId MainIgw: Value: !Ref IGW Export: Name: MainIGWId ファイル選択から vpc_network.yml をアップロードします。 スタック名は「vpc_network」とします。 スタックの作成には時間がかかりますので少し待ちましょう。 スタックの完成予想図。 サブネットを切る VPC が構築できたらサブネットを切ります。 今回は django アプリケーション公開用にセキュリティグループに TCP でポート 8000 を開けます。 DjangoSubnet.yml AWSTemplateFormatVersion: 2010-09-09 Parameters: AZ: Description: AvailabilityZone Type: String Default: "ap-northeast-1a" PublicSubnetCidrBlock: Description: PublicSubnetCidrBlock Type: String Default: 10.0.2.0/24 Resources: PublicSubnet: Type: AWS::EC2::Subnet Properties: AvailabilityZone: !Ref AZ VpcId: !ImportValue MainVpcId CidrBlock: !Ref PublicSubnetCidrBlock Tags: - Key: Name Value: PublicSubnet PubRT: Type: AWS::EC2::RouteTable Properties: VpcId: !ImportValue MainVpcId Tags: - Key: PublicRoute Value: PublicRouteCf PubToInternet: Type: AWS::EC2::Route Properties: RouteTableId: !Ref PubRT DestinationCidrBlock: 0.0.0.0/0 GatewayId: !ImportValue MainIGWId PubRTAssociate: Type: AWS::EC2::SubnetRouteTableAssociation Properties: SubnetId: !Ref PublicSubnet RouteTableId: !Ref PubRT secSSHGroup: Type: AWS::EC2::SecurityGroup Properties: GroupName: PublicSecGrp GroupDescription: PublicSecGrp VpcId: !ImportValue MainVpcId SecurityGroupIngress: - IpProtocol: tcp FromPort: 22 ToPort: 22 CidrIp: 0.0.0.0/0 - IpProtocol: tcp FromPort: 8000 ToPort: 8000 CidrIp: 0.0.0.0/0 Tags: - Key: Name Value: PublicSecGrp Outputs: PublicSubnet: Value: !Ref PublicSubnet Export: Name: PublicSubnet PublicSecGrp: Value: !GetAtt secSSHGroup.GroupId Export: Name: PublicSecGrp ファイル選択から DjangoSubnet.yml をアップロードしてスタックを作成 スタック名を「django-subnet」とします。 スタックの作成には時間がかかりますので少し待ちましょう。 スタックの完成予想図。 キーペアを作成する AWS コンソールから EC2 を開き、左ペインからキーペアを選択 キーペアを作成をクリック キーペアを「Mykeypair」という名前で作成 EC2 を構築する CloudFormation の画面に戻り、EC2 を作成する。 public_django_ec2.yml AWSTemplateFormatVersion: 2010-09-09 Resources: myEC2Instance: Type: AWS::EC2::Instance Properties: KeyName: Mykeypair ImageId: ami-0992fc94ca0f1415a InstanceType: t2.micro Monitoring: false NetworkInterfaces: - AssociatePublicIpAddress: true DeviceIndex: "0" GroupSet: - !ImportValue PublicSecGrp PrivateIpAddress: "10.0.2.10" SubnetId: !ImportValue PublicSubnet Tags: - Key: Name Value: PublicEC2 ファイル選択から public_django_ec2.yml をアップロード スタックの完成予想図 セキュリティグループの確認 SSH 用のポートと公開用のポート番号が開かれていることを確認しましょう。 Visual Studio Code の設定 Visual Studio Code で Remote SSH をインストール EC2 に SSH でログインする為に VisualStudioCode のプラグインである「Remote SSH」をインストールします。 まだ、インストールをしていない人は以下のようにインストールと表示されていると思います。 インストールされている方は以下 Remote SSH の設定 Visual Studio Code の拡張機能 Remote SSH を設定します。 まず、Visual Studio Code の画面左下の緑ボタンを押します。 するとウィンドウの上部に選択肢が出るので「Connect to Host...」を選択 続いて「Configure SSH Hosts」を選択 Remote SSH の格納先を問われるのでユーザ名配下の.ssh を選択 以下の内容を環境に合わせて記載。 Host Django-EC2 HostName {パブリックIPアドレス} IdentityFile {キーペア名(フルパス)} User ec2-user コンフィグを保存して閉じる。 再度、緑のボタンを押して Remote SSH 接続を開始すると新しいウィンドウが開かれる。 Django を試す EC2 Django のセットアップ 「Open Folder 」を選択 ディレクトリを選択 ec2-user のホームディレクトリ「/home/ec2-user/」を選択 Visual Studio Code のウィンドウ左ペインから ファイルを新規作成 以下のような Bash スクリプトを書いて EC2 の「/home/ec2-user/」に保存する。 django-install.sh # !/bin/bash sudo yum update -y && \ sudo amazon-linux-extras install -y docker && \ sudo usermod -a -G docker ec2-user && \ sudo systemctl start docker.service && \ sudo systemctl status docker.service && \ sudo systemctl enable docker.service && \ sudo curl -L https://github.com/docker/compose/releases/download/1.21.0/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose && \ sudo chmod +x /usr/local/bin/docker-compose && \ sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose && \ sudo yum install -y python37 python3-devel gcc jq tree git && \ git clone https://github.com/ymd65536/django_test.git && \ cd django_test/source && \ cd src && \ pip3 install -r requirements.txt --user && \ python3 manage.py migrate && \ python3 manage.py runserver 0.0.0.0:8000 &(アンパサンド)を使うことでコマンドの実行がこけた時の対策ができる。 例えば、今回のケースだと最初の yum がこけた場合は以降のコマンドは実行されない。 また、バックスラッシュでコマンド同士をつなぐとコマンド同士をつないでから実行するという意味になる。 作成した Bash スクリプトを実行する。 [ec2-user@ip-10-0-2-10 ~]$ pwd /home/ec2-user [ec2-user@ip-10-0-2-10 ~]$ [ec2-user@ip-10-0-2-10 ~]$ ls django-install.sh [ec2-user@ip-10-0-2-10 ~]$ [ec2-user@ip-10-0-2-10 ~]$ bash ./django-install ------------------------------------- Performing system checks... System check identified no issues (0 silenced). April 10, 2021 - 13:30:12 Django version 2.0, using settings 'todobackend.settings' Starting development server at http://0.0.0.0:8000/ Quit the server with CONTROL-C. HTTP で開く EC2 上に Django によって作成された Web ページがオープンされたので http://パブリック IP アドレス:8000 でアクセスする。 うまくいくとこんな感じに Django の REST Framework が表示される。 REST API で遊んでみる http://localhost:8000/todos を開く UI で操作するのも良いですがここでは curl で操作してみることにする。 #POSTでitemを作成する curl -X POST -H "Content-Type: application/json" localhost:8000/todos -d '{"title": "推しのリプライを確認", "order": 1}' ※途中動かなくなったと思ってガチャガチャとリクエストを打ったら todo 番号がめちゃくちゃになりました。 #タスクを更新する（localhost:8000/todos/16 のアイテムのcompletedを更新） curl -X PATCH -H "Content-Type: application/json" localhost:8000/todos/16 -d '{"completed":"true"}' 「推しのリプライを確認」16 の todo ステータスが true になりましたね。 他の 14 と 15 の todo を消してみましょう。 #タスクを削除する（localhost:8000/todos/14,localhost:8000/todos/15 のアイテムを削除） curl -X DELETE -H "Content-Type: application/json" localhost:8000/todos/14 curl -X DELETE -H "Content-Type: application/json" localhost:8000/todos/15 todo 番号 14 と 15 が消えましたね。 todos の中身を見る [ec2-user@ip-10-0-2-10 src]$ curl http://localhost:8000/todos | jq % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 110 100 110 0 0 5789 0 --:--:-- --:--:-- --:--:-- 5789 [ { "url": "http://localhost:8000/todos/16", "title": "推しのリプライを確認", "completed": true, "order": 1 } ] [ec2-user@ip-10-0-2-10 src]$ テストプログラムを実行 あらかじめ用意しておいたテストプログラムを実行する。 まずは、テスト用プログラムに利用するパッケージをインストールする為に ディレクトリを移動する。 [ec2-user@ip-10-0-2-10 src]$ cd /home/ec2-user/django_test/source/src/ [ec2-user@ip-10-0-2-10 src]$ pip3 install -r requirements_test.txt --user [ec2-user@ip-10-0-2-10 src]$ python3 manage.py test --settings todobackend.settings_test ---------------------------------------------------------------------- XML: /home/ec2-user/django_test/source/src/unittests.xml Name Stmts Miss Cover ----------------------------------------------------- todo/__init__.py 0 0 100% todo/admin.py 1 1 0% todo/migrations/0001_initial.py 5 0 100% todo/migrations/__init__.py 0 0 100% todo/models.py 6 6 0% todo/serializers.py 7 0 100% todo/urls.py 6 0 100% todo/views.py 17 0 100% ----------------------------------------------------- TOTAL 42 7 83% ---------------------------------------------------------------------- Ran 12 tests in 0.181s OK Destroying test database for alias 'default'... [ec2-user@ip-10-0-2-10 src]$ rails test もテストにパスすると最後に OK が出るのでなんだか親しみやすいですね。 まとめ 今回は CloudFormation で VPC と EC2 を構築して django 環境を建て Django REST Framework で遊んでみました。 次回は EC2 インスタンス上で Docker を扱っていきます。 おわり

メモ。 アドレス 用途 リファレンス 169.254.169.123 時刻取得 Linuxインスタンスの時刻の設定 169.254.169.253 名前解決 VPC での DNS の使用 169.254.169.254 メタデータの取得 インスタンスメタデータの取得

EC2でyum updateしようとしたら以下のエラーが発生した。 前提として ・EC2はPrivate Subnetに配置してある ・VPCエンドポイントは設定済み である。 [ec2-user@ip-10-0-77-0 ~]$ sudo yum update 読み込んだプラグイン:extras_suggestions, langpacks, priorities, update-motd Could not retrieve mirrorlist http://amazonlinux.ap-northeast-1.amazonaws.com/2/core/latest/x86_64/mirror.list error was 12: Timeout on http://amazonlinux.ap-northeast-1.amazonaws.com/2/core/latest/x86_64/mirror.list: (28, 'Resolving timed out after 5000 milliseconds') One of the configured repositories failed (不明), and yum doesn't have enough cached data to continue. At this point the only safe thing yum can do is fail. There are a few ways to work "fix" this: 1. Contact the upstream for the repository and get them to fix the problem. 2. Reconfigure the baseurl/etc. for the repository, to point to a working upstream. This is most often useful if you are using a newer distribution release than is supported by the repository (and the packages for the previous distribution release still work). 3. Run the command with the repository temporarily disabled yum --disablerepo=<repoid> ... 4. Disable the repository permanently, so yum won't use it by default. Yum will then just ignore the repository until you permanently enable it again or use --enablerepo for temporary usage: yum-config-manager --disable <repoid> or subscription-manager repos --disable=<repoid> 5. Configure the failing repository to be skipped, if it is unavailable. Note that yum will try to contact the repo. when it runs most commands, so will have to try and fail each time (and thus. yum will be be much slower). If it is a very temporary problem though, this is often a nice compromise: yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true Cannot find a valid baseurl for repo: amzn2-core/2/x86_64 Resolving timed out after 5000 milliseconds でggったら公式リファレンスが引っかかった。 https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-troubleshoot-yum-errors-al1-al2/ けど内容が正直よく分からない・・・（YourDNSって何？どう正しければ良いの？何を直せばいいの？） 「Resolving timed out after 5000 milliseconds」 次のコマンドを実行して、/etc/resolv.conf ファイルに DNS サーバーの正しい IP があることを確認します。 cat /etc/resolv.conf nameserver YourDNSIP 取り急ぎの対応だとは思うが、とりあえずこの /etc/resolv.conf の設定を変えることで自分の場合がyum使えるようになりました。 以下手順です。 ①sudo権限で/etc/resolv.confを編集する $ sudo vi /etc/resolv.conf ②nameserver {IPアドレス}の部分を上書きする。（上書きしたら!wqで保存。） （変更前） nameserver {IPアドレス} （変更後） nameserver 8.8.8.8 nameserver 8.8.4.4 これで出来ない場合は上に貼った公式リファレンスを上から眺めていくと良いかもです。

対象環境＆読者 対象環境 AWS Google Authenticatorなど、スマホの認証アプリ 対象読者 MFAデバイスにGoogle Authenticatorなどのスマホ認証アプリを使用しているのに、スマホ故障や紛失、機種交換してMFAできないかた MFAログインできない！ ある日の出来事。久しぶりにルートユーザーでAWSのマネジメントコンソールへのログインを試みる。MFAコードを要求されたので、MFAデバイスのGoogle Authenticatorを起動。ところが、機種交換したためにGoogle Authenticatorが初期化されて使えないことに気付く。 やべー！　機種交換したら、Google Authenticatorに以前の設定が残ってないの？ 調べてみると、どうやらそういうものらしい。機種交換前に移行作業が必要とのこと。 機種変更をするので Google Authenticator のアカウントを移行したい だけれど、リカバリー方法はあるだろう。ネットを検索しつつ、リカバリーを試みた。 リカバリーを試みる こんどはMFAコードの入力画面で「MFAのトラブルシューティング」をクリックする。 トラブルシューティングページが表示されるので「別の要素を使用したサインイン」をクリックする。 ステップ1で「確認Eメールの送信」をクリックする。 登録したメールアドレスに「AWS Email Verification」というタイトルのメールが送られてくるので、メール内の「Verify your email address」をクリックする。 メールのリンクをクリックするとステップ2が表示されるので「すぐに連絡を受ける」をクリックする。 あとは電話が来るのを待つだけ。だけれど来ないし、画面には「完了できませんでした」の文字。ガーン！ このようになった原因は、国番号付きで電話をかけるときは先頭のゼロを省略するので、登録が間違っていたらしい。 電話番号：090-XXXX-XXXX 国番号付き：+81-90-XXXX-XXXX 登録すべき部分：90-XXXX-XXXX どうすればいいんだ、俺、？ AWSへ問い合わせ サポートへの問い合わせを決断。IAMユーザーはMFAを使っていなかったので、IAMユーザーでログインして問い合わせを起票。あとは待つだけ。 心待ちにしていると、申し訳なさそうな回答と共に専用の窓口を案内される。内部でスイッチできないのね...。コチラはサインイン不要です。 Lost or unusable Multi-Factor Authentication (MFA) device https://aws.amazon.com/forms/aws-mfa-support 上記リンクをクリックすると、以下のページが表示される。「I'm still having...」のほうをクリックする。最初は「Sign-in to AWS」をクリックして、普通のコンソールが表示されて意味不明で悩んだ。間違えないように。 「I'm still having...」をクリックすると、下に入力エリアが出現。これらを入力し、末尾の「Submit」をクリックして完了。 後ほどAWSから電話がかかってきて、個人認証を済ませるとMFAを無効にしてくれるとのこと。解除まで時間がかかるかもしれないと言われたが、すぐに解除完了のメールが来た。 これで問題は解決。パスワードログイン可能になっているので、MFAを再設定して完了だ。 MFAデバイス比較 https://aws.amazon.com/jp/iam/details/mfa/ MFAデバイスの設定ページ https://console.aws.amazon.com/iam/home?#security_credential 私みたいなライトユーザーに丁寧なサポートをありがとうございます。月に数万円以上使っているならまだしも、年間でもそれほど使っていないのに、こんな対応していたら大変そう。 教訓 機種変更するときは、MFAデバイスの情報をエクスポートするべし。もしくはMFAを一時的に無効にする MFAデバイス紛失に備えて、電話での認証が可能か確認しておこう もしくは、エクスポートしたQRコードのスクショを別の場所に保存していてもいいかもしれない（未検証） それでもダメなときは、上記の問い合わせフォームを使おう

EC2インスタンスへのログインは毎回忘れるので、メモ書き程度に貼っておきます。 EC2インスタンスへのログイン手順 ホームディレクトリに移動 ターミナル % cd ~ sshに移動 ターミナル % cd .ssh/ pemファイルの存在を確認 ターミナル % ls ターミナル % chmod 600 キーペア名.pem ターミナル % ssh -i キーペア名.pem ec2-user@作成したEC2インスタンスに紐付けたElastic IP

背景 GitHubにプッシュをした際、きちんと整形されているかどうか、実行エラーが出ないかなどの簡単な自動テストをしようと思った。その際、GitHub ActionsとECSが連携していることを知り、ECSでテスト実行しようと思った。しかし動作確認をしているうち、 GitHub側でエラーが出ていないのに、なぜタスクが実行されないのか （後ほど書くが、サービスのタスクの数を0に設定していたから） という問題にぶつかった。朝早くから何度も設定を見直して動作確認を繰り返したり、夜遅くまでうまくいかない原因を必死にググっていた。 そして昨日、ついにGitHub ActionsとECSの連携はWebアプリケーションを手軽にデプロイするサービスであることを知った。というか先輩から教えてもらった。その先輩はこのサービスを使ったことがないのにも関わらず、プッシュ時の自動テスト用ではないことを瞬時に見抜いた。そのときの自分はすごく無様だった・・・。せっかくいろいろ調べたしそのうち使うかもしれないので記事にしておく。 Webサイトのデプロイ 1. リポジトリを作成する GitHubに新しいリポジトリを作成する。 2. DockerFileを作成する デプロイ用のDockerfileを作成する。公式ドキュメントにあるDockerfileを用いる。 FROM ubuntu:18.04 COPY ./index.html /var/www/html/ COPY ./run_apache.sh /root/ RUN apt-get update && \ apt-get -y install apache2 && \ chmod 755 /root/run_apache.sh EXPOSE 80 CMD ["sh", "/root/run_apache.sh"] 以下のrun_apache.shとindex.htmlもDockerfileと同じ階層に入れておく。 run_apache.sh . /etc/apache2/envvars mkdir -p /var/run/apache2 mkdir -p /var/lock/apache2 /usr/sbin/apache2 -D FOREGROUND index.html <h1>Hello World!</h1> 以下の画像は現在のリポジトリの状態 3. GitHub Actions １．Actionsを選択 ２．Deploy to Amazon ECSを選択 ３．start commit を選択し、Commit new fileを選択 現在のリポジトリの状態 4. ECRにリポジトリを作成する こちらの記事を参考にリポジトリを作成する。 5. クラスター、タスク定義、サービスを作成する クラスター、タスク定義の作成 こちらの記事を参考に作成する。 サービスの作成 １．作成したタスク定義、クラスターを選択し、任意のサービス名を入力 ２．タスクの数を入力。これは常時いくつのタスクを実行状態に保つか、という値。1にすれば常時1つのタスクを実行状態にしてくれる。ただ、タスクの実行が終了すれば、そのタスクは停止する。その後、タスクの数1を保とうとして自動でタスクが実行される。 この値を0にしていると、GitHub Actionsでデプロイしてもタスクが実行されない ３．スケーリング これはサービス作成後に修正するが、今はデフォルト。 ４．サービス更新 4-1. 先ほど作成したサービスを選択し更新を選択する 4-2. 「サービスの必要数を調整する」を選択する 4-3. タスクの最大数を1にすることで、実行状態にあるタスクは高々1つになる。 こうしている間にもタスクがどんどん起動されている。リポジトリを作成しただけでイメージは格納されていないのでエラー終了している。 6. task-definition.json の作成 以下のようにJSON形式でタスク定義を見ることができる。これをコピペすればよいが、不要なキーが多くある。 以下のように必要なキーだけを記述する。 task-definition.json { "executionRoleArn": "arn:aws:iam::012345678912:role/ecsTaskExecutionRole", "containerDefinitions": [ { "logConfiguration": { "logDriver": "awslogs", "options": { "awslogs-group": "/ecs/git-task", "awslogs-region": "ap-northeast-1", "awslogs-stream-prefix": "ecs" } }, "image": "image:latest", "essential": true, "name": "container" } ], "memory": "512", "family": "git-task", "requiresCompatibilities": [ "FARGATE" ], "networkMode": "awsvpc", "cpu": "256" } 7. アクセスキーID・シークレットアクセスキーの登録 こちらに作成方法が書いてある。AWS_ACCESS_KEY_ID 、AWS_SECRET_ACCESS_KEY を登録する。 デバッグを行うために次の2つのシークレットを作成しておく。ACTIONS_RUNNER_DEBUG、ACTIONS_STEP_DEBUG の値をtrueで登録する。参考記事はこちら。 Settings → Secrets → Name, Valueを入力 という流れ。Valueに認証情報を貼り付ける。 8. GitHub Actions aws.yml の編集 以下5つのキーを書き換える。 aws-region: ap-northeast-1 ECR_REPOSITORY: my-repo container-name: container service: git-service cluster: git-test 後はpush時にデプロイできるように以下の部分を修正する。 修正前 on: release: types: [created] 修正後 on: push: branches: [main] ↑ mainにはどのブランチをデプロイするか適宜修正する。 これをpushすれば、早速デプロイが始まる。成功すれば以下のように緑のチェックが表示される。 タスクのパブリックIPに80ポートでアクセスし、デプロイを確認する。（セキュリティグループのインバウンドルールに、自分のIPアドレスを登録する） 参考記事

今回はとあるホームページ（シングルページ・静的ページ）をAWSの S3 Route53 を使ってwebサイトを構築し、独自ドメインでアクセスすると言うことをやる。 まず、 AWSのS3でバケットを作成する。 ※バケット名は取得するドメイン名と完全一致させること その後、バケットに対象のファイル関連ぶち込む。 アクセス許可を全て解除して、静的ウェブサイトホスティングを編集 ・有効にする 静的ウェブサイトをホストする その後、バケットポリシーを編集 { "Version": "2012-10-17", "Statement": [ { "Sid": "PublicReadGetObject", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::ドメイン名/*" } ] } Route53でドメインの購入 バケット名と合わせること。 ホストゾーンを作成する。レコードを作成して、エイリアスを有効にして トラフィックのルーティング先をバケットを作成したリージョンを選択。 S3のエンドポイントを選択。 レコードを作成。 通常ならこれで独自ドメインでのサイトへのサクセスが可能になる。 だが自分の場合は『そうは問屋がおろしてくれなかった』 なぜか、ドメインでアクセスしても、アクセスができない。 アクセス権限がないのではなく、そもそもアクセス先が存在しないと言うことだ このサイトにアクセスできませんーーーーーー.com にタイプミスがないか確認してください。 DNS_PROBE_FINISHED_NXDOMAIN もしここまでの症状と一致してる人はほぼ１００%私と同じ現象だと思うので whoisで対象のドメインを検索する。 その後、NSの対象URLが4つあるのでそこを探して欲しい。 Name Server:　に続く部分である。 その後それと、route53の登録したドメインという項目から 登録済みドメインをクリック。 ネームサーバーと先ほどwhoisで検索をかけたURLと一致するか確認。 私の場合、ここが異なっていた。 もちろん、実際whoisで検索したものが正しいネームサーバー名である。 なのでroute53で登録してるネームサーバーを編集して一致させることで正しく起動するようになる。