Posts Tagged “wercker”

Deploying from wercker to fortrabbit

Today we got a support ticket from a user that wants to deploy his PHP application to fortrabbit, a PHP as a service provider. To help this customer I decided to create a small sample app and try to deploy it to fortrabbit. This blogpost describes the steps I took. I will give you a short summery right away: It was pretty damn easy!

The PHP application

I have a very simple PHP application that echo's some cities in json format from the index.php. Here is the content of index.php:

$cities = array("Amsterdam", "San Francisco", "Berlin",
                "New York", "Tokyo", "London");

header('Content-Type: application/json');
echo json_encode($cities, JSON_PRETTY_PRINT);

It also contains some tests and has a small wercker.yml that defines the build pipeline. Here is the content of wercker.yml:

# Execute the pipeline with the wercker/php box
box: wercker/php
    # Install dependencies with composer
    - script:
        name: install dependencies
        code: |-
            composer install --no-interaction
    # Spin webservice and serve site
    - script:
        name: Serve application
        code: php -S localhost:8000 >> /dev/null &
    # Execute integration tests with php unit
    - script:
        name: PHPUnit integration tests
        code: phpunit --configuration phpunit.xml

Generating SSH Key

Wercker has the ability to generate SSH keys that are available from the build and deployment pipeline. These can be generated from the application settings tab at wercker. I generate a key with the name fortrabbit and wercker shows me the public key.

generating an ssh key at

Adding public key to fortrabbit

To be able to git push deploy to fortrabbit we need to add the public key part of the SSH key pair to our application. This can be done in the manage view of your application via the application overview.

application overview

Navigate to the git tab.

git tab

Enter a name for the git user, I picked wercker and paste the public key part into the big text area.

git tab

Hit the Save Git Users button to confirm.

Deployment pipeline

I have played a bit and came up with the following deployment pipeline that I added to the wercker.yml:

    - add-to-known_hosts:
        hostname: $FORTRABBIT_GIT_HOST
    - script:
        name: Setup git repository
        code: |-
          # Remove existing git repository if exists
          if [ -d ".git" ]; then rm -rf .git; fi

          # Configure git user
          git config --global "wercker"
          git config --global

          # Initialize new repository and add everything
          git init
          git add .
          git commit -m 'Deploy commit'

          # Add fortrabbit remote
          git remote add fortrabbit "$FORTRABBIT_GIT_REMOTE"
    - script:
        name: Make .SSH directory
        code: mkdir -p "$HOME/.ssh"
    - create-file:
        name: Write SSH key
        filename: $HOME/.ssh/id_rsa
        overwrite: true
        content: $FORTRABBIT_KEY_PRIVATE
    - script:
        name: Set permissions for SSH key
        code: |-
          chmod 0400 $HOME/.ssh/id_rsa
    - script:
        name: Git push deploy
        code: |-
          git push fortrabbit master -f

Most steps should be self explaining, but here is what is it does in plain English:

* Trust forstrabbit git hostname, eq: ``
* Setup git repository and add all files to push
* Add SSH private key for authentication
* Git push deploy to fortrabbit

Add deploy target

The last step is to add an deploy target to the application at wercker. This can be done via the settings tab of the application:

add deploy target

I name it production, and enable auto deploy for the master branch.

deploy target basic properties

We can add environment variables to the deploy target to make information available during the deployment. I start by exposing the SSH key that I have added earlier:

add ssh key variable

Next I add the two text variables FORSTRABBIT_GIT_REMOTE and FORSTRABBIT_GIT_HOST, which I set to the values displayed on the git tab at fortrabbit.


Navigate to your latest build and choose deploy:


When the deploy is finish I proudly look at the running version of the application:

cities running at fortrabbit


Simplify your Jekyll publishing process with wercker

With many bloggers moving to static site generators and success stories like Obama's $250 million fundraising platform people are accepting static site generators as a serious alternative. Especially when security and performance is important.

Regardless of all the goodness that static site generators offer, they come with a price. You need to regenerate the site every time the content changes. This must be done by a machine that has the static site generator software installed. Although this may not be a problem when you are at the office, it will withhold you from finishing an article on your tablet or fixing a typo from your cell phone.

Wercker to the rescue!

Wercker is a collaborative continuous delivery platform in the cloud. You can leverage its power to do the content generation and deployment process for you. In this post we will focus on how you set up such a process for a Jekyll site that is hosted on Amazon S3.


Add your application to wercker

First you need to add an application to wercker. Sign in at wercker and click the big blue add an application button.


Follow the steps given and make sure you give the werckerbot user, read rights on your repository at Github or Bitbucket.

At the end of the process the following screen appears.


Creating the wercker.yml

Now it is time to define your build process. This is the pipeline that will get executed everytime changes are pushed to the git repository.

Create a new file called wercker.yml in the root of your repository with the following content:

# our build should run within a Ruby box
box: wercker/ruby
    # Run a smart version of bundle install
    # which improves build execution time of
    # future builds
    - bundle-install

    # A custom script step
    # that actually builds the jekyll site
    - script:
        name: generate site
        code: bundle exec jekyll build --trace

Lets briefly go through the wercher.yml file. The first line contains box: wercker/ruby which defines that you want to run the build in a Ruby box (by default this is Ruby version 1.9.3p429). The second line describes the build section that consists of steps, in this case there are two steps. These steps are performed during the execution of the build process. The first step bundle-install is a smart version of the bundle install command that leverages caching so future builds will run faster. The second step script executes the script that is defined the code clause that consists of a single command bundler exec jekyll build --trace. This step actually builds your Jekyll site.

Add wercker.yml to your repository

After you created the wercker.yml add it to your repository by executing the following commands.

git add wercker.yml
git commit -m 'Add wercker.yml'
git push origin master

Because you have created an application for this repository at wercker it should now start building. Open the application page at wercker to see the following result.


Congratulations, you first green build on wercker! If you tweet me or e-mail a screenshot I will make sure you receive a wercker sticker to celebrate.

Add deployment target information

Now you have automated your content generation process that will get executed every time you push your code to git. This is helpful to catch jekyll errors early, but without deployment it doesn't help your actual live website. Let's add a deploy target to your application on wercker so we can close the loop!

Go to your application at and click on the settings tab.


A new form opens that you can use to enter information that is passed to the deployment context. Here you enter the details of your Amazon S3 bucket. The key and secret key can be found in the AWS security credentials page.


We leverage environment variables, in faith with the 12 factor design principles.

note: these aren't my real keys… duh!

If you host your website somewhere else you can leverage the custom deploy target for any type of deployment (for instance FTP or rsync)

Add deployment steps

The current wercker.yml file contains the steps that are executed when the application is built. Now you want to add steps that are run when the application is actually deployed. These steps are performed in a context that hold the information you have entered in the previous section; key, secret and s3 url.

Add the following to the end of your current wercker.yml file:

    - s3sync:
        key_id: $KEY
        key_secret: $SECRET
        bucket_url: $URL
        source_dir: _site/

The s3sync step synchronises a source directory with an Amazon S3 bucket. The key_id, key_secret and bucket_url options are set to the information from the deploy target, previously created. Only the source_dir option is hard coded (or should I say hard configured) to _site/. This is the directory where Jekyll stores the output.

We could also hard code the key and key secret in here, but that is not something you want to put in your git repository. Especially not when you repository is public like mine.

Commit the changes of the wercker.yml file and push them to your repository.

git add wercker.yml
git commit -m 'Add deployment section'
git push origin master

Deploy it!

You have pushed changes to your repository, thus wercker created another build. Now the deployment information that you have added in the previous steps can be used to deploy the website. This can be done for every successful build in your application by clicking the blue deploy button.


Did anything go wrong?

Let me help you! Just tweet me or sent me an e-mail

Learn more