Skip to content

Latest commit

 

History

History
86 lines (57 loc) · 4.34 KB

usage.md

File metadata and controls

86 lines (57 loc) · 4.34 KB

QuickLab Usage

Lifecycle

QuickLab Lifecycle

Walkthrough

Prerequisites

  • create API keys (for cloud provider and monitoring)
  • download required software
  • add API keys to QuickLab for monitoring
    • Edit aws.auto.tfvars. In the Monitoring section, add Sumo Logic credentials and Organization ID.

Notes:

  • Terraform will automatically use your default aws cli profile to authenticate to AWS and select which Region to use, but you can optionally specify a different named aws cli profile and/or region.
  • Terraform can read your API keys from environment variables.

Create

This step validates you have met the prerequisites and is required before enabling QuickLab components.

  • Initialize terraform and create empty QuickLab using terraform init && terraform apply -auto-approve

    Notes:

    • terraform must be initalized from a root module (e.g. quicklab/aws)
    • terraform apply can be used without -auto-approve to review the tf plan before terraform implements it.
    • The profile+region combination used to create a QuickLab should be used for the entire life of that LabId. Switching regions will cause terraform to overwrite state entries for QuickLab Component cloud resources, orphaning them to be managed outside of terraform. To use multiple concurrent QuickLabs in different AWS Regions, or using different AWS CLI Profiles, download this project code to a different local directory on your computer and repeat this step to generate a separate LabId.

Use

Enable the QuickLab components needed for your use case, starting with the Network (which is required for the Bastion and Cluster). Disable QuickLab components when they are no longer needed.

  • enable or disable a component

    • Edit aws.auto.tfvars. In the Components section, set create_network to true (or false).
    • Update QuickLab using terraform apply -auto-approve and review terraform output.

  • build on QuickLab

    • use the bastion to securely access Windows or Linux servers in the Network's private subnets
    • use the cluster to deploy and use containerized microservice-based apps like the AstronomyShop OpenTelemetry-Demo application.
    • use Sumo Logic to analyze QuickLab component health, performance, cost, and security using out-of-box solutions with no configuration required
    • use Sumo Logic to implement OpenTelemetry-based telemetry collection for logs, metrics, and traces to an Observability backend

Notes:

  • QuickLab monitoring is enabled by selecting a supported monitoring backend (e.g. Sumo Logic, using monitoring = "sumo")
  • See a QuickLab inventory in the AWS Console using the aws_resource_group named in the terraform output.
  • For typical QuickLab component create/destroy times, see component notes.
  • When building on QuickLab, remember that any resources you create or add will not be managed by QuickLab's terraform state. These resources should be removed prior to disabling any QuickLab component they depend on.

Destroy

  • destroy QuickLab

    • To remove all QuickLab components while maintaining the existing Lab Id, use:

      terraform apply \
-auto-approve \
-var="create_network=false" \
-var="create_bastion=false" \
-var="create_cluster=false" \
-var="monitoring=none"

    • Use terraform destroy to reset the Lab Id and clear Terraform state.

      Note: terraform variables can be set for each run via cli argument

Documentation