使用 Universal 安装工具的 AWS 上多分域 DC/OS

AWS 上 DC/OS 使用 Universal 安装工具添加远程分域的指南。

This guide expects that you already have a running DC/OS cluster based on Universal Installer . To learn more about running DC/OS with the Universal Installer have a look into the Guide for DC/OS on AWS using the Universal Installer.

You will learn how to place additional infrastructure into a AWS remote region. Remote regions will be connected to each other by using the .

Prerequisites

  • A running DC/OS Enterprise cluster set up with Universal Installer 0.2 modules
  • A subnet range for your remote region

Getting started with remote region

We expect your already running DC/OS clusters main.tf will look similar to this example. To deploy a remote region we have to do some changes to your main.tf

The first change we have to apply to your main.tf is adding a specific provider statement for the remote region. In this example we will use us-west-2 with the alias usw2 as our remote region. We also add an alias statement to the provider used deploying our region holding the master instances.

This needs to be done so our modules know which account credentials to use.

Note: Some resources have name length limitations which is the reason we shorten our region name.

  1. provider "aws" {
  2.   # Change your default region here
  3.   region = "us-east-1"
  4.   alias  = "master"
  5. }
  7. provider "aws" {
  8.   # Change your default region here
  9.   region = "us-west-2"
  10.   alias  = "usw2"
  11. }
  13. # ...

To create the remote region and its infrastructure we will use the same underlying modules as in our master region. This also means there will be some information needed for both infrastructures like cluster_name, admin_ips and ssh_public_key_file. To make the operation easier you should define local variables in your main.tf that will be used in every module.

  1. #...
  3. // lets define variables which are shared between all regions
  4. locals {
  5.   ssh_public_key_file = "~/.ssh/id_rsa.pub"
  6.   cluster_name        = "my-dcos-demo"
  7.   admin_ips           = ["${data.http.whatismyip.body}/32"]
  8. }
  10. #...

Part of the shared information is which internal subnets are used in your infrastructure. This information needs to be known by all parts of the DC/OS so traffic can be routed and is allowed by the security groups. If you did not specify subnet_range, terraform uses the default which is 172.16.0.0/16. The remote region we want to specify needs its own subnet.

IMPORTANT: You should not take the next free network of 172.16/12 as 172.17.0.0/16 is dockers internal network default which will lead to problems.

The locals section will now look like this

To let our main region allow traffic from the remote region and vice versa we have to specify the accepted_internal_networks variable in both. This variable will inform the security group which allows the agents and masters to communicate to each other. accepted_internal_networks can contain the regions network which makes it extremly easy to let terraform calculate the value for this variable. We will use the values method to retrieve the subnets from locals.region_networks which we previously defined.

The locals section will now look like this:

  1. #...
  3. locals {
  4.   ssh_public_key_file = "<path-to-public-key-file>"
  7.   region_networks = {
  8.     // dont use 172.17/26 as its used by docker.
  9.     "master" = "172.16.0.0/16" // this is the default
  10.     "usw2"   = "10.128.0.0/16"
  11.   }
  13.   accepted_internal_networks = "${values(local.region_networks)}"
  14. }
  16. #...

Before we start changing values within the dcos module we will append the infrastructure definition of the remote region to your main.tf. In our example case we only want to have private agents in our remote region, and both private and public agents can be put in a remote region.

IMPORTANT: Running master instances in remote regions is not supported.

To only start private agents we will set num_masters = 0 and num_public_agents = 0. Due to some internal limitation we also have to tell the infrastructure module not preparing load balancers for masters and public agents with lb_disable_public_agents and lb_disable_masters

Another important topic to mention is naming. To distinguish between instances of your main and your remote region we introduced the name_prefix variable which allows you to add a prefix to the name of every resource. In this example we set the name_prefix to the short name of the remote region.

In the following example you will also find the being used in the module call referenced by e.g. local.admin_ips and the provider we specified for the region

  1. #...
  3. module "dcos-usw2" {
  4.   source  = "dcos-terraform/infrastructure/aws"
  5.   version = "~> 0.2.0"
  7.   admin_ips   = ["${local.admin_ips}"]
  8.   name_prefix = "usw2"
  10.   cluster_name               = "${local.cluster_name}"
  11.   accepted_internal_networks = "${values(local.region_networks)}"
  13.   num_masters        = 0
  14.   num_private_agents = 1
  15.   num_public_agents  = 0
  17.   lb_disable_public_agents = true
  18.   lb_disable_masters       = true
  20.   ssh_public_key_file = "${local.ssh_public_key_file}"
  21.   subnet_range        = "${local.region_networks["usw2"]}"
  23.   providers = {
  24.     aws = "aws.usw2"
  25.   }

We now need to establish a connection between the two infrastructures. The Universal Installer provides a module for this task. In this module we reference data from both infrastructures the main region holding DC/OS masters and the remote region holding your remote private agents.

Here is the example vpc-peering-section

At this point its time to do changes to your dcos module so it knows about the remote region and is able to install the remote agents.

  1. Choose a subnet range. In general this change is not needed but we wanted to make your example pretty specific.

subnet_range = "${local.region_networks["master"]}"

  1. Add accepted internal networks. Same as in the remote region we need to specify the internal networks to allow internal traffic flow.

accepted_internal_networks = "${values(local.region_networks)}"

  1. Change the cluster_name. As this is a shared resource we will make use of the local variable.

cluster_name = "${local.cluster_name}"

  1. List the SSH key. This is also a shared resource and we can make use of the local variable

ssh_public_key_file = "${local.ssh_public_key_file}"

  1. Add the admin IPs following the same pattern.

admin_ips = ["${local.admin_ips}"]

  1. Add the private agents. This nearly the most important new variable. This tells the DC/OS installation module which other agents need to be installed.

additional_private_agent_ips = ["${module.dcos-usw2.private_agents.private_ips}"]

  1. Update the providers section. As we change to explicit alias providers we have to point our dcos module to this specific provider.
  1. providers = {
  2.   aws = "aws.master"
  3. }

After the changes above have been applied, your dcos module should look like this

  1. module "dcos" {
  2.   source  = "dcos-terraform/dcos/aws"
  3.   version = "~> 0.2.0"
  5.   cluster_name        = "${local.cluster_name}"
  6.   ssh_public_key_file = "${local.ssh_public_key_file}"
  7.   admin_ips           = ["${local.admin_ips}"]
  8.   subnet_range        = "${local.region_networks["master"]}"
  10.   num_masters        = "1"
  11.   num_private_agents = "2"
  12.   num_public_agents  = "1"
  14.   dcos_version = "1.13.3"
  16.   dcos_instance_os             = "centos_7.5"
  17.   bootstrap_instance_type      = "m5.large"
  18.   masters_instance_type        = "m5.2xlarge"
  19.   private_agents_instance_type = "m5.xlarge"
  20.   public_agents_instance_type  = "m5.xlarge"
  22.   accepted_internal_networks   = "${values(local.region_networks)}"
  23.   additional_private_agent_ips = ["${module.dcos-usw2.private_agents.private_ips}"]
  25.   providers = {
  26.     aws = "aws.master"
  27.   }
  29.   dcos_variant              = "ee"
  30. }

Full main.tf example