GitHub Codespaces の無料枠を無駄にしないために
Github Codespaces とは
codespace は、クラウドでホストされている開発環境です。 構成ファイルをリポジトリにコミットすることで、GitHub Codespaces のプロジェクトをカスタマイズできます (コードとしての構成とよく呼ばれます)。これにより、プロジェクトのすべてのユーザーに対して繰り返し可能な codespace 構成が作成されます。
ref: https://docs.github.com/ja/codespaces/overview
つまりいつでもどこでもぱぱっと開発環境が準備できるべんりなやつ!
Codespaces 無料枠の有効活用を考える
2022年11月に GitHub Codespaces が全ユーザーに向けて開放され、合わせて無料枠の付与も発表された。
ただしこの無料枠、使い方を間違えると途端に使い果たしてしまうものでもあるので、手元で動かしてわかったことをもとに、個人的な「こんな感じに使うといいんじゃないかな」を書いてみる。
(使っていたら枠が超速で消費されて「なんじゃなんじゃ!」となった…)
※個人開発用途がメインのため、チーム利用観点での情報はあまり書けていないと思う
You はどうして Codespaces を?
- 普段利用しているOS、マシンが複数種類あり、それぞれで環境構築を行うことが面倒なこと
- コンテナ技術、設定ファイルを書くと同じ環境が立ち上がる、という開発体験が好み
この2つが主な理由な気がする。
メイン PC は Windows Desktop、仕事では Linux Laptop、外出先では Macbook Air(AppleSilicon M2)を使っている。
PCのデータを吹き飛ばすこともよくあるので、できる限りポータブルな開発環境を使いたい、というニーズに Codespaces がはまっている。
はやい、うまい、やすい
読むのはめんどくさいけどとりあえず向け
- Prebuild を使うのは控えておいてもいいかも
- コストが膨れやすい
-
https://github.com/settings/billing の usage report はこまめに確認しよう
- どこにいくらかかってるのか確認できる
以降で詳しく見ていく
Codespaces の課金形態
Usage hours
と Storage
の二種類の計測項目があり、それぞれ別の基準でカウントされる。
どちらかが尽きると、追加のお金を入れるまで Codespace が利用できなくなる。
ので、片方だけ先に使い切ってしまった、みたいな状態になるともったいない。
どういったリソースを使うとどの程度コストがかかるのかをざっくりとでも把握しておけば、バランス良く無料枠を利用できる。
Usage hours(Computing)
マシンの稼働時間 * コア数
で計算されるコンピューティングの使用量をカウントする。
無料枠の 60h というのは 2Core のマシンを動かした場合の上限で、4Core で動かす場合、稼働時間の上限は 30h となる。
何コアのマシンを動かしているか、何時間稼働させたか、は把握しやすい情報だと思うので、「え?もう上限ひっかかったの?」とはなりにくい気がする。
目を離した隙に停止状態に移行してしまった!という場合でも1分程度で再稼働するので使いやすい。
デフォルトでは、30分無操作であれば停止する設定になっている。
A codespace will stop running after a period of inactivity. By default this period is 30 minutes
ref: https://docs.github.com/en/codespaces/customizing-your-codespace/setting-your-timeout-period-for-github-codespaces
Storage
total storage size / hours this month
で計算される。
計算対象となるのは主に下記
(他になにかあったっけ?と思ったけど全量かわからないので予防線)
- 稼働中/停止中の Codespace コンテナでの消費
- Prebuild 機能での消費
- くせもの。
Codespace コンテナでの消費
稼働中、停止中に関わらず、https://github.com/codespaces で確認できる作成済みコンテナでの利用ボリュームに応じてコストがかかる。
ただし、 公式イメージをベースにセットアップされたコンテナ に関しては、ベースの公式イメージサイズ分が、計測対象から除外される。
よって、お得に使うには、必要なパッケージを十分に揃えたイメージを公式で用意されたものである https://github.com/devcontainers/images/tree/main/src から選んで利用するのが良いのではないかと思う。
mcr.microsoft.com/devcontainers/universal:linux
あたりは基本的なパッケージがまるっと入っていて使いやすい。デフォルトで Codespaces を立ち上げたときに使われるのもこのイメージ。
公式の軽量イメージにカスタムでパッケージを追加して使うよりも、全部入りパッケージを使ってしまったほうが、コンテナ作業で消費される Storage コストの観点ではお得になる。
下表は請求例
実験ref: https://zenn.dev/link/comments/b00e2e3239d43c
-
universal:linux
: $0.002/day- ほぼ素
-
base:focal
: $0.004/day- feature 機能でいくつかパッケージを追加したが、実態は
universal:linux
よりかなり軽いはず
- feature 機能でいくつかパッケージを追加したが、実態は
https://github.com/codespaces を確認して、使っていないコンテナはこまめに削除しておくのもコスト削減に有効。
https://github.com/settings/codespaces から自動削除の期間も設定できる。(下画像)
デフォルトは30日。削除前にはメールでお知らせが来て、無視していると勝手に削除される。(たぶん)
Prebuild 機能での消費
Prebuild ってなんだ
Codespaces で使うコンテナイメージを先にビルドしておき、すぐに起動できる状態にしておく機能。
カスタムしたイメージを使ってコンテナを起動する際にビルド時間が長くなってしまう場合に使ったりすると便利。
Prebuild のコスト感
storage size = price per GB * size (GB) * regions * versions
で算出される。
ref: https://docs.github.com/en/billing/managing-billing-for-github-codespaces/about-billing-for-github-codespaces#billing-for-codespaces-prebuilds
- Prebuild したイメージは保持され続けるため、常時コストがかかっている状態になる
- 公式イメージを使っていても関係なくコストにカウントされる
- 可用性の設定次第(regions, versions)で使用量が大きく変動する
- buildのコストは GitHub Actions の枠が消費される
Prebuild は上記のような特徴があり、コスト管理をする上で気をつけたほうが良いと思われる点がいくつかある。
公式イメージを使っていても関係なくコストにカウントされる
Codespace コンテナのストレージカウントからは除外されていた公式イメージの枠は、Prebuild では除外されずすべて計測の対象になる。
mcr.microsoft.com/devcontainers/universal:linux
のイメージが便利で使っていて、その状態で Prebuild の機能を有効にすると下表のような請求(手元の実験で$0.25/day)になり、すぐに無料枠を使い切ってしまう。
可用性の設定次第で使用量が大きく変動する
コストの算出式の regions * versions
部分について気をつけたい。
デフォルトで 4regions * 2versions
(4地域で2バージョンずつ保持する) の設定になっているため、イメージサイズの8倍のストレージコストがかかり続けることになる。
公式イメージを使っていても関係なくコストにカウントされる
であげた請求表は、このデフォルト設定で Prebuild 機能を使った場合のものなので、これを 1region * 1version
に制限すると、下表のようにコストが激減する。($0.25/day -> $0.03/day)
- リポジトリ/Settings/Codespaces でセットアップを行う際に設定可能(後から変更もできる)
-
https://github.com/settings/codespaces からデフォルトで利用する region も指定可能
コスト管理まとめ
- 全般
- 定期的に https://github.com/settings/billing の usage report を確認してコスト感を確認してみるのがよさそう
- 設定したことを忘れていた Prebuild にも気付ける
- 膨れている所があれば削減できるところがないか設定を見直してみる
- 定期的に https://github.com/settings/billing の usage report を確認してコスト感を確認してみるのがよさそう
- Computing
- 2-4Core くらいであれば、Compute の使用量はそんなに跳ねない。料金も「そんなもんかな」の範囲内に思うので、積極的に活用すると良さそう
- Storage
- Prebuild
- 特に要件がないのであれば、利用 region は絞っておく
- 公式イメージも全てコストにカウントされる。特に universal 利用時に使うと Storage コストが大幅に消費されるので、使う際は要注意
- 軽量イメージでビルドする場合でも、毎日積み重なるコストになるので、Storage 消費が激しくなることには変わらず注意しておく
- Container
- 公式イメージ(https://github.com/devcontainers/images/tree/main/src)を使うと、コンテナでの消費を抑えられる
- 十分なパッケージがすでに含まれている universal は便利
- 非稼働コンテナもコストがかかってくるので、https://github.com/codespaces を確認して使っていないものはこまめに削除してく。削除期間を短めに設定するのもよい
- 公式イメージ(https://github.com/devcontainers/images/tree/main/src)を使うと、コンテナでの消費を抑えられる
- Prebuild
Links
- 請求確認
- Codespaces可用性設定
- 作成済みのCodespacesコンテナ一覧
- 公式コンテナ一覧
Discussion