{ "info": { "author": "MaibornWolff", "author_email": "", "bugtrack_url": null, "classifiers": [ "Development Status :: 4 - Beta", "Environment :: Console", "License :: OSI Approved :: Apache Software License", "Programming Language :: Python :: 3", "Programming Language :: Python :: 3.5", "Programming Language :: Python :: 3.6", "Programming Language :: Python :: 3.7" ], "description": "

\"dcos-deploy\"

\n\ndcos-deploy is a command line tool that helps you to deploy and manage groups of services and apps on [DC/OS](https://dcos.io). It acts as an orchestration engine on top of the existing DC/OS tools and APIs to install, configure and update frameworks, marathon apps and metronome jobs. It is based on a yaml-configuration file which describes the services that you want. It will read this file and execute any changes necessary so that your DC/OS cluster reflects your desired configuration.\n\nFor example: To deploy a complete elasticsearch stack on your cluster you would typically need to install the elasticsearch framework from the DC/OS universe, a kibana app, expose both to your loadbalancer and add some regular jobs for backups and cleanup. Additionally if you run elasticsearch with x-pack or searchguard installed you also need to create a public-private keypair, service-account and secret for your framework. This amounts to quite a number of steps. With dcos-deploy you just describe your entire stack in one simple yaml file and let dcos-deploy do the rest. See the examples folder for more.\n\n(!) This tool is under heavy development. Use in production environments at your own risk.\n\n## Features\n\n* Handles the following \"entities\":\n * DC/OS packages\n * Marathon apps\n * Metronome jobs\n * secrets\n * serviceaccounts\n * public-private-keypairs (for use in secrets)\n * [Edge-LB](https://docs.mesosphere.com/services/edge-lb/)\n * [S3](https://aws.amazon.com/s3/) files\n* For DC/OS packages it supports version updates and configuration changes.\n* Handles install and update dependencies between entities (e.g. a framework is only installed after its serviceaccount is created, an app is restarted if an attached secret changes).\n* Parameterise your configuration using variables (e.g. to support different instances of a service).\n* Stateless / no backend: There is no local or remote state. Everything needed is pulled directly from the cluster: dcos-deploy is a client-only tool that directly uses the existing DC/OS APIs to access your DC/OS cluster and does not need its own backend service.\n* Uses your installed dcos-cli to figure out how to talk to your cluster. No extra configuration needed.\n* dry-run mode: Check which changes would be done.\n* partial deployment: Choose the entities to be deployed.\n* Can be extended with extra modules (still in development).\n\n\n### Limitations\n* Deleting packages/apps/jobs is not supported: Since dcos-deploy does not keep a state it cannot detect if you remove a service/app/job from its configuration. Therefore you are responsible to delete any no longer wanted entities yourself.\n* Frameworks/packages with more complicated update procedures (like Edge-LB) are at the moment not fully supported.\n\n\n## Requirements\n* A DC/OS cluster with version >= 1.11 (for features like secrets an EE cluster is needed)\n* dcos-cli installed and connected to your cluster (to verify it works run `dcos node` and it should display a list of nodes in your cluster)\n\nIf you want to run it from source, aditionally you need:\n* Python >= 3.5\n* Python modules from `requirements.txt`\n\n## Installation\nThere are several ways to install dcos-deploy:\n* Binary\n * Download the binary for your system from the Releases page\n * Make the file executable and copy it into a folder inside your path\n* Install from pypi (`pip install dcos-deploy`)\n* Run from source\n * Clone this github repository to your system (for a stable release checkout a release tag)\n * Install all requirements from `requirements.txt` (optional: use a virtualenv to keep your system clean)\n * Optional: Create a symlink of `dcos-deploy` to a folder in your exectuable path (e.g. `ln -s $(pwd)/dcos-deploy ~/usr/bin/dcos-deploy`)\n\n## Usage\n* Create your `dcos.yml` (start from scratch or use one of the examples). You should separate your stack into groups and create a `dcos.yml` for each of them (e.g. one for all hdfs related services, one for all elastic related and so on) to keep the complexity manageable.\n* Run `dcos-deploy apply`.\n* See `dcos-deploy apply --help` for all options.\n\n### Credentials\n\ndcos-deploy has several ways to retrieve connection credentials for your DC/OS cluster:\n\n* dcos-cli: By default dcos-deploy uses the authentication information from the dcos-cli, so make sure you are logged in (verify by running `dcos node`, if it works you should see a list of nodes in your cluster).\n* Static token via environment variables: `DCOS_BASE_URL` (set this to the public URL of your master) and `DCOS_AUTH_TOKEN` (set this to a valid auth token). This way is handy for automation situations where you do not want to expose the admin username and password by adding them to your automation tool (e.g. Gitlab CI secrets). Instead you can provide the automation job with short-lived credentials.\n* DC/OS serviceaccount secret: If you are running dcos-deploy from inside your DC/OS cluster (e.g. in a metronome job) you can also provide the credentials via a serviceaccount secret. To do that create a serviceaccount with superuser rights and expose its credentials secret to your service/job via the environment variable `DCOS_SERVICE_ACCOUNT_CREDENTIAL`. Also provide the variable `DCOS_BASE_URL` and set it to the internal URL of your master (should be `https://leader.mesos` in most cases).\n\n## Config file syntax\nThe config file is written as a yaml file. The root level consists of key/value-pairs (a dictionary). Each key represents the unique name for one entity, the value is again a dictionary with all the options for that entity.\n\n### Meta fields\nThere are some meta fields for further configuation:\n* `variables`: Define variables to be used in the rest of the file and in app definitions and package options. See the [Variables](#variables) section for more info.\n* `includes`: Structure your config further by separating parts into different files and including them. Provide a list of filenames. The include files must be structured the same way as the main file. Each entity name must be unique over the base file and all included files.\n* `modules`: Extend the features of dcos-deploy using external modules (still in development, not documented yet).\n\n### Variables\nTo be more generic with your services you can use variables in certain places. All variables must be defined in the `variables` section of your config file.\n```\nvariables:\n var1:\n required: True # Required variables must be provided when calling dcos-deploy using the -e option (e.g. -e var1=foo)\n var2:\n required: False\n default: foobar # If a variable is not provided by the user the default value is used. Variables without a default are treated as empty values\n var3:\n values: # You can restrict the allowed values for a variable\n - foo\n - bar\n - baz\n default: bar\n var4:\n env: MY_VAR4 # Variables can also be read from the environment\n required: True\n var5:\n file: myvalue.txt # The value of the variable will be the content of the file. Can be useful to provide longer values\n encode: base64 # This will encode the value using base64. Some DC/OS frameworks have config options that require base64-encoded values. Using this option the value can be kept in clear-text and will be automatically encoded by dcos-deploy when rendering the options file for the framework.\n```\n\nVariables can be used via [Mustache](http://mustache.github.io/) templates in most options and in marathon app definitions and package options. See `examples/elastic` for usage examples. You can not use variables in entity names or outside option strings (ground rule: the yaml file must be syntactically correct without mustache template rendering).\n\nSome variables are automatically provided by `dcos-deploy` based on your cluster. These are:\n\n* `_cluster_version`: The DC/OS version of your cluster, for example `1.12.2`\n* `_cluster_variant`: The DC/OS variant of your cluster, for example `enterprise`\n* `_num_masters`: The number of masters in your cluster\n* `_num_private_agents`: The number of private agents in your cluster (useful if you want to tailor the size of an app or framework node to the cluster size)\n* `_num_public_agents`: The number of public agents in your cluster\n* `_num_all_agents`: The number of public and private agents in your cluster\n\n### Global config\nTo specifiy an attribute for all entities of a specific type you can define it in the global config. The config for a specific entity will be merged with the global config for the corresponding type.\n\nExample:\n```\nglobal:\n s3file:\n server:\n endpoint: \"{{s3_endpoint}}\"\n access_key: \"{{s3_access_key}}\"\n secret_key: \"{{s3_secret_key}}\"\n```\n\n### Encryption\ndcos-deploy supports encrypting files so that sensitive information is not stored unencrypted. Files are symmetricly encrypted using [Fernet](https://cryptography.io/en/latest/fernet/) (AES-128) from the python [cryptography](https://cryptography.io/en/latest/) library.\nIn most places where you provide a filename (at the moment not possible with `s3file`) you can use encrypted files by using the following syntax as filename: `vault::`.\nYou should use a variable for the encryption key.\n\nExample:\n```\nvariables:\n encryption_key:\n env: ENCRYPTION_KEY\n required: True\n\nservicepasswords:\n type: secret\n path: /myservice/passwords\n file: \"vault:{{encryption_key}}:servicepasswords.encrypted\"\n```\n\nYou can also specify the encryption key in the global config to avoid writing it for every occurence:\n```\nvariables:\n encryption_key:\n env: ENCRYPTION_KEY\n required: True\n\nglobal:\n vault:\n key: \"{{encryption_key}}\"\n\nservicepasswords:\n type: secret\n path: /myservice/passwords\n file: vault::servicepasswords.encrypted\n```\n\n\ndcos-deploy has several util commands that help you in creating encrypted files:\n* `dcos-deploy vault generate-key`: Generates a new key that you can use for encrypting files\n* `dcos-deploy vault encrypt`: Encrypts a file using a given key\n* `dcos-deploy vault decrypt`: Decrypts a file using a given key\n\nExample usage:\n```\n$ echo \"supersecret\" > servicepasswords\n$ dcos-deploy vault generate-key\nYour new key: 6htLemxXcEXnahVl1aZI6Aa3TXIHmbE8abtibC2iO6c=\nKeep this safe.\n$ export ENCRYPTION_KEY=\"6htLemxXcEXnahVl1aZI6Aa3TXIHmbE8abtibC2iO6c=\"\n$ dcos-deploy vault encrypt -i servicepasswords -o servicepasswords.encrypted -e ENCRYPTION_KEY\n$ cat servicepasswords.encrypted\ngAAAAABb9rkSdEqT1xn0w5G5ipjPH6Vd5TsUfDLAWnN7I8FXTOPK6t1tMUstm8nA_yiA6SV5B1Blxj1h-xqCl8VqqbH7D7RF9Q==\n$ dcos-deploy vault decrypt -i servicepasswords.encrypted -o servicepasswords.clear -e ENCRYPTION_KEY\n$ cat servicepasswords.clear\nsupersecret\n```\n\nTo use encrypted files with includes make sure that the variable for the encryption key is either defined in the file itsself or in an included file that is read before the encrypted one.\n\n\n### Entity\nEach entity has the same structure and some common options:\n```\nentityname:\n type: foo\n only:\n var1: foo\n except:\n var2: bar\n dependencies:\n - otherentity\n```\n\n`type` defines what kind of entity this is. Currently implemented are\n* `app`\n* `framework`\n* `job`\n* `account`\n* `secret`\n* `cert`\n* `repository`\n* `edgelb`\n* `s3file`\n* `taskexec`\nSee their respective sections below for details.\n\n`only` and `except` take key/value-pairs of variable names and values. These are evaluated when reading the config file based on all provided and default variables. The entity is excluded if one of the variables in the `only` section does not have the value specified or if one of the variables in the `except` section has the specified value. In the example above the entity is only included if `var1 == foo` and `var2 != bar`. If a variable in the `only` section is not defined (no default value) the condition is treated as false and the entity is ignored.\n\n`dependencies` takes a list of entity names that this entity depends on. Optionally the dependency type can be provided. Currently supported are `create` (default) and `update`. They can be defined by adding a colon after the entity name and then the type (e.g. `otherentity:create`). A `create` dependency is only honored during creation time of an entity and means that the entity will only be created after all its dependencies have been successfully created (e.g. a service account for a framework). An update dependency extends the `create` dependency and is currently only honored by the `marathon` module. If during an apply-operation a dependency of a marathon app is changed (e.g. a secret) and the app has no changes it will be restarted.\n\n### Marathon app\n`type: app` defines a marathon app. It has the following specific options:\n* `path`: id of the app. If not specified the `id` field of the marathon app definition is used. Variables can be used.\n* `marathon`: path to the marathon app definition json file. Required. Variables can be used in the path and in the json file itsself.\n* `extra_vars`: key/value-pairs of of extra variables and values to be used when rendering the app definition file.\n\nIf you want to start several apps from the same basic app definition, there is a meta option to allow this:\n```\nmymultiapp:\n type: app\n _template: marathon.json\n _vars: mymultiapp.yml\n```\n\nThe `marathon.json` file is your normal app definition json file, paramerised with mustache variables. The `mymultiapp.yml` file has the following structure:\n```\ndefaults: # optional, key/value-pairs of variables, can get overwritten in the instances section\n var1: foo\n var2: bar\ninstances:\n instance1:\n var1: baz\n var3: hello\n instance2:\n var3: world\n```\nFor each key under `instances` dcos-deploy will create a marathon app from the template file specialized with the variables provided.\n\nIn both the `extra_vars` and the variables in the `instances` you can define dependent variables. The variable name must be in the form `:`, and the value must be key-value pairs of variables. If `` has value `` the variables defined under that key will be added to the variables for that entity, otherwise they will be discarded. A simple example:\n```\nvariables:\n env:\n required: True\n foo: something\nmyapp:\n type: app\n marathon: myapp.json\n extra_vars:\n env:test:\n foo: bar\n env:int:\n foo: baz\n```\nIf `env` has value `test`, the variable `foo` will have value `bar`, if `env` has value `int`, the variable `foo` will have value `baz`, in neither of these cases `foo` will have value `something`.\n\nIf not defined marathon will add a number of default fields to an app definition. dcos-deploy tries to detect these defaults and exclude them when checking for changes between the local definition and the one known to marathon. This is rather complex as these default values partly depend on several modes (network, container type, etc.). If you find a case where dcos-deploy falesly reports a change please open an issue at the github project and attach your app definition and the definition reported by marathon (via `dcos marathon app show `).\n\n### Framework\n`type: framework` defines a DC/OS framework. It has the following specific options:\n* `path`: name of the framework. If not specified the `service.name` field of the package options are used. Variables can be used.\n* `package`:\n * `name`: name of the package in the DC/OS universe. This is the same as used when installing a package via the cli (`dcos package install `). Required. Variables can be used.\n * `version`: version of the package. This is the same as used when installing a package via the cli (`dcos package install --package-version=`). Required. Variables can be used.\n * `options`: Path to the json options file to configure the package. Required. Variables can be used in the path and in the json file itsself.\n\nThese options correspond to the parameters provided when installing a package via the dcos-cli: `dcos package install --package-version= --options=`.\n\nDuring installation of a package dcos-deploy will wait until the framework is installed. If the framework exposes the standard plan API (like all frameworks based on the [Mesosphere SDK](https://github.com/mesosphere/dcos-commons/), e.g. elastic, hdfs or kafka) dcos-deploy will also wait (with a timeout of 10 minutes) until the deploy-plan is complete.\nAny change in the options file or in the package version will trigger an update (the same as doing `dcos update start --package-version= --options=`). dcos-deploy will not wait for the completion of the update as it assumes that any updates are done in a rolling-restart fashion.\n\n### Metronome job\n`type: job` defines a metronome job. It has the following specific options:\n* `path`: id of the job. If not specified the `id` field of the job definition is used. Variables can be used.\n* `definition`: path to the metronome job definition json file. Required. Variables can be used in the path and in the json file itsself.\n\n### Secret\n`type: secret` defines a secret. This can only be used on EE clusters. It has the following specific options:\n* `path`: path for the secret. Required. Variables can be used.\n* `value`: Value for the secret. Variables can be used. Either this or `file` is required.\n* `file`: Path to a file. The content of the file will be used as value for the secret. Either this or `value` is required.\n* `render`: Wether to render the file content with mustache. Use if your file contains variables. Boolean. Defaults to False.\n\n### Serviceaccount\n`type: serviceaccount` defines a serviceaccount. This can only be used on EE clusters. It has the following specific options:\n* `name`: Name of the serviceaccount. Required. Variables can be used.\n* `secret`: Path to use for the secret that contains the private key associated with the account. Required. Variables can be used.\n* `groups`: List of groups the account should be added to. Optional. Variables can be used.\n* `permissions`: Permissions to give to the account. Dictionary. Key is the name of the permission (rid), value is a list of actions to allow. If a permission does not yet exist, it will be created. Variables are not supported.\n\nThis entity equates to the steps required to create a serviceaccount for a framework as described in the [DC/OS documentation](https://docs.mesosphere.com/1.12/security/ent/service-auth/custom-service-auth/).\nAny groups or permissions not specified in the config are removed from the account during the update process.\n\nExample:\n```\ntype: serviceaccount\nname: hdfs-service-account\nsecret: hdfs/serviceaccount-secret\npermissions:\n \"dcos:mesos:master:framework:role:hdfs-role\":\n - create\n \"dcos:mesos:master:reservation:role:hdfs-role\":\n - create\n - delete\n```\n\n### X.509 certificate\n`type: cert` is a special type that uses the [DC/OS CA API](https://docs.mesosphere.com/1.11/security/ent/tls-ssl/ca-api/) to create a public-private keypair, sign it with the internal DC/OS CA and provide the key and certificate as secrets. This can only be used on EE clusters. It has the following specific options:\n* `cert_secret`: secret path to store the certificate. Required. Variables can be used.\n* `key_secret`: secret path to store the key. Required. Variables can be used.\n* `dn`: distinguished name to be used for the certificate. Requied. Variables can be used.\n* `hostnames`: List of hostnames to put in the certificate. Optional.\n\nOne example usecase for this is a service secured with TLS client certificate authentication (e.g. elasticsearch with x-pack or searchguard). You configure the service to accept client certificates signed by the cluster-internal DC/OS CA. Then using the `secret` entity provide appropriate certificates as secrets to your client services. The keys and certificates are securely kept inside the cluster and using the [path restrictions](https://docs.mesosphere.com/1.11/security/ent/#spaces-for-secrets) for secrets can only be accessed by authorized services.\n\n### Package repository\n`type: repository` defines a package repository. It has the following specific options:\n* `name`: name of the repository. Required. Variables can be used.\n* `uri`: uri for the repositroy. Required. Variables can be used.\n* `index`: at what index to place the repository in the repository list. 0 for beginning. Do not set for end of list.\n\nWith this type you can add additional package repositories to DC/OS. You can for example use it to add the Edge-LB repositories to your EE cluster. Set the repository as a dependency for any frameworks/packages installed from it.\n\n### Edge-LB pool\n`type: edgelb` defines an edgelb pool. This can only be used on EE clusters. It has the following specific options:\n* `name`: name of the pool. Taken from pool config if not present. Variables can be used.\n* `pool`: filename to the yaml file for configuring the pool. Required. The filename itsself and the yaml file can contain variables.\n\nFor configuring a pool see the [Edge-LB configuration](https://docs.mesosphere.com/services/edge-lb/1.2/pool-configuration/).\n\nFor this to work you must have the edgelb package installed via the repository URLs provided by Mesosphere (use the `repository` and `package` types, there is a [complete example](examples/edgelb) available).\nAt the moment dcos-deploy can not safely detect if the pool config was changed so it will always apply it. Be aware that changing certain options in the pool config (like ports or secrets) will result in a restart of the haproxy instances. Make sure you have a HA setup so that there is no downtime.\n\n### S3 File\n`type: s3file` defines a file to be uploaded to S3-compatible storage. If you are not running on AWS you can use [Minio](https://minio.io/) or any other storage service with an s3-compatible interface. This entitiy is designed to provide files for apps / services (via the fetch mechanism) that are either too big or otherwise not suited for storage as secrets (for example plugins for a service). It has the following specific options:\n* `server`:\n * `endpoint`: endpoint of your s3-compatible storage. If you use AWS S3 set this to your region endpoint (e.g. `s3.eu-central-1.amazonaws.com`). Required. Variables can be used.\n * `access_key`: your access key. Required. Variables can be used. For security reasons you should provide the value via environment variable. Make sure the iam user associated with these credentials has all rights for retrieving and uploading objects (`s3:Get*` and `s3:Put*`).\n * `secret_key`: your secret access key. Required. Variables can be used. For security reasons you should provide the value via environment variable.\n* `source`: path to your file or folder to be uploaded to s3. Should be relative to the `dcos.yml` file. Required. Variables can be used.\n* `destination`:\n * `bucket`: name of the bucket to use. Required. Variables can be used.\n * `key`: key to store the file(s) under. Required. Variables can be used.\n* `compress`: type of compressed archive to combine the files in. Currently only supported is `zip`. Optional. Variables can be used.\n\nThis entity has several modes of operation:\n\n* Upload a single file: `source` points to a file, `compress` is not set. The file is uploaded and `destination.key` is used as name.\n* Upload a folder: `source` points to a folder, `compress` is not set. All files and folders under `source` are recursively uploaded. `destination.key` is used as prefix.\n* Upload a folder as a zip file: `source` points to a folder, `compress: zip`. The files and folders under `source` are compressed into a zip file and uploaded. `destiation.key` is used as name of the zip file.\n\nChanges to the uploaded files are detected by comparing md5 hashsums, which are stored as metadata with the object in S3. Only changed files will be uploaded. If you try to manage files that were already uploaded some other way, on the first run they will be detected as changed (due to the missing hash value metadata) and reuploaded. For comparing hashsums for files to be uploaded in compressed form the tool will temporarily create the zip file to calculate the hashsum.\n\nFor multi-file upload: If `source` does not end in a slash, the last part of the name will be used as base folder: For `source: files/foo` and `destination.key: bar`, all files will under foo be uploaded as `bar/foo/`. In contrast if `source: files/foo/`, all files will be uploaded as `bar/`.\n\nTo use your S3 bucket to serve files to apps and services you must configure it for anonymous read access. For security reasons you should restrict that access to the IP range of your cluster. See the [AWS S3 documentation](https://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html) for details.\nCreating and configuring the bucket is outside the scope of this tool.\n\nTo make sure a marathon app that uses s3 files is made aware of changes to the uploaded files, you should set the `s3file` entity as an `update` dependency to the `app` entity. dcos-deploy will restart the app whenever the uploaded file changes.\n\nIf you run `apply` with `--debug` dcosdeploy will download already existing files from s3 and print the differences between the local and remote version in the unified diff format. So only use `--debug` for textual files.\n\n### Task exec\n`type: taskexec` allows to execute commands inside tasks. This is primarily meant to trigger configuration reloads on services that can do some sort of hot-reload as to avoid restarting a service. It has the following specific options:\n* `task`: task identifier to uniquely identify the task. Can be part of a task name. Required. Variables can be used.\n* `command`: command to execute in the task. Required. Variables can be used.\n* `print`: boolean. Wether to print the output of the executed command. Optional. Defaults to false.\n\nThis has the same effect as running `dcos task exec `.\n\nAs dcos-deploy has no state it cannnot detect if this command has been run before. As such it will run this command every time `apply` is called. You must either make the command idempotent so that running it multiple times is possible without changing the result, or (recommended) add dependencies (with `:update`) to it and add `when: dependencies-changed`. That way the command will only be executed when one of its dependencies has been changed.\n\nExample for this is: Uploading configuration files to S3 and triggering a redownload of the files into the service by a command. See [examples](examples/demo) for details.\n\n\n## Deployment process\nWhen running the `apply` command dcos-deploy will first check all entities if they have changed. To do this it will first render all options and files using the provided variables, retrieve the currently running configurations from the DC/OS cluster using the specific APIs (e.g. get the app definition from marathon) and compare them. It will print a list of changes and ask for confirmation (unless `--yes` is used). If an entity needs to be created it will first recursively create any dependencies.\nThere is no guaranteed order of execution. Only that any defined dependencies will be created before the entity itsself is created.\n\nThe deployment process has some specific restrictions:\n* Names/paths/ids may not be changed.\n* Options files for frameworks, apps and jobs are not verified for structural correctness. If the new file is not accepted by the API an error will be thrown.\n* For frameworks dcos-deploy does not verify beforehand if a version update is supported by the framework. If the framework does not accept the new version an error will be thrown.\n* An already created `cert` entity will not be changed if the `dn` or `hostnames` fields change.\n* Dependencies must be explicitly defined in the `dcos.yml`. Implicit dependencies (like a secret referenced in a marathon app) that are not explicitly stated are not honored by dcos-deploy.\n\n### Deleting entities\n\ndcos-deploy has support for deleting entities. You can use it to delete one or all entities defined (for example to clean up after tests). Do so use the command `dcos-deploy delete`. It will delete all entities defined in your configuration, honoring the dependencies (e.g. deleting a service before deleting the secret associated with it). If you only want to delete a specific entity use `--only `. All entities that have this entity as a dependency will also be deleted (e.g. if you delete a secret a marathon app depending on it will also be deleted). Check the dry-run output to make sure you don't unintentionally delete the wrong entity. The command is idempotent, so deleting an already deleted entity has no effect.\nThe delete command will not modify your configuration files. So to make sure that the deleted entity will not be recreated during the next `apply`-run, remove the entity definition from your yaml files. \n\n\n## Roadmap\n\n* Support for creating and configuring kubernetes clusters\n* Add as package to the Mesosphere universe for easy installation as a module for the dcos-cli\n* Better and documented plugin support\n* Provide some sort of verification for configurations\n\n\n## Contributing\nIf you found a bug or have a feature request, please open an issue in Github.", "description_content_type": "text/markdown", "docs_url": null, "download_url": "", "downloads": { "last_day": -1, "last_month": -1, "last_week": -1 }, "home_page": "https://github.com/MaibornWolff/dcos-deploy/", "keywords": "dcos marathon mesos", "license": "Apache 2.0", "maintainer": "", "maintainer_email": "", "name": "dcos-deploy", "package_url": "https://pypi.org/project/dcos-deploy/", "platform": "", "project_url": "https://pypi.org/project/dcos-deploy/", "project_urls": { "Homepage": "https://github.com/MaibornWolff/dcos-deploy/" }, "release_url": "https://pypi.org/project/dcos-deploy/0.2.0/", "requires_dist": null, "requires_python": ">=3.5", "summary": "Deploy and orchestrate DC/OS services and apps", "version": "0.2.0" }, "last_serial": 5342737, "releases": { "0.1.0": [ { "comment_text": "", "digests": { "md5": "21a7fd9726e96867ce48fdd2a0feabe0", "sha256": "6fa0338c3cad5d3b4224711a89f4e970882c2b6cd617f59c42a937315b351ff8" }, "downloads": -1, "filename": "dcos-deploy-0.1.0.tar.gz", "has_sig": false, "md5_digest": "21a7fd9726e96867ce48fdd2a0feabe0", "packagetype": "sdist", "python_version": "source", "requires_python": ">=3.5", "size": 36628, "upload_time": "2018-12-19T12:06:03", "url": "https://files.pythonhosted.org/packages/57/75/0617867c639a27fe6e53a44cb3d53f551f3a3cd27cfdd46e9a04639bd0bb/dcos-deploy-0.1.0.tar.gz" } ], "0.2.0": [ { "comment_text": "", "digests": { "md5": "40a1f278024c99b712de3ec4f3ff7cdb", "sha256": "e948c8d719421a6a1bf2cbe79b18263674074a66e4fcaea21a103f80b899ff3b" }, "downloads": -1, "filename": "dcos-deploy-0.2.0.tar.gz", "has_sig": false, "md5_digest": "40a1f278024c99b712de3ec4f3ff7cdb", "packagetype": "sdist", "python_version": "source", "requires_python": ">=3.5", "size": 53528, "upload_time": "2019-05-31T13:11:06", "url": "https://files.pythonhosted.org/packages/f0/28/0f46f5c74ebbe23fa8e6f635f280f4848c948f2f2a43851533356bdc644f/dcos-deploy-0.2.0.tar.gz" } ] }, "urls": [ { "comment_text": "", "digests": { "md5": "40a1f278024c99b712de3ec4f3ff7cdb", "sha256": "e948c8d719421a6a1bf2cbe79b18263674074a66e4fcaea21a103f80b899ff3b" }, "downloads": -1, "filename": "dcos-deploy-0.2.0.tar.gz", "has_sig": false, "md5_digest": "40a1f278024c99b712de3ec4f3ff7cdb", "packagetype": "sdist", "python_version": "source", "requires_python": ">=3.5", "size": 53528, "upload_time": "2019-05-31T13:11:06", "url": "https://files.pythonhosted.org/packages/f0/28/0f46f5c74ebbe23fa8e6f635f280f4848c948f2f2a43851533356bdc644f/dcos-deploy-0.2.0.tar.gz" } ] }