The top-level module should be named "atat" inside the Docker container.
Confusingly, the application code is inside "/opt/atat/atst", with the
top-level application module at "/opt/atat/atst/atat". That directory
path is a holdover from when this application was a series of
microservices. Eventually we should truncate it to something sensible
and descriptive.
uWGI was generating warnings about being unable to find plugin files we
specify. To fix this, I've added uwsgi-python3 to the list of Alpine
packages we install in the container specified the plugins directory in
the uWSGI config. The updated uWSGI ConfigMap has been applied to the
staging cluster, which eliminated the warning about the logfile plugin.
The remaining warning about the python3 plugin will be eliminated once
the new container built by this branch is deployed.
For local development, we symlink the USWDS fonts from the npm installed
copy into our static directory. This causes problems for the Docker
build because it is not expecting to find a pre-existing "static/fonts"
directory. This forcibly removes any existing "static/fonts" directory
to fix the issue.
The CircleCI Orbs were useful for getting started, but now that we only
have to deploy to one provider our pipeline should be tailored to
efficiently push to just that environment. This inlines all the relevant
pieces from the Orbs we were relying on as bash/sh commands instead.
This builds the Docker images upfront. Since we have a multi-stage
Dockerfile, it builds the first stage as a separate image and then
proceeds to build the complete image. This is done so that the first
stage (called "builder") can be used for testing. It retains executables
like pipenv that we need to install development dependencies needed for
tests.
Other notes:
- CircleCI does not persist Docker images between jobs. As a
work-around, we use the CircleCI caching mechanism to create a named
cache with *.tar copies of the images. Subsequent jobs use the cache
and load the images.
- Both the test and integration-tests jobs need to make minor
modifications to the container to run correctly. The test job needs to
install the development Python dependencies, and the integration-tests
job needs to rebuild the JS bundle so that it uses the mock uploader
(the container is build to use the Azure uploader by default).
- The test and integration-tests jobs run in parallel.
- This adjusts the Dockerfile so that the TZ environment variable is set
for both stages of the build.
This applies configuration changes for the Flask app and adds changes to
the Dockerfile so that the build can make a CSP-specific JS bundle. It
adds `write_dotenv` script that creates the appropriate `.env` file for
the `parcel` bundler depending on how the `CSP` environment variable is
set.
- Configure K8s environment variables for Flask CSP usage
- Supply default CSP config setting to Flask app
- Declare the CSP arg in the Dockerfile
- Supply extra Docker build args to CD
- Fix top-level reference to boto3 in file_upload module
- Add back missing sample NGINX config for docker-compose build
- Fix some python formatting and import issues
- Fix dockerfile to include sync-crls script
- Adjust sync-crls script to use paths and CLI tools available in the
Docker container
Add CircleCI config for both CSPs to:
- build the Docker image and push it to the registry
- run a short-lived k8s job to apply migrations and see data
- update the images for the Flask pods and rq worker pods
Most build tools (i.e., the CircleCI Orbs) expect a Dockerfile in the
repo root. Rather than have to configure an exception everywhere, put it
where most people/tools expect it to be.
