mirror of
https://github.com/cisagov/manage.get.gov.git
synced 2025-08-03 00:12:16 +02:00
Create new stable environment (#367)
update documentation for environments and setup new stable environment
This commit is contained in:
Logan McDonald
GitHub
parent
80f8748f39
commit
6a54bf1ff4
16 changed files with 88 additions and 137 deletions
|
|
@ -16,16 +16,16 @@ Deployment_Node(aws, "AWS GovCloud", "Amazon Web Services Region") {
|
|||
System_Ext(cloudgov_logdrain, "logs.fr.cloud.gov", "ELK")
|
||||
Boundary(atob, "ATO boundary") {
|
||||
Deployment_Node(organization, "get.gov organization") {
|
||||
Deployment_Node(unstable, "unstable space") {
|
||||
System_Boundary(dashboard_unstable, "get.gov registrar") {
|
||||
Container(getgov_app_unstable, "Registrar Application", "Python, Django", "Delivers static HTML/CSS and forms")
|
||||
ContainerDb(dashboard_db_unstable, "Unstable PostgreSQL Database", "AWS RDS", "Stores agency information and reports")
|
||||
Deployment_Node(sandbox, "sandbox space") {
|
||||
System_Boundary(dashboard_sandbox, "get.gov registrar") {
|
||||
Container(getgov_app_sandbox, "Registrar Application", "Python, Django", "Delivers static HTML/CSS and forms")
|
||||
ContainerDb(dashboard_db_sandbox, "sandbox PostgreSQL Database", "AWS RDS", "Stores agency information and reports")
|
||||
}
|
||||
}
|
||||
Deployment_Node(staging, "staging space") {
|
||||
System_Boundary(dashboard_staging, "get.gov registrar") {
|
||||
Container(getgov_app_staging, "Registrar Application", "Python, Django", "Delivers static HTML/CSS and forms")
|
||||
ContainerDb(dashboard_db_staging, "Staging PostgreSQL Database", "AWS RDS", "Stores agency information and reports")
|
||||
Deployment_Node(stable, "stable space") {
|
||||
System_Boundary(dashboard_stable, "get.gov registrar") {
|
||||
Container(getgov_app_stable, "Registrar Application", "Python, Django", "Delivers static HTML/CSS and forms")
|
||||
ContainerDb(dashboard_db_stable, "stable PostgreSQL Database", "AWS RDS", "Stores agency information and reports")
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -34,7 +34,7 @@ Deployment_Node(aws, "AWS GovCloud", "Amazon Web Services Region") {
|
|||
}
|
||||
|
||||
' Logs flow
|
||||
Rel(staging, cloudgov_logdrain, "logs to", "stdout/stderr")
|
||||
Rel(stable, cloudgov_logdrain, "logs to", "stdout/stderr")
|
||||
Rel(team, cloudgov_logdrain, "reviews logs", "https (443)")
|
||||
|
||||
Rel(team, cloudgov_uaa, "authenticates with", "https (443)")
|
||||
|
|
@ -54,12 +54,12 @@ Rel(github_repo, github_actions_deploy, "pushes to main trigger deployment")
|
|||
Rel(team, github_repo, "commits code, makes pull-request, approves PRs", "https (443)")
|
||||
Rel(github_actions_deploy, cloudgov_controller, "pushes code, invokes tasks", "https (443)")
|
||||
Rel(github_actions_deploy, cloudgov_router, "runs smoke tests on URLs", "https (443)")
|
||||
Rel(cloudgov_controller, staging, "provisions/operates apps and services", "admin access limited")
|
||||
Rel(cloudgov_controller, unstable, "provisions/operates apps and services")
|
||||
Rel(cloudgov_controller, stable, "provisions/operates apps and services", "admin access limited")
|
||||
Rel(cloudgov_controller, sandbox, "provisions/operates apps and services")
|
||||
|
||||
Rel(getgov_app_staging, dashboard_db_staging, "reads agency info, reads/writes reports, ", "postgres (5432)")
|
||||
Rel(getgov_app_unstable, dashboard_db_unstable, "reads agency info, reads/writes reports, ", "postgres (5432)")
|
||||
Rel(getgov_app_stable, dashboard_db_stable, "reads agency info, reads/writes reports, ", "postgres (5432)")
|
||||
Rel(getgov_app_sandbox, dashboard_db_sandbox, "reads agency info, reads/writes reports, ", "postgres (5432)")
|
||||
|
||||
Rel(cloudgov_router, getgov_app_staging, "proxies to", "https GET/POST (443)")
|
||||
Rel(cloudgov_router, getgov_app_stable, "proxies to", "https GET/POST (443)")
|
||||
|
||||
@enduml
|
||||
|
|
@ -28,7 +28,7 @@ Secrets (for example, if you'd like to have a working Login.gov authentication)
|
|||
DJANGO_SECRET_LOGIN_KEY="<...>"
|
||||
```
|
||||
|
||||
You'll need to create the `.env` file yourself. Get the secrets from Cloud.gov by running `cf env getgov-unstable`. More information is available in [rotate_application_secrets.md](../operations/runbooks/rotate_application_secrets.md).
|
||||
You'll need to create the `.env` file yourself. Get the secrets from Cloud.gov by running `cf env getgov-YOURSANDBOX`. More information is available in [rotate_application_secrets.md](../operations/runbooks/rotate_application_secrets.md).
|
||||
|
||||
## Viewing Logs
|
||||
|
||||
|
|
@ -134,10 +134,6 @@ Within the `registrar/assets` folder, the `_theme` folder contains three files i
|
|||
|
||||
You can also compile the sass at any time using `npx gulp compile`. Similarly, you can copy over other static assets (images and javascript files), using `npx gulp copyAssets`.
|
||||
|
||||
## Nightly Builds
|
||||
|
||||
We run a deploy to staging from `main` nightly. You can see the deploys [here](https://github.com/cisagov/getgov/actions/workflows/deploy.yaml).
|
||||
|
||||
## Finite State Machines
|
||||
|
||||
In an effort to keep our domain logic centralized, we are representing the state of
|
||||
|
|
|
|||
|
|
@ -5,46 +5,46 @@ You can connect to a Cloud.gov database using the
|
|||
After installing it, use the command
|
||||
|
||||
```shell
|
||||
cf connect-to-service getgov-unstable getgov-unstable-databse
|
||||
cf connect-to-service getgov-SANDBOXNAME getgov-SANDBOXNAME-databse
|
||||
```
|
||||
|
||||
to get a `psql` shell on the `unstable` environment's database.
|
||||
to get a `psql` shell on the sandbox environment's database.
|
||||
|
||||
## Running Migrations
|
||||
|
||||
When new code changes the database schema, we need to apply Django's migrations.
|
||||
We can run these using CloudFoundry's tasks to run the `manage.py migrate`
|
||||
command in the correct environment. For the `unstable` environment, developers
|
||||
command in the correct environment. For any developer environment, developers
|
||||
can manually run the task with
|
||||
|
||||
```shell
|
||||
cf run-task getgov-unstable --command 'python manage.py migrate' --name migrate
|
||||
cf run-task getgov-SANDBOXNAME --command 'python manage.py migrate' --name migrate
|
||||
```
|
||||
|
||||
Optionally, load data from fixtures as well
|
||||
|
||||
```shell
|
||||
cf run-task getgov-unstable --wait --command 'python manage.py load' --name loaddata
|
||||
cf run-task getgov-SANDBOXNAME --wait --command 'python manage.py load' --name loaddata
|
||||
```
|
||||
|
||||
For the `staging` environment, developers don't have credentials so we need to
|
||||
For the `stable` environment, developers don't have credentials so we need to
|
||||
run that command using Github Actions. Go to
|
||||
<https://github.com/cisagov/getgov/actions/workflows/migrate.yaml> and select
|
||||
the "Run workflow" button, making sure that `staging` is selected.
|
||||
the "Run workflow" button, making sure that `stable` is selected.
|
||||
|
||||
## Getting data for fixtures
|
||||
|
||||
To run the `dumpdata` command, you'll need to ssh to a running container. `cf run-task` is useless for this, as you will not be able to see the output.
|
||||
|
||||
```shell
|
||||
cf ssh getgov-unstable
|
||||
cf ssh getgov-SANDBOXNAME
|
||||
/tmp/lifecycle/shell # this configures your environment
|
||||
./manage.py dumpdata
|
||||
```
|
||||
|
||||
## Dropping and re-creating the database
|
||||
|
||||
For `unstable`, it might be necessary to start the database over from scratch.
|
||||
For your sandbox environment, it might be necessary to start the database over from scratch.
|
||||
The easiest way to do that is `DROP DATABASE ...` followed by `CREATE DATABASE
|
||||
...`. In the `psql` shell, first run the `\l` command to see all of the
|
||||
databases that are present:
|
||||
|
|
|
|||
|
|
@ -36,23 +36,13 @@ Binding the database in `manifest-<ENVIRONMENT>.json` automatically inserts the
|
|||
|
||||
# Deploy
|
||||
|
||||
We have two environments: `unstable` and `staging`. Developers can deploy locally to unstable whenever they want. However, only our CD service can deploy to `staging`, and it does so on every commit to `main`. This is to ensure that we have a "golden" environment to point to, and can still test things out in an unstable space. You should make sure all of the USWDS assets are compiled and collected before deploying to unstable. To deploy locally to `unstable`:
|
||||
We have two types of environments: developer "sandboxes" and `stable`. Developers can deploy locally to their sandbox whenever they want. However, only our CD service can deploy to `stable`, and it does so when we make tagged releases of `main`. This is to ensure that we have a "golden" environment to point to, and can still test things out in a sandbox space. You should make sure all of the USWDS assets are compiled and collected before deploying to your sandbox. To deploy locally to `sandbox`:
|
||||
|
||||
```bash
|
||||
# Compile and collect the assets
|
||||
docker-compose run node npx gulp compile
|
||||
docker-compose run node npx gulp copyAssets
|
||||
docker-compose run app ./manage.py collectstatic
|
||||
|
||||
# Deploy to unstable
|
||||
cf target -o cisa-getgov-prototyping -s unstable
|
||||
cf push getgov-unstable -f ops/manifests/manifest-unstable.yaml
|
||||
cf run-task getgov-unstable --command 'python manage.py migrate' --name migrate
|
||||
```
|
||||
Alternatively, you could run the `deploy.sh` script in the `/src` directory to build the assets and deploy to `unstable`. Similarly, you could run `build.sh` script to just compile and collect the assets without deploying.
|
||||
For ease of use, you can run the `deploy.sh <sandbox name>` script in the `/src` directory to build the assets and deploy to your sandbox. Similarly, you could run `build.sh <sandbox name>` script to just compile and collect the assets without deploying.
|
||||
|
||||
Your sandbox space should've been setup as part of the onboarding process. If this was not the case, please have an admin follow the instructions [here](../../.github/ISSUE_TEMPLATE/developer-onboarding.md#setting-up-developer-sandbox).
|
||||
|
||||
## Serving static assets
|
||||
We are using [WhiteNoise](http://whitenoise.evans.io/en/stable/index.html) plugin to serve our static assets on cloud.gov. This plugin is added to the `MIDDLEWARE` list in our apps `settings.py`.
|
||||
|
||||
Note that it’s a good idea to run `collectstatic` locally or in the docker container before pushing files up to `unstable`. This is because `collectstatic` relies on timestamps when deciding to whether to overwrite the existing assets in `/public`. Due the way files are uploaded, the compiled css in the `/assets/css` folder on `unstable` will have a slightly earlier timestamp than the files in `/public/css`, and consequently running `collectstatic` on`unstable` will not update `public/css` as you may expect. For convenience, both the `deploy.sh` and `build.sh` scripts will take care of that.
|
||||
Note that it’s a good idea to run `collectstatic` locally or in the docker container before pushing files up to your sandbox. This is because `collectstatic` relies on timestamps when deciding to whether to overwrite the existing assets in `/public`. Due the way files are uploaded, the compiled css in the `/assets/css` folder on your sandbox will have a slightly earlier timestamp than the files in `/public/css`, and consequently running `collectstatic` on your sandbox will not update `public/css` as you may expect. For convenience, both the `deploy.sh` and `build.sh` scripts will take care of that.
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ Where `credentials-<ENVIRONMENT>.json` looks like:
|
|||
|
||||
(Specific credentials are mentioned below.)
|
||||
|
||||
You can see the current environment with `cf env <APP>`, for example `cf env getgov-unstable`.
|
||||
You can see the current environment with `cf env <APP>`, for example `cf env getgov-stable`.
|
||||
|
||||
The commands `cups` and `uups` stand for [`create user provided service`](https://docs.cloudfoundry.org/devguide/services/user-provided.html) and `update user provided service`. User provided services are the way currently recommended by Cloud.gov for deploying secrets. The user provided service is bound to the application in `manifest-<ENVIRONMENT>.json`.
|
||||
|
||||
|
|
@ -30,8 +30,8 @@ To rotate secrets, create a new `credentials-<ENVIRONMENT>.json` file, upload it
|
|||
Example:
|
||||
|
||||
```bash
|
||||
cf update-user-provided-service getgov-credentials -p credentials-unstable.json
|
||||
cf restage getgov-unstable --strategy rolling
|
||||
cf update-user-provided-service getgov-credentials -p credentials-stable.json
|
||||
cf restage getgov-stable --strategy rolling
|
||||
```
|
||||
|
||||
Non-secret environment variables can be declared in `manifest-<ENVIRONMENT>.json` directly.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue