Joy-Conのスティックを交換する機会があったので使用したキットや参考動画をメモしておきます。
似たものがたくさんありますが、修理キットはこれを購入しました。
付属のY字ドライバーを使うのはやめましょう。
無理するとネジ穴が潰れます（後述）。
こちらのドライバーだとすんなり外せました。
あとはこの方の動画を頼りに作業を進め無事完了しました。
修理の過程でY字ネジを一つ完全に潰してしまい、諦めかけましたが、この動画に救われました。
Y字ドライバーをケチるのはやめましょう。
# apt install collectd Reading package lists... Done Building dependency tree... Done Reading state information... Done Package collectd is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'collectd' has no installation candidate
バグらしいです。
こちらに記載の手順でdebファイルをダウンロードし、インストールできました。
# wget https://launchpad.net/ubuntu/+archive/primary/+files/collectd-core_5.12.0-11_amd64.deb # wget https://launchpad.net/ubuntu/+archive/primary/+files/collectd_5.12.0-11_amd64.deb # apt install ./collectd-core_5.12.0-11_amd64.deb ./collectd_5.12.0-11_amd64.deb
AWS Load Balancer Controllerをv2.0.1からv2.4.5にアップデートにしたので手順をメモします。
リージョンは東京（ ap-northeast-1 ）です。
❯ helm history aws-load-balancer-controller -n kube-system REVISION UPDATED STATUS CHART APP VERSION DESCRIPTION 1 Tue Feb 2 21:57:58 2021 superseded aws-load-balancer-controller-1.0.8 v2.0.1 Install complete 2 Mon Dec 19 20:21:15 2022 deployed aws-load-balancer-controller-1.4.6 v2.4.5 Upgrade complete
公式の手順を参考に進めます。
以降の作業で参照する変数を定義しておきます。
$ CLUSTER_NAME=<eks-cluster-name>
$ VPC_ID=$(
aws eks describe-cluster \
--name $CLUSTER_NAME \
--query "cluster.resourcesVpcConfig.vpcId" \
--output text
)
$ POLICY_ARN=$(
aws iam list-policies \
--query 'Policies[?PolicyName==`AWSLoadBalancerControllerIAMPolicy`].Arn' \
--output text
)
ダウンロードした iam_policy.json でIAMポリシーの新しいバージョンを作成します。
公式の手順ではv2.4.4のファイルを参照していましたが、差分はないのでv2.4.5を指定しました。
$ curl -o iam_policy.json \
https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/v2.4.5/docs/install/iam_policy.json
$ aws iam create-policy-version \
--policy-arn $POLICY_ARN \
--policy-document file://iam_policy.json --set-as-default
$ rm iam_policy.json
作成済みなので、特に変更しません。
最新の手順ではロール名（ --role-name ）を明示的に指定していましたが、名前を変更する必要もないので無視します。
When upgrading, change install to upgrade in the previous command, but run the following command to install the TargetGroupBinding custom resource definitions before running the previous command.
ということで、CRDをインストールするために以下のコマンドを実行します。
$ kubectl apply -k "github.com/aws/eks-charts/stable/aws-load-balancer-controller/crds?ref=master"
続けて、チャートをアップデートします。
$ helm repo update $ helm upgrade aws-load-balancer-controller eks/aws-load-balancer-controller \ --set clusterName=$CLUSTER_NAME \ --set serviceAccount.create=false \ --set serviceAccount.name=aws-load-balancer-controller \ --set region=ap-northeast-1 \ --set vpcId=$VPC_ID \ --set image.repository=602401143452.dkr.ecr.ap-northeast-1.amazonaws.com/amazon/aws-load-balancer-controller \ -n kube-system
バージョンが更新されたことを確認して終わりです。
❯ helm list -n kube-system NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION aws-load-balancer-controller kube-system 2 2022-12-19 20:21:15.305269 +0900 JST deployed aws-load-balancer-controller-1.4.6 v2.4.5
❯ kubectl get deployment aws-load-balancer-controller -n kube-system -o yaml | yq e '.spec.template.spec.containers[0].image' - 602401143452.dkr.ecr.ap-northeast-1.amazonaws.com/amazon/aws-load-balancer-controller:v2.4.5
fluent-plugin-elb-logでS3からALBのアクセスログを収集してみたので手順をまとめます。
$ lsb_release -d Description: Ubuntu 22.04 LTS
$ td-agent --version td-agent 4.4.1 fluentd 1.15.2 (c32842297ed2c306f1b841a8f6e55bdd0f1cb27f)
$ td-agent-gem list fluent-plugin-elb-log fluent-plugin-elb-log (1.3.2)
fluent-plugin-elb-logをインストールします。
$ sudo td-agent-gem install fluent-plugin-elb-log Fetching aws-sdk-ec2-1.329.0.gem Fetching fluent-plugin-elb-log-1.3.2.gem Successfully installed aws-sdk-ec2-1.329.0 Successfully installed fluent-plugin-elb-log-1.3.2 Parsing documentation for aws-sdk-ec2-1.329.0 Installing ri documentation for aws-sdk-ec2-1.329.0 Parsing documentation for fluent-plugin-elb-log-1.3.2 Installing ri documentation for fluent-plugin-elb-log-1.3.2 Done installing documentation for aws-sdk-ec2, fluent-plugin-elb-log after 13 seconds 2 gems installed
EC2インスタンスにポリシー AmazonS3ReadOnlyAccess をIAMロールで割り当てます。
プレフィックスなしでバケット my-bucket に保存したアクセスログ（ my-bucket/AWSLogs/... ）を対象とします。
<source> @type elb_log tag elb.access region ap-northeast-1 # 東京リージョンの場合 s3_bucketname my-bucket # バケット名 #s3_prefix # プレフィックスを指定した場合のみ timestamp_file /var/lib/td-agent/elb/elb_last_at.dat # ログのタイムスタンプを記録 buf_file /var/lib/td-agent/elb/fluentd-elblog.tmpfile # バッファファイル start_time 2022-09-01 00:00:00Z # 開始時刻(後述) refresh_interval 300 # リフレッシュ間隔 delete false # 処理したログファイルをS3から削除 include_all_message false # 生のログをall_messageフィールドに出力(後述) </source> <match elb.access> @type stdout </match>
ドキュメント化されていませんが、開始時刻はstart_timeで指定できました。
timestamp_file と start_time のうち、より大きいタイムスタンプを使用するようです。
同様に説明がないですが、以下のIssueで追加されたオプションです。
true を設定すると、生のログを all_message に出力します。
省略されたフィールドにアクセスしたい場合に使用します。
{
...
"all_message": "h2 2022-09-01T00:00:40.188594Z ... ... 192.168.xxx.xxx:80 0.002 0.003 0.000 200 200 245 641 \"GET https://... HTTP/2.0\" \"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0\" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 arn:aws:elasticloadbalancing:ap-northeast-1:...:targetgroup/... ... ... ... 1 2022-09-01T00:00:40.183000Z \"forward\" \"-\" \"-\" \"192.168.xxx.xxx:80\" \"200\" \"-\" \"-\"\n"
}
以下の通りにアクセスログが取得できることを確認できました。
オブジェクトの件数が多いと時間がかかるので気長に待ちましょう。
...
2022-09-06 14:37:52 +0900 [info]: #0 processing 6212 object(s).
2022-09-06 14:37:52.803265383 +0900 fluent.info: {"message":"processing 6212 object(s)."}
2022-09-01 09:00:40.000000000 +0900 elb.access:
{
"account_id":"...",
"region":"ap-northeast-1",
"logfile_date":"2022/09/01",
"logfile_elb_name":"...",
"elb_ip_address":"...",
"logfile_hash":"...",
"elb_timestamp":"20220901T0005Z",
"key":"AWSLogs/.../elasticloadbalancing/ap-northeast-1/2022/09/01/....log.gz",
"prefix":null,
"elb_timestamp_unixtime":1661990700,
"s3_last_modified_unixtime":1661990709,
"time":"2022-09-01T00:00:40.188594+0000",
"elb":"...",
"client":"...",
"client_port":"...",
"backend":"...",
"backend_port":"...",
"request_processing_time":0.002,
"backend_processing_time":0.003,
"response_processing_time":0.0,
"elb_status_code":"200",
"backend_status_code":"200",
"received_bytes":245,
"sent_bytes":641,
"request_method":"GET",
"request_uri":"https://...",
"request_protocol":"HTTP/2.0",
"user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0",
"ssl_cipher":"ECDHE-RSA-AES128-GCM-SHA256",
"ssl_protocol":"TLSv1.2",
"type":"h2",
"target_group_arn":"arn:aws:elasticloadbalancing:ap-northeast-1:...:targetgroup/...",
"trace_id":"...",
"domain_name":"...",
"chosen_cert_arn":"...",
"matched_rule_priority":"1",
"request_creation_time":"2022-09-01T00:00:40.183000Z",
"actions_executed":"forward",
"redirect_url":"-",
"error_reason":"-",
"option1":"...",
"option2":"\"200\"",
"option3":null
}
...
fluent-plugin-cloudwatch-logsのin_cloudwatch_logsでCloudWatch Logsからログを収集してみたので手順をまとめます。
$ lsb_release -d Description: Ubuntu 22.04 LTS
$ td-agent --version td-agent 4.4.1 fluentd 1.15.2 (c32842297ed2c306f1b841a8f6e55bdd0f1cb27f)
$ td-agent-gem list fluent-plugin-cloudwatch-logs fluent-plugin-cloudwatch-logs (0.14.3)
Install by DEB Package (Debian/Ubuntu)の手順に従い、 td-agent をインストールします。
# For Ubuntu Jammy # td-agent 4 (experimental) $ curl -fsSL https://toolbelt.treasuredata.com/sh/install-ubuntu-jammy-td-agent4.sh | sh
デーモンの起動を確認します。
$ systemctl status td-agent
● td-agent.service - td-agent: Fluentd based data collector for Treasure Data
Loaded: loaded (/lib/systemd/system/td-agent.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2022-08-30 18:09:38 JST; 1min 19s ago
Docs: https://docs.treasuredata.com/display/public/PD/About+Treasure+Data%27s+Server-Side+Agent
Main PID: 1608 (fluentd)
Tasks: 9 (limit: 4692)
Memory: 100.1M
CPU: 1.765s
CGroup: /system.slice/td-agent.service
├─1608 /opt/td-agent/bin/ruby /opt/td-agent/bin/fluentd --log /var/log/td-agent/td-agent.log --daemon /var/run/td-agent/td>
└─1611 /opt/td-agent/bin/ruby -Eascii-8bit:ascii-8bit /opt/td-agent/bin/fluentd --log /var/log/td-agent/td-agent.log --dae>
Aug 30 18:09:38 ip-172-31-31-91 systemd[1]: Starting td-agent: Fluentd based data collector for Treasure Data...
Aug 30 18:09:38 ip-172-31-31-91 systemd[1]: Started td-agent: Fluentd based data collector for Treasure Data.
標準設定で有効なHTTPエンドポイントにサンプルログを投げ、動作確認を行います。
$ curl -X POST -d 'json={"json":"message"}' http://localhost:8888/debug.test
$ tail -n 1 /var/log/td-agent/td-agent.log
2022-08-30 18:12:07.867864796 +0900 debug.test: {"json":"message"}
fluent-plugin-cloudwatch-logsをインストールします。
$ sudo td-agent-gem install fluent-plugin-cloudwatch-logs Fetching fluent-plugin-cloudwatch-logs-0.14.3.gem Fetching aws-sdk-cloudwatchlogs-1.53.0.gem Successfully installed aws-sdk-cloudwatchlogs-1.53.0 Successfully installed fluent-plugin-cloudwatch-logs-0.14.3 Parsing documentation for aws-sdk-cloudwatchlogs-1.53.0 Installing ri documentation for aws-sdk-cloudwatchlogs-1.53.0 Parsing documentation for fluent-plugin-cloudwatch-logs-0.14.3 Installing ri documentation for fluent-plugin-cloudwatch-logs-0.14.3 Done installing documentation for aws-sdk-cloudwatchlogs, fluent-plugin-cloudwatch-logs after 0 seconds 2 gems installed
ログの取得( in_cloudwatch_logs )に必要な以下のポリシーを割り当てたIAMユーザまたはロールを作成します。
IAMロールを使用する場合はEC2インスタンスに割り当ててください。
{ "Version": "2012-10-17", "Statement": [ { "Action": [ "logs:GetLogEvents", "logs:DescribeLogStreams" ], "Effect": "Allow", "Resource": "*" } ] }
ロググループ /aws/log/group 以下の複数のログストリーム app-* を対象にログを取得する例です。
取得したログは標準出力に吐き出して確認します。
<source>
@type cloudwatch_logs
tag cloudwatch
aws_key_id ... # IAMユーザのアクセスキー(IAMロールの場合は不要)
aws_sec_key ... # IAMユーザのシークレットアクセスキー(IAMロールの場合は不要)
region ap-northeast-1 # 東京リージョンの場合
log_group_name /aws/log/group # ロググループ名
use_log_stream_name_prefix true # log_stream_nameを接頭辞として使用
log_stream_name app- # ログストリームの接頭辞を指定
fetch_interval 60 # 1分毎にログを取得
throttling_retry_seconds 30 # レート制限を超過した場合に30秒スリープ
json_handler json
<storage> # 現在の状態（例：next_forward_token）を保存するファイルの指定
@type local
path /var/tmp/state.json
</storage>
</source>
<match cloudwatch>
@type stdout
</match>
td-agent.log にCloudWatch Logsのログが書き込まれることを確認できました。
以下はEKSのContainer Insightsから取得したApacheコンテナのログです。
...
2022-08-31 14:21:47.000000000 +0900 cloudwatch: {"log":"httpd-combined 192.168.35.125 - - [31/Aug/2022:05:21:47 +0000] \"GET ...
2022-08-31 14:21:51.000000000 +0900 cloudwatch: {"log":"httpd-combined 192.168.35.125 - - [31/Aug/2022:05:21:47 +0000] \"POST ...
対象となるログストリームが多いとAPI DescribeLogStreams のレート制限(デフォルト：5件/秒)を超過し、 ThrottlingException が発生する恐れがあります。
#0 thread exited by unexpected error plugin=Fluent::Plugin::CloudwatchLogsInput title=:in_cloudwatch_logs_runner error_class=Aws::CloudWatchLogs::Errors::ThrottlingException error="Rate exceeded"
このような場合にはクォータの引き上げを要求するか、 log_stream_name の設定で十分に対象を絞る必要があります。
Conda環境の設定変更が及ぼすプラットフォーム毎の影響を自動で確認するようにしました。
大したことはせず、GitHub ActionsでPR時にConda環境を作成（ conda env create -f <environment.yml> ）して、正常終了するかを確認するだけです。
conda-incubator/setup-miniconda でMiniconda環境を作成し、対象リポジトリ上で管理しているYAMLファイルでConda環境を作成します。
今回は以下の設定を採用しました。詳細はリンク先のREADMEを参照してください。
- uses: conda-incubator/setup-miniconda@v2 with: environment-file: path/to/environment.yml # 環境設定ファイル(conda env exportしたファイル) auto-activate-base: false # base環境を有効化しない auto-update-conda: true # condaのアップデート use-only-tar-bz2: true # キャッシュが機能するように
異なるプラットフォームでConda環境を作成する例です。
普段開発に使用しているmacOS 10.15(Catalina)で開発用のConda環境( dev.yml )を作成し、
デプロイ先として想定するUbuntu 18.04やWindows Server 2019では本番用のConda環境( production.yml )を作成します。
name: build on: push: branches: [ master ] pull_request: jobs: conda-env-create-on-macos: runs-on: macos-10.15 steps: - uses: actions/checkout@v2 - name: Install Homebrew packages run: brew install <formula-1> ... <formula-N> - uses: conda-incubator/setup-miniconda@v2 with: environment-file: path/to/dev.yml auto-activate-base: false auto-update-conda: true use-only-tar-bz2: true conda-env-create-on-linux: runs-on: ubuntu-18.04 steps: - uses: actions/checkout@v2 - name: Update list of packages run: sudo apt-get update - name: Install apt packages run: sudo apt-get install -y <package-1> ... <package-N> - uses: conda-incubator/setup-miniconda@v2 with: environment-file: path/to/production.yml auto-activate-base: false auto-update-conda: true use-only-tar-bz2: true conda-env-create-on-windows: runs-on: windows-2019 steps: - uses: actions/checkout@v2 - uses: conda-incubator/setup-miniconda@v2 with: environment-file: path/to/production.yml auto-activate-base: false auto-update-conda: true use-only-tar-bz2: true
これでPRを契機にConda環境が作成され、環境設定の不備を早期に摘出できるようになりました。
動的に変わるELB（ALB）に割り当てられたIPアドレスの履歴を確認する方法です。
アクセスログが取得されていることを前提とします。
S3に保存されたアクセスログのファイル名は以下のフォーマットに従います。
load-balancer-id 及び ip-address の箇所を参照することで、ログ保存時点に使用していたIPアドレスを特定することができます。
bucket[/prefix]/AWSLogs/aws-account-id/elasticloadbalancing/region/yyyy/mm/dd/aws-account-id_elasticloadbalancing_region_app.load-balancer-id_end-time_ip-address_random-string.log.gz
load-balancer-id: The resource ID of the load balancer. If the resource ID contains any forward slashes (/), they are replaced with periods (.).
ip-address: The IP address of the load balancer node that handled the request. For an internal load balancer, this is a private IP address.
S3のコンソールから確認するのは辛いので、CLIで取得したバケット一覧からIPアドレスを抽出します。
ls — AWS CLI 1.22.86 Command Reference
ALB my-load-balancer が2022年に使用したIPアドレスの一覧を取得する例です。
ALBの名前を LB_NAME に、ログを格納したバケットのURIを S3_URI に指定してください。
第一列には当該IPが初めて使用された時のログ作成時刻を出力しました。
$ LB_NAME=my-load-balancer
$ S3_URI=s3://my-bucket/AWSLogs/123456789012/elasticloadbalancing/ap-northeast-1/2022/
$ aws s3 ls $S3_URI --recursive --summarize |
> grep $LB_NAME |
> awk '{print $1"_"$2"_"$4}' |
> awk -F'_' '{print $1,$2,$8}' |
> awk '!arr[$3]++ {print $1,$2,$3}'
2022-01-01 09:00:02 aaa.aaa.aaa.aaa
2022-01-01 09:00:03 bbb.bbb.bbb.bbb
2022-01-01 09:00:11 ccc.ccc.ccc.ccc
2022-02-02 19:25:06 ddd.ddd.ddd.ddd
2022-02-02 19:35:08 eee.eee.eee.eee
2022-02-02 19:50:03 fff.fff.fff.fff
2022-02-04 10:45:04 ggg.ggg.ggg.ggg
2022-02-04 10:50:04 hhh.hhh.hhh.hhh
2022-02-04 11:10:10 iii.iii.iii.iii
