今まで 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"
}
]
}NLB を削除できない場合、
API Gateway に VPC links の設定が残っている場合が多い。
API Gateway で VPC links で NLB を登録していたが、先にその設定を解除（削除）する必要がある。
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
docker では entrypoint が設定されていると、
docker の中に入るために 起動シェルを変更したとしても
entrypoint の引数として認識されてしまう事がある。
entrypoint を変更する事で、コンテナ内に入る事が可能になる。
“`
docker run -it --rm --entrypoint /bin/bash tsukada/image