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.
Requirements
Mesos/Marathon
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.
Marathon Job Configuration
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",
}
}
Installation and Setup
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]
Configuration
app_prefix
This is the prefix applied to Marathon App names.
The default value is kitchen/
.
app_template
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
.
app_config
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 {}
.
app_launch_timeout
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.
marathon_host
The web address to the Marathon host.
The default value is http://localhost:8080
.
marathon_password
The password to use for an HTTP AUTH protected Marathon Host
The default value is nil
.
marathon_username
The username to use for an HTTP AUTH protected Marathon Host
The default value is nil
.
marathon_verify_ssl
Whether or not a certificate presented by the Marathon Host is verified.
The default value is true
.
Marathon Proxy Configuration
marathon_proxy_address
Provides the option to specify a proxy address if necessary when connecting to the Marathon host.
The default value is nil
.
marathon_proxy_password
Provides the option to specify a proxy passowrd if necessary when connecting to the Marathon host.
The default value is nil
.
marathon_proxy_port
Provides the option to specify a proxy port if necessary when connecting to the Marathon host.
The default value is nil
.
marathon_proxy_username
Provides the option to specify a proxy username if necessary when connecting to the Marathon host.
The default value is nil
.
Development
- 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:
- Fork the repo
- Create your feature branch (
git checkout -b my-new-feature
) - Commit your changes (
git commit -am 'Added some feature'
) - Push to the branch (
git push origin my-new-feature
) - Create new Pull Request
Authors
Created and maintained by Anthony Spring ([email protected])
License
Apache 2.0 (see LICENSE)