PHP5.5+OPcacheでシンボリックリンクでデプロイするとキャッシュが消えない - オープンソースこねこね
という問題にぶち当たりました。 どういうことかを話す前にPHPアプリケーションの個人的なデプロイ構成について説明します。 要はCapistranoのデプロイと同様なのですが、デプロイ先は以下のようなディレクトリ構成になっています。 . |-- current -> /path/to/releases/20141011000001 |-- releases | |-- 20141011000000 | `-- 20141011000001 currentがアプリケーションサーバ(apacheやphp-fpm)から参照される箇所で、releases配下の最新のアプリケーションへのシンボリックリンクになっている。新しくアプリをデプロイするとreleases配下に20141011000002のようなタイムスタンプで新しくディレクトリが作成され、そこにアプリケーションのコードが配置される。その後cu
AWS + Capistrano + PHP + Opcache でデプロイが反映されない - pospomeのプログラミング日記
AWSの問題かな? と思ったが違った。 以下によるとPHPのOpcacheはシンボリックリンクの切り替えではクリアされないっぽい。 http://kohkimakimoto.hatenablog.com/entry/2014/09/13/154342 なので、Capistranoでデプロイすると 「ソースコードは変更されているはずなのに前と挙動が変わらない」 という現象が発生する。 どうすればいーのか? 結論から言うと、Capistranoでデプロイ後に php-fpm を reload するタスクを deploy.rb に追加しました。 namespace :deploy do # ここが追加した部分 desc "clear opcache" task :clear_opcache do on roles(:web) do execute "/etc/init.d/php-fpm rel
jailing - chroot jailを構築・運用するためのスクリプトを書いた
個人サーバで外部に公開するサービスを動かすときには、chrootを使うにこしたことはないわけです。サービス毎にchrootしてあれば、サーバソフトウェアにセキュリティホールがあっても、他の情報が漏洩したりする可能性をぐっとおさえることができるわけですから。 でも、そのためだけにVPSにdockerとかコンテナを入れて使うってのは、構築も運用もめんどくさいし、ディスク容量食うし、やりたくない。systemd-nspawnも割と重たい雰囲気だし、LTSなubuntuだとそもそもsystemd入ってないし… 俺たちがほしいのは、ホストの環境の一部のみにアクセスできる、手軽なjailだー！ ってわけで、ざっくり書いたのが、jailing。 /usr/bin等、OS由来のディレクトリをchroot環境にread-onlyでエクスポートしつつ、指定されたコマンドを、そのchroot環境で動かすスクリプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
