beenull/ente
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

npx prettier --config ../docs/.prettierrc.json --write '**/*.md'

Browse source
This commit is contained in:
Manav Rathi 2024-03-14 22:33:00 +05:30
parent dc29ab496f
commit 12bdbcfbdc
No known key found for this signature in database
2 changed files with 27 additions and 26 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
infra/copycat-db/README.md
View file

@ -11,8 +11,8 @@ when it creates a new one to avoid indefinite retention.
In production the service runs as a cron job, scheduled using a systemd timer. In production the service runs as a cron job, scheduled using a systemd timer.
> These backups are in addition to the regular snapshots that we take, and are > These backups are in addition to the regular snapshots that we take, and are
> meant as a second layer of replication. For more details, see our [Reliability > meant as a second layer of replication. For more details, see our
> and Replication Specification](https://ente.io/reliability). > [Reliability and Replication Specification](https://ente.io/reliability).
## Quick help ## Quick help
@ -60,7 +60,8 @@ then the Docker image falls back to using `pg_dump` (as outlined next).
Not needed in production when taking a backup (since we use the Scaleway CLI to Not needed in production when taking a backup (since we use the Scaleway CLI to
take backups in production). take backups in production).
These are used when testing a backup using `pg_dump`, and when restoring backups. These are used when testing a backup using `pg_dump`, and when restoring
backups.
##### RCLONE_CONFIG ##### RCLONE_CONFIG
@ -69,9 +70,9 @@ to use to save the backups, and the credentials to to access it.
Specifically, the config file contains two remotes: Specifically, the config file contains two remotes:
* The bucket itself, where data will be stored. - The bucket itself, where data will be stored.
* A "crypt" remote that wraps the bucket by applying client side encryption. - A "crypt" remote that wraps the bucket by applying client side encryption.
The configuration file will contain (lightly) obfuscated versions of the The configuration file will contain (lightly) obfuscated versions of the
password, and as long as we have the configuration file we can continue using password, and as long as we have the configuration file we can continue using
@ -163,9 +164,9 @@ you wish to force the job to service immediately
## Updating ## Updating
To update, run the [GitHub To update, run the
workflow](../../.github/workflows/copycat-db-release.yaml) to build and push the [GitHub workflow](../../.github/workflows/copycat-db-release.yaml) to build and
latest image to our Docker Registry, then restart the systemd service on the push the latest image to our Docker Registry, then restart the systemd service
instance on the instance
sudo systemctl restart copycat-db sudo systemctl restart copycat-db

34
infra/services/README.md
View file

@ -2,26 +2,26 @@
"Services" are Docker images we run on our instances and manage using systemd. "Services" are Docker images we run on our instances and manage using systemd.
All our services (including museum itself) follow the same All our services (including museum itself) follow the same pattern:
pattern:
* They're run on vanilla Ubuntu instances. The only expectation they have is for - They're run on vanilla Ubuntu instances. The only expectation they have is
Docker to be installed. for Docker to be installed.
* They log to fixed, known, locations - `/root/var/log/foo.log` - so that these - They log to fixed, known, locations - `/root/var/log/foo.log` - so that
logs can get ingested by Promtail if needed. these logs can get ingested by Promtail if needed.
* Each service should consist of a Docker image (or a Docker compose file), and a - Each service should consist of a Docker image (or a Docker compose file),
systemd unit file. and a systemd unit file.
* To start / stop / schedule the service, we use systemd. - To start / stop / schedule the service, we use systemd.
* Each time the service runs it should pull the latest Docker image, so there is - Each time the service runs it should pull the latest Docker image, so there
no separate installation/upgrade step needed. We can just restart the service, is no separate installation/upgrade step needed. We can just restart the
and it'll use the latest code. service, and it'll use the latest code.
* Any credentials and/or configuration should be read by mounting the - Any credentials and/or configuration should be read by mounting the
appropriate file from `/root/service-name` into the running Docker container. appropriate file from `/root/service-name` into the running Docker
container.
## Systemd cheatsheet ## Systemd cheatsheet
@ -46,9 +46,9 @@ service file (_note_: starting on boot requires one more step later):
WantedBy=multi-user.target WantedBy=multi-user.target
``` ```
Copy the service file to the instance where we want to run the service. Copy the service file to the instance where we want to run the service. Services
Services might also have some additional configuration or env files, also copy might also have some additional configuration or env files, also copy those to
those to the instance. the instance.
```sh ```sh
scp services/example.service example.env <instance>: scp services/example.service example.env <instance>: