👋

GitHub Codespaces を Rails のプロジェクトに導入・運用してみた

kaz-e4b880

2024/06/19に公開

タイトル通り、GitHub Codespaces を Rails のプロジェクトに導入・運用してみたので得た知見などを共有します。

メリット・デメリット

メリット

環境構築が不要

数クリック、数分で起動するので下記のような場合に重宝します

オンボーディング時に利用しましたが、環境周りの説明を後回しにしてとりあえず動かしたりできるのはとてもよかったです
別チームの人とか普段触らない人がすぐにコード書いたりテスト実行できる
個人の環境の所為で構築失敗がない

Port Visibility の Public が便利

他の人やスマホからアクセスできるのでとても便利です

アプリ開発中にバックエンドの接続先をこっちにして動作確認等に利用

etc.

複数のブランチを扱っていると切り替えが面倒でしたが、起動してちょっと作業してもとの作業に戻るみたいな使い方ができます
普段 VS Code を使用しているならローカルの VS Code を接続するようにすると違和感はほとんどないです
ローカルで Docker 動かさないので PC 負荷が減ります

デメリット

割と料金がかかる

個人的な印象なのですが、めちゃくちゃ安いって感じではないです

個人の無料枠は毎日使ったりしない限り十分だと思います
組織で使う場合、無料枠なしの従量課金です
- 3 人くらいがたまに使うくらいの想定で 100 [ USD / Month ] に設定したらかなり余裕がありました
- ※もちろん利用状況 ( purebuild の頻度、使用するマシンスペック等 ) によります

変化が早い

古い情報にあたったり、日本語じゃないことは多いです

情報が点在しているので見つけやすくはないです
- ChatGPT とかに聞いた方が早い場合あり
個人的使用して 1 年くらいですが、1 年前は使えなかったりしたものが使えたり、逆に使えなくなってるとかあります

etc.

VM の CPU 使用率、Storage の使用状況は見えないのでエラーの調査は難しいです
他の Container の状況が分かりづらい
- 接続先の Container を加工すれば見られるようになるらしいです

お試し〜運用までの流れ

前提

Rails のみのリポジトリ
docker-compose.yml が存在していた
外部接続する部分もあったが、無視できた

お試し

設定

ディレクトリ構造は以下の通りです

project-root/
│
├── .devcontainer/
│   ├── devcontainer.json
│   ├── docker-compose.override.yml
│   └── on_create_command.sh
│
├── app/
│   ├── controllers/
│   └── models/
│
└── docker-compose.yml

設定ファイルの一部抜粋

.devcontainer/devcontainer.json

{
  "dockerComposeFile": [
    "../docker-compose.yml",
    "docker-compose.override.yml"
  ],
  "service": "web",
  "runServices": ["web", "db", "redis", "smtp"],
  "postCreateCommand": "sh .devcontainer/on_create_command.sh",
}

凝った構成じゃなければ基本のままで動くと思うので変えてる部分のみ説明します

project-root に docker-compose.yml があるので相対パス指定して Codespaces 用に変えたい部分は .devcontainer/docker-compose.override.yml に書いてます
すべて起動すると重かったので runServices で起動したいものだけ起動しています
- 起動の指定なので build はされます
bin/rails db:create 等は .devcontainer/on_create_command.sh 内に書いてます
- 複数行だと読みづらかったので別ファイルにしました

etc.

お試しで個人設定だったので個人の無料枠を消費してます
個人が Free プランだと 2-Core, 4-Core のみ使用できます
個人でも自動で停止、消す設定は入れた方が無難だと思います
- 消し忘れで Storage の無料枠を全部使い切るとか過去にやりました

導入

お試しで安定して動くようになったので、チームで使うためにやったことは以下の通りです

Codespaces の料金を個人から組織に変更
Limit spending の設定
- これを設定するまで起動できないと思います
Policy の設定 ( コスト削減 )
- Machine types
  - 短期的には必要なさそうな 16-core のみ使えなくしました
- Maximum retention period
  - 消し忘れても大丈夫なように 1 [ day ] に設定しています

運用

build に時間がかかって起動までが長かったので prebuild で解消しました
※prebuild は Codespaces 起動時に発生する Docker image build などを予め実行し Storage に保存することで起動を高速化する機能

起動時間が 15 [ m ] -> 2, 3 [ m ] に短縮できました
設定は↓の通り
- Region availability
  - prebuild が使用できる Region の設定
    - 設定した Region 以外では prebuild は無効になる
  - Southeast Asia のみ設定
    - Region * versions で料金が変わるので絞ってます
- Template history
  - prebuild した template を何 version 分保存しておくかの設定
    - 新しい template を作る際に古いものから破棄
  - 2 [ versions ] に設定
    - 1 [ versions ] だと prebuild の GitHub Actions 実行中は prebuild したものが利用できない
prebuild は時間がかかる & 割と料金がかかる
- 私が適用した PJ の場合 4-core で build した場合の 4 ~ 5 倍の時間がかかりました
- GitHub Actions で prebuild するのでその料金がかかります
- 起動時に build する場合、build している時間も CPU クレジットを消費するので速さとコストを見てこの辺は調整が必要だと思います
prebuild は設定したブランチから派生したブランチでも有効

その他

細かい使用量などは Billing & plans の usage report で見ることができます
prebuild 中は大丈夫だが、通常 build 時は Storage 不足になる場合があるので注意
- docker-compose.yml に色々書かれていたり、 multi-stage build を利用している場合は注意が必要
別 PJ の話ですが、 submodules を利用している場合は下記のように設定すること利用できます
```
"initializeCommand": "git submodule update --init",
```
- 権限で clone できない場合があるので注意

参考記事

Linc'well, inc.Publication

医療スタートアップ Linc'well のエンジニアの記事を集めています。

メリット・デメリット

メリット

環境構築が不要

Port Visibility の Public が便利

etc.

デメリット

割と料金がかかる

変化が早い

etc.

お試し〜運用までの流れ

前提

お試し

設定

etc.

導入

運用

その他

参考記事

Discussion