Category: AWS

AWS Organizationsで作った環境でVPCを作っていく

作業の流れ AWS OrganizationでOrganization Unit ( OU )作成、AWS Organization 内で AWSアカウントも作成 VPC作成、サブネットを各AZごとに合計3つ作成 VPC内でインターネットゲートウェイ作成, 作成したVPCに紐付け AWS、アカウント作成直後のネットワーク設定 実作業 AWSの具体的なリソースは省略しています。得られた値で読み替えてください。 VPC作成 プロファイルは都度、変更してください –cidr-block は 既存サブネットと被らないように取得してください vpcのタグ名は都度、変更する CLIでの作成はここが非常に参考になります aws ec2 --profile test-site create-vpc --cidr-block "172.37.0.0/16" --tag-specifications "ResourceType=vpc,Tags=[{Key=Name,Value=prod}]" { "Vpc": { "CidrBlock": "172.37.0.0/16", "DhcpOptionsId": "dopt-08f0bf2e614f696d8", "State": "pending", "VpcId": "vpc-04d******" "OwnerId": "*************", "InstanceTenancy": "default", "Ipv6CidrBlockAssociationSet": [], "CidrBlockAssociationSet": [ { "AssociationId": "vpc-cidr-assoc-", "CidrBlock": "172.37.0.0/16", "CidrBlockState": { "State": "associated" } } ], "IsDefault": false, "Tags": [ { "Key": "Name", "Value": "prod" } ] } } また上記のCLIで作成した際の 「 “VpcId”: “vpc-? Read more...

AWS Organizations関連のメモ

AWS Organizations でアカウント管理してみる - ユニファ開発者ブログ 久しぶりに作業した時には、ざっと目を通す AWS Organizations の用語と概念 - AWS Organizations 手順 ログイン https://console.aws.amazon.com/organizations/home?region=ap-northeast-1#/accounts [ アカウントの追加 ]->[ アカウントの作成 ] フルネーム: kaoru-inoue Eメール: kaoru-inoue@hoge.com IAM ロール名: OrganizationAccountAccessRole [ 作成 ]をクリック ログイン https://console.aws.amazon.com/organizations/home#/accounts [ Organize account ]をクリック、組織を作成する 組織を作成する [ Create organizational unit ]( [ 新規組織単位 ] )をクリック。 組織名を入力。ハイフンを利用可能だった。使わなくても良いが。 アカウント( というかOrganization のアカウント )の作成 [ Account ]->[ Add account ]->[ Create account ] Read more...

Dockerイメージの検証、更新する手順

できればインフラ構成についてもコード化したいため、CodeBuildのbuildspecでECSの設定を記述/更新しています。 このため、ECSの設定画面でポチポチと変更、検証することも可能ですが、Githubへのpush、CodeBuildで更新がかかると、ECSへの変更も元に戻ります。 (検証のために、ちょっとだけECS側で変更するのは無害です) 恒久的な変更はCodeBuild側へ変更するようにしましょう。 下記の手順はローカルでDockerイメージをダウンロードして検証する方法です。 「こうすると効率が良かった」というレベルのものです。 作業の流れ ECRからイメージダウンロード Mac上でコンテナを起動し、いろいろ検証( Dockerfileに必要な変更の検討など ) 必要な修正が決まったら、Githubのtestブランチにpush Githubの testブランチへpushされるとCodeBuildでdocker buildが始まり、ECRにpushされる ECRのDockerレポジトリのイメージIDをメモ ECSで起動しているコンテナを変更して動作確認を行う という流れになります。 イメージをローカルにダウンロードする プライベートなDockerレポジトリ(ECR)への認証を済ませる必要があります 認証情報の取得 eval (aws ecr get-login –profile=profile名 –no-include-email –region ap-northeast-1) 手元で実行 (2019/02/22の内容で、環境変数などは将来的に変更する可能性があります) docker run -p 10022:22 -e GITHUB_ENV=env25 -e AWS_ACCESS_KEY_ID=XXXXXXXXXXX -e AWS_SECRET_ACCESS_KEY=YYYYYYYYYYYYYY -it 11111111.dkr.ecr.ap-northeast-1.amazonaws.com/image-name:latest /bin/bash -p 10022:22 : リモートにSSHログインできるようにdocker内にsshdを立てました(将来的にはssmに切り替えたいですが)、sshdがlistenするポートが22番ポートなのですが、これをMacの10022にポートフォワードしています -e GITHUB_ENV=env25 : ECSで「どの環境を更新するか」を指定しています(Githubの「どのブランチを読み込むのか?」にも使っています) -it : Dockerコンテナに入ってCLIを利用したい時に使うオプションです 111111.dkr.ecr.ap-northeast-1.amazonaws.com/php-fpm:latest : 最新イメージの場合はlatestを指定しますが、トラブルシューティングの時には必要なタグを指定してください /bin/bash : Dockerコンテナで実行するプログラムを指定します。今回はCLIをつかって調査したいので、/bin/bashを利用しています( /bin/bashをインストールしていないコンテナの場合は /bin/ash をお使いください ) 検証が終わって「開発サーバ郡の標準のDockerイメージとして使いたくなった」ら ECSで起動する際のdockerイメージですが、タスク定義で起動するDockerイメージのタグをstable 11111.dkr.ecr.ap-northeast-1.amazonaws.com/php-fpm:stable としています(デフォルトはlatestです) Read more...

ECS開発環境の時刻を変えたい

背景 開発環境の時刻を変えたい時があります。 「その時刻になった時の振る舞いを確認したい」 「ある時間帯をターゲットにした開発を行いたい」 などです。 そういった開発の時だけ夜間に来る、というのは現実的ではないので、手軽に開発環境の時刻を変える方法があると便利です。 EC2 Linuxサーバですとdateコマンドなどで時間を変更できます( https://qiita.com/na0AaooQ/items/af6b853faf32c58c21d3 ) ただECS Fargate環境だと( システム時刻の変更に管理者権限が必要なため )上記の方法が使えません。 このため環境変数で開発環境のロケールを変更できるようにしてみました。 Dockerコンテナの起動、複数コンテナの連携方法などの設定などはタスク定義に行います。「タスク」という単位でサーバが起動します。 サービスという概念もあり、タスクが含まれます( 同じタスクを3セット立ち上げたりします)。 サービスにはロードバランサーとの接続など「Dockerと接続する外界」といった設定項目が含まれます。 ※ この方法で時刻をずらした場合、なにかデプロイされる度に、設定は初期化されます。 なにか新しいリビジョンのものがCI経由でデプロイされると、この環境変数の設定は初期化されます。 手順 AWS Webコンソールにログイン AWS_Fargateで目的の環境のタスク定義をここから探す( env27とか、そういったものです ) 最新のタスク定義をクリック [新しいリビジョンの作成 ] [コンテナの定義]のコンテナ[ nginx ]と[ php-fpm ]のなど変更をします。 `片方だけだとエラーがでるはずです。 [環境]の[Key]に環境変数名 TIMEZONE を入力、 値として任意のタイムゾーン( 例えば America/Argentina/Buenos_Aires のようなもの )を入力します。 ※ この『America/****』の文字列はスラッシュを含む全てです。 この地域はもうすぐ朝が来てしまう などで、他の地域を設定したい場合、 地図と時差を確認 して このIBMのページの文字列をコピペします。 インフラへの設定が反映されたかを確認するのは良い習慣です。確認する場合は、設定したコンテナをクリック、環境変数が設定されているかで確認できます。 [ 作成 ]をクリック *これでできた新しいリビジョンのタスク定義で、サービスを再起動します 時刻のロケールを戻す 2つの方法があります。 このページの[手順]の[新しいリビジョンの作成]のクリック後、 上記同様、nginxとphp-fpmの2つのコンテナの環境変数を変更します。 [コンテナの定義]のコンテナ[ nginx ]と[ php-fpm ]のそれぞれに対して設定を行います。 [環境]の[Key]のTIMEZONEの箇所で Read more...

ECS Fargate を CLIで操作

ECSのサービス設定、つくる作業が煩雑なので、CLIで自動化できないか検討。 aws ecs create-service --cluster example-dev-20181030-1 \ --service-name env36\ --task-definition env36\ --desired-count 1\ --launch-type FARGATE\ --deployment-configuration maximumPercent=200,minimumHealthyPercent=100\ --network-configuration "awsvpcConfiguration={subnets=[subnet-111111111111,subnet-222222222222,subnet-33333333333],securityGroups=[sg-4444444444],assignPublicIp=DISABLED}"\ --deployment-controller type=ECS aws cliのecsのcreate-serviceのオプションは多いのでCLIで作るのを想定してる感じある。 Read more...

AMIについての雑多なメモ

基本的に「AWSによる管理」のポリシーだけで構築可能ならそうする ただ 「AWSによる管理」のポリシー だけだと、残念だが噛み合わない(権限が大きすぎる)のも多数あるので、自前で用意する。 `ポリシ 会社によっては、より厳密には「特定のリソースへアクセスできる、できない」もポリシーを作るか?という観点があるが、これはAWSアカウントレベルで分離する形の方が運用コストが下げられるので、避けていきたい。 ロールの作成方針は書く(方針なりIAMロール作成手順はあった方が効率良い、再利用性が高まる)。だが、台帳は作らないレベル 「EC2につけられるIAMロールはひとつだけ」という制限がある。複数のポリシーを一つのロールにまとめるように作る 何かポリシーを作ったら下記に追加する( 作成した時の意図とユースケースくらい ) 作成したロールについては、現状、不要( ロールは、それぞれの管理画面、例えばEC2やlambda、RDSなどの管理画面側で確認できるので) 開発と本番は共通のポリシー。AWSアカウントは異なるので、アカウントの部分は「*」で記述して共通に使えるようにする。 EcsExec ECS Fargate に AWS SSM の機能を用いて直接シェルを起動するのに作成した ECS Fargate 用に既に作ってあったロール、 ecsTaskExecutionRole にポリシーを追加する想定 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ssmmessages:CreateControlChannel", "ssmmessages:CreateDataChannel", "ssmmessages:OpenControlChannel", "ssmmessages:OpenDataChannel" ], "Resource": "*" } ] } Billing 経理情報を確認できるように作成 https://recipe.kc-cloud.jp/archives/6020 この情報を参考にした { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "aws-portal:ViewBilling", "aws-portal:ViewUsage" ], "Resource": "*" } ] CloudWatchLogsWrite 意図: ECSでサービスを作ったらCloudWatch logsに自動的にストリームを作成させたかった。 ユースケース: ECSのサービスを作った際に、自動的にログストリームを作らせたかった。ほか「自動的にログストリームを作成させたい」場合に使う { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Resource": [ "arn:aws:logs:ap-northeast-1:111111111111:log-group:/aws/codebuild", "arn:aws:logs:ap-northeast-1:111111111111:log-group:/aws/codebuild:*" ], "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ] } ] } ECSServiceRolePolicy 意図: ECSでサービスを動作させるのに必要 ユースケース: ECSのサービスを作る際に、CloudWatchLogsWriteとセットで使う { "Version": "2012-10-17", "Statement": [ { "Sid": "ECSTaskManagement", "Effect": "Allow", "Action": [ "ec2:AttachNetworkInterface", "ec2:CreateNetworkInterface", "ec2:CreateNetworkInterfacePermission", "ec2:DeleteNetworkInterface", "ec2:DeleteNetworkInterfacePermission", "ec2:Describe*", "ec2:DetachNetworkInterface", "elasticloadbalancing:DeregisterInstancesFromLoadBalancer", "elasticloadbalancing:DeregisterTargets", "elasticloadbalancing:Describe*", "elasticloadbalancing:RegisterInstancesWithLoadBalancer", "elasticloadbalancing:RegisterTargets", "route53:ChangeResourceRecordSets", "route53:CreateHealthCheck", "route53:DeleteHealthCheck", "route53:Get*", "route53:List*", "route53:UpdateHealthCheck", "servicediscovery:DeregisterInstance", "servicediscovery:Get*", "servicediscovery:List*", "servicediscovery:RegisterInstance", "servicediscovery:UpdateInstanceCustomHealthStatus" ], "Resource": "*" }, { "Sid": "ECSTagging", "Effect": "Allow", "Action": [ "ec2:CreateTags" ], "Resource": "arn:aws:ec2:*:*:network-interface/*" } ] } EC2RoleforSSM EC2にAWS SSMを用いてsshできるようにロールを作成した。 AWSの管理ロールである、AmazonEC2RoleforSSM をそのまま割り当てた( AmazonEC2RoleforSSM をダイレクトにEC2のIAMロールに割り当てる事はできなかった ) Read more...

Athenaを簡単に使ってみる

Athenaは「s3にあるファイルをSQLで検索できる」というサービスになる。 既にs3にファイルの形で置かれている場合はAthenaで集計が可能だが、 コストが読み込んだファイルに応じてかかるので、なんらかの形で課金を抑える施策が必要。 日付でログを分けるような運用を考えてみる。 調査の流れ 下記がまとまっていて分かりやすい。 Amazon Athenaではじめるログ分析入門 - Qiita 上記で紹介されていた、下記のページ Amazon Kinesis Firehose, Amazon Athena, Amazon QuickSightを用いたVPCフローログの分析 | Amazon Web Services ブログ も、Athenaを理解するのに役立つ、ただ… ただnginxログ解析のために、 イベントを受けるlambda -> kinesis firehouse -> s3 -> Athena は冗長ではないか… もうちょっとラクはできないのか AWS Glue ? GlueはRedshift, RDS, S3をソースにできる。ただpython, scalaで記述するらしい。 私がソースにしたいのは、CloudWatchなのだ。 が、考えてみると、CloudWatch -> s3へエキスポートできれば良い。方法はあった。 Amazon S3 へのログデータのエクスポート - Amazon CloudWatch ログ 割とシンプルにありそう。たぶんAPIもあるだろう。 で、なぜkinesis firehoseか?を考えると、こちらはリアルタイム解析なのだと思う。 今回の要件については…. redashで解析できれば良いので日時で良かろう。 ただディレクトリ構造については悩ましい。 s3に吐き出すディレクトリ構造については、他のエントリを参考にしよう。 Amazon Kinesis Firehose, Amazon Athena, Amazon QuickSightを用いたVPCフローログの分析 | Amazon Web Services ブログ Read more...

aws-cliが参照する環境変数

環境変数 AWS CLI Configuration Variables — AWS CLI 1.7.38 documentation CLIの初期設定について 認証情報とコマンド補完 TASK NOTES ||対象||設定ファイル変数||環境変数||オプション ||アクセスキーID||aws_access_key_id|| AWS_ACCESS_KEY_ID|| - ||シークレットアクセスキー||aws_secret_access_key|| AWS_SECRET_ACCESS_KEY|| - ||リージョン||region||AWS_DEFAULT_REGION||–region ||出力||output||AWS_DEFAULT_OUTPUT||–output ||プロファイル||profile|| AWS_DEFAULT_PROFILE|| –profile ||設定ファイル||-|| AWS_CONFIG_FILE|| - ||トークン||aws_security_token||AWS_SECURITY_TOKEN||- 変数が参照される順序 環境変数 AWS認証情報 ~/.aws/credentials CLI構成ファイル ~/.aws/config インスタンスプロファイルの認証情報 でも『環境変数を参照するプログラム』は沢山ある… という悩みを解決しそうな AWSを操作(AWS CLIに限らない)する場合の環境変数設定作業を軽くする Read more...

CloudWatch logsのログをinsightで検索

ログについては、ひとまずCloudWatch logsに投げ込む運用にしています(注1 このCloudWatch logsを高速に検索できるインサイトをCLIから使う紹介です( WEBでの使い方については[ CloudWatch ]->[ インサイト ]でいろいろ試していただきたいです ) 障害調査の場合、どのみちgrepすることになるのでCLIでの手順も残しておきます。 ログ取得 https://docs.aws.amazon.com/ja_jp/AmazonCloudWatchLogs/latest/APIReference/API_StartQuery.html --start-time 開始時刻をunixtime --end-time 終了時刻をunixtime --query-string 参考 https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/logs/CWL_QuerySyntax.html クエリ(フィルタリング)について 検索する際の方法 limit 10 とか。 このためにインサイトを使っていると言えますが正規表現 | filter @message like /access_token=/ クエリ例 参考: サンプルクエリ - Amazon CloudWatch Logs nginxのログのみを表示する | filter @logStream LIKE /nginx/ ロードバランサからのヘルスチェックを除外する | filter @message NOT LIKE /ua:ELB-HealthChecker/ ステータスコードが500番台のもののみを表示する | filter @message LIKE /status:5\d+/ ログをパースして変数にセットする | parse @message "time:*host:*forwardedfor:*req:*status:*size:*referer:*ua:*reqtime:*cache:*runtime:*vhost:*userid:*" as time, host, forwardedfor, req, status, size, referer, ua, reqtime, cache, runtime, vhost, userid クエリ実行( ログ検索は時間がかかるため、後で別途getする必要があります) bash環境(dateコマンドはbrewのcoreutilsを使用) Read more...

CloudWatchでアラートを設定する

CloudWatchのアラートを設定する方法 ここでは各環境向けにCPUとメモリ使用率のアラートを設定する方法を共有します。以下で説明する alarms.sh、 alarm_mem_template.json、 alarm_cpu_template.json の3つのファイルを用いて作業します。 alarms.sh 各ECSサービスのアラームの設定をするShell Scriptです。 alarms.shの名前で以下の内容のファイルを作成します。 このスクリプトでは現在作成されている環境を全て取得し、そのそれぞれに対して、すでに同名のアラームがある場合には更新、 存在しない場合には新規にアラームを作成します。 そのため新しい環境を追加し、CPUおよびメモリ使用率のアラートを設定したい度に実行する必要があります。 #!/bin/bash services=$(aws ecs list-services --cluster=test-dev-20181030-1 | jq -r .serviceArns[] | sed s#.*/##g) THRESHOLD_MEM=70 THRESHOLD_CPU=70 for service in ${services[@]}; do SERVICE=$service THRESHOLD_MEM=$THRESHOLD_MEM envsubst < ./alarm_mem_template.json > alarm_mem.json SERVICE=$service THRESHOLD_CPU=$THRESHOLD_CPU envsubst < ./alarm_cpu_template.json > alarm_cpu.json aws cloudwatch put-metric-alarm --cli-input-json file://alarm_mem.json aws cloudwatch put-metric-alarm --cli-input-json file://alarm_cpu.json done 使い方 alarms.sh を作成したディレクトリに alarm_mem_template.json と alarm_cpu_template.json をそれぞれ以下の内容で作成します。 alarm_mem_template.json { "EvaluationPeriods": 3, "TreatMissingData": "missing", "ComparisonOperator": "GreaterThanThreshold", "ActionsEnabled": true, "AlarmActions": [ "arn:aws:sns:ap-northeast-1:811111111111:alert2Slack" ], "OKActions": [ "arn:aws:sns:ap-northeast-1:811111111111:alert2Slack" ], "Namespace": "AWS/ECS", "Period": 60, "Threshold": ${THRESHOLD_MEM}, "AlarmName": "Memory Utilization of ${SERVICE} alert to Slack", "Dimensions": [ { "Name": "ClusterName", "Value": "test-dev-20181030-1" }, { "Name": "ServiceName", "Value": "${SERVICE}" } ], "DatapointsToAlarm": 3, "Statistic": "Average", "MetricName": "MemoryUtilization" } alarm_cpu_template. Read more...