Advanced Services

This article describes advanced usage of service containers within wercker.

Injecting environment variables in services

Services such as databases often need environment variables defined in order to run. Typical examples are usernames and passwords. You therefore probably want to start off by defining your service containers and reference them through an ID:

services:
    - id: mongo

Next you want to pass along additional environment information, such as a username and password:

services:
    - id: mariadb
      env:
        MYSQL_ROOT_USERNAME: myusername
        MYSQL_ROOT_PASSWORD: mysecretpassword

Custom entrypoint command for services

It could be that the Docker container that you are using for a service does not have an ENTRYPOINT or command to run upon launching the container.

You can specify a command for your container to run on launching in your wercker.yml as follows:

services:
    - id: shannon/awesome-service
      username: $USERNAME
      password: $PASSWORD
      tag: latest
      cmd: my_amazing_command

Here we use a the container awesome-service by the user shannon and define the command to be run when launching the container my_amazing_command.

Per-pipeline services

Sometimes you want a service to be only available in a specific pipeline as opposed to a global service. You can define services on a per-pipeline basis as follows:

build:
  services:
    - id: mariadb
      username: $USERNAME
      password: $PASSWORD
      tag: latest

  box:
    id: google/golang
    steps:
       # Build the project
      - script:
          name: go build
          code: |
            go build ./...

Here we define the mariadb service to be only available in the build pipeline.

Local services

You can develop your services locally using local services. The service syntax is largely the same, except we add a url field, which points to the service you want to use on disk.

Below is an example of a project that uses a local service:

services:
    - redis
    - id: bestservice
      url: file://../api#dev
      cmd: python /pipeline/source/app.py
box: python:2.7
dev:
  steps:
    - pip-install
    - internal/watch:
        name: start web server
        code: python app.py
        reload: false

The service id bestservice has special meaning here. We’ll use the ID to set up the docker link, so inside your client container, you can query DNS for the service host.

The url field should be a file pointer of the form file://<path>#<pipeline>. The path can be absolute or relative, and the fragment should be the pipeline of the service to run. In the below service YAML, dev will be run when we start the service.

services:
    - redis
dev:
  box: python:2.7
  steps:
    - pip-install
    - internal/watch:
        name: start API server
        code: |
            python app.py

When running Wercker on the above example, YAML will first run the bestservice, as if it were a normal build, and then commit the image. Next, it will start the Redis service and the bestservice image we committed earlier. Finally, it will start the Python image and link it with the services.

Because of the way we commit the image, you will need to give it a command to run when it starts. Currently, environmental variables are not exposed in the service box, so you will need to give it the absolute path to the source directory.

You will also need to add any services your services depend on to your client YAML because we don’t currently inspect the service YAML to find out which services it depends on.