Using Docker

You can also make use of Docker in Scrutinizer's build environment. Simply enable it by adding the following to your configuration:

build:
    environment:
        docker: true

This will automatically start the Docker daemon and install a recent version of Docker Compose.

Extended Compatibility Mode (Remote Engine)

By default, Docker runs inside the build container. As a result, some syscalls are restricted, and depending on how you use Docker, you might run into errors like open /proc/####/environ: permission denied, failed to register layer or general permission/operation denied errors.

For these cases, Scrutinizer provides a separate environment with a Docker engine running that provides un-restricted syscalls. Simply, set the remote_engine flag to true in your configuration:

build:
    environment:
        docker:
            remote_engine: true

Accessing Exposed Ports

Any ports that are exposed are not exposed on localhost as the Docker engine is not running inside the local build environment, but are exposed in the remote host. You can access services exposed there using the $DOCKER_IP environment variable.

Volume Limitations and Solutions

When using volumes with remote_engine enabled, those volumes are not referring to the local build environment, but to the host that the Docker engine is running in. As such, you can't mount a local repository folder if remote engine is enabled. This behavior is the same as if you were running Docker via Docker Machine as is common on Mac OS X.

So, if you run a command like docker run -v ./some-file:/image-path/some-file my-base-image some-command, this would not work when the remote engine is enabled. To overcome this, simply create an image where you copy the file to the desired location. For the example above, the Dockerfile can look like this:

FROM my-base-image

COPY ./some-file /image-path/some-file

You can then build the image in the build environment docker build -t my-build-image -f Dockerfile ., and after that run your original command docker run my-build-image some-command.

Defining Registry Logins

If you want to push images or pull private images from a registry, you can define logins in the configuration:

build:
    environment:
        docker:
            logins:
            - { username: "my-user", password: "my-password" } # DockerHub
            - { username: "another-user", password: "some-pass", server: "quay.io" }

Caching Images

If you would like us to cache certain base images, you can define those too:

build:
    environment:
        docker:
            cache:
                images:
                - "scrutinizer/web:base-123"     # Exact name including tag name
                - "scrutinizer/*"                # Wildcard match against repository name
Note: We currently have to use the vfs storage driver of Docker. This means that each layer is a full copy of the image. If you have many layers, it may be faster to not cache them, but re-download them on-the-fly.