Skip to content
This repository has been archived by the owner on Feb 25, 2020. It is now read-only.

Using the deployer

Jump to bottom
dcsobral edited this page Apr 5, 2013 · 5 revisions

Intro

The deployer is a tool to automate deployment and management of service artifacts, including configurations, JARs, etc. It also allows for lifecycle hooks (the most commonly used is postinstall) to verify and validate deployment. This page isn't intended to go into full detail, but does cover basic usage.

Obtaining the tool

The deployer tool is located in the infrastructure repository, under sector7/tools/deploymanager.rb, and configurations for the various deployment environments are under sector7/. Basic usage is:

deploymanager.rb <args...>

Checking current configurations

You can get a full listing of configurations with the listconfigs command:

» tools/deploymanager.rb prod-v2.conf listconfigs auth-v1-beta
Configs: 
  auth-v1-beta-20121002135335531  : stable=true, rejected=false, deployed=1, deploying=0, failed=0
  auth-v1-beta-20120927181820289  : stable=true, rejected=false, deployed=1, deploying=0, failed=0
  auth-v1-beta-20120927134638800  : stable=true, rejected=false, deployed=1, deploying=0, failed=0
  auth-v1-beta-20120927133212746  : stable=true, rejected=false, deployed=1, deploying=0, failed=0
  auth-v1-beta-20120927132636656  : stable=true, rejected=false, deployed=0, deploying=0, failed=1

Each configuration represents a combination of specific artifacts. The configuration is represented by a serial number (essentially a timestamp) and some metadata about the deployment. Stable means that the configuration deployed successfully at least once. Rejected means deployment failed more than once without any successes, and the rest are counts of deployment attempts. To get more details on what is currently deployed, you can add the "latest" flag to the command:

tools/deploymanager.rb prod-v2.conf listconfigs auth-v1-beta latest
Configs: 
  auth-v1-beta-20121002135335531  : stable=true, rejected=false, deployed=1, deploying=0, failed=0
    postinstall = s3://ops.reportgrid.com/deploy/prodv2/auth-v1-beta/postinstall.sh-20120927113209
    Files:
      s3://ops.reportgrid.com/deploy/prodv2/auth-v1-beta/auth-assembly-2.0.0-SNAPSHOT.jar-20121002115229 => /usr/share/java/auth-v1-beta.jar
      s3://ops.reportgrid.com/deploy/prodv2/auth-v1-beta/auth-v1-beta.conf => /etc/precog/auth-v1-beta.conf
      s3://ops.reportgrid.com/deploy/prodv2/auth-v1-beta/auth-v1-beta.default => /etc/default/auth-v1-beta
      s3://ops.reportgrid.com/deploy/prodv2/auth-v1-beta/auth-v1-beta.init-20120927114632 => /etc/init/auth-v1-beta.conf
      s3://ops.reportgrid.com/deploy/prodv2/auth-v1-beta/auth-v1-beta.logging.xml => /etc/precog/auth-v1-beta.logging.xml
      s3://ops.reportgrid.com/deploy/prodv2/auth-v1-beta/auth-v1-beta.monit => /etc/monit/conf.d/auth-v1-beta.monit
    Successfully deployed on:
      qclus-demo01.reportgrid.com
    Currently running on:
      qclus-demo01.reportgrid.com

This will show the files deployed, as well as where each file is linked on the deployed systems, then which hosts have deployed and are running the config.

Adding a configuration

To add a configuration to a service, use the addconfig command. In the raw, this takes a series of command arguments of the form symlink target=source file. Since most services consist of multiple related files, a shortcut of load=<file of load lines> exists to simplify deployment. For the vast majority of our services, adding a configuration will take the form:

deploymanager.rb <env config> addconfig <service name> load=<load file> jar=<jar file>

The format of the load file is one line per entry, where an entry is of the form:

tag=<tag name> - specify a tag for this config
stable=<stable value> specify true or false to mark the config as stable (defaults to true)

Hooks:
preinstall=<source file|remove>  
postinstall=<source file|remove> 
preremove=<source file|remove>   
postremove=<source file|remove>  

Setting a hook to a S3 URL sets the hook, setting to "remove" will remove the hook

Files:
<source file>[,<mode>]                  - Adds the file specified by the URL with optional mode
<symlink target>=<source file>[,<mode>] - Adds the file specified by the URL with optional mode and the given symlink target

Shortcuts for files:
default=<source file> - Adds the file symlinked to /etc/default/<service name>
init=<source file>    - Adds the file symlinked to /etc/init/<service name>.conf
conf=<source file>    - Adds the file symlinked to /etc/reportgrid/<service name>.conf
jar=<source file>     - Adds the file symlinked to /usr/share/java/<service name>.jar

The symlink defined above means a symlink on the deployed host that will point to the version of the file defined in the config. For example, an entry of

/etc/precog/shard-v1.conf=dev/shard-v1.conf

will upload the local file dev/shard-v1.conf (if it's different than in the previous config) as part of the configuration. When the configuration deploys, the file is downloaded to a staging area (default is /opt/reportgrid/deployer/base/<service name>/<file basename>) and then a symlink is made from the staged file to /etc/precog/shard-v1.conf, setting mode as required.

Due to current limitations (big TODO), you should be in the same directory as the load file when executing this. For example, to update the auth service:

$ cd platform/auth/configs
$ ~/repos/infrastructure/sector7/tools/deploymanager.rb ~/repos/infrastructure/sector7/prod-v2.conf addconfig auth-v1-beta load=loads.beta jar=../target/auth-assembly-2.0.0-SNAPSHOT.jar

The script will upload only modified files, then start deployment. The new config becomes the latest configuration, so you can check deployment status with the listconfigs <service name> latest command.

Current Services

We have a number of environments managed by the deployer. This is a listing of the environments and the services running under them

prod-v2.conf

This is the beta/demo quirrel V2 environment, running on qclus-demo01.reportgrid.com. It runs the following services:

  • shard-v2-demo - A configuration for the four demo shards, all using the same JAR, but separate from beta to allow for specialized config and management.
  • shard-v2-beta - The beta quirrel shard
  • ingest-v2-beta
  • auth-v1-beta
  • accounts-v1-beta
  • jobs-v1-beta
  • shard-v2-beta-b, ingest-v2-beta-b, auth-v1-beta-b, accounts-v1-beta-b and jobs-v1-beta-b - Alternate services for high availability and load balance

special-v2.conf

This is the special customer environment running on nebula.precog.com. It runs the following services:

  • shard-v2
  • shard-v2-staging - Environment used to test changes against production data
  • ingest-v2
  • auth-v1
  • accounts-v1
  • jobs-v1
  • shard-v2-b, ingest-v2-b, auth-v1-b, accounts-v1-b and jobs-v1-b - Alternate services for high availability and load balance

dev-v2.conf

This is the V2 dev cluster running on devqclus02.reportgrid.com. It runs the following services:

  • shard-v2
  • ingest-v2
  • auth-v1
  • accounts-v1
  • jobs-v1
  • shard-v2-b, ingest-v2-b, auth-v1-b, accounts-v1-b and jobs-v1-b - Alternate services used when testing high availability

These services are auto-deployed via jenkins on successful platform builds.

Legacy environments

The following environments are for the legacy (v1) services:

  • dev.conf
  • production.conf
  • staging.conf
Clone this wiki locally