Questions[capistrano](server)

I use Amazon EC2 for my mobile app. Depending on load of the application at a given time, I might spawn new instances and then take them down when load is lower to save costs.

How does one keep up with Nagios configurations for such a dynamic environment? When one deals with managed hardware, configuration files are predictable. In this case Nagios, Capistrano and a bunch of other configuration files would need to be added. Capistrano needs to know where to deploy a new build to for an app server. Nagios needs to know to remove an existing instance or add a new instance for monitoring. Nagios also needs to know if a node was intentionally taken down or if the host is down due to error.

How is this done with the wonderful world of VPS/dynamic instances?

We use capistrano for website deployments and our Apache document root is a symlink to a particular code release. The deployment procedure switches the symlink from the old release to the new release as the final step of the deployment.

We are migrating our webservers from real servers running RHEL 5.6 to Amazon EC2 virtual machines running Ubuntu 11.10 and the new servers are suffering from a problem where Apache doesn't immediately notice the change to it's document root when the symlink is switched. It can take a second or so (and I think I've even seen it take a couple of minutes). It's kind of like Apache has cached the physical path of the symlink for some time.

Does anyone know some Apache settings I could look at to get it to "scan" for changes to it's served files quicker.

Thoughts:

• I read that the disks on virtual machines are much slower (since they are network attached storage). Perhaps the filesystem cache somehow works differently too? If so, is there anything that can be done?
• The website runs PHP code. Perhaps there is some PHP config differences between RHEL and Ubuntu? I checked realpath_cache_ttl but both servers have it commented out:

e.g.

; Duration of time, in seconds for which to cache realpath information for a given
; file or directory. For systems with rarely changing files, consider increasing this
; value.
; http://www.php.net/manual/en/ini.core.php#ini.realpath-cache-ttl
;realpath_cache_ttl = 120

• We do use the APC opcode cache but don't think it's the issue due to experimentation. The PHP code is in different file paths for each deployment and we ensure stat=1.
• Here is a similar question that is very interesting: 294107 - but doesn't provide an answer for me.
• One solution would be to reload Apache everytime we modify the document root symlink. I'll do this if we can't find another solution.

If a team is used to using Capistrano for application deployments, what is the compelling benefit of switching to MCollective, or adding it into the mix? The team is already taking on the task of adopting Puppet for system configuration management, so there is a question of how much to learn at once.

On RedHat/CentOS systems, all of the service management scripts in /etc/init.d (and also run by the "service" command) produce color output. (i.e. the "[ OK ]" and "[FAILED]" strings.) How do I disable this? (The color-producing escape sequences are making the webistrano output more ugly than it needs to be.)

We have a PHP web application we are deploying to a LAMP server running CentOS 5.5 using Capistrano. Capistrano manages switching to the latest version (and rolling back) using a symlink, so our document root has to point to that symlink.

Unfortunately, we have been seeing that web requests to the PHP application still point to the previous target of the document root's symlink for exactly 60 seconds after the symlink is updated.

The only setting in the PHP config I could find that might relate to this is the realpath_cache_ttl setting, however this is set to 120 seconds. I couldn't find anything in apache's configuration.

We are not using APC.

Am I even looking in the right place?