Remove AWS deployment from Architecture Description and place into de…

…ployment-aws.adoc
SUSE · Feb 21, 2020 · 5edd4a1 · 5edd4a1
1 parent 9d6d8fb
commit 5edd4a1
Show file tree

Hide file tree

Showing 2 changed files with 90 additions and 83 deletions.
diff --git a/adoc/architecture-description.adoc b/adoc/architecture-description.adoc
@@ -80,8 +80,8 @@ Versioning scheme: `x.y.z`
 * SUSE OpenStack Cloud 8
 * VMware ESXi {vmware_version}
 * Bare Metal
+* Amazon Web Services (technological preview)
 
-Deployment on Amazon Web Services (AWS) is currently tech preview.
 
 == Supported Architectures
 
@@ -330,86 +330,6 @@ it's needed to have a local RMT server mirroring the CaaSP
 repositories, a mirror of the SUSE container registry and a mirror of
 the SUSE helm chart repository.
 
-[[architecture.aws]]
-=== AWS Deployment
-
-The AWS deployment created by our {tf} template files leads to the
-creation of the infrastructure described in the next paragraphs.
-
-==== Network
-
-All the infrastructure is created inside of a user specified AWS region.
-All the resources are currently located inside of the same availability
-region.
-
-A dedicated Amazon Virtual Private Cloud (link:https://aws.amazon.com/vpc/[VPC])
-with two subnets (_"public"_ and _"private"_) is created by the {tf} template
-files.
-
-Instances inside of the public subnet have
-link:https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html[Elasic IP addresses]
-associated, hence they are reachable from the internet.
-
-Instances inside of the private subnet are not reachable from the internet.
-However they can still reach external resources; for example they can still
-perform operations like downloading updates and pulling container images from
-external container registries.
-
-Communication between the public and the private subnet is allowed.
-
-All the control plane instances are currently located inside of the public
-subnet. Worker instances are inside of the private subnet.
-
-Both control plane and worker nodes have tailored
-link:https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html[Security Groups]
-assigned to them. These are based on the networking requirements described
-in <<sysreq.networking>>.
-
-==== Load Balancer
-
-The {tf} template files take care of creating a
-link:https://aws.amazon.com/elasticloadbalancing/[Classic Load Balancer]
-which exposes the Kubernetes API service deployed on the control plane
-nodes.
-
-The load balancer exposes the following ports:
-
-* `6443`: Kubernetes API server
-* `32000`: Dex (OIDC Connect)
-* `32001`: Gangway (RBAC Authenticate)
-
-[[architecture.aws.vpc_peering]]
-==== Join already existing VPCs
-
-The {tf} template files allow the user to have the
-{productname} VPC join one or more existing VPCs.
-
-This is achieved by the creation of
-link:https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html[VPC peering links]
-and dedicated
-link:https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html[Route tables].
-
-This feature allows {productname} to access and be accessed by resources defined
-inside of other VPCs. For example, this capability can be used to register all
-the {productname} instances against a SUSE Manager server running inside of a
-private VPC.
-
-Current limitations:
-
-* The VPCs must belong to the same AWS region.
-* The VPCs must be owned by the same user who is creating the {productname}
-infrastructure via {tf}.
-
-==== IAM profiles
-
-The
-link:https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#aws[AWS Cloud Provider]
-integration for Kubernetes requires special
-link:https://aws.amazon.com/iam/[IAM] profiles to be associated with the control
-plane and worker instances.
-
-{tf} can create these profiles or can leverage existing ones. It all depends on
-the rights of the user invoking {tf}.
 
 === Control plane nodes certificates
 

diff --git a/adoc/deployment-aws.adoc b/adoc/deployment-aws.adoc
@@ -1,13 +1,100 @@
 == Deployment on Amazon AWS
 
+Deployment on Amazon Web Services (AWS) is currently tech preview.
+
 .Preparation Required
 [NOTE]
+====
 You must have completed <<deployment.preparations>> to proceed.
+====
 
 You will use {tf} to deploy the whole infrastructure described in
-<<architecture.aws>>. Then you will use the `skuba` tool to bootstrap the
+<<architecture-aws>>. Then you will use the `skuba` tool to bootstrap the
 {kube} cluster on top of those.
 
+
+[[architecture-aws]]
+=== AWS Deployment
+
+The AWS deployment created by our {tf} template files leads to the
+creation of the infrastructure described in the next paragraphs.
+
+==== Network
+
+All the infrastructure is created inside of a user specified AWS region.
+All the resources are currently located inside of the same availability
+region.
+
+A dedicated Amazon Virtual Private Cloud (link:https://aws.amazon.com/vpc/[VPC])
+with two subnets (_"public"_ and _"private"_) is created by the {tf} template
+files.
+
+Instances inside of the public subnet have
+link:https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html[Elasic IP addresses]
+associated, hence they are reachable from the internet.
+
+Instances inside of the private subnet are not reachable from the internet.
+However they can still reach external resources; for example they can still
+perform operations like downloading updates and pulling container images from
+external container registries.
+
+Communication between the public and the private subnet is allowed.
+
+All the control plane instances are currently located inside of the public
+subnet. Worker instances are inside of the private subnet.
+
+Both control plane and worker nodes have tailored
+link:https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html[Security Groups]
+assigned to them. These are based on the networking requirements described
+in <<sysreq.networking>>.
+
+==== Load Balancer
+
+The {tf} template files take care of creating a
+link:https://aws.amazon.com/elasticloadbalancing/[Classic Load Balancer]
+which exposes the Kubernetes API service deployed on the control plane
+nodes.
+
+The load balancer exposes the following ports:
+
+* `6443`: Kubernetes API server
+* `32000`: Dex (OIDC Connect)
+* `32001`: Gangway (RBAC Authenticate)
+
+[[architecture-aws-vpc-peering]]
+==== Join already existing VPCs
+
+The {tf} template files allow the user to have the
+{productname} VPC join one or more existing VPCs.
+
+This is achieved by the creation of
+link:https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html[VPC peering links]
+and dedicated
+link:https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html[Route tables].
+
+This feature allows {productname} to access and be accessed by resources defined
+inside of other VPCs. For example, this capability can be used to register all
+the {productname} instances against a SUSE Manager server running inside of a
+private VPC.
+
+Current limitations:
+
+* The VPCs must belong to the same AWS region.
+* The VPCs must be owned by the same user who is creating the {productname}
+infrastructure via {tf}.
+
+==== IAM profiles
+
+The
+link:https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/#aws[AWS Cloud Provider]
+integration for Kubernetes requires special
+link:https://aws.amazon.com/iam/[IAM] profiles to be associated with the control
+plane and worker instances.
+
+{tf} can create these profiles or can leverage existing ones. It all depends on
+the rights of the user invoking {tf}.
+
+
 The {tf} link:https://www.terraform.io/docs/providers/aws/index.html[AWS provider]
 requires your credentials. These can be obtained by following these steps:
 
@@ -85,7 +172,7 @@ the nodes in the cluster must be directly reachable from the machine where
 `skuba` is being run.
 `skuba` could be run from one of the master nodes or from a pre-existing bastion
 host located inside of a joined VPC as described in
-<<architecture.aws.vpc_peering>>.
+<<architecture-aws-vpc-peering>>.
 ====
 
 .Note down IP/FQDN for nodes