Skip to content

Latest commit

 

History

History
230 lines (139 loc) · 11.7 KB

40-catalog-onboarding.md

File metadata and controls

230 lines (139 loc) · 11.7 KB

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 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.

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 in the IBM Cloud console.
    2. Click Create.
    3. Give the catalog a name. For example, My deployable architectures.
    4. Click Create.

  2. 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/releases/tag/1.0.0.

      This URL links to the tar.gz asset file that is located in the GitHub release page.

    • Variation: Standard.

      💡 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. 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.

  3. Click Add product.

  4. (Optional) Change the default name for your deployable:

    1. Click Edit.

    2. Change the product name to one of your choice. For example, Secure webapp.

    3. (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.

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).

  2. The Configure version pane is displayed:

    1. Review the details in Step 1 - Review the version details. Click Next.

    2. 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.

      terraform {
required_version = ">= 1.3, < 1.6"
required_providers {
    ibm = {
    source  = "IBM-Cloud/ibm"
    version = "1.54.0"
    }
}
}

    3. In the Input variables section, click Add input variables.

    4. Select all variables and click Add. We want to display all variables from our Terraform module to users in IBM Cloud projects.

    5. 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

      2. In the Details section, change the type from string to VPC Region

      3. Complete the same steps to set the ssh_key variable type to type VPC SSH Key.

        TODO: double check. Probably does not apply.

      Compare your entries against the following screenshot.

    6. Click Next.

  3. 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 +.
    2. In service, search for Virtual Private Cloud.
    3. In platform access role, select Editor.
    4. Click Add.

    Compare your work against the following screenshot.

  4. 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

    2. Follow the steps to add an architecture diagram.

      The repository for this lab contains an architecture diagram at TODO

  2. 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.

  3. 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, leave the agreements empty.

    In this step, you can identify a license agreement that users must accept before they deploy.

  2. 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.

  2. 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.

      <<EOT
-----BEGIN OPENSSH PRIVATE KEY-----
< private key in base 64 >
-----END OPENSSH PRIVATE KEY-----
EOT

  3. In Step 3 - Validate version, click Validate.

    Validation is now in progress. The IBM Cloud catalog is running the Terraform module in a Schematics workspace.

    If the validation completes successfully, you see a pane that looks like the following screenshot:

    💡 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.

  2. Click Next.

  3. 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 in predefined profiles.

    ℹ️ 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.

  4. Review the details in the Review Requirements pane, and then click Ready to share. Confirm your choice.

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.

  2. Click Actions... and select Share.

  3. Select Share to this account, and click Share.

You can also share the deployable architecture with other accounts in the same IBM Cloud enterprise. 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.

The deployable architecture is also displayed in the catalog page.