-
Notifications
You must be signed in to change notification settings - Fork 2
docs: editorial review of part 2 #4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,7 @@ | ||
# Lab 2: Automating deployment, and sharing through a private IBM Cloud Catalog | ||
# Lab 2: Automating deployment and sharing through a private catalog | ||
|
||
Lab 1 shows how you can leverage existing landing-zone automation to deploy most of the topology, and then customize and deploy on top of that infrastructure. | ||
In lab 1, you deployed most of the landing zone topology, and then customized the infrastructure. | ||
|
||
The purpose of lab 2 is to show of the manual steps in lab 1 can be fully automated. Lab 2 will also show how the fully automated custom solution can be shared with other users in your enterprise through the [IBM Cloud Catalog](https://cloud.ibm.com/catalog). | ||
Now in lab 2, you use automation to accomplish what you did manually in lab 1. Lab 2 also demonstrates how you can share the fully automated custom solution with other users in your enterprise through the [IBM Cloud catalog](https://cloud.ibm.com/catalog). | ||
|
||
Lab 2 assumes a basic knowledge of [Terraform](https://www.ibm.com/topics/terraform). | ||
Lab 2 assumes a basic knowledge of [Terraform](https://www.ibm.com/topics/terraform). |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,64 +1,45 @@ | ||
# Customizing the landing zone topology | ||
|
||
## Overview of the landing-zone customization options | ||
|
||
The Landing Zone module is designed to enable both lightweight and deep | ||
customizations of the VPC topology, inclusive of all associated | ||
services that are deployed to make the VPC topology compliant. In a nutshell, there are | ||
two ways the topology can be customized: | ||
1. By using Terraform input variables. The module exposes over 70 input | ||
variables that can be used to tweaks aspects of the VPC topology | ||
that is deployed. See them as "knobs" that you can turn to slightly | ||
adjust the desired VPC topology. | ||
2. By using a json definition, which enables deeper and | ||
broader types of customizations. The Landing Zone module accepts a json input in the form of a file or through a string containing a json definition. Using a json definition, you can fully | ||
customize all aspects of the topology, beyond the use of the | ||
Terraform input variables. | ||
|
||
## Defining our custom topology with a json definition | ||
|
||
In this lab, we are going to use the json-based approach to define a | ||
topology that matches the manual steps followed in lab 1 of the | ||
lab. Starting from the definition for the standard VSI landing zone pattern as a starting point, we make the following customizations: | ||
- Expose one of the VSI in the management VPC through a public floating IP -- this is our "jump box". | ||
- Add a public VPC load balancer serving public http traffic and distribiting requests to the VSIs in the workload VPC | ||
- All necessary adjustments to the network ACL and security group to accommodate inbound and outbound traffic to the management jump box (ssh access) and the workload (http). | ||
|
||
### Creating the json definition | ||
|
||
There are three ways to produce a json definition that codify the desired | ||
topology -- ranked by order of complexity: | ||
1. The first way is to use the Graphical User Inferface tool provided | ||
at | ||
<https://slz-gui.15z7evpngrsf.us-south.codeengine.appdomain.cloud/> | ||
to guide your through a step-by-step documented wizard leading to | ||
the produce a valid JSON file. The GUI tool also allows you to | ||
import an existing json file and start customizations from there. | ||
 | ||
2. The second way is to start making customization through the | ||
terraform input variable. The Landing Zone module has got one output | ||
named "config" that contains a JSON definition that includes the | ||
customizations made through the terraform input variables. From that | ||
point, you can make further customization manually or through the | ||
GUI tool mentioned above. | ||
3. The third way is to start from a copy of the json definition of one | ||
of the 4 patterns provided out-of-the-box with the Landing Zone | ||
module [here](https://github.com/terraform-ibm-modules/terraform-ibm-landing-zone/tree/main/patterns) | ||
. For example, the JSON file for the standard VSI-based Landing Zone | ||
is located under the [vsi directory](https://github.com/terraform-ibm-modules/terraform-ibm-landing-zone/blob/main/patterns/vsi/override.json). From that point, make customization to the copy of that JSON file | ||
either through the GUI or manually. | ||
|
||
### Creating the json definition | ||
|
||
In this lab, we provide the JSON file containing those customizations | ||
[here](https://github.com/IBM/infra-to-app-with-landing-zone/blob/main/custom-slz/override.tftpl) . | ||
|
||
?> _TODO_ ensure the gui is updated before the lab | ||
|
||
You may take a few moment to explore the content of the provided json definition: | ||
1. Import the json definition in the Graphical User Inferface tool provided at <https://slz-gui.15z7evpngrsf.us-south.codeengine.appdomain.cloud/>. | ||
2. Click the Import JSON button and copy paste the content of the JSON definition. | ||
 | ||
3. After import, you can use the GUI to explore the various facet of the topology using the right-hand menu. Of particular interest in the scope of the customizations are the [VPC Access control](https://slz-gui.15z7evpngrsf.us-south.codeengine.appdomain.cloud/nacls), [Security Groups](https://slz-gui.15z7evpngrsf.us-south.codeengine.appdomain.cloud/securityGroups), and [Virtual Server Instances](https://slz-gui.15z7evpngrsf.us-south.codeengine.appdomain.cloud/vsi) sections. | ||
## Two ways to customize | ||
|
||
The landing zone module is designed to enable both lightweight and deep customizations of the VPC topology, including all the services that are deployed to make the VPC topology compliant. | ||
|
||
In a nutshell, you can customize the topology in two ways: | ||
|
||
- By using Terraform input variables. | ||
|
||
The module accepts more than 70 input variables that you can use to tweak the VPC topology. Consider the input variables as "knobs" that you can turn to adjust the topology. | ||
- By using a JSON file, named `override.json` | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You can pass a string value also to the variable called There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Changed to |
||
The override file enables deeper and broader types of customizations. By using a JSON file, you can fully customize aspects of the topology beyond what you can achieve with Terraform input variables. | ||
|
||
## Defining our custom topology with a JSON definition | ||
|
||
In this lab, you use the JSON override file to define a topology that matches the manual steps that you followed in the lab 1. | ||
|
||
As a refresher, here's what you did in lab 1: | ||
|
||
- Created a VPC-topology based on the standard SLZ pattern. | ||
- Exposed one VSI in the management VPC through a public floating IP address (our "jump box"). | ||
- Exposed one VSI in the workload VPC behind a public load balancer. | ||
- Made the necessary adjustments to the network ACL and security group to accommodate inbound and outbound traffic to the management jump box and the workload. | ||
|
||
### Creating the JSON definition | ||
|
||
You can create a JSON file that codifies the topology that you want in one of three ways. The following list orders the methods from least complex to most complex: | ||
|
||
- Use the [secure landing zone wizard](https://slz-gui.15z7evpngrsf.us-south.codeengine.appdomain.cloud/) to produce a valid JSON file. | ||
|
||
The wizard also supports importing an existing JSON file and start from there. | ||
|
||
 | ||
- Customize the definition through a Terraform input variable. | ||
|
||
The landing zone module produces an output that is named `config`. The `config` output contains a JSON definition with all the customizations that are made through the Terraform input variables. You can start with this output and make more customizations, either manually or through the wizard in the previous method. | ||
- The third way is to start from a copy of the JSON definition in one of the four [patterns](https://github.com/terraform-ibm-modules/terraform-ibm-landing-zone/tree/main/patterns) that are provided with the landing zone module. | ||
|
||
For example, the JSON file for the standard VSI-based landing zone is located under the [vsi](https://github.com/terraform-ibm-modules/terraform-ibm-landing-zone/blob/main/patterns/vsi/override.json) directory. You can customize a copy of that JSON pattern file either manually or through the wizard. | ||
|
||
### Creating the JSON definition | ||
|
||
For this lab, use the customized JSON file at https://github.com/IBM/infra-to-app-with-landing-zone/blob/main/custom-slz/override.tftpl. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
shouldn't it be -
Now in lab 2, you will use automation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've used our tech writing style of keeping most things in the present tense. For example,
Feel free to change back to future if it makes more sense to the lab usage.