AWSの情報をまとめる
今まで fargate で service を動かせていたが、platform 1.4 では動かせないことがあった。その対処法を紹介。
pseudoTerminal option があるが、falase だと起動した後に停止してしまう。解決策としては、
pseudoTerminal を false から true にすること。
そもそも pseudoTerminal とは擬似ターミナル。
Docker Remote API の コンテナを作成する際、セッションの TTy にマッピングして docker run にマッピングするオプション。
1.3 まではこの設定が false でも動かすことができたが、1.4 ではこれを true にしないと動かすことができないようだ。
fargate でサービスを運用していて、夜間サービスを停止したい時がある。オートスケールの設定を流用することで、夜間停止を行うことができる。
オートスケール設定
aws application-autoscaling \
register-scalable-target \
--service-namespace ecs \
--resource-id service/{cluster-name}/{service-name} \
--scalable-dimension ecs:service:DesiredCount \
--min-capacity 0 \
--max-capacity 1停止スケジュール
(スケジューリング機能を使い、MinCapacity を 0 にする)
aws application-autoscaling put-scheduled-action \
--service-namespace ecs \
--resource-id service/{cluster-name}/{service-name} \
--scheduled-action-name poweroff-hogehoge \
--schedule "cron(00 10 ? * * *)" \
--scalable-dimension ecs:service:DesiredCount \
--scalable-target-action MinCapacity=0,MaxCapacity=0起動スケジュール
aws application-autoscaling put-scheduled-action \
--service-namespace ecs \
--resource-id service/{cluster-name}/{service-name} \
--scheduled-action-name poweron-hogehoge \
--schedule "cron(30 0 ? * MON-FRI *)" \
--scalable-dimension ecs:service:DesiredCount \
--scalable-target-action MinCapacity=1,MaxCapacity=1AWS では Active Directory / LDAP アプリケーションは大きく３つ存在している。全ての説明は Classmethod 社の記事がわかりやすかったので引用する。
１コマンドで確認することができる。
aws --profile stg elbv2 describe-load-balancers --load-balancer-arns arn:aws:elasticloadbalancing:ap-northeast-1:01234567:loadbalancer/net/tsukadanlb/a1b2c3d4e5結果は以下の通り
{
"LoadBalancers": [
{
"LoadBalancerArn": "arn:aws:elasticloadbalancing:ap-northeast-1:708179590705:loadbalancer/net/tsukadanlb/a1b2c3d4e5",
"DNSName": "tsukada-nlb-a1b2c3d4e5.elb.ap-northeast-1.amazonaws.com",
"CanonicalHostedZoneId": "a1b2c3d4e5",
"CreatedTime": "2019-06-06T11:01:01.615000+00:00",
"LoadBalancerName": "tsukada-nlb",
"Scheme": "internal",
"VpcId": "vpc-a1b2c3d4e5",
"State": {
"Code": "active"
},
"Type": "network",
"AvailabilityZones": [
{
"ZoneName": "ap-northeast-1c",
"SubnetId": "subnet-a1b2c3d4e5",
"LoadBalancerAddresses": []
},
{
"ZoneName": "ap-northeast-1a",
"SubnetId": "subnet-a1b2c3d4e5",
"LoadBalancerAddresses": []
}
],
"IpAddressType": "ipv4"
}
]
}CodeDeploy で Step 3 で失敗することがある。
The overall deployment failed because too many individual instances failed deployment, too few healthy instances are available for deployment, or some instances in your deployment group are experiencing problems.上記エラーの対処をまとめる。
原因を探っていくと、AllowTraffic で 1時間以上も時間がかかって失敗していた。
この処理の Script の中身を確認するものの何も書かれていない。
この原因について調査し、原因がわかったので備忘録として記載すると、
これは LoadBalancer から新しくDeploy されたインスタンスへのトラフィックが流れない事が原因だった。
具体的に言うと LoadBalancer から新インスタンスへの health check が通っていない状況。
LoadBalancer の health check を修正する事で deploy が成功するようになった。
パーセントと、パーセンタイルを比べるとわかりやすい。
一般的な パーセントの場合は、率をあらわす。
50パーセントは全体に対し、半分がという意味になる。
一方でパーセンタイルは似たようでちょっと違う。
全体を 100個に区切り、
小さい方順にソートして 何番目にあるかを表現されている。
p50 (50パーセンタイ)ルの場合は、
下から 50/100に位置しているデータ。
p90 (90パーセンタイル)の場合は、
下から 90/100に位置しているデータ。
p95 (95パーセンタイル)の場合は、
下から 95/100に位置しているデータ。
となる。
機械学習ではなく xray でもこのパーセンタイルを採用しているが、おそらく理由は、
それより遅い異常値を弾くことで精度の高い統計情報にするためだと考える。
CloudWatch の Dimensions を知りたいが、
ブラウザで AWS のコンソール画面に入っても、Dimensions を見ることはできない。
この時の確認の仕方を紹介。
コンソールからNamespaces を調べる。
今回 API gateway 。
クリックしていくと、 Metric Name を選ぶので任意のものを選ぶ。
今回は Count
上記メモとしてひかえ、aws cli を投げる
aws cloudwatch list-metrics
--namespace AWS/ApiGateway
--metric-name Count
以下のようなレスポンスが返ってくる
{
"Metrics": [
{
"Namespace": "AWS/ApiGateway",
"MetricName": "Count",
"Dimensions": [
{
"Name": "ApiName",
"Value": "Tsukada API"
},
{
"Name": "Resource",
"Value": "/info/name/_search"
},
Dimensions を確認することができる
CloudWatch logs から lambda subscription-filter しようとした際、以下のようなエラーになった。
An error occurred (InvalidParameterException) when calling the PutSubscriptionFilter operation: Could not execute the lambda function. Make sure you have given CloudWatch Logs permission to execute your function.
対処法は以下の通り lambda に対しパーミッションを追加する必要がある
aws --profile mfa lambda add-permission --function-name "lambda function name" \ --statement-id "lambdapermission-xxxxxxxxx-uniq" \ --principal "logs.ap-northeast-1.amazonaws.com" \ --action "lambda:InvokeFunction" \ --source-arn "arn:aws:logs:ap-northeast-1:1234567890:log-group:/aws/lambda/hogehoge-lambda-function:*" \ --source-account "1234567890" --region=ap-northeast-1
以下の一行のみ。
yum install python3
実施結果は以下の通り
# yum install python3 Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.team-cymru.com * epel: mirror.steadfastnet.com * extras: mirrors.liquidweb.com * remi-safe: mirror.team-cymru.com * updates: centosz6.centos.org Resolving Dependencies --> Running transaction check ---> Package python3.x86_64 0:3.6.8-13.el7 will be installed --> Processing Dependency: python3-libs(x86-64) = 3.6.8-13.el7 for package: python3-3.6.8-13.el7.x86_64 --> Processing Dependency: python3-setuptools for package: python3-3.6.8-13.el7.x86_64 --> Processing Dependency: python3-pip for package: python3-3.6.8-13.el7.x86_64 --> Processing Dependency: libpython3.6m.so.1.0()(64bit) for package: python3-3.6.8-13.el7.x86_64 --> Running transaction check ---> Package python3-libs.x86_64 0:3.6.8-13.el7 will be installed --> Processing Dependency: libtirpc.so.1()(64bit) for package: python3-libs-3.6.8-13.el7.x86_64 ---> Package python3-pip.noarch 0:9.0.3-7.el7_7 will be installed ---> Package python3-setuptools.noarch 0:39.2.0-10.el7 will be installed --> Running transaction check ---> Package libtirpc.x86_64 0:0.2.4-0.16.el7 will be installed --> Finished Dependency Resolution Dependencies Resolved ============================================================================================================================================================================================================ Package Arch Version Repository Size ============================================================================================================================================================================================================ Installing: python3 x86_64 3.6.8-13.el7 base 69 k Installing for dependencies: libtirpc x86_64 0.2.4-0.16.el7 base 89 k python3-libs x86_64 3.6.8-13.el7 base 7.0 M python3-pip noarch 9.0.3-7.el7_7 updates 1.8 M python3-setuptools noarch 39.2.0-10.el7 base 629 k Transaction Summary ============================================================================================================================================================================================================ Install 1 Package (+4 Dependent packages) Total download size: 9.5 M Installed size: 48 M Is this ok [y/d/N]: y Downloading packages: (1/5): libtirpc-0.2.4-0.16.el7.x86_64.rpm | 89 kB 00:00:01 (2/5): python3-3.6.8-13.el7.x86_64.rpm | 69 kB 00:00:01 (3/5): python3-setuptools-39.2.0-10.el7.noarch.rpm | 629 kB 00:00:00 (4/5): python3-pip-9.0.3-7.el7_7.noarch.rpm | 1.8 MB 00:00:00 (5/5): python3-libs-3.6.8-13.el7.x86_64.rpm | 7.0 MB 00:00:00 ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Total 3.7 MB/s | 9.5 MB 00:00:02 Running transaction check Running transaction test Transaction test succeeded Running transaction Installing : libtirpc-0.2.4-0.16.el7.x86_64 1/5 Installing : python3-setuptools-39.2.0-10.el7.noarch 2/5 Installing : python3-libs-3.6.8-13.el7.x86_64 3/5 Installing : python3-3.6.8-13.el7.x86_64 4/5 Installing : python3-pip-9.0.3-7.el7_7.noarch 5/5 Verifying : python3-pip-9.0.3-7.el7_7.noarch 1/5 Verifying : python3-3.6.8-13.el7.x86_64 2/5 Verifying : libtirpc-0.2.4-0.16.el7.x86_64 3/5 Verifying : python3-setuptools-39.2.0-10.el7.noarch 4/5 Verifying : python3-libs-3.6.8-13.el7.x86_64 5/5 Installed: python3.x86_64 0:3.6.8-13.el7 Dependency Installed: libtirpc.x86_64 0:0.2.4-0.16.el7 python3-libs.x86_64 0:3.6.8-13.el7 python3-pip.noarch 0:9.0.3-7.el7_7 python3-setuptools.noarch 0:39.2.0-10.el7 Complete!
pip3 も一緒にインストールされる
ECS のタスクスケジューリングで
FailedInvocations が発生するのは、CloudWatch eventsでの実行ロールに権限が足りないから。その対処方法をまとめる。
I AM ロールを作成する。
今回は ecsEventsRole という名前にした。
作成したロールの信頼関係を編集。
cloudwatch events から実行できるよう権限を付与。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
以下の通り貼り付ける。
作成したroleに`AmazonEC2ContainerServiceEventsRole` ポリシーをアタッチする。
今回作成した ecsEventsRole を割り当てる。
CloudWatch メトリクスを確認すると、
FailedInvocations が解消し Invocations になった。
