vague memory

うろ覚えを無くしていこうともがき苦しむ人の備忘録

Backlog 課題の文字数制限

公式に記載を見つけられなかったのでメモ。

  • 件名は1文字以上255文字以下で入力してください。
  • 詳細は100,000文字以下で入力してください。
  • コメントは50,000文字以下で入力してください。

参考

その他制限等

Datadog AWS Integration リージョン除外設定

Datadog AWSインテグレーション設定にいつの間にか機能追加されていたのでメモ。

※ 2020/07 現時点ではUIからの参照・更新はサポートされていないようです

excluded_regions
An array of AWS regions to exclude from metrics collection

IAM Role 等で明示的に拒否しない限りは、全リージョンを参照していたと思われますが、 設定が可能になった事により不要なリージョンへのAPIリクエスト数削減が見込めそうです。

尚、 Terraform の Datadog Providor では既に機能追加されています。

    excluded_regions = ["us-east-1", "us-west-2"]

Datadog hoge before 関数はエイリアス

Datadog のグラフ作成時に過去情報を参照する関数が用意されています。

  • hour_before : 1時間前
  • day_before : 1日前
  • week_before : 7日前
  • month_before : 28日前(4週間≒1ヶ月)

f:id:htnosm:20200719152120p:plain

これらは期間固定なため、2日前とか任意期間での指定はできないものかと調べたところ、公式ドキュメントにまんまの記載がありました。

timeshift(<METRIC_NAME>{*}, -<TIME_IN_SECOND>)

hoge_before は timeshift 関数のエイリアスのようです。
秒数指定で任意の日時のグラフ表示が可能です。

注意点として、 UI上でサジェストされないため、直入力の必要があります。

f:id:htnosm:20200719152128p:plain

AWS CDK [aws-lambda] log_retention設定

AWS CDK (AWS Cloud Development Kit) に触れた際の備忘録
python 成分多め

[aws-lambda] log_retention 設定用のLambda Function が作成される

設定は数値ではなく、定数を使う必要がある。(例: 3 ではなく、 THREE_DAYS 等)

myFunction という Lambda Function に log_retention を設定した場合、

        fn = aws_lambda.Function(self, 'myFunction',
          code=aws_lambda.Code.asset('lambda'),
          log_retention=aws_logs.RetentionDays.ONE_WEEK,
        );

LogRetention 設定用の LambdaFunction / IAM Role / Log Group が作成される。

Logical ID PhysicalID Type
LogRetention〜 myFunction-LogRetention〜 AWS::Lambda::Function
LogRetention〜ServiceRole〜 myFunction-LogRetention〜 AWS::IAM::Role
LogRetention〜ServiceRoleDefaultPolicy〜 myFun-LogR-〜 AWS::IAM::Policy

deploy 時に LogRetention 設定用の LambdaFunction が実行され、 その LogGroup が作成される。

  • CloudWatch Log Groups
    • /aws/lambda/myFunction-LogRetention〜
      • LogRetention = 1 day

AWS CDK [aws-events] 定期cron式

AWS CDK (AWS Cloud Development Kit) に触れた際の備忘録
python 成分多め

[aws-events] 定期cron式で指定するのは day/week_day のいずれか

時間 曜日 意味
0/15 * * * ? * 15 分ごとに実行
        rule = aws_events.Rule(
            self, "Rule",
            schedule=aws_events.Schedule.cron(
                minute='0/5',
                hour='*',
                day='*',
                month='*',
                #week_day='?',
                year='*'),
            enabled=False,
        )

両方指定は不可

dayとweek_dayの両方指定すると下記エラーとなる。

jsii.errors.JSIIError: Cannot supply both 'day' and 'weekDay', use at most one

? の明示指定は不要

day を指定(*)した場合、week_day に ? が入る。

    Type: AWS::Events::Rule
    Properties:
      ScheduleExpression: cron(0/15 * * * ? *)

dayに ? を指定すると、 dayとweek_dayが ? となり、

    Type: AWS::Events::Rule
    Properties:
      ScheduleExpression: cron(0/15 * ? * ? *)

書式不正で CREATE_FAILED となる。

Parameter ScheduleExpression is not valid. (Service: AmazonCloudWatchEvents; Status Code: 400; Error Code: ValidationException;

AWS CLI v2 で alpine glibc 問題に遭遇

alpine で AWS CLI v2 を使おうとしたら地味に嵌り、 結果、有名な(?) glibc 問題だったというオチでした。

結論

公式がイメージを配布しているので、そちらを使いましょう。 (CLI用のentrypointになっているので、必要に応じてオーバーライド)

もしくはサポートしているディストリビューションのイメージへインストールしましょう。

alpineへ不足ライブラリを入れる事でも実現可能ですが、拘り無いなら上記2点で良いのかなと思います。

経緯

alpine へ公式ドキュメント通りにインストール。
一部略してますが、buildのログは以下のような感じに、 Successfully となってはいます。

Step 1/3 : FROM python:3.8-alpine
Step 2/3 : RUN apk --update --no-cache add   curl
Step 3/3 : RUN curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" && unzip awscliv2.zip && ./aws/install
Archive:  awscliv2.zip
   creating: aws/
   creating: aws/dist/

・・・略

  inflating: aws/dist/botocore/data/comprehendmedical/2018-10-30/paginators-1.json
./aws/install: line 78: /aws/dist/aws: not found
You can now run: /usr/local/bin/aws --version
Successfully built xxxxxxxxxxxxx

コンテナの中身を見てみると、ファイル自体は存在し、パスも通っているが、実行時に not found となる。

/ # which aws
/usr/local/bin/aws
/ # aws --version
sh: aws: not found
/ # /usr/local/bin/aws
sh: /usr/local/bin/aws: not found
/ # ls -l /usr/local/bin/aws
lrwxrwxrwx    1 root     root            37 May  3 05:44 /usr/local/bin/aws -> /usr/local/aws-cli/v2/current/bin/aws
/ # ls -l /usr/local/aws-cli/v2/current/bin/aws
lrwxrwxrwx    1 root     root            11 May  3 05:44 /usr/local/aws-cli/v2/current/bin/aws -> ../dist/aws
/ # ls -l /usr/local/aws-cli/v2/dist/aws
-rwxr-xr-x    1 root     root       4099736 May  3 05:44 /usr/local/aws-cli/v2/dist/aws
/ #

原因

AWS CLI v2 は glibc を使用するが、alpine は glibc でなく musl-libc を使っているため、単純にインストールするだけでは動作しない。

参考

AWS CLI v2 のリポジトリに同エラーが issue として挙がってます。

Upstart の自動起動無効化

世の中systemdなので無用の長物になりそうですがメモ。
公式に記載がある通りです。

Ubuntuだと14.10以降は override が利用できるようですが、 CentOS6 や Amazon Linux の場合、 提供されている upstart のバージョンが古く、 override は利用できないようです。

公式

With Upstart 0.6.7, to stop Upstart automatically starting a job, you can either:

  • Rename the job configuration file such that it does not end with ".conf".
  • Edit the job configuration file and comment out the "start on" stanza using a leading '#'.

version 1.3 以上では、override ファイルが利用可能

With Upstart 1.3, you can make use of an "override file" and the manual stanza to achieve the same result in a simpler manner [31]:

# echo "manual" >> /etc/init/myjob.override

Note that you could achieve the same effect by doing this:

# echo "manual" >> /etc/init/myjob.conf

公式の Override の説明リンクが切れてますが、 アーカイブがありました。 upstart.at が既に無いようです。

検証

Amazon Linux の ssm-agent が upstart での起動なので、そちらで検証してみます。

  • 環境
$ grep PRETTY_NAME /etc/os-release
PRETTY_NAME="Amazon Linux AMI 2018.03"
$ initctl --version
initctl (upstart 0.6.5)

a) リネーム

効きました。

$ ls -l /etc/init/amazon-ssm-agent.*
-rw-r--r-- 1 root root 760  8月  3  2018 /etc/init/amazon-ssm-agent.conf_

b) コメントアウト

効きました。

$ diff /etc/init/amazon-ssm-agent.conf.org /etc/init/amazon-ssm-agent.conf
17c17
< start on (runlevel [345] and started network)
---
> #start on (runlevel [345] and started network)
$

c) overrideファイルへ "manual"

効きません。

$ ls -l /etc/init/amazon-ssm-agent.*
-rw-r--r-- 1 root root 760  8月  3  2018 /etc/init/amazon-ssm-agent.conf
-rw-r--r-- 1 root root   7  3月 15 01:10 /etc/init/amazon-ssm-agent.override
$ sudo cat /etc/init/amazon-ssm-agent.override
manual
$
  • reboot 後
$ uptime
 01:11:17 up 0 min,  1 user,  load average: 0.08, 0.02, 0.01
$ ps -ef | grep [s]sm-agent
root      2266     1  0 01:11 ?        00:00:00 /usr/bin/amazon-ssm-agent
$

d) confファイルへ "manual"

効きました。

$ diff /etc/init/amazon-ssm-agent.conf.org /etc/init/amazon-ssm-agent.conf
22a23
> manual
$