Managed Nodes

Shipa automatically manages managed nodes. Shipa handles the machine provisioning process and installation using your cloud configuration.

The sections below cover the necessary information required by users when using Shipa to manage and scale nodes.

Adding New Nodes


Cloud Credentials

Before adding cloud nodes, confirm that the desired cloud provider's credentials are entered using the shipa credential add command.

For more information, please visit the Cloud Credentials page

To add (register) a new node with the Shipa framework, use the node add command.

shipa node add [param_name=param_value]...

By default, this command calls the configured cloud provider to create a new machine. Every parameter is sent to the cloud provider during node creation.

Shipa supports nodes across different clouds and virtualization providers. Below is a description of a few options when creating nodes on the specific providers:

Amazon Web Services:

amazonec2-block-duration-minutesAWS spot instance duration in minutes (60, 120, 180, 240, 300, or 360)-
amazonec2-iam-instance-profileThe AWS IAM role name to be used as the instance profile-
amazonec2-instance-typeThe instance type to runt2.micro
amazonec2-monitoringEnable CloudWatch Monitoringfalse
amazonec2-regionThe region to use when launching the instanceus-east-1
amazonec2-request-spot-instanceUse spot instancesfalse
amazonec2-root-sizeThe root disk size of the instance (in GB)16
amazonec2-security-groupAWS VPC security group namedocker-machine
amazonec2-spot-priceSpot instance bid price in dollars. Requires the amazonec2-request-spot-instance flag.0.50
amazonec2-subnet-idAWS VPC subnet ID-
amazonec2-tagsA comma-separated list of AWS extra tag key-value pairs. For example, key1,value1,key2,value2 -
amazonec2-vpc-idYour VPC ID to launch the instance in-
amazonec2-zoneThe AWS zone to launch the instance in (one of a,b,c,d, and e)a

Below is an example of the node add command adding a node in AWS:

shipa node add driver=amazonec2 amazonec2-region=us-west-1 amazonec2-zone=a amazonec2-instance-type=c5.xlarge framework=aws name=aws-ca-01 credential=aws

Google Cloud:

google-disk-sizeThe disk size of instance.10
google-disk-typeThe disk type of instancepd-standard
google-machine-typeThe type of instancef1-standard-1
google-networkSpecify network in which to provision VMdefault
google-subnetworkSpecify subnetwork in which to provision VM-
google-tagsInstance tags (comma-separated)-
google-zoneThe zone to launch the instanceus-central1-a
google-projectThe project to launch the instance

Below is an example of the node add command adding a node in Google Cloud:

shipa node add driver=google framework=shipa-framework-name name=machine-name credential=credential-name google-zone=europe-west4-a google-machine-type=n1-standard-2 google-disk-size=50 google-project=project-name

Microsoft Azure:

azure-availability-setAzure Availability Set to place the virtual machine intodocker-machine
azure-environmentAzure environment. For example, AzurePublicCloud or AzureChinaCloudAzurePublicCloud
azure-locationAzure region to create the virtual machinewestus
azure-resource-groupAzure Resource Group name to create the resources indocker-machine
azure-sizeSize for Azure Virtual MachineStandard_A2
azure-subnetAzure Subnet Name to be used within the Virtual Network192.168.0.0/16
azure-subnet-prefixPrivate CIDR block. Used to create subnet if it does not exist. Must match in the case that the subnet does exist.docker-machine
azure-vnetAzure Virtual Network name to connect the virtual machine. To specify a Virtual Network from another resource group, use resourcegroup:vnet-name format.docker-machine

Below is an example of the node add command adding a node in Microsoft Azure:

shipa node add driver=azure framework=azure name=az1 credential=azure azure-location=southcentralus azure-size=Standard_B2ms

Listing Nodes

To list the nodes to a specific cluster, use the node-list command.

shipa node list [--filter/-f <metadata>=<value>]...

The command also shows the metadata associated with each node and the IaaS ID if added using an IaaS provider.

When using the -f/--filter flag, the user can filter the nodes in the list based on the key pairs displayed in the metadata column. Users can also combine filters using -f multiple times.


-f, --filter(= {}) Filter by metadata name and value
-q(= false) Display only nodes IP address

Updating Nodes

To modify metadata associated with a node, use the node update command.

shipa node update <address> [param_name=param_value...] [--disable] [--enable]

The command above modifies metadata associated with a node. If a parameter is set to an empty value, it will be removed from the node's metadata.

If the --disable flag is used, the node will be marked as disabled, and the scheduler won't consider it when selecting a node to receive containers.


--disable(= false) Disable node in scheduler
--enable(= false) Enable node in scheduler

Removing Nodes

To removes a specific node from a cluster, use the node remove command.

shipa node remove <address> [--no-rebalance] [--destroy] [-y]

Removes a specific node from a cluster.

By default, Shipa will redistribute all containers present on the removed node among other existing nodes. This behavior can be inhibited using the --no-rebalance flag.

Shipa will not destroy the machine on the cloud provider if the node being removed was created using a cloud provider unless the --destroy flag is used.


--destroy(= false) Destroys node from cloud provider
--no-rebalance(= false) Do not rebalance containers from removed node
-y, --assume-yes(= false) Do not ask for confirmation

Rebalancing Containers

To move units among nodes to create a more even distribution, use the node rebalance command.

shipa node rebalance [--dry] [-y/--assume-yes] [-m/--metadata <metadata>=<value>]... [-a/--app <appname>]...

This command will automatically choose which node each unit should be moved to, distributing the units as evenly as possible.

The --dry flag runs the balancing algorithm without doing any real modification. It will only print which units would be moved and where they would be created.


-a, --app(= []) Filter by application name
--dry(= false) Dry run, only shows results of a simulation
-m, --metadata(= {}) Filter by host metadata
-y, --assume-yes(= false) Do not ask for confirmation