This is the web portal for managing Staff Device DNS / DHCP servers
Assuming you have been granted necessary access permissions to the Shared Service Account, please follow the NVVS DevOps best practices provided step-by-step guide to configure your AWS Vault and AWS Cli with AWS SSO.
- Clone the repository
- Copy
.env.example
to.env
- Modify the
.env
file and provide values for variables as below:
Variables | How? |
---|---|
AWS_PROFILE= |
your AWS-CLI profile name for the Shared Services AWS account. Check this guide if you need help. |
SHARED_SERVICES_ACCOUNT_ID= |
Account ID of the MoJO Shared Services AWS account. |
REGISTRY_URL= |
<MoJO Development AWS Account ID> .dkr.ecr.eu-west-2.amazonaws.com |
ENV= |
Your Terraform namespace from the DNS DHCP Infrastructure repo. |
- Copy
.env.development
to.env.<your terraform namespace>
This repo is dependant on a locally running dhcp network. This is so that the admin app can query the dhcp api without timing out.
- Clone the repository here
- Follow the instructions in the cloned repository to run the dhcp server
- Navigate back to this repo
-
If this is the first time you have setup the project:
-
Build the base containers
make build-dev
-
Setup the database
make db-setup
-
-
Start the application
$ make serve
- Setup the test database
make db-setup
- Run the entire test suite
make test
To run individual tests:
- Shell onto a test container
ENV=test make shell
- Run the test file or folder
bundle exec rspec path/to/spec/file
There are two utility scripts in the ./scripts
directory to:
- Migrate the database schema
- Deploy new tasks into the service
The deploy
command is wrapped in a Makefile. It calls ./scripts/deploy
which schedules a zero downtime phased deployment in ECS.
It doubles the currently running tasks and briefly serves traffic from the new and existing tasks in the service. The older tasks are eventually decommissioned, and production traffic is gradually shifted over to only the new running tasks.
On CI this command is executed from the buildspec.yml file after migrations and publishing the new image to ECR has been completed.
The ECS infrastructure is managed by Terraform. The name of the cluster and service are outputs from the Terraform apply. These values are published to SSM Parameter Store, when this container is deployed it pulls those values from Parameter Store and sets them as environment variables.
The deploy script references these environment variables to target the ECS Admin service and cluster. This is to avoid depending on the hardcoded strings.
The build pipeline assumes a role to access the target AWS account.
- Export the following configurations as an environment variable.
export DHCP_DNS_TERRAFORM_OUTPUTS='{
"admin": {
"ecs": {
"cluster_name": "[TARGET_CLUSTER_NAME]",
"service_name": "[TARGET_SERVICE_NAME]"
}
}
}'
This mimics what happens on CI where this environment variable is already set.
When run locally, you need to target the AWS account directly with AWS Vault.
- Schedule the deployment
aws-vault exec [target_aws_account_profile] -- make deploy
The AWS RDS SSL certificate is due to expire August 22, 2024. See the documentation for information on updating the certificate closer to the date.
To update the certificate, update the Dockerfile to use the new intermediate (region specific) certificate (found here), and update the config/database.yml
to point to the new certificate file path.
For information on how to perform the data import before network cutover, please see the documentation.
Details of how to perform a new Site Import from CSV.
- CI Terraform code - staff-device-dns-dhcp-admin
- Terraform module - module "pttp-infrastructure-ci-pipeline-dns-dhcp-admin-container"
- AWS Account - MOJ Official (Shared Services)
- Pipeline "Staff-Device-Admin-Portal"
- Dependabot currently does not support a container image monitoring solution only for the Docker container ruby:3.2.2-alpine3.16, this alpine images needs to be updated manually.
Developer tools (alpine-sdk, ruby-dev) have been added to the container to facilitate Gem version updates. To update a Gem version:
-
Build and run tests to make sure you have a baseline of the application running well.
-
Build the dev container
make build-dev
- Run the application with an interactive shell
make shell-dev
- Change the version in the Gemfile
- In the interactive shell run a bundle update for the Gem being updated, e.g.
bundle update rails
-
Check that the Gemfile.lock has the new version
-
Destroy container, re-build and run tests.