Docker Hub の課金周りの変更や、ワークフロー可視化など|Productivity Weekly(2025-02-26)
こんにちは。サイボウズ株式会社 生産性向上チームの uta8a です。
僕たち生産性向上チームは毎週水曜日に Productivity Weekly という「1 週間の間に発見された開発者の生産性向上に関するネタを共有する会」を社内で開催しています。
本記事はその時のネタをまとめたものです。
2023-01-25 号から、基本的に隔週で連載することとしました。たまに単独でも投稿するかもしれません。
今週は 2025-02-26 単独号です。
今回が第 180 回目です。過去の記事はこちら。
news 📺
Revisiting Docker Hub Policies: Prioritizing Developer Experience | Docker
去年 9 月に発表された Docker Hub の pull rate limit 仕様変更についてですが、一部実施予定だった内容が変わりました。端的に言うと次のような変更になります。
- docker pull 数の従量課金が廃止
- Docker Personal プランの pull rate limit 緩和
- ストレージ課金を無期限延期
もうちょっと詳しく書きます。
9 月の発表内容から変わる内容
- pull count limit、月間プル数上限超えの課金を廃止
- もともとは 3/1(後に 4/1)から課金予定だった
- business: 1M pull/month → 廃止
- team: 100K pull/month → 廃止
- pro: 25K pull/month → 廃止
- pull rate limit の変更
- personal: 40 pull/user/hour → 100 pull/user/hour
- ストレージ課金を無期限延期
- もともとは 3/1(後に 4/1)から課金予定だった
- 今後課金するようにする場合、6 ヶ月前に通知するとのこと
9 月の発表内容から変わらない内容
- pull rate limit の変更
- business: 廃止
- team: 廃止
- pro: 廃止
- 未認証: 10 pull/ip/hour
- pull rate limit 以外の内容(Docker Scout や Docker Build Cloud など)
なお、現在 9 月の記事を読みに行くともともとあった pull count limit の件が消えており、差分がわかりづらくなっています。
元々の記事が読みたい方は Wayback Machine に当時の内容が残っているので参照ください。
pull count limit、Docker Hub のイメージをヘビーに使ってる組織は大打撃を受けるだろうと考えていましたが、利用者としては廃止されて嬉しいですね。それはそれとして課金アカウントの pull rate limit 廃止もそのままなので嬉しいですね。
ストレージ課金については廃止ではなく無期限延期なので無くなってはないです。ヘビーユーザーの方は覚悟の準備をしておきましょう。
本項の執筆者: @korosuke613
Amazon Bedrock now available in Asia Pacific (Hyderabad) and Asia Pacific (Osaka) regions
Amazon Bedrock が大阪リージョンでも使えるようになりました。現時点で使えるモデルは Claude 3.5 Sonnet v2 のみのようです。
Bedrock はクォータが厳しいのでクロスリージョンで使うことが視野に入りますが、それが日本国内で完結できるようになったのは嬉しいですね。とはいえ東京と大阪の 2 リージョンでも商用利用においては不十分かもしれませんが…。
本項の執筆者: @takamin55
GitHub Actionsを可視化するGitHub Actions OpenTelemetryの紹介
GitHub Actions の実行時間に関する情報を OpenTelemetry の形式で送信してくれるアクションが紹介された記事です。ワークフローやジョブの実行時間の劣化・改善を可視化できます。
リポジトリは paper2/github-actions-opentelemetry です。OTel 形式のデータなので特定のベンダーにロックされずに CI を分析できるのが良いですね。データストアや分析基盤を作る手間はどうしても発生しますが、継続的な計測によってワークフローやジョブの変化を追える点も嬉しいです。
なお、過去との継続的な比較ではなく単発の気軽な分析でよければ、Kesin11/actions-timeline
というアクションもあります。こちらの資料 で詳細が説明されていますので、興味がありましたらぜひご覧ください!
計測してどんどんワークフローを効率化していきましょう!
本項の執筆者: @takamin55
Repositories – Updated insight views (General Availability) - GitHub Changelog
リポジトリの Insights タブの Contributors と Code frequency の画面のデザインが新しくなりました。
期間を指定できるようになり、ある期間での Contributor の commit 等のランキングが見られるようになりました。毎月の Top Contributor のような値が知りたい時に便利そうですね。
本項の執筆者: @uta8a
Deno 2.2: OpenTelemetry, Lint Plugins, node:sqlite
Deno 2.2 きました!!! わいわい!
破壊的変更はありません。
個人的にデカい変更は以下です:
- Built-in OpenTelemetry integration
-
console.log
やDeno.serve
、fetch
をはじめとする API 呼び出しを追跡できます。
-
- Linter updates > JavaScript plugin API
- Deno Lint のルールをユーザー定義できます。
- マジで嬉しい!!!!!!!!!!!! マジで嬉しい!!!!!!!!!!!!
- Support for node:sqlite
- Node.js の SQLite モジュールが使用可能になりました。
Lint ルールをユーザー定義できる機能マジで待ってました!!! 今まではユーザー定義するなら ESLint などを使うしかありませんでしたが、これからは Deno で完結できそうです。さらに、3 月 4 日まで Lint ルールの発表大会が開催されていて、何かしらのルールを JSR で公開すると Deno ステッカーがもらえるみたいです。激アツ!!!!! この記事が公開される頃はもう終わってるかもですが、そうでなければ挑戦してみましょう!
本項の執筆者: @ajfAfg
Amazon ECS increases the CPU limit for ECS tasks to 192 vCPUs - AWS
Amazon ECS on EC2 にて、タスクの vCPU のハードリミットの上限が 10 vCPUs から 192 vCPUs に引き上げられました。
ECS on Fargate については、2025/03/07 現在で 公式ドキュメント の変更は無いため、従来通り 16 vCPU までと思われます。
そもそも ECS では、コンテナレベルとタスクレベルの 2 つでそれぞれ CPU とメモリの上限を設定できます。
また ECS on EC2 の場合、タスクレベルでの CPU の上限設定は任意です。
CPU 上限を設定しないと、EC2 のリソースを上限として際限なく使うことになります。
ただし、他のタスクと CPU を共有しているので、リソースの競合が発生する可能性があります。
なのでタスクレベルのリソース上限もきちんと設定することで、この競合が起きないようにするのが良いです。
今回、そのタスクレベルの CPU 上限が 10 vCPUs から 192 vCPUs と大幅に上がったことで、より大きなワークロードであってもタスクの競合を心配せずに実行できるようになりました。
今まで CPU のリソース競合を気にして ECS を使えなかった方も、今回の変更で ECS の選択肢が増えると思うと、嬉しいですね。
本項の執筆者: @defaultcf
know-how 🎓
mizchi/deno-ai-bestpractice
Deno を使用したプロジェクトを Cline や Roo Code で開発する際の .clinerules
として参考になるものが書かれています。
.clinerules
ファイルは user, global レベルと異なる project レベルでの Custom instruction で、Cline 内での全ての指示に対してシステムプロンプトとして影響を与えます。(参考: ドキュメント > .clinerules File)
実際にこのリポジトリで紹介されている .clinerules
の中身を見ていくと、人とコーディングエージェント双方に向けた内容になっています。チームのコード規約がコーディングエージェントへのシステムプロンプトとして整備される時代もやってくるんだろうなと思いました。また、こういったエージェントへの指示では test や lint はよく見ますが、型定義の方針や実装時の使い分け(Deno の書き捨てのスクリプトとしてか、複数ファイルで構成するか)まで指示されているのは参考になると感じました。
本項の執筆者: @uta8a
新しい curl コマンドの使い方 完全ガイド(2025年版) #ShellScript - Qiita
curl の TIPS 集です。curl のオプションをはじめとして、種々の便利な使い方が紹介されています。
個人的に面白かったものは以下です:
- クエリー文字列を組み立てるオプション
--url-query
- このオプションで指定するバリューは、自動的に URL エンコードされるとのことです。
- JSON データを POST するオプション
--json
-
--data [arg] --header 'Content-Type: application/json' --header 'Accept: application/json'
のショートハンド
-
雰囲気で使っていた curl の全体像が見えてよかったです。
本項の執筆者: @ajfAfg
tool 🔨
read more 🍘
Productivity Weekly で出たネタを全て紹介したいけど紹介する体力が持たなかったネタを一言程度で書くコーナーです。
- news 📺
-
know-how 🎓
-
モジュール数 100+ の Go Monorepo の CI を改善した話
- 具体的な構成が載っているので、go で Monorepo をしている場合は役立ちそうです。
- GitHub Artifact Storage が何を指しているのか(おそらく upload-artifact/download-artifact で使っているあの artifact?)気になります。
-
脆弱性報告で GitHub から $4,000 貰った話
- GitHub で脆弱性を見つけた時の流れから、確定申告まで詳細に書かれています。GitHub Pro が永年無料になったりするんですね...
-
モジュール数 100+ の Go Monorepo の CI を改善した話
- tool 🔨
あとがき
最近寒い日が多く、寒くない日は花粉が飛んでおり、大変な時期ですね。体調に気をつけていきましょう!
サイボウズの生産性向上チームでは社内エンジニアの開発生産性を上げるための活動を行なっています。そんな生産性向上チームが気になる方は下のリンクをクリック!
Discussion