Skip to content

Conversation

TheOneFromNorway
Copy link
Contributor

Separate deployment of application and infrastructure changes

This enables separating out infrastructure components into a separate repository. Some cleanup is required post deployment, this is not done at this stage to ensure backwards compatibility of the infrastructure.

  • Replace the task definition creation with a template version
    • The template version will be picked up and modified during the ECS deployment workflow
  • Remove redundant resources/outputs
    • We no longer need outputs/s3 buckets since we will be using AWS provided github actions for deployment
  • Move application-specific variables into a config file (to be used in deployment)
    • A new SSM resources is introduced that will allow tweaking
      parameters without redeployment
  • Create ECS deployment specific role in AWS
    • Limits permission scope for production deployments
    • Adheres to the principle of least privilege
    • Separates permissions between application deployments and infrastructure changes

Ticket: MAV-1657

@TheOneFromNorway TheOneFromNorway requested review from a team as code owners August 28, 2025 14:59
@TheOneFromNorway TheOneFromNorway added the infrastructure Related to infrastructure changes label Aug 28, 2025
@TheOneFromNorway TheOneFromNorway force-pushed the separate_app_and_infra_deployments branch from 6a60f17 to 5aec2b4 Compare August 28, 2025 15:39
@TheOneFromNorway TheOneFromNorway force-pushed the separate_app_and_infra_deployments branch 4 times, most recently from 467e3e4 to 02f42b3 Compare September 2, 2025 12:33
@tvararu tvararu force-pushed the separate_app_and_infra_deployments branch 2 times, most recently from 8fc8c72 to f9c0ab6 Compare September 11, 2025 09:08
@tvararu tvararu marked this pull request as draft September 11, 2025 09:13
@tvararu tvararu force-pushed the separate_app_and_infra_deployments branch from bebba7b to 2feac96 Compare September 11, 2025 10:21
@tvararu
Copy link
Member

tvararu commented Sep 11, 2025

@thomasleese this PR will cause some minor conflicts with your #4564 because I also removed some good_job references when bumping the infrastructure workflows.

@tvararu tvararu marked this pull request as ready for review September 11, 2025 10:23
@tvararu tvararu force-pushed the separate_app_and_infra_deployments branch from 2feac96 to 29bed06 Compare September 11, 2025 10:23
- Replace the task definition creation with a teamplate version
  - The template version will be picked up and modified during the ECS deployment workflow
- Remove redundant resources/outputs
  - We no longer need outputs/s3 buckets since we will be using AWS provided github actions for deployment
- Move application-specific variables into a config file (to be used in deployment)
  - A new SSM resources is introduced that will allow tweaking
    parameters without redeployment
- These variables have been moved to a config file to be inserted into the task definition on deploy
- Modify the docker-start script to turn the comma separated key-value pairs in the ENV_VARS secret into environment variables
- Limits permission scope for production deployments
- Adheres to the principle of least privilege
- Separates permissions between application deployments and infrastructure changes
- The application can now be deployed independently from infrastructure changes
  - Create SSM parameter population script in python so it can also be used between services located in different repositories (e.g. like reporting service)
- Create a new task definition based on the templated version created by infrastructure deploy
- Create appspec.yaml template for handling codedeploys
- Remove redundant parameters from terraform deployment
- This is required due to the new template-mechanism
- Adheres to split between application and infrastructure
- Remnant from database migration
- Dashes instead of underline for github pipelines
- Clear separation of concerns in account tf stack
- Remove unnecessary `app_version` input
TheOneFromNorway and others added 10 commits September 12, 2025 14:06
- Docker entry point is top level so this is where the environment
  variables must be extracted
- Otherwise shelling into the container and also db:seed does not
  execute properly
Also format some yml whitespace using prettier.
Matches the one in .tool-versions.
The workflow always replaces the db cluster, so the check isn't
necessary anymore.
Update the title, pass in `git_ref_to_deploy`, only
`build-and-push-image` image if an `image_tag` isn't specified, and
ensure that `yq` is installed before using it.
Matches the convention that GitHub actions generally use.
We're now fully relying on sidekiq, so don't need this anymore.
Skip building if an `image-tag` is passed in, and rename the
`deploy-sidekiq` subtask for consistency.
Use kebab-case for variables and remove an unused env var.
We don't deploy this worker anymore.
- Agreed to change the setup to control the set of tunable variables
  only on infrastructure side
- Parameter store locations for the variables are created, but only
  populated with a CHANGE_ME parameter
- This is for use with non-prod systems only
- The docker entry point now unsets any variables with CHANGE_ME values
- Workflow updated to reflect new secret/aws variable management setup
- python scripts/dependency removed as no scripting is needed for
  secrets in the new setup
@TheOneFromNorway TheOneFromNorway force-pushed the separate_app_and_infra_deployments branch from ac891d0 to 4e6a0c9 Compare September 15, 2025 12:03
Copy link

Quality Gate Failed Quality Gate failed

Failed conditions
13 Security Hotspots

See analysis details on SonarQube Cloud

Comment on lines +127 to +129
non_empty_parameter_groups = toset([
for key, value in local.parameter_store_variables : key if length(concat(local.secret_arns[key], local.parameter_store_paths[key])) > 0
])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The non_empty_parameter_groups is just used to dynamically create dedicated iam roles and policies for "CORE" and "REPORTING" right? I would prefer to create the iam resources explicitly and avoid this complex construction

default = "Unknown"
nullable = false
}

locals {
is_production = var.environment == "production"
parameter_store_variables = tomap({
Copy link
Contributor

@bogsi17 bogsi17 Sep 19, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the explicit casts to map are not necessary, also in the other places further down in this file

Comment on lines -195 to -199
MAVIS__ACADEMIC_YEAR_TODAY_OVERRIDE = var.academic_year_today_override
MAVIS__ACADEMIC_YEAR_NUMBER_OF_PREPARATION_DAYS = var.academic_year_number_of_preparation_days
MAVIS__PDS__ENQUEUE_BULK_UPDATES = var.enable_pds_enqueue_bulk_updates ? "true" : "false"
MAVIS__PDS__RATE_LIMIT_PER_SECOND = var.pds_rate_limit_per_second
GOOD_JOB_MAX_THREADS = 5
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How are these values now defined for production?

valueFrom = var.rails_master_key_path
}
], local.parameter_store_config_list)
task_secrets = tomap({
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is the RAILS_MASTER_KEY not added as task secret anymore?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
infrastructure Related to infrastructure changes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants