• V2Deployment

V2 Deployment

V2Master

• Contents

  1. V2 Deployment
  2. Introduction
  3. Server Architecture
     1. Overview
     2. Supporting Technologies
  4. Server Deployment
     1. General Recommendations
     2. Hardware
     3. Virtual Machines
     4. VM Provisioning
  5. Application Deployment
  6. Beta Systems
     1. Environment
     2. Apache Configuration
     3. Procedure

Introduction

This page describes:

1. The server architecture for deploying publicly accessible MAPS and V2 systems
2. The software infrastructure that supports MAPS and V2 deployment
3. How to install publicly accessible beta instances of V2 and MAPS

Server Architecture

Overview

1. Access to one or more physical servers, accessible via a limited number of public IP addresses
   1. Use virtual hosts (DNS aliases) for addressing services and application instances
   2. Use a reverse proxy server to dispatch to the appropriate server, virtual machine
2. The physical servers will collectively support multiple services:
   1. Rails-based MAPS and V2 systems
   2. PHP-based DrawMGT systems
   3. Wiki systems
   4. Web servers
   5. DNS servers
   6. CVS and Git servers
3. Services hosted in virtual machines:
   1. Easy to migrate VMs to alternate physical servers
   2. Host OS does not need to be updated based on changing application requirements
   3. Scaling to additional physical or could-based machines is possible
4. Automated deployment of V2 systems:
   1. Creation of an instance of a, largely pre-configured, virtual machine
   2. Provisioning of the virtual machine (VM) with all site and instance specific configuration
   3. Deployment of the V2 application instance, including the site an instance specific configuration
5. Automated monitoring:
   1. MAPS and V2 instances
   2. Virtual machines
   3. Physical servers
   4. Supporting infrastructure (DNS servers, reverse-proxy servers, etc.)

Supporting Technologies

1. Selected CentOS because:
   1. Acceptable to corporate and enterprise clients

   2. Supports Vagrant and VirtualBox (FreeBSD is currently unable to host

2. The purpose of the reverse proxy server is to route incoming web requests to the appropriate server and virtual machine
3. Selected Apache mod_proxy because:
   1. We have experience configuring and using Apache
   2. We do not have high performance requirements and therefore don't need to be particularly concerned about choosing the best performing reverse proxy server.
      1. Our highest traffic DrawMGT sites, which have 500-800 users, generate at most 25,000 requests per week, meaning (given a five day week and a 10 hour day) an average only 500 requests per hour. E.g. significantly less than one per second
   3. Apache and mod_proxy can be swapped out and replaced with something else, without affecting the rest of the infrastructure

Server Deployment

General Recommendations

1. Have spare hardware capacity
   1. Do not have idle backup servers, but use extra servers in production roles
   2. Run multiple identical servers with load split between them
2. Regularly migrate services to different servers to ensure:
   1. It is possible and that there are no hidden problems
   2. We can rapidly and reliably restore services in the event of a failure

Hardware

1. 64-bit architecture
2. Multi-core, fast CPU(s)
3. Lots of RAM
4. SSD (non-mirrored) disk for host operating system and the active part of the guest VMs (e.g. the guest OS, Rails and DB servers)
5. Mirror/RAID hard disk for application data and backup staging

Note that Virtualization must be enabled in the underlying PC BIOS in order for Vagrant and VirtualBox VMs to function

Virtual Machines

• To be completed - describe:

  • Vagrant - including:
    • Vagrant user
    • Locations of VM boxes and active VMs
    • Multiple VMs on one host
    • Base OS box creation
    • Network configuration

  • VirtualBox

    • Monitoring commands
  • SHaring of viles between host and guest OSs

VM Provisioning

• To be completed - describe:

  • DNS config (and naming convention)
  • Revery proxy config
  • Network config
  • Rails setup
    • Ruby version 1.9.x
    • Rails and associated Gems
  • Apache setup and config
    • Phusion Passenger apache module
  • Puppet

Application Deployment

1. Includes MAPS and V2 deployment

2. To be completed - describe:

   • Application issues
     • Gemfile.lock
   • Apache config
   • Site/instance Git repository
     • Structure of repository
     • Deployment files
       • database.yml
   • Capistrano

Beta Systems

Environment

The V2 server is a virtual host on the zg-3.softxs.ch server.

The server has following software systems:

1. FreeBSD 9.0-RELEASE FreeBSD 9.0-RELEASE #0
2. Apache Server version: Apache/2.2.23 (FreeBSD)
3. Phusion Passenger apache module
4. Ruby: ruby 1.9.3p327 (2012-11-10 revision 37606) [amd64-freebsd9]
5. Rails 3.2.11
6. mysql Ver 14.14 Distrib 5.5.28, for FreeBSD9.0 (amd64) using 5.2
7. And many Gems

The installation location for Rails applications:

1. /v01/local/www/rails

For each application two items are required:

1. In the rails directory the following is required:
   1. A directory with the path {app}-app where the git repository is cloned
   2. A symbolic link {app} which points to the {app}-app/public directory

2. In /usr/local/etc/apache22/httpd.conf there must be a RackBaseUri defined. See below

Example directory structure for the V2pp and MAPS installations:

1. Note that the V2p0 and MAPS applications are currently configured for the development environment

   • $ cd /v01/local/www/rails
     $ ls -l
     lrwxr-xr-x   1 alan  www    16 Jan 24 13:00 maps -> maps-app/public
     drwxrwxr-x  13 root  www    21 Jan 24 13:00 maps-app
     lrwxr-xr-x   1 root  www    15 Jan 17 16:20 v2p0 -> v2p0-app/public
     drwxrwxrwx  15 alan  www    23 Jan 24 17:14 v2p0-app

Apache Configuration

The following is configured in usr/local/etc/apache22/httpd.conf

• ## ====== Rails ======
  
  LoadModule passenger_module /usr/local/lib/ruby/gems/1.9/gems/passenger-3.0.17/ext/apache2/mod_passenger.so
  PassengerRoot /usr/local/lib/ruby/gems/1.9/gems/passenger-3.0.17
  PassengerRuby /usr/local/bin/ruby19
  
  <VirtualHost *:80>
    DocumentRoot  /v01/local/www/rails
    ServerName    v2.softxs.ch
    <Directory /v01/local/www/rails>
      Allow from all
    </Directory>
  
    # -- v2p0 app
  
    RackBaseURI   /v2p0
    <Directory /v01/local/www/rails/v2p0>
      RailsEnv    development
      Options     -MultiViews
    </Directory>
  
    # -- maps app
  
    RackBaseURI   /maps
    <Directory /v01/local/www/rails/maps>
      RailsEnv    development
      Options     -MultiViews
    </Directory>
  
    # -- test0 app
  
    RackBaseURI   /test0
    <Directory /v01/local/www/rails/test0>
      RailsEnv    development
      Options     -MultiViews
    </Directory>
  
    # -- test1 app
  
    RackBaseURI   /test1
    <Directory /v01/local/www/rails/test1>
      RailsEnv    test
      Options     -MultiViews
    </Directory>
  </VirtualHost>

Procedure

1. Log into zg-3.softxs.ch
   1. You must be a member of group www
2. cd to the {app}-app dircetory
3. Git pull/fetch. Typically:

   • git pull origin master

4. Bundle install

   • bundle install

     Use 'sudu gem install' as necessary to install any missing Gems. Note that it appears that bundle install detects the presence of sudo and asks for a password for the bundle install if new gems must be installed. If any Gems are installed then you need to restart Apache:

     • cd /usr/local/etc/rc.d
       sudo ./apache22 restart

     Then check in /var/log/httpd-error.log to make sure there were no errors when Apache restarted.
5. Run rake tasks as necessary. The typical list of rake tasks is:

   • rake db:drop
     rake db:create
     rake db:migrate
     rake db:seed_fu
     rake db:populate

6. If you need to perform any tweaks in the database, use the following user/password to access the DB server:

   • mysql -uroot -psqladmin

7. Test the result. Links:

   1. MAPS http://v2.softxs.ch/maps

   2. V2p0 http://v2.softxs.ch/v2p0