Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/improbable-eng/docker-service-buildkite-plugin

Run separate Docker service containers alongside your primary build command in Buildkite.
https://github.com/improbable-eng/docker-service-buildkite-plugin

buildkite-plugin engineering-velocity

Last synced: 17 days ago
JSON representation

Run separate Docker service containers alongside your primary build command in Buildkite.

Awesome Lists containing this project

README

        

# Docker Service Buildkite plugin

A [Buildkite plugin](https://buildkite.com/docs/agent/v3/plugins) for running a container alongside
your build step. For example to ensure that a local Postgres instance is available in the step that
runs your database backend integration tests.

## Quickstart

The following step definition will spin up a PostgreSQL container with some default settings. The
container will be bound to both the localhost and external network interface of the machine running
the build. It will then run the `integration-tests.sh` script after which the container is spun
down.

```yaml
steps:
- label: integration-tests
command: ./integration-tests.sh
plugins:
- improbable-eng/docker-service#v0.3.0:
container: postgres:12.6
flags:
- --env=POSTGRES_DB=postgres
- --env=POSTGRES_USER=postgres
- --env=POSTGRES_PASSWORD=postgres
```

## Advanced usage

### Service logs

Any logs generated by the service container over the course of the build will be dumped at the end
into the `docker-service.logs` file. They can then be uploaded as part of the artifacts of your step
for later inspection.

### Specifying a custom command

You can also specify a specific command to run inside the docker container:

```yaml
steps:
- label: my-step
command: ./step-script.sh
plugins:
- improbable-eng/docker-service#v0.3.0:
container: a-container:1.2.3
cmd: "my-command --flag=value arg1 arg1"
```

### Multi-build network setup

If you have multiple builds running on the same machine they can end up requiring running the same
service via the Docker Service plugin. This creates conflicts when those services try to bind to the
same host port.

To address this issue use the `network` option. The plugin will attach the container running your
service to the specified docker network. It the network does not yet exist it will be created. The
IP of the container running the service will be available to your build via the `DOCKER_SERVICE_IP`
environment variable.

This information can then be used to attach another docker container to the same network and use the
service. This would typically require your build step to also run in a docker container, for example
by using the [Docker Buildkite plugin] with its `network` option.

```yaml
steps:
- label: my-dockerised-step
plugins:
- improbable-eng/docker-service#v0.3.0:
container: postgres:12.6
network: "postgres"
flags:
- --env=POSTGRES_DB=postgres
- --env=POSTGRES_USER=postgres
- --env=POSTGRES_PASSWORD=postgres
- buildkite-plugins/docker#v3.8.0:
container: "my-build-container:v1.0.0"
command: "./my-db-test-script.sh"
network: "postgres"
propagate-uid-gid: true
environment:
- DOCKER_SERVICE_IP
```

[Docker Buildkite plugin]: https://github.com/buildkite-plugins/docker-buildkite-plugin

## Configuration

| Option | Required | Type | Description | Default |
| --------- | :------: | --------------- | ----------------------------------------------- | ---------------- |
| container | **Yes** | string | Container image to run | n.a |
| cmd | No | string | Command to run in the container | `` |
| flags | No | list of strings | List of flags for 'docker run' | `` |
| network | No | string | Docker network to which to attach the container | `host` |

## Environment variables

The plugin will set the following environment variables which will be accessible to your build:

| Environment Variable | Description |
| --------------------------- | ----------------------------------------------- |
| DOCKER_SERVICE_CONTAINER_ID | Docker ID of the container running the service. |
| DOCKER_SERVICE_IP | IP at which the service can be reached. |