Commands
login
Log in to your Mobingi account.
Flags
--client-id, -iYour Mobingi client id.
--client-secret, -sYour Mobingi client secret.
--grant-type, -gGrant type. Default value is "password".
--username, -uUsername. You can use your main (master) account to login as root. Or you can use any subuser name.
--password, -pPassword
--endpointsSetup endpoints after login. If you have a Mobingi dev or qa account(s), you can set this to dev or qa.
This is the first command you need to run to use the other commands. To login, run
# Login as root
$ mobingi login --client-id=foo --client-secret=bar \
[email protected] --password=1234
[mobingi]: info: Login successful.
# Login as subuser
$ mobingi login --client-id=foo --client-secret=bar \
--username=subuser01 --password=pass
[mobingi]: info: Login successful.
# If you don't want to show your password, remove the --password flag
$ mobingi login --client-id=foo --client-secret=bar --username=subuser01
Password: xxxx
[mobingi]: info: Login successful.If login is successful, cli will create a file config.yml under $HOME/.mobingi/ folder that will contain the configuration values set during login. Cli will also attempt to store your credentials in the platform's native store (i.e. Keychain for OSX), if available. If not successful, the retrieved token during login will be saved in the config.yml file. This token has an expiration so you will probably need to relogin at some point when this happens.
For Windows and OSX, cli can use the native credential store directly; wincred for Windows, Keychain for OSX. For Linux, cli uses pass as storage. The following is an example of how to setup pass in Ubuntu systems.
By default, all endpoints are set to Mobingi production during login. You can use the --endpoints flag to target alternative endpoints. For example, if you have a Mobingi dev account, you can use the following login command:
stack list
List your stacks.
Example:
stack describe
Describe a stack.
Flags
--id- The stack id to describe.
Example:
stack create
Create a stack.
Flags
--alm-templatePath to your ALM template. This is required in v3.
--vendorStack vendor. For now, only AWS is supported.
--credYour vendor credential ID. If not set, cli will try to get your list of credentials and use the first one in the list, if not empty.
--regionRegion code. By default, this is set to ap-northeast-1 (Tokyo).
--nicknameYour stack's nickname.
--archStack type. Valid values are: "art_single", "art_elb". By default, this is set to "art_elb".
--typeInstance type. By default, this is set to m3.medium.
--imageDocker registry path to deploy. If you are using hub.docker.com, you can omit the domain part (ex. grayltc/lamp). Otherwise, specify the full path (ex. registry.mobingi.com/wayland/lamp). By default, this is set to mobingi/ubuntu-apache2-php7:7.1.
--dhub-userYour Docker hub username if repository is private.
--dbuh-passYour Docker hub password if repository is private.
--minMinimum number of instances in your autoscaling group when --arch is set to art_elb. By default, this is set to 2.
--maxMaximum number of instances in your autoscaling group when --arch is set to art_elb. By default, this is set to 10.
--spot-rangePercentage of spot instance to deploy to autoscaling group. For example, if you have a total of 20 instances running and your spot range is 50 (50%), then there will be a fleet of 10 spot instances and 10 on-demand instances. By default, this is set to 50.
--codeYour git repository url. This can be updated anytime. By default, this is set to github.com/mobingilabs/default-site-php.
--code-refRepository branch. By default, this is set to master.
--code-privkeyPrivate key if git repository is private.
--usedbSet to true if you want to deploy a database.
--dbengineYour database engine. Valid values are: "db_mysql", "db_postgresql". Requires --usedb flag.
--dbtypeDatabase instance/class type. Requires --usedb flag.
--dbstorageDatabase storage in GB. Set between 5 to 6144. Requires --usedb flag.
--dbread-replica1Read replica 1. Requires --usedb flag.
--dbread-replica2Read replica 2. Requires --usedb flag.
--dbread-replica3Read replica 3. Requires --usedb flag.
--dbread-replica4Read replica 4. Requires --usedb flag.
--dbread-replica5Read replica 5. Requires --usedb flag.
--use-elasticacheSet to true if you want to use elasticache.
--elasticache-engineEither Redis or Memcached. Requires --use-elasticache flag.
--elasticache-nodetypeElasticache node size. For example, cache.r3.large. Requires --use-elasticache flag.
--elasticache-nodecountIf Redis, range is 1 to 6. If Memcached, range is 1 to 20. Requires --use-elasticache flag.
API v3
Starting in v3, we create stacks using ALM Templates. Below is an example of a very simple template that creates a single EC2 instance:
Example:
API v2
Examples:
stack update
Update an existing stack.
Flags
--alm-templatePath to your updated ALM template file. Required in v3.
--idThe stack id to update.
--typeInstance type. See stack create command for more information.
--minMinimum number of instances in your autoscaling group. See stack create command for more information.
--maxMaximum number of instances in your autoscaling group. See stack create command for more information.
--spot-rangePercentage of spot instance to deploy to autoscaling group. See stack create command for more information.
API v3
Similar to stack creation, you only need to update some parts of your ALM template to update your stack.
API v2
Examples:
stack delete
Delete a stack.
Flags
--idThe stack id to delete.
Example:
stack ssh
Try to establish an ssh connection to your instances.
Flags
--idThe stack id the instance belongs to.
--ipThe IP address of the instance you want to connect.
--flagThe configuration flag.
--userThe ssh username. By default, this is set to ec2-user. Set to root when vendor is Alibaba Cloud.
--browserTry to open the url using the user's default browser.
Examples:
stack exec
Try to execute a bash script to one or more instances.
Flags
--targetThe target instance to execute the script. The format is stack-id|ip:flag. This flag can be specified more than once.
--scriptThe script file to execute.
Examples:
stack pem
Print the stack's pem file (and save to file optionally), if available. Useful if you want to connect to your instances using other tools.
Flags
--idThe stack id to query.
--flagThe configuration flag.
Example:
template versions
List available template versions of a stack.
Flags
--idThe stack id owning the template versions to be listed.
Example:
template compare
Compare two template versions.
You can compare template versions from the same stack, versions from different stacks, or a local template file to a specific template version.
Flags
--src-sidThe stack id of the first (or source) template. This flag is required.
--src-vidThe version id of the first (or source) template. This flag is required.
--tgt-sidThe stack id of the second (or target) template. If not set, cli will assume you are comparing templates of the same stack.
--tgt-vidThe version id of the second (or target) template. This flag is required if you are not providing the --tgt-body flag.
--tgt-bodyPath of the template file you want to compare to the first (or source) template. If you set this flag, do not set the --tgt-sid and the --tgt-vid flags as they are ignored.
Example:
rbac describe
List all defined role(s) or per-user role(s). Only your root account has the permissions to run this command.
If --user is not provided, this command will list all defined roles.
Flags
--userSubuser name. Optional.
rbac sample
Print a sample role.
This is useful when creating roles and you want something to start with. You can use this command to write to a file (using the --out global flag), edit the contents and use the file for role creation.
Example:
rbac create
Define a role.
Flags
--typeCreate type. Valid values are role and user. Default is role.
--nameRole name when --type is role.
--scopePath to role file.
--allow-allWhen set to true, --scope is ignored, the resulting role will allow all actions to all resources.
Example:
rbac attach
Attach a role to a user.
Flags
--userThe subuser name to attach the role to.
--role-idThe role id to attach.
Example:
rbac delete
Delete a role.
Flags
--role-idThe role id to delete. You can get the role id from the describe command.
svrconf show
Show a stack's serverconfig (server configuration) contents. Starting from v3, server config options are replaced by ALM templates. The following commands are still valid for v2.
Flags
--idThe stack id to query.
Example:
svrconf update
Update a stack's serverconfig (server configuration).
Flags
--idThe stack id to update.
--envA comma-separated key/value pair(s) for environment variables. If you have whitespaces in the input, enclose it with double quotes. You can also set this flag to "null" to clear all environment variables.--filepathNew filepath value if you want to update your filepath.
Examples:
Note that when you provide update options simultaneously (for example, you provide --env=FOO:bar and --filepath=test at the same time), the tool will send each option as a separate request.
creds list
List vendor credentials.
Flags
--vendorThe vendor to list credentials. Valid values: aws, alicloud. Default value is aws.
Examples:
registry catalog
List images under logged in username.
This command is inherently slow.
Registry related commands will use the login user/password credentials, if native store is supported. Otherwise, you will have to provide the user/password credentials using the --username and --password flags.
Flags
--usernameUsername (Mobingi account subuser)
--passwordPassword (Mobingi account subuser)
--serviceAuthentication service. By default, this is set to "Mobingi Docker Registry".
--scopeAuthentication scope. See https://docs.docker.com/registry/spec/auth/scope/ for more information on scopes.
Examples:
registry tags
List image tags.
Flags
--usernameUsername (Mobingi account subuser)
--passwordPassword (Mobingi account subuser)
--serviceAuthentication service. By default, this is set to "Mobingi Docker Registry".
--scopeAuthentication scope. See https://docs.docker.com/registry/spec/auth/scope/ for more information on scopes.
--imageImage name to list.
Example:
registry manifest
Display a tag's manifest.
Flags
--usernameUsername (Mobingi account subuser)
--passwordPassword (Mobingi account subuser)
--serviceAuthentication service. By default, this is set to "Mobingi Docker Registry".
--scopeAuthentication scope. See https://docs.docker.com/registry/spec/auth/scope/ for more information on scopes.
--imageImage tag to query. Format is image:tag.
Example:
command: registry delete
Delete a tag.
Flags
--usernameUsername (Mobingi account subuser)
--passwordPassword (Mobingi account subuser)
--serviceAuthentication service. By default, this is set to "Mobingi Docker Registry".
--scopeAuthentication scope. See https://docs.docker.com/registry/spec/auth/scope/ for more information on scopes.
--imageImage tag to query. Format is image:tag.
Example:
registry token
Get an access token for Mobingi Docker Registry access.
Flags
--usernameUsername (Mobingi account subuser)
--passwordPassword (Mobingi account subuser)
--serviceAuthentication service. By default, this is set to "Mobingi Docker Registry".
--scopeAuthentication scope. See https://docs.docker.com/registry/spec/auth/scope/ for more information on scopes.
Example:
This is useful when you want to access the registry directly using other tools. For example, you can use the token when using Docker Registry API via curl.
reset
Reset all configuration values to default. It will also delete all credential information stored in the platform's native store.
Example:
version
Prints the cli version.
Last updated
Was this helpful?