From 12bdbcfbdc8845aadf49c54f7e78b4db7d3eff90 Mon Sep 17 00:00:00 2001 From: Manav Rathi Date: Thu, 14 Mar 2024 22:33:00 +0530 Subject: [PATCH] npx prettier --config ../docs/.prettierrc.json --write '**/*.md' --- infra/copycat-db/README.md | 19 ++++++++++--------- infra/services/README.md | 34 +++++++++++++++++----------------- 2 files changed, 27 insertions(+), 26 deletions(-) diff --git a/infra/copycat-db/README.md b/infra/copycat-db/README.md index 4310c73d8..266bd4e6e 100644 --- a/infra/copycat-db/README.md +++ b/infra/copycat-db/README.md @@ -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 diff --git a/infra/services/README.md b/infra/services/README.md index 17fb6ce87..8c3a3d569 100644 --- a/infra/services/README.md +++ b/infra/services/README.md @@ -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 :