Easy nodes provisioning through Kontena CLI about kontena HOT 7 CLOSED

Proposed solution:

Create provider plugin architecture to support multiple cloud providers. Each plugin should implement necessary functions to provision, configure and install Kontena Node(s) to selected provider. Initially, have providers for Digital Ocean, AWS and Vagrant.

If user has configured some provider, it should be possible to provision nodes to this provider (automatically joining to a selected grid) through CLI.

from kontena.

Why not reuse existing solutions like docker machine?

from kontena.

Good point, we have been checking docker machine as one possibility to provision machines. Right now kontena installation needs something more than plain server + docker provisioning. Basically we need to install deb packages that do some configuration to host machine... this is not supported by docker machine and that's why we are implementing our own lightweight tool.

from kontena.

I'm not sure that I understand why you depend on ubuntu. In comment #95 (comment), I showed how I started your existing Dockerfiles using docker-compose up. That means both the api server and the agent run in a container. Thus, from my point of view only a plain server + docker provisioning is required.
Am I missing something?

from kontena.

We don't directly depend on ubuntu but atm we provide packages only for ubuntu. Kontena includes something more than just plain containers, mainly etcd2 and weave. Etcd2 is included in CoreOS and Weave can be installed (or replaced with Flannel) but then agents will miss automatic node discovery and other cool stuff that's baked into ubuntu packages. If you want to port those features to CoreOS systemd (cloud-config) files, here is the ubuntu package magic:
https://github.com/kontena/kontena/tree/master/agent/packaging/ubuntu
https://github.com/kontena/kontena/tree/master/server/packaging/ubuntu

from kontena.

We have now provisioners for vagrant and digitalocean. Both are using coreos-stable. Should we close this?

from kontena.

yes. i think this issue can be closed. the current design fulfills the original idea. if we want more provisioning engines, we'll create issue for each one of them in the future.

from kontena.