This repository contains instructions and configuration files for EDGI’s deployment of the Web Monitoring project. Unlike most other software repos, this one contains deployment configurations that are specific to EDGI’s setup. If you’d like to deploy your own copy of the Web Monitoring project, you can use the content of this repo as a general guide or fork and edit it.
We currently run all our services in AWS:
- Services and Scheduled Jobs are managed by Kubernetes. See the
kubernetesdirectory for details. - We use a handful of AWS services like S3 and RDS. See the
manually-manageddirectory for details.
Incident Reports: When major problems happen in production, we try and write up incident reports that describe what happened and how the problem was addressed. You can find these in the incidents directory.
We separate the process of shipping new code into two parts: releases (semi-automatic) and deploys (manual).
Most of our repos automatically publish new releases when code is pushed to the release branch.
-
Docker images get published to https://hub.docker.com/u/envirodgi. Images are tagged with the SHA-1 of the git commit they were built from. For example, the image
envirodgi/db-rails-server:ddc246819a039465e7711a1abd61f67c14b7a320was built from commitddc246819a039465e7711a1abd61f67c14b7a320in web-monitoring-db. -
Packages/libraries get published to their relevant registries (e.g. PyPI or NPM).
We usually create merge commits on the release branch that note the PRs included in the release or any other relevant notes (e.g. Release #503, #504). Since most of our code is not widely distributed, we don’t currently include release notes that describe the changes in more detail.
Services running in Kubernetes always use the Docker images we release as above. Inside our Kubernetes cluster, we manage two namespaces: staging and production. The staging namespace has fewer instances of most services and operates against a smaller database that we might reset from time to time. It’s good for testing things. We typically deploy new code to both at the same time, but occasionally send new code only to staging or use a configuration variable to only turn the new code on in staging if it needs more rigorous testing. To update Kubernetes:
-
When we are ready to deploy code, trigger a release as described above.
-
Update the Kubernetes configuration files in this repo to point to the new images. Adjust secrets and environment variables as appropriate for the new release.
-
Use the
kubectlcommand-line tool to update our Kubernetes cluster with the new configuration files.
Manually managed servers (for our scheduled jobs) tend to each have their own process. Check the manually-managed directory for details on each one.
Manually managed AWS services like RDS or S3 are also described in manually-managed.
While EDGI strives to work as much in the open as possible, a production deployment of software necessarily involves some secret data like account credentials. We maintain secret data in a private Git repo stored on Keybase, and layer that data on top of what’s in this repo. Get in touch with a project maintainer on Slack if you need access to it.
This repository falls under EDGI's Code of Conduct.
This is an open-source project, and works because of contributors like you! See our contributing guidelines to find out how you can help.
Copyright (C) 2017-2023 Environmental Data and Governance Initiative (EDGI)
This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, version 3.0.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
See the LICENSE file for details.