PlacementStrategy

Placement Process

The DockerInfrastructure consists of a Cluster of DockerHost entities, each running the Docker Engine software. Blueprints deployed to the infrastructure will have a DockerContainer created for each of their entities. This container will be created on a DockerHost, and the placement strategies that are configured define how that host is chosen. If all available hosts are rejected when trying to place an entity, then a new Docker host will be provisioned for the container.

The Docker Cloud application on the root infrastructure entity can have a list of strategies configured, using the docker.container.strategies key. This defaults to a single DepthFirstPlacementStrategey. Additionally, the entities in the blueprint being deployed can have their own strategy list defined. These strategies are checked in order, first the infrastructure list then the entity list, for each container being created. The purpose of a strategy is to examine the available hosts and check their suitability for the entity being assigned a new container. They will filter the hosts and return them in order of preference for placement.

Available Strategies

BreadthFirstPlacementStrategy

Accepts all hosts and returns them in a fixed order, rotating the starting point each time it is used. This gives a round-robin style balancing effect.

RandomPlacementStrategy

Accepts all hosts and returns them in a random order.

DepthFirstPlacementStrategy

Accepts all hosts and returns them in a fixed order. Because the first returned host will normally be used this has the effect of filling that host until it is reject by some other strategy, such as the maximum container size.

LowestCpuUsagePlacementStrategy

Accepts all hosts and returns them ordered by current CPU usage, lowest first.

LeastContainersPlacementStrategy

Accepts all hosts and returns them ordered by current number of containers, lowest first.

MaxContainersPlacementStrategy

Rejects any hosts with more than maxContainers already deployed, and leaves ordering unchanged.

MaxCpuUsagePlacementStrategy

Rejects any hosts with current CPU usage greater than maxCpu, and leaves ordering unchanged.

LabelPlacementStrategy

Checks host tags against configured set of labels.

HostnamePlacementStrategy

Checks the hostname matches a given regular expression.

Placement Strategy Definition

Strategies are configred in the YAML blueprint for the Docker Cloud application as Brooklyn objects in a list; the default setting for Clocker is as follows:

    docker.container.strategies:
    - $brooklyn:object:
        type: "brooklyn.location.docker.strategy.MaxContainersPlacementStrategy"
        brooklyn.config:
          maxContainers: 8
    - $brooklyn:object:
        type: "brooklyn.location.docker.strategy.BreadthFirstPlacementStrategy"
    - $brooklyn:object:
        type: "brooklyn.location.docker.strategy.MaxCpuUsagePlacementStrategy"
        brooklyn.config:
          maxCpuUsage: 0.75

This configuration is for 8 containers per host maximum, with breadth first placement, and will reject any host with CPU usage over 75%.

The next strategy shown will choose a host that has the ssd label set. This would normally be configured when the hosts are created, for example by setting metadata or by using the cloud provider's console to add a tag for particular VMs. In this case we assume that hosts provisioned with SSD storage have the ssd tag set, and we want our NoSQL store to take advantage of this.

- serviceType: brooklyn.entity.nosql.redis.RedisStore
  brooklyn.config:
    docker.container.strategies:
    - $brooklyn:object:
        type: "brooklyn.location.docker.strategy.LabelPlacementStrategy"
        brooklyn.config:
          labels:
          - "ssd"

Placement Strategy Implementation

User defined placement strategies can be configured if the classes are available to Clocker. A strategy is simply a Java class implementing the DockerAwarePlacementStrategy interface. They can extend the AbstractDockerPlacementStrategy and implement the filterLocations method directly, which is passed the list of available hosts and the entity requesting placement.

    /**
     * Filters a list of {@link DockerHostLocation locations} to determine if the given {@link Entity} can be
     * deployed into a new container there.
     */
    List<DockerHostLocation> filterLocations(List<DockerHostLocation> locations, Entity context);

Alternatively, the BasicDockerPlacementStrategy is available. Classes extending this should implement both a Predicate that accepts or rejects DockerHostLocation instances and a Comparator that can order the locations. The default behaviour is to accept all hosts, with no ordering.