だめと書いてますがサーバーが1台の場合は特に問題ないと思います。
また、Blue-GreenDeployにおいてもあまり気にする必要はないかもしれません。
今回はローリングアップデートでデプロイした際にphp artisan cache:clearで駄目だったのでその回避方法を紹介します。
ローリングアップデートで死ぬ
今回はサーバー（インスタンス）が２台あり、それぞれをローリングアップデートでデプロイしているケースです。
１台目のデプロイ時にphp artisan cache:clearでキャッシュを消していました。
このとき、２台目のまだリリースが完了していないアプリケーションにリクエストが流れ、そのキャッシュが作られたことにより、１台目のアプリケーションでキャッシュから取得したデータがロジック変更によりエラーになってしまいました。
ではどうしたらよかったか。
違うキャッシュキーを参照するようにする
１台目と２台目でキャッシュキーが異なれば１台目ではキャッシュが取得できないので新たに取得処理・キャッシュ生成が行われます。また、そもそもキャッシュをクリアする必要すら不要になります。
デプロイする都度、その世代のキャッシュキーを生成することで問題は解消されます。
Laravelのconfig/cache.phpにはprefixという項目があり、CACHE_PREFIXという環境変数で変更できます。
'prefix' => env(
'CACHE_PREFIX',
str_slug(env('APP_NAME', 'laravel'), '_') . '_cache'
),
※CACHE_PREFIXはキャッシュをfileやarray指定時には利用されません。
デプロイの都度一意のキャッシュキーを生成
今回はCircleCIでの例です。
echo -n "CACHE_PREFIX=" > .env | echo $CIRCLE_SHA1 | cut -c -10 >> .env
CircleCIでは$CIRCLE_SHA1で最終コミットのハッシュが取得できます。これを利用し、この先頭から10桁を.envに書き出しました。
これでデプロイする都度キャッシュキーはリフレッシュされます。
同じことでお困りの方がいたら参考にどうぞ。
追記
DBのキャッシュとセッションキャッシュが両方消えて困った！という方は次の方法をご検討ください。
まずはmemcachedの設定をDB向けとセッション向けで分離します。
'db_memcached' => [
// 内容はmemcached項目を参照
],
'session_memcached' => [
// 内容はmemcached項目を参照
],
そして.envのDBのキャッシュドライバとセッションストアの指定を変更
CACHE_DRIVER=db_memcached
SESSION_STORE=session_memcached
これでDBのキャッシュとセッションのキャッシュを分離できました。
続いてdb_memcachedのみprefixを与えます。
'db_memcached' => [
// 内容はmemcached項目を参照
'options' => [
Memcached::OPT_PREFIX_KEY => env('DB_CACHE_PREFIX', '')
]
],
あとは先程のデプロイ手順同様にDB_CACHE_PREFIXを生成してあげることでデプロイ毎にDBキャッシュだけ更新されます。
めでたしめでたし。