Service Containers

Service containers are additional containers that run along with the main container defined in a step. The main purpose of service containers is providing network accessible services. For example, the main container runs tests that require a MySQL database and a Redis instance running in separate service containers.

Define service containers

For instance, in the following example, the main container pings a service container 5 times:

job("Use service") {
    container(displayName = "Ping service", image = "alpine") {
        shellScript {
            content = "ping -c 5 db"
        }

        service("mysql:5.7") {
            alias("db")
            env["MYSQL_ROOT_PASSWORD"] = "pwd1234"
        }
    }
}

To define a service container, you should use the service function.
service can be placed only inside container (the main container).
Note that service containers do not let you run shell scripts and Kotlin code using shellScript and kotlinScript.

Access service containers

You can access a service container from the main container only by using the network connection. To access a service container, you should use its hostname. By default, the hostname is created from the container's image name:

All characters after the colon : are discarded.
All characters except letters, digits, dashes -, and underscore symbols _ are replaced by a dash -.

For example, a service container defined as service("myimages/mysql:5.7") will get the hostname myimages-mysql.

Alternatively, you can set the container's hostname using the alias keyword. For example, here we specify db as the hostname:

service("mysql:5.7") {
    alias("db")
}

Also note that:

It is not possible to access the main container from a service container, or one service container from another.
Situations, when you have two or more containers with the same hostname, are not handled by Automation: which service will be available under this hostname is undefined.

When do service containers run

Service containers always start before the main container.

Define service container resources

You can define no more than 7 service containers inside a container.
As well as the main container, a service container has its own resources constraints set by resources:
service("mysql:5.7") { alias("db") resources { cpu = 1024 memory = 768 } }
The default constraints are: 2 vCPU (2048 CPU units), 7800 MiB.
Overall resources allocated for the main container and all its service containers are limited to 4 vCPU (4096 CPU units) and 16 GB memory.

View service container logs

Open the project's Jobs page.
Open the Steps tab.
In the left pane, choose the desired step and service. The logs will be shown in the right pane.

Usage example

One of the most typical service contatiner purposes is running some network services required by unit tests. In the example below, the job runs tests that require a MySQL database, a Redis instance, and an Elastic Search instance:

job("Run tests") {
    gradlew("gradle:6.1.1-jdk11", ":tests:test") {
        env["DB_HOST"] = "db"
        env["DB_PORT"] = "3306"
        env["ELASTIC_HOST"] = "elasticsearch"
        env["ELASTIC_PORT"] = "9200"
        env["REDIS_HOST"] = "redis:6379"

        service("mysql:5.7") {
            alias("db")
            args("--log_bin_trust_function_creators=ON",
                    "--max-connections=700")
            env["MYSQL_ROOT_PASSWORD"] = "pwd1234"
            env["MYSQL_DATABASE"] = "mydb"
        }

        service("docker.elastic.co/elasticsearch/elasticsearch:6.5.4") {
            alias("elasticsearch")
        }

        service("redis:4.0.2-alpine") {
            alias("redis")
        }
    }
}

Last modified: 15 December 2023