This is not the certificate setup we will use in production. I'd like to
merge this configuration as a reference point because this is the
easiest way to handle manual LetsEncrypt verification within the
cluster.
This allows NGINX to serve static files over HTTP from the
".well-known/acme-challenge" directory, which is necessary for certbot
validation of domain ownership.
Adds a [kustomize](https://github.com/kubernetes-sigs/kustomize) overlay
for a new staging environment. Additionally, adds environment variables
in the place of certain pieces of information that need to be templated.
The K8s README ("deploy/README.md") has been updated to reflect the new
method for applying config.
This commit also removes the configuration for the AWS cluster and
references to AWS in the README.
This will allow us to force SSL connections to the database in
production by setting two values:
- PGSSLMODE should be set to "verify-full". This forces the client to
verify the server against a known CA: https://www.postgresql.org/docs/10/libpq-ssl.html
- PGSSLROOTCERT should be set to the path of the public cert for the
relevant CA.
When the database connection is made, these values are passed to the
adapter. For local development, PGSSLMODE is set to "prefer" and
PGSSLROOTCERT is left unset.
Kubernetes config has been added to maintain the root CAs for both Azure
and AWS as k8s ConfigMap objects. These are mounted into the containers
and referenced by PGSSLROOTCERT in the container environment.
We will run a separate pod for the beat worker. There should only ever
be a single beat worker (to avoid redundant work) so the number of
replicas needs to be managed independently.
This adds both the Kubernetes config for the new pod and additional
CircleCI config to swap a new image into the pod during CD.
This will allow Kubernetes resources that only pull images occasionally
(i.e., k8s jobs) to point to a static tag name, "latest", that is updated
regularly. It also means we can refer to that image in the k8s config
tracked in the repo, instead of out-of-date images.
Celery provides a more robust set of queueing options for both tasks and
worker processes. Updates include:
- infrastructure necessary to run Celery, including celery entrypoint
- backgrounded functions are now imported directly from atst.jobs
- update tests as-needed
- update kubernetes worker pod command
