<p><imgstyle="float:right;margin-left:1.2em;"alt="substack"src="http://substack.net/images/substackistan.png"><i>This is a guest post by James "SubStack" Halliday, originally posted <ahref="http://substack.net/posts/16a9d8/multi-server-continuous-deployment-with-fleet">on his blog</a>, and reposted here with permission.</i></p>
<p>Writing applications as a sequence of tiny services that all talk to each other over the network has many upsides, but it can be annoyingly tedious to get all the subsystems up and running. </p>
<p>Running a <ahref="http://substack.net/posts/7a1c42">seaport</a> can help with getting all the services to talk to each other, but running the processes is another matter, especially when you have new code to push into production. </p>
<p><ahref="http://github.com/substack/fleet">fleet</a> aims to make it really easy for anyone on your team to push new code from git to an armada of servers and manage all the processes in your stack. </p>
<p>To start using fleet, just install the fleet command with <ahref="http://npmjs.org">npm</a>: </p>
<p>Now fleet is listening on :7000 for commands and has started a git server on :7001 over http. There's no ssh keys or post commit hooks to configure, just run that command and you're ready to go! </p>
<p>Next set up some worker drones to run your processes. You can have as many workers as you like on a single server but each worker should be run from a separate directory. Just do: </p>
<p>where <spanclass="code">x.x.x.x</span> is the address where the fleet hub is running. Spin up a few of these drones. </p>
<p>Now navigate to the directory of the app you want to deploy. First set a remote so you don't need to type <spanclass="code">--hub</span> and <spanclass="code">--secret</span> all the time. </p>
<p>The deploy command does a <spanclass="code">git push</span> to the fleet hub's git http server and then the hub instructs all the drones to pull from it. Your code gets checked out into a new directory on all the fleet drones every time you deploy. </p>
<p>Because fleet is designed specifically for managing applications with lots of tiny services, the deploy command isn't tied to running any processes. Starting processes is up to the programmer but it's super simple. Just use the <spanclass="code">fleet spawn</span> command: </p>
<p>By default fleet picks a drone at random to run the process on. You can specify which drone you want to run a particular process on with the <spanclass="code">--drone</span> switch if it matters. </p>
<p>Start a few processes across all your worker drones and then show what is running with the <spanclass="code">fleet ps</span> command: </p>
<p>Now suppose that you have new code to push out into production. By default, fleet lets you spin up new services without disturbing your existing services. If you <spanclass="code">fleet deploy</span> again after checking in some new changes to git, the next time you <spanclass="code">fleet spawn</span> a new process, that process will be spun up in a completely new directory based on the git commit hash. To stop a process, just use <spanclass="code">fleet stop</span>. </p>
<p>This approach lets you verify that the new services work before bringing down the old services. You can even start experimenting with heterogeneous and incremental deployment by hooking into a custom <ahref="http://substack.net/posts/5bd18d">http proxy</a>! </p>
<p>Even better, if you use a service registry like <ahref="http://substack.net/posts/7a1c42">seaport</a> for managing the host/port tables, you can spin up new ad-hoc staging clusters all the time without disrupting the normal operation of your site before rolling out new code to users. </p>
<p>Fleet has many more commands that you can learn about with its git-style manpage-based help system! Just do <spanclass="code">fleet help</span> to get a list of all the commands you can run. </p>
