IaC Site Deployment

Guide for source-code operations from Github

• Clone repository using the recursive option to assure that the linked repositories declared as submodules are properly initialized

git clone --recurse-submodules <This repository URL HTTPS-or-SSH>

• In case you missed the previous guideline and did a clone without flag, you can recursively remove the project and redo the cloning operation with recurs

git submodule init 
git submodule update

alternatively the two can be combined as less obvious, but more compact form:

git submodule update --init --recursive

• After changing branches (either in the root project or in submodule), use the following command to update the checked out git branches

git pull --all --recurse-submodules

Details specific for deploying infrastructure from the NIST side

• Make sure that you have proper functional account set by iTac and OISM.
• For deployment from directory ./iac (Infrastructure as Code) do not refer directly to terraform engine. The AD dependency is initialized and maintained in ./iac/ter.sh script.
• Use ./iac/ter.sh (or ./ter.sh when inside ./iac directory) for any command that otherwise would call for using terraform.

IaC Deployment of the site to NIST infrastructure:

1. Initialize the terraform infrastructure:

   ./ter.sh init
   

2. Review option offered by make-script

   make
   

   Expected result should look similar to the following:

    TARGET                         DESCRIPTION
    help                           Show this help message
    init                           Init terraform  configuration
    plan                           Preview the Terraform plan
    apply                          Apply the Terraform plan
    refresh                        Refresh Terraform outputs
    build                          Build all dependencies
    clean                          Clean dependencies of all artifacts
    build-dashboard                Build the dashboard
    environment-dashboard          Produce dashboard environment files
    clean-dashboard                Clean dashboard build artifacts and environment files
    build-lambda                   Build the lambda source
    clean-lambda                   Clean lambda build artifacts
    connection-profile             Generate the connection profile for the given workspace
    clean-connection-profile       Clean the connection profile~`
   

3. To assure that he previous deployment(s) artifact do not block the new development during build it's advisable to begin by running:

make clean

4. Before deploying site, when an existing site has been functioning for a wile can cause deletion/destruction of certain objects. To make sure that you are aware of such events before applying your changes to the cloud infrastructure run the following command:

   make plan
   

   Pay special attention to messages in RED font simila to the following:

   # aws_s3_object.web-content["assets/index.1a2b3c4d5f.js"] will be destroyed
   

   In this particular example it is the dashboard site in its' JS-compiled form, which is expected. But watch out for potential storage objects that might have accumulated some information while deployed and could be destroyed by deployment. Such artifacts: e.g. databases, data-files, etc, which are not currently (April 2024) in the project architecture, but may become at a later date.

   Note: If such a change (DB or data-file addition to the project) were to happen these artifacts will possibly need backup and consequential post-deployment reinstallation or data repopulation from the said backup.

5. If the operations you expect from the Makefile script are not describing the "planning" for something you don't expect, deploy the cloud resources using the following command:

   make apply
   

   Note: you will be prompted during the process to type yes verbatim to finish the potentially destructive operation of the resources redeployment