diff --git a/docs/README.md b/docs/README.md index cad873e..f1c133d 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,4 +1,4 @@ -# Seamless Deployment: From Provisioning to Runtime With the IBM Cloud VPC Landing Zone +# Seamless Deployment: From Provisioning to Runtime With the IBM Cloud VPC landing zone The introduction of IBM Cloud [deployable architectures](https://cloud.ibm.com/docs/secure-infrastructure-vpc?topic=secure-infrastructure-vpc-faqs) makes it easy to provision predefined architecture in no time. @@ -6,7 +6,7 @@ The introduction of IBM Cloud [deployable architectures](https://cloud.ibm.com/d In this hands-on lab, you will learn how to work with the VPC landing zone deployable architecture to accomplish these goals. -1. Create a customized VPC-based topology from the VPC Landing Zone deployable architecture. +1. Create a customized VPC-based topology from the VPC landing zone deployable architecture. 2. Deploy and expose a web application on this secure topology. For this lab, we use an Apache service as an example. 3. Share this deployable pattern with your enterprise through the IBM Cloud private catalog. @@ -18,7 +18,7 @@ Two labs are available. The two labs are independent. However, the first lab is In [Lab 1](./part1/00-objectives), you take the perspective of a cloud infrastructure engineer: -1. Use the [Landing Zone Deployable Architecture](https://cloud.ibm.com/docs/secure-infrastructure-vpc?topic=secure-infrastructure-vpc-overview) to automatically deploy a secure VPC-based topology in an IBM Cloud account. +1. Use the [landing zone deployable architecture](https://cloud.ibm.com/docs/secure-infrastructure-vpc?topic=secure-infrastructure-vpc-overview) to automatically deploy a secure VPC-based topology in an IBM Cloud account. 2. Manually customize the deployed infrastructure in the account in the following ways: a. Provide operator access through a "jump box" VSI. b. Install an Apache server in one of the workload VPCs that serves the web pages. diff --git a/docs/about/20-vpc-landing-zone.md b/docs/about/20-vpc-landing-zone.md index 29284ed..e3ed6e9 100644 --- a/docs/about/20-vpc-landing-zone.md +++ b/docs/about/20-vpc-landing-zone.md @@ -1,6 +1,6 @@ -# VPC Landing Zone +# VPC landing zone -IBM VPC Landing Zone (also referred to as "SLZ" for Secure Landing Zone) is [Infrastructure-As-Code](https://en.wikipedia.org/wiki/Infrastructure_as_code) automation that enables you to create a fully customizable VPC environment within a single region. The VPC Landing Zone is implemented in Terraform and automates the provisioning, configuring, and integration of several services that participate in the realization of a compliant VPC-based topology that is aligned with the documented [IBM Cloud for Financial Cloud Services Framework](./about/10-fs-cloud). +IBM VPC landing zone (also referred to as "SLZ" for secure landing zone) is [Infrastructure-As-Code](https://en.wikipedia.org/wiki/Infrastructure_as_code) automation that enables you to create a fully customizable VPC environment within a single region. The VPC landing zone is implemented in Terraform and automates the provisioning, configuring, and integration of several services that participate in the realization of a compliant VPC-based topology that is aligned with the documented [IBM Cloud for Financial Cloud Services Framework](./about/10-fs-cloud). The automation is available as a set of [Terraform modules on GitHub](https://github.com/terraform-ibm-modules/terraform-ibm-landing-zone). The automation creates and configures all of the resources necessary to create a secure and compliant topology: - A resource group for cloud services and for each VPC @@ -12,10 +12,10 @@ The automation is available as a set of [Terraform modules on GitHub](https://gi - Virtual Private Endpoint (VPE) for Cloud Object Storage in each VPC - A VPN gateway in the management VPC -# Landing Zone patterns +# Landing zone patterns -VPC Landing Zone comes with four fully functional patterns that follow the IBM Cloud Framework for Financial Services reference architecture: +VPC landing zone comes with four fully functional patterns that follow the IBM Cloud Framework for Financial Services reference architecture: - VPC pattern - VPC with Virtual Servers ("VSIs") – which the lab uses. diff --git a/docs/about/30-deployable-arch.md b/docs/about/30-deployable-arch.md index 01f3855..1a3d96a 100644 --- a/docs/about/30-deployable-arch.md +++ b/docs/about/30-deployable-arch.md @@ -12,10 +12,10 @@ In other words, a user can run the Terraform automation behind a deployable arch ![Deployable architecture console](../images/about-deployable-arch.png) -The Landing Zone Terraform module and patterns that are described in [🌍 VPC Landing Zone](./about/20-vpc-landing-zone.md) have a corresponding [deployable architecture](https://cloud.ibm.com/docs/secure-infrastructure-vpc?topic=secure-infrastructure-vpc-overview) in IBM Cloud. To help you learn about deployable architectures, this lab provides steps for the deployable architecture in IBM Cloud rather than by running Terraform commands against the open source GitHub version. +The landing zone Terraform module and patterns that are described in [🌍 VPC landing zone](./about/20-vpc-landing-zone.md) have a corresponding [deployable architecture](https://cloud.ibm.com/docs/secure-infrastructure-vpc?topic=secure-infrastructure-vpc-overview) in IBM Cloud. To help you learn about deployable architectures, this lab provides steps for deploying the deployable architecture in IBM Cloud rather than by running Terraform commands against the open source GitHub version. -IBM-maintained deployable architectures are just like the Landing Zone deployable architecture in these ways: +IBM-maintained deployable architectures are just like the landing zone deployable architecture in these ways: - Provide the same level of customer support as any other IBM Cloud product -- [Come with extensive documentation](https://cloud.ibm.com/docs/secure-infrastructure-vpc?topic=secure-infrastructure-vpc-overview) -- Are maintained to be current over time +- Come with extensive [documentation](https://cloud.ibm.com/docs/secure-infrastructure-vpc?topic=secure-infrastructure-vpc-overview) +- Are maintained to stay current diff --git a/docs/part1/00-objectives.md b/docs/part1/00-objectives.md index 5ccf266..fee8d13 100644 --- a/docs/part1/00-objectives.md +++ b/docs/part1/00-objectives.md @@ -2,7 +2,7 @@ In lab 1, you provision a secure VPC-based topology that is aligned with the **VSI on VPC landing zone** deployable architecture, as shown in the following diagram. -![](https://raw.githubusercontent.com/terraform-ibm-modules/terraform-ibm-landing-zone/main/reference-architectures/vsi-vsi.drawio.svg 'size=60%' ) +![VSI on VPC landing zone architecture diagram](https://raw.githubusercontent.com/terraform-ibm-modules/terraform-ibm-landing-zone/main/reference-architectures/vsi-vsi.drawio.svg 'size=60%' ) After you provision the VPC, you customize the deployed infrastructure in the following ways: @@ -23,7 +23,7 @@ Make sure that you meet the following prerequisites before you begin the lab. - An IBMid - API key with the following permissions - ?> _TODO_ review +?> _TODO_ add permissions for API key - A development computer with the following software. - [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) diff --git a/docs/part1/10-project.md b/docs/part1/10-project.md index 141b843..662eeb5 100644 --- a/docs/part1/10-project.md +++ b/docs/part1/10-project.md @@ -1,4 +1,4 @@ -# Deploying the Landing Zone VSI pattern through IBM Cloud projects +# Deploying the landing zone VSI pattern through IBM Cloud projects 1. On your computer, create an SSH key pair by issuing the following command: @@ -31,7 +31,7 @@ 1. Click **Review deployment options** on the lower right. 1. Click **Add to project**. - 1. In **Create New**, enter a name for the project. For example, "\ Landing Zone Lab". You can leave the other information as is. + 1. In **Create New**, enter a name for the project. For example, "\ landing zone lab". You can leave the other information as is. 1. Click **Add** on the lower right. 1. Configure the project diff --git a/docs/part2/00-objectives.md b/docs/part2/00-objectives.md index aa30efb..fbbb60d 100644 --- a/docs/part2/00-objectives.md +++ b/docs/part2/00-objectives.md @@ -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). \ No newline at end of file +Lab 2 assumes a basic knowledge of [Terraform](https://www.ibm.com/topics/terraform). diff --git a/docs/part2/10-customizing.md b/docs/part2/10-customizing.md index cb5e046..cb1c5da 100644 --- a/docs/part2/10-customizing.md +++ b/docs/part2/10-customizing.md @@ -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 - - 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. - ![](../images/part-2/cdbc891686d226024c1d5da0aef003a858508460.png) -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 . - 2. Click the Import JSON button and copy paste the content of the JSON definition. - ![](../images/part-2/override-gui.png) - 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 passing a JSON string value to the `override.json` variable. + + 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. + + ![screenshot of the secure landing zone wizard](../images/part-2/cdbc891686d226024c1d5da0aef003a858508460.png) +- 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. diff --git a/docs/part2/20-custom-module.md b/docs/part2/20-custom-module.md index f5c61c7..54a7503 100644 --- a/docs/part2/20-custom-module.md +++ b/docs/part2/20-custom-module.md @@ -1,78 +1,79 @@ -# Encapsulating the topology definition in a terraform module - +# Encapsulating the topology definition in a Terraform module ## Objective -In this step, you will be executing a terraform module that automates -the creation of the custom landing zone topology defined in the json -definition created in the [previous step](./10-customizing.md). - -The objective is to provide a basic terraform module that can be easily -consumed to create the custom VPC topology. See this module as a level -of abstraction simplifying consumption: consumers of the module that we -will create here do not need to understand landing zone, or even the -json file containing the custom topology definition -- they can "just" run -`terraform apply` with a minimal number of inputs to get the full custom -VPC topology deployed in their account. - -## Executing landing-zone with a json definition - -The code for this step is located in the [custom-slz](https://github.com/IBM/infra-to-app-with-landing-zone/tree/main/custom-slz) directory. The custom-slz directory contains two -important files: -1. The [override.tftpl](https://github.com/IBM/infra-to-app-with-landing-zone/blob/main/custom-slz/override.tftpl) file -- which is a copy of the json definition for our custom topology created in the previous step of this lab. -> In this lab, the file is a template file that contains the json definition, with one small addition: the file contains placeholders `${prefix}` that are replaced by an input variable at runtime to ensure that resource group names are unique in the account using the [templatefile](https://developer.hashicorp.com/terraform/language/functions/templatefile) function. This is necessary to ensure there is no clash in the resource group names from multiple attendees running the lab in the same IBM Cloud account. -2. The [main.tf](https://github.com/IBM/infra-to-app-with-landing-zone/blob/main/custom-slz/main.tf) file which contains the terraform logic calling the landing zone module with the 'right' parameters. The logic is relatively minimal as it mainly delegates the effort to the landing zone module. Two noteworthy aspects: - - a. The input named `override_json_string` takes the full json definition. In this example, the json passed to the module goes through the templatefile function first to 'inject' the prefix. It is done to ensure uniqueness of the resource group names in the account as indicated in step 1. - - b. The source is set to the standard vsi pattern and pointing to the latest version at the time this lab was written (v4.4.4). - -```hcl -module "landing_zone" { - source = "git::https://github.com/terraform-ibm-modules/terraform-ibm-landing-zone.git//patterns/vsi?ref=v4.4.4" - prefix = var.prefix - region = var.region - ibmcloud_api_key = var.ibmcloud_api_key - ssh_public_key = var.ssh_key - override_json_string = templatefile("./override.tftpl", { prefix = var.prefix }) -} -``` - -To run the terraform module on your local environment: - -1. Clone the git repository locally with - ```bash +In this step, you run a Terraform module that automates the creation of the custom landing zone topology that you defined in the JSON file in the [previous step](./10-customizing.md). + +The objective now is to provide a basic Terraform module that can be easily consumed and creates the custom VPC topology. You can consider this module as a level of abstraction that simplifies consumption. Consumers of the module do not need to understand the landing zone code or the JSON file that contains the topology definition. They can run a `terraform apply` command with a minimal number of inputs to deploy the fully customized VPC topology in their account. + +## Executing the landing zone with a JSON definition + +You can find the code for this step in the [custom-slz](https://github.com/IBM/infra-to-app-with-landing-zone/tree/main/custom-slz) directory. The directory contains two important files: +- The customized JSON file [override.tftpl](https://github.com/IBM/infra-to-app-with-landing-zone/blob/main/custom-slz/override.tftpl) file. + + This file is a copy of the JSON definition for our custom topology that you created in the previous step of this lab. The file contains `${prefix}` placeholders that are replaced by an input variable at run time by using the `templatefile` function. The placeholders ensure that resource group names are unique in the account. Unique names are necessary to ensure that the resource group names don't clash because of multiple attendees who are running the lab in the same IBM Cloud account. +- The [main.tf](https://github.com/IBM/infra-to-app-with-landing-zone/blob/main/custom-slz/main.tf) file. + + This file contains the Terraform logic that calls the landing zone module with the correct parameters. The logic is relatively minimal because it mostly delegates the effort to the landing zone module. + + Notice these two settings in the `main.tf` file: + + - The `override_json_string` input variable takes the full JSON definition. In this example, the JSON that is passed to the module through the `templatefile` function first to 'inject' the prefix. That process is done to ensure uniqueness of the resource group names in the account, as mentioned in the first item. + - The `source` is set to the standard VSI pattern and points to the version 4.4.7 (the most recent version at the time that this lab was written). + + ```hcl + module "landing_zone" { + source = "git::https://github.com/terraform-ibm-modules/terraform-ibm-landing-zone.git//patterns/vsi?ref=v4.4.7" + prefix = var.prefix + region = var.region + ibmcloud_api_key = var.ibmcloud_api_key + ssh_public_key = var.ssh_key + override_json_string = templatefile("./override.tftpl", { prefix = var.prefix }) + } + ``` + +To run the Terraform module in your local environment, follow these steps. + +1. Clone the repository locally with the following Git command: + + ```sh git clone https://github.com/IBM/infra-to-app-with-landing-zone ``` -2. Change directory into the custom-slz folder\ - ```bash +2. Change to the `custom-slz` folder + + ```sh cd infra-to-app-with-slz/custom-slz ``` -3. Create a new terraform workspace. You may replace "lab" with the - name of your choice in the command below. - ```bash +3. Create a Terraform workspace. Replace `lab` with your own name in the following command. + + ```sh terraform workspace new lab ``` -4. Generate a SSH key pair. This is the key pair that will be used to ssh to the VSIs created by this execution. -``` -ssh-keygen -t rsa -b 4096 -N '' -f ./lab2-key-tf -``` +4. Generate an SSH key pair. This key pair is used to `ssh` to the VSIs created by this execution. -5. Export the IBM Cloud API Key that will be used by terraform for the execution. See [instructions](https://cloud.ibm.com/docs/account?topic=account-userapikey&interface=ui) -``` -export TF_VAR_ibmcloud_api_key= -``` + ```sh + ssh-keygen -t rsa -b 4096 -N '' -f ./lab2-key-tf + ``` + +5. Export the IBM Cloud API key that the Terraform will use for the execution. For instructions, see [Managing user API keys](https://cloud.ibm.com/docs/account?topic=account-userapikey&interface=ui). + + ```sh + export TF_VAR_ibmcloud_api_key= + ``` 6. Generate a plan. The plan lists of resources that are going to be created. - ```bash + + ```sh terraform plan --var=region=eu-gb -var=ssh-key="$(cat ./lab2-key-tf)" -var=prefix=lab-prefix ``` -7. (Optional) Execute the module with terraform apply. -> This step may take up to 15 minutes to complete. We recommend to skip it if you are short on time. The automation will be run through the catalog onboarding in a subsequent step of this lab. - ```bash +7. (Optional) Apply the changes. + + This step might take up to 15 minutes to complete. You can skip it if you're short on time. The automation is run through the catalog onboarding in a later step of this lab. + + ```sh terraform apply --var=region=eu-gb -var=ssh-key="$(cat ./lab2-key-tf)" -var=prefix=lab-prefix - ``` \ No newline at end of file + ``` diff --git a/docs/part2/30-add-apache.md b/docs/part2/30-add-apache.md index 7658956..4c56cc3 100644 --- a/docs/part2/30-add-apache.md +++ b/docs/part2/30-add-apache.md @@ -1,21 +1,14 @@ -# Add the Apache server deployment logic in the terraform module +# Add the Apache server deployment logic in the Terraform module ## Objective -This step adds the automation to deploy an Apache Server on the three -workload virtual servers. +This step adds the automation to deploy an Apache server on the three workload virtual servers. -In order to implement this automation, we leverage the native terraform -[remote-exec](https://developer.hashicorp.com/terraform/language/resources/provisioners/remote-exec) provisioner. In short, the remote-exec provisioner connects to a -remote resource and invokes a script on that machine. +To implement this automation, we use the built-in Terraform [remote-exec](https://developer.hashicorp.com/terraform/language/resources/provisioners/remote-exec) provisioner. The remote-exec provisioner connects to a remote resource and invokes a script on that computer. -In this step, we configure the remote-exec provisioner to run a script -that installs Apache server all VSIs in the workload VPC ("worker VSIs"). The remote-exec provisioner -is configured to access the worker nodes through our management jump box -that is publicly exposed through a floating IP. The same private ssh key is used in this -example to connect to the jump box and to the worker VSIs. +We configure the remote-exec provisioner to run a script that installs the Apache server on a worker VSI. The remote-exec provisioner is configured to access the worker nodes through our management jump box that is publicly exposed. The same private SSH key is used to connect both to the jump box and to the worker VSIs. -![](../images/part-2/media/image21.png) +![Diagram of the flow through the jump box to the workload VSIs](../images/part-2/media/image21.png) ## Steps @@ -40,6 +33,6 @@ resource "null_resource" "application-install" { } ``` -The full logic is located [here](https://github.com/IBM/infra-to-app-with-landing-zone/tree/main/app-install). +You can find the full logic in the [app-install](https://github.com/IBM/infra-to-app-with-landing-zone/tree/main/app-install) directory. -[ TODO - steps] \ No newline at end of file +?> _TODO_ add steps diff --git a/docs/part2/40-catalog-onboarding.md b/docs/part2/40-catalog-onboarding.md index b12fe78..055f12c 100644 --- a/docs/part2/40-catalog-onboarding.md +++ b/docs/part2/40-catalog-onboarding.md @@ -1,232 +1,230 @@ -# Onboard the terraform module as a "Deployable Architecture" in IBM Cloud Catalog. +# Onboard the Terraform module as a deployable architecture in IBM Cloud catalog ## Objective -In this section, the lab guides you through the steps to make the automation available to end-user through the [IBM Cloud Catalog](https://cloud.ibm.com/catalog) as a Deployable Architecture. +In this step of lab 2, you make the automation available to users through the [IBM Cloud catalog](https://cloud.ibm.com/catalog) as a deployable architecture. -The end result is a **secure webapp** tile in the IBM Cloud Catalog, that end-user can click on to be guided through the execution of this Deployable Architecture. +The result is a **secure webapp** tile in the IBM Cloud catalog that guides users through the execution of this deployable architecture. ![](../images/part-2/c4a6c586954e853f8fa36d097f311cf25c71ba09.png) -## Creating a private catalog for the Deployable Architecture +## Creating a private catalog for the deployable architecture -1. Create a private catalog to hold your organization's custom - deployable architectures. +1. Create a private catalog to hold your organization's custom deployable architectures. - a. Navigate to Manage → Catalogs → [Private Catalogs](https://cloud.ibm.com/content-mgmt/catalogs) in the IBM Cloud console. + 1. Go to **Manage** > **Catalogs** > **[Private catalogs](https://cloud.ibm.com/content-mgmt/catalogs)** in the IBM Cloud console. + 1. Click **Create**. + 1. Give the catalog a name. For example, `My deployable architectures`. + 1. Click **Create**. +1. Select the catalog, and then click **Add** to add a product to the new catalog offering. - b. Click **Create.** + - Product type: **Deployable architecture**. + - Delivery method: **Terraform**. + - Repository type: **Public repository**. + - Source URL: `https://github.com/IBM/infra-to-app-with-landing-zone/releases/tag/1.0.0`. - c. Give the catalog a name, eg. "My Deployable Architectures". + This URL links to the `tar.gz` asset file that is located in the [GitHub release page](https://github.com/IBM/infra-to-app-with-landing-zone/releases/tag/1.0.0). + - Variation: **Standard**. - d. Click **Create**. + :bulb: **Tip:** A deployable architecture can have multiple variations for the user to choose from. For example, the VSI on VPC landing zone deployable architecture has two variations: "quick start" and "standard". In this lab, our deployable architecture has one variation. It's good practice to name this variation "Standard" - but you can use any name. + - Software Version: **1.0.0**. + This version is the version that is displayed to users in the catalog. The version can be any string that follows [semantic versioning conventions](https://semver.org/). It does not need to match the version in your source control management system. + - Category: **Enterprise applications**. -2. Select the catalog, and click **Add** to add a Product to the new - catalog offering. + You can select a category that matches your deployable architecture. User who browses the catalog can filter by category. +1. Click **Add product**. +1. (Optional) Change the default name for your deployable: - a. Product type: **Deployable architecture** + 1. Click **Edit**. - b. Delivery method: **Terraform** + ![](../images/part-2/e49d98bdf9d5c5fe23d2f0f3b04b2e0b271b50e4.png) - c. Repository type: **Public repository** + 1. Change the product name to one of your choice. For example, `Secure webapp`. + 1. (Optional) You can change any other details in the tile of your private catalog. For example, you can change the icon, short description, tags, or documentation URL. A preview of the catalog tile on the right side of the page updates as you make changes. - d. Source URL: `https://github.com/IBM/infra-to-app-with-landing-zone/releases/tag/1.0.0`.\ - :information_source: **Note** This URL is the direct link to the tar.gz asset file located in the [GitHub release page](https://github.com/IBM/infra-to-app-with-landing-zone/releases/tag/1.0.0). +## Specifying initial version details + +In the next few steps, you edit the information that applies to the version. - e. Variation: **Standard**. \ - :information_source: **Note**: a Deployable Architecture may have multiple variations the user may choose from. For example, the VSI landing zone deployable architecture has got two variations: "quick start" and "standard". In this lab, our deployable architecture has got only one variation. It is a good practice to name this variation "Standard" - but you are free to input any name in this field. +### Configuring the version +1. Access the version configuration pages: - f. Software Version: **1.0.0**. \ - :information_source: **Note**: this is the version shown in the tile to the end-users in the catalog tile. It can be any string following the [semantic versioning conventions](https://semver.org/) and does not necessarily need to match the version in your source control management system. + 1. In the **Version list** section, click the version that was imported (1.0.0). - g. Category: **Enterprise applications**. \ - :information_source: **Note**: You may select a category that closely matches your deployable rchitecture. The catalog can be filtered by category. + ![](../images/part-2/8189e32b5ed54528a3fe0cd0ab18af214555cc7d.png) - h. Click **Add product** +1. The **Configure version** pane is displayed: + ![](../images/part-2/media/image24.png) -3. A default name is randomly generated for your deployable architecture. To change it: + 1. Review the details in **Step 1 - Review the version details**. Click **Next**. + 1. In **Step 2**, you can configure both the Terraform runtime version to run this version of the deployable architecture and the Terraform input and output variables that are displayed to users in IBM Cloud projects. - a. Click the **edit** button - ![](../images/part-2/e49d98bdf9d5c5fe23d2f0f3b04b2e0b271b50e4.png) + Leave the Terraform runtime version as is. You do not need to override the Terraform version to use for our deployable architecture. IBM Cloud Schematics is able to pick the correct Terraform version from the `version.tf` file in the module. - b. Change the product name to one of your choice -- eg: "Secure webapp" + ```hcl + terraform { + required_version = ">= 1.3, < 1.6" + required_providers { + ibm = { + source = "IBM-Cloud/ibm" + version = "1.54.0" + } + } + } + ``` - c. (Optional) You may change any other details that will be surfaced in the "tile" of your private catalog. Eg: icon, short description, tags, documentation url. Notice the tile preview on the right-hand side of the page updating as you make changes. + 1. In the Input variables section, click **Add input variables**. -## Specifying initial version details + ![](../images/part-2/media/image25.png) + 1. Select all variables and click **Add**. We want to display all variables from our Terraform module to users in IBM Cloud projects. -In the next few steps, we edit the information specific to a given version. + ![](../images/part-2/media/image26.png) + 1. Edit some input variables: -1. To access the version configuration screens, under the **Version list** section (bottom of the screen), click on the version that was imported (1.0.0) ![](../images/part-2/8189e32b5ed54528a3fe0cd0ab18af214555cc7d.png) + By default, the type of the variable is based on the Terraform variable type (which are limited to `string`, `number`, `list`, and `map`). You can set finer-grained types for the input variables, which can help users set the input values. -2. You should be directed to a screen looking like this: - ![](../images/part-2/media/image24.png) + 1. Click the `region` input variable + 1. In the **Details** section, change the type from string to *VPC Region* -3. Screen **Configure version -- Step 1**: Review the version details, and click **Next** + ![](../images/part-2/520e1108848d01be4e7f9a8b40b36435dcecaa02.png) + 1. Complete the same steps to set the `ssh_key` variable type to type `VPC SSH Key`. -4. Screen **Configure version -- Step 2:** This screen gives the opportunity to configure (1) the terraform runtime version to execute this version of the Deployable architecture (2) the terraform input and output variables that are made visible to the end-user in IBM Cloud Projects as well as their type. + TODO: double check. Probably does not apply. - a. Leave the terraform runtime version as is -- there is no need to override the terraform version to use for our deployable architecture. IBM Cloud Schematics is able to pick the correct terraform version based on the version.tf file in our module. + Compare your entries against the following screenshot. - ``` - terraform { - required_version = ">= 1.3, < 1.6" - required_providers { - ibm = { - source = "IBM-Cloud/ibm" - version = "1.54.0" - } - } - } - ``` + ![](../images/part-2/16ac8f7add0155eacbc958df9b14489264e9574b.png) - b. Under input variables, click the **Add input variables** button - ![](../images/part-2/media/image25.png) + 1. Click **Next**. - c. Select all variables and click **Add**. We want to expose all - variables from our terraform module to end-users in IBM Cloud - Projects. - ![](../images/part-2/media/image26.png) +1. In the **Step 3** pane, you define the IAM access permissions that are needed to run the deployable architecture. This information is displayed to users of your deployable architecture tile. - d. By default, the type of the variable is based on the terraform - variable types (which is limited to string, number, list, map). - Catalog gives the possibility to set finer-grained types for the - input variables. - These finer-grained types are used in IBM Cloud - Projects to further assist the end-user to input value: - * Click the **region** input variable + The deployable architecture deploys a VPC, so users need at least editor platform access to the VPC: + 1. Click **Add +**. + 1. In service, search for **Virtual Private Cloud**. + 1. In platform access role, select **Editor**. + 1. Click **Add**. - * Under the **Details** section, change the type from string to *VPC Region* - ![](../images/part-2/520e1108848d01be4e7f9a8b40b36435dcecaa02.png) + Compare your work against the following screenshot. - * Perform the same steps to set the "ssh_key" variable type to - "VPC SSH Key" type. TODO: double check -- probably does not - apply. + ![](../images/part-2/media/image29.png) - e. At this stage, you should end up with a screen like this. Click **Next** at the bottom of the screen. - ![](../images/part-2/16ac8f7add0155eacbc958df9b14489264e9574b.png) +1. Click **Next**. -5. Screen **Configure version -- Step 3:** This screen allows you to define the IAM access requires to execute. This information is displayed to the end-users of your deployable architecture tile. - Given that the deployable architecture deploys a VPC, there is a - need for the user to have at least editor platform access to the - VPC. We indicate this: +### Adding deployable architecture details - a. Click the **Add +** button +In the **Add deployable architecture details** section, you can add architecture diagrams and other information about the deployable architecture. - b. Under service, search for **Virtual Private Cloud** +1. In the **Step 1 - Add architecture diagrams** pane, add an architecture diagram: - c. Under platform access role, select **Editor** + 1. Click the **Add architecture diagram** link - d. Click **Add**. + ![](../images/part-2/media/image30.png) - e. You should end up with a list as shown:![](../images/part-2/media/image29.png) + 1. Follow the steps to add an architecture diagram. - f. Click **Next** to go to the next main step **Add deployable architecture details** + The repository for this lab contains an architecture diagram at TODO -6. Screen: **Add deployable architecture details -- Step 1 -- add - architecture diagrams.** One or several architecture diagrams can be - made available to the user of the deployable architecture tile - though this step. + ![](../images/part-2/ee8a02736dedaaec38f6826ef5e454765563da63.png) - a. Click the "Add architecture diagram" link ![](../images/part-2/media/image30.png) +1. In the **Step 2 - add prerequisites** pane, leave the input as blank, and click **Next**. - b. Follow the steps to add an architecture diagram. The repository for this lab contains an architecture diagram. This link is: TODO ![](../images/part-2/ee8a02736dedaaec38f6826ef5e454765563da63.png) + In this step, you can identify prerequisite deployable architectures that must be deployed. However, in this lab, our module deploys the full infrastructure, and you don't need to identify other deployable architectures that are required. -7. Screen **Add deployable architecture details -- Step 2 -- add - prerequisites**. Leave input as blank, and click "Next". - :information_source: **Note**: This step allows the deployable architecture author to indicate that one or several other deployable architectures must be deployed. In this - lab, our module deploys the full infrastructure that is needed, so - there is no need to indicate to the end-user to execute any other - deployable architecture as a pre-req. +1. In the **Step 3 - Add highlights** pane, leave the list of highlights blank. -8. Screen **Add deployable architecture details -- Step 3 -- Add - highlights**. This step allows to indicate any specific highlights - of your deployable architecture. In this lab, we leave the list of - highlights blank. + In this step, you can indicate other pertinent information about your deployable architecture. -9. Screen **Add license agreements**. This step allows to surface any - license agreement that users of the deployable architecture must - accept before deploying. In this lab, we leave the license - agreements empty. +### Updating the license agreement and readme file -10. Screen **Edit readme**. By default, the `readme.md` file that is - packaged in the version is displayed to the end-users of the - deployable architecture. This step allows making change to the text - surfaced in the catalog tile. This is useful in the case where the - deployable architecture does not have access to make modification - directly to the readme file, where there is no readme file, or where - the readme file needs adjustment to cover specifics of IBM Cloud - deployable architecture integration. In this lab, we are using the - readme as is. +1. In the **Add license agreements** pane, leave the agreements empty. -11. Screen **Validate version** - to get the tile visible to other users - in your account, it must be "validated". The validation process - consists in executing successfully the terraform module in a - Schematics workspace at least once. To do so: + In this step, you can identify a license agreement that users must accept before they deploy. - a. Catalog gives the opportunity to configure the Schematics workspace used for the validation process. You may leave the existing values as is and click **Next**![](../images/part-2/708ba95b2a76860568ee6d085b47d4d7777d748b.png) +1. In the **Edit readme** pane, leave the readme file as is. - b. In **Step 2 -- Input variable** - fill out the following parameters: + By default, the `readme.md` file that is packaged in the version is displayed to users. In this step, you can change the content that is displayed. Changing the content of the readme file is useful in several situations. For example, - * `ibmcloud_api_key`: Input the API Key that was provided to you + - When the deployable architecture does not have access to make modifications directly to the readme file. + - When no readme file exists. + - When the details of the deployable architecture are different in the IBM Cloud deployable architecture integration. - * `region`: Set to eu-gb +### Validating the version - * `ssh_key`: Copy paste the ssh_key that was imported in part 1 of this lab TODO: probably need to generate a new key here to avoid clash +Before the deployable architecture is published to others to see, it is validated. The validation process attempts to execute the Terraform module in a IBM Cloud Schematics workspace at least one time successfully. - * `ssh_private_key`: Copy paste the private key created in part - 1 of this lab in [heredoc format](https://en.wikipedia.org/wiki/Here_document). +1. In the **Step 1 - Configure Schematics workspace ** pane, leave the existing values as is and click **Next**. + + ![](../images/part-2/708ba95b2a76860568ee6d085b47d4d7777d748b.png) + +1. In **Step 2 - Input variable**, specify the following parameters: + + - `ibmcloud_api_key`: Input the API key that was provided to you + - `region`: Set to eu-gb + - `ssh_key`: Copy and paste the SSH key that was imported in lab 1. TODO: probably need to generate a new key here to avoid clash + - `ssh_private_key`: Copy and paste the private key that you created in lab 1 in the [heredoc format](https://en.wikipedia.org/wiki/Here_document). ```text < + < private key in base 64 > -----END OPENSSH PRIVATE KEY----- EOT ``` - c. In **Step 3 -- Validate version**, click the **Validate** button. ![](../images/part-2/f35f2e7ea685311f9ff32b22d3ec33dc86a5cd7e.png) +1. In **Step 3 - Validate version**, click **Validate**. + + ![](../images/part-2/f35f2e7ea685311f9ff32b22d3ec33dc86a5cd7e.png) + + Validation is now in progress. The IBM Cloud catalog is running the Terraform module in a Schematics workspace. + + ![](../images/part-2/fe1c405a22514718df660e8e3ce13f96060e0065.png) - d. Validation is now in progress. Catalog is running the terraform - module in a Schematics workspace. ![](../images/part-2/fe1c405a22514718df660e8e3ce13f96060e0065.png) + If the validation completes successfully, you see a pane that looks like the following screenshot: - e. Once the validation complete, the following screen should look as - is: ![](../images/part-2/366e1c7205147143b2bf25c68e2dc30deed8679c.png) - :bulb: **Tip:** In the case where there are validation issues, you may view and - follow the full terraform logs in IBM Cloud Schematics through the - **View logs** link. + ![](../images/part-2/366e1c7205147143b2bf25c68e2dc30deed8679c.png) -12. Screen **Review cost.** The cost displayed in this screen are based - on the resources created in the validation step. You may review the - estimate and click **Next**. + :bulb: **Tip:** If you have issues with validation, click the **View logs** link to examine the full Terraform logs in IBM Cloud Schematics. -13. Screen **Manage compliance**. This step enables you to claim - compliance to specific controls or set of controls. The claims are - made against controls that are recorded in [IBM Cloud Security and Compliance Center](https://www.ibm.com/cloud/security-and-compliance-center) (SCC) in [pre-defined - profiles](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-predefined-profiles). - :information_source: **Note**: To further support your claim, you can attach the result of a Security and Compliance Center scan against the infrastructure created from your Deployable Architecture. The result of the scan will be surfaced to the consumer of your Deployable architecture. In this lab, we are not going to make any claim for our Deployable Architecture. +### Reviewing cost, compliance, and requirements -14. Screen **Review Requirements**. This screen gives a summary of any - requirement. ![](../images/part-2/eb92cfbd40e4d346943f162d58a9c509f2262efc.png) - Click **Ready to share** and confirm the choice in the popup. +1. In the **Review cost** pane, review the cost estimate. The costs are based on the resources that are created in the validation step. +1. Click **Next**. +1. In the **Manage compliance** pane, leave everything as is and click **Next**. -15. In order to share the Deployable Architecture with other users in - your private catalog: + The compliance step supports your claiming compliance with specific controls or a set of controls. The claims are made against controls that are recorded in [IBM Cloud Security and Compliance Center](https://www.ibm.com/cloud/security-and-compliance-center) in [predefined profiles](https://cloud.ibm.com/docs/security-compliance?topic=security-compliance-predefined-profiles). - a. Go to the Deployable Architecture page for the Secure webapp. At this point the state of the version 1.0.0 should be marked as **Ready**. ![](../images/part-2/8ede5141765f7fc8fc5d8f1c669613227075a83c.png) + :information_source: **Note**: To further support your claim, you can attach the result of a Security and Compliance Center scan against the infrastructure that is created from your deployable architecture. The result of the scan is available to users of your deployable architecture. - b. Under the **Actions\...** button (top right), select **Share** ![](../images/part-2/ffbd5d3eb533623f2b7e3196d9947c898928fbbf.png) + In this lab, we don't make any claims for our deployable architecture. - c. Select **Share to this account**, and click the **Share** button at the bottom of the screen. ![](../images/part-2/8d1be5e148980da96710b4ede30117ae9babd529.png) - :information_source: **Note**: There is also the possibility to share with other - accounts within the same [IBM Cloud enterprise](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-what-is-enterprise&interface=ui) - this is the most common way to share Deployable Architecture across accounts for an organization, company, ISV. +1. Review the details in the **Review Requirements** pane, and then click **Ready to share**. Confirm your choice. + ![](../images/part-2/eb92cfbd40e4d346943f162d58a9c509f2262efc.png) + +### Sharing your deployable architecture + +To share the deployable architecture with other users in your private catalog, following these steps. + +1. Go to the deployable architecture page for the Secure webapp. Make sure that state of the version 1.0.0 is marked as `Ready`. + + ![](../images/part-2/8ede5141765f7fc8fc5d8f1c669613227075a83c.png) +1. Click **Actions...** and select **Share**. + + ![](../images/part-2/ffbd5d3eb533623f2b7e3196d9947c898928fbbf.png) +1. Select **Share to this account**, and click **Share**. + + ![](../images/part-2/8d1be5e148980da96710b4ede30117ae9babd529.png) + + +You can also share the deployable architecture with other accounts in the same [IBM Cloud enterprise](https://cloud.ibm.com/docs/secure-enterprise?topic=secure-enterprise-what-is-enterprise&interface=ui). This method is the most common way to share deployable architectures across accounts for an organization, company, or ISV. + +The secure webapp deployable architecture is available to any user in the account. Your users can find it by searching directly in the search box in the IBM Cloud header. -At this stage, the secure webapp Deployable Architecture is available to -any user in the account. Users can find it by searching directly in the -search box in the IBM Cloud header: ![](../images/part-2/72a9d91f4543d58261951b90512784e62d4df141.png) -It is also visible in the [catalog](https://cloud.ibm.com/catalog) page. ![](../images/part-2/c4a6c586954e853f8fa36d097f311cf25c71ba09.png) \ No newline at end of file +The deployable architecture is also displayed in the [catalog](https://cloud.ibm.com/catalog) page. + +![](../images/part-2/c4a6c586954e853f8fa36d097f311cf25c71ba09.png) diff --git a/docs/part2/50-going-further.md b/docs/part2/50-going-further.md index c46f6f1..7543def 100644 --- a/docs/part2/50-going-further.md +++ b/docs/part2/50-going-further.md @@ -1,46 +1,27 @@ -# Going further... +# Going further ## Automating onboarding of new versions to catalog -This lab focuses on onboarding the deployable architecture through the -IBM Cloud Catalog UI as a learning exercise. - -In order to scale, especially to support the full lifecycle as new -versions of the deployable architecture are produced, it is common to -automate the catalog onboarding steps as opposed to going through the -UI. - -The accompanying git repository contains starter scripts that can be -leveraged to build a pipeline that automatically pushes new version of a -deployable architecture from GitHub or GitLab to the IBM Cloud Catalog --- inclusive of triggering all of the validation steps. The starter kits -are provided as GitHub action and tekton toolchain located at \[TODO: -add link to automation folder in our repo \] - -## Leveraging curated building blocks for your Deployable Architecture - -The public organization -contains curated terraform modules that can be used as base building -blocks in your solution to provision and configure some of the most -common IBM Cloud service. The modules are designed to cover the most -common uses cases, as well as providing guidance and pre-wired -secure-by-default configuration (typically under the profiles/fscloud -directory in each module repository). - -See in particular this list \[TODO -- add link\] which contains the -modules that are actively maintained, supported and kept current by the -IBM Cloud development organization. - -Whenever you have a need to create some IBM Cloud services in your -solution, strongly consider using the curated modules as opposed to the -IBM Cloud terraform provider resources directly. The modules are higher -level, and will make you gain time, while getting the assurance that the -configuration is tested and maintained by IBM. +This lab focuses on onboarding the deployable architecture through the IBM Cloud catalog UI as a learning exercise. + +It can be tedious to use the catalog UI to support the lifecycle of several deployable architectures as new versions are produced. You can automate the catalog onboarding steps with these starter scripts in the accompanying Git repository. The scripts build a pipeline that pushes new versions of a deployable architecture from GitHub or GitLab to the IBM Cloud catalog and trigger the catalog validation. The starter scripts are use GitHub actions and the tekton toolchain and are available at + +?> _TODO_ add link to automation folder in our repo + +## Using curated building blocks for your deployable architecture + +The [IBM Cloud Terraform modules](https://github.com/terraform-ibm-modules) GitHub organization contains curated Terraform modules that you can use as building blocks in your solution to provision and configure some of the most common IBM Cloud services. The modules are designed to cover the most common uses cases and provide guidance and secure-by-default configurations (typically in the `profiles/fscloud` directory of the module). + +The following list contains the modules that are actively maintained, supported, and kept current by IBM Cloud. + +?> _TODO_ add link + +If you need to create some IBM Cloud services in your solution, consider using these curated modules rather than coding against the IBM Cloud Terraform provider resources directly. The modules are higher level and can save you time, and they provide assurance that the configuration is tested and maintained by IBM. ## Best practices to implement deployable architectures -Recommendations and best practices to implement quality terraform modules is available on the [terraform-ibm-modules](https://terraform-ibm-modules.github.io/documentation/#/implementation-guidelines) organization. A module template is also available [here](https://github.com/terraform-ibm-modules/terraform-ibm-module-template) that can be used to quickly get started with best practices. +For recommendations and best practices about implementing quality Terraform modules, see the [terraform-ibm-modules](https://terraform-ibm-modules.github.io/documentation/#/implementation-guidelines) documentation. A [module template](https://github.com/terraform-ibm-modules/terraform-ibm-module-template) is also available that you can use to get started quickly creating your own module. -## Making a Deployable Architecture available in the IBM Cloud public catalog. +## Making a deployable architecture available in the IBM Cloud public catalog. -If you are a partner or vendor interested in making available a Deployable Architecture to all users in the Public IBM Cloud Catalog - see the following [details](https://cloud.ibm.com/docs/sell?topic=sell-selling-clouds). +If you are a partner or vendor that is interested in making a deployable architecture available in the public IBM Cloud catalog, see [Selling on IBM Cloud](https://cloud.ibm.com/docs/sell?topic=sell-selling-clouds). diff --git a/docs/sidebar.md b/docs/sidebar.md index 38d21e7..e1d0a7d 100644 --- a/docs/sidebar.md +++ b/docs/sidebar.md @@ -1,10 +1,10 @@ - [🌐 Introduction](README.md) - [🏢 IBM Cloud for Financial Services](./about/10-fs-cloud.md) - - [🌍 VPC landing zone](./about/20-vpc-landing-zone.md) + - [🌍 VPC Landing Zone](./about/20-vpc-landing-zone.md) - [🏗️ Deployable architectures](./about/30-deployable-arch) - [📚 IBM Cloud projects](./about/40-projects.md) - [📂 Lab 1 - End-to-end deployment](./part1/00-objectives.md) - - [🚀 Deploy Landing Zone VSI pattern](./part1/10-project.md) + - [🚀 Deploy the landing zone VSI pattern](./part1/10-project.md) - [👤 Operator Access](./part1/20-operator-access.md) - [🌐 Install Apache server](./part1/30-apache-server.md) - [🌐 Expose a web application](./part1/40-expose-web-app.md)