diff --git a/app-install/main.tf b/app-install/main.tf index 04c314e..e501326 100644 --- a/app-install/main.tf +++ b/app-install/main.tf @@ -26,6 +26,7 @@ resource "null_resource" "application-install" { provisioner "remote-exec" { inline = [ + "apt-get update", "apt-get install apache2 -y" ] } diff --git a/docs/README.md b/docs/README.md index 2c0a915..f1c133d 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,18 +1,30 @@ -# Seamless App Deployment with IBM Cloud's Secure Landing Zone +# Seamless Deployment: From Provisioning to Runtime With the IBM Cloud VPC landing zone -With the release of IBM Cloud Deployable Architectures, it is easy to provision an exisiting pre-defined architecture or customize and import. +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. -In this hands-on lab, you will learn to: +## 📖 What you will learn -1. Create a customized VPC-based topology using the VPC Landing Zone Deployable Architecture -2. Deploy and expose a web application on top of this secure topology. For this lab, we will use an Apache service as an example. -3. Share this deployable pattern with your enterprise through the IBM Cloud Private Catalog +In this hands-on lab, you will learn how to work with the VPC landing zone deployable architecture to accomplish these goals. -The objective of this lab is split into two distinct parts. The first part is built as a stepping stone for the second part. +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. -- Part 1 shows how the end-to-end steps to deploy a sample web application on top of a secure VPC-topology in your own account. - - The secure VPC-based topology will be deployed using the Landing Zone Deployable Architecture. - - Operator access will be provided through a manually deployed jump box VSI - - An Apache server will be deployed in a secure VSI workload VPC - - The web application will be exposed for outside access. -- Part 2 shows how to automate the manual steps in Part 1, and then, how to package, and share the automation as a “Deployable Architecture” with other user through a private IBM Cloud Catalog +The lab also introduces some concepts and background to help you to better get the "bigger" picture at the beginning. However, the hands-on steps are designed to be independent from the concepts and background information. + +## Lab structure + +Two labs are available. The two labs are independent. However, the first lab is a stepping stone in term of knowledge to the second lab. + +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. +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. + c. Expose the web pages that are served by the Apache server through a public VPC load balancer. + +In [Lab 2](./part2/00-objectives), you are a DevOps/automation engineer: + +1. Automate all the manual steps in lab 1. +2. Package, and share the automation with other users as a **Deployable architecture** through a private IBM Cloud catalog. This packaging in a private catalog helps specific users to find and consume your automation. diff --git a/docs/about/10-fs-cloud.md b/docs/about/10-fs-cloud.md index 5996fb8..9c1583b 100644 --- a/docs/about/10-fs-cloud.md +++ b/docs/about/10-fs-cloud.md @@ -1,25 +1,9 @@ -# VPC Landing Zone +# IBM Cloud for Financial Cloud Services Framework -IBM VPC Landing Zone (“SLZ”) is a set of [Infrastructure-As-Code](https://en.wikipedia.org/wiki/Infrastructure_as_code) automation that enables creating 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 participates in the realization of a compliant VPC-based topology: +IBM Cloud Framework for Financial Services provides comprehensive and detailed guidance around regulatory compliance, security, and resiliency to help address the needs of enterprises both during initial deployment and with ongoing operations. For more information, see [Getting started with IBM Cloud for Financial Services](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-about). -- A resource group for cloud services and for each VPC. -- Cloud Object Storage instances for flow logs and Activity Tracker -- Encryption keys in either a Key Protect or Hyper Protect Crypto Services instance -- A management and workload VPC connected by a transit gateway -- A flow log collector for each VPC -- All necessary networking rules to allow communication. -- Virtual Private Endpoint (VPE) for Cloud Object Storage in each VPC -- A VPN gateway in the management VPC +The framework was initially based on the needs of financial institutions, as its name indicates. However, it can be used as a compliance and security starting point and baseline for most industries. -[Available VPC Landing Zone terraform modules](https://github.com/terraform-ibm-modules/terraform-ibm-landing-zone) - -VPC Landing Zone comes with four fully functional patterns that are strictly following the IBM Cloud Financial Services reference architecture: - -- VPC pattern -- VPC with Virtual Servers (“VSIs”) – which the lab will use. -- VPC with OpenShift -- VPC with VSIs and OpenShift (“mixed”) pattern. - -Each of the patterns can be used as a starting point to create your own customizable VPC-based topology that matches your enterprise or customer exact needs. +The framework provides secure [VPC reference architectures](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-about) that meet a number of regulatory controls. ![VPC reference architecture](../images/about-fs-cloud.png) diff --git a/docs/about/20-vpc-landing-zone.md b/docs/about/20-vpc-landing-zone.md index a388bc0..e3ed6e9 100644 --- a/docs/about/20-vpc-landing-zone.md +++ b/docs/about/20-vpc-landing-zone.md @@ -1,9 +1,29 @@ -# IBM Cloud for Financial Cloud Services Framework +# VPC landing zone -The IBM Cloud Financial Cloud Services Framework provides comprehensive and detailed guidance to help address the needs of enterprises with regulatory compliance, security, and resiliency during the initial deployment phase and with ongoing operations. +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). -Whilst the framework was initially based on the needs of financial institutions, as its name indicates, it can be used as a starting point and baseline for meeting compliance and security for most industries. +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 +- Cloud Object Storage instances for flow logs and Activity Tracker (access and audit logs) +- Encryption keys in either a Key Protect or Hyper Protect Crypto Services instance +- A management and workload VPC connected by a transit gateway +- A flow log collector for each VPC +- All necessary networking rules to allow communication. +- Virtual Private Endpoint (VPE) for Cloud Object Storage in each VPC +- A VPN gateway in the management VPC -[Getting started with IBM Cloud for Financial Services](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-about) +# Landing zone patterns -The framework provides secure [VPC reference architectures](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-about) meeting with a number of regulatory controls. + +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. +- VPC with Red Hat OpenShift ("ROKS") +- VPC with VSIs and Red Hat OpenShift ("mixed") pattern. + +| VPC pattern | Virtual server pattern | Red Hat OpenShift pattern | Mixed pattern | +| ------------------------------ | -------------------------------- | -------------------------------- | ---------------------------------- | +| [![VPC](https://raw.githubusercontent.com/terraform-ibm-modules/terraform-ibm-landing-zone/main/reference-architectures/vpc.drawio.svg)](https://github.com/terraform-ibm-modules/terraform-ibm-landing-zone/blob/main/patterns/vpc/README.md) | [![VSI](https://raw.githubusercontent.com/terraform-ibm-modules/terraform-ibm-landing-zone/main/reference-architectures/vsi-vsi.drawio.svg)](https://github.com/terraform-ibm-modules/terraform-ibm-landing-zone/blob/main/patterns/vsi/README.md) | [![ROKS](https://raw.githubusercontent.com/terraform-ibm-modules/terraform-ibm-landing-zone/main/reference-architectures/roks.drawio.svg)](https://github.com/terraform-ibm-modules/terraform-ibm-landing-zone/blob/main/patterns/roks/README.md) | [![Mixed](https://raw.githubusercontent.com/terraform-ibm-modules/terraform-ibm-landing-zone/main/.docs/images/mixed.png)](https://github.com/terraform-ibm-modules/terraform-ibm-landing-zone/blob/main/patterns/mixed/README.md) | + +You can use any pattern as a starting point to create a customizable VPC-based topology that supports your customer needs or the needs of your enterprise. diff --git a/docs/about/30-deployable-arch.md b/docs/about/30-deployable-arch.md index 4ca16a2..1a3d96a 100644 --- a/docs/about/30-deployable-arch.md +++ b/docs/about/30-deployable-arch.md @@ -1,21 +1,21 @@ -# Deployable Architecture +# Deployable architecture -“Deployable Architecture” is officially defined as “Cloud automation for deploying a common architectural pattern that combines one or more cloud resources that is designed for easy deployment, scalability, and modularity.” +A deployable architecture is defined as "Cloud automation for deploying a common architectural pattern that combines one or more cloud resources that is designed for easy deployment, scalability, and modularity. -More specifically, and concretely, from a technical perspective, “Deployable Architectures” are essentially terraform modules that are fully integrated into the IBM Cloud experience. Deployable Architecture are: +From a technical perspective, deployable architectures are essentially Terraform modules that are fully integrated into the IBM Cloud experience. Deployable architectures have these characteristics: -- Discoverable and available through the IBM Cloud Catalog (and through IBM Cloud search) -- Fully integrated in IBM Cloud Projects and Schematics. +- Discoverable and available through the IBM Cloud catalog (and through IBM Cloud search) +- Fully integrated in IBM Cloud projects and Schematics - Integrated with [IBM Cloud Risk Analyzer](https://cloud.ibm.com/docs/code-risk-analyzer-cli-plugin?topic=code-risk-analyzer-cli-plugin-cra-cli-plugin#terraform-command) -In other words, it is possible for an end-user to execute the terraform automation behind a “Deployable Architecture” just from a few clicks and inputs in the IBM Cloud console. +In other words, a user can run the Terraform automation behind a deployable architecture just from a few clicks and inputs in the IBM Cloud console. -![Deployable Architecture console](../images/about-deployable-arch.png) +![Deployable architecture console](../images/about-deployable-arch.png) -The Landing Zone terraform module and patterns described just above have a corresponding [Deployable Architecture](https://cloud.ibm.com/docs/secure-infrastructure-vpc?topic=secure-infrastructure-vpc-overview) in IBM Cloud. In this lab, the Secure Landing Zone is consumed through the Deployable Architecture experience for ease of use, rather than using the terraform CLI 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, like the Landing Zone Deployable Architecture: +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 and remains 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/about/40-projects.md b/docs/about/40-projects.md index 28c3333..4ad30f9 100644 --- a/docs/about/40-projects.md +++ b/docs/about/40-projects.md @@ -1,18 +1,19 @@ -# IBM Cloud Projects +# IBM Cloud projects -IBM Cloud Projects make it easy to manage Infrastructure-As-Code deployments across accounts, collaborate with team members, and maintain compliance. +IBM Cloud projects make it easy to manage Infrastructure-As-Code (IaC) deployments across accounts, collaborate with team members, and maintain compliance. -At its core, an IBM Cloud Project is made up of a collection of configurations that are used to manage related Infrastructure as Code (IaC) deployments (and associated resources) across accounts. +At its core, an IBM Cloud project is made up of a collection of configurations that are used to manage related Infrastructure as Code (IaC) deployments (and associated resources) across accounts. -As a concrete example, let’s imagine the scenario of a SRE team responsible for setting up the infrastructure supporting the web application. That SRE team wants to follow best practices and deploy the following environments, all based on the same Deployable Architecture template (but with slight configuration differences for each environment): +For example, let’s imagine the scenario of a SRE team that is responsible for setting up the infrastructure that supports the web application. That SRE team wants to follow best practices and deploy the following environments, which are based on the same deployable architecture template (but with slight configuration differences for each environment): -1. A development environment – with scaled down compute resources and no audit event tracking. -2. A staging environment – as close as possible to the production environment -3. 2 production environments: one in America and another one in Europe. +1. A development environment: with scaled down compute resources and no audit event tracking. +2. A staging environment: as close as possible to the production environment +3. Two production environments: one in North America and another one in Europe. -That SRE team can group configurations, and thus centralize the governance, for the 4 different environments in one single Project. +That SRE team can group configurations, and thus centralize the governance and supervision, for the four different environments in one single Project. -Beyond the core configuration grouping capability, IBM Cloud Projects is designed with an IaC and a compliance-first approach. Projects also seemingly integrate with IBM Cloud Schematics to deploy, update, and manage the resources created by the IaC automation. -Each project also includes tools to scan for potentially harmful resource changes, compliance, security, and cost, as well as tracking configuration versioning and governance. +Beyond the core configuration grouping capability, IBM Cloud projects is designed with an IaC and a compliance-first approach. Projects also seemingly integrates with IBM Cloud Schematics to deploy, update, and manage the resources that are created by the IaC automation. -![IBM Cloud Projects](../about/40-projects.md) +Each project also includes tools to scan for potentially harmful resource changes, compliance, security, and cost issues, and to track configuration versioning and governance. + +![IBM Cloud projects](../images/about-projects.png) diff --git a/docs/cover.md b/docs/cover.md index d887025..872f3a6 100644 --- a/docs/cover.md +++ b/docs/cover.md @@ -1,7 +1,7 @@ -> Seamless App Deployment with
-> IBM Cloud's Secure Landing Zone +> Seamless Deployment: From Provisioning to Runtime
+> with IBM Cloud VPC landing zone _Session 2448_ diff --git a/docs/images/favicon.svg b/docs/images/favicon.svg index 4f05647..7c8f876 100644 --- a/docs/images/favicon.svg +++ b/docs/images/favicon.svg @@ -1 +1 @@ - + diff --git a/docs/images/part-1/10-configuration.png b/docs/images/part-1/10-configuration.png new file mode 100644 index 0000000..6b6cfe9 Binary files /dev/null and b/docs/images/part-1/10-configuration.png differ diff --git a/docs/images/part-1/10-deployment.png b/docs/images/part-1/10-deployment.png new file mode 100644 index 0000000..23c2c1c Binary files /dev/null and b/docs/images/part-1/10-deployment.png differ diff --git a/docs/images/part-1/10-deployment.png:Zone.Identifier b/docs/images/part-1/10-deployment.png:Zone.Identifier new file mode 100644 index 0000000..2dac2bc --- /dev/null +++ b/docs/images/part-1/10-deployment.png:Zone.Identifier @@ -0,0 +1,3 @@ +[ZoneTransfer] +LastWriterPackageFamilyName=Microsoft.MSPaint_8wekyb3d8bbwe +ZoneId=3 diff --git a/docs/images/part-1/10-overview-page.png b/docs/images/part-1/10-overview-page.png new file mode 100644 index 0000000..c68f936 Binary files /dev/null and b/docs/images/part-1/10-overview-page.png differ diff --git a/docs/images/part-1/10-validation.png b/docs/images/part-1/10-validation.png new file mode 100644 index 0000000..8d91edc Binary files /dev/null and b/docs/images/part-1/10-validation.png differ diff --git a/docs/images/part-1/20-floating-ip.png b/docs/images/part-1/20-floating-ip.png new file mode 100644 index 0000000..616f87a Binary files /dev/null and b/docs/images/part-1/20-floating-ip.png differ diff --git a/docs/images/part-1/20-network-int-pencil.png b/docs/images/part-1/20-network-int-pencil.png new file mode 100644 index 0000000..624bed4 Binary files /dev/null and b/docs/images/part-1/20-network-int-pencil.png differ diff --git a/docs/images/part-1/20-ssh-acl-inbound.png b/docs/images/part-1/20-ssh-acl-inbound.png new file mode 100644 index 0000000..97ff07d Binary files /dev/null and b/docs/images/part-1/20-ssh-acl-inbound.png differ diff --git a/docs/images/part-1/20-ssh-acl-outbound.png b/docs/images/part-1/20-ssh-acl-outbound.png new file mode 100644 index 0000000..5a631ff Binary files /dev/null and b/docs/images/part-1/20-ssh-acl-outbound.png differ diff --git a/docs/images/part-1/20-ssh-sg.png b/docs/images/part-1/20-ssh-sg.png new file mode 100644 index 0000000..b4d9db2 Binary files /dev/null and b/docs/images/part-1/20-ssh-sg.png differ diff --git a/docs/images/part-1/30-mgmt-ssh-acl-inbound.png b/docs/images/part-1/30-mgmt-ssh-acl-inbound.png new file mode 100644 index 0000000..89b9521 Binary files /dev/null and b/docs/images/part-1/30-mgmt-ssh-acl-inbound.png differ diff --git a/docs/images/part-1/30-mgmt-ssh-acl-outbound.png b/docs/images/part-1/30-mgmt-ssh-acl-outbound.png new file mode 100644 index 0000000..c8b4dbe Binary files /dev/null and b/docs/images/part-1/30-mgmt-ssh-acl-outbound.png differ diff --git a/docs/images/part-1/30-private-ip.png b/docs/images/part-1/30-private-ip.png new file mode 100644 index 0000000..5119780 Binary files /dev/null and b/docs/images/part-1/30-private-ip.png differ diff --git a/docs/images/part-1/30-workload-ssh-acl-inbound.png b/docs/images/part-1/30-workload-ssh-acl-inbound.png new file mode 100644 index 0000000..7e9e7dc Binary files /dev/null and b/docs/images/part-1/30-workload-ssh-acl-inbound.png differ diff --git a/docs/images/part-1/30-workload-ssh-acl-outbound.png b/docs/images/part-1/30-workload-ssh-acl-outbound.png new file mode 100644 index 0000000..4e54f15 Binary files /dev/null and b/docs/images/part-1/30-workload-ssh-acl-outbound.png differ diff --git a/docs/images/part-1/40-acl-inbound.png b/docs/images/part-1/40-acl-inbound.png new file mode 100644 index 0000000..0986589 Binary files /dev/null and b/docs/images/part-1/40-acl-inbound.png differ diff --git a/docs/images/part-1/40-acl-outbound.png b/docs/images/part-1/40-acl-outbound.png new file mode 100644 index 0000000..be0909b Binary files /dev/null and b/docs/images/part-1/40-acl-outbound.png differ diff --git a/docs/images/part-1/40-sg.png b/docs/images/part-1/40-sg.png new file mode 100644 index 0000000..afd35b5 Binary files /dev/null and b/docs/images/part-1/40-sg.png differ diff --git a/docs/images/part-1/50-c2s.png b/docs/images/part-1/50-c2s.png new file mode 100644 index 0000000..fa8398e Binary files /dev/null and b/docs/images/part-1/50-c2s.png differ diff --git a/docs/images/part-2/16ac8f7add0155eacbc958df9b14489264e9574b.png b/docs/images/part-2/16ac8f7add0155eacbc958df9b14489264e9574b.png new file mode 100644 index 0000000..a2220c7 Binary files /dev/null and b/docs/images/part-2/16ac8f7add0155eacbc958df9b14489264e9574b.png differ diff --git a/docs/images/part-2/366e1c7205147143b2bf25c68e2dc30deed8679c.png b/docs/images/part-2/366e1c7205147143b2bf25c68e2dc30deed8679c.png new file mode 100644 index 0000000..45b0c31 Binary files /dev/null and b/docs/images/part-2/366e1c7205147143b2bf25c68e2dc30deed8679c.png differ diff --git a/docs/images/part-2/520e1108848d01be4e7f9a8b40b36435dcecaa02.png b/docs/images/part-2/520e1108848d01be4e7f9a8b40b36435dcecaa02.png new file mode 100644 index 0000000..a80bc3b Binary files /dev/null and b/docs/images/part-2/520e1108848d01be4e7f9a8b40b36435dcecaa02.png differ diff --git a/docs/images/part-2/708ba95b2a76860568ee6d085b47d4d7777d748b.png b/docs/images/part-2/708ba95b2a76860568ee6d085b47d4d7777d748b.png new file mode 100644 index 0000000..27dbf46 Binary files /dev/null and b/docs/images/part-2/708ba95b2a76860568ee6d085b47d4d7777d748b.png differ diff --git a/docs/images/part-2/72a9d91f4543d58261951b90512784e62d4df141.png b/docs/images/part-2/72a9d91f4543d58261951b90512784e62d4df141.png new file mode 100644 index 0000000..fb61a36 Binary files /dev/null and b/docs/images/part-2/72a9d91f4543d58261951b90512784e62d4df141.png differ diff --git a/docs/images/part-2/8189e32b5ed54528a3fe0cd0ab18af214555cc7d.png b/docs/images/part-2/8189e32b5ed54528a3fe0cd0ab18af214555cc7d.png new file mode 100644 index 0000000..ee52113 Binary files /dev/null and b/docs/images/part-2/8189e32b5ed54528a3fe0cd0ab18af214555cc7d.png differ diff --git a/docs/images/part-2/8d1be5e148980da96710b4ede30117ae9babd529.png b/docs/images/part-2/8d1be5e148980da96710b4ede30117ae9babd529.png new file mode 100644 index 0000000..c48b61f Binary files /dev/null and b/docs/images/part-2/8d1be5e148980da96710b4ede30117ae9babd529.png differ diff --git a/docs/images/part-2/8ede5141765f7fc8fc5d8f1c669613227075a83c.png b/docs/images/part-2/8ede5141765f7fc8fc5d8f1c669613227075a83c.png new file mode 100644 index 0000000..670fe3a Binary files /dev/null and b/docs/images/part-2/8ede5141765f7fc8fc5d8f1c669613227075a83c.png differ diff --git a/docs/images/part-2/c4a6c586954e853f8fa36d097f311cf25c71ba09.png b/docs/images/part-2/c4a6c586954e853f8fa36d097f311cf25c71ba09.png new file mode 100644 index 0000000..4e90338 Binary files /dev/null and b/docs/images/part-2/c4a6c586954e853f8fa36d097f311cf25c71ba09.png differ diff --git a/docs/images/part-2/cdbc891686d226024c1d5da0aef003a858508460.png b/docs/images/part-2/cdbc891686d226024c1d5da0aef003a858508460.png new file mode 100644 index 0000000..2c759d9 Binary files /dev/null and b/docs/images/part-2/cdbc891686d226024c1d5da0aef003a858508460.png differ diff --git a/docs/images/part-2/e49d98bdf9d5c5fe23d2f0f3b04b2e0b271b50e4.png b/docs/images/part-2/e49d98bdf9d5c5fe23d2f0f3b04b2e0b271b50e4.png new file mode 100644 index 0000000..87c61ad Binary files /dev/null and b/docs/images/part-2/e49d98bdf9d5c5fe23d2f0f3b04b2e0b271b50e4.png differ diff --git a/docs/images/part-2/eb92cfbd40e4d346943f162d58a9c509f2262efc.png b/docs/images/part-2/eb92cfbd40e4d346943f162d58a9c509f2262efc.png new file mode 100644 index 0000000..f69cac0 Binary files /dev/null and b/docs/images/part-2/eb92cfbd40e4d346943f162d58a9c509f2262efc.png differ diff --git a/docs/images/part-2/ee8a02736dedaaec38f6826ef5e454765563da63.png b/docs/images/part-2/ee8a02736dedaaec38f6826ef5e454765563da63.png new file mode 100644 index 0000000..bf44cdd Binary files /dev/null and b/docs/images/part-2/ee8a02736dedaaec38f6826ef5e454765563da63.png differ diff --git a/docs/images/part-2/ef502cb9edd49d7f1c226268ea4099d1d21ee566.png b/docs/images/part-2/ef502cb9edd49d7f1c226268ea4099d1d21ee566.png new file mode 100644 index 0000000..15b1765 Binary files /dev/null and b/docs/images/part-2/ef502cb9edd49d7f1c226268ea4099d1d21ee566.png differ diff --git a/docs/images/part-2/f35f2e7ea685311f9ff32b22d3ec33dc86a5cd7e.png b/docs/images/part-2/f35f2e7ea685311f9ff32b22d3ec33dc86a5cd7e.png new file mode 100644 index 0000000..b146158 Binary files /dev/null and b/docs/images/part-2/f35f2e7ea685311f9ff32b22d3ec33dc86a5cd7e.png differ diff --git a/docs/images/part-2/fe1c405a22514718df660e8e3ce13f96060e0065.png b/docs/images/part-2/fe1c405a22514718df660e8e3ce13f96060e0065.png new file mode 100644 index 0000000..466d49c Binary files /dev/null and b/docs/images/part-2/fe1c405a22514718df660e8e3ce13f96060e0065.png differ diff --git a/docs/images/part-2/ffbd5d3eb533623f2b7e3196d9947c898928fbbf.png b/docs/images/part-2/ffbd5d3eb533623f2b7e3196d9947c898928fbbf.png new file mode 100644 index 0000000..95e857d Binary files /dev/null and b/docs/images/part-2/ffbd5d3eb533623f2b7e3196d9947c898928fbbf.png differ diff --git a/docs/images/part-2/media/image1.jpg b/docs/images/part-2/media/image1.jpg new file mode 100644 index 0000000..f6f51a9 Binary files /dev/null and b/docs/images/part-2/media/image1.jpg differ diff --git a/docs/images/part-2/media/image10.png b/docs/images/part-2/media/image10.png new file mode 100644 index 0000000..f037f73 Binary files /dev/null and b/docs/images/part-2/media/image10.png differ diff --git a/docs/images/part-2/media/image11.png b/docs/images/part-2/media/image11.png new file mode 100644 index 0000000..3fbbee1 Binary files /dev/null and b/docs/images/part-2/media/image11.png differ diff --git a/docs/images/part-2/media/image12.png b/docs/images/part-2/media/image12.png new file mode 100644 index 0000000..2efb7f5 Binary files /dev/null and b/docs/images/part-2/media/image12.png differ diff --git a/docs/images/part-2/media/image13.png b/docs/images/part-2/media/image13.png new file mode 100644 index 0000000..2308d8b Binary files /dev/null and b/docs/images/part-2/media/image13.png differ diff --git a/docs/images/part-2/media/image14.png b/docs/images/part-2/media/image14.png new file mode 100644 index 0000000..c1c0f0e Binary files /dev/null and b/docs/images/part-2/media/image14.png differ diff --git a/docs/images/part-2/media/image15.png b/docs/images/part-2/media/image15.png new file mode 100644 index 0000000..04096e1 Binary files /dev/null and b/docs/images/part-2/media/image15.png differ diff --git a/docs/images/part-2/media/image16.png b/docs/images/part-2/media/image16.png new file mode 100644 index 0000000..89b7479 Binary files /dev/null and b/docs/images/part-2/media/image16.png differ diff --git a/docs/images/part-2/media/image17.png b/docs/images/part-2/media/image17.png new file mode 100644 index 0000000..aa560cb Binary files /dev/null and b/docs/images/part-2/media/image17.png differ diff --git a/docs/images/part-2/media/image18.png b/docs/images/part-2/media/image18.png new file mode 100644 index 0000000..8bcb5d3 Binary files /dev/null and b/docs/images/part-2/media/image18.png differ diff --git a/docs/images/part-2/media/image19.png b/docs/images/part-2/media/image19.png new file mode 100644 index 0000000..f685a91 Binary files /dev/null and b/docs/images/part-2/media/image19.png differ diff --git a/docs/images/part-2/media/image2.png b/docs/images/part-2/media/image2.png new file mode 100644 index 0000000..5bbd7c3 Binary files /dev/null and b/docs/images/part-2/media/image2.png differ diff --git a/docs/images/part-2/media/image21.png b/docs/images/part-2/media/image21.png new file mode 100644 index 0000000..ee0eec9 Binary files /dev/null and b/docs/images/part-2/media/image21.png differ diff --git a/docs/images/part-2/media/image24.png b/docs/images/part-2/media/image24.png new file mode 100644 index 0000000..4c5ad19 Binary files /dev/null and b/docs/images/part-2/media/image24.png differ diff --git a/docs/images/part-2/media/image25.png b/docs/images/part-2/media/image25.png new file mode 100644 index 0000000..8fd9d70 Binary files /dev/null and b/docs/images/part-2/media/image25.png differ diff --git a/docs/images/part-2/media/image26.png b/docs/images/part-2/media/image26.png new file mode 100644 index 0000000..b0a6bb3 Binary files /dev/null and b/docs/images/part-2/media/image26.png differ diff --git a/docs/images/part-2/media/image29.png b/docs/images/part-2/media/image29.png new file mode 100644 index 0000000..7efb7df Binary files /dev/null and b/docs/images/part-2/media/image29.png differ diff --git a/docs/images/part-2/media/image3.png b/docs/images/part-2/media/image3.png new file mode 100644 index 0000000..38f7361 Binary files /dev/null and b/docs/images/part-2/media/image3.png differ diff --git a/docs/images/part-2/media/image30.png b/docs/images/part-2/media/image30.png new file mode 100644 index 0000000..6353886 Binary files /dev/null and b/docs/images/part-2/media/image30.png differ diff --git a/docs/images/part-2/media/image4.png b/docs/images/part-2/media/image4.png new file mode 100644 index 0000000..20ce48a Binary files /dev/null and b/docs/images/part-2/media/image4.png differ diff --git a/docs/images/part-2/media/image5.png b/docs/images/part-2/media/image5.png new file mode 100644 index 0000000..68df0cb Binary files /dev/null and b/docs/images/part-2/media/image5.png differ diff --git a/docs/images/part-2/media/image6.png b/docs/images/part-2/media/image6.png new file mode 100644 index 0000000..ef250de Binary files /dev/null and b/docs/images/part-2/media/image6.png differ diff --git a/docs/images/part-2/media/image7.png b/docs/images/part-2/media/image7.png new file mode 100644 index 0000000..f7db2b2 Binary files /dev/null and b/docs/images/part-2/media/image7.png differ diff --git a/docs/images/part-2/media/image8.png b/docs/images/part-2/media/image8.png new file mode 100644 index 0000000..d7b3007 Binary files /dev/null and b/docs/images/part-2/media/image8.png differ diff --git a/docs/images/part-2/media/image9.png b/docs/images/part-2/media/image9.png new file mode 100644 index 0000000..4c9ef01 Binary files /dev/null and b/docs/images/part-2/media/image9.png differ diff --git a/docs/images/part-2/override-gui.png b/docs/images/part-2/override-gui.png new file mode 100644 index 0000000..7066211 Binary files /dev/null and b/docs/images/part-2/override-gui.png differ diff --git a/docs/index.html b/docs/index.html index f6e704f..ec0d16e 100644 --- a/docs/index.html +++ b/docs/index.html @@ -7,7 +7,7 @@ name="viewport" content="width=device-width, initial-scale=1, minimum-scale=1.0, shrink-to-fit=no" /> - Deploy your first application to IBM Cloud in 3 clicks | IBM TechXchange 2023 + Seamless Deployment: From Provisioning to Runtime with IBM Cloud's Landing Zone Deployable Architecture | IBM TechXchange 2023 @@ -48,14 +48,14 @@ @@ -83,5 +87,7 @@ + + diff --git a/docs/js/docsify-copy-code.min.js b/docs/js/docsify-copy-code.min.js new file mode 100644 index 0000000..3e0138b --- /dev/null +++ b/docs/js/docsify-copy-code.min.js @@ -0,0 +1,9 @@ +/*! + * docsify-copy-code + * v3.0.0 + * https://github.com/jperasmus/docsify-copy-code + * (c) 2017-2023 JP Erasmus + * MIT license + */ +!function(){"use strict";function e(o){return e="function"==typeof Symbol&&"symbol"==typeof Symbol.iterator?function(e){return typeof e}:function(e){return e&&"function"==typeof Symbol&&e.constructor===Symbol&&e!==Symbol.prototype?"symbol":typeof e},e(o)}!function(e,o){void 0===o&&(o={});var t=o.insertAt;if(e&&"undefined"!=typeof document){var n=document.head||document.getElementsByTagName("head")[0],c=document.createElement("style");c.type="text/css","top"===t&&n.firstChild?n.insertBefore(c,n.firstChild):n.appendChild(c),c.styleSheet?c.styleSheet.cssText=e:c.appendChild(document.createTextNode(e))}}(".docsify-copy-code-button,.docsify-copy-code-button>span{cursor:pointer;transition:all .25s ease}.docsify-copy-code-button{background:grey;background:var(--theme-color,grey);border:0;border-radius:0;color:#fff;font-size:1em;opacity:0;outline:0;overflow:visible;padding:.65em .8em;position:absolute;right:0;top:0;z-index:1}.docsify-copy-code-button>span{background:inherit;border-radius:3px;pointer-events:none}.docsify-copy-code-button>.error,.docsify-copy-code-button>.success{font-size:.825em;opacity:0;padding:.5em .65em;position:absolute;right:0;top:50%;transform:translateY(-50%);z-index:-100}.docsify-copy-code-button.error>.error,.docsify-copy-code-button.success>.success{opacity:1;right:100%;transform:translate(-25%,-50%)}.docsify-copy-code-button:focus,pre:hover .docsify-copy-code-button{opacity:1}.docsify-copy-code-button>[aria-live]{height:1px;left:-10000px;overflow:hidden;position:absolute;top:auto;width:1px}"),document.querySelector('link[href*="docsify-copy-code"]')&&console.warn("[Deprecation] Link to external docsify-copy-code stylesheet is no longer necessary."),window.DocsifyCopyCodePlugin={init:function(){return function(e,o){e.ready((function(){console.warn("[Deprecation] Manually initializing docsify-copy-code using window.DocsifyCopyCodePlugin.init() is no longer necessary.")}))}}},window.$docsify=window.$docsify||{},window.$docsify.plugins=[function(o,t){var n={buttonText:"Copy to clipboard",errorText:"Error",successText:"Copied"};o.doneEach((function(){var o=Array.from(document.querySelectorAll("pre[data-lang]"));t.config.copyCode&&Object.keys(n).forEach((function(o){var c=t.config.copyCode[o];"string"==typeof c?n[o]=c:"object"===e(c)&&Object.keys(c).some((function(e){var t=location.href.indexOf(e)>-1;return n[o]=t?c[e]:n[o],t}))}));var c=['"].join("");o.forEach((function(e){e.insertAdjacentHTML("beforeend",c)}))})),o.mounted((function(){var e=document.querySelector(".content");e&&e.addEventListener("click",(function(e){if(e.target.classList.contains("docsify-copy-code-button")){var o="BUTTON"===e.target.tagName?e.target:e.target.parentNode,t=document.createRange(),c=o.parentNode.querySelector("code"),i=o.querySelector("[aria-live]"),r=window.getSelection();t.selectNode(c),r&&(r.removeAllRanges(),r.addRange(t));try{document.execCommand("copy")&&(o.classList.add("success"),i.innerText=n.successText,setTimeout((function(){o.classList.remove("success"),i.innerText=""}),1e3))}catch(e){console.error("docsify-copy-code: ".concat(e)),o.classList.add("error"),i.innerText=n.errorText,setTimeout((function(){o.classList.remove("error"),i.innerText=""}),1e3)}(r=window.getSelection())&&("function"==typeof r.removeRange?r.removeRange(t):"function"==typeof r.removeAllRanges&&r.removeAllRanges())}}))}))}].concat(window.$docsify.plugins||[])}(); +//# sourceMappingURL=docsify-copy-code.min.js.map diff --git a/docs/part1/00-objectives.md b/docs/part1/00-objectives.md new file mode 100644 index 0000000..08feb8f --- /dev/null +++ b/docs/part1/00-objectives.md @@ -0,0 +1,38 @@ +# Lab 1: End-to-end deployment of a sample web application on a secure VPC topology + +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. + + + +After you provision the VPC, you customize the deployed infrastructure in the following ways: +- Expose one of the VSI in the management VPC to act as a "jump box" for operator access. This jump box is the entry point for operators to access the VSIs in the workload VPC. +- Deploy an Apache server in a VSI in the workload VPC. +- Expose the web pages that are served by the Apache server to the internet through a public load balancer. + +## Lab Prerequisites :white_check_mark: + +?> _TODO_ review + +Make sure that you meet the following prerequisites before you begin the lab. + +- IBM Cloud + - An IBM Cloud Pay-Go or Subscription account + + :information_source: **Note**: Participants in the TechXchange classroom will be provided with credentials to access an IBM Cloud account during the lab. + - An IBMid + - API key with the following permissions + +?> _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) + - Text editor of your choice + - Web browser + - Tools to generate SSH key + - Linux and Mac come with ssh-keygen. + - Windows users can use [PuTTYgen](https://www.ssh.com/academy/ssh/putty/windows/puttygen) + + For more information, see [Generating an external SSH key](https://cloud.ibm.com/docs/vpc?topic=vpc-ssh-keys&interface=ui#generating-ssh-keys). + - Optional: [IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-getting-started) + +:information_source: **Note**: Participants in the TechXchange classroom will be provided with a development VM with the prerequisite software installed. diff --git a/docs/part1/10-project.md b/docs/part1/10-project.md new file mode 100644 index 0000000..0b1a380 --- /dev/null +++ b/docs/part1/10-project.md @@ -0,0 +1,76 @@ +# Deploying the landing zone VSI pattern through IBM Cloud projects + +1. On your computer, create an SSH key pair by issuing the following command: + + ```sh + ssh-keygen -t rsa -b 4096 -N '' -f ./lab-key + ``` + + This command generates two files in the current directory: `lab-key` (the private key) and `lab-key.pub` (the public key. + + List the keys exist in the current directory with the following command: + + ```sh + ls lab-key* + ``` + + If the SSH key pair succeeded, the output lists them: + + ```sh + lab-key lab-key.pub + ``` + +1. Add the deployable architecture to a project: + + 1. Access the [VSI on VPC landing zone Deployable Architecture](https://cloud.ibm.com/catalog/architecture/deploy-arch-ibm-slz-vsi-ef663980-4c71-4fac-af4f-4a510a9bcf68-global?catalog_query=aHR0cHM6Ly9jbG91ZC5pYm0uY29tL2NhdGFsb2cjcmVmZXJlbmNlX2FyY2hpdGVjdHVyZQ%3D%3D) in IBM Cloud. + 1. On the VSI on VPC landing zone details page, make sure that the following settings are selected:\ + a. Product version: **Select the latest** (`4.4.7` at the time of writing).\ + b. Variation: `Standard` + + ![Details page](../images/part-1/10-overview-page.png) + + 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. Click **Add** on the lower right. + +1. Configure the project + 1. In the **Configure** > **Security** section, specify the following information: \ + a. Authentication: Clear **Use a secret** and paste in your IBM Cloud API key. + + 1. In the **Configure** > **Required** section, specify the following settings:\ + a. `ssh_public_key`: The value of the `lab-key.pub` file that you generated in step 1.\ + b. `region`: The region that you want to deploy in. \ + c. `prefix`: Your initials. + + ![Configuration](../images/part-1/10-configuration.png) + + 1. In the **Configure** > **Optional**, set the following options:\ + a. `add_atracker_route`: `false`. + 1. Click **Save**. + +1. Validate and deploy the deployable architecture: + 1. Click **Validate**. + + The project runs through several validation steps. When it finishes, the validation is marked as successful. In the **Approval pending** section, add a comment and click **Approve** to start provisioning. + + ![Validation](../images/part-1/10-validation.png) + + 1. Click **Deploy** + + :information_source: **Tip**: Deployment takes approximately 15 minutes to complete. + +1. While you wait for the deployment to finish, consider doing these things: + + - Look at the deployment logs: + - The Terraform init step initializes the Terraform configuration files for use with Terraform. + - The Terraform plan steps show the list of resources that are going to be created. + - The Terraform apply steps shows the resources that are being created. + + Example: + + ![Deployment](../images/part-1/10-deployment.png) + + - Go to the [VPC section](https://cloud.ibm.com/vpc-ext/vpcLayout) and the [resource list](https://cloud.ibm.com/resources) in your IBM Cloud account. Refresh the screen to see the resources that are created during deployment. + - Explore some of the materials in the [introduction](README) to this lab. + - Have a coffee ☕ diff --git a/docs/part1/20-operator-access.md b/docs/part1/20-operator-access.md new file mode 100644 index 0000000..1dafdc1 --- /dev/null +++ b/docs/part1/20-operator-access.md @@ -0,0 +1,54 @@ +# Providing operator access to the VPC landing zone + +## Overview of operator access + +By default, network access to the VPC landing zone topology is locked down for security compliance reasons. In this part of the lab, you open the necessary access for an operator to access the VPC environment, including deploying application on the VSIs located in the workload VPC. + +You give operator access through the _Management VPC_. You have several options to give operator access, with varying level of security, compliance, and ease of enablement. + +- Exposing a VSI in the management VPC as a ‘jump-box’ by assigning a public floating IP +- Deploying a client-to-site VPN solution in the management VPC +- Deploying a site-to-site VPN solution in the management VPC +- Deploying a certified bastion solution, such as Gravitational Teleport in the management VPC. + +In this lab, you expose one of the VSIs in the management VPC as a 'jump-box'. This method is one of the simplest ways to proceed, although it is not overly secure. The [Going further](./part1/50-going-further) section later in the lab provides links to some of the other ways that you can provide operator access. + +## Steps + +Complete the following steps to enable public SSH access to one of the VSI in the management VPC. This VSI is the unique operator entry point ('jump-box') to the landing zone VPC topology. + +1. Access the [Virtual server instances for VPC list](https://cloud.ibm.com/vpc-ext/compute/vs). +2. Verify that the region is set to the region you provisioned your resources and click the VSI labeled `-management-server-1`. +3. Add a floating IP address by clicking the pencil icon in the Network Interface section. Reserve a new floating IP address. + + ![Pencil icon](../images/part-1/20-network-int-pencil.png) + + :exclamation: **Important**: Take note of the public floating IP address. You need it later. + + ![Floating IP address](../images/part-1/20-floating-ip.png) + +5. Click **Save**. +6. In the [Security Groups for VPC](https://cloud.ibm.com/vpc-ext/network/securityGroups), click the one labeled `-management`. +7. Go to the Rules section and allow port 22 for SSH inbound access by clicking **Create** in the _Inbound rules_ section. + + :information_source: **Tip**: Security groups are stateful so you don’t need to add a corresponding outbound rule. + + ![Allow SSH in Security group](../images/part-1/20-ssh-sg.png) + +8. Click **Create**. +9. In the [Access control lists for VPC](https://cloud.ibm.com/vpc-ext/network/acl), click the one labeled `-management-acl`. +10. Create the following ACL inbound rule for SSH access: + + ![SSH ACL Inbound rule](../images/part-1/20-ssh-acl-inbound.png) + +11. Create the following ACL outbound rule for SSH access: + + ![SSH ACL Outbound rule](../images/part-1/20-ssh-acl-outbound.png) + +12. You can now access the 'jump-box' through the public floating IP address that you provisioned earlier. On your computer, issue the following command from the terminal or command window: + + ```sh + ssh -i ./lab-key root@ + ``` + + Replace \ with the address that you reserved earlier. diff --git a/docs/part1/30-apache-server.md b/docs/part1/30-apache-server.md new file mode 100644 index 0000000..b564147 --- /dev/null +++ b/docs/part1/30-apache-server.md @@ -0,0 +1,61 @@ +# Deploying an Apache server in the Workload VPC + +In this part of the lab, you install an Apache server on a workload VSI. + +By default, the workload VSI (Virtual Server Instance) is locked down from the management VPC. You need to allow access through the access control list. + +1. In the [Access control list](https://cloud.ibm.com/vpc-ext/network/acl), click the ACL labeled `-workload-acl`. + 1. Create an ACL inbound rule to allow ssh access from the Management VPC. + + ![Workload SSH ACL Inbound rule](../images/part-1/30-workload-ssh-acl-inbound.png) + + 1. Create an ACL outbound rule to allow ssh access from the Management VPC. + + ![Workload SSH ACL Outbound rule](../images/part-1/30-workload-ssh-acl-outbound.png) + +1. In the [Access control list](https://cloud.ibm.com/vpc-ext/network/acl), click the ACL labeled `-management-acl`. + 1. Create an ACL inbound rule to allow ssh access from the Workload VPC. + + ![Management SSH ACL Inbound rule](../images/part-1/30-mgmt-ssh-acl-inbound.png) + + 1. Create an ACL outbound rule to allow ssh access from the Workload VPC. + + ![Management SSH ACL Outbound rule](../images/part-1/30-mgmt-ssh-acl-outbound.png) + +1. Access the workload VSI by completing the following steps: + 1. Go to [Virtual server instances for VPC](https://cloud.ibm.com/vpc-ext/compute/vs). Take note of the private IP("Reserved IP") for the VSI labeled `:/root + ``` + + 1. SSH to the bastion host + + ```sh + ssh -i ./lab-key root@ + ``` + + 1. Change permissions of the private key + + ```sh + chmod 600 lab-key + ``` + + 1. SSH to the workload VSI + + ```sh + ssh -i ./lab-key root@ + ``` + +1. Install the Apache web server by issuing the following commands: + + ```sh + apt-get update + apt-get install apache2 --yes + ``` + +1. (Optional) You can repeat steps 3 and 4 for the workload VSIs `-workload-server-2` and `-workload-server-3` diff --git a/docs/part1/40-expose-web-app.md b/docs/part1/40-expose-web-app.md new file mode 100644 index 0000000..b9a14ef --- /dev/null +++ b/docs/part1/40-expose-web-app.md @@ -0,0 +1,48 @@ +# Exposing the web application to the internet + +In this part of the lab, you expose the web pages to the internet through a VPC load balancer so that anyone can access them. + +1. Create a public load balancer to expose the web application. + 1. Access the [Load balancers for VPC](https://cloud.ibm.com/vpc-ext/network/loadBalancers) page. + 1. Click **Create**. +1. Specify the following settings for the load balancer: + - Load balancer type: Application Load Balancer (ALB) + - Location: Location that you provision your VPC resources + - Details: + - Name: `-web-lb` + - Virtual private cloud: `-workload-vpc` + - Type: `Public` + - DNS type: `Public` + - Subnets: `-workload-vsi-zone-1` + - Backend pool: + - Name: `-backend-pool` + - Pool protocol: `HTTP` + - Health Port: `80` + - Click **Attach server +** in the Back-end pools section and add the VSI that is in the subnet `-workload-vsi-zone-1` with a server port of `80`. + - Create a front-end listener by clicking **Create listener** and set the Listener port to `80`. + - Under the _Security Group_ section, clear all settings except the one labeled `-workload`. + - Click **Create load balancer**. +1. Allow access to the load balancer by adding the following inbound rule to the [security group](https://cloud.ibm.com/vpc-ext/network/securityGroups) called `-workload` that the load balancer is attached. + + ![Inbound security group rule](../images/part-1/40-sg.png ':size=60%') + +1. Allow internet access to the load balancer by adding the following rules to the [Access control list](https://cloud.ibm.com/vpc-ext/network/acl) for the ACL `-workload-acl`. + - Create an inbound rule + + ![ACL inbound rule](../images/part-1/40-acl-inbound.png ':size=60%') + + - Create an outbound rule + + ![ACL outbound rule](../images/part-1/40-acl-outbound.png ':size=60%') + + :information_source: **Tip**: It can take several minutes for your load balancer to provision. Wait until the status is set to `Active` in [Load balancers for VPC](https://cloud.ibm.com/vpc-ext/network/loadBalancers). You might need to refresh the page periodically. + +1. Complete these steps after your web application is exposed: + 1. Retrieve the FQDN of your load balancer: + 1. [Access the Load Balancer list](https://cloud.ibm.com/vpc-ext/network/loadBalancers) and click your provisioned load balancer. + 1. Copy the value under `Hostname`. + 1. On your computer, open a web browser and point it to `http://`. You can also test connectivity by issuing the following curl command: + + ```sh + curl http:// + ``` diff --git a/docs/part1/50-going-further.md b/docs/part1/50-going-further.md new file mode 100644 index 0000000..2884d01 --- /dev/null +++ b/docs/part1/50-going-further.md @@ -0,0 +1,30 @@ +# Going further + +To keep the lab simple, you give operator access through a VSI jump-box in the management VPC. Then you expose the web application directly through a public load balancer that is attached to the worker VPC. + +These approaches provide a reasonable level of security, satisfy a number of compliance controls, and might be sufficient for a number of industries and enterprises. If you want more security and need to comply with different controls, consider the following information to set a more secure and compliant posture. + +## Other ways to provide operator access + +Some secure options to consider for providing network connectivity to the management VPCs. + +- A Client-To-Site VPN, in which the operator has a VPN client on the environment that connects to a VPN server that is running the management VPC. IBM Cloud provides a default [client-to-site VPN solution](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-client-to-site-overview) that can be used for this purpose. For an example of automation to deploy a client-to-site gateway in a landing-zone management VPC, see [Client-To-Site VPN add-on for landing zone](https://github.com/terraform-ibm-modules/terraform-ibm-client-to-site-vpn/tree/main/extensions/landing-zone). + + ![Client-to-site VPN](../images/part-1/50-c2s.png) +- A [site-to-site VPN](https://cloud.ibm.com/docs/vpc?topic=vpc-using-vpn) to connect the management VPC to another private network. The landing zone deployable architecture creates a site-to-site gateway for this purpose. +- Direct LInk, which extends an organization data center network. For a starting point with more details, see [Connecting application provider to the management VPC](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-connectivity-management). + +From a compliance perspective, record all interactive operator actions with a bastion solution. Operators connect through the bastion, which records all interactive session actions for auditing. For more information, see [Running operator actions through a bastion host +](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-connectivity-bastion) in the IBM cloud Framework for Financial Services docs. For a tutorial that uses the 3rd-party solution Teleport, see [Setting up a bastion host that uses Teleport](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-connectivity-bastion-tutorial-teleport). + +## Other ways to expose the web application to the internet + +In the lab, the workload is exposed through a public VPC load balancer that is attached to the workload VPC. With the following additions, you can make the solution more secure. + +1. Create the public VPC load balancer in a separate edge VPC. Route the traffic from the edge VPC to the application that is running on the workload VPC through a private load balancer (which is routable only from within the VPC topology). This approach ensures that no direct public network flows to the workload VPC. For more information, see [Connecting from public internet](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-connectivity-workload#consumer-provider-public-internet) in "Consumer connectivity to workload VPC". + +2. Introduce a web application firewall in the flow in one of two ways: +- As-a-service: Typically, you add a global load balancer, such as IBM Cloud CIS or Akamai, in front of the VPC load balancer. Then, you add a network ACL on the VPC load balancer to accept inbound traffic only from the global load balancer set of known IP addresses. +- Hosted: You can host the application with a 3rd-party solution, such as BigIP F5. This solution is deployed and hosted on servers that you run, for example in VSIs in the landing-zone VPC topology. For a tutorial, see [Setting up a web application firewall with F5 BIG-IP](https://cloud.ibm.com/docs/framework-financial-services?topic=framework-financial-services-vpc-architecture-connectivity-waf-tutorial). + + diff --git a/docs/part2/00-objectives.md b/docs/part2/00-objectives.md new file mode 100644 index 0000000..fbbb60d --- /dev/null +++ b/docs/part2/00-objectives.md @@ -0,0 +1,7 @@ +# Lab 2: Automating deployment and sharing through a private catalog + +In lab 1, you deployed most of the landing zone topology, and then customized the infrastructure. + +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). diff --git a/docs/part2/10-customizing.md b/docs/part2/10-customizing.md new file mode 100644 index 0000000..c725dc2 --- /dev/null +++ b/docs/part2/10-customizing.md @@ -0,0 +1,45 @@ +# Customizing the landing zone topology + +## 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 file `override.json` or through the module variable `override_json_string`. + + The override enables deeper and broader types of customizations. By using a JSON definition, 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 new file mode 100644 index 0000000..fae202a --- /dev/null +++ b/docs/part2/20-custom-module.md @@ -0,0 +1,86 @@ +# Encapsulating the topology definition in a Terraform module + +## Objective + +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.5.4 (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.5.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 in your local environment, follow these steps. + +1. Clone the repository locally with the following Git command: + + ```sh + cd ~ + git clone https://github.com/IBM/infra-to-app-with-landing-zone + ``` + +2. Change to the `custom-slz` folder + + ```sh + cd infra-to-app-with-landing-zone/custom-slz + ``` + +3. Create a Terraform workspace. Replace `lab` with your own name in the following command. + + ```sh + terraform workspace new lab + ``` + +4. Generate an SSH key pair. This key pair is used to `ssh` to the VSIs created by this execution. + + ```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. Initialize Terraform. + + ```sh + terraform init + ``` + +7. Generate a plan. The plan lists of resources that are going to be created. + + ```sh + terraform plan -var=region=eu-gb -var=ssh_key="$(cat ./lab2-key-tf.pub)" -var=prefix=lab-prefix + ``` + +8. (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.pub)" -var=prefix=lab-prefix + ``` diff --git a/docs/part2/30-add-apache.md b/docs/part2/30-add-apache.md new file mode 100644 index 0000000..af2a02c --- /dev/null +++ b/docs/part2/30-add-apache.md @@ -0,0 +1,77 @@ +# 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. + +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. + +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. + +![Diagram of the flow through the jump box to the workload VSIs](../images/part-2/media/image21.png) + +## Execute the Apache deployment logic + +You can find the code for this step in the [lab/step2](https://github.com/IBM/infra-to-app-with-landing-zone/tree/main/lab/step2) directory. The directory contains the following important files: + +- The [apache.tf](https://github.com/IBM/infra-to-app-with-landing-zone/blob/main/lab/step2/apache.tf) file which contains the terraform logic calling the remote-exec provisioner with the 'right' parameters. + + Notice the following settings in the `apache.tf` file: + + - In the connection block, the `bastion_host` is set to the management server floating IP address that you will use as a jump host to connect to the workload server. + - In the connection block, the `host` is set to the IP address of the workload server. + - In the provisioner block, a list of the commands that will be executed on the workload server are listed. + + ```hcl + resource "null_resource" "application-install" { + count = var.number_vsi_workload + connection { + type = "ssh" + user = "root" + bastion_host = var.floating_ip_address + host = local.workload_ip_list[count.index] + private_key = var.ssh_private_key + agent = false + timeout = "15m" + } + + provisioner "remote-exec" { + inline = [ + "apt-get install apache2 -y" + ] + } + } + ``` + +To run the Terraform module in your local environment, follow these steps. These steps assume you ran the steps in ([Executing the landing zone with a JSON definition](./part2/20-custom-module)). + +1. Copy the apache.tf file from the lab/step2 directory to the `custom-slz` folder + + ```sh + cd ~/infra-to-app-with-landing-zone/ + cp lab/step2/apache.tf custom-slz + ``` + +2. Initialize Terraform. + + ```sh + terraform init --upgrade + ``` + +3. Generate a plan. The plan lists of resources that are going to be created. + - If you ran the optional `terraform apply` step in [Executing the landing zone with a JSON definition](./part2/20-custom-module), then the plan shows only the new resources related to the creation of the Apache server. + - Otherwise, the plan shows the all of the resources related to the creation of the infrastructure in additional to the resources related to the Apache server. + + ```sh + terraform plan -var=region=eu-gb -var=ssh_private_key="$(cat ./lab2-key-tf)" + ``` + + + +4. (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_private_key="$(cat ./lab2-key-tf)" + ``` \ No newline at end of file diff --git a/docs/part2/40-catalog-onboarding.md b/docs/part2/40-catalog-onboarding.md new file mode 100644 index 0000000..f2f5035 --- /dev/null +++ b/docs/part2/40-catalog-onboarding.md @@ -0,0 +1,241 @@ +# Onboard the Terraform module as a deployable architecture in IBM Cloud catalog + +## Objective + +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 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 + + +1. Create a private catalog to hold your organization's custom deployable architectures. + + 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 (yourinitials)`. + 1. Click **Create**. +1. Select the catalog, and then click **Add** to add a product to the new catalog offering. + + - Product type: **Deployable architecture**. + - Delivery method: **Terraform**. + - Repository type: **Public repository**. + - Source URL: `https://github.com/IBM/infra-to-app-with-landing-zone/archive/refs/tags/1.0.0.tar.gz`. + + 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**. + + :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**. + + 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: + + 1. Click **Edit**. + + ![](../images/part-2/e49d98bdf9d5c5fe23d2f0f3b04b2e0b271b50e4.png) + + 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. + 1. Click the **Save** button to persist the changes. + +## Specifying initial version details + +In the next few steps, you edit the information that applies to the version. + +### Configuring the version +1. Access the version configuration pages: + + 1. In the **Version list** section, click the version that was imported (1.0.0). + + ![](../images/part-2/8189e32b5ed54528a3fe0cd0ab18af214555cc7d.png) + +1. The **Configure version** pane is displayed: + ![](../images/part-2/media/image24.png) + 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. + + 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. + + ```hcl + terraform { + required_version = ">= 1.3, < 1.6" + required_providers { + ibm = { + source = "IBM-Cloud/ibm" + version = "1.54.0" + } + } + } + ``` + + 1. In the Input variables section, click **Add input variables**. + + ![](../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. + + ![](../images/part-2/media/image26.png) + 1. Edit some input variables: + + 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. + + 1. Click the `region` input variable + 1. In the **Details** section, change the type from string to *VPC Region* + + ![](../images/part-2/520e1108848d01be4e7f9a8b40b36435dcecaa02.png) + + 1. Perform the same steps to set the type of the `ssh_private_key` variable to *Multiline secure value* + + Compare your entries against the following screenshot. + + ![](../images/part-2/16ac8f7add0155eacbc958df9b14489264e9574b.png) + + 1. Click **Next**. + +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. + + 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**. + + Compare your work against the following screenshot. + + ![](../images/part-2/media/image29.png) + +1. Click **Next**. + +### Adding deployable architecture details + +In the **Add deployable architecture details** section, you can add architecture diagrams and other information about the deployable architecture. + +1. In the **Step 1 - Add architecture diagrams** pane, add an architecture diagram: + + 1. Click the **Add architecture diagram** link + + ![](../images/part-2/media/image30.png) + + 1. Follow the steps to add an architecture diagram. + + The repository for this lab contains an architecture diagram. When prompted, use this url: `https://raw.githubusercontent.com/IBM/infra-to-app-with-landing-zone/cff0457a362c9b56ce805234410b678d55ebe29d/vpc.drawio.svg` + + ![](../images/part-2/ee8a02736dedaaec38f6826ef5e454765563da63.png) + +1. In the **Step 2 - add prerequisites** pane, leave the input as blank, and click **Next**. + + 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. + +1. In the **Step 3 - Add highlights** pane, leave the list of highlights blank. + + In this step, you can indicate other pertinent information about your deployable architecture. + +### Updating the license agreement and readme file + +1. In the **Add license agreements** pane, keep the [license](https://github.com/IBM/infra-to-app-with-landing-zone/blob/main/LICENSE) that was imported automatically by IBM Cloud Catalog from the Github repository. + + In this step, you can identify a license agreement that users must accept before they deploy. + +1. In the **Edit readme** pane, leave the readme file as is. + + 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, + + - 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. + +### Validating the version + +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. + +1. In the **Step 1 - Configure Schematics workspace** pane, leave the existing values as is and click **Next**. + + ![](../images/part-2/708ba95b2a76860568ee6d085b47d4d7777d748b.png) + +1. Generate an SSH key pair. This key pair is used to ssh to the VSIs created by this execution. + + ```sh + ssh-keygen -t rsa -b 4096 -N '' -f ./lab2-catalog-key + ``` + +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 generated in previous step (content of `lab2-catalog-key.pub`). + - `ssh_private_key`: Copy and paste the private key that was generated in previous step (content of `lab2-catalog-key`) in the [heredoc format](https://en.wikipedia.org/wiki/Here_document). You should end up with a string looking like: + + ```text + < + -----END OPENSSH PRIVATE KEY----- + EOT + ``` + + - `prefix` (under the **Optional input variables** section): Your initials followed by catalog. For instance `vb-catalog`. + +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) + + Validation may take up to 25 minutes as it is going to deploy the full solution implemented in the module. While you wait for the validation to finish, consider doing these things: + 1. Look at the deployment logs in IBM Cloud Schematics by clicking the **View logs** link + 1. Explore some of the materials in the [introduction](README) to this lab. + 1. Have a coffee ☕ + + If the validation completes successfully, you see a pane that looks like the following screenshot: + + ![](../images/part-2/366e1c7205147143b2bf25c68e2dc30deed8679c.png) + + :bulb: **Tip:** If you have issues with validation, click the **View logs** link to examine the full Terraform logs in IBM Cloud Schematics. + +### Reviewing cost, compliance, and requirements + +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**. + + 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). + + :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. + + In this lab, we don't make any claims for our deployable architecture. + +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. + +![](../images/part-2/72a9d91f4543d58261951b90512784e62d4df141.png) + +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 new file mode 100644 index 0000000..7543def --- /dev/null +++ b/docs/part2/50-going-further.md @@ -0,0 +1,27 @@ +# 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. + +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 + +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. + +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/prereqs.md b/docs/prereqs.md new file mode 100644 index 0000000..dca5149 --- /dev/null +++ b/docs/prereqs.md @@ -0,0 +1,36 @@ +# Lab Prerequisites :white_check_mark: + +Make sure that you meet the following prerequisites before you begin the lab. + +- IBM Cloud + - An IBM Cloud Pay-Go or Subscription account + - An IBMid + + :information_source: **Note**: Participants in the TechXchange classroom will be provided with credentials to access an IBM Cloud account during the lab. + - [API key with the following permissions](https://cloud.ibm.com/docs/account?topic=account-userapikey&interface=ui#create_user_key) + + | Service | Resources | Role | + | -------- | ------- | ------- | + | IBM Cloud Projects | Aldministrator | + | Activity Tracker event routing | All | Editor | + | Transit Gateway | All | Editor, Manager | + | Schematics | All | Editor, Manager | + | Key Protect | All | Editor, KeyPurge, Manager | + | Cloud Object Storage | All | Editor, Manager | + | VPC Infrastructure Services | All | Editor, Manager | + | Resource group only | All resource group in the account | Viewer, Editor, Administrator| + + :exclamation: **Important**: Participants in the TechXchange classroom will need to create an API key for their provided credentials. Please save the generated API key for later use. + +- A development computer with the following software. + - [Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli) + - Text editor of your choice + - Web browser + - Tools to generate SSH key + - Linux and Mac come with ssh-keygen. + - Windows users can use [PuTTYgen](https://www.ssh.com/academy/ssh/putty/windows/puttygen) + + For more information, see [Generating an external SSH key](https://cloud.ibm.com/docs/vpc?topic=vpc-ssh-keys&interface=ui#generating-ssh-keys). + - Optional: [IBM Cloud CLI](https://cloud.ibm.com/docs/cli?topic=cli-getting-started) + +:information_source: **Note**: Participants in the TechXchange classroom will be provided with a development VM with the prerequisite software installed. \ No newline at end of file diff --git a/docs/sidebar.md b/docs/sidebar.md index 270cf4c..c61f44b 100644 --- a/docs/sidebar.md +++ b/docs/sidebar.md @@ -1,5 +1,18 @@ -- [📘 Overview](README.md) - - [IBM Cloud for Financial Service](./about/10-fs-cloud.md) - - [VPC Landing Zone](./about/20-vpc-landing-zone.md) - - [Deployable Architectures](./about/30-deployable-arch) - - [IBM Cloud Projects](./about/40-projects.md) +- [🌐 Introduction](README.md) + - [🏢 IBM Cloud for Financial Services](./about/10-fs-cloud.md) + - [🌍 VPC Landing Zone](./about/20-vpc-landing-zone.md) + - [🏗️ Deployable architectures](./about/30-deployable-arch) + - [📚 IBM Cloud projects](./about/40-projects.md) +- [📂 Lab Prerequisites](./prereqs.md) +- [📂 Lab 1 - End-to-end deployment](./part1/00-objectives.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) + - [🎓 Go further](./part1/50-going-further.md) +- [📂 Lab 2 - Automate and share](./part2/00-objectives.md) + - [🛠️ Customization options](./part2/10-customizing.md) + - [🔍 Execute the custom topology](./part2/20-custom-module.md) + - [🤖 Automate web app deployment](./part2/30-add-apache.md) + - [📦 Share through a IBM Cloud catalog](./part2/40-catalog-onboarding.md) + - [🎓 Go further](./part2/50-going-further.md) diff --git a/main.tf b/main.tf index f96ad59..4b3ecd5 100644 --- a/main.tf +++ b/main.tf @@ -5,7 +5,7 @@ module "landing_zone" { - source = "git::https://github.com/terraform-ibm-modules/terraform-ibm-landing-zone.git//patterns/vsi?ref=v4.4.4" + source = "git::https://github.com/terraform-ibm-modules/terraform-ibm-landing-zone.git//patterns/vsi?ref=v4.5.4" prefix = var.prefix region = var.region ibmcloud_api_key = var.ibmcloud_api_key