feat: (IAC-1117) Dark Site deployment #288
Conversation
| ## Launch EC2-instance based on the current AMI in use | ||
| First thing to do is launch an EC2-instance based on the AMI that's in use as AWS-base image for the nfs-server and the jump-server. You can see which AMI that is in https://github.com/sassoftware/viya4-iac-aws/blob/main/modules/aws_vm/main.tf | ||
|
|
||
|  |
There was a problem hiding this comment.
Guessing this is the code snippet that's an image. Is there a reason this is not plain text one could copy?
There was a problem hiding this comment.
@thpang, the main reason that I used the image is that the README content from Josh's repo and the inline images that he included is that they are all intended to work together to help illustrate the required steps for creating a custom AMI image as simply as possible. I suspect he thought that the images were more helpful than the words that might replace it. In some cases he highlights relevant fields or indicates the important parts of an AWS console page action with arrows.
Would you consider us releasing this as is in the experimental phase since we know that it is a working set of instructions and following up with another task that tries to replace the existing images with text if that is what you would prefer we have instead?
| sudo apt install nfs-kernel-server | ||
| ``` | ||
|
|
||
|  |
There was a problem hiding this comment.
If we're providing images for the output of the commands, could those images be associated with the command that was run? Seems like we state the 3 commands and then have the 3 outputs from those commands.
| git clone https://github.com/sassoftware/viya4-iac-aws.git | ||
| ``` | ||
|
|
||
| <img src="img/img17.png" style="zoom:60%;" /> |
There was a problem hiding this comment.
Again, not sure this is the right image, but the data block for the image assignment should be text that can be copied if possible.
There was a problem hiding this comment.
Is there not a sample or example file we can share with folks in this section. Lots of screen shots of text and modifications but it might be better to have a file with comments in-line that could be removed to address the same thing.
There was a problem hiding this comment.
Not a fan of providing text that could be copied or utilized as an image.
There was a problem hiding this comment.
Having an example file might be simpler here with items that call out what needs to be done.
viya4-iac-aws-darksite/README.md
Outdated
| This documentation contains procedures that can be used to successfully complete a Dark Site deployment using elements of `viya4-iac-aws` GitHub project decribed below. | ||
|
|
||
| #### Dark Site Deployment Target Recommendation | ||
| **Note:** _It is recommended for a Dark Site deployment that you use a [BYON](https://github.com/sassoftware/viya4-iac-aws/blob/main/docs/user/BYOnetwork.md) or Bring Your Own Network configuration (scenario 3) with IAC by creating your own VPC, subnets, AWS private endpoints, and network security groups versus letting `viya4-iac-aws` create these items for you. If you rely on `viya4-iac-aws` to create the network infrastructure in a Dark Site scenario, you will likely run into failure points. The procedures listed below assume that you use a BYON configuration scenario with IAC._ |
There was a problem hiding this comment.
viya4-iac-aws-darksite/README.md
Outdated
| 3. **Build tfvars:** | ||
| - The Terraform scripts create the necessary BYON subnet_ids, `viya4-iac-aws` can be configured to use those subnets for all the subnet_ids map BYON variables in the tfvars file (public, private, control_plane and database). | ||
| - Do not specify any public access cidrs in your tfvars file. | ||
| - Set `cluster_api_mode` to private. |
There was a problem hiding this comment.
The primary thing that IaC users need to be concerned about for a private site is networking: both a route from the IaC execution machine and a route from the BYON VPC to AWS services needed to create the cluster. This latter can happen over a private channel by ensuring that either:
IaC creates VPC endpoints for requisite services, e.g. *.ec2..vpce.amazonaws.com
or the customer pre-creates VPC endpoints for requisite services
I think this needs stating in any "dark site README for IaC".
And, technically speaking, cluster_api_mode is not required to be at 'private' for a dark site. IaC creates both a 'public and private' endpoint when cluster_api_mode=public and EKS still sets up the private subnet based ENIs for private access to the control plane and to allow the control plane to communicate with the kubelets.
If one uses cluster_api_mode=public things are still workable and in such a case a customer might want to specify cluster_endpoint_public_access_cidrs
Can we re-phrase this more as a recommended way to use IaC to integrated with a BYON dark site? There isn't only the way suggested here, albeit it is the most common/typical approach.
For example ....
Recommend using cluster_api_mode of private
recommend ensuring vpc_private_endpoints_enabled is true (over false and providing them)
and always include all source IPs as needed for the following variables:
cluster_endpoint_private_access_cidrs
vpc_endpoint_private_access_cidrs
vm_private_access_cidrs
viya4-iac-aws-darksite/README.md
Outdated
| - Set `cluster_api_mode` to private. | ||
|
|
||
| 4. **Deploy viya4-iac-aws:** | ||
| - Ensure that the deployment machine has a route and is allowed ingress to the cluster control plane before attempting a deployment. Executing a `kubectl` command such as `kubectl get nodes` from the deployment VM in the public VPC can be used to confirm connectivty to the EKS control plane. |
There was a problem hiding this comment.
I'm confused here, perhaps some of the terminology being used isn't helping?
How can you confirm connectivity to the control plane before building the cluster? You don't have the URI for the API server UNTIL you have a cluster.
Of course if we are talking about later, on the Viya 4 Deployment machine, that's different, but I don't think we are talking about that here. Some terminology changes could help:
Terminology
Typically we use "deploy" for SAS Viya and the viya4-deployment project.
For IaC, I find it's clearer to stick to terms like "build" the infrastructure. The machine where IaC runs is then the execution or build machine.
Ingress: while valid to use ingress as you are here, it's easily confused with the all important topic of "cluster ingress and the ingress controller". I find it better to stick to "inbound access" when talking about "allowed" routes, since we are talking about security groups now, and AWS uses "INBOUND rules" in this context.
|
Had a discussion with Thomas this morning, I opened IAC-1470 to address the review concerns he raised above related to the image based command inputs that are present in the current custom-ami/README.md content. Intent is to include those changes in the follow-up minor release for Dark Site / Air-Gapped Experimental support. Thomas was OK with the current content and that plan to re-visit and update the images where needed. |
There was a problem hiding this comment.
Good with the changes as @dhoucgitter stated, with the caveat that the input examples are put in plain text and/or an example file is created to help the customer in the near future, i.e. the next release before general availability.
Refer to internal ticket comment on May 8 for dev branch information being used for Experimental dar site support code review.