S3のコンテンツを管理したい
そのWebサービスでは画像やJS、CSSなどの静的リソースをAWSのS3に上げて利用していたのですが、マネコンから手動でアップロードしている状態でした。
そのため、量が多いと作業も大変ですし、抜け漏れなどの人的ミスも発生していました。
元々その静的リソースはgitにも保存していたので、gitで管理しているリソースをawsのcliで aws s3 sync で同期した方が確実だし楽じゃん！、と思いデプロイ手順を変更しました。
gitとs3の手動同期
そもそも今gitとs3の中身って本当に同じなの？、という疑惑があったので、 aws s3 sync で全差分を出して一つずつチェック。
S3にしかないもの、gitにしかないもの、これどこで使ってるの？、みたいなファイルが山ほどあり、調整は時間を要しましたが、基本はS3に上がっているものが正なので、差分はS3のものを残す方針で、どうにかgitとS3のリソースを完全一致させることができました。
デプロイ手順の変更
- dryrunで差分を確認。ルートパスでやると余計な差分出てしまうかもしれない＆時間かかるので、最小の範囲のパスで。
aws s3 sync path_to_target_localdir/ s3://BACKET/path_to_target_s3dir/ --delete --dryrun
- 意図通りの差分であることを確認して、OKだったら実行
aws s3 sync path_to_target_localdir/ s3://BACKET/path_to_target_s3dir/ --delete
この方式でデプロイするようにし、作業はだいぶ楽になりました。
それから3ヶ月後
新しいデプロイ手順にも慣れ、いつも通り本番デプロイした後に、「このページの画像が全部でなくなったんだけど」 との問い合わせが・・・。
そのページは独自のCMSで作られているページで、記事や画像を管理画面から入力して生成する機能でした。
削除された画像のパスを見て、3ヶ月前のある記憶が蘇りました・・・。
（3ヶ月前の記憶）
「このS3のフォルダ、大量に画像上がってるけど、gitには一つもないなあ。なんだこれ」
「うわ、CMSの画像アップロード先、静的リソース置き場になっちゃってるじゃん・・・」
「どこかのタイミングで、アップロード先変更しないとなあ」
「とりあえずは、同期する時にこのフォルダ除外するようにしておこう」
そう、調査のときに一つ除外しないといけないフォルダを確認していたのにも関わらず、すっかり忘れていました。
デプロイ時にdryrunで差分をチェックする手順でしたが、作業慣れからチェックが形骸化しdryrunは実行するものの「まああってるでしょ」みたいなノリで異変を見逃され、gitにはないアップロード画像数百枚全削除 の同期が実行されてしまいました・・・。
幸い、元になる画像は運用担当者の手元に残っていたので、全て上げ直してもらうことで復旧はできました。
運用方法の変更
aws s3 sync には exclude の除外オプションもありますが、また別のフォルダで起きるかもしれないので、根本的に変えました。
-
aws s3 syncは禁止 - ファイルの追加は
aws s3 cp、削除はaws s3 rmで一つずつ実行- 事前にスクリプトを用意しておく
- コマンドの実行ログを記録に残す
- そもそも静的リソース置き場をgitで管理しないCMS等のアップロード先にしない
ヨシ！
現場ネコの 「前の2人が合格にしてるんだから絶対ヨシ！」 を思い出しました。