Running Bang

Quick Start

With all of your deployer credentials (e.g. AWS API keys) and stack configuration in the same file, mywebapp.yml, you simply run:

bang mywebapp.yml

As a convenience for successive invocations, you can set the BANG_CONFIGS environment variable:

export BANG_CONFIGS=mywebapp.yml

# Deploy!

# ... Hack on mywebapp.yml

# Deploy again!

# ... Uh-oh, connection issues on one of the hosts.  Could be
# transient interweb goblins - deploy again!

# Yay!


Set this to a colon-separated list of configuration specs.

Other Options

Deploys a full server stack based on a stack configuration file. In order to SSH into remote servers, ``bang`` needs the corresponding private key for the public key specified in the ``ssh_key_name`` fields of the config file. This is easily managed with ssh-agent, so ``bang`` does not provide any ssh key management features.

usage: bang [-h] [--ask-pass] [--user USER] [--dump-config {json,yaml,yml}]
            [--list] [--no-configure] [--no-deploy] [--playbook PLAYBOOK]
            [CONFIG_SPEC [CONFIG_SPEC ...]]
Positional arguments:
config_specs Stack config specs(s). A *config spec* can either be a basename of a config file (e.g. ``mynewstack``), or a path to a config file (e.g. ``../bang-stacks/mynewstack.yml``). A basename is resolved into a proper path this way: - Append ``.yml`` to the given name. - Search the ``config_dir`` path for the resulting filename, where the value for ``config_dir`` comes from ``$HOME/.bangrc``. When multiple config specs are supplied, the attributes from all of the configs are deep-merged together into a single, *union* config in the order specified in the argument list. If there are collisions in attribute names between separate config files, the attributes in later files override those in earlier files. At deploy time, this can be used to provide secrets (e.g. API keys, SSL certs, etc...) that you don’t normally want to check in to version control with the main stack configuration.
--ask-pass=False, -k=False
 ask for SSH password
--user, -u set SSH username (default=docs)

Dump the merged config in the given format, then quit

Possible choices: json, yaml, yml

--list=False Dump stack inventory in ansible-compatible JSON. Be sure to set the ``BANG_CONFIGS`` environment variable to a colon-separated list of config specs. E.g. # specify the configs to use export BANG_CONFIGS=/path/to/mystack.yml:/path/to/secrets.yml # dump the inventory to stdout bang –list # run some command ansible webservers -i /path/to/bang -m ping
 Do *not* configure the servers (i.e. do *not* run the ansible playbooks). This allows the person performing the deployment to perform some manual tweaking between resource deployment and server configuration.
 Do *not* deploy infrastructure resources. This allows the person performing the deployment to skip creating infrastructure and go straight to configuring the servers. It should be obvious that configuration may fail if it references infrastructure resources that have not already been created.
--playbook, -p Specify playbook(s) to run during the Ansible phase. *WARNING* This overrides any list of playbooks specified in the bang config(s). This argument can be passed multiple times to specify multiple playbooks to run. They will be executed in the order in which they are passed on the command line. E.g. # deploy and configure a stack as usual. playbooks # are defined in ``my_own_cloud.yml``: bang own_cloud.yml # run an ad-hoc playbook on the same stack: bang own_cloud.yml -p update_loadbalancers.yml # run multiple ad-hoc playbooks: bang own_cloud -p start_maintenance_window.yml \ -p restart_apache.yml \ -p stop_maintenance_window.yml
--version, -v show program’s version number and exit