While the approach of the previous section is simple to set up, it doesn't give you much control over which gems are offered on the server. If you want to offer gems without installing them, you have the option to create a gem server manually. In the case of Acme, where they already have Apache installed on the production machine, it makes sense to make use of that to present the gems over HTTP. This also has the advantage that Apache starts and stops with the physical machine, due to its incorporation into the init
sequence (see, Apache on Linux and Mac OS X in Chapter 4); with the gem_server
command, you would have to write your own start/stop script to get this happen.
To set up a gem server using Apache on Linux, follow these steps:
First, create a directory to use as the base for the gem server. To keep things simple, I created this as a sub-directory inside Apache's htdocs
directory (as root):
$ mkdir /opt/apache2.2/htdocs/gemserver
Next, create the directory, which will hold the gems:
$ mkdir /opt/apache2.2/htdocs/gemserver/gems
Gems are typically available for download from Rubyforge, though they may be offered from non-standard repositories. For example, you can get the Rails gems from http://gems.rubyforge.org/gems/. We'll start by getting the Rake gem to demonstrate:
$ cd /opt/apache2.2/htdocs/gemserver/gems/
$ wget http://gems.rubyforge.org/gems/rake-0.7.3.gem
A gem is just a zip file with a nonstandard suffix (.gem). Put all the gem
files you want to serve into the gems
directory.
Configure Apache to serve the new directory as a virtual host by adding the following directive to /opt/apache2.2/conf/httpd.conf:
<VirtualHost *:80> ServerName gems.company.local DocumentRoot /opt/apache2.2/htdocs/gemserver </VirtualHost>
You will need to add the new domain name to the DNS as appropriate: see Chapter 6, Into Production for details. Reload Apache:
$ /etc/init.d/apache2.2 graceful
The final step to enable your repository is to index the gems it contains:
$ index_gem_repository.rb -d /opt/apache2.2/htdocs/gemserver
Note that the -d
switch should reference the directory above the gems
directory. This adds two files, yaml
and yaml.Z
, and a directory, quick
, to the gemserver
directory. These are used by clients (like the gem
command line tool) to discover gems in the repository.
Now, test that the repository responds correctly to gem
from a remote machine:
$ gem list --remote --source http://gems.company.local/
*** REMOTE GEMS ***
Need to update 1 gems from http://gems.company.local/
.
complete
rake (0.7.3)
Ruby based make-like utility.
Using this technique, you can make a precise set of gems available to developers. The down side is that you need to run the index_gem_server.rb
command each time you add or change gems, to update the index (or you could use cron
to do this automatically); you have to maintain the repository and ensure that the dependencies between gems are satisfied; and the documentation isn't displayed if you visit http://gems.company.local/
(the gems aren't necessarily installed, so may not have documentation available).
You can set up developer machines to use the repository, as their default, as outlined in the section: Setting Your Gem Server as the Default on the previous page.
52.15.129.90