jump to navigation

Using Ohai to obtain platform September 1, 2009

Posted by John Dewey in Chef, Code, Deployment, Ohai.
add a comment

I have found myself needing to know the operating system platform. Rather than explicitly checking for /etc/lsb-base or /etc/issue to determine if it’s Ubuntu or Debian respectively. Let Ohai do the work for you.

This small gist prints the platform. You can access just about anything you want to know about your system via this method.

Advertisements

using geminstaller with vlad the deployer February 28, 2009

Posted by John Dewey in Configuration, Deployment, Example, Rake, Vlad.
1 comment so far

I really really really like vlad the deployer. I recently switched my apps over to geminstaller vs Rails’ config.gem.

This gist adds in geminstaller functionality to vlad’s update task.

Rails log rotations via rsyslog December 25, 2008

Posted by John Dewey in Code, Configuration, Deployment, Example, Rails.
2 comments

I have a client that logs their rails logs via syslog, for consumption by pl_analyze. I am not a fan of this, and will probably change it at some point. When using Apache, I’ll typically configure rails to use a rotatelogs pipe.

However, in this case, to avoid changing legacy infrastructure around the logs, I setup rsyslog to do the rotations for me. Hopefully this will be useful to someone else.

This assumes your rails app already logs to syslog.

Added the following to /etc/rsyslog.conf.

controlling memcached with Phusion’s daemon_controller September 6, 2008

Posted by John Dewey in Code, Deployment, Memcached, Plugins & Gems, Rails, Ruby.
add a comment

I am working on an application that utilizes memcached, and want to develop against a locally running instance. Previously, we pointed our development environment to a sandboxed memcached cluster, which can be slow depending on time of day, location, and network. I typically mock external resources, however, I like a living memcache.

This post describes a way to start memcached automatically with script/server, and is a continuation of the daemon_controller memcached configuration post.

As the Phusion guys pointed out. Pulling code — and not worrying about configuration is AWESOME! This is especially true in the development environment.

phusion-daemon-controller.png

Adding this to development.rb will automatically start and stop memcached via ‘script/console’ and ‘script/server’. SAs maintain the daemons in the other environments via SMF, nor am I interested in maintaining those environments (did that … done that).

daemon_controller memcached configuration September 4, 2008

Posted by John Dewey in Configuration, Deployment, Memcached, Plugins & Gems, Rails, Ruby.
2 comments

The Phusion guys created a sweeet library (daemon_controller) to control servers or daemons. I created a daemon_memcache class which controls memcached.

Memcached can be controlled programatically by:

DaemonMemcache.instance.start
DaemonMemcache.instance.running?
DaemonMemcache.instance.stop

Will show you how to utilize this class to start/stop Memcached via ‘script/server’ in a follow-up post.

Disable mongrel mod_proxy_balancer workers via Capistrano August 15, 2008

Posted by John Dewey in Capistrano, Configuration, Deployment, Mongrel, Rails, WebServers.
add a comment

I created a Capistrano task for disabling workers inside a given balancer, from Daniel Wharton’s Deploying Rails post.

Here’s the pastie. BTW I really hate linking off to pastie for these things. Any suggestions?

The task disables the worker, and is not specific to Mongrel.

Run a Capistrano task on a single server in a given role February 7, 2008

Posted by John Dewey in Capistrano, Code, Command Line, Deployment, Monkey Patch.
3 comments

There are times I want to run a Capistrano task on a single server, rather than every system in the role. Adding this monkey patch to deploy.rb adds this functionality. To utilize this feature append ‘server=IP_ADDRESS’ to the Cap command. Tasks are defined to run on particular role(s), this feature will target the server inside a particular tasks role. It will not execute a task on an arbitrary server.  CJ Kihlbom filled me in and stated this can be accomplished with `cap deploy HOSTS=IP_ADDRESS`.  See his comments attached to this post.

Multi-App Mongrel Cluster Init Script January 22, 2008

Posted by John Dewey in Capistrano, Configuration, Deployment, Mongrel, Rails.
2 comments

I found the mongrel_cluster.sh script, everyone uses — doesn’t quite cut it.   Especially, when a system may host several RoR applications.  Why, you ask?  The ability to easily control, and dynamically discover applications is missing.  In most cases, this doesn’t matter.  Especially when the applications are deployed with Capistrano, since it is leveraged for various tasks (including stop, starts, and restarts).

The SAs on the other hand, usually do not use Capistrano (they should!), or have a recent version of the app checked out.  Having a standard init script across all your applications and servers becomes useful.

You get bonus points for dynamically discovering new application installs.We can make certain assumptions in our environment.

We use Capistrano, apps run as the same user,  live under the same base directory, and link to common Subversion Rake tasks.  That enables the use of a generic Rake task to control all RoR applications. Furthermore, the Rake task can be wrapped by a system init script for use under /etc/init.d/.