Dusty App Specs

These specs are used to specify apps for you local environment. They should go in the apps folder in your specs repo.

Keys

repo

repo: github.com/gamechanger/app1
repo: /Users/dusty/app1

This repo key is used to specify a local or remote GitHub repo where the code for the app lives.

mount

mount: /gc/app1

The mount key is used to specify where in the container's file system to mount the code specified by the repo key. The mounting is done using Docker's volume mounts.
Using the image and mount keys specified above, the code specified in /Users/dusty/app1 on your Mac will be visible in your container at /gc/app1.
The repo and mount keys are linked. If you specify one you must specify the other.

depends

depends:
  services:
    - coreMongo
    - coreRedis
  apps:
    - deferrableworker
    - docketsworker
  libs:
    - gclib

The depends key is used to specify what libs, apps and services this app depends on.
Apps and services specified in the depends dict are spun up before the current app. The current app is then linked (using Docker Compose's links) to the apps and services. Because we are using Docker Compose links, dependencies must only be 1 way. This means you cannot have app1 depend on app2 and app2 depend on app1.

Libs specified in the depends dict have a different meaning. They tell Dusty that these libs (and their recursive dependencies) need to be mounted into this app's container (using Docker's volume mounts). In so doing, the running app will have access to the most recent code in these libs.

conditional_links:
  apps:
    - app2

The conditional_links key is similar to the depends key. There are some big differences though. First, the conditional_links key can only specify apps. Second, the current app will only link to the apps specified (here app2) when:
1. It is specified in different activated app's depends dict.
2. It is specified in an activated bundles apps list.
As in the depends dict, circular dependencies are not allowed.

host_forwarding

host_forwarding:
  - host_name: local.website.com
    host_port: 80
    container_port: 80

The host_forwarding key is used specify a list of dictionaries. Each dictionary allows you to specify a mapping from the containers ip space to your Mac's ip space.
host_name is the local url you would like to hit.
host_port is the port on which you will hit the host_name.
container_port is the port the app is running on in the Docker container.

build

build .

The build key is one way to specify how to get the base image for the app's container.
The build key specifies a path to a Dockerfile's parent directory. This patch can be absolute or relative. If it is relative, it is relative to the local path of the app's repo.

image

image: docker.gamechanger.io/gcweb

The image key is the other way to specify how to get the base image for the app's container.
The image key is a local or remote image. Dusty (using Docker Compose) will attempt to pull the image if it is not found locally.

The image and build keys are linked. One, but not both, must be specified. Both are direct mappings to Docker Compose's yml spec.

commands

commands:
  once:
    - apt-get update &
  always:
    - python manage.py runserver --noreload

The commands key is used to specify a list of once and always commands. These commands are run at different times in the container's life cycle.
The once commands will only be run the first time a container is started. This mainly occurs if you are running dusty up.
The always commands are run every time the app restarts. This includes on dusty up and dusty restart <app_name>.
Two sets of commands allows you to do the heavy work of installation in the once command. This frees your restart commands to be very fast and responsive.
We save the logs of these commands inside the app's container at /var/log/dusty_always.log and /var/log/dusty_once.log.

scripts

scripts:
    - name: grunt
      description: Build assets compiled by Grunt (CSS, JS, that sort of thing)
      command:
        - /gc/gcweb/grunt/node_modules/.bin/grunt build

The scripts key is used to specify a list of scripts that can be run in each container.
name specifies how you would call the the script. If the current spec is for app1, I could execute the following script:
dusty scripts app1 grunt
Scripts can accept arguments. Arguments will be passed through to the final command specified by the command key.

compose

compose:
  environment:
    gcenv: local
    MONGO_URI: coreMongo
    REDIS_HOST: coreRedis

The compose key is a direct mapping to the keys specified in the Docker Compose yml spec.
The yml seen above will set the variables defined in the app container's environment.

test

test:
    ...

Apps contain the test key. To find out more about the testing spec, visit the testing spec page.