From c161031d3bb91cafcf7a5aba8e84ad7153b520d1 Mon Sep 17 00:00:00 2001 From: decentral1se Date: Thu, 28 Mar 2024 17:14:44 +0100 Subject: [PATCH] docs: remove old cruft --- docs/abra/cheat-sheet.md | 8 -------- docs/maintainers/handbook.md | 2 +- docs/operators/handbook.md | 26 -------------------------- 3 files changed, 1 insertion(+), 35 deletions(-) diff --git a/docs/abra/cheat-sheet.md b/docs/abra/cheat-sheet.md index ffa729e..9c3a680 100644 --- a/docs/abra/cheat-sheet.md +++ b/docs/abra/cheat-sheet.md @@ -27,11 +27,6 @@ flags: `-f/--force`, `-C/--chaos` - `abra app rm --volumes $APPNAME` flags: `-f/--force`, `-V/--volumes` -### add/remove server -- `abra server add $SERVER` -- `abra server remove $SERVER` -flags: `-s/--server` - ### upgrade abra - `abra upgrade` flags: `--rc` @@ -74,6 +69,3 @@ As you can see we, we're selecting all recipes where category is "Utilities". `abra app ls -m -S |jq '[.[].apps[] | select(.status == "deployed") | del(.upgrade)]' |tv` The `del(.upgrade)` filter filters out available versions for the recipe in question for that row. It could be useful to leave in if you want a list of deployed apps that need an upgrade. - - - diff --git a/docs/maintainers/handbook.md b/docs/maintainers/handbook.md index 9f99cd1..d3c1d73 100644 --- a/docs/maintainers/handbook.md +++ b/docs/maintainers/handbook.md @@ -391,7 +391,7 @@ If you don't have time or are not an operator, reach out on our communication ch In the root of your recipe repository, run the following (if the folder doesn't already exist): ``` -mkdir -p releases +mkdir -p release ``` And then create a text file which corresponds to the version release, e.g. `1.1.0+5.9.0` and write some notes. `abra` will show these when another operator runs `abra app deploy` / `abra app upgrade`. diff --git a/docs/operators/handbook.md b/docs/operators/handbook.md index 65bc8b3..1a4bd40 100644 --- a/docs/operators/handbook.md +++ b/docs/operators/handbook.md @@ -205,20 +205,6 @@ At time of writing (Jan 2022), we think there is a limitation in our design whic This may be possible to overcome if someone really needs it, we encourage people to investigate. We've found that often there are limitations in the actual software which don't support this anyway and several of the current operators simply use a new domain per app. -## Creating a new server - -!!! warning "Creating servers with Abra once upon a time" - - Previous versions of Abra could auto-magically create servers but this was - removed due to issues of Not Invented Here Syndrome, Abra scope creep and - being hard to maintain & test. - -The process of creating a new server usually goes like this: - -1. Create an account with a server hosting provider -2. Generate an API client key which you'll give to `abra` -3. Run `abra server new` & fill in the values - ## How do I bootstrap a server for running Co-op Cloud apps? The requirements are: @@ -250,18 +236,6 @@ apt install apparmor systemctl restart docker containerd ``` -## Managing DNS entries - -`abra record ...` can help you manage your DNS entries if you have an account with a supported 3rd party provider. We currently support [Gandi](https://gandi.net). The process of managing DNS with `abra` usually goes like this: - -1. Create an account with a DNS service provider -2. Generate an API client key which you'll give to `abra` -3. Run `abra record ls` to check everything works - -`abra` supports creating, listing and removing DNS entries if the 3rd party integration supports it. - -If you want to teach `abra` how to support your favourite DNS service provider, we'd glady accept patches. - ## How do I persist container logs after they go away? This is a big topic but in general, if you're looking for something quick & easy, you can use the [journald logging driver](https://docs.docker.com/config/containers/logging/journald/). This will hook the container logs into systemd which can handle persistent log collection & managing log file size.