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

前回は Rails プロジェクト向けでしたが、今回は Rails + フロントエンド + etc. を含むプロジェクトに導入・運用してみたので得た知見などを共有します
前回の記事は↓です

https://zenn.dev/lincwell_inc/articles/61bff901f293e9

プロジェクト概要

リポジトリは下記のように分割されています

• バックエンド ( Rails )
• フロントエンド ( React )
• etc. ( 認証関連 )

バックエンドのリポジトリには Rails 以外にもいくつかのコンテナが含まれています

• 含まれるコンテナ
  • Rails
  • DB
  • Redis
  • .etc.

前提

• 各 Dockerfile 作成済み
• Local ですべてのコンテナが動作する docker-compose.yml 作成済み
• GitHub Codespaces で 8-core 解放済
  • image build に CPU パワーとディスク容量が必要なため
  • 解放のためには以下のいずれかの条件を満たす必要があります
    • 組織管理のリポジトリの場合、Codespaces ownership が Organization ownership
    • 個人管理のリポジトリの場合、Team Plan 以上

構築編

submodule 化

ディレクトリ構成

今回は下記のようなディレクトリ構成にしています

.
├─ .devcntainer
│  ├── devcontainer.json
│  └── docker-compose.override.yml # Local との差分はここに書く
├─ .github/workflows/update-submodules.yml # submodule 更新
├─ バックエンド # submodule
├─ フロントエンド # submodule
├─ 認証関連 # submodule
├─ .gitmodules # submodule 用の設定ファイル
└─ docker-compose.yml # Local で動かすためのファイル

作業方法

1. submodule 追加

   git submodule add <repository>
   

2. 追加したリポジトリのディレクトリに移動して、対象のブランチに切り替え
3. .gitmodules の branch に対象のブランチを設定
4. 更新が必要な場合は下記のコマンドで更新

   git submodule update --remote
   

.devcntainer の設定

submodule 関連で必要な設定は下記の通り

  "dockerComposeFile": [
    "../docker-compose.yml",
    "docker-compose.override.yml"
  ],
  "service": "service", # 接続したい Service を設定
  "initializeCommand": "git submodule update --init", # submodule を clone するためのコマンド
  "customizations": {
    "codespaces": {
      "repositories": {
        "<organization>/<バックエンド リポジトリ>": {
          "permissions": "write-all"
        },
        "<organization>/<フロントエンド リポジトリ>": {
          "permissions": "write-all"
        },
        "<organization>/<認証関連 リポジトリ>": {
          "permissions": "write-all"
        }
      }
    }
  }
}

• initializeCommand, customizations.codespaces.repositories の部分は必須
  • initializeCommand は最初に実行されます
  • customizations.codespaces.repositories は clone するための権限設定です
    • write-all にしてますが、もっと細かく設定できます
    • 設定していると初回起動時に改めて許可するか確認されます

調整

ここまでの設定ですんなり起動すれば問題ないですが、起動しないときの対策としては以下を試しました

• platform の違い
  • Codespaces は Linux/amd64 なので Apple Slicon Mac 専用になっている場合は失敗します
    • 両方に対応しているイメージを使うのが手っ取り早いです
• コンテナが落ちている
  • スペックの問題か負荷の問題かは不明ですが、Local では問題なくても Codespaces 上だとコンテナが落ちていることがあります
    • 下記をすることで docker コマンドで確認できます
      1. 接続しているコンテナに設定追加
         docker-compose.override.yml

         environment:
            DOCKER_HOST: unix:///var/run/docker.sock
         volumes:
         - /var/run/docker.sock:/var/run/docker.sock
         

      2. パッケージインストール

         apt-get update && apt-get install -y docker.io
         

      3. コンテナ状態確認

         docker ps
         

    • 不安定な場合は docker-compose.override.yml で対象のコンテナに restart: always 設定を入れる
    • postCreateCommand に重い処理を入れると不安定になりやすい気がするので、30 [ s ] くらい sleep 入れると安定します

運用編

CI 設定

submodule の更新が手間なので CI の設定をお勧めします
設定すると cron 通りに全部の submodule が最新化され main に commit されます

.github/workflows/update-submodules.yml

name: Update Submodules

on:
  schedule:
    - cron: '00 15 * * 3,4'
  workflow_dispatch:

jobs:
  update-submodules:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout repository including submodules
      uses: actions/checkout@v3
      with:
        token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}
        submodules: recursive
        fetch-depth: 0

    - name: Update Submodules
      run: |
        git submodule update --remote --merge

    - name: Commit submodule changes
      run: |
        git config --global user.name 'GitHub Actions'
        git config --global user.email '[e-mail]'
        git add .
        git commit -m "Update submodules" || echo "No changes to commit"

    - name: Push changes
      run: |
        git push origin main
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

• on
  • schedule
    • 適宜設定
  • workflow_dispatch
    • schedule でカバーできない場合に備えて設定
• secrets.PERSONAL_ACCESS_TOKEN
  • submodule の clone のために必要

普段

• 追跡ブランチと変えて起動したい場合は PR を作って起動するのがよいと思います

まとめ

メリット

• prebuild を設定していると最新 image が build 済みなのでそこそこ起動が早いです
  • ジョインした直後などに使えそう
• 個人の端末で問題があった場合のバックアップとして使えます
  • とりあえずここで動いてたら全員には影響がないので、っていう考え方ができる

デメリット

• エラーが調査しづらい
  • 他のコンテナの状況やログが見づらい
• submodule はやはり運用が難しい