Skip to content

Latest commit

 

History

History
107 lines (70 loc) · 4.36 KB

README_deploy.md

File metadata and controls

107 lines (70 loc) · 4.36 KB

Deploying code with Unity-CS

Unity CS is designed to deploy code by looking for certain standard entry points to execute. The most common entry point is a directory of terraform scripts called terraform-unity that is used to execute deployments to

Common Entry Points

Deployments are currently triggered via Terraform, and the scripts are stored in the terraform-unity directory. The -unity suffix indicates that the terraform scripts in this directory have been configured to work with the Unity-CS infrastructure scripts.

If the terraform-unity directory does not exist, the project will not work with the Unity-CS Framework

Terraform Values provided by Unity-CS

For deployment into MCP and other high-security AWS environments the number of VPCs and certain other resources are restricted. To work with this restriction Unity-CS applies it's own networking.tf and variables.tf files which contain the proper identifiers. These values are not particularly sensitive, but are unique to each AWS account being deployed to.

At runtime, the appropriate venue configurations are copied into the terraform-unity directory and then executed.

.
└── terraform-unity
    ├── main.jpl.tf
    ├── main.mcp.tf
    ├── networking.jpl.tf
    ├── networking.mcp.tf
    ├── variables.jpl.tf
    └── variables.mcp.tf

Communication with Terraform Cloud

Communication with Terraform cloud is handled through the main.tf file, which specifies the connection to Terraform cloud. This snippet dictates which workspace to use in Terraform Cloud:


terraform {

  ...

  required_version = ">= 0.14.9"
  cloud {
    organization = "JPL-UNITY"

    workspaces {
      name = "unity-cs-mcp"
    }
  }
}

The workspace name should match the workspace name in Terraform Cloud. This workspace has encrypted AWS credentials set for communication with the appropriate venue.

Terraform Cloud requires a token to communicate, which is stored in Github Secrets (Settings > Secrets > Actions) as TERRAFORM_CLOUD_TOKEN and will not function without this value being set. This value can be re-generated through the Terraform Cloud UI.

⚠️ This configuration may be temporary: Unity-CS is exploring other ways to deploy to highly secured AWS environments at this time.

Communication with AWS

Terraform Cloud (https://app.terraform.io/app) holds Varriables in each Workspace for communication with AWS. For short term access keys, the following Variables must be set (as Sensitive - write only values)

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_SESSION_TOKEN

For long term access keys, only two values must be set:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

Variables can also be stored in sets for use across multiple workspaces.

Push-Button Deployments via Github Actions

Automated Deployments are kicked off via Github Actions in the github.com/unity-sds/unity-cs-infra repository. The CI Deployment workflow in particular is designed to look for and run each of the common entry points in sequence.

  1. Go to the unity-cs-infra GitHub Actions page
  2. Select the "CI Deployment" Workflow
  3. Click "Run workflow"
  • (NOTE: if you don't see this link, contact the U-CS team, as you may need to be granted write access permissions)
  1. Select "deployment Target"
  2. Select "Repository Source"
  3. Select "Repository Branch"
  4. Click "Run Workflow"

Smoke Testing

Smoke Tests are short and simple tests that detect whether a service is up and running. This is the final step in a deployment and can be used to influence the next steps, whether it be a notification of success or kicking off regression tests, or even a teardown/rollback in the event of failure. The deployment workflow will look for a smoke test execution script in a common entry point and run it.

Common Entry Points

The Unity-CS framework will look for an entry point here:

.
└── smoketest
    └── smoketest.sh

Executing Smoke Tests

This shell script can reference any number of testing methods. From CURL commands to python scripts, even full blown Docker commands, as long as they are wrapped in the smoketest.sh script and fail appropriately.

Failing appropriately means exiting with a status other than 0, as there's no case where a failing smoke test will allow the deployment to persist.