Docker Hubがしんどくなりそうなのでghcr.ioにも置くようにした
@matsuuさんのポストより。
Docker Hub、2025/03/01から認証なしでのimage pullはIPアドレス毎に1時間あたり10回までに制限。認証してもPersonalはアカウント毎に1時間あたり40回まで。まじかよ。いよいよ厳しくなってきたな。 / “Usage and limits” https://t.co/hJWuR41b9G
— matsuu (@matsuu) 2025年2月23日
これ、先ほどサイト確認したら書き変わってて、2025/03/01→2025/04/01になってた。
— matsuu (@matsuu) 2025年2月23日
Personalアカウント上限も40回→100回
でも認証なしの10回まではそのまま。
これはつらい。
最近業務でトレーシングハンズオンをした折に、配布のために魔改造Jaeger HotRODデモをDocker Hubに置いて使っていた。ハンズオンという性質上、受講者がDockerにアカウントを持っていることを前提にはできず、10回制限だとちょっと試行錯誤しただけでもひっかかりそうで危ない。
ということで、とりあえず今だと別のレジストリとしてGitHub Container Registry（ghcr.io）にも置いておくのがまぁまぁ順当だろう。
ghcr.ioに置くのは初めてなので、調べながらやっていく。
王道としてはGitHub ActionsでGITHUB_TOKENを使うのだが、Jaegerリポジトリをフォークしてexamplesだけ変更しているため、Actionsの設定をいじくるのは手間そうだ。そもそも滅多にイメージを更新する機会もないので、必要なときだけPersonal Access Tokenを払い出してイメージプッシュをすることにする。
GitHubのSettings→Developer Settingsと進み、Personal access tokens (classic)へ。本当はFine-grained tokensのほうがリポジトリを絞れてよいのだが、ghcr.io向けにはclassicでないとダメらしい。
Generate new tokens→Generate new token (classic)でトークン生成画面を開く。Noteにこのトークンの説明、Expirationに有効期限（使い切り前提なので短くてよい）。「write:packages」にチェックを入れる。これでほかのrepoなどにもチェックが自動で付く。
「Generate token」ボタンでトークンが作られ、一度だけ表示されるトークン文字列が示される。これをコピーして保存しておく。
このトークンを使ってログインする（ユーザー名はGitHubのユーザー名）。
docker login -u ユーザー名 ghcr.io トークン文字列入力
または
cat トークン文字列保存ファイル | docker login -u ユーザー名 --password-stdin ghcr.io
HotRODイメージのビルドとレジストリプッシュはこれまでは以下のようにしていた。
docker buildx build --platform linux/amd64,linux/arm64 -t kenshimuto/hotrod:latest --push .
ghcr.ioにプッシュするために以下のように変更。
docker buildx build --platform linux/amd64,linux/arm64 -t ghcr.io/kmuto/hotrod:latest --push .
できたできた（hotrod latest）。デフォルトはprivateになっていたので、Package settingsでPublicに切り替えた。
参照しているdocker-compose.ymlなども変更する。
services:
hotrod:
image: ghcr.io/kmuto/hotrod:latest
次回の頃にはトークンが期限切れしているので、また生成からやることになる。そのときにはきっとこのメモを読み返すだろう……
ちなみにOpenTelemetry Collectorの場所がDocker HubとGitHub Container Registryでだいぶ違った。たとえばopentelemetry-collector-contribは以下のとおり。
- Docker Hub：
otel/opentelemetry-collector-contrib - GitHub Container Registry：
ghcr.io/open-telemetry/opentelemetry-collector-releases/opentelemetry-collector-contrib
なお、Re:VIEWのDockerイメージの「vvakame/review」はずっと昔からDocker Hubのほかにghcr.io/vvakame/reviewにもリリースしているのであった。さすわか。
（最近Re:VIEW本体の機能リリースないやんけ、と言われると、ハイ…）
OpenTelemetry Demo 2.0が出たので試していた
Announcing the OpenTelemetry Demo 2.0が出ていたので、何かよさそうな変更があるか試してみた。
GitHubワーキングコピーとDockerでやっていたらどうも古いコンテナイメージがlatestタグで残ってしまっていて動かなかったので、以下で全部吹っ飛ばしたらmake startで動くようになった。
docker images|grep open-telemetry|awk '{print $3}'|xargs docker rmi
新しくなったこと
さて、アナウンスを見ながら調べてみる。
DAGでサービスマップを見てみた。でっかい。
Flagd-uiの導入
Flagd Configuratorページで操作できるようになった。これはGitHub main HEADではわりと早期にできていたので、あれそうだったんだ、という印象。
なんにせよ、説明があってわかりやすい。エラーを起こす系のはトレースで一発で出てわかりやすい。逆にレイテンシー悪化系のはトレースやAPMを使っても探すのがけっこう難しいなと改めて感じた。
なお、裏で生のyamlを変更しているので、これで操作するとワーキングコピーに差分ができる。
image-providerの導入
これも前からあった気がしていたけど、新しかったのか。静的な商品画像を提供するImageProviderサービスで、NGINX Native OpenTelemetryモジュールの実装例。frontend-proxyから呼ばれる。
RedisをValkeyで置き換え
当たり前だけど体験としては変わらない。
ビルドargsを.envファイルに置き換え
設定まわりを.envファイルに書くようになった。ただこのファイル自体はたまに変わるので、実際の上書きは.env.overrideでやるほうがよさそう。
コンテナを特定の場所に置き換えるために_DOCKERFILE環境変数を導入した、ってなんだろうなと思ったけど、なるほど。
ACCOUNTING_DOCKERFILE=./src/accounting/Dockerfile AD_DOCKERFILE=./src/ad/Dockerfile
サービスの名前を変更
ad-serviceみたいに-serviceを付けるのをやめて、adのようになった。
Acccountingサービスを.NETで置き換え
Goで書かれていたAccountingサービスを、NETの自動計装で置き換えた（zero-code計装、instrument.shの利用）。Cartサービスも.NETだけど、そちらは手動計装。
ENTRYPOINT ["./instrument.sh", "dotnet", "Accounting.dll"]
エグザンプラの追加
CartサービスでGetCartとAddItemの操作について、トレースエグザンプラを記録するようにした。Grafanaで様子を見ることができる。
設定についての説明はCart Serviceのところにあった。
private static readonly ActivitySource CartActivitySource = new("OpenTelemetry.Demo.Cart");
private static readonly Meter CartMeter = new Meter("OpenTelemetry.Demo.Cart");
private static readonly Histogram<long> addItemHistogram = CartMeter.CreateHistogram<long>(
"app.cart.add_item.latency",
advice: new InstrumentAdvice<long>
{
HistogramBucketBoundaries = [ 500000, 600000, 700000, 800000, 900000, 1000000, 1100000 ]
});
private static readonly Histogram<long> getCartHistogram = CartMeter.CreateHistogram<long>(
"app.cart.get_cart.latency",
advice: new InstrumentAdvice<long>
{
HistogramBucketBoundaries = [ 300000, 400000, 500000, 600000, 700000, 800000, 900000 ]
});
React Nativeの例
これが特に注目だぜ！らしい。AndroidやiOS向けにアプリケーションをビルドできる。ドキュメント。
iOSはけっこう複雑だな。Androidのほうをやってみる。
Debianにandroid-sdkパッケージをインストールし、開発者向けオプション有効・USBデバッグ有効にしたLenovo Tab M10をUSB-Cで接続。デバッグモードを有効にした。
プラットフォームは34想定らしいので、sdkmanagerで入れておく（bookwormにはない）。
cd src/react-native-app sudo ANDROID_HOME=/usr/lib/android-sdk sdkmanager "platforms;android-34" "build-tools;34.0.0" sudo ANDROID_HOME=/usr/lib/android-sdk sdkmanager --licenses 5 of 6 SDK package licenses not accepted. Review licenses that have not been accepted (y/N)? y
諸々あって、開始もrootでないと面倒だった。
sudo ANDROID_HOME=/usr/lib/android-sdk npm run android ... › Opening io.opentelemetry.reactnativeapp://expo-development-client/?url=http%3A%2F%2FXXX%3A8081 on Lenovo_TB_X306F › Logs for your project will appear below. Press Ctrl+C to exit. ... Android Bundled 1275ms node_modules/expo-router/entry.js (1638 modules) Android node_modules/expo-router/entry.js ▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░ 96.7% ERROR [TypeError: Network request failed] ERROR [TypeError: Network request failed]
んー。タブレット側にはロゴのあと、「Products No products found, make sure the backend services for the OpenTelemetry demo are running」となってしまった。Debian側の0.0.0.0:8080では動いているんだが、何が見えていないのか。Manifestを見る限りは変な気はしないのだが。
引き続き検証が必要そう。ローカルのAndroid Studioだといけるのかな。
メッセージスパン向けのスパンリンク
メッセージングでproducer/consumerのスパンはリンクしましょう、と推奨は確かにそれはそう。そのデモとして、AccountingおよびFraud-Detectionのconsumerスパンが、Checkout/orders publishのproducerスパンにリンクされている。
メッセージングのproducer/consumerだとreferencesのような親子関係を作れないので、Linksを使うらしい。
ただ、Accountingのorders receiveからorders publishへはReferencesになってるんだよな。クリックするとorders publishのトレースに飛べる。なるほど。JSONで見たときの属性的にはCHILD_OFではなくFOLLOWS_FROMなのでいいんだろうか。
マルチアーキテクチャビルド
makeのターゲットでarm64とamd64のようにほかのアーキテクチャでビルドできるようにした。ユーザーにとっては関係がないけど、ローカルで実行するときには便利なときもある。
Dependabot導入
これもユーザーにとっては関係がないけど、Dependabotを入れて依存ライブラリ更新をするようにした。
途中
- Grafanaダッシュボード。semconvが変わったりしているのでダッシュボードが追従しきれてないっぽい
- DependabotのPRテスト。Dependabot更新が原因で壊れないかの自動のテストがまだできていない
- デモのスケーラビリティ。ローカルで実行可能にしつつデモシナリオの拡張をするというバランスが難しいね、という話
将来計画
- Erlang/Elixirの再導入。Feature Flagサービスは昔これで書かれていたけど書き換えに伴って外してて、でもこの言語サンプルないよね〜で再登場の可能性がある
- React Native Appでデモをリモート実行する手法
- Dependabotとかによる自動化・テスト
しかしあいかわらずだいぶ「でっかい」デモなので、なかなか大変。LOCUSTでのアクセスを止めればいいのかも。
