Using YAML to Drive App Deployment

There’s a very handy but sometimes overlooked feature of the stackato client that we’d like to let you know more about. I often have to remind myself to point it out when I’m doing demos for people, as it’s something that I’ve quickly come to take for granted. It’s the stackato.yml config file.

It’s a small addition to base vmc functionality, but it really helps with consistent, automated application deployment. You see, the stackato and vmc command-line clients are normally interactive. You are prompted for confirmation of the URL…

$ vmc push wordpress
Would you like to deploy from the current directory? [Yn]:
Application Deployed URL [wordpress.stackato.local]: 

…confirmation of the detected runtime or framework…

Detected a PHP Application, is this correct? [Yn]:

…memory allocation…

Memory Reservation (64M, 128M, 256M, 512M) [128M]: 64M

You are asked if you want to create a new data service or bind to a new one, and you are prompted for a name…

Would you like to bind any services to 'wordpress'? [yN]: y
Would you like to use an existing provisioned service? [yN]: n
The following system services are available
1: mongodb
2: mysql
3: postgresql
4: rabbitmq
5: redis
Please select one you wish to provision: 2
Specify the name of the service [mysql-33b93]: mysql-wordpress
Creating Service: OK
...

Both clients have a –no-prompt option for the ‘push’ command, but to specify non-default values with vmc you have to add them as command line arguments. Wouldn’t it be handy to specify these things in a config file?

Since a lot of Stackato configuration files on the server side are done in YAML, we chose that as the data serialization format. We made the stackato client check for a ‘stackato.yml’ file and use the options specified there. This bypasses all of the prompting during a ‘push’ or ‘update’ and gives you a place to see all of your configuration at a glance in a human readable format.

$ cat stackato.yml
name: mywordpress
mem: 64M
instances: 1
services:
    mysql: mysql-wordpress
hooks:
  post-staging:
    - sh salt.sh

When it comes time to push or update the app, you can use the ‘-n’ or ‘–no-prompt’ switch:

$ stackato push -n
Application Url: mywordpress.stackato.local
Creating Application [mywordpress]: OK
Creating mysql Service [mysql-wordpress]: OK
Binding Service [mysql-wordpress]: OK
Uploading Application [mywordpress]:
  Ignoring path [.git]
  Checking for available resources: OK
  Processing resources: OK
  Packing application: OK
  Uploading (16K): 100% OK
Push Status: OK
Staging Application [mywordpress]: OK
Starting Application [mywordpress]: OK

What else can you do with stackato.yml?

In addition to driving the basic push operations, stackato.yml can be used for additional server-side setup operations, as you might do with the ‘stackato run‘ and ‘stackato env‘ commands.

You can specify the commands in a ‘post-staging’ or ‘pre-running’ hooks section. For example, the WordPress demo suggests creating a salt.php file before pushing. I’ve wrapped those commands in a salt.sh bash script (see above) and run it as a post-staging hook instead.

You can set environment variables in an ‘env’ section. For example, if you want to set up New Relic monitoring for a Django app, file you can set the environment variables in stackato.yml instead of creating a separate newrelic.inifile:

env:
  DJANGO_SETTINGS_MODULE: settings
  NEW_RELIC_LICENSE_KEY: gg070c96385e870xxthisisnotarealkey5a12xx
  NEW_RELIC_APP_NAME: DJANGO GTD
  NEW_RELIC_LOG: stderr

You can even specify a different web server process to run your application, as in this example from the Starman demo:

processes:
  web: starman --listen $VCAP_APP_HOST:$VCAP_APP_PORT --workers 2 app.psgi

<!–

–>

Written by admin on December 1st, 2011 with no comments.
Read more articles on browser.

« Older articles

Newer articles »