複数のAWSアカウントのECRからdocker pullするときに、いちいちプロファイルを指定するのがめんどくさいことがあったので（docker-composeとか）、環境変数を追加するecs-loginのラッパーを作った。
~/.docker/ecr-login-env.json に以下のような感じで設定を書いておいて
{ "123456789012.dkr.ecr.us-east-1.amazonaws.com": { "AWS_PROFILE": "my-profile" } }
~/.docker/config.json の ecr-login を ecr-login-with-env に差し替えると
{ "credHelpers": { "123456789012.dkr.ecr.us-east-1.amazonaws.com": "ecr-login-env" } }
docker pull/pushなどをするときにecr-loginに環境変数 AWS_PROFILE=my-profile が渡されるようになる。
マスクされた値はマウスで選択すれば見れる。
以下のようなaliasを設定して使っている。
alias opeco='op item list | tail -n +2 | sort -k2 | peco | cut -b -26 | (op item get --format json $(cat -) | opmsk)'
※peco: https://github.com/peco/peco
GolangのRedashクライアントライブラリはいくつかあるものの、メンテナンスが活発でなかったり、一部のリソースしか操作できなかったりするため、新しくライブラリを書いた。
※その他のライブラリ
RedashのAPIは一応、ドキュメントがあるもの網羅的ではなく、リファレンスとしてはほとんど使えないので、Redashのソースコードとredash-toolbeltを参考にした。
SPAなのですべての操作はAPIで行われているが、外部公開を考慮していないものもいくつかあるようで、正しくないパラメータを送るとすぐにInternal Server Errorになってしまったり、同じAPIが構造の異なるスキーマを返したりと癖があり、少し時間がたつとすぐに腐ってしまいそうなので、このライブラリではそれなりに頑張ってテストを書いている。ユニットテストだけでなく、DockerでRedashを立ち上げてのインテグレーションテストも一通り書いた。
以下はクエリを作成して、実行結果を表示する例。
package main import ( "context" "fmt" "time" "github.com/winebarrel/redash-go" ) func main() { client, _ := redash.NewClient("https://redash.example.com", "<secret>") //client.Debug = true ctx := context.Background() query, _ := client.CreateQuery(ctx, &redash.CreateQueryInput{ DataSourceID: 1, Name: "my-query1", Query: "select 1", }) var buf bytes.Buffer job, _ := client.ExecQueryJSON(ctx, query.ID, &buf) if job != nil { for { job, _ := client.GetJob(ctx, job.Job.ID) if job.Job.Status >= 3 { buf = bytes.Buffer{} client.GetQueryResultsJSON(ctx, query.ID, &buf) break } time.Sleep(1 * time.Second) } } fmt.Println(buf.String()) }
REST APIをマップしているので ListAlerts() でアラートの一覧を表示したり、CreateDashboard() でダッシュボードを作ったり…とリファレンスを見れば大体の操作はわかると思う。
クエリの実行、Jobまわりは癖があるのでAPIそのままではないが、普通に使える気はする。 Job一覧を表示するAPIは未だ見つけられず。
APIの調査のため、ローカルでRedashを立ち上げてひたすらたたいたいた。 redash-goにデバッグフラグを追加して、HTTPのリクエストとレスポンスをダンプし、流れてくるJSONを観察。
https://github.com/winebarrel/redash-go/blob/main/client.go#L115-L118
if client.Debug {
b, _ := httputil.DumpRequest(req, true)
fmt.Fprintf(os.Stderr, "---request begin---\n%s\n---request end---\n", b)
}
そのJSONをJSON-to-Go: Convert JSON to Go instantlyでGolangの構造体に変換する、ということを繰り返していたが、レスポンスの一行JSONが見にくく、それをいちいちコピペで整形する手間がめんどくさかったのでppcatというツールも作った。
これはテキストにJSONっぽい行が含まれていたらパースしてみてJSONだったら整形して表示するというもの。 たとえば上の出力をppcatに通すと以下のようになる。
大分見やすくなったので開発も捗った。
GitHubのPRがマージされたら、リポジトリの他のPRのブランチを更新するコマンドとそのGitHub actionを作った。
name: pru on: push: branches: - main paths: - "**/*.go" - Makefile permissions: contents: write pull-requests: write jobs: pru: name: pru runs-on: ubuntu-latest steps: - uses: winebarrel/pru-action@v0.3.0 with: paths: | **/*.go Makefile
この例だと、PR#1をマージしたときに、**/*.go,Makefileを含むPR#2のブランチを更新している。
SQS+PostgreSQL+Lambdaとその間をつなぐデーモンで構成されたジョブキューシステムです。 入り口のSQLにメッセージを投げると、メッセージで指定した関数名のLambdaが実行されます。 Lambdaの実行に失敗した場合は、適当な感覚でリトライされます。
Ruby製のジョブキューシステムQueとそのクローンであるqgを模した作りになっています。
コンテナ環境で使いやすいジョブキューシステムが欲しかったのが、モチベーションです。
Resqueのようにプロセスとしてジョブを起動するタイプだと、コンテナのライフサイクルとのミスマッチでスケールイン・スケールアウトが難しので、コンテナを使うならなるべくクラウド上の何か（ECS・Lambda…etc）でジョブを実行したいのですが、一方で完全にAWSリソースだけでジョブキューシステムを作ると、特にSQSの使い勝手が悪くキューの可観測性が低いので、もう少し使い勝手の良い何かが欲しいなーと。
READMEに書いたとおりなんですが
$ docker-compose up
$ make tf-init $ make tf-apply
※LocakStackに対してterraformを適用します
$ make db
初期状態ではデーモンが起動に失敗しているので、再起動します。
$ make restart
以上でサーバのセットアップは完了です。
最後にSQSにメッセージを投げるとLambdaが実行されることを確認できます。
$ make message
サンプルのLambdaはこんな感じです:
make failure を実行すると、Lambdaが失敗するメッセージをSQSに投げるので、ジョブがリトライする様子を確認できます。
$ make failure
DBに残っているジョブは http://localhost:8081 から確認できます。
親Contextの都合でcancelしてほしくないが、loggerの引き回しはContextでやりたい、みたいなときにDeadline()/Done()/Err()を無視すればいいのかなぁ…と思って実装してみた。
cancelされたくないというのは、SIGINTですべてのgoroutineを停止したいんだけど、goroutineのトランザクションは完了しててほしい、みたいな。
package ctxutil import ( "context" "time" ) type withoutCancelCtx struct { parent context.Context } func (*withoutCancelCtx) Deadline() (deadline time.Time, ok bool) { return } func (*withoutCancelCtx) Done() <-chan struct{} { return nil } func (*withoutCancelCtx) Err() error { return nil } func (ctx *withoutCancelCtx) Value(key any) any { return ctx.parent.Value(key) } func WithoutCancel(parent context.Context) context.Context { return &withoutCancelCtx{parent} }
ctx = ctxutil.WithoutCancel(ctx)
ctxutil.WithoutCancel()を読んでいる関数の上位の関数では、親ContextのDone()をチェックして、子が終わったら終了する想定。
キャンセルされたくないトランザクションはいろいろあるきがしているけど、その対応の実装例をあまり見ないような気がしている。他の人、どうしているんだろう？