Microsoft Engineers Wanted for Architel (job ad)
Are you high-speed? Energetic? Looking for a challenge? Ready to jump in the game? Quit wasting your time, start getting ahead. Join a company that is going somewhere - FAST!!!
Architel provides IT support to small businesses in the Dallas Fort Worth area. Architel also sponsors an open source project called SimpleTicket as well as a set of pro-sumer blogging tools called Big in Japan. Architel is looking for engineers to join the team. Since Christmas they have added three new engineers and they are hoping to add two more before January 15th. Are you looking for a new job? Here is what they are looking for:
- Microsoft engineers (Level II and III)
- Four plus years of Microsoft server/desktop experience
- Four year college degree (BA or BS) or
- Former Military (USMC preferred)
- Clean background and drug/tobacco free
They need engineers to support their clients. You will get exposed to all of our businesses, but first and foremost you will be asked to provide engineering support to Architel’s small business clients. If you are interested in joining the team email your resume, salary requirements and availability to us immediately. If former military, in lue of degree, please indicate rank and type of discharge (be able to produce DD214).
Open source = FREE (SimpleTicket = Open Source Trouble Ticket System)
We have received scores of inquiries regarding the price of SimpleTicket. SimpleTicket is being released using an open source license - i.e. it is free! You don’t have to pay anyone for its use. We thought most people understood open source models, but just to be clear:
SimpleTicket is 100% FREE! Now we will help you install it for a fee, host it for a fee or customize it for a fee - but you don’t need to pay us anything to use the ticketing system. Are there other open source trouble ticket systems? The answer is yes:
Are their any other Ruby on Rails based ticketing systems? How about a ticketing system with Ajax goodness? Nope - as far as we know SimpleTicket is the only one.
Rails Installation Help
Need help deploying Rails so that you can install SimpleTicket? James Davidson has some great advice that I will reblog here (James refers to himself as I throughout)
In my previous essay, I said that Rails deployment can get complicated. And that it was a DIY situation. Both are true, but it doesn’t have to be complicated. To help you learn how to DIY your Rails deployment and show you the easiest way to get going, here’s my recipe for deploying onto a server with LightTPD.
Prerequisites and Assumptions
This recipe assumes a bit of prep work has already been done and that you have a server set up somewhere. I’m going to assume that it’s already got the following items on it:
On Mac OS X, see Hivelogic’s guide to Building Ruby, Rails, LightTPD, and MySQL on Tiger if you need some pointers. On other platforms, well, I’m going to assume that one way or another you’ve got things squared away.
I’m also going to assume that this is the only web application that you’re going to be running on your server. In other words, this box does nothing but serve your application to the world. I’ll tackle showing you how to set up multiple Rails applications, as well as co-existing with other things on the server, in later recipes. For now, let’s keep things as simple as possible.
On your client machine, the one on which you do development, you have already by necessity set up Ruby and Rails and a database or else we wouldn’t be having this conversation. There’s one more thing that you’ll need to make sure you have set up: SwitchTower. If you don’t have it on your system, do this:
And last, I’m assuming your code is in Subversion. You do have your code under version control don’t you?
Why LightTPD?
Why am I using lighty for this recipe? The answer is that it’s lightweight, fast, and easy to configure. As well, it already has support for FastCGI built in. There’s no need to add it by using a third-party module. It can either manage a set of FastCGI dispatcher processes itself (which is what I’ll show in this recipe), or load balance between a set of external FastCGI processes either on the same machine or remote machines.
Lighty is also well loved by the Rails community. If you have it installed on your local development machine, then script/server will use it instead of WEBrick. With the attention it gets from the Rails community, you can be sure that things will work well now and into the future.
But wait! If lighty already supports FastCGI, why do you need the FastCGI library installed on your machine as specified in the prerequisites above? Well, the FastCGI library isn’t there for lighty’s sake. It’s there for the ruby-fcgi bindings to work well. That said, the ruby-fcgi bindings will work in a pure ruby mode, but there are problems when using the pure ruby mode, especially with file uploads and other large HTTP POST requests.
Where Things Will End Up
Before deploying onto a server, you should have a clear strategy for where things are going to be located. For this recipe, we’re going to use the following:
- Lighty’s config file at /etc/lighttpd/lighttpd.conf
- Lighty’s runtime pid file at /var/run/lighttpd.pid
- Lighty’s access logs written to /var/log/lighttpd/access_log
- Lighty’s error logs written to /var/log/lighttpd/error_log
- Rails application deployed to /Library/Rails/mycoolapp
That last path is a Mac OS X-biased one. If you’re using Linux or FreeBSD, you’ll probably want to use something like /usr/local/rails/myapplication to deploy your Rails application to.
Testing Your Server Setup
Now that we’ve covered the prerequisites and assumptions, let’s make sure everything is in place on your server. Call me paranoid, but… The machine name I’ll be using in this recipe is Luna.local.
Password: *******
Last login: Sun Dec 25 00:07:38 2005 from incognita.local
Welcome to Darwin!
Luna:~ duncan$ lighttpd -v
lighttpd-1.4.8 (ssl) - a light and fast webserver
Build-Date: Dec 7 2005 15:22:51
Luna:~ duncan$ rails –version
Rails 1.0.0
Luna:~ duncan$ svn –version
svn, version 1.2.3 (r15833)
compiled Dec 7 2005, 13:23:49
Next, we need to make sure that that fcgi bindings are a-ok. To test this out, fire up irb:
irb(main):001:0> require ‘fcgi.so’
=> true
This tells us that the native adapter for the ruby-fcgi library is in place. If you get a load error here, the native bindings aren’t happy. You can see if your ruby-fcgi bindings will work in in pure Ruby mode:
=> true
If you get a load error for fcgi.so, but not for fcgi, then you can continue on with the recipe, but make sure that you either fix the issue or understand the potential problems.
You should also test to make sure that your database adapter is happy. For example, if you are using MySQL, you can test for the existence of the mysql-ruby bindings with the following:
=> true
In the case of MySQL, you can get away without using the mysql-ruby bindings. There’s a pure Ruby adapter in rails. However, for performance reasons, you will want to be use the mysql-ruby bindings if at all possible.
Next, let’s make sure that you can reach the Subversion code repository that your project is in. Sometimes firewalls and what not, especially if your server is in a DMZ which restrictes outbound access, can get in your way. If this is the first time you’ve hooked up to the repository from your server, you’ll see a lot of stuff:
Certificate information:
- Hostname: svn.server.com
- Valid: from Dec 7 12:05:21 2005 GMT until Dec 8 12:05:21 2006 GMT
- Issuer: Equifax Secure Inc., US
- Fingerprint: da:00:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:**:71
(R)eject, accept (t)emporarily or accept (p)ermanently? p
Authentication realm: <https://svn.server.com:443> svn.server.com
Password for ‘duncan’: *******
README
Rakefile
app/
components/
config/
db/
doc/
lib/
log/
public/
script/
test/
vendor/
Seeing this directory listing of your project tells you all is well.
Note: Testing out your Subversion access here also means that you’ve already ensured that you’ve accepted the certificate for an https based Subversion repository and already handled the authentication bits. This means that you won’t have it happening during a deployment which, as of version 0.9.0, SwitchTower isn’t too friendly about.
Annoyance: Some versions of the svn client don’t seem to save authentication information against https based repositories the first time around. I’ve seen this issue intermittently. Executing svn ls a few times in a row will clear this up. Very annoying.
Once you’ve validated all is happy on the server, it’s time to focus back on your development machine and on your code tree.
SwitchTower Setup
In order to use SwitchTower on a Rails application, you’ll need to have SwitchTower to install a few things into your codebase:
Incognita:~/mycoolapp duncan$ switchtower –apply-to `pwd` mycoolapp
exists config
create config/deploy.rb
exists lib/tasks
create lib/tasks/switchtower.rake
As you can see from the output, SwitchTower has places two files into your project. The first of these, deploy.rb, contains the configuration information for your application’s deployment. The second, switchtower.rake, adds some rake tasks which allow you to interact with SwitchTower.
Editing deploy.rb
Now, we’re ready to edit the config/deploy.rb file. First, in the section marked REQUIRED VARIABLES, you’ll need to let SwitchTower know where the source code repository for your project is:
set :repository, "https://svn.server.com/mycoolapp/trunk"
Next, you’ll need to edit the ROLES section to let SwitchTower know what server it should deploy your application to. Since we’re using a single server for all tasks in this recipe, set all three roles to your server name:
role :app, "Luna.local"
role :db, "Luna.local", :primary => true
Next, we need to tell SwitchTower where on the server we want the application deployed to. To do this, set the :deploy_to variable:
Last, if your svn executable on the server isn’t on the default path that the SSH environment gives you (typically /usr/bin:/bin:/usr/sbin:/sbin), you’ll need to set up the :svn variable:
The First Deployment
Now that the config/deploy.rb is configured, the next thing to do is have SwitchTower set up things on the server. To do this, execute the following command:
Unless you have set up SSH public/private key authentication, you’ll be challenged for your password for the remote server. After authenticating, this sets up the deployment directory and a few directories inside of it. Next, let’s do the first deployment:
This deploys the application into the /Library/Rails/mycoolapp/current directory. At the end of the output from the command, you’ll probably see the following:
command finished
This error message tells us that SwitchTower couldn’t restart the remote Rails application. Since we haven’t configured and started up the server, this is expected output. Well get that set up soon, but first…
Interlude: Set up Your Database
At this point, you should make sure that your production database is set up and that the correct settings appear in the production section of config/database.yml. Since everyone’s database set up is different, I can’t help you too much with this. But, once you thing you’re set up, there’s an easy way to check up to see if everything is working. On your production server in the current deployment directory, start up the console in production mode:
Loading production environment.
>>
Now, do a find on one of your model classes. Here’s an example from my application:
=> #<Content:0×8e451d0 @attributes={"last_modified"=>"2005-12-25 00:43:13", "title"=>"European Open Source Convention Photos", "date"=>"2005-10-17 12:00:00", "url"=>"http://www.flickr.com/photos/x180/sets/1145208/", "datapath"=>"2005/10/euroosconphotos", "id"=>"1", "summary"=>"The photos I’m taking for the Open Source Convention in Amsterdam are all going up onto Flickr. Of course."}>
Once you’ve verified that your production database connection works, you’re ready to set up lighty.
LightTPD Configuration
Here’s a simple, yet still realistic Lighty configuration that we can use on a production server to run a Rails app:
server.modules = ("mod_rewrite", "mod_accesslog", "mod_fastcgi")
server.port = 80
server.username = "www"
server.groupname = "www"
server.pid-file = "/var/run/lighttpd.pid"
accesslog.filename = "/var/log/lighttpd/access_log"
server.errorlog = "/var/log/lighttpd/error_log"
server.indexfiles = ( "index.html" )
url.rewrite = ( "^/$" => "index.html", "^([^.]+)$" => "$1.html" )
server.document-root = "/Library/Rails/" + var.appname + "/current/public"
server.error-handler-404 = "/dispatch.fcgi"
mimetype.assign = (
".css" => "text/css",
".gif" => "image/gif",
".html" => "text/html",
".jpeg" => "image/jpeg",
".jpg" => "image/jpeg",
".js" => "text/javascript",
".pdf" => "application/pdf",
".png" => "image/png",
".txt" => "text/plain",
)
fastcgi.server = ( ".fcgi" =>
( "localhost" =>
( "min-procs" => 1,
"max-procs" => 1,
"socket" => "/tmp/mycoolapp.fcgi.socket",
"bin-path" => "/Library/Rails/" + var.appname + "/current/public/dispatch.fcgi",
"bin-environment" => ( "RAILS_ENV" => "production" )
)
)
)
Create this configuration at /etc/lighttpd/lighttpd.conf.
Note: Don’t use the lighttpd.conf file that Rails will automatically generate in the config directory of your application. This configuration is set up for development use and uses relative paths which is only appropriate when running Lighty using the script/server command.
After ensuring that the /var/log/lighttpd directory exists and is writable by the www user, you are ready to start up Lighty.
Now, if all has been configured correctly—including your database and database connection—you’ll be able to point a browser at your production server and see your application running.
Troubleshooting Tip: If the first thing you see when you hit your production server is a big Application error (Rails) notice, then the safe hunch is that your application can’t find its way to the database. Verify that your application can access the database using the script/console command mentioned above. Once you’ve ruled database connection problems out, then dive through the various log files to figure out what may be going on.
Subsequent SwitchTower Deployments
Once you’ve verified that your application is up and running on the production server, you’re ready to deploy as often as you like. All you need to do is to make your changes, test (you are are writing unit tests aren’t you?), commit your changes, and redeploy using:
Now that Lighty is up and running, what happens when you execute this command is:
- SwitchTower pushes up the latest copy of your application into the current directory
- SwitchTower executes script/process/reaper to restart your application.
The reaper script looks for currently running instances dispatch.fcgi and send a USR2 signal to them. This causes the your running Rails processes to restart using your newly deployed codebase. This happens gracefully as each process finishes up processing requests already in progress. You can see this in action in the output from SwitchTower. At the end of the output stream, you’ll see something like the following:
[out :: Luna.local] Restarting [20210] ruby /Library/Rails/mycoolapp/current/public/dispatch.fcgi
[out :: Luna.local] Restarting [20211] ruby /Library/Rails/mycoolapp/current/public/dispatch.fcgi
Now, this doesn’t restart Lighty. If you make changes to your lighttpd.conf file, you’ll need to bump the server manually. To do this, use the INT signal to gracefully terminate lighty after all pending requests have finished being processed.
Wait a second or two or three, then:
Unfortunately, Lighty doesn’t have a graceful way to reload it’s configuration without this complete shutdown. It’d be nice to have something similar to Apache httpd’s apachectl -k graceful command. Fortunately, since you can update your Rails app gracefully without restarting Lighty, this issue isn’t a deal-breaker.
Note: SwitchTower, at least as of version 0.9.0, updates your production copy of your application based on what is committed into Subversion—not what is in your local workspace. If you make some changes and deploy, but don’t see the changes up on the server, remember, you need to commit first!
Finishing Touches
At this point, you should take a few minutes and make sure that Lighty will be started up at system startup in a manner appropriate for your system. Otherwise, you’ll be in for a rude surprise when you’re server restarts at 4AM for whatever reason and your application doesn’t come back up.
If you are running Mac OS X 10.4, here’s a launchd lighttpd plist that will do the trick. Read up on the launchd man page for more details about how it works.
Potential Gotchas
I’ve covered a lot of ground in this essay. In doing so, I hope that I’ve demystified how to deploy a Rails application onto Lighty. However, in preparing this recipe, there’s no way I can cover every possibility. You may run into issues along the way. Most issues are path or environment related. For example, you’ll want to make sure that your ruby and rake commands are on the environment provided when you remotely executed a command on your server via ssh. As well, you may need to set the PATH, RUBYLIB, or GEM_HOME environment variables in your ~/.ssh/environment file on the server.
If you run into outright bugs in this recipe, or even gotchas that you think that I should include with this essay, please send me an email using the address at the bottom of the page. I can’t promise that I’ll have any time to help you with troubleshooting your problem, but I will make any needed changes to this essay if you can tell me what you experienced and how you fixed it.
SimpleTicket Release News
We have decided to release the code of SimpleTicket this week without the following features:
- tagging
- RSS feeds
- scheduling
- statistics
Each of these features are key to the success of the project and they will be added by the end of January, but we wanted to get the basic code out there as soon as possible. These features were causing the delay in releasing the code (at least that is our story). Anyway, keep your fingers crossed that the code will be up on SourceForge by the end of the week. WOOT!
SimpleTicket Release Delay
Kevin had hoped to launch the latest version of SimpleTicket internally last night for basic testing and release next week. He was not able to release it. We are hopeful he will be able to release tonight so the public code release won’t be delayed, but if we cannot get it out tonight it may be delayed until after New Years.