-
Notifications
You must be signed in to change notification settings - Fork 1
Container support
Cloudify supports integrations with Docker and Docker-based container managers, including Docker, Docker Swarm, Docker Compose, Kubernetes, and Apache Mesos. At a minimum, Cloudify supports the creation, scaling, and healing of the platforms themselves. For Kubernetes and Docker Swarm, service orchestration is also supported. When orchestrating other orchestrators (e.g. Kubernetes, Swarm, Mesos), the Cloudify philosophy is to lightly integrate so that native descriptors can be used if desired. Options are also provided to use TOSCA based configuration for services, but support is more limited than native descriptors.
The Docker plugin is a Cloudify plugin that defines a single type: cloudify.docker.Container. The plugin is compatible with Docker 1.0 (API version 1.12) and relies on the docker-py library. The plugin executes on a computer host that has Docker pre-installed.
-
imageA dict describing a docker image. To import an image from a tarball use the src key. The value will be an absolute path or URL. If pulling an image from docker hub, do not use src. The key is repository. The value is that repository name. You may additionally specify the tag, if none is given, latest is assumed. -
nameThe name of the Docker container. This will also be the host name in Docker host config. -
use_external_resourceBoolean indicating whether the container already exists or not.
The cloudify.interfaces.lifecycle interface is implemented, and supports the following function parameters
-
createinputs: -
paramsA dict of parameters allowed by docker-py to the create_container function -
startinputs: -
paramsA dictionary of parameters allowed by docker-py to the start function -
processes_to_wait_forA list of processes to verify are active on the container before completing the start operation. If all processes are not active the function will be retried. -
retry_intervalBefore finishing start checks to see that all processes on the container a A dictionary of parameters allowed by docker-py to the stop function.re ready. This is the interval between checks. -
stopinputs: -
paramsA dictionary of parameters allowed by docker-py to the stop function. -
retry_intervalIf Exited is not in the container status, then the plugin will retry. This is the number of seconds between retries. -
deleteinputs: -
paramsA dictionary of parameters allowed by docker-py to the remove_container function.
The Docker Swarm blueprint creates and manages a Docker Swarm cluster on Openstack. There are 3 blueprints, with slightly different use cases:
- swarm-local-blueprint.yaml : a cfy local blueprint that orchestrates setup and teardown of the cluster without a manager
- swarm-openstack-blueprint.yaml : an Openstack blueprint that orchestrates setup and teardown of the cluster with a manager
- swarm-scale-blueprint.yaml : an Openstack blueprint that orchestrates setup, teardown, autohealing, and autoscaling of the cluster
These blueprints have only been tested against an Ubuntu 14.04 image with 2GB of RAM. The image used must be pre-installed with Docker 1.12. Any image used should have passwordless ssh, and passwordless sudo with requiretty false or commented out in sudoers. Also required is an Openstack cloud environment. The blueprints were tested on Openstack Kilo.
The swarm-local blueprint is intended to be run using the cfy local CLI command. As such, no manager is necessary. The blueprint starts a two node Swarm cluster and related networking infrastructure in Openstack.
-
imageThe Openstack image id. This image will be used for both master and worker nodes. This image must be prepared with Docker 1.12, as well as support passwordless ssh, passwordless sudo, and passwordless sudo over ssh. Only Ubuntu 14.04 images have been tested. -
flavorThe Openstack flavor id. This flavor will be used for both master and worker nodes. 2 GB RAM flavors and 20 GB disk are adequate. Flavor size will vary based on application needs. -
ssh_userThis blueprint uses the Fabric plugin and so requires ssh credentials. -
ssh_keynameThe Openstack ssh key to attach to the compute nodes (both master and worker). -
ssh_keyfileThis blueprint uses the Fabric plugin and so requires ssh credentials.
The blueprint contains a dsl_definitions block to specify the Openstack credentials:
-
usernameThe Openstack user name -
passwordThe Openstack password -
tenant_nameThe Openstack tenant -
auth_urlThe Openstack Keystone URL
The Docker Swarm Plugin provides support for deploying services onto Docker Swarm clusters, as well as support for Docker Compose.
A type that represents a Swarm manager not managed by Cloudify. If a Cloudify managed manager is used, the Cloudify proxy plugin should be used instead.
-
ipThe IPV4 address of the Swarm manager -
portThe port the manager REST API is listening on (default 2375) -
ssh_userAn ssh user for operations that require ssh (Docker Compose) -
ssh_keyfileAn ssh private key for operations that require ssh (Docker Compose)
The cloudify.swarm.Microservice type represents a Docker Swarm service. It can be configured to use TOSCA-style properties or point to an external Swarm yaml descriptor.
-
compose_fileThe path to a Docker compose descriptor file. If set, all other properties are ignored. - all other properties are translated into the Docker REST service create API call. Properties in the blueprint are encoded with underscores between words (e.g.
log_driver) and converted internally to the REST API body camel case (e.g.LogDriver). See comments in the plugin.yaml for an extensive example.
-
cloudify.swarm.relationships.microservice_contained_in_managerThis relationship connects a Microservice to a manager. The implementation allows the target to be either acloudify.swarm.Managertype or acloudify.nodes.DeploymentProxytype.
The Kubernetes Plugin provides support for deploying services on Kubernetes clusters.
The Kubernetes Blueprint creates and manages a Kubernetes cluster on Openstack and Amazon EC2.