Change Sources

EXPERIMENTAL: Provisioning on commit (via Travis CI)

Travis CI has a mechansim to encrypt secrets. It also has a hook that is run on success. This means we can have yaybu perform system orchestration tasks on commit + successful CI run without having to run any of our own servers.

Here is a simple Yaybufile:

yaybu:
    options:
        - name: BIGV_KEY
        - name: BIGV_SECRET
        - name: BIGV_ACCOUNT
        - name: BIGV_ROOT_PASSWORD
          default: penguin55

new Provisioner as myexample:
    new Compute as server:
        driver:
            id: BIGV
            key: {{ yaybu.argv.BIGV_KEY }}
            secret: {{ yaybu.argv.BIGV_SECRET }}

        image: precise

        name: myexample

        user: root
        password: {{ yaybu.argv.BIGV_ROOT_PASSWORD }}

    resources:
      - Package:
          name: git-core

      - Checkout:
         name: /tmp/yaybu
         scm: git
         repository: https://github.com/yaybu/example

The yaybu.options section allows us to define arguments that can be passed to yaybu via the command line. You can define defaults to use if no such argument is passed in.

Now we can encrypt these details using the travis command line tool:

travis encrypt BIGV_KEY=myusername --add env.global
travis encrypt BIGV_SECRET=password --add env.global
travis encrypt BIGV_ACCOUNT=myaccount --add env.global
travis encrypt BIGV_ROOT_PASSWORD=password --add env.global

And here is what your .travis.yml looks like:

language: python
pythons:
  - "2.6"

env:
  global:
    - secure: <YOUR_ENCRYPTED_STRINGS>

script:
  - true # This is where you would normally run your tests

after_success:
  - sudo add-apt-repository yaybu-team/yaybu
  - sudo apt-get update
  - sudo apt-get install python-yaybu
  - yaybu up BIGV_KEY=$BIGV_KEY BIGV_SECRET=$BIGV_SECRET BIGV_ACCOUNT=$BIGV_ACCOUNT BIGV_ROOT_PASSWORD=$BIGV_ROOT_PASSWORD

EXPERIMENTAL: Provisioning on commit

This uses a new command, yaybu run. This puts yaybu into a mode where it continues to run, rather than deploying then exiting. Parts can set up listeners to respond to external events like commits or monitoring systems.

To deploy on commit you can use a Yaybufile like this:

new GitChangeSource as changesource:
    polling-interval: 10
    repository: https://github.com/isotoma/yaybu

new Provisioner as myexample:
    new Compute as server:
        driver:
            id: EC2_EU_WEST
            key: mykey
            secret: mysecret

        size: t1.micro
        image: ami-4f504f3b

        ex_keyname: mysshkey
        name: myexample

        user: ubuntu
        private_key: mysshkey.pem

    resources:
      - Package:
          name: git-core

      - Checkout:
         name: /tmp/yaybu
         scm: git
         repository: {{ changesource.repository }}
         revision: {{ changesource.master }}

The GitChangeSource part polls and sets {{changesource.master}} with the SHA of the current commit.

This example changesource polls to learn if a new commit has occurred. This is only because the part is an example implementation - it could easily be a webhook or zeromq push event.

The Checkout resource uses the master property of changesource. Yaybu can use this dependency information to know that the Provisioner that owns the Checkout is stale and needs applying every time master changes.

If your Yaybufile contained another Provisioner that didn’t have such a Checkout (perhaps its the database server) then Yaybu would equally know not to deploy to it on commit.

Read the Docs v: 3.1
Versions
latest
3.1
3.0
Downloads
On Read the Docs
Project Home
Builds

Free document hosting provided by Read the Docs.