Cloud 66 Toolbelt Commands
These commands are listed alphabetically by top level command name.
backups list
Lists all the managed backups of an application grouped by their database type and/or backup schedule.
$ cx backups list --stack <application name> --latest
Arguments | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | The name of the application |
--dbtypes <type> | no | — | Database type to be listed. (all, mysql, postgresql, mongodb, redis) |
--latest, -l | yes | — | List the latest backup |
$ cx backups list -s "My Awesome App" --dbtypes mysql --latest
backups download
Download a managed database backup via the command line. If the backup spans multiple files, the command will automatically concatenate them into a single file.
$ cx backups download --stack <application name> [--download <download directory>] <backup id>
Arguments | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | The name of the application |
--directory, -d <download directory> | no | — | The local directory in which to save the downloaded file |
<backup ID> | yes | — | The backup ID (you can get this using the backup list command) |
$ cx backups download -s mystack -d /tmp/backups 23212
Note
This command only applies to managed backups and not the unmanaged ones.
backups new
Creates a new database backup task for an application.
cx backups new --stack <application name> --dbtypes postgresql --frequency <schedule> --gzip <bool> --exclude-tables <table name> --run-on-replica <bool> --backup-type <type>
Parameter | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | Yes | — | Name of your application |
--dbtypes <type> | No | all |
Comma separated list of Database types which need backup tasks. (all , mysql , postgresql , mongodb , redis ) |
--frequency <schedule> | No | 0 */1 * * * |
Frequency of backup task in cron schedule format |
--keep <number> | No | 100 |
Number of previous backups to keep |
--gzip <bool> | No | true |
Compress your backups with gzip |
--exclude-tables <table name> | No | — | Tables that must be excluded from the backup |
--run-on-replica <bool> | No | true |
Run backup task on replica server if available |
--backup-type <type> | No | text |
Specify the type of backup to perform. Acceptable values are binary and text . |
$ cx backups new -s mystack --dbtypes postgresql --frequency="0 */1 * * *" --gzip true --exclude-tables my_log_table --run-on-replica false --backup-type text
Note
This command only applies to managed backups and not the unmanaged ones.
config
Allows you to configure multiple profiles in cx to support multiple Cloud 66 accounts. Please read our separate guide on configuring Toolbelt.
containers list
Alias: container list
Lists all the containers running on an application or server (depending on your parameters).
$ cx containers list --stack <application name> [--server <server name>][--enviornment <environment name>][--verbose]
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of your application |
--server <server name> | no | — | The server to query |
--environment <environment name> | no | — | The application environment |
--verbose | no | — | Show more detailed information about each container |
$ cx containers list -s mystack
$ cx containers list -s mystack --server orca
$ cx containers list -s mystack --verbose --server orca
containers attach
Alias: container attach
Connect to a container (by container name) and print the STDOUT
output stream of the container process. This is roughly equivalent to tailing the logs of a container.
If you need to connect to a container in order to execute commands, you should use the cx run command and specify the name of the container.
$ cx containers attach --stack <application name> <container ID>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of your application |
<container ID> | yes | — | The ID of the container to be attached |
$ cx containers attach -s mp-app 2844142c
containers stop
Alias: container stop
Stops a specific container on a given stack by container ID or name (supports partial IDs and names).
$ cx containers stop --stack <application name> <container ID>|<container name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of your application |
<container ID> | either\or | — | The ID of the container to stop |
<container name> | either\or | — | The name of the container to stop |
$ cx containers stop -s mystack 2844142cbfc064123777b6be765b3914e43a9e083
$ cx containers stop -s mystack 2844142c
$ cx containers stop -s mystack web.pro-active-quick-witted-dinosaur
$ cx containers stop -s mystack web
containers restart
Alias: container restart
Restarts a particular container on a given stack by container ID or name (supports partial IDs and names).
$ cx containers restart --stack <application name> <container ID>|<container name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of your application |
<container ID> | either\or | — | The ID of the container to restart |
<container name> | either\or | — | The name of the container to restart |
$ cx containers restart -s mystack 2844142cbfc064123777b6be765b3914e43a9e083afce4e4348b5979127c220c
$ cx containers restart -s mystack 2844142c
$ cx containers restart -s mystack web.pro-active-quick-witted-dinosaur
$ cx containers restart -s mystack web
databases promote-replica
Alias: database promote-replica
Alias: database promote-slave
(deprecated)
Alias: databases promote-slave
(deprecated)
Promotes the specified replica database server to a standalone master. The replica will be reconfigured as the new standalone DB. Providing the database type is optional and is only necessary for shared servers where we can’t automatically determine the target database type.
⚠️ This action could result in application downtime, it is advisable to choose a low traffic time to perform this action, and to place your application in maintenance mode.
The existing master and other replicas will need to be removed after this process as after this the new configuration will have only a single database. You will be able to configure replication again by scaling up new servers.
In the case of any servers not being accessible during this time, those servers will remain unchanged. It is therefore important to stop/shut down those servers in this case (or to manually stop the DB service on those servers) as having multiple masters in a cluster could cause problems throughout the cluster.
$ cx databases promote-replica --stack <stack name> [--dbtype <database type>] <replica server name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <stack name> | yes | — | Name of your application |
--dbtype <database type> | no | — | The database type (mysql ,postgresql ,redis ) |
<replica server name> | yes | — | Name of replica server to promote to master |
$ cx databases promote-replica -s My_Awesome_App my_redis_replication_replica
$ cx databases promote-replica --stack My_Awesome_App --dbtype=mysql my_replica_server_name
databases resync-replica
Alias: database resync-replica
Alias: database resync-slave
(deprecated)
Alias: databases resync-slave
(deprecated)
Re-syncs the specified replica database server with its master database server. From time-to-time your replica database may go out of sync with its master. This action attempts to re-sync your specified replica server. This can happen depending on many factors (such as DB size, frequency of change, networking between servers etc).
The server provided must have already been configured as a replication replica via the Cloud 66 UI. Providing the database type is optional and is only necessary for shared servers where we can’t automatically determine the target database type.
$ cx databases resync-replica --stack <application name> --dbtype <database type> <replica server name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of your application |
<replica server name> | yes | — | Name of replica server to be resynced with master |
--dbtype <database type> | no | — | The database type (mysql ,postgresql ) |
$ cx databases resync-replica -s My_Awesome_App my_replica_server_name
$ cx databases resync-replicas -s My_Awesome_App --dbtype=postgresql my_replica_server_name
download
Use this command to download a copy of file from the remote server to your local computer. If you don’t specify a target directory, the file will be downloaded to your current local directory.
$ cx download --stack <application name> --server <server name> <path to source file> [<target directory>]
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of your application |
--server <server name> | yes | — | Name of the server which contains the file |
<path to source file> | yes | — | The path to the file on the server |
<target directory> | no | — | The path to the local directory in which the file will be saved |
$ cx download -s "My Awesome App" --server web /tmp/file.txt /tmp/file.txt
dump-token
Prints the content of the cx token file with no new lines.
Usage
$ cx dump-token
env-vars list
Prints environment variables (both keys and values) for your application to terminal. If environment variable keys are specified, the list will be limited to those keys. The --history
option lists any recent changes to each variable.
$ cx env-vars list --stack <application name> <environment variables> [--history]
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of your application |
<environment variables> | yes | — | A space separated list of environment variable keys |
--history | no | — | Displays a list of recent changes to each variable |
$ cx env-vars list -s mystack
$ cx env-vars list -s mystack RAILS_ENV
$ cx env-vars list -s mystack RAILS_ENV ANOTHER_VARIABLE --history
env-vars download
Downloads the environment variables from an application and writes them to a file. This file can either use the same format as web download (dotenv
) or json
.
You can specify which kinds of variables to download using environment-type
with the following variables:
all
returns all environment variablesuser
returns user-created environment variablesgenerated
returns environment variables generated by Cloud 66locked
returns non-editable environment variables that were generated by Cloud 66
$ cx env-vars download --stack <application name> --environment-type <type> --file <filename> --file-type <file-type>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Full or partial name of the application |
--file-type <file-type> | yes | — | Sets the format of the file containing the list of environment variables (dotenv or json) |
--file <filename> | yes | — | The filename of the file being created (or overwritten) by the download |
--environment-type <type> | no | — | Specify the type of variables. Accepts multiple options. (all, user, generated, locked) |
$ cx env-vars download -s mystack --file environment_variables_json --file-type json
$ cx env-vars download -s another_app --file environment_variables_dotenv --file-type dotenv
env-vars set
Adds (or updates) a single environment variables for your application. You can use the --apply-strategy
option to specify when Cloud 66 will apply the change in environment variables to your servers. The default is immediately
.
$ cx env-vars set --stack <application name> [--apply-strategy] <key> <value>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of your application |
<key> | yes | — | The KEY for the env-var that will be added or updated |
<value> | yes | — | The value assigned to the KEY |
--apply strategy | no | immediately | When the changes will be applied. Options are immediately, deployment |
$ cx env-vars set -s mystack FIRST_VAR=123
$ cx env-vars set -s mystack SECOND_VAR='this value has spaces in it'
$ cx env-vars set -s mystack --apply-strategy immediately THIRD_VAR='value-applied-now'
$ cx env-vars set -s mystack --apply-strategy deployment FOURTH_VAR='value-after-deployment'
env-vars upload
Set the environment variables for an application based on a file in either dotenv
or json
format.
You must specify an apply-strategy
for your upload process. They can either be applied immediately
or on the next deployment
.
$ cx env-vars upload --stack <application name> --file <filename> --file-type <type> [--apply-strategy <strategy>] [--delete]
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Full or partial name of the application |
--file-type <type> | yes | — | The format of the source file containing the list of environment variables (dotenv or json) |
--file <filename> | yes | — | The filename of the file being uploaded |
--apply-strategy <strategy> | no | — | Sets when uploaded changes will be applied (immediately, deployment) |
--delete | no | — | Delete any user-generated variables that don’t appear in file |
$ cx env-vars upload -s mystack --file environment_variables_dotenv --file-type dotenv --apply-strategy deployment --delete
$ cx env-vars upload -s my_other_stack --file environment_variables_json --file-type json --apply-strategy immediately
failover-groups list
Lists the Failover Groups for a Cloud 66 account. Info includes the Failover Group ID, address, attached applications and current active application.
$ cx failover-groups list [--output <view>]
Arguments | Required? | Default | Description |
---|---|---|---|
–output, -o <view> | no | standard | Tailor the output view (standard or wide) |
$ cx failover-groups list -o wide
failover-groups add
Adds a new Failover Group to a Cloud 66 account. You can create an empty Failover Group with neither primary nor secondary app set.
$ cx failover-group add [--primary <primary app>] [--secondary <secondary app>] [--current <current app>] [--no-primary] [--no-secondary]
Argument | Required? | Default | Description |
---|---|---|---|
–primary, -p <primary app> | no | — | The name of the application which should be set as “primary” in the Failover Group |
–secondary, -s <secondary app> | no | — | The name of the application which should be set as “secondary” in the Failover Group |
–current <current app> | no | – | Sets the Failover Group to point at either the primary app - or the secondary app |
–no-primary | no | — | Create a Failover Group with no primary application |
–no-secondary | no | — | Create a Failover Group with no secondary application |
$ cx failover-group add -p my-main-app -s my-backup-app
failover-groups delete
Deletes an existing Failover Group from a Cloud 66 account.
$ cx failover-groups delete --uid <failover UID>
Arguments | Required? | Default | Description |
---|---|---|---|
–uid <failover UID> | yes | — | The UID of the Failover Group to be deleted. |
$ cx failover-groups delete --uid "5999b763474b0eafa5fafb64bff0ba80"
failover-groups update
Updates an existing Failover Group on a Cloud 66 account.
$ cx failover-group update --uid <failover UID> [--primary <primary app>] [--secondary <secondary app>] [--current <app pointer>] [--no-primary] [--no-secondary]
Argument | Required? | Default | Description |
---|---|---|---|
–uid |
yes | — | The UID of the Failover Group to be updated. |
–primary, -p <primary app> | either/or | — | The name of the application which should be set as “primary” in the Failover Group. (The current value will not be updated if this is not specified) |
–secondary, -s <secondary app> | either/or | — | The name of the application which should be set as “secondary” in the Failover Group. (The current value will not be updated if this is not specified) |
–current <current app> | no | — | Sets the Failover Group to point at either the primary app - or the secondary app |
–no-primary | no | — | Remove the current primary application from the Failover Group |
–no-secondary | no | — | Remove the current secondary application from the Failover Group |
$ cx failover-group update --uid "5999b763474b0eafa5fafb64bff0ba80" -p my-main-app -s my-backup-app --current 2
formations list
Alias: formation list
List all the formations of a stack in a Skycap application by name and UID.
$ cx formations list --stack <application name> <formation names>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Full or partial name of the application |
<formation names> | no | — | Space separated list of the formations to display |
$ cx formations list -s mystack foo bar # only show formations "foo" and "bar"
formations commit
Alias: formation commit
Commits the specified stencil(s) to the application’s template repository with a commit message.
$ cx formations commit --stack <application name> -f <formation name> --stencil <stencil name> | --dir <directory path> --message <your commit message> [--default-folders]
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Full or partial name of the application |
-f <formation name> | yes | — | The name of the formation to which the stencils belong. |
--stencil <stencil name> | either/or | — | A single stencil file to commit. Cannot be used alongside –dir |
--dir <directory path> | either/or | — | Directory holding the formation stencils. Cannot be used alongside –stencil |
--message <your commit message> | yes | — | The commit message |
--default-folders | no | — | Use ~/cloud66/formations with a formation name suffix as the dir |
$ cx formations commit -s my-skycap-app -f main-formation --stencil app-template-1 --message "updates to structure"
$ cx formations commit -s my-skycap-app --formation main-formation --dir stencils_for_editing --message "edited variables"
formations create
Alias: formation create
Creates a new Formation in the specified Skycap application.
$ cx formations create --stack <application name>] --name <formation name> --template-repo <template repo URL> --template-branch <branch name> [--tags <tagA> <tagB>]
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Full or partial name of the application |
--name <formation name> | yes | — | The name of the new formation |
--template-repo <template repo URL> | yes | — | The URL of the template repository to be used by the new formation |
--template-branch <branch name> | yes | — | The branch of the template repository to be used |
--tags <tagA> <tagB> | no | — | Tags to attach to the new formation |
$ formations create -s my-skycap-app --name new-formation --template-repo "https://my.repo.url/skycap-stencils" --template-branch "main" --tags ver2
formations deploy
Alias: formation deploy
Deploys a Formation in a Skycap application.
$ cx formations deploy --stack <application name> -f <formation name> [--snapshot-uid <UID>] [--use-latest <boolean>] [-w <workflow name>]
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Full or partial name of the application |
-f <formation name> | yes | — | The name of the formation to which the Stencils belong. |
--snapshot-uid <UID> | no | — | UID of the snapshot to be used (Use latest for the most recent snapshot) |
--use-latest | no | true | Use the snapshot’s HEAD gitref (and not the ref stored in the formation) |
-w <workflow name> | no | — | The name of the workflow to use for the formation deployment |
$ formations deploy -s my-skycap-app -f main-formation --use-latest true -w quick-workflow
formations fetch
Alias: formation fetch
Fetches all stencils from a Formation in a Skycap application and downloads them to a local directory.
$ cx formations fetch --stack <application name> -f <formation name> [--outdir <directory path>] [--overwrite <bool>]
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Full or partial name of the application |
-f <formation name> | yes | — | The name of the formation to which the Stencils belong. |
--outdir <directory path> | no | ~/cloud66/formations (suffixed by the formation name) | Path of the output directory for the Formation. Will be created if missing. |
--overwrite <bool> | no | false | Overwrite existing files in outdir if present. |
$ formations fetch -s my-skycap-app -f main-formation --outdir "~/my-formations" --overwrite true
formations stencils list
Alias: formation stencils list
List all the stencils in a formation.
$ cx formations stencils list --formation <formation name> --output <view>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Full or partial name of the application |
--formation <formation name> | yes | — | The name of the Formation to which the Stencils belong. |
--output <view> | no | standard | Tailor the output view (standard or wide) |
$ cx formations stencils list --formation foo
$ cx formations stencils list --formation bar --output wide
gateways list
Lists all the gateway servers attached to a Cloud 66 account or organization.
$ cx --org <organization_name> gateways list [--verbose]
Argument | Required? | Default | Description |
---|---|---|---|
--org <organization_name> | no | — | The name of an organization in your Cloud 66 account |
--verbose | no | — | Display more detail about the gateways |
$ cx --org my-compay gateways list --verbose
gateways add
Add a gateway server to a Cloud 66 account.
$ cx gateways add --name <gateway name> --address <gateway address> --username <gateway username> --private-ip <private ip of gateway>
Argument | Required? | Default | Description |
---|---|---|---|
--name <gateway name> | yes | — | The name of the gateway |
--address <gateway address> | yes | — | The IP address of the gateway |
--username <gateway username> | yes | — | The username for accessing the gateway |
--private-ip <private ip of gateway> | yes | — | The private IP address to use to access the network behind the gateway |
$ cx gateways add --name aws_bastion --address 192.168.100.100 --username ec2-user --private-ip 192.168.1.1
$ cx --org My_Awesome_org gateways add --name aws_bastion --address 1.1.1.1 --username ec2-user --private-ip 192.168.2.2
gateways close
Close a gateway (prevents traffic flowing via the gateway).
$ cx gateways close --name <gateway name>
Argument | Required? | Default | Description |
---|---|---|---|
--name <gateway name> | yes | — | The name of the gateway |
$ cx gateways close --name aws_bastion
gateways open
Opens a gateway for use with Cloud 66 for a specified amount of time (TTL).
$ cx gateways open --name <gateway name> --key <path/to/gateway/key/file> --ttl <time to live>
Argument | Required? | Default | Description |
---|---|---|---|
--name <gateway name> | yes | — | The name of the gateway |
--key <path/to/gateway/key/file> | yes | — | The path to the gateway key file on your local machine |
--ttl <time to live> | yes | — | The length of time the gateway will remain open. For example 1h, 30m, 30s |
$ cx gateways open aws_bastion --key /tmp/gateway.pem --ttl 45m
gateways remove
Remove a gateway from a Cloud 66 account.
$ cx gateways remove --name <gateway name>
Argument | Required? | Default | Description |
---|---|---|---|
--name <gateway name> | yes | — | The name of the gateway |
$ cx gateways remove --name aws_bastion
help
Shows a full list of commands or detailed help for one command.
Usage
$ cx help
$ cx <command> --help
info
Shows information about your account, toolbelt and the specified stack or the current directory.
$ cx info --stack <application name --unmanaged
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | no | — | Full or partial name of the application |
--unmanaged | no | — | Lists the servers under your cloud account that are NOT in any of your applications. |
$ cx info -s my-application --unmanaged
init
Initializes the Toolbelt. Please read our separate guide on installing and configuring Toolbelt.
init agent
Initializes the Toolbelt as a standalone (headless) agent. Please read our separate guide on installing and configuring Toolbelt.
jobs list
Alias: job list
Lists all automated (scheduled) jobs on an application or a server.
$ cx jobs list --stack <application name> --server <server name>|<server ip>|<server role> --service <service name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Full or partial name of the application |
--server <server name>|<server ip>|<server role> | no | — | The name, IP address or role of the server. |
--service <service name> | no | — | The name of the service |
$ cx jobs list -s my-app
$ cx jobs list -s my-app --server orca
$ cx jobs list -s my-app --server 168.123.448.56 --service web
$ cx jobs list -s my-app --service web
jobs run
Alias: job run
Runs the given job once with the given parameters.
$ cx jobs run --stack <application name> --arg [--arg option --arg option] <job name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Full or partial name of the application |
<job name> | yes | — | The name of the job |
--arg [–arg option –arg option] | no | — | Parameters to be passed to the job |
$ cx job run -s "My Awesome App" my_job
$ cx job run -s "My Awesome App" --arg "arg1" --arg "arg2" my_job
lease
This will open the firewall of the given server for a limited time. ‘Time to open’ is in minutes. By default the firewall closes after 20 minutes. The maximum time to open is 240 minutes.
$ cx lease --stack <application name> --port <port to open> [--from <from IP>] --tto <lease time>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Full or partial name of the application |
--from, -f <from IP> | no | automatically uses your current IP | IP address for the source of traffic. Uses your current IP if not provided. |
--port, -p <port to open> | yes | 22 | The port to open on the server |
--tto, -t <lease time> | yes | 20 | The number of minutes the lease will last (the maximum is 240) |
$ cx lease -s mystack
$ cx lease -s mystack -t 120 -p 3306
$ cx lease -s mystack -p 3306 -f 52.65.34.98
login
Opens the default web browser and logs into the associated Cloud 66 account. This makes it easier to login to Cloud 66 web UI by streamlining your login through a registered and authenticated Toolbelt.
Usage
$ cx login
notifications download
Download all the alert settings for a given application as a YAML formatted file.
$ cx notifications download --stack <application name> --file <filename>
Arguments | Required? | Default | Description |
---|---|---|---|
-stack, -s <application name> | yes | — | The name of the application |
–file, -f <filename> | yes | — | The name of the file in which the notification settings will be saved. |
$ cx notifications download -s my-stack --file my-stack-alerts.yml
notifications upload
Uploads notifications in a YAML formatted file. Settings in the file will replace any existing settings. If an application group is specified, all of the apps in the group will be updated.
$ cx notifications upload [--stack <application name> | --application-group <group name>] --file <filename>
Arguments | Required? | Default | Description |
---|---|---|---|
-stack, -s <application name> | either/or | — | The name of the application to be updated |
–application-group, -a <group name> | either/or | — | The name of the application group to be updated |
–file, -f <filename> | yes | — | The name of the file containing the notification settings that will be uploaded |
$ cx notifications upload -a production-group -f my-notification-settings.yml
open
Opens the default web browser and opens the web end-point of a given application.
$ cx open --stack <application name> <server name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Full or partial name of the application |
<server name> | no | — | The name of the web server to query |
$ cx open lion
$ cx open -s mystack
$ cx open -s mystack lion
processes list
Alias: process list
List the details of the processes running on an application or a server.
$ cx processes list --stack <application name> [--server <server name>] [--name <process name>]
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Full or partial name of the application |
--server <server name> | no | — | The name of the server to query |
--name <process name> | no | — | The name of a process |
$ cx processes list -s mystack
$ cx processes list -s mystack --server orca
$ cx processes list -s mystack --name worker
$ cx processes list -s mystack --server orca --name worker
processes pause
Alias: process pause
Pauses all processes for the given service and/or server.
$ cx processes pause --stack <application name> [--server <server name>] [<process name>]
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Full or partial name of the application |
--server <server name> | no | — | The name of the server to query |
<process name> | no | — | The name of a specific process to be paused |
$ cx processes pause -s mystack a_backend_process
$ cx processes pause -s mystack --server my_server
$ cx processes pause -s mystack --server my_server a_backend_process
processes restart
Alias: process restart
Restarts all processes on the given service and/or server.
$ cx processes restart --stack <application name> [--server <server name>] [<process name>]
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Full or partial name of the application |
--server <server name> | no | — | The name of the server to use |
<process name> | no | — | The name of a process |
$ cx processes restart -s mystack a_backend_process
$ cx processes restart -s mystack --server my_server
$ cx processes restart -s mystack --server my_server a_backend_process
processes resume
Alias: process resume
Resumes all paused processes on the given service and/or server.
$ cx processes resume --stack <application name> [--server <server name>] <process name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Full or partial name of the application |
--server <server name> | no | — | The name of the server to query |
<process name> | no | — | The name of a process |
$ cx processes resume -s mystack a_backend_process
$ cx processes resume -s mystack --server my_server
$ cx processes resume -s mystack --server my_server a_backend_process
processes scale
Alias: process scale
Starts <count>
processes from the given process definition. <count>
can be an absolute value like 2
or a relative value like [+2]
or [-3]
If server is provided, will start <count>
processes on that server. If server is not provided, will start <count>
processes on every server. NOTE: the square brackets are required for relative count values.
$ cx processes scale --stack <application name> [--server <server name>] [--name <process name>] [<count>]
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Full or partial name of the application |
--server <server name> | no | — | The name of the server on which to scale the process |
--name <process name> | yes | — | The name of a process |
<count> | yes | — | Specifies either an absolute count of processes (3), or a relative change ([+4] or ([-2]) |
$ cx processes scale -s mystack --server backend1 --name worker [+5]
$ cx processes scale -s mystack --server backend2 --name worker [-5]
$ cx processes scale -s mystack --server backend3 --name worker 15
$ cx processes scale -s mystack --name worker 2
redeploy
Alias: stacks redeploy
Enqueues redeployment of an existing application. If the app is already building, another build will be enqueued and performed immediately after the current one is finished.
$ cx redeploy --stack <application name> --listen [-y] [--git-ref <git_ref>] [--service <service>] [--deploy-strategy <strategy>] [--rollout-strategy <strategy>] [--canary-percentage <percentage>] [--deployment-profile <profile name>]
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Full or partial name of the application |
-y | no | — | Answer yes to confirmations |
--listen | no | — | Waits for deployment to complete, shows progress and log output when available |
--git-ref <git_ref> | no | — | Redeploy the specific git reference (branch, tag or hash). |
--service <service> | no | — | Will deploy the specified services from your application. Each service can have an optional colon-separated reference which is an image tag or git reference. |
--deploy-strategy <strategy> | no | — | Set a strategy for this redeployment. Options are serial, parallel, rolling (Rails/Rack) or fast (Maestro) |
--rollout-strategy <strategy> | no | none | Set a rollout strategy for this redeployment. Options are none, blue_green_immediate, blue_green_delayed, or canary |
--canary-percentage <percentage> | no | — | Set the percentage of traffic to direct to a canary rollout |
--deployment-profile <profile name> | no | — | Use an existing profile for this redeployment. |
$ cx redeploy -s "My Awesome App" -e production --deploy-strategy fast
$ cx redeploy -s "My Awesome App" -e production -y --git-ref my_git_ref_value
$ cx redeploy -s "My Awesome Containerized App" --service web:8c7f3d393162f88b8b9493f6babec574b03ca957 --service api:latest
register-server
A shortcut to run the server registration script on a group of servers.
$ cx register-server [--org <organization>] [--server <IP address>] [--file <filename.txt>] [--user <username>] [--key <private SSH key>] [--force-local-ip <bool>] [--tags <tagA,tagB>]
Argument | Required? | Default | Description |
---|---|---|---|
--server <IP address> | either/or | — | The public IP address of the server to register |
--file <filename.txt> | either/or | — | A text file containing a list of IP addresses for servers (one per line) |
--org <organization> | yes | — | The name of the Cloud 66 organization to which the server(s) must be added |
--user <username> | yes | — | The username to use when connecting to server(s) |
--key <private SSH key> | yes | — | The private SSH key to use to connect to the server(s) |
--force-local-ip <bool> | no | false | Use the local ip address of the registered server |
--tags <tagA,tagB> | no | — | Comma separated list of tags to add to the server(s) |
$ cx register-server --org team --user root --server 149.56.134.22 --key ~/.ssh/private_key
$ cx register-server --org team --user ubuntu --file servers.txt --key ~/.ssh/private_key
$ cx register-server --org team --user ubuntu --file servers.txt --key ~/.ssh/private_key --force-local-ip true
$ cx register-server --org team --user ubuntu --file servers.txt --key ~/.ssh/private_key --tags "dc 1,az2"
run
Execute a command directly on a remote server, in a service, or in a existing container. To do this it:
- Opens the firewall for SSH from your IP address temporarily (20 minutes)
- Downloads your SSH key if you don’t have it
- Starts a SSH session
- Executes the command specified and returns its output.
You need to have the correct access permissions to use this command. You can use either the server name (e.g. lion
) or the server IP (e.g. 123.123.123.123
) or the server role (e.g. web
). If a role is specified the command will connect to the first server with that role.
This command is only supported on Linux and OS X clients (for Windows you can run this in a virtual machine if necessary)
$ cx run --stack <application name> [--server <server name> | <IP address>] [--service <service name>] [--container <container name>] [--interactive] '<commands>'
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
--server, –svr <server name> | <IP address> | either/or | — | The name or IP address of the server on which to run the command |
--service, –svc <service name> | either/or | — | (Maestro only) Name of the service in which to run the command |
--container, –cnt <container name> | either/or | — | (Maestro only) Name of the pod/container in which to run the command |
--interactive, -i | no | — | Set the session to interactive mode |
<commands> | yes | — | The linux commands to run. |
$ cx run -s mystack --server lion 'ls -la'
$ cx run -s mystack --server lion -i
$ cx run -s mystack --svc webapp 'ls -la'
$ cx run -s mystack --service api --interactive 'bundle exec rails c'
$ cx run -s mystack --container web-123 -i 'bundle exec rails c'
servers list
Alias: server list
List details for all the servers used by an application including name, IP address, server role and the date/time it was created. The <name>
argument can be a list of server names entered as separate parameters.
$ cx servers list --stack <application name> <server name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
<server name> | no | — | The name of the server(s) to query |
$ cx servers list -s mystack
orca 162.243.201.164 [rails web app] Healthy Mar 26 11:23
snowleopard 107.170.98.160 [mysql db] Building Mar 26 11:23
$ cx servers list -s mystack orca
orca 162.243.201.164 [rails web app] Healthy Mar 26 11:23
servers reboot
Alias: server reboot
Reboot a specific server.
$ cx servers reboot --stack <application name> --server <server name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
--server <server name> | yes | — | The name of the server to reboot |
$ cx server reboot --stack my-app --server lion
servers settings list
Alias: server settings list
Lists all the settings applicable to the given server. It also shows the key, value and the readonly flag for each setting. Settings can be a list of multiple
$ cx servers settings list --stack <application name> --server <server name> <setting>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
--server <server name> | yes | — | The name of the server to query |
<setting> | no | — | The specific setting(s) to fetch (supports multiples) |
$ cx servers settings list -s mystack --server lion
server.name lion readonly
disk.space.alert.threshold 80 read/write
$ cx servers settings list -s mystack --server db server.name
server.name tiger readonly
services info
Alias: service info
Get info for given the service. The list of available services can be obtained through the services list
command. If the server is provided it will only query the specified server.
$ cx services info --stack <application name> [--server <server name>] <service name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
--server <server name> | no | — | The name of a server to query |
<service name> | yes | — | The service to query |
$ cx services info -s mystack my_web_service
$ cx services info -s mystack a_backend_service
$ cx services info -s mystack --server my_server my_web_service
services list
Alias: service list
List all the services and running containers of a whole application or a specific server.
$ cx services list --stack <application name> [--server <server name>] [<service name>]
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
--server <server name> | no | — | The name of a server to query |
<service name> | no | — | The service to query |
$ cx services list -s mystack
$ cx services list -s mystack --server orca
$ cx services list -s mystack --server orca --service web
$ cx services list -s mystack --service web
services pause
Alias: service pause
Pauses all the containers for the given service. The list of available services can be obtained through the list services
command. If
$ cx services pause --stack <application name> [--server <server name>] <service name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
--server <server name> | no | — | The name of a server to query |
<service name> | yes | — | The service to pause |
$ cx services pause -s mystack my_web_service
$ cx services pause -s mystack a_backend_service
$ cx services pause -s mystack --server my_server my_web_service
services restart
Alias: service restart
Restarts all the containers for the given service. The list of available services can be obtained through the list services
command. If
$ cx services restart --stack <application name> [--server <server name>] <service name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
--server <server name> | no | — | The name of a server to query |
<service name> | yes | — | The service to restart |
$ cx services restart -s mystack my_web_service
$ cx services restart -s mystack a_backend_service
$ cx services restart -s mystack --server my_server my_web_service
services resume
Alias: service resume
Resumes all the containers from the given service that were previously paused. The list of available services can be obtained through the list services
command. If
$ cx services resume --stack <application name> [--server <server name>] <service name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
--server <server name> | no | — | The name of a server to query |
<service name> | yes | — | The service to resume |
$ cx services resume -s mystack my_web_service
$ cx services resume -s mystack a_backend_service
$ cx services resume -s mystack --server my_server my_web_service
services scale
Alias: service scale
Starts <count>
containers for the given service across the stack. If <count>
is an absolute value like 2
, then that will be the total of <count>
containers across the application. If <count>
is a relative value like [+2]
or [-3]
, then the current total count of containers across the application will be changed by <count>
. NOTE: the square brackets are required for relative count values.
$ cx services scale --stack <application name> <service name> <count>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
<service name> | yes | — | The service to restart |
<count> | yes | — | Specifies either an absolute count of containers (3), or a relative change ([+4] or ([-2]) |
$ cx services scale -s mystack my_web_service 1
$ cx services scale -s mystack a_backend_service [+5]
$ cx services scale -s mystack a_backend_service [-2]
services stop
Alias: service stop
Stops all the containers for the given service. The list of available services can be obtained through the list services
command. If <server name>
is provided it will query only the specified server.
$ cx services stop --stack <application name> [--server <server name>] <service name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
--server <server name> | no | — | The name of a server to query |
<service name> | yes | — | The service to stop |
$ cx services stop -s mystack my_web_service
$ cx services stop -s mystack a_backend_service
$ cx services stop -s mystack --server my_server my_web_service
settings list
Alias: setting list
Lists all the settings for the given application, including the key, value and readonly flag for each setting. You can use <setting>
multiples times to query multiple services.
$ cx settings list --stack <application name> <setting>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
<setting> | no | — | The setting(s) to query (can be used multiple times) |
$ cx settings list -s mystack
stack.name mystack readonly
git.branch master read/write
git.repository git://git@github.com:cloud66-samples/rails.git read/write
$ cx settings list -s mystack git.branch
git.branch master read/write
settings set
Alias: setting set
Sets and applies the value of a setting to an application.
$ cx settings set --stack <application name> <setting> <values>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
<setting> | yes | — | The setting(s) to query (can be used multiple times) |
<values> | yes | — | The values to apply to the setting |
$ cx settings set -s mystack git.branch dev
$ cx settings set -s mystack allowed.web.source 191.203.12.10
$ cx settings set -s mystack allowed.web.source anywhere
$ cx settings set -s mystack maintenance.mode 1|true|on|enable
$ cx settings set -s mystack maintenance.mode 0|false|off|disable
Available settings
Setting | Default | Description |
---|---|---|
allowed.web.source | nil i.e. 0.0.0.0 |
IP addresses that are allowed to access a stacks web servers (with IP addresses in the command or a CSV file with IP addresses as input) |
asset.prefix | nil | If you change your default Rails assets folder, you can set it here |
continuous.deploy | false |
Enable or disable continuous deployment on Github. |
custom.build.command | - | Set custom build command. Only applies to Sinatra or Padrino stacks |
custom.deploy.command | - | Set custom deploy command. Only applies to Sinatra or Padrino stacks |
db.check.backup.size | true |
Enable/Disable Check free space before taking backup |
git.branch | - | Change the Git branch of the application repository |
git.repository | - | Change the Git repository URL |
logrotate.app.frequency | daily |
For application specific log files accepted value: hourly daily weekly monthly |
logrotate.app.keep.count | 14 |
The number of log files to keep for each logfile |
logrotate.server.frequency | daily |
For server specific log files accepted values: hourly daily weekly monthly |
logrotate.server.keep.count | 14 |
The number of log files to keep for each logfile |
maintenance.mode | false |
Enable or disable maintenance mode on the application. |
reconfigure.nginx | true |
If set to true, it will regenerate Nginx configuration and restart it (only on the next deployment) |
run.deploy.command | true |
Enable or disable option run deploy command on every deployment (“database migrations” for Rails stacks). |
stack.name | View your application name |
skycap listen
Polls your Skycap application and prints workflow events when they are triggered, effectively running the commands embedded in the workflow on the client machine.
$ cx skycap listen --stack <application name> [--log-level <level>] [--interval <time>]
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
--log-level <level> | no | info | The verbosity of logging. Acceptable values: debug, info |
--interval <time> | no | 10s | How often to query the queue - must be greater than 5s |
$ cx skycap list --stack my-skycap-app --log-level "info" --interval "10s"
snapshots list
Lists details of the snapshots in a Skycap application, including triggers, snapshot UUID and date/time
$ cx snapshots list --stack <application name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
$ cx snapshots list -s mystack
snapshots render
Renders the requested files for the given formation and snapshot
$ snapshots render --stack <application name> --formation <formation UID> --snapshot <snapshot UID> [--latest] [--files <file name>] [--outdir <directory path>] [--filter <filter name>] [--ignore warnings]
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
--snapshot <snapshot UID> | yes | — | UID of the snapshot to be used. Use latest to use the most recent snapshot |
--formation <formation UID> | yes | — | UID of the formation to be used |
--latest | no | — | Use the HEAD for stencils. True by default. If false, it would use the snapshot’s gitref |
--files <file name> | no | — | The files to render. If not provided all files will be pulled |
--outdir <directory path> | no | . | The local directory in which to save the files. Will use the current directory by default |
--ignore-errors | no | — | Return anything that can be rendered and ignore the errors |
--ignore-warnings | no | — | Return anything that can be rendered and ignores the warnings |
--filter <filter name> | no | — | The name of the formation filter to be used during rendering |
$ cx snapshots render -s mystack --formation fm-xxxx --snapshot sn-yyyy --latest --files foo.yaml --files bar.yml --ignore-warnings
ssh
Allows direct SSH shell into your servers by opening the firewall temporarily for the source IP address, downloading the SSH key and starting a SSH session with one command.
Your server SSH key is downloaded to ~/.ssh
and re-used in subsequent SSH connections via the toolbelt. You need to have shell to server rights over the application to use this command.
If your server deployed behind a gateway, you need to provide the private key in order to pass through the gateway.
$ cx ssh [--gateway-key <path to gateway key>] --stack <application name> <server name>|<server ip>|<server role> --vv
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
--gateway-key <path to gateway key> | no | — | Path to the private key for the gateway server |
-v, –vv, –vvv | no | — | Set the verbosity level of the output |
<server name> | either/or | — | The name of the server to access |
<server IP> | either/or | — | The IP address of the server to access |
<server role> | either/or | — | Role of the server to access (e.g. web) |
$ cx ssh -s mystack lion
$ cx ssh -s mystack 52.65.34.98
$ cx ssh -s mystack web
$ cx ssh --gateway-key ~/.ssh/bastion_key -s mystack db
stacks clear-caches
Alias: stack clear-caches
For improved performance, Cloud 66 caches volatile code. It is possible for a those caches to become invalid if you switch branches, change git repository URL, rebase or force a commit. Since switching branch or changing git repository URL is done via the Cloud 66 interface, your volatile caches will automatically be purged. However, rebasing or forcing a commit is external to Cloud 66 and therefore doesn’t trigger the purge, so this command can be used to manually purge the existing volatile caches.
$ cx stacks clear-caches --stack <application name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
$ cx stacks clear-caches -s "my updated app"
stacks configure download
Alias: stack configure download
Download configuration files such as a service.yml or manifest.yml. (Maestro only)
$ cx stacks configure download --file <filename> --stack <application name> --output <output path>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
--file, -f <filename> | yes | — | Name of the config file. Accepted values: service.yml ,manifest.yml |
--output, -o <output path> | no | — | Full path of the output file. |
$ cx stacks configure download -f service.yml -s myapp -o /c66/config-files/service.yml
stacks configure list-versions
Alias: stack configure list-versions
List the versions of configuration files such as a service.yml or manifest.yml. (Maestro only)
$ cx stacks configure list-versions --file <filename> --stack <application name> --version <file version type>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
--file, -o <filename> | yes | — | Name of the config file. Accepted values: service.yml ,manifest.yml |
--version, -v <file version type> | no | — | Full or partial file version |
$ cx stacks configure list-versions -o service.yml -s myapp
stacks configure upload
Alias: stack configure upload
Upload configuration files such as a service.yml or manifest.yml. (Maestro only)
$ cx stacks configure upload --file <filename> --stack <application name> --comments <comment>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
--file, -f <filename> | yes | — | Name of the config file. Accepted values: service.yml ,manifest.yml |
--comments, -c <comment> | yes | — | A brief description of your changes |
$ cx stacks configure upload -f service.yml -s myapp -c "updates to ports"
stacks configuration list
Alias: stack configuration list
List all the available configurations on an application.
$ cx stacks configuration list --stack <application name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
$ cx stacks configuration list -s my-app
stacks configuration apply
Alias: stack configuration apply
Applies the latest configuration to an application. You can find all the types of configuration available on your application using the stacks configuration list
function.
$ cx stacks configuration apply --stack <application name> --type <config type>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
--type, -t <config type> | yes | — | Type of configuration to apply |
$ cx stacks configuration apply -s my-application -t nginx
stacks configuration download
Alias: stack configuration download
Gets the content of the specified configuration file from the given application and either prints it to screen or saves it as a file. You can find all the types of configuration available on your application using the stacks configuration list
function.
$ cx stacks configuration download --stack <application name> --type <config type> --output <filename>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
--type, -t <config type> | yes | — | Type of configuration to download |
--output, -o <filename> | no | stdout | Save configuration output to a local file |
$ cx stacks configuration download -s my-application -t nginx -o nginx.conf
stacks configuration upload
Alias: stack configuration upload
Updates the content of the specified configuration type on the stack and (optionally) applies it. You can find all the types of configuration available on your application using the stacks configuration list
function.
$ cx stacks configuration upload --stack <application name> --type <config type> --source <source file> --no-apply --commit-message <message>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | Name of the application |
--type, -t <config type> | yes | — | Type of configuration to upload |
--source <source file> | yes | — | The source file containing the configuration you wish to upload |
--no-apply | no | — | Do not automatically apply the configuration changes to your servers (default behaviour is to apply changes immediately) |
--commit-message <message> | no | — | A message to associate with the configuration update |
$ cx stacks configuration upload -s my-app -t nginx --source nginx.conf --no-apply --commit-message "changes to error pages"
stacks list
Alias: stack list
Lists applications. Shows the application name, environment, and last deploy time. You can query (multiple) applications by name - but the command will display all applications by default.
$ cx stacks list [<application name>] [--output <output style>]
Argument | Required? | Default | Description |
---|---|---|---|
<application name> | no | — | List the details for specific application(s) |
--output, -o <output style> | yes | standard | Tailor the output view. Options are standard or wide |
$ cx stacks list
mystack production Jan 2 12:34
mystack staging Feb 2 12:34
mystack-2 development Jan 2 12:35
$ cx stacks list mystack-2
mystack-2 development Jan 2 12:34
stacks create
Alias: stack create
Creates a new Maestro application based on a service definition (service.yml
) and an optional application Manifest (manifest.yml
).
$ cx stacks create --name <new application name> --service_yaml <service definition>
Argument | Required? | Default | Description |
---|---|---|---|
--name, -n <new application name> | yes | — | Name for the new application |
--service_yaml <service definition> | yes | — | The YAML formatted service definition file |
--manifest_yaml, -m | no | — | Manifest definition for the new application (YAML formatted file) |
$ cx stacks create --name my_maestro_stack --service_yaml service.yml --manifest_yaml manifest.yml
stacks listen
Alias: stack listen
Acts like a tail
for all the deployment logs for an application (to tail a specific log file, see the function below).
$ cx stacks listen --stack <application name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | The application name |
$ cx stacks listen -s my-app
stacks reboot
Alias: stack reboot
Reboots groups of servers in your application. Valid values for the <group>
argument are all
, web
, haproxy
, and db
. Database specific values like mysql
or redis
are also supported.
<strategy>
specifies whether you want your web servers to be rebooted in parallel
or in serial
. For serial reboots web servers are removed and re-added to the load balancer one by one. Non-web server will always be rebooted in parallel. If this value is left unspecified, Cloud 66 will determine the best strategy based on your infrastructure layout.
$ cx stacks reboot --stack <application name> --group <server group> --strategy <reboot strategy> -y
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | The application name |
--group <server group> | no | all | The group of servers to reboot. Valid values: all, web, haproxy, db, mysql, redis, postgres, mongodb |
--strategy <reboot strategy> | no | — | The strategy for rebooting the app’s web servers. Valid values: serial, parallel |
-y | no | — | Answer “yes” to confirmations |
$ cx stacks reboot -s mystack
$ cx stacks reboot -s mystack --group web
$ cx stacks reboot -s mystack --group all -y
$ cx stacks reboot -s mystack --strategy parallel
$ cx stacks reboot -s mystack --group web --strategy serial -y
stacks redeploy
Alias: stack redeploy
Triggers the deployment of an application. Alias of redeploy
function.
stacks restart
Alias: stack restart
Sends a restart signal to all application components. This means different things for different components. For a web server, it means a restart of nginx. For an application server, this might be a restart of the worker processes.
$ cx stacks restart --stack <application name>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | The application name |
$ cx stacks restart -s my-app
stacks ssl
Alias: stack ssl
Add an SSL certificate to a stack.
$ cx stacks ssl --stack <application name> --type <certificate type> --domain <domain name> --ssl-termination --cert <certificate file> --key <SSL key file> --intermediate <intermediate cert file> --overwrite
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | The application name |
--type <certificate type> | yes | — | The type of certificate (lets_encrypt or manual) |
--domain <domain name> | Depends on –type | — | Domain name applicable to this SSL certificate (required for lets_encrypt, optional for manual). Repeatable for multiple domains |
--ssl-termination | no | — | Enable SSL termination |
--cert <certificate file> | Depends on –type | — | SSL certificate file path (required for manual) |
--key <SSL key file> | Depends on –type | — | SSL key file path (required for manual) |
--intermediate <intermediate cert file> | no | — | SSL intermediate certificate file path |
--overwrite | yes, if cert already exists | — | Required confirmation flag to update an existing SSL certificate |
$ cx stacks ssl add -s my-stack --type lets_encrypt --domain 'web.domain.com' --domain 'api.domain.com' --overwrite
$ cx stacks ssl add -s my-stack --type manual --cert /certs/my_certificate --key /ssl/my_key --intermediate /certs/my_intermediate_cert
tags add
Add tags to a given entity.
$ cx tags add --entity <entity type> --id <entity ID> --tags <tag>
Argument | Required? | Default | Description |
---|---|---|---|
--entity <entity type> | yes | — | The type of the entity |
--id <entity ID> | yes | — | The id of the entity |
--tags <tag> | yes | — | Tags to add to the given entity (can be multiple) |
$ cx tags add --entity stack --id 12 --tags foo --tags bar
tags delete
Remove tags from a given entity.
$ cx tags delete --entity <entity type> --id <entity ID> --tags <tag>
Argument | Required? | Default | Description |
---|---|---|---|
--entity <entity type> | yes | — | The type of the entity |
--id <entity ID> | yes | — | The id of the entity |
--tags <tag> | yes | — | Tags to remove from the given entity (can be multiple) |
$ cx tags delete --entity stack --id 45 --tags buzz --tags fuzz
tail
Runs a Linux tail
command on the specified server and given log file. You must specify the log file name including the extension. If you don’t specify a path, or specify a relative path, then we will assume <stack-directory>/current/log
(i.e. the subdirectory und $STACK_PATH
) as the current directory. You can specify a different (absolute) log path as needed.
This command is only supported on Linux and OS X.
$ cx tail --stack <application name> <server name> | <server ip> | <server role> /optional/log/path/<log filename>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | The application name |
<server name> | either/or | — | Name of the server to query |
<server ip> | either/or | — | IP of the server to query |
<server role> | either/or | — | Role of the server to query |
/optional/log/path/<log filename> | no | — | The log file to query (must include extension) |
$ cx tail -s mystack production.log
$ cx tail -s mystack 52.65.34.98 nginx_error.log
$ cx tail -s mystack web /custom/logs/my.log
templates list
Lists all stencil template repositories for Skycap applications in an account.
Usage:
$ cx templates list
templates resync
Pulls the latest code from the stencil template repository for a specific template.
$ cx templates resync --template <template UID>
Argument | Required? | Default | Description |
---|---|---|---|
--template <template UID> | yes | — | The UID of the template that will be refreshed |
$ cx templates resync --template 'bt-2e0810a17c33ab35d7970ff330b1f916'
templates show
Shows a single template repository and its stencils.
$ cx templates show --name <repo name>
Argument | Required? | Default | Description |
---|---|---|---|
--name <repo name> | yes | — | The name of the template repository |
$ cx templates show --name 'my repo'
test
Checks if cx is properly installed and authenticated.
Usage:
$ cx test
tunnel
Opens an SSH tunnel between your local machine and the remote server on a specific port. This is useful when connecting to remote databases or other services using local tools.
tunnel
does the following:
- Opens a lease in port 22 for your local IP address
- Fetches your SSH key from your Cloud 66 account
- Starts an SSH tunnel between your machine and the server on the given ports
- Closes the tunnel when you exit the Toolbelt (Ctrl-C)
Applications using gateways (Bastion servers) are not supported.
If a role is specified the command will connect to the first server with that role.
To specify the ports for the tunnel, use --local
and --remote
arguments. For example, if you need to connect to a MySQL server, you can use 3307
locally and 3306
(MySQL port on the server) as the remote port. Once the tunnel is established, you can use your favourite MySQL client to connect to the server on 127.0.0.1 and the local port (3307
in this case).
If a local port is not specified, cx will use “remote + 1” as a convention for the local port. For example, if you only specify --remote 5432
without explicitly specifying local, cx will use 5433
as the local port.
This command is only supported on Linux and OS X (for Windows you can run this in a virtual machine if necessary)
$ cx tunnel --stack <application name> --server <server name> | <server IP> | <server role> --local <local port> --remote <remote port>
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | The application name |
--server <server name> | <server ip> | <server role> | either/or | — | Name or IP or role of the server to access |
-local, -l <local port> | no | — | Local port for the tunnel |
-remote, -r <remote port> | yes | — | Remote port for the tunnel |
$ cx tunnel -s mystack --server lion --local 3307 --remote 3306
$ cx tunnel -s mystack --server 52.65.34.98 --local 3307 --remote 3306
$ cx tunnel -s mystack --server web -l 3307 -r 3306
update
This command runs automatically. You should not need to run it manually. You can use it to force cx to use a certain version.
Usage:
$ cx update --force <version>
upload
Copies a file from your local computer to the remote server. Uploads the files to the /tmp
directory by default, unless a path is specified.
This command open the firewall for SSH from your IP address temporarily (20 minutes), downloads the keys if you don’t have them and starts a SSH session. If a role is specified the command will connect to the first server with that role.
This command is only supported on Linux and OS X (for Windows you can run this in a virtual machine if necessary)
$ cx upload --stack <application name> --server <server name> | <server IP> | <server role> /path/to/source/file /path/to/target/directory
Argument | Required? | Default | Description |
---|---|---|---|
--stack, -s <application name> | yes | — | The application name |
--server <server name> | <server ip> | <server role> | yes | — | Name or IP or role of the server to which the file will be uploaded |
/path/to/source/file | yes | — | Local path to the file that will be uploaded |
/path/to/target/dir | no | /tmp | Path on the server where the file will be saved |
$ cx upload -s mystack --server lion /tmp/file.txt
$ cx upload -s mystack --server lion /mydir/files/file.txt /var/www/app
$ cx upload -s mystack --server 52.65.34.98 /user/archives/yes.zip
$ cx upload -s mystack --server web /path/to/source/file /path/to/target/directory
users list
Shows a list of all the users in an organization that you have rights to manage. You can find your <organization name>
by using cx info
.
$ cx --org <organization name> users list
Argument | Required? | Default | Description |
---|---|---|---|
--org <organization name> | yes | — | The email address associated with the user’s Cloud 66 account |
$ cx --org my-org users list
users apply-profile
Apply Profile allows you to apply a user’s Access Profile to another one. To use this command you need to have an Access Profile as a json
file. This can be generated using the users show
command with the json
option. Once you have the file you can modify it to make any changes you require in the Access Profile.
Any missing attribute for the json
Access Profile will be left unchanged even if override
is used. Also, override
doesn’t have any effect on the contents of the account_profile
section.
$ cx users apply-profile <user email> --json <access profile>
Argument | Required? | Default | Description |
---|---|---|---|
<user email> | yes | — | The email address associated with the user’s Cloud 66 account |
--json <access profile> | yes | — | The access profile to be applied to the user |
--override | no | — | Will override the access rights instead of append |
$ cx --org My_Awesome_org users apply-profile jack@gmail.com --json /tmp/jim_profile.json
$ cx --org My_Awesome_org users apply-profile jack@gmail.com --json /tmp/jim_profile.json --override
users show
Returns details about a user. You can dump these as a json file for use with the users apply-profile
function.
$ cx users show <user email> --json <filename>
Argument | Required? | Default | Description |
---|---|---|---|
<user email> | yes | — | The email address associated with the user’s Cloud 66 account |
--json <filename> | no | — | Dumps the profile data as a json formatted file. |
$ cx users show jim@gmail.com --json /tmp/jim_profile.json