forked from toolshed/docs.coopcloud.tech
Compare commits
2 Commits
main
...
backupbot-
Author | SHA1 | Date | |
---|---|---|---|
65ac99ca25 | |||
3f1f57f4ba |
293
Backupbottwo.md
Normal file
293
Backupbottwo.md
Normal file
@ -0,0 +1,293 @@
|
|||||||
|
---
|
||||||
|
title: Backupbot-two
|
||||||
|
---
|
||||||
|
|
||||||
|
# For Operators
|
||||||
|
|
||||||
|
## Deployment
|
||||||
|
|
||||||
|
**1. Create a new app:**
|
||||||
|
|
||||||
|
```
|
||||||
|
abra app new backup-bot-two
|
||||||
|
```
|
||||||
|
|
||||||
|
**2. Configure :**
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
|
||||||
|
Run the cronjob that creates a backup, including the push notifications and docker logging: abra app cmd <backupbot_name> app run_cron
|
||||||
|
|
||||||
|
### Create a backup of all apps:
|
||||||
|
|
||||||
|
```
|
||||||
|
abra app run <backupbot_name> app -- backup create
|
||||||
|
```
|
||||||
|
|
||||||
|
The apps to backup up need to be deployed
|
||||||
|
|
||||||
|
### Create an individual backup:
|
||||||
|
|
||||||
|
```
|
||||||
|
abra app run <backupbot_name> app -- backup --host <target_app_name> create
|
||||||
|
```
|
||||||
|
|
||||||
|
### Create a backup to a local repository:
|
||||||
|
|
||||||
|
```
|
||||||
|
abra app run <backupbot_name> app -- backup create -r /backups/restic
|
||||||
|
```
|
||||||
|
|
||||||
|
It is recommended to shutdown/undeploy an app before restoring the data
|
||||||
|
|
||||||
|
### Restore the latest snapshot of all including apps:
|
||||||
|
|
||||||
|
```
|
||||||
|
abra app run <backupbot_name> app -- backup restore
|
||||||
|
```
|
||||||
|
|
||||||
|
### Restore a specific snapshot of an individual app:
|
||||||
|
|
||||||
|
```
|
||||||
|
abra app run <backupbot_name> app -- backup --host <target_app_name> restore --snapshot <snapshot_id>
|
||||||
|
```
|
||||||
|
|
||||||
|
### Show all snapshots:
|
||||||
|
|
||||||
|
```
|
||||||
|
abra app run <backupbot_name> app -- backup snapshots
|
||||||
|
```
|
||||||
|
|
||||||
|
### Show all snapshots containing a specific app:
|
||||||
|
|
||||||
|
```
|
||||||
|
abra app run <backupbot_name> app -- backup --host <target_app_name> snapshots
|
||||||
|
```
|
||||||
|
|
||||||
|
### Show all files inside the latest snapshot (can be very verbose):
|
||||||
|
|
||||||
|
```
|
||||||
|
abra app run <backupbot_name> app -- backup ls
|
||||||
|
```
|
||||||
|
|
||||||
|
### Show specific files inside a selected snapshot:
|
||||||
|
|
||||||
|
```
|
||||||
|
abra app run <backupbot_name> app -- backup ls --snapshot <snapshot_id> --path /var/lib/docker/volumes/
|
||||||
|
```
|
||||||
|
|
||||||
|
### Download files from a snapshot:
|
||||||
|
|
||||||
|
filename=$(abra app run <backupbot_name> app -- backup download --snapshot <snapshot_id> --path <absolute_path>)
|
||||||
|
abra app cp <backupbot_name> app:$filename .
|
||||||
|
|
||||||
|
# For Maintainers
|
||||||
|
|
||||||
|
TODO:
|
||||||
|
pre/post hooks
|
||||||
|
- Simple command
|
||||||
|
- accessing secrets
|
||||||
|
- more complex scripts mounted in the container
|
||||||
|
|
||||||
|
From the perspective of the recipe maintainer, backup/restore is just more
|
||||||
|
`deploy: ...` labels. Tools can read these labels and then perform the
|
||||||
|
backup/restore logic.
|
||||||
|
|
||||||
|
## Tools
|
||||||
|
|
||||||
|
Two of the current "blessed" options are
|
||||||
|
[`backup-bot-two`](https://git.coopcloud.tech/coop-cloud/backup-bot-two) &
|
||||||
|
[`abra`](https://git.coopcloud.tech/coop-cloud/abra).
|
||||||
|
|
||||||
|
### `backup-bot-two`
|
||||||
|
|
||||||
|
`backup-bot-two` is a recipe which gets deployed on the server, it can perform automatic backups.
|
||||||
|
Please see the [`README.md`](https://git.coopcloud.tech/coop-cloud/backup-bot-two#backupbot-ii) for the full docs.
|
||||||
|
|
||||||
|
### `abra`
|
||||||
|
|
||||||
|
`abra` will read labels and store backups in `~/.abra/backups/...` .
|
||||||
|
|
||||||
|
## Backup
|
||||||
|
|
||||||
|
Unless otherwise stated all labels should be added to the main service (which should be named `app`).
|
||||||
|
|
||||||
|
1. Enable backups for the recipe:
|
||||||
|
You need to enable backups for the recipe by adding the following label:
|
||||||
|
```
|
||||||
|
backupbot.backup=true
|
||||||
|
```
|
||||||
|
|
||||||
|
2. Decide wich volumes should be backed up:
|
||||||
|
By default all volumes will be backed up. To disable a certain volume you can add the following label:
|
||||||
|
```
|
||||||
|
backupbot.backup.volumes.{volume_name}=false
|
||||||
|
```
|
||||||
|
|
||||||
|
3. Decide which path should be backed up on each volume
|
||||||
|
By default all files get backed up for a volume. To only include certain paths you can add the following label:
|
||||||
|
```
|
||||||
|
backupbot.backup.volumes.{volume_name}.path=/mypath1/foo,/mypath2/bar
|
||||||
|
```
|
||||||
|
|
||||||
|
Note: You cann include multiple paths by providing a comma seperated list
|
||||||
|
Note: All paths are specified relativ to the volume root
|
||||||
|
|
||||||
|
4. Run commands before the backup
|
||||||
|
For certain services like a database it is not reccomend to just backup files, because the backup might end up in a corrupted state. Instead it is reccomended to make a database dump. You can run arbitrary commands in any container before the files are backed up.
|
||||||
|
To do this add the following label to the service on which you want the command being run:
|
||||||
|
```
|
||||||
|
backupbot.backup.pre-hook=mysqldump -u root -pghost ghost --tab /var/lib/foo
|
||||||
|
```
|
||||||
|
|
||||||
|
5. Run commands after the backup
|
||||||
|
Sometimes you want to clean up after the backup. You can run arbitrary commands in any container after the files were backed up.
|
||||||
|
To do this add the following label to the service on which you want the command being run:
|
||||||
|
```
|
||||||
|
backupbot.backup.post-hook=rm -rf /var/lib/mysql-files/*
|
||||||
|
```
|
||||||
|
|
||||||
|
### Testing the backup
|
||||||
|
That's it your recipe can now be backed up. But how can you make sure your configuration is correct?
|
||||||
|
|
||||||
|
TODO:
|
||||||
|
|
||||||
|
### Examples
|
||||||
|
|
||||||
|
## Restore
|
||||||
|
|
||||||
|
Restore, in this context means, "moving a compressed archive back to the
|
||||||
|
container backup paths". So, if you set
|
||||||
|
`backupbot.backup.path=/var/lib/foo,/var/lib/bar` and you have a backed up
|
||||||
|
archive, tooling will unzip files in the archive back to those paths.
|
||||||
|
|
||||||
|
In the case of restoring database tables, you can use the `pre-hook` &
|
||||||
|
`post-hook` commands to run the insertion logic.
|
||||||
|
|
||||||
|
## Configuration Examples
|
||||||
|
|
||||||
|
### Mysql
|
||||||
|
|
||||||
|
### Postgres
|
||||||
|
|
||||||
|
# Specification
|
||||||
|
|
||||||
|
TODO:
|
||||||
|
- should the post hook be executed when the backup/restore fails?
|
||||||
|
|
||||||
|
## Summary
|
||||||
|
|
||||||
|
Creating automated backups of docker swarm services is an often needed task. This specification describes how backups can be configured via [service labels](https://docs.docker.com/compose/compose-file/compose-file-v3/#labels-1) in a standardised way.
|
||||||
|
|
||||||
|
## Requirements
|
||||||
|
|
||||||
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in [RFC-2119].
|
||||||
|
|
||||||
|
When backing up a docker stack you MUST first check if the `backupbot.backup`. It MUST be set to true, for the backup to happen.
|
||||||
|
|
||||||
|
## Backup
|
||||||
|
|
||||||
|
To enable backups for a docker stack, the `backupbot.backup=true` label MUST be on any of its services. It SHOULD be declared on the first service.
|
||||||
|
A `backupbot.backup.pre-hook` MAY be set on a service. When set the command MUST be executed inside the running container of the service before backup up files.
|
||||||
|
By default all volumes MUST be backed up. A volume MAY be excluded from backing up when `backupbot.backup.volumes.{volume_name}=false` is set, where `{volume_name}` is the name of the volume.
|
||||||
|
By default all files MUST be backed up on a volume. `backupbot.backup.volumes.{volume_name}.path` MAY be set to limit the paths for that volume. The value MUST be a valid path relative to the volume root. It MAY contain multiple paths which get seperated by a comma.
|
||||||
|
A `backupbot.backup.post-hook` MAY be set on a service. When set the command MUST be executed inside the running container of the service after backing up all files.
|
||||||
|
A backup implementation SHOULD provide the backup of one or multiple stacks in a `.tar.gz` format.
|
||||||
|
|
||||||
|
## Restore
|
||||||
|
|
||||||
|
A `backupbot.restore.pre-hook` MAY be set on a service. When set the command MUST be executed inside the running container of the service before restoring backup files.
|
||||||
|
By default all files MUST be restored into their volume. A volume or path MAY be excluded from restoring.
|
||||||
|
A `backupbot.restore.post-hook` MAY be set on a service. When set the command MUST be executed inside the running container of the service after restoring backup files.
|
||||||
|
|
||||||
|
## Labels
|
||||||
|
|
||||||
|
### `backupbot.backup`
|
||||||
|
|
||||||
|
**Type:** boolean
|
||||||
|
**Default:** false
|
||||||
|
**Description:**
|
||||||
|
Enables backupbot for this compose stack. The labe should be added to the main service of the compose stack.
|
||||||
|
|
||||||
|
**Example:**
|
||||||
|
|
||||||
|
```
|
||||||
|
backupbot.backup: true
|
||||||
|
```
|
||||||
|
|
||||||
|
### `backupbot.backup.volumes.{volume_name}`
|
||||||
|
|
||||||
|
**Type:** boolean
|
||||||
|
**Default:** true
|
||||||
|
**Description:** When set to false the volume is excluded from backups.
|
||||||
|
|
||||||
|
**Example:**
|
||||||
|
|
||||||
|
```
|
||||||
|
backupbot.backup.volumes.{volume_name}: false
|
||||||
|
```
|
||||||
|
|
||||||
|
### `backupbot.backup.volumes.{volume_name}.path`
|
||||||
|
|
||||||
|
**Type:** string
|
||||||
|
**Default:** ""
|
||||||
|
**Description:**
|
||||||
|
A comma seperated list of paths. When one or more paths are set, it only backups up those on the given volume instead of the whole volume.
|
||||||
|
|
||||||
|
**Example:**
|
||||||
|
|
||||||
|
```
|
||||||
|
backupbot.backup.volumes.{volume_name}.path: '/var/lib/mariadb/dump.sql.gz'
|
||||||
|
```
|
||||||
|
|
||||||
|
### `backupbot.backup.pre-hook`
|
||||||
|
|
||||||
|
**Type:** string
|
||||||
|
**Default:** ""
|
||||||
|
**Description:**
|
||||||
|
A command, that gets executed before the files are backed up.
|
||||||
|
|
||||||
|
**Example:**
|
||||||
|
|
||||||
|
```
|
||||||
|
backupbot.backup.pre-hook: 'mysqldump -u root -p"$(cat /run/secrets/db_root_password)" -f /volume_path/dump.db'
|
||||||
|
```
|
||||||
|
|
||||||
|
### `backupbot.backup.post-hook`
|
||||||
|
|
||||||
|
**Type:** string
|
||||||
|
**Default:** ""
|
||||||
|
**Description:**
|
||||||
|
A command, that gets executed after the files are backuped.
|
||||||
|
|
||||||
|
**Example:**
|
||||||
|
|
||||||
|
```
|
||||||
|
backupbot.backup.post-hook: "rm -rf /volume_path/dump.db"
|
||||||
|
```
|
||||||
|
|
||||||
|
### `backupbot.restore.pre-hook`
|
||||||
|
|
||||||
|
**Type:** string
|
||||||
|
**Default:** ""
|
||||||
|
**Description:**
|
||||||
|
A command, that gets executed before the files are restored.
|
||||||
|
|
||||||
|
**Example:**
|
||||||
|
|
||||||
|
```
|
||||||
|
backupbot.restore.pre-hook: "lock db"
|
||||||
|
```
|
||||||
|
|
||||||
|
### `backupbot.restore.post-hook`
|
||||||
|
|
||||||
|
**Type:** string
|
||||||
|
**Default:** ""
|
||||||
|
**Description:**
|
||||||
|
A command, that gets executed after the files are restored.
|
||||||
|
|
||||||
|
**Example:**
|
||||||
|
|
||||||
|
```
|
||||||
|
backupbot.restore.post-hook: "sqldump dump.sql && unlock db && rm dump.sql"
|
||||||
|
```
|
@ -7,132 +7,62 @@ title: Cheat sheet
|
|||||||
!!! info
|
!!! info
|
||||||
not all flags are listed here.
|
not all flags are listed here.
|
||||||
|
|
||||||
|
!!! warning
|
||||||
|
Definitely set up autocomplete or you'll be sad
|
||||||
|
|
||||||
### Abra Autocomplete
|
`abra autocomplete bash/zsh/fizsh`
|
||||||
|
|
||||||
Definitely set up autocomplete or you'll be sad :sob: `abra` supports `bash`,
|
### create and deploy a new app:
|
||||||
`zsh`, and `fizsh` just run
|
- `abra app new $RECIPE`
|
||||||
|
flags: `-s/--server`, `-D/--domain`, `-S/--secrets`, `-p/--pass`
|
||||||
|
- `abra app config $APPNAME`
|
||||||
|
- `abra app secret generate $APPNAME -a`
|
||||||
|
flags: `-p/--pass`, `-a/--all`
|
||||||
|
- `abra app deploy $APPNAME`
|
||||||
|
flags: `-f/--force`, `-C/--chaos`
|
||||||
|
|
||||||
```
|
### undeploy and remove an app
|
||||||
$ abra autocomplete bash
|
- back up any data you don't want to lose
|
||||||
```
|
- `abra app undeploy $APPNAME`
|
||||||
|
- `abra app rm --volumes $APPNAME`
|
||||||
|
flags: `-f/--force`, `-V/--volumes`
|
||||||
|
|
||||||
|
### add/remove server
|
||||||
|
- `abra server add $SERVER`
|
||||||
|
- `abra server remove $SERVER`
|
||||||
|
flags: `-s/--server`
|
||||||
|
|
||||||
### Create & deploy an app
|
### upgrade abra
|
||||||
|
- `abra upgrade`
|
||||||
|
flags: `--rc`
|
||||||
|
|
||||||
```
|
### upgrade a recipe
|
||||||
$ abra app new $RECIPE`
|
- `abra recipe upgrade $RECIPE`
|
||||||
```
|
flags: `-x,y,z/--major,minor,patch`
|
||||||
|
- `abra recipe sync $RECIPE`
|
||||||
Optional flags: `-s/--server`, `-D/--domain`, `-S/--secrets`, `-p/--pass`
|
flags: `-x,y,z`
|
||||||
|
- `abra recipe release $RECIPE [$VERSION]`
|
||||||
```
|
flags: `-p/--publish`, `-r/--dry-run`, `-x,y,z`
|
||||||
$ abra app config $APPNAME
|
|
||||||
$ abra app secret generate $APPNAME -a
|
|
||||||
```
|
|
||||||
|
|
||||||
Optional flags: `-p/--pass`, `-a/--all`
|
|
||||||
|
|
||||||
```
|
|
||||||
$ abra app deploy $APPNAME
|
|
||||||
```
|
|
||||||
|
|
||||||
Optional flags: `-f/--force`, `-C/--chaos`
|
|
||||||
|
|
||||||
|
|
||||||
### Restarting an app
|
|
||||||
|
|
||||||
To run `restart` you need to specify the `<service>` name with the default being `app`
|
|
||||||
|
|
||||||
```
|
|
||||||
$ abra app restart <domain> app
|
|
||||||
```
|
|
||||||
|
|
||||||
### Undeploy & remove an app
|
|
||||||
|
|
||||||
Back up any data you don't want to lose
|
|
||||||
|
|
||||||
```
|
|
||||||
$ abra app undeploy $APPNAME
|
|
||||||
$ abra app rm --volumes $APPNAME
|
|
||||||
```
|
|
||||||
|
|
||||||
Optional flags: `-f/--force`, `-V/--volumes`
|
|
||||||
|
|
||||||
|
|
||||||
### Upgrade abra
|
|
||||||
|
|
||||||
To upgrade `abra` itself, run the following:
|
|
||||||
|
|
||||||
```
|
|
||||||
$ abra upgrade
|
|
||||||
```
|
|
||||||
|
|
||||||
Option flags: `--rc`
|
|
||||||
|
|
||||||
|
|
||||||
### Upgrade a recipe
|
|
||||||
|
|
||||||
```
|
|
||||||
$ abra recipe upgrade $RECIPE`
|
|
||||||
```
|
|
||||||
|
|
||||||
Option flags: `-x,y,z/--major,minor,patch`
|
|
||||||
|
|
||||||
```
|
|
||||||
$ abra recipe sync $RECIPE
|
|
||||||
```
|
|
||||||
|
|
||||||
Optional flags: `-x,y,z`
|
|
||||||
|
|
||||||
```
|
|
||||||
$ abra recipe release $RECIPE [$VERSION]
|
|
||||||
```
|
|
||||||
|
|
||||||
Optional flags: `-p/--publish`, `-r/--dry-run`, `-x,y,z`
|
|
||||||
|
|
||||||
|
|
||||||
### Manually restoring app data
|
|
||||||
|
|
||||||
To manually restore app data or configurations, you can use the `cp` command as:
|
|
||||||
|
|
||||||
```
|
|
||||||
$ abra app cp <domain> path/to/.app.conf app:/home/app/
|
|
||||||
$ abra app cp <domain> path/to/data app:/home/app/
|
|
||||||
```
|
|
||||||
|
|
||||||
*Note: the destination must be a directory and not a filename*
|
|
||||||
|
|
||||||
|
|
||||||
### Make changes to a recipe
|
|
||||||
|
|
||||||
Edit the files in `~/.abra/recipe/$RECIPENAME`
|
|
||||||
|
|
||||||
Deploy the changed version to your test instance
|
|
||||||
|
|
||||||
Determine how serious your change is (semver.org for reference)
|
|
||||||
|
|
||||||
```
|
|
||||||
$ abra recipe release $RECIPE [$VERSION]
|
|
||||||
```
|
|
||||||
|
|
||||||
|
### make a change to a recipe
|
||||||
|
- edit the files in `~/.abra/recipe/$RECIPENAME`
|
||||||
|
- deploy the changed version to your test instance
|
||||||
|
- determine how serious your change is (semver.org for reference)
|
||||||
|
- `abra recipe release $RECIPE [$VERSION]`
|
||||||
|
|
||||||
### Advanced Listing using `jq`
|
### Advanced Listing using `jq`
|
||||||
|
|
||||||
Several `abra` commands can output JSON formatted tables, and can thus be queried and filtered with the tool [jq](https://stedolan.github.io/jq/ "jq JSON Query tool"). We can also format these outputs with [tv](https://github.com/uzimaru0000/tv "tv Table Viewer") into a pretty table.
|
Several `abra` commands can output JSON formatted tables, and can thus be queried and filtered with the tool [jq](https://stedolan.github.io/jq/ "jq JSON Query tool"). We can also format these outputs with [tv](https://github.com/uzimaru0000/tv "tv Table Viewer") into a pretty table.
|
||||||
|
|
||||||
Currently, `abra recipe ls`, `abra server ls`, and `abra app ls` support the `-m` machine readable output flag which outputs JSON.
|
|
||||||
|
|
||||||
|
Currently, `abra recipe ls`, `abra server ls`, and `abra app ls` support the `-m` machine readable output flag which outputs JSON.
|
||||||
|
|
||||||
#### Filter recipes by "category"
|
#### Filter recipes by "category"
|
||||||
|
|
||||||
```
|
`abra recipe ls -m | jq '[.[] | select(.category == "Utilities") ]' | tv`
|
||||||
$ abra recipe ls -m | jq '[.[] | select(.category == "Utilities") ]' | tv
|
|
||||||
```
|
|
||||||
|
|
||||||
As you can see we, we're selecting all recipes where category is "Utilities".
|
As you can see we, we're selecting all recipes where category is "Utilities".
|
||||||
|
|
||||||
|
|
||||||
#### Filter apps by state `deployed`
|
#### Filter apps by state `deployed`
|
||||||
|
|
||||||
!!! info
|
!!! info
|
||||||
@ -141,8 +71,9 @@ As you can see we, we're selecting all recipes where category is "Utilities".
|
|||||||
!!! info
|
!!! info
|
||||||
`abra app ls` lists apps grouped into a server object, with statistics about the server. In `jq` we can select the entire apps list with `.[].apps[]`.
|
`abra app ls` lists apps grouped into a server object, with statistics about the server. In `jq` we can select the entire apps list with `.[].apps[]`.
|
||||||
|
|
||||||
```
|
`abra app ls -m -S |jq '[.[].apps[] | select(.status == "deployed") | del(.upgrade)]' |tv`
|
||||||
$ 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.
|
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.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
@ -1,9 +0,0 @@
|
|||||||
---
|
|
||||||
title: Design
|
|
||||||
---
|
|
||||||
|
|
||||||
## Design Prime Directives
|
|
||||||
|
|
||||||
* De-coupling: it should be possible to use the recipes without relying on
|
|
||||||
`abra`. The commons of recipes should live and function independently of
|
|
||||||
`abra`.
|
|
@ -2,19 +2,6 @@
|
|||||||
title: Hack
|
title: Hack
|
||||||
---
|
---
|
||||||
|
|
||||||
## Contributing
|
|
||||||
|
|
||||||
Welcome to Hacking the Planet with `abra`! We're looking forward to see what
|
|
||||||
you come up. If you have any questions, don't hesitate to ask 💖 If any of your
|
|
||||||
changes seems a bit controversial, it's probably to come have a chat first to
|
|
||||||
avoid heartache.
|
|
||||||
|
|
||||||
In general, we're into the idea of "Optimistic Merging" (instead of
|
|
||||||
"Pessimistic Merging" based on our understanding of
|
|
||||||
[C4](https://hintjens.gitbooks.io/social-architecture/content/chapter4.html)
|
|
||||||
(described further down under "Development Process" and also [in this blog
|
|
||||||
post](http://hintjens.com/blog:106)).
|
|
||||||
|
|
||||||
## Quick start
|
## Quick start
|
||||||
|
|
||||||
Get a fresh copy of the `abra` source code from [here](https://git.coopcloud.tech/coop-cloud/abra).
|
Get a fresh copy of the `abra` source code from [here](https://git.coopcloud.tech/coop-cloud/abra).
|
||||||
|
@ -2,40 +2,14 @@
|
|||||||
title: Install
|
title: Install
|
||||||
---
|
---
|
||||||
|
|
||||||
## Installer script source
|
|
||||||
|
|
||||||
You can view that [here](https://git.coopcloud.tech/coop-cloud/abra/src/branch/main/scripts/installer/installer).
|
|
||||||
|
|
||||||
## Installer prerequisites
|
|
||||||
|
|
||||||
* `tar`
|
|
||||||
* `wget`
|
|
||||||
* `curl` (only if using `curl` method below)
|
|
||||||
|
|
||||||
## Stable release
|
## Stable release
|
||||||
|
|
||||||
### Wget
|
|
||||||
|
|
||||||
```
|
|
||||||
wget -q -O - https://install.abra.coopcloud.tech | bash
|
|
||||||
```
|
|
||||||
|
|
||||||
### Curl
|
|
||||||
|
|
||||||
```
|
```
|
||||||
curl https://install.abra.coopcloud.tech | bash
|
curl https://install.abra.coopcloud.tech | bash
|
||||||
```
|
```
|
||||||
|
|
||||||
## Release candidate
|
## Release candidate
|
||||||
|
|
||||||
### Wget
|
|
||||||
|
|
||||||
```
|
|
||||||
wget -q -O - https://install.abra.coopcloud.tech | bash -s -- --rc
|
|
||||||
```
|
|
||||||
|
|
||||||
### Curl
|
|
||||||
|
|
||||||
```
|
```
|
||||||
curl https://install.abra.coopcloud.tech | bash -s -- --rc
|
curl https://install.abra.coopcloud.tech | bash -s -- --rc
|
||||||
```
|
```
|
||||||
@ -62,6 +36,10 @@ Otherwise, you downloaded a corrupted file and you should re-download it.
|
|||||||
|
|
||||||
Follow the guide [here](https://docs.coopcloud.tech/abra/hack/)
|
Follow the guide [here](https://docs.coopcloud.tech/abra/hack/)
|
||||||
|
|
||||||
|
## Installer script source
|
||||||
|
|
||||||
|
You can view that [here](https://git.coopcloud.tech/coop-cloud/abra/src/branch/main/scripts/installer/installer).
|
||||||
|
|
||||||
## Using Docker
|
## Using Docker
|
||||||
|
|
||||||
```
|
```
|
||||||
@ -72,6 +50,6 @@ docker run \
|
|||||||
|
|
||||||
!!! note
|
!!! note
|
||||||
If you're using symlinks, e.g. for [sharing
|
If you're using symlinks, e.g. for [sharing
|
||||||
`~/.abra`](/operators/handbook/#sharing-abra), add more `-v` options for
|
`~/.abra`](/operators/handbook/#sharing-abra), add more `-v` options for each
|
||||||
each directory you're symlinking to, e.g. `-v
|
directory you're symlinking to, e.g. `-v
|
||||||
$HOME/Projects/CoopCloud/apps:/home/user/Projects/CoopCloud/apps`
|
$HOME/Projects/CoopCloud/apps:/home/user/Projects/CoopCloud/apps`
|
||||||
|
@ -20,10 +20,6 @@ abra upgrade --rc
|
|||||||
|
|
||||||
> General release notes are [here](https://git.coopcloud.tech/coop-cloud/abra/releases/)
|
> General release notes are [here](https://git.coopcloud.tech/coop-cloud/abra/releases/)
|
||||||
|
|
||||||
### `0.8.x-beta` -> `0.9.x-beta`
|
|
||||||
|
|
||||||
None at this time.
|
|
||||||
|
|
||||||
### `0.7.x-beta` -> `0.8.x-beta`
|
### `0.7.x-beta` -> `0.8.x-beta`
|
||||||
|
|
||||||
- We now have an `--offline` flag instead of relying on internal logic to try
|
- We now have an `--offline` flag instead of relying on internal logic to try
|
||||||
|
@ -1,160 +0,0 @@
|
|||||||
---
|
|
||||||
title: Code of Co-operation
|
|
||||||
---
|
|
||||||
|
|
||||||
> Huge thanks to the folks at [Varia](https://varia.zone/) &
|
|
||||||
> [LURK](https://lurk.org) who carefully prepared wonderful Code of Conduct
|
|
||||||
> documents which we have adapted for our needs (with permission). See the
|
|
||||||
> original documents [here](https://varia.zone/en/pages/code-of-conduct.html)
|
|
||||||
> and [there](https://lurk.org/TOS.txt).
|
|
||||||
|
|
||||||
Co-op Cloud is used by several communities coming from a variety of cultural,
|
|
||||||
ethnic and professional backgrounds. We strive for to be welcoming to people of
|
|
||||||
these various backgrounds and provide a non-toxic and harassment-free
|
|
||||||
environment.
|
|
||||||
|
|
||||||
The Code of Conduct is a set of guidelines that help establish shared values
|
|
||||||
and ensure that behaviour that may harm participants is avoided.
|
|
||||||
|
|
||||||
We acknowledge that we come from different backgrounds and all have certain
|
|
||||||
biases and privileges. Therefore, this Code of Conduct cannot account for all
|
|
||||||
the ways that people might feel excluded, unsafe or uncomfortable. We commit to
|
|
||||||
open dialogues, and as such this Code of Conduct is never finished and should
|
|
||||||
change whenever needed. We amend this document over time so it reflects the
|
|
||||||
priorities and sensitivities of the community as it changes.
|
|
||||||
|
|
||||||
It is a collective responsibility for all of us to enact the behaviour
|
|
||||||
described in this document.
|
|
||||||
|
|
||||||
## Expected behaviour
|
|
||||||
|
|
||||||
We expect each other to:
|
|
||||||
|
|
||||||
### Be considerate...
|
|
||||||
|
|
||||||
...of each other, the space we enter, the Co-op Cloud community and the
|
|
||||||
practices that it houses.
|
|
||||||
|
|
||||||
### Be open and generous...
|
|
||||||
|
|
||||||
...while trying not to make assumptions about others. This can include
|
|
||||||
assumptions about identity, knowledge, experiences or preferred pronouns. Be
|
|
||||||
generous with our time and our abilities, when we are able to. Help others, but
|
|
||||||
ask first. There are many ways to contribute to a collective practice, which
|
|
||||||
may differ from our individual ways.
|
|
||||||
|
|
||||||
### Be respectful...
|
|
||||||
|
|
||||||
...of different viewpoints and experiences. Respect physical and emotional
|
|
||||||
boundaries. Be respectful of each others' limited time and energy. Take each
|
|
||||||
other and each other's practices seriously. Acknowledge that this might lead to
|
|
||||||
disagreement. However, disagreement is no excuse for poor manners.
|
|
||||||
|
|
||||||
### Be responsible....
|
|
||||||
|
|
||||||
...for the promises we make, meaning that we follow up on our commitments. We
|
|
||||||
take responsibility for the good things we do, but also for the bad ones. We
|
|
||||||
listen to and act upon respectful feedback. We correct ourselves when
|
|
||||||
necessary, keeping in mind that the impact of our words and actions on other
|
|
||||||
people doesn't always match our intent.
|
|
||||||
|
|
||||||
### Be dedicated...
|
|
||||||
|
|
||||||
...which means not letting the group happen to us, but making the group
|
|
||||||
together. We participate in the group with self-respect and don't exhaust
|
|
||||||
ourselves. This might mean saying how we feel, setting boundaries, being clear
|
|
||||||
about our expectations. Nobody is expected to be perfect in this community.
|
|
||||||
Asking questions early avoids problems later. Those who are asked should be
|
|
||||||
responsive and helpful.
|
|
||||||
|
|
||||||
### Be empathetic...
|
|
||||||
|
|
||||||
..by actively listening to others and not dominating discussions. We give each
|
|
||||||
other the chance to improve and let each other step up into positions of
|
|
||||||
responsibility. We make room for others. We are aware of each other's feelings,
|
|
||||||
provide support where necessary, and know when to step back. One's idea of
|
|
||||||
caring may differ from how others want to be cared for. We ask to make sure
|
|
||||||
that our actions are wanted.
|
|
||||||
|
|
||||||
### Foster an inclusive environment...
|
|
||||||
|
|
||||||
...by trying to create opportunities for others to express views, share skills
|
|
||||||
and make other contributions. Being together is something we actively work on
|
|
||||||
and requires negotiation. We recognize that not everyone has the same
|
|
||||||
opportunities, therefore we must be sensitive to the context we operate in.
|
|
||||||
There are implicit hierarchies that we can challenge, and we should strive to
|
|
||||||
do so. When we organize something (projects, events, etc.), we think about how
|
|
||||||
we can consider degrees of privilege, account for the needs of others, promote
|
|
||||||
an activist stance and support other voices.
|
|
||||||
|
|
||||||
## Unacceptable behaviour
|
|
||||||
|
|
||||||
### No structural or personal discrimination
|
|
||||||
|
|
||||||
Attitudes or comments promoting or reinforcing the oppression of any groups or
|
|
||||||
people based on gender, gender identity and expression, race, ethnicity,
|
|
||||||
nationality, sexuality, sexual orientation, religion, disability, mental
|
|
||||||
illness, neurodiversity, personal appearance, physical appearance, body size,
|
|
||||||
age, or class. Do not claim “reverse-isms”, for example “reverse racism”.
|
|
||||||
|
|
||||||
### No harrassment
|
|
||||||
|
|
||||||
Neither public nor private. Also no deliberate intimidation, stalking,
|
|
||||||
following, harassing photography or recording, disruption of events,
|
|
||||||
aggressive, slanderous, derogatory, or threatening comments online or in person
|
|
||||||
and unwanted physical or electronic contact or sexual attention. No posting or
|
|
||||||
disseminating libel, slander, or other disinformation.
|
|
||||||
|
|
||||||
### No violation of privacy
|
|
||||||
|
|
||||||
Namely publishing others’ private information, such as a physical or electronic
|
|
||||||
address, without explicit permission. Do not take or publish photos or
|
|
||||||
recordings of others after their request to not do so. Delete recordings if
|
|
||||||
asked.
|
|
||||||
|
|
||||||
### No unwelcome sexual conduct
|
|
||||||
|
|
||||||
Including unwanted sexual language, imagery, actions, attention or advances.
|
|
||||||
|
|
||||||
### No destructive behaviour
|
|
||||||
|
|
||||||
Or any other conduct which could reasonably be considered inappropriate. This
|
|
||||||
includes (but is not exclusive to) depictions of violence without content
|
|
||||||
warnings, consistently and purposely derailing or disrupting conversations, or
|
|
||||||
other behaviour that persistently disrupts the ability of others to engage in
|
|
||||||
the group or space.
|
|
||||||
|
|
||||||
## Intervention procedure
|
|
||||||
|
|
||||||
**Immediate intervention (help is needed now!)**
|
|
||||||
|
|
||||||
If you are feeling unsafe, you can immediately contact the Co-op Cloud members
|
|
||||||
who are tasked with making sure the code of co-operation is respected.
|
|
||||||
|
|
||||||
These contact people are members of Co-op Cloud who will do their best to help,
|
|
||||||
or to find the correct assistance if relevant/necessary. Here is the list so
|
|
||||||
far. If you would like to help in this task, please also feel free to volunteer
|
|
||||||
to be a support member.
|
|
||||||
|
|
||||||
> handle: `sordidwhiskey` contact:
|
|
||||||
> [helo@coopcloud.tech](mailto:helo@coopcloud.tech) handle: `3wc` contact:
|
|
||||||
> [helo@coopcloud.tech](mailto:helo@coopcloud.tech)
|
|
||||||
|
|
||||||
For example, something happened during a still-ongoing online event and needs
|
|
||||||
to be acted upon right away. Action is taken immediately when this violation of
|
|
||||||
the code of co-operation is reported. This could involve removing an attendee
|
|
||||||
from said event.
|
|
||||||
|
|
||||||
## Non-immediate intervention (a situation that requires more time)
|
|
||||||
|
|
||||||
Other violations need to be considered and consulted upon with more people or
|
|
||||||
in a more measured way. For example: If you experience an ongoing pattern of
|
|
||||||
harrassment; if you witness structurally unacceptable behaviour; if somebody
|
|
||||||
keeps "accidentally" using discriminatory language, after being asked to stop.
|
|
||||||
|
|
||||||
If you feel comfortable or able, discuss the issues with the involved parties
|
|
||||||
before consulting a mediator. We prefer to constructively resolve disagreements
|
|
||||||
together and work to right the wrong, when it is possible and safe to do so.
|
|
||||||
However, if the problems still persist, those who are responsible for enforcing
|
|
||||||
the code of co-operation can help you deal with these kinds of problems.
|
|
||||||
Contact the members listed above. Information will be handled with sensitivity.
|
|
@ -38,10 +38,4 @@ This is the public facing page where we publish all things federation in the ope
|
|||||||
|
|
||||||
[Tools We Use](/federation/tools){ .md-button .md-button--primary }
|
[Tools We Use](/federation/tools){ .md-button .md-button--primary }
|
||||||
|
|
||||||
- __Code of Co-operation__
|
|
||||||
|
|
||||||
Be excellent to each other 💝
|
|
||||||
|
|
||||||
[Read More](/federation/code-of-coop){ .md-button .md-button--primary }
|
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
|
@ -4,17 +4,15 @@ title: Membership
|
|||||||
|
|
||||||
> Are you also interested in joining the federation? Please see [Resolution 002](/federation/resolutions/passed/002/) for our process on how to join. If you have any questions, [drop us a line](/intro/contact/) with us for a chat
|
> Are you also interested in joining the federation? Please see [Resolution 002](/federation/resolutions/passed/002/) for our process on how to join. If you have any questions, [drop us a line](/intro/contact/) with us for a chat
|
||||||
|
|
||||||
| Name | Dues Paid | Notes | Contact |
|
| Name | Dues paid up? | Notes | Contact |
|
||||||
| --------- | --------- | -------- |-------- |
|
| -------- | -------- | -------- |-------- |
|
||||||
| Agaric | - | - | `@wolcen:matrix.org` |
|
| Agaric | - | - | `@wolcen:matrix.org` |
|
||||||
| [Autonomic](https://autonomic.zone) | - | - | `@3wc`, `@cas`, `@knoflook`, `@travvy`, `@aadil` |
|
| Flancia | - | - | `@vera:fairydust.space` |
|
||||||
| [Bonfire](https://bonfirenetworks.org) | - | - | `@mayel:matrix.org` + Ivan (`@cambriale:matrix.org`) |
|
| Autonomic | - | - | `@3wc` `@cas` `@decentral1se` `@knoflook` `@travvy` |
|
||||||
| [Doop.coop](https://doop.coop) | - | - | `@yusf:gottsnack.net` |
|
| Bonfire | - | - | `@mayel:matrix.org` + Ivan (`@cambriale:matrix.org`) |
|
||||||
| [EOTL](https://eotl.supply) | - | - | `@basebuilder:pub.solar` |
|
| Doop.coop | - | - | `@yusf:gottsnack.net` |
|
||||||
| [Karrot](https://karrot.world) | - | - | `@nicksellen:matrix.org` |
|
| Local IT | - | - | Philipp (`@yksflip:matrix.kaputt.cloud`) + `@moritz:matrix.local-it.org` |
|
||||||
| [Klasse & Methode](https://klasse-methode.it) | - | - | `@p4u1_f4u1:matrix.org` |
|
| ruangrupa | - | - | Henry `@babystepper:matrix.org` |
|
||||||
| [Local IT](https://local-it.org/) | - | - | Philipp (`@yksflip:matrix.kaputt.cloud`) + `@moritz:matrix.local-it.org` |
|
| UTAW | - | - | `@javielico:matrix.org` |
|
||||||
| Mirsal ™ | - | - | `@mirsal:1312.media` |
|
| ??? | - | - | `@mirsal:1312.media` |
|
||||||
| [UTAW](https://utaw.tech) | - | - | `@javielico:matrix.org` |
|
| Klasse & Methode | - | - | `@p4u1_f4u1:matrix.org` |
|
||||||
| [BeWater](https://bewater.contact) | Waiver | - | `@decentral1se` |
|
|
||||||
| [ruangrupa](https://ruangrupa.id) | - | - | Henry `@babystepper:matrix.org` |
|
|
||||||
|
@ -1,125 +0,0 @@
|
|||||||
---
|
|
||||||
title: 2024-03-29
|
|
||||||
---
|
|
||||||
|
|
||||||
## Meta
|
|
||||||
|
|
||||||
* Time: 29-03-2024
|
|
||||||
* Present: d1, p4u1, mo
|
|
||||||
* Call: https://vc.autistici.org/CoopCloudFederationMeeting
|
|
||||||
|
|
||||||
## Agenda
|
|
||||||
|
|
||||||
- checking in
|
|
||||||
- abra release planning https://git.coopcloud.tech/coop-cloud/organising/issues/583
|
|
||||||
- reforms to fedi process
|
|
||||||
- symptoms
|
|
||||||
- eotl vote delayed weeks
|
|
||||||
- many members not paying dues, no waiver agreed
|
|
||||||
- vera / Flancia left all chats?
|
|
||||||
- proposals
|
|
||||||
- [define fedi member reponsibilities](https://git.coopcloud.tech/coop-cloud/organising/issues/579)
|
|
||||||
- exit criteria for fedi members
|
|
||||||
- delay x quorom decision making
|
|
||||||
- rolling "credit system" for doing work
|
|
||||||
|
|
||||||
## Notes
|
|
||||||
|
|
||||||
### Checking in
|
|
||||||
|
|
||||||
d1: last release was gnarly, was tired but now looking forward to coordinating new release
|
|
||||||
|
|
||||||
mo: travelling, pretty busy, alakazam presentation/docs/feedback energies
|
|
||||||
|
|
||||||
p4: release hell, good progress, happy to see automation for new release. backupbot spec is underway, to discuss soon...
|
|
||||||
|
|
||||||
### Release planning
|
|
||||||
|
|
||||||
Note about previous release: goreleaser refused to to release on a branch previously, so we reverted the backup changes and reverted the revert after the release
|
|
||||||
|
|
||||||
#### Catalogue
|
|
||||||
|
|
||||||
why catalogue?
|
|
||||||
- advantage: git repository
|
|
||||||
- disadvantage: overhead, CI/CD system, people don't understand it, several bugs
|
|
||||||
|
|
||||||
proposal: rely on tags in the repository. clone everything to .abra/recipes/... pull tags locally on-the-fly.
|
|
||||||
|
|
||||||
if i create a new version of a recipe, the catalogue is not even at all. it just looks locally. the update happens afterwards
|
|
||||||
|
|
||||||
precomputing means saving resources later on
|
|
||||||
|
|
||||||
With the operator collaboration topic, it will be possible to specificy an app recipe with a git location, it is then possible to skip the catalogue.
|
|
||||||
https://git.coopcloud.tech/coop-cloud/organising/issues/533#issuecomment-19038
|
|
||||||
|
|
||||||
recipes.coopcloud.tech (the Elm app) is reading the JSON
|
|
||||||
|
|
||||||
in an ideal post-catalogue abra, you could just ref a git org where `RECIPE=<recipe>` would find `https://git.example.com/<org>/<recipe>` and even `RECIPE=<org>/<recipe>`
|
|
||||||
|
|
||||||
Backwards compatiblibility will be key. For next next release 🎉
|
|
||||||
|
|
||||||
#### Automation test suite
|
|
||||||
|
|
||||||
Computing power from somewhere? Local-IT doing migration atm so not ideal timing. Maybe again after a month or so, can check-in again then.
|
|
||||||
|
|
||||||
Can also ask Autonomic and/or whoever else feels like they can help.
|
|
||||||
|
|
||||||
#### Cli Argument Handling
|
|
||||||
|
|
||||||
https://git.coopcloud.tech/coop-cloud/organising/issues/581
|
|
||||||
|
|
||||||
Upgrade to `urfave/cli` version 2 will enforce `abra app command command [command options] <domain> [<service>] <command> [-- <args>]`
|
|
||||||
|
|
||||||
Maybe we need a poll to see how people are using it? `@mo` using the strict format anyway, `@d1` not minding, `@p4` in favour...
|
|
||||||
|
|
||||||
adding a good/clear warning/error that if using e.g. `--chaos` on the end, it's not possible anymore...
|
|
||||||
|
|
||||||
> How do you use flag options (e.g. `--chaos`) with Abra?
|
|
||||||
> At the beginning: abra app deploy --chaos app.example.com
|
|
||||||
> At the end: abra app deploy app.example.com --chaos
|
|
||||||
|
|
||||||
> How annoyed will you be if, we enforce it at the beginning?
|
|
||||||
> Not annoyed
|
|
||||||
> Slighty annoyed
|
|
||||||
> Very annoyed
|
|
||||||
> If you are *annoyed, what can we do to help this process? e.g. docs, warning, etc.
|
|
||||||
|
|
||||||
Decision vs. poll? It's not really a choice. the lib is broken / enforces this. its ambigous now and just causes issues / questions / confusion.
|
|
||||||
|
|
||||||
Hack to re-order options transparently? Some pre-processor which would special case the `[-- ARGS]` for `abra app cmd`.
|
|
||||||
|
|
||||||
Doing it one way is just clear for everyone.
|
|
||||||
|
|
||||||
Plan: make proposal, get votes. if voted against, try to make new with adaptions / more work/money etc. but compromises with needs. (TODO: `@d1`)
|
|
||||||
|
|
||||||
Btw emoji polls are actually broken for some clients 😱
|
|
||||||
|
|
||||||
### Fedi process reforms
|
|
||||||
|
|
||||||
https://git.coopcloud.tech/coop-cloud/organising/issues/579
|
|
||||||
|
|
||||||
- pay yearly dues or get waiver (don't pay)
|
|
||||||
- actively participate in voting
|
|
||||||
- actively participate in monthly federation meetings. if you can't make it, please send your updates by text
|
|
||||||
- agree to code of conduct
|
|
||||||
|
|
||||||
exit criteria?
|
|
||||||
|
|
||||||
- no yearly dues arragement
|
|
||||||
- no/less voting/participation in meetings
|
|
||||||
|
|
||||||
TODO: proposal, pass, check in with people in the "exit criteria" area, are they OK?
|
|
||||||
|
|
||||||
### Goals of Federation?
|
|
||||||
|
|
||||||
- what is the purpose of the fedi?
|
|
||||||
- in relation to theory, ideology, strategy
|
|
||||||
- Co-op Cloud Conf !!!
|
|
||||||
- let's think about this and check back in
|
|
||||||
|
|
||||||
### Next meeting
|
|
||||||
|
|
||||||
`@mo` does next poll
|
|
||||||
|
|
||||||
|
|
||||||
|
|
@ -9,7 +9,7 @@ title: "Resolution 017"
|
|||||||
|
|
||||||
### Summary
|
### Summary
|
||||||
|
|
||||||
> [BeWater Co-op](https://bewater.contact).
|
[BeWater Co-op](https://bewater.contact).
|
||||||
|
|
||||||
`@decentral1se` is a member and has been active in Abra hacking & coordination
|
`@decentral1se` is a member and has been active in Abra hacking & coordination
|
||||||
on several issues. BeWater maintains several small-scale Co-op Cloud
|
on several issues. BeWater maintains several small-scale Co-op Cloud
|
@ -1,48 +0,0 @@
|
|||||||
---
|
|
||||||
title: "Resolution 022"
|
|
||||||
---
|
|
||||||
|
|
||||||
- Topic: Budget 10: Abra integration suite automation
|
|
||||||
- Date: 04-04-2024
|
|
||||||
- Deadline: 18-04-2024
|
|
||||||
- Size: Large
|
|
||||||
|
|
||||||
### Summary
|
|
||||||
|
|
||||||
Motivated by the collective release planning:
|
|
||||||
[`#583`](https://git.coopcloud.tech/coop-cloud/organising/issues/583) under
|
|
||||||
"Automate Integration Test Suite".
|
|
||||||
|
|
||||||
The latest `abra` release (`0.9.x`) was heavily delayed due to several issues.
|
|
||||||
One of those was the need to fix the integration test suite which wasn't run in
|
|
||||||
some time. Many breakages had crept into the test suite over time. This can
|
|
||||||
avoided in the future by automating the running of the integration test suite.
|
|
||||||
|
|
||||||
This proposal describes a way to do this and includes a budget for doing so.
|
|
||||||
|
|
||||||
### Details (Budget 10)
|
|
||||||
|
|
||||||
The `abra` test suite takes around 1.30 hrs to run on a modest machine.
|
|
||||||
Therefore, we propose to run it only once daily. Some parts of the tests are
|
|
||||||
slow, fast and only a few require public DNS. This means we can break up the
|
|
||||||
tests and run them in separate "builds" to speed things up. This involves some
|
|
||||||
research & experimentation.
|
|
||||||
|
|
||||||
A server has been provided by `@mirsal` on donation (💘). This machine will be
|
|
||||||
be wiped clean each day (`docker <command> prune ....`) and will have the usual
|
|
||||||
DNS machinery attached to it, e.g. `int.coopcloud.tech`, `*.int.coopcloud.tech`.
|
|
||||||
|
|
||||||
Once that is all wired up, we can implement the CI/CD configuration to make the
|
|
||||||
test suite run automatically once a day. This will be triggered via the
|
|
||||||
`.drone.yml` in the `abra` Git repository.
|
|
||||||
|
|
||||||
Budget details:
|
|
||||||
|
|
||||||
| Item | Cost | Who? |
|
|
||||||
| ---- | ---- | ---- |
|
|
||||||
| Server | Free (on donation) | `@mirsal` |
|
|
||||||
| Server setup & docs | 1 hour | `@d1` |
|
|
||||||
| R & D for breaking up tests | 5 hours | `@d1` |
|
|
||||||
| Implementing CI/CD configs | 10 hours | `@d1` |
|
|
||||||
|
|
||||||
**Total: 16 hrs * 20 EUR = 320 EUR**
|
|
@ -1,19 +0,0 @@
|
|||||||
---
|
|
||||||
title: "Resolution 018"
|
|
||||||
---
|
|
||||||
|
|
||||||
- Topic: EOTL joins the Co-op Cloud Federation
|
|
||||||
- Date: 12-03-24
|
|
||||||
- Deadline: 26-03-2024
|
|
||||||
- Size: Large
|
|
||||||
|
|
||||||
### Summary
|
|
||||||
|
|
||||||
> [EOTL](https://codeberg.org/eotl)
|
|
||||||
|
|
||||||
[@basebuilder](https://git.coopcloud.tech/basebuilder) has been active in contributions
|
|
||||||
to the Co-op Cloud documentation and Abra testing.
|
|
||||||
|
|
||||||
### Details
|
|
||||||
|
|
||||||
N/A.
|
|
@ -1,25 +0,0 @@
|
|||||||
---
|
|
||||||
title: "Resolution 019"
|
|
||||||
---
|
|
||||||
|
|
||||||
- Topic: Karrot joins the Co-op Cloud Federation
|
|
||||||
- Date: 25-03-24
|
|
||||||
- Deadline: 08-04-2024
|
|
||||||
- Size: Large
|
|
||||||
|
|
||||||
### Summary
|
|
||||||
|
|
||||||
> [Karrot](https://karrot.world) / [Docs](https://docs.karrot.world)
|
|
||||||
|
|
||||||
[@nicksellen](https://git.coopcloud.tech/nicksellen) is a Karrot Team member and has:
|
|
||||||
|
|
||||||
- Used Co-op Cloud for [bath.social](https://bath.social)
|
|
||||||
- Supported Foodsharing Luxembourg to self-host Karrot using Co-op Cloud
|
|
||||||
- Participated in [`#coopcloud-tech:autonomic.zone`](https://matrix.to/#/#coopcloud-tech:autonomic.zone) chat
|
|
||||||
- Some small contributions/fixes/bug reports for some Co-op Cloud stuff
|
|
||||||
|
|
||||||
### Details
|
|
||||||
|
|
||||||
We, the Karrot Team, consented to apply to join during our weekly meeting ([minutes](https://community.karrot.world/t/weekly-call-about-karrot-development-2024/1510/10)) and are happy to contribute 60€/year.
|
|
||||||
|
|
||||||
We would enjoy a video call if our application is successful to introduce members of our wider team and connect a little more 🤗♥️
|
|
@ -24,7 +24,7 @@ We'd be happy to hear feedback about our documentation, if it was helpful, what
|
|||||||
|
|
||||||
- [Organisers guide](/organisers): You run meetings, write guidelines & shape our democratic process :fist:
|
- [Organisers guide](/organisers): You run meetings, write guidelines & shape our democratic process :fist:
|
||||||
|
|
||||||
- [Recipes](/abra/recipes/): You want to know what recipes are packaged so you can deploy them as apps :nerd:
|
- [Recipes](/recipes/): You want to know what recipes are packaged so you can deploy them as apps :nerd:
|
||||||
|
|
||||||
- [Abra](/abra): You want to install the command-line client and hack the planet :unicorn:
|
- [Abra](/abra): You want to install the command-line client and hack the planet :unicorn:
|
||||||
|
|
||||||
|
@ -1,6 +0,0 @@
|
|||||||
---
|
|
||||||
title: Inspirations
|
|
||||||
---
|
|
||||||
|
|
||||||
* [Dmytri Kleiner: "You can't code away their wealth"](https://yewtu.be/watch?v=FEU632_Em3g). Also, [The Telekommunist Manifesto](https://www.networkcultures.org/_uploads/%233notebook_telekommunist.pdf). Reading / checking out Kleiners work is a must IMHO -- `@decentral1se`.
|
|
||||||
* [CoopCycle](https://coopcycle.org/en/) - heavily inspired the Federation model and how we shaped the first decisions on how to do it. -- `@decentral1se`
|
|
@ -391,17 +391,13 @@ 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):
|
In the root of your recipe repository, run the following (if the folder doesn't already exist):
|
||||||
|
|
||||||
```
|
```
|
||||||
mkdir -p release
|
mkdir -p releases
|
||||||
```
|
```
|
||||||
|
|
||||||
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`.
|
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`.
|
||||||
|
|
||||||
You can also add release notes for the next release into a special file `releases/next`. This file will be used when running `abra recipe release`.
|
You can also add release notes for the next release into a special file `releases/next`. This file will be used when running `abra recipe release`.
|
||||||
|
|
||||||
!!! warning "Not available previous versions of Abra"
|
|
||||||
|
|
||||||
Using `releases/next` is only available in > 0.9.x series of `abra`.
|
|
||||||
|
|
||||||
## How do I generate the recipe catalogue
|
## How do I generate the recipe catalogue
|
||||||
|
|
||||||
To generate an entire new copy of the catalogue:
|
To generate an entire new copy of the catalogue:
|
||||||
@ -696,21 +692,6 @@ You should be able to deploy this overriden configuration now.
|
|||||||
|
|
||||||
## Linting rules
|
## Linting rules
|
||||||
|
|
||||||
### R015: "long secret names"
|
|
||||||
|
|
||||||
Due to limitations placed by the Docker runtime, secret names must be < 64
|
|
||||||
characters long. Due to convetions in recipe configuration and how `abra`
|
|
||||||
works, several characters are appended to secret names during a deployment.
|
|
||||||
This means if you have a domain `example.org` and a secret `foo_pass`, you'll
|
|
||||||
end up with something like `example_org_foo_pass_v1` being used for the secret
|
|
||||||
name.
|
|
||||||
|
|
||||||
Based on a discussion in
|
|
||||||
[`#463`](https://git.coopcloud.tech/coop-cloud/organising/issues/463) and
|
|
||||||
looking on what is implemented currently in existing recipes, we came up with a
|
|
||||||
general rule of thumb that secret names in recipe configurations should be < 12
|
|
||||||
characters long to avoid errors on deployment.
|
|
||||||
|
|
||||||
### R014: "invalid lightweight tag"
|
### R014: "invalid lightweight tag"
|
||||||
|
|
||||||
This is an issue related to the way Git/`go-git` handle Git tags internally. We
|
This is an issue related to the way Git/`go-git` handle Git tags internally. We
|
||||||
|
@ -205,6 +205,18 @@ 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.
|
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
|
||||||
|
|
||||||
|
`abra server new` can create servers if you have an account with a supported 3rd party integration. We currently support [Servers.coop](https://servers.coop) & [Hetzner](https://hetzner.com). 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
|
||||||
|
|
||||||
|
`abra` supports creating, listing and removing servers if the 3rd party integration supports it.
|
||||||
|
|
||||||
|
If you want to teach `abra` how to support your favourite server hosting provider, we'd glady accept patches.
|
||||||
|
|
||||||
## How do I bootstrap a server for running Co-op Cloud apps?
|
## How do I bootstrap a server for running Co-op Cloud apps?
|
||||||
|
|
||||||
The requirements are:
|
The requirements are:
|
||||||
@ -214,12 +226,6 @@ The requirements are:
|
|||||||
1. Swarm mode initialised
|
1. Swarm mode initialised
|
||||||
1. Proxy network created
|
1. Proxy network created
|
||||||
|
|
||||||
!!! warning "You may need to log in/out"
|
|
||||||
|
|
||||||
When running `usermod ...`, you may need to (depending on your system) log
|
|
||||||
in and out again of your shell session to get the required permissions for
|
|
||||||
Docker.
|
|
||||||
|
|
||||||
```
|
```
|
||||||
# docker install convenience script
|
# docker install convenience script
|
||||||
wget -O- https://get.docker.com | bash
|
wget -O- https://get.docker.com | bash
|
||||||
@ -236,6 +242,18 @@ apt install apparmor
|
|||||||
systemctl restart docker containerd
|
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?
|
## 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.
|
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.
|
||||||
@ -317,20 +335,9 @@ See [`#312`](https://git.coopcloud.tech/coop-cloud/organising/issues/312) for mo
|
|||||||
|
|
||||||
If you're app [supports backup/restore](/maintainers/handbook/#how-do-i-configure-backuprestore) then you have two options: [`backup-bot-two`](https://git.coopcloud.tech/coop-cloud/backup-bot-two) & [`abra`](https://git.coopcloud.tech/coop-cloud/abra).
|
If you're app [supports backup/restore](/maintainers/handbook/#how-do-i-configure-backuprestore) then you have two options: [`backup-bot-two`](https://git.coopcloud.tech/coop-cloud/backup-bot-two) & [`abra`](https://git.coopcloud.tech/coop-cloud/abra).
|
||||||
|
|
||||||
With `abra`, you can simply run the commands:
|
With `abra`, you can simply run `abra app backup ...` & `abra app restore ...`.
|
||||||
|
|
||||||
```
|
|
||||||
$ abra app backup <domain>
|
|
||||||
$ abra app restore <domain>
|
|
||||||
```
|
|
||||||
|
|
||||||
Pass `-h` for more information on the specific flags & arguments.
|
Pass `-h` for more information on the specific flags & arguments.
|
||||||
|
|
||||||
If your app Recipe *does not support backups* you can do it manually with the
|
|
||||||
`abra cp` command. See the exact commands in [abra
|
|
||||||
cheetsheet](/abra/cheat-sheet/#manually-restoring-app-data).
|
|
||||||
|
|
||||||
|
|
||||||
## How do I take a manual database backup?
|
## How do I take a manual database backup?
|
||||||
|
|
||||||
MySQL / MariaDB:
|
MySQL / MariaDB:
|
||||||
@ -455,28 +462,3 @@ route requests after. You're free to make as many `$whatever.yml` files in your
|
|||||||
|
|
||||||
Please note that we have to hardcode `production` and `web-secure` which are
|
Please note that we have to hardcode `production` and `web-secure` which are
|
||||||
typically configurable when not using `FILE_PROVIDER_DIRECTORY_ENABLED`.
|
typically configurable when not using `FILE_PROVIDER_DIRECTORY_ENABLED`.
|
||||||
|
|
||||||
## Can I use Caddy instead of Traefik?
|
|
||||||
|
|
||||||
Yes, it's possible although currently Quite Experimental! See
|
|
||||||
[`#388`](https://git.coopcloud.tech/coop-cloud/organising/issues/388) for more.
|
|
||||||
|
|
||||||
## Running an offline coop-cloud server
|
|
||||||
|
|
||||||
You may want to run a coop-cloud directly on your device (or in a VM or machine on your LAN), whether that's for testing a recipe or to run coop-cloud apps outside of the cloud ;-)
|
|
||||||
In that case you might simply add some names to `/etc/hosts` (e.g `127.0.0.1 myapp.localhost`), or configure them on a local DNS server - which means `traefik` won't be able to use `letsencrypt` to generate and verify SSL certificates. Here's what you can do instead:
|
|
||||||
1. In your traefik .env file, edit/uncomment the following lines:
|
|
||||||
```
|
|
||||||
LETS_ENCRYPT_ENV=staging
|
|
||||||
WILDCARDS_ENABLED=1
|
|
||||||
SECRET_WILDCARD_CERT_VERSION=v1
|
|
||||||
SECRET_WILDCARD_KEY_VERSION=v1
|
|
||||||
COMPOSE_FILE="$COMPOSE_FILE:compose.wildcard.yml"
|
|
||||||
```
|
|
||||||
2. Generate a self-signed certificate using the [command listed here](https://letsencrypt.org/docs/certificates-for-localhost/#making-and-trusting-your-own-certificates). Unless using `localhost` you may want to edit that where it appears in the command, and/or add multiple (sub)domains to the certificate e.g: `subjectAltName=DNS:localhost,DNS:myapp.localhost`
|
|
||||||
3. Run these commands:
|
|
||||||
```
|
|
||||||
abra app secret insert localhost ssl_cert v1 "$(cat localhost.crt)"
|
|
||||||
abra app secret insert localhost ssl_key v1 "$(cat localhost.key)"
|
|
||||||
```
|
|
||||||
4. Re-deploy `traefik` with `--force` and voila!
|
|
||||||
|
@ -32,12 +32,6 @@ You need to keep port `:80` and `:443` free on your server for web proxying to y
|
|||||||
|
|
||||||
`abra` has support for creating servers (`abra server new`) but that is a more advanced automation feature which is covered in the [handbook](/operators/handbook). For this tutorial, we'll focus on the basics. Assuming you've managed to create a testing VPS with some `$hosting_provider`, you'll need to install Docker, add your user to the Docker group & setup swarm mode:
|
`abra` has support for creating servers (`abra server new`) but that is a more advanced automation feature which is covered in the [handbook](/operators/handbook). For this tutorial, we'll focus on the basics. Assuming you've managed to create a testing VPS with some `$hosting_provider`, you'll need to install Docker, add your user to the Docker group & setup swarm mode:
|
||||||
|
|
||||||
!!! warning "You may need to log in/out"
|
|
||||||
|
|
||||||
When running `usermod ...`, you may need to (depending on your system) log
|
|
||||||
in and out again of your shell session to get the required permissions for
|
|
||||||
Docker.
|
|
||||||
|
|
||||||
```
|
```
|
||||||
# docker install convenience script
|
# docker install convenience script
|
||||||
wget -O- https://get.docker.com | bash
|
wget -O- https://get.docker.com | bash
|
||||||
@ -139,21 +133,15 @@ abra server ls
|
|||||||
|
|
||||||
In order to have your Co-op cloud deployment serve the public internet, we need to install the core web proxy, [Traefik](https://doc.traefik.io/traefik/).
|
In order to have your Co-op cloud deployment serve the public internet, we need to install the core web proxy, [Traefik](https://doc.traefik.io/traefik/).
|
||||||
|
|
||||||
Traefik is the main entrypoint for all web requests (e.g. like NGINX) and
|
Traefik is the main entrypoint for all web requests (e.g. like NGINX) and supports automatic SSL certificate configuration and other quality-of-life features which make deploying libre apps more enjoyable.
|
||||||
supports automatic SSL certificate configuration and other quality-of-life
|
|
||||||
features which make deploying libre apps more enjoyable.
|
|
||||||
|
|
||||||
**1. To get started, you'll need to create a new app:**
|
To get started, you'll need to create a new app:
|
||||||
|
|
||||||
```bash
|
```bash
|
||||||
abra app new traefik
|
abra app new traefik
|
||||||
```
|
```
|
||||||
|
|
||||||
Choose your newly registered server and specify a domain name. By default `abra`
|
Choose your newly registered server and specify a domain name.
|
||||||
will suggest `<app-name>.server.org` or prompt you with a list of servers.
|
|
||||||
|
|
||||||
|
|
||||||
**2. Configure this new `traefix` app**
|
|
||||||
|
|
||||||
You will want to take a look at your generated configuration and tweak the `LETS_ENCRYPT_EMAIL` value. You can do that by running `abra app config`:
|
You will want to take a look at your generated configuration and tweak the `LETS_ENCRYPT_EMAIL` value. You can do that by running `abra app config`:
|
||||||
|
|
||||||
@ -161,32 +149,14 @@ You will want to take a look at your generated configuration and tweak the `LETS
|
|||||||
abra app config <traefik-domain>
|
abra app config <traefik-domain>
|
||||||
```
|
```
|
||||||
|
|
||||||
Every app you deploy will have one of these `.env` files, which contains
|
Every app you deploy will have one of these `.env` files, which contains variables which will be injected into app configurations when deployed. Variables starting with `#` are optional, others are required.
|
||||||
variables which will be injected into app configurations when deployed. These
|
|
||||||
files exist at relevantly named path:
|
|
||||||
|
|
||||||
```bash
|
Now it is time to deploy:
|
||||||
~/.abra/servers/<domain>/<traefik-domain>.env
|
|
||||||
```
|
|
||||||
|
|
||||||
Variables starting with `#` are optional, others are required. Some things to
|
|
||||||
consider here is that by default our *Traefik* recipe exposes the metric
|
|
||||||
dashboard unauthenticated on the public internet at the URL `<traefik-domain>`
|
|
||||||
it is deployed to, which is not ideal. You can disable this with:
|
|
||||||
|
|
||||||
```
|
|
||||||
DASHBOARD_ENABLED=false
|
|
||||||
```
|
|
||||||
|
|
||||||
**3. Now it is time to deploy your app:**
|
|
||||||
|
|
||||||
```
|
```
|
||||||
abra app deploy <traefik-domain>
|
abra app deploy <traefik-domain>
|
||||||
```
|
```
|
||||||
|
|
||||||
Voila. Abracadabra :magic_wand: your first app is deployed :sparkles:
|
|
||||||
|
|
||||||
|
|
||||||
### Deploy Nextcloud
|
### Deploy Nextcloud
|
||||||
|
|
||||||
And now we can deploy apps. Let's create a new Nextcloud app.
|
And now we can deploy apps. Let's create a new Nextcloud app.
|
||||||
|
11
mkdocs.yml
11
mkdocs.yml
@ -61,7 +61,6 @@ nav:
|
|||||||
- "Frequently Asked Questions": intro/faq.md
|
- "Frequently Asked Questions": intro/faq.md
|
||||||
- "Project Strategy": intro/strategy.md
|
- "Project Strategy": intro/strategy.md
|
||||||
- "Comparisons": intro/comparisons.md
|
- "Comparisons": intro/comparisons.md
|
||||||
- "Inspirations": intro/inspirations.md
|
|
||||||
- "Project Status": intro/bikemap.md
|
- "Project Status": intro/bikemap.md
|
||||||
- "Managed Hosting": intro/managed.md
|
- "Managed Hosting": intro/managed.md
|
||||||
- "Get In Touch": intro/contact.md
|
- "Get In Touch": intro/contact.md
|
||||||
@ -92,7 +91,6 @@ nav:
|
|||||||
- "Install": abra/install.md
|
- "Install": abra/install.md
|
||||||
- "Quick Start": abra/quickstart.md
|
- "Quick Start": abra/quickstart.md
|
||||||
- "Upgrade": abra/upgrade.md
|
- "Upgrade": abra/upgrade.md
|
||||||
- "Design": abra/design.md
|
|
||||||
- "Recipes": abra/recipes.md
|
- "Recipes": abra/recipes.md
|
||||||
- "Hack": abra/hack.md
|
- "Hack": abra/hack.md
|
||||||
- "Troubleshoot": abra/trouble.md
|
- "Troubleshoot": abra/trouble.md
|
||||||
@ -105,7 +103,6 @@ nav:
|
|||||||
- "Bylaws": federation/bylaws.md
|
- "Bylaws": federation/bylaws.md
|
||||||
- "Finance": federation/finance.md
|
- "Finance": federation/finance.md
|
||||||
- "Membership": federation/membership.md
|
- "Membership": federation/membership.md
|
||||||
- "Code of Co-operation": federation/code-of-coop.md
|
|
||||||
- "Resolutions":
|
- "Resolutions":
|
||||||
- federation/resolutions/index.md
|
- federation/resolutions/index.md
|
||||||
- "Passed":
|
- "Passed":
|
||||||
@ -123,17 +120,13 @@ nav:
|
|||||||
- federation/resolutions/passed/012.md
|
- federation/resolutions/passed/012.md
|
||||||
- federation/resolutions/passed/014.md
|
- federation/resolutions/passed/014.md
|
||||||
- federation/resolutions/passed/015.md
|
- federation/resolutions/passed/015.md
|
||||||
- federation/resolutions/passed/016.md
|
|
||||||
- federation/resolutions/passed/017.md
|
|
||||||
- federation/resolutions/passed/018.md
|
|
||||||
- federation/resolutions/passed/019.md
|
|
||||||
- "In Progress":
|
- "In Progress":
|
||||||
- federation/resolutions/in-progress/013.md
|
- federation/resolutions/in-progress/013.md
|
||||||
- federation/resolutions/in-progress/022.md
|
- federation/resolutions/in-progress/016.md
|
||||||
|
- federation/resolutions/in-progress/017.md
|
||||||
- "Minutes":
|
- "Minutes":
|
||||||
- federation/minutes/index.md
|
- federation/minutes/index.md
|
||||||
- "Recently":
|
- "Recently":
|
||||||
- federation/minutes/2024-03-29.md
|
|
||||||
- federation/minutes/2024-02-01.md
|
- federation/minutes/2024-02-01.md
|
||||||
- "Archive":
|
- "Archive":
|
||||||
- federation/minutes/2022-03-03.md
|
- federation/minutes/2022-03-03.md
|
||||||
|
Loading…
x
Reference in New Issue
Block a user