くりにっき

フルスタックキュアエンジニアです

Cloud Runでは/_ah/で始まるパスは使えない

GCP

タイトルが全て

事象

Cloud RunにDockerコンテナをデプロイしたが、gcloud run deploy --allow-unauthenticated *1 で全公開にしてるにも関わらず /_ah/health （コンテナ内で動いてるアプリのヘルスチェック用のエンドポイント）を呼ぼうとして401エラーになっていた。

$ curl -s https://xxxxxxxxxxxx.a.run.app/_ah/health

<html><head>
<meta http-equiv="content-type" content="text/html;charset=utf-8">
<title>401 Unauthorized</title>
</head>
<body text=#000000 bgcolor=#ffffff>
<h1>Error: Unauthorized</h1>
<h2>Your client does not have permission to the requested URL <code>/_ah/health</code>.</h2>
<h2></h2>
</body></html>

原因

別のパスだと呼べたのでおそらくGCP側の仕様。

ググった範囲だとCloud Runの公式ドキュメントにはどこにも書かれていなかったが、Google App Engineだと /_ah/start や /_ah/warmup が特別なパスとして予約されていてIAMの権限がないとアクセスできない仕様になっていたので*2、おそらく同じ仕様がCloud Runでも適用されていると思われる。

Dockerizeする前の元のアプリで /_ah/health が実装済だったのでそれを使っていたのだが、まさか --allow-unauthenticated が効かないとは思わなかった、、、

公式ドキュメントに書いてないのはハマるのでこの事象はフィードバックで報告しています。

*1:https://cloud.google.com/run/docs/authenticating/public?hl=ja

*2: https://cloud.google.com/appengine/docs/standard/go/configuring-warmup-requests?hl=ja , https://cloud.google.com/appengine/docs/standard/python/how-instances-are-managed?hl=ja

CircleCIでマトリックスビルドがサポートされたのでさっそく使ってみた

CircleCI

公式ドキュメント

実際に使ったPR

github.com

github.com

これはビルドマトリクスの軸が1つだけなので大したリファクタリングになってないですが、軸が2つ以上になった時にかなり .circleci/config.yml がシンプルになると思われます。

所感

過去にブログ で

  • ビルドマトリクスの軸が2つ以上になる場合はTravis CIの方が圧倒的に楽
    • というか、CircleCIやGitLab CIで2軸以上のマトリクステストは人間がメンテできる気がしない、、、

って書きましたが、これでだいぶ改善されました。

社内ライブラリをメンテしているとついついビルド1回で30個以上のジョブが作られるような超巨大マトリクスビルドを作りがちですが、CircleCIにはパフォーマンスプランがあるのでこれからはオートスケールの並列数で殴れるようになるのではないかと思っています。

余談

【CVE-2020-2179】Jenkins Yaml Axis Plugin v0.2.1をリリースした

security

昔作ったJenkins Yaml Axis Pluginにリモートコード実行の脆弱性が見つかったので修正してv0.2.1をリリースしています。ご利用の方は速やかにアプデお願いします。

https://github.com/jenkinsci/yaml-axis-plugin/blob/master/CHANGELOG.md#021-2020-04-07

jenkins.io

gitpanda v0.9.0をリリースした

gitlab

https://github.com/sue445/gitpanda/blob/master/CHANGELOG.md#v090

最近のGitLabでは https://gitlab.com/gitlab-org/gitlab/-/merge_requests や https://gitlab.com/gitlab-org/gitlab/-/issues みたいに /-/ が含まれるURLになっているようなので*1、そういった形式のURLに対応するようにしました

*1:https://docs.gitlab.com/ee/development/routing.html#project-routes

chatwork-ruby 0.12.2とpixela 1.4.1をリリースした

gem

それぞれfaraday v1.0対応です。

https://github.com/asonas/chatwork-ruby/blob/master/CHANGELOG.md#v0122

https://github.com/sue445/pixela/blob/master/CHANGELOG.md#v141

実はfaraday v1.0対応自体は1月くらいにはできていてfaraday_middleware v1.0.0が出るのを待っていたのですが、なかなかリリースされないしv1.0.0.rc1があるしまあいいかくらいの軽いノリで出しました。

どっちのgemもfaraday 0系と1系両方対応してますがメンテつらくなったタイミングで0系のサポートをきります

wgetでPOSTする

tl;dr;

wget --post-data="key1=value1&key2=value2" https://example.com/webhook -O /dev/null

経緯

  • CIの実行中に通知用のwebhookをPOSTして通知をやりたかったんだけど、CIで使ってるDockerイメージに curl が入っていなくて困った
  • 素直に curl 入れればよかったんだけど、パッケージのインストールはスロービルドの原因になるのでなるべくインストールしたくなかった
  • curl はなかったけど wget は入ってたので wget でPOSTしてみた

解説

冒頭のコマンドが全てなのですが、特筆するとしたら最後の -O /dev/null 辺りです。

wgetするとPOSTであってもカレントディレクトリに webhook みたいなファイルを書き出すのですが、その状態でもう一度同じURLに対して wget すると（ つまり1回のCIで同じwebhookを2回叩くと *1 ）

wget: can't open 'webhook': File exists

のようなエラーになるので、2回目エラーにならないように出力を /dev/null に捨てています。

*1:自分の場合terraform applyの前後で通知をしようとしたらapply後の通知でエラーになった

#プリッカソン でprismdb-rubyとfaker-pretty_seriesを作った

Ruby gem

prismdb-ruby

PrismDB のAPIクライアント

github.com

  • スピード重視で使い慣れたREST APIを使ったけど、GraphQLの方を使った方がよかったかもしれない

faker-pretty_series

Rubyでダミーのテストデータを作るライブラリ「faker」のプリティーシリーズ版

github.com