Kitchen::Marathon

A Test Kitchen Driver for Mesos Marathon.

This driver uses the Marathon REST API to create and destroy Marathon applications which act as Kitchen suites, allowing you to leverage the resources of a Mesos cluster to help reduce testing time.

To use this driver you will need access to a Mesos Marathon cluster. You will need to know the hostname and access credentials of the cluster for the plugin to access the REST API.

This cluster must be configured to run Docker containers.

This driver requires the following be true of the Marathon job configuration:

• You are running a Marathon container job of type "DOCKER".
• You can SSH into the container with a user specified username and private key.

This driver requires a slightly opinionated approach to Marathon Application configuration to assist in identifying what host port to use to acccess SSH running inside of a container.

If there is a single port mapping defined, the plugin will assume that this is where SSH is listening, if there is more than one port mapping defined, the plugin looks for a mapping label with the key of "SERVICE" and a value of "SSH".

The following is a slice of json showing the label:

{
  "container": {
    "docker": {
      "forcePullImage": true,
      "image": "someimagenamehere:latest",
      "network": "BRIDGE",
      "portMappings": [
        {
          "containerPort": 22,
          "hostPort": 0,
          "labels": {
            "SERVICE" : "ssh"
          },
          "protocol": "tcp"
        },
      ],
    },
    "type": "DOCKER",
  }
}

Please read the Test Kitchen docs for more details.

Example .kitchen.local.yml:

---
driver:
  name: marathon

# Username and key used to access the container
transport:
  ssh_key: '~/.ssh/vagrant'
  username: kitchen

driver_config:
  app_launch_timeout: 30
  app_template: '.kitchen-marathon.json'
  marathon_host: 'http://core-apps.mesos-marathon.service.consul:8080'

platforms:
- name: centos-7
  driver_config:
    app_config:
      container:
        docker:
          image: jdeathe/centos-ssh:centos-7
  run_list:
  - recipe[yum]

This is the prefix applied to Marathon App names.

The default value is kitchen/.

This allows for a Marathon Job template that will be used as the base template when the job template is created. If this value is not provided all configuration parameters need to be set via app_config.

The default value is nil.

This allows for Marathon Job configuration to be configured at the platform/suite/etc level as necessary.

This configuration is merged on top of any configuration provided by app_template.

The default value is {}.

Determines the timeout, in seconds, that the driver will wait for a Marathon App to deploy. If the timeout is reached, the driver will assume that the deployment will not succeed and will attempt to stop the deployment and delete the Marathon App. (This cleanup is best effort.)

The default value is 30 seconds.

The web address to the Marathon host.

The default value is http://localhost:8080.

The password to use for an HTTP AUTH protected Marathon Host

The default value is nil.

The username to use for an HTTP AUTH protected Marathon Host

The default value is nil.

Whether or not a certificate presented by the Marathon Host is verified.

The default value is true.

Provides the option to specify a proxy address if necessary when connecting to the Marathon host.

The default value is nil.

Provides the option to specify a proxy passowrd if necessary when connecting to the Marathon host.

The default value is nil.

Provides the option to specify a proxy port if necessary when connecting to the Marathon host.

The default value is nil.

Provides the option to specify a proxy username if necessary when connecting to the Marathon host.

The default value is nil.

• Source hosted at GitHub
• Report issues/questions/feature requests on GitHub Issues

Pull requests are very welcome! Make sure your patches are well tested. Ideally create a topic branch for every separate change you make. For example:

1. Fork the repo
2. Create your feature branch (git checkout -b my-new-feature)
3. Commit your changes (git commit -am 'Added some feature')
4. Push to the branch (git push origin my-new-feature)
5. Create new Pull Request

Created and maintained by Anthony Spring (aspring@yieldbot.com)

Apache 2.0 (see LICENSE)