Tomorrow I'm scheduled to present at the fortnightly internal JBoss R&D call.  It's just a routine hugfest where the engineers who care to dial in have a group meeting.  Normally someone presents their recent work.

Since this is an open-source company, and I ain't got no secrets, I figured this would be the best way to distribute my slides (PDF), instead of choking the mail-server.

They attempt to explain the thought process behind these projects and their future.

Throughout the day (I've scheduled a daily maintenance window from 9am-5pm US Eastern every day...) this site occasionally will go offline while I update the code behind it.

Sometimes I'm updating the Rails application that powers it.  Sometimes I'm updating the Rails deployer that lights it up.

Application Updates

In the case of just updating the application, the downtime should last all of 5 seconds while AS redeploys the app atomically after Capistrano has successfully updated the code and such on the server. 

Capistrano checks the code out from the repository (GitHub) into a timestamped directory.  It creates a symlink named current pointing to the newly deployed directory of code.  It then emits an updated -rails.yml deployment descriptor in the JBoss deploy/ directory.  Every few seconds, AS scans the deploy/ directory for updated things to deploy.  Seeing the new -rails.yml, it first completely undeploys the old application from the old timestamped directory, including any scheduler.  Then it deploys the new application from the new timestamped directory.

We intentionally do not use the current symlink when deploying to AS.  If we did, as soon as the symlink was created, the code would be visible to the "old" version of the running Rails application before it gets completely undeployed.  This could result in errors if you require model migrations, changes to config/** files or have added gems. 

By using the timestamped directories, we can ensure that the old version of the application remains intact until fully undeployed.  Then it gets atomically replaced by the new version.

Deployer Updates

I have yet to automate updating of the deployer itself, but I will soon.  I update the deployer itself every day or so, after integrating new features or improvements (thanks Ales!).

To update the deployer, I bring AS down completely (cap deploy:stop), pull the new code from GitHub, run maven, and restart AS (cap deploy:start).  On this server, I've just symlinked the maven build output over to my AS deployers/ directory.

All told, updating both the deployer and the app (including ssh'ing over a very-high-latency satellite connection) takes right about 10 minutes.

Bottom Line

The update this morning brought about changes to both the deployer and the app. 

The deployer itself now uses Microcontainer slightly better, thanks to code reviews from Ales Justin (Mr. Microcontainer). 

And the Atom feed should now include better URLs for links in the entries.  Thanks to Adam Warski for noticing and reporting that.

Per the discussion in Nobody should need cron, I've added scheduled-task deployment capability to the JBoss Rails deployer.  Currently this functionality is only in the Git repository, but the next beta binary release will certainly include it.

Instead of editing crontabs, you now work with RAILS_ROOT/config/jboss-scheduler.yml, a simple YAML file.

It defines all the scheduled tasks you want to be managed by the container.  For example, the jboss-scheduler.yml for Odd Thesis looks like this currently:

# Field Name        Allowed Values      Allowed Special Characters
# ----------------------------------------------------------------
# Seconds           0-59                , - * /
# Minutes           0-59                , - * /
# Hours             0-23                , - * /
# Day-of-month      1-31                , - * ? / L W
# Month             1-12 or JAN-DEC     , - * /
# Day-of-Week       1-7 or SUN-SAT      , - * ? / L #
# Year (Optional)   empty, 1970-2099    , - * /

github.commit.poller:
  description: Poll projects for GitHub commits
  cron: 0 */15 * * * ?
  task: Github::CommitPoller

That names a task ("github.commit.poller"), sets the cron spec (every 15 minutes), and wires up an associated Ruby class to do the work (Github::CommitPoller).

The container loads up the rails environment once for each task, and keeps it handy and fresh for each triggering of the task. 

It looks for tasks under RAILS_ROOT/app/scheduler/.  In the above example, it's ultimately using RAILS_ROOT/app/scheduler/github/commit_poller.rb.

The task class itself has no particular requirements, other than being able to respond to run() called with no arguments.

module Github
  class CommitPoller
    def run()
      # do work, use ActiveRecord models, etc
    end
  end
end

Since you don't want to fire up the whole container to execute your task, perhaps if you're testing, or need an extra execution of it, there's a magic Rake task you can execute:

rake jboss:scheduler:run:commit_poller

The JBoss-Rails Plugin automatically scans your scheduled-tasks and creates rake tasks to run them from the command-line.  It currently just uses the last portion of the name ("commit_poller"), so it's up to you to avoid any naming conflicts.  Having foo/poller.rb and bar/poller.rb will only result in sadness.

I'm not necessarily super-happy with the name of the deployment descriptor (jboss-scheduler.yml) nor of the task class location (app/scheduler/**.rb).  I'm open to suggestions and discussions.

Check it out from GitHub if you're brave, else a binary release should be forthcoming before too long.

And yes, I advise you to use this wisely.  It's not an acceptable way to do very important sysadmin chores.  But if you have some recurring activity that's not either a user thread or runnable as a daemon, I think this can be quite useful.

Check out the Odd Thesis Commits page for an example.  Every 15 minutes it polls GitHub for a YAML feed of recent commits, and then jams them into our database.  It's not a critical task, but one I don't want to screw with Vixie cron to handle.

Thanks to Jason Hunter and the friendly kids at MarkMail (a free service provied by Mark Logic), we've now got a swell mailing list archive.

http://oddthesis.markmail.org/search/?q=

 

I've knocked together some documentation about using the Capistrano support in the JBoss Rails Plugin. 

The goal is to make it easy for people used to deploying traditional Rails apps. 

After a few settings in your Capistrano deploy.rb file, you simply do what you normally do to deploy your app.  Assuming you've got JBoss setup on your server to replace your pack of mongrels...

cap deploy

That's it.  You're done.

Today I managed to get things to the point where they're hopefully easy to give a whirl.

First, there's the binary of the deployer, along with installation instructions.  We hope to soon have an uber tarball that includes both AS5 and the deployer.  But for now, you'll have to install AS, then drop in the deployer.

Then there's the instructions for installing and using the JBoss Rails Plugin to deploy your app and control the appserver.

Expect frequent releases over the coming weeks as we continue to make fast progress on both capability and usability.

Ultimately, we all want easy-to-replicate deployments of our apps.  Perhaps we're deploying on a cloud, and deploy often on new virtual hardware.  Perhaps we're just paranoid, and expect an earthquake to hit our datacenter.  Or maybe we expect to grow like the 4H club's monster pumpkin, and fully anticipate moving to new/different hardware soon.

Either way, the fewer moving parts and manual steps you have to follow, the better.

To me, cronjobs are the most-often forgotten step. They don't take up visible room on the filesystem.  They don't listen on a port.  They're easy to forget.  You can forget to install them.  You can forget to remove them.  In general, cronjobs annoy me.

But there's still the need to do things at certain times, or on a regularly occurring schedule.

With Rails apps, we can vendorize our dependencies.  With JRuby-on-Rails, we basically vendorize the whole language.  And with JBoss-Rails, we have a really nice and complete environment.  Java has tried real hard to allow you to deploy entirely within a container.  JBoss AS certainly provides everything we'd need.

Specifically, it provides Quartz.

Since we're running in AS, we're happy to write deployers if needed, and we have a scheduler already setup in AS, I think we can bake scheduled tasks right into application deployment.

Imagine $RAILS_ROOT/app/scheduled-tasks/blog_poller.rb.

It could have a fairly simple execute() method on it.

When your app is deployed, $RAILS_ROOT/config/scheduler.rb could be read to set up the quartz tasks. 

Cron's syntax isn't exactly warm and fuzzy.  I think common case is a recurring interval for a task execution.  Something like...

Scheduler.deploy do |schedule|
  schedule.every( 30.minutes ).run( BlogPoller )
end

Simple enough. If parameters are needed, perhaps something akin to

Scheduler.deploy do |schedule|
  schedule.every( 30.minutes ).run( BlogPoller ).with(
    :number_of_retries=>3,
    :notify_on_failure=>true
  )
end

Some syntax to support concrete time-of-day or day-of-week should be doable.  It might be worth investigating the chronic gem.

And since we're handling the deployment, we don't have to wiggle these in strangely as part of the web-app.  A deployer will look for config/scheduler.rb, fire up a ruby interpreter to figure out what the schedule is, and then go deploy actual scheduled tasks into the Quartz service.  Scheduled tasks can be a first-class component like a Servlet, a message queue, or an EJB.

Deploy your app, your scheduled tasks get deployed too.  Undeploy, and the scheduled tasks get cancelled and removed likewise.

 

Thesis 1, Rails can run well on JBoss has a mailing list now.  To subscribe, send a message to

jboss-rails-subscribe@oddthesis.org

Thesis 2, JBoss can run well on the Cloud also has a list.  To subscribe, send a message to

jboss-cloud-subscribe@oddthesis.org

Each list supports all of the projects clustered around the thesis.

As noted in the introduction, I'm currently practicing "thesis-driven development."  This site is fodder for the practical experimentation of what I'm doing.

In addition to a nifty logo, it's a custom Rails app, doing traditional Rails appish things (pages, posts, tags, comments, oh my!).  It uses some popular gems.  It's deployed using capistrano tasks in the way Rubyists are used to. 

But it all runs on JBoss.

The base is:

• JBoss AS 5.0.0.CR2
• Postgres 8.something
• RHEL 4

The gems/extensions/plugins in use by the app currently include:

• aasm
• activerecord-jdbc-adapter-0.8.3
• activerecord-jdbcpostgresql-adapter-0.8.3
• activerecord-jdbcsqlite3-adapter-0.8.3
• atom-tools
• foreign_key_migrations
• haml
• jboss-rails-plugin
• jdbc-postgres-8.2
• jdbc-sqlite3-3.5.8
• rakismet
• redhillonrails_core
• restful_authentication
• transactional_migrations
• will_paginate

I'd also like to welcome my first non-Red Hat committer to these projects.  John Williams is one of the cool kids from Contegix (where this server lives).

I did the round-trip from the land of cows to Raleigh to attend the Raleigh RubyCamp over the weekend.

I think I heard about 80 folks showed up, but I’m not certain on that.

Mark (root@37s) and James did a very nice job of organizing it.  They provided good coffee and donuts to start the morning right.  Krispy Kreme is never a bad idea.

We gathered, and a handful of folks presented introductions about what they wanted to do a session on.  We then figured out the slots, and got started.

Brenton Leanhardt talked about Genome and Cobbler, two emerging technologies at Red Hat.  Cobbler helps to stitch together distributions, Kickstarts and repositories, while Genome helps manage the inventory of virtualization hardware and the guest instances running on them.

His use-case for the technologies is the fact that we’ve got Xen hosts running on machines scattered under desks and in closets, which have been donated to a virtual pool.

Where did you launch that instance last month?  Where can you launch a new instance today?  Genome helps answer those questions.  Many of the Genome bits are Camping apps.

I presented my short slide-deck about JBoss-Rails.

Mark Imbriaco led an open discussion about Rails deployments.  It ended up mostly being us asking how 37signals did things.  He described their hosting environment, their occasional frustrations with Mongrel, along with some stories about running migrations against a 100gig database.

Sean Cribbs talked about his experience in joining and then leading open-source projects, particularly Radiant CMS.  He discussed breaking up the core into many plugins and modules, and the uptick in community participation that followed.

Overall it was a great weekend, and I even got some nice t-shirts out of it.  Not bad.