This article is being updated. Please be aware the content herein, not limited to version numbers and slight syntax changes, may not match the output from the most recent versions of Bright. This notation will be removed when the content has been updated.
This article describes how to configure cm-cluster-extension to an already existing VPC (and vpc subnets).
- Start cm-cluster-extension CLI tool, select “Add cloud provider” menu entry.
- Follow on-screen instructions up until the “Summary” screen. When selecting “region” select the region which contains the existing VPC you want to use.
- On the last (“Summary”) screen go to ‘Advanced’ -> clusterextension -> “VPC for region <name>”.
- Change “CREATE NEW” to the vpc you want to reuse. There will be a list of VPC. Highlight the desired VPC and confirm it with ENTER. After that tool will prompt for selecting public and private subnets. If there is a desire to use only one subnet, not two, then select the same subnet as both public and private.
- Choose existing security groups if needed:
- Select “Security groups” -> “PICK SECURITY GROUPS”.
- A menu opens, allowing you to select one of the available security groups for the cloud director.
- Once you pick a security group for cloud director, second menu will open allowing you to select one of the available security groups for cloud nodes.
- Go back to “Summary” screen, write out config file to disk. Exit utility.
- Before deploying, open the newly created config file (YAML format) in your favorite editor, and ensure that the following values are set correctly in the config file:
- underneath the “vpcs” config section:
base_address -> must match the selected VPC
id: <id> <- must match the id of the VPC, e.g. “vpc-dsadwe” - underneath the “vpcs/subnets” config section (i.e. a “subnets” section inside of the “vpcs” section):
make sure “base_address”, “id”, “netmask_bits” match the values of the selected subnet(s). Also, if you select one subnet, make sure the “cloud_node_count” is other than 0. If you selected two subnets (public and private), the ‘cloud_node_count’ in most cases should be “0” for public subnet, and non-zero for “private subnet”, those other combination will also work. But if it will be set to 0 for both subnets, no cloud compute nodes will be created by the deployment.
- underneath the “vpcs” config section:
At this point you’re ready to power on your cloud director.
The following approach is still valid for older 7.3 versions that lack the feature to pick security groups using advanced settings:
- run cm-cluster-extension -c <config_name>
- go to cmsh
cloud; use amazon; privateclouds; use <name>;
show
[pw-aws->cloud[amazon]->privateclouds[vpc-eu-central-1]]% show
Parameter Value
-------------------------------- ---------------------------------------
Revision
Type ec2
DefaultNetworkACL
InternetGatewayID
MainRouteTable
Name vpc-eu-central-1
Private Net RTID
Public Net RTID
SecGroupD
SecGroupN
(...)“SecGroupD” and “SecGroupN” will be empty. You will need to set them to IDs of the sec groups.
Depending on the exact version of your CMDaemon might have by default created default security groups in the selected VPC, called “brightclouddirectorVPC” and “brightnodeVPC”
Get their IDs from AWS web console, and set them to SecGroupD (for brightclouddirectorVPC) and SecGroupN (for brightnodeVPC)
Example final:
[pw-aws->cloud[amazon]->privateclouds[vpc-eu-central-1]]% show | grep SecGroup
SecGroupD sg-e8a0c580
SecGroupN sg-e9a0c581
- in the same mode set the following fields to "false":
manageRouteTableSetupInAWS
manageSecurityGroupsInAWS
manageSubnetsInAWS
manageVPCInAWSOtherwise CMDaemon might attempt to remove certain VPC entities when removing cluster extension intergation