Bootstrap deployment options through AMP CLI

appcelerator-archive / amp

** THIS PROJECT IS STOPPED ** An open source CaaS for Docker, batteries included.

http://appcelerator.io

Apache License 2.0

81 stars 28 forks source link

Bootstrap deployment options through AMP CLI #839

Closed ndegory closed 7 years ago

ndegory commented 7 years ago

The AMP CLI uses InfraKit for cluster deployment (amp start and stop commands). A few more options should be available for controlling the cluster:

start command
- initial size of the cluster (-n option of the bootstrap script, default is 5)
- deployment target (-t option of the bootstrap script, default is local)
new update command
- should be able to scale the cluster (-n option above)
new status command
- should also be implemented in the bootstrap script to provide a list of the groups and a list of the instances

subfuzion commented 7 years ago

I propose something along the following lines:

$ amp cluster create [--managers count] [--workers count] [--driver "local"] [--driver-opt opt ...]
$ amp cluster destroy CLUSTER
$ amp cluster update --workers --managers CLUSTER
$ amp cluster status CLUSTER

ndegory commented 7 years ago

please add a label option: $ amp cluster create --name=NAME this will be used to label the Docker engines. The bootstrap script is called with the -l option: bootstrap -l NAME

neha-viswanathan commented 7 years ago

in the amp cluster create command, what are --driver-opt?

ndegory commented 7 years ago

To be defined, when an option is needed for a driver. Not implemented for now.

neha-viswanathan commented 7 years ago

What about the amp cluster status command?

ndegory commented 7 years ago

For now amp cluster create should bootstrap with what is provided by the bootstrap script and templates. This means:

local deployment: exec the bootstrap script with the proper arguments
aws deployment: prepare a terraform.tfvars file and run the terraform container to apply the configuration (see in #853 for the full description). This may be difficult because the container should run on the host and map data that are inside the cli container (the bootstrap folder). We don't want to rely on a checked out repo on the host.

Regarding the status, it's similar to the above, it should call the appropriate tool (bootstrap script for local deployment, terraform container for remote deployment).

neha-viswanathan commented 7 years ago

@ndegory Is this issue still current?