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.
> 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
> and Replication Specification](https://ente.io/reliability).
> meant as a second layer of replication. For more details, see our
> [Reliability and Replication Specification](https://ente.io/reliability).
## 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
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
@ -69,9 +70,9 @@ to use to save the backups, and the credentials to to access it.
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
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
To update, run the [GitHub
workflow](../../.github/workflows/copycat-db-release.yaml) to build and push the
latest image to our Docker Registry, then restart the systemd service on the
instance
To update, run the
[GitHub workflow](../../.github/workflows/copycat-db-release.yaml) to build and
push the latest image to our Docker Registry, then restart the systemd service
on the instance
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.
All our services (including museum itself) follow the same
pattern:
All our services (including museum itself) follow the same pattern:
* They're run on vanilla Ubuntu instances. The only expectation they have is for
Docker to be installed.
- They're run on vanilla Ubuntu instances. The only expectation they have is
for Docker to be installed.
* They log to fixed, known, locations - `/root/var/log/foo.log` - so that these
logs can get ingested by Promtail if needed.
- They log to fixed, known, locations - `/root/var/log/foo.log` - so that
these logs can get ingested by Promtail if needed.
* Each service should consist of a Docker image (or a Docker compose file), and a
systemd unit file.
- Each service should consist of a Docker image (or a Docker compose 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
no separate installation/upgrade step needed. We can just restart the service,
and it'll use the latest code.
- Each time the service runs it should pull the latest Docker image, so there
is no separate installation/upgrade step needed. We can just restart the
service, and it'll use the latest code.
* Any credentials and/or configuration should be read by mounting the
appropriate file from `/root/service-name` into the running Docker container.
- Any credentials and/or configuration should be read by mounting the
appropriate file from `/root/service-name` into the running Docker
container.
## Systemd cheatsheet
@ -46,9 +46,9 @@ service file (_note_: starting on boot requires one more step later):
WantedBy=multi-user.target
```
Copy the service file to the instance where we want to run the service.
Services might also have some additional configuration or env files, also copy
those to the instance.
Copy the service file to the instance where we want to run the service. Services
might also have some additional configuration or env files, also copy those to
the instance.
```sh
scp services/example.service example.env <instance>: