This article describes advanced usage of service containers within wercker.
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
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
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.
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 as an alias to the hostname, so inside your client container, you can query DNS for the service host. For more information, see Service Container Networking.
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.