GitHub Codespaces を触ってみる

モチベーション

研修環境を GitHub Codespaces でつくるのサイコーじゃんと思っていて、実際どうやってつくるのか試してみる

受講者が Codespaces を使う

とりあえず研修受講する側の使い方から。

• ブラウザから使う
• VScodeから使う

ブラウザから使う

特に難しいことはなく、 GitHub で Dev Containers ( Codespaces 用の設定がある) に対応したリポジトリを開き、 [Use this template] > Open in a codespace を押す。

そうすると、セットアップ中と表示されたタブが開く。

待っていると数分で、 VScode そっくりの画面が開いたらオシマイ。 マジか ...

なお使ったのは、このテンプレート。 また起動中は自身の GitHub アカウントの Codespaces で開いている。

microsoft/vscode-remote-try-php: PHP sample project for trying out Dev Containers

Codespace の停止

ブラウザを閉じてから 30 分で自動終了するのだけど、 60 時間と限られた時間なので、終了処理を忘れずにやる。

• ブラウザの VScode から停止する

  1. config ボタンからコマンドパレットを開く（ or Windows なら ctrl + shift + p ）
  2. コマンドパレットに codespase と入力し始めると候補が出るので Codespases: Stop Current Codespase を選択
  3. しばらくして Codespase is Stopped と表示されれば停止
     

• 自身の Codespace の一覧画面から停止する

  1. Codespaces を開く
  2. 使っている Codespace のメニューから Stop codespace を選択 → Stopped というメッセージが表示されれば停止完了

Codespace の削除

これも 30 日間動かしてなければ、通知の上、自動で削除されるのだけど、間違えて動かしてしまうのもアレなので削除しよう。

停止処理とほぼ同じだけど、念のため。

1. Codespaces を開く
2. 使っている Codespace のメニューから Delete を選択 → ダイアログがでるので yes を選択
   

VScode から使う

ブラウザだけでなく VScode からも使えるのだけど、 Docker が必要なので、今回は遠慮する ... 。

はよ、 Docker にせねば、というところなんだけど、 Vagrant で作ってしまった Web メディアの開発環境があるので、それを移行するのがツラい。

トレーナー（研修を実施する側）が Codespace を使う

こっちが本題。

ワンクリック・ノービルドで研修環境を構築できて、受講者には PC (スペックを問わない！) とブラウザだけ用意してもらえれば OK なので、トレーナーからしても魅力的。

template リポジトリをつくる

受講者には先程のようにブラウザから使えるのが理想なので、そうするには template リポジトリを作って公開するのが一番良い（ private リポジトリでも OK なんだけど、その場合、いちいち invite したり、 Organization に入れたりメンドイ）。

今回は PHP / Laravel (フロントエンドまでやるかは不明) の環境を作る。

大きな手順はこんな感じで、以降は公式ドキュメントを参考にしながら進める。

Setting up a template repository for GitHub Codespaces - GitHub Docs

1. 雛形となるテンプレートを選ぶ
2. リポジトリをつくり .devcontainer ディレクトリを作成
3. devcontainer.json を作成
   • core 数などの指定
   • 使用する設定ファイル (dockerfile など) を指定

Laradock を fork してやってみる

ものは試しということで、一旦、 Laradock を fork して Codespaces を立ち上げてみる。

Laradock の .devcontainer.json を用意する

Laradock を fork する。 fork する際、わかりやすいよう -template という名前をつけた。

sezemiadmin/laradock-template

template-test というブランチを切る

template-test

すでに .devcontainer/devcontainer.sample.json があるので、それを devcontainer.json に変更してコミット。

Remove sample

ちなみにローカルで行っても意味がないので、画面ですべてやっている。 なんだか怖い ... 。

image や hostRequirements も追加しようと思ったんだけど、とりあえずこれで動かしてみてエラーが発生したなら追記しようと考え、とりあえずこれで Codespaces が動くかやってみる。

Codespaces で動かす

ブランチを開いて、 [<> code ▼] でメニューを開くと、 Create codespace on template-test メニューができているので、それを押す。

いつもの setting up 画面が表示され、無事に立ち上がった！

git や PHP などのバージョン確認をしたところで今日は一旦おしまい。

• git git version 2.25.1
• php PHP 7.3.27 (cli) (built: Mar 18 2021 08:29:27) ( NTS )

mysql は動かず、 php artisan serve も動かないので、この辺は次回確かめてみる。 たぶん、 Laradock を動かす手順が必要なんだろう。

Laradock をベースにするのは断念

docker in docker で開いた codespace に docker をさらに入れることも考えたけど、初手で docker in docker で試すのは、ちょっと記事からすると趣旨が違うので（ docker in docker を使えるようにするのではない）、 Laradock をベースにするのは断念。

同時に template リポジトリも削除。

他候補を探す

laravel codespaces devcontainer のようなクエリで GitHub 内なり、ググったりで、 探す -> 試す をやってみるも、 php artisan や mysql がないと言われる。

で、そんなときに GitHub 内を探していると、 topics で template を扱っていたことを発見。

codespaces · GitHub Topics

php でフィルタして候補を探す。

新しいテンプレートに切り替え

topics で探したテンプレートのうち、 flemzord/codespaces-laravel を試したところ、 php artisan コマンドで無事に表示された！

flemzord/codespaces-laravel

というわけで、これをベースにする。

PostgresSQL -> MySQL に切り替え

ベースにした codespaces-laravel では PostgresSQL を使っていたので、これを MySQL にする。

1. .devcontainer/docker-compose.yml の image を変更

  app:
    build: ./docker/app
    # 中略
    environment:
        APP_ENV: local
        PHP_EXTENSION_XDEBUG: 1
        # PHP_EXTENSION_PGSQL: 1
        # PHP_EXTENSION_PDO_PGSQL: 1
        PHP_EXTENSION_MYSQLI: 1
        PHP_EXTENSION_PDO_MYSQL: 1
    # 中略
  db:
    image: mysql:5.7
    restart: unless-stopped
    ports:
      # - 5432:5432
      - 3306:3306
    environment:
        # POSTGRES_DB: laravel
        # POSTGRES_USER: laravel
        # POSTGRES_PASSWORD: laravel
        MYSQL_DB: laravel
        MYSQL_USER: laravel
        MYSQL_PASSWORD: laravel

2. .env を変更

# DB_CONNECTION=pgsql
# DB_HOST=db
# DB_PORT=5432
DB_CONNECTION=mysql
DB_HOST=mysql
DB_PORT=3306

Codespace を起動してみるも mysql コマンドが使えず

これで Codespace を起動してみると、無事に動きました。

試しに artisan migrate でテーブルを作成してみると、これも無事に通りました。

$ php artisan migrate --database
Migration table created successfully.
Migrating: 2014_10_12_000000_create_users_table
Migrated:  2014_10_12_000000_create_users_table (84.84ms)
Migrating: 2014_10_12_100000_create_password_resets_table
Migrated:  2014_10_12_100000_create_password_resets_table (37.35ms)
Migrating: 2019_08_19_000000_create_failed_jobs_table
Migrated:  2019_08_19_000000_create_failed_jobs_table (60.87ms)

mysql 動いてるやん！ と心躍りながら、 mysql --version を実行してみると ... 、 mysql コマンドは無いとのこと。 えっ、 migrate できたのに !?

ps a でも mysql はなく（ apache2 は動いていた）、 service mysql status でも mysql は認識されていないとのこと（ apahe2 は動いていた）。

なぜ！？

前回のログから、試行錯誤しつづけ、というよりハマりまくり、はじめて環境構築をしたときと同じぐらいだった。 3 日間溶かしてしまった ... 。

というわけで、ハマったポイントなどをつらつら残しておく。

Docker Compose 知ってるつもりで知らなかった問題

前回のログでも試してみていたように、 codespace で開いたコンテナに mysql が入っているものと思っていたのが、そもそもの大きな間違い。

docker-compose.yml を見てみると、

services:
  app:
    # 中略
  db:
    # 中略
  redis:
    # 中略
  mailhog:

とあるので、 app / db / redis / mailhog がそれぞれ別コンテナになっていて、 default ネットワークで繋がっているのだった。

なので、codespace の workspace として開くようになっていたのが app で、そこで mysql を探しても当然ながら無いのだった。 orz

app コンテナから他コンテナが見れない問題

通常の Docker compose なら開発者 PC なりの host が各種コンテナを立ち上げ、 host から docker ps などのコマンドでコンテナの状態を知ったり操作するのだが、 Codespaces の場合、この host は GitHub のコンテナであり、これに入って作業するわけではなかったのだった ... （ app コンテナに Codespace の workspace があった）。

というわけで、 app コンテナからは db などのコンテナが動いているのかどうかもわからず、なんとか Codespace の creation log を追って、 create db -> done してるやん、とわかるぐらいだった。 なので、 db コンテナが出来上がったのはわかるけど、中がどうなっているのかはわからんという状態だった。

これが致命的で、 php artisan migate の実行エラーが起こっても、

php_network_getaddresses: getaddrinfo for db failed: Name or service not known ( # 略

そのエラーメッセージからだけしか状態がわからず、ググっては試し -> エラー、ググっては試し -> エラー の循環をただただ繰り返すことになってしまった ... 。 ツラかった。

ちなみに最終的にわかった原因は、

• db というホスト名がついてなかった
• laravel という DB が作れていなかった

この 2 つだった。

docker-from-docker に救われる

手探りで db ホストを正しく立てられるようにするのは諦め、 app コンテナから host もしくは db の状態がわかる手段を探す方に切り替えた。

app コンテナに docker 入れればいいんじゃね、と思ったけど、それだと app コンテナから別のコンテナが立ち上げることになるから、うーん、とググっていたところに出会ったのがこれ（検索クエリを忘れてしまった ... ）。

Dev Container 環境で Docker を使う - Qiita

いや、マジで神記事でした ... 。 先人に感謝しかないです。

docker-in-docker ではなく、 docker-from-docker なら app コンテナから host の docker を動かせるというもので、「まさしく、求めていたのはこれ！」。

というわけで、 devcontainer.json に docker-from-docker を入れてみたところ、

app コンテナで docker version が動く！動くぞ！
docker ps が動いた！コンテナちゃんたち、ちゃんといたのね！
docker exec で db コンテナ入れるやん！

となったのだった。

MySQL 特有の問題？

docker-from-docker で db の状態がわかるようになり、 docker exec -it conatainer_id bash で db コンテナに入ろうとすると、

Error response from daemon: Container 3f16c721fd2315181363585fc74e06d6d6a26e42946573d3a98042edfa0b1313 is restarting, wait until the container is running

というエラーで入れず。 調べてみると MYSQL_ROOT_PASSWORD 環境変数を入れてないからだった。 MYSQL_USER と MYSQL_PASSWORD を入れておけば OK とあったのに ... 。

MySQLのコンテナを作成したのに再起動し続けるときの対応方法 - Qiita

MYSQL_ROOT_PASSWORD を入れると、 db コンテナに無事に入れた。

これで php artisan migrate が通るかと思いきや、引き続き同じエラーが続く。

hostname がちゃんと指定された db になっているか db コンテナに入ると、コンテナ ID が振られただけの状態だった。 えっ、 MYSQL_HOST=db って指定しているのに！

事実は事実なので、 docker-compose.yml で、

  db:
    image: mysql:5.7
    hostname: db

にすると、無事に hostname が db になった。 そんなん外からは絶対わからんやん。

今度こそ php artisan migrate が通るだろうと思っていたら、またまた同じエラー。

port がちゃんと開いてるのか、と思って確認すると、ちゃんと開いてるし、なぜじゃ、とこれまた悩む。 links プロパティが必要なのか -> 動かん、というのを繰り返す。

ふと、そもそも database ができてるのか、と db コンテナで確認してみると、なんと空っぽ。

えーー。

MYSQL_DB=laravel って docker-compose.yml には書いてるのに！

というわけで、何度か確認してた mysql の公式イメージのドキュメントを改めて見ていると ... 、

MYSQL_DATABASE
This variable is optional and allows you to specify the name of a database to be created on image startup. If a user/password was supplied (see below) then that user will be granted superuser access (corresponding to GRANT ALL) to this database.

ん？ MYSQL_DATABASE ??

アホアホ、 MYSQL_DB にしてるやん！

というわけで、 docker-compose.yml を書き換えて、 php artisan migrate を実行！

$ php artisan migrate
Migrating: 2014_10_12_000000_create_users_table
Migrated:  2014_10_12_000000_create_users_table (205.04ms)
Migrating: 2014_10_12_100000_create_password_resets_table
Migrated:  2014_10_12_100000_create_password_resets_table (187.86ms)
Migrating: 2019_08_19_000000_create_failed_jobs_table
Migrated:  2019_08_19_000000_create_failed_jobs_table (209.16ms)

ヤッターーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー！

「推測するな、計測せよ」という言葉どおりの結末で、なんとか postgresql -> mysql に成功。

というわけで、これで原稿にするぞい。