{"id":967,"date":"2011-11-18T17:01:19","date_gmt":"2011-11-18T15:01:19","guid":{"rendered":"http:\/\/blog.railsware.com\/?p=967"},"modified":"2021-08-12T13:43:51","modified_gmt":"2021-08-12T10:43:51","slug":"caphub-multiple-applications-deployment-with-capistrano","status":"publish","type":"post","link":"https:\/\/railsware.com\/blog\/caphub-multiple-applications-deployment-with-capistrano\/","title":{"rendered":"CapHub – multiple applications deployment with Capistrano"},"content":{"rendered":"\n
\"\"<\/figure>\n\n\n\n

Today we’ll talk about deploying multiple applications via single Capistrano project, managing its deployment configurations in a single place.
This approach is a must for projects with multiple applications deployment and recommended for any other project using Capistrano for deployment.
We’ve created a tool called Caphub<\/a> for simplifying creation of multi-deployment Capistrano projects. Before showing it in details let’s review original Capistrano deployment methods: default and multi-stage.<\/p>\n\n\n\n

Preface<\/h3>\n\n\n\n

We’re pretty sure you’re already familiar with basic capistrano setup. Let’s just repeat it briefly:<\/p>\n\n\n\n

$ cd blog\n$ gem install capistrano\n$ capify .<\/pre>\n\n\n\n
Then you put project-specific configuration to config\/deploy.rb<\/em><\/p>\n\n\n\n
Another thing that people usually use for deployment is multistage extension<\/a> originally written by capistrano author.<\/p>\n\n\n\n
This extension allows you to specify particular configuration related to specific environments<\/em> easily. For example, production or qa environments. Common configuration is located in config\/deploy.rb<\/em> and specific configuration in config\/deploy\/{stage_name}.rb<\/em> So any of your tasks are always executed as:<\/p>\n\n\n\n
$ cap CONFIGURATION_TASK NAMESPACE:TASK_NAME<\/pre>\n\n\n\n
E.g.:<\/p>\n\n\n\n
$ cap production deploy:setup<\/pre>\n\n\n\n
In our opinion this approach works fine… even extremely fine<\/em>! Thank you, Jamis Buck!<\/p>\n\n\n\n
Decentralized multi-deployment approach<\/h3>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
Following examples assume you’re working on large or just complex project that contains several applications. For example you use SOA<\/a> approach. So deployment code is located in each of its applications.<\/p>\n\n\n\n
There are serious disadvantages in this method:<\/p>\n\n\n\n
  1. Multiple directories<\/strong>: You must enter each project and start application deployment procedure there. So you either use cd<\/em> command or open each project’s directory in a new terminal console.<\/li>
  2. Copy-n-Paste<\/strong>: Some shared configuration and Capistrano recipes are just copy-n-pasted between projects. It’s not DRY.<\/li>
  3. Deployment and Application mixing<\/strong>: We believe application code must be independent from deployment code \u2014 that is just different projects. So why would we put deployment code directly into main application repository? It makes a mess at least in SCM commit history.<\/li><\/ol>\n\n\n\n
    As an alternative you may use centralized deployment approach.<\/p>\n\n\n\n
    Centralized multi-deployment approach<\/h3>\n\n\n\n
    \"\"<\/figure><\/div>\n\n\n\n
    Let’s create another repository and call it mysite-deploy<\/em> for example. Create repository layout similar to Capistrano multistage convention:<\/p>\n\n\n\n
    [mysite-deploy]$ tree --dirsfirst\n.\n\u251c\u2500\u2500 config\n\u2502   \u251c\u2500\u2500 deploy\n\u2502   \u2502   \u251c\u2500\u2500 billing\n\u2502   \u2502   \u2502   \u251c\u2500\u2500 production.rb\n\u2502   \u2502   \u2502   \u2514\u2500\u2500 qa.rb\n\u2502   \u2502   \u251c\u2500\u2500 core\n\u2502   \u2502   \u2502   \u251c\u2500\u2500 production.rb\n\u2502   \u2502   \u2502   \u2514\u2500\u2500 qa.rb\n\u2502   \u2502   \u2514\u2500\u2500 customer\n\u2502   \u2502       \u251c\u2500\u2500 production.rb\n\u2502   \u2502       \u2514\u2500\u2500 qa.rb\n\u2502   \u251c\u2500\u2500 keys\n\u2502   \u2514\u2500\u2500 deploy.rb\n\u251c\u2500\u2500 recipes\n\u251c\u2500\u2500 Capfile\n\u2514\u2500\u2500 Gemfile<\/pre>\n\n\n\n
    What is the benefit?<\/p>\n\n\n\n
    1. Centralized location<\/strong>: mysite-deploy<\/em> is your deployment control repository now. All deployment code located in single<\/em> place and you can easily support or refactor it.<\/li>
    2. Reuseable code<\/strong>: You don’t need to copy-n-paste Capistrano recipes or configuration files anymore. Such approach allows you to include shared configurations to certain subprojects. You can include external recipes via gems or put your own ones into recipes directory. You can easy configure\/override particular recipe for certain configuration.<\/li>
    3. Security policy<\/strong>: You may restrict access to deployment project so only specific people\/departments would be able to deploy the application. Or if you use ssh keys you can create yet another repository deployment-keys<\/em> and add it as git submodule or symlink it. There are lots of ways how you may organize your security policy. Anyway it is much easier with centralized deployment project location.<\/li><\/ol>\n\n\n\n\n\n\n\n
      System configuration deployment<\/h3>\n\n\n\n
      Where do you store your web server configuration files configured for your applications? nginx.conf<\/em> for example. Do you configure it each time from scratch? Do you copy it from one server to another? Do you put in your knowledge base? Do you put it in your application repository?<\/p>\n\n\n\n
      We believe system configuration also should be stored in SCM. And even more: system configuration is also treated as part of deployment infrastructure! Your system administrator may say it is not true but believe us :)<\/p>\n\n\n\n
      So we advise you to create another repository, call it mysite-sysconf<\/em> for example, and put configuration files there. You are free to organize sysconf repository layout as you wish. It depends on your deployment architecture. You can either store all config files in one repository mysite-sysconf or in several repositories like mysite-sysconf-nginx<\/em>. Again it depends on your site architecture.<\/p>\n\n\n\n
      Then go to mysite-deploy repository and write deployment recipes. For example:<\/p>\n\n\n\n
      [mysite-deploy]$ cap sysconf:nginx:production deploy:setup\n[mysite-deploy]$ cap sysconf:nginx:production deploy<\/pre>\n\n\n\n
      Benefits:<\/p>\n\n\n\n
      1. System configuration is version-controlled<\/strong>: You won’t lose you system configuration changes. You can review any configuration file before it will be applied to production servers. You can test configuration on another servers.<\/li>
      2. Automated deployment<\/strong>: It is easier to setup multiple servers with the same configurations. If you need to add extra server to existing architecture it’s also will be easy to do it with capistrano.<\/li><\/ol>\n\n\n\n
        Now let’s simplify deployment projects creation with Caphub.<\/p>\n\n\n\n
        What is CapHub?<\/h3>\n\n\n\n
        CapHub<\/a> is a simple tool that generates deployment repository layout described above for you. If you want to build own deployment repository caphub<\/em> might be handy. It’s as easy as bundle gem NAME<\/em> command.<\/p>\n\n\n\n
        Installation<\/h4>\n\n\n\n
        $ gem install caphub<\/pre>\n\n\n\n
        Usage<\/h4>\n\n\n\n
        Let’s create own deployment hub!<\/p>\n\n\n\n
        $ caphub mysite-deploy<\/pre>\n\n\n\n
        Go to mysite-deploy<\/em> directory and install gems:<\/p>\n\n\n\n
        $ bundle install<\/pre>\n\n\n\n
        Push repository to your remote server:<\/p>\n\n\n\n
        git remote add origin your\/remote\/git\/repo\/url\ngit push -u origin master<\/pre>\n\n\n\n
        Details<\/h4>\n\n\n\n
        Caphub generates minimal layout like:<\/p>\n\n\n\n
        tree --dirsfirst\n.\n\u251c\u2500\u2500 config\n\u2502   \u251c\u2500\u2500 deploy\n\u2502   \u2514\u2500\u2500 deploy.rb\n\u251c\u2500\u2500 recipes\n\u251c\u2500\u2500 Capfile\n\u251c\u2500\u2500 Gemfile\n\u2514\u2500\u2500 Gemfile.lock<\/pre>\n\n\n\n
        Where Gemfile<\/strong> already contains some handy gems-recipes:<\/p>\n\n\n\n
        source \"http:\/\/rubygems.org\"\n\ngem \"capistrano\"\ngem \"capistrano_colors\"\n\ngem \"capistrano-multiconfig\"\ngem \"capistrano-uptodate\"\ngem \"capistrano-patch\"\ngem \"capistrano-calendar\"<\/pre>\n\n\n\n
        The core of Caphub is actually capistrano-multiconfig<\/a> gem. It automatically builds capistrano task-configrations from files located in config\/deploy\/<\/em> directory.<\/p>\n\n\n\n
        So if you create file config\/deploy\/apps\/customer\/production.tb<\/em>, corresponding configuration task will become available:<\/p>\n\n\n\n
        [mysite]$ cap -T\n...\ncap apps::customer:production          # Load apps:customer:production configuration\n...<\/pre>\n\n\n\n
        Please read capistrano-multiconfig<\/a> README file for more details.<\/p>\n\n\n\n
        Extending with your recipes<\/h4>\n\n\n\n