-
Notifications
You must be signed in to change notification settings - Fork 10
Separate app and infra deployments #4432
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: next
Are you sure you want to change the base?
Conversation
6a60f17
to
5aec2b4
Compare
467e3e4
to
02f42b3
Compare
8fc8c72
to
f9c0ab6
Compare
bebba7b
to
2feac96
Compare
@thomasleese this PR will cause some minor conflicts with your #4564 because I also removed some |
2feac96
to
29bed06
Compare
- 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
- 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.
29bed06
to
c9c17f5
Compare
- 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
ac891d0
to
4e6a0c9
Compare
|
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 | ||
]) |
There was a problem hiding this comment.
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({ |
There was a problem hiding this comment.
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
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 |
There was a problem hiding this comment.
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({ |
There was a problem hiding this comment.
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?
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.
parameters without redeployment
Ticket: MAV-1657