Compare commits
1 Commits
main
...
local-inte
| Author | SHA1 | Date |
|---|---|---|
 p4u1
|
73dc1400a1 |
|
|
@ -1,4 +1,4 @@
|
|||
FROM squidfunk/mkdocs-material:9.5.7
|
||||
FROM squidfunk/mkdocs-material:9.4.10
|
||||
|
||||
EXPOSE 8000
|
||||
|
||||
|
|
@ -8,4 +8,6 @@ WORKDIR /docs
|
|||
|
||||
RUN apk add --no-cache curl
|
||||
|
||||
RUN pip install -r requirements.txt
|
||||
RUN pip install \
|
||||
mkdocs-awesome-pages-plugin==2.9.1 \
|
||||
mkdocs-material-extensions==1.1.1
|
||||
|
|
|
|||
16
README.md
16
README.md
|
|
@ -1,21 +1,13 @@
|
|||
# docs.coopcloud.tech :open_book:
|
||||
# docs.coopcloud.tech
|
||||
|
||||
[](https://build.coopcloud.tech/coop-cloud/docs.coopcloud.tech)
|
||||
|
||||
View: [docs.coopcloud.tech](https://docs.coopcloud.tech)
|
||||
> https://docs.coopcloud.tech
|
||||
|
||||
|
||||
## Developing / Hacking
|
||||
|
||||
Co-op Cloud's docs are created with the [mkdocs-material](https://squidfunk.github.io/mkdocs-material/) framework.
|
||||
|
||||
To install dependencies and serve local build of site, simply run:
|
||||
## hacking
|
||||
|
||||
```
|
||||
make
|
||||
```
|
||||
|
||||
Useful docs for theming and content reference:
|
||||
|
||||
- [Changing the colors](https://squidfunk.github.io/mkdocs-material/setup/changing-the-colors/)
|
||||
- [Reference](https://squidfunk.github.io/mkdocs-material/reference/)
|
||||
Theme docs are [here](https://squidfunk.github.io/mkdocs-material/setup/changing-the-colors/) and [there](https://squidfunk.github.io/mkdocs-material/reference/).
|
||||
|
|
|
|||
|
|
@ -7,132 +7,62 @@ title: Cheat sheet
|
|||
!!! info
|
||||
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`,
|
||||
`zsh`, and `fizsh` just run
|
||||
### create and deploy a new app:
|
||||
- `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`
|
||||
|
||||
```
|
||||
$ abra autocomplete bash
|
||||
```
|
||||
### undeploy and remove an app
|
||||
- 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`
|
||||
|
||||
```
|
||||
$ abra app new $RECIPE`
|
||||
```
|
||||
|
||||
Optional flags: `-s/--server`, `-D/--domain`, `-S/--secrets`, `-p/--pass`
|
||||
|
||||
```
|
||||
$ 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]
|
||||
```
|
||||
### upgrade a recipe
|
||||
- `abra recipe upgrade $RECIPE`
|
||||
flags: `-x,y,z/--major,minor,patch`
|
||||
- `abra recipe sync $RECIPE`
|
||||
flags: `-x,y,z`
|
||||
- `abra recipe release $RECIPE [$VERSION]`
|
||||
flags: `-p/--publish`, `-r/--dry-run`, `-x,y,z`
|
||||
|
||||
### 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`
|
||||
|
||||
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"
|
||||
|
||||
```
|
||||
$ 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".
|
||||
|
||||
|
||||
#### Filter apps by state `deployed`
|
||||
|
||||
!!! info
|
||||
|
|
@ -141,8 +71,9 @@ As you can see we, we're selecting all recipes where category is "Utilities".
|
|||
!!! 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 -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.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
---
|
||||
|
||||
## 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
|
||||
|
||||
Get a fresh copy of the `abra` source code from [here](https://git.coopcloud.tech/coop-cloud/abra).
|
||||
|
|
@ -23,11 +10,10 @@ Install [direnv](https://direnv.net), run `cp .envrc.sample .envrc`, then run `d
|
|||
|
||||
Install [Go >= 1.16](https://golang.org/doc/install) and then:
|
||||
|
||||
- `make build` to build. If this fails, run `go mod tidy`.
|
||||
- `make build` to build
|
||||
- `./abra` to run commands
|
||||
- `make test` will run tests
|
||||
- `make install-abra` will install abra to `$GOPATH/bin`
|
||||
- `make install-kadabra` will install kadabra to `$GOPATH/bin`
|
||||
- `make install` will install it to `$GOPATH/bin`
|
||||
- `go get <package>` and `go mod tidy` to add a new dependency
|
||||
|
||||
Our [Drone CI configuration](https://git.coopcloud.tech/coop-cloud/abra/src/branch/main/.drone.yml) runs a number of checks on each pushed commit. See the [Makefile](https://git.coopcloud.tech/coop-cloud/abra/src/branch/main/Makefile) for more handy targets.
|
||||
|
|
@ -266,7 +252,7 @@ For developers, while using this `-beta` format, the `y` part is the "major" ver
|
|||
|
||||
### `godotenv`
|
||||
|
||||
We maintain a fork of [godotenv](https://git.coopcloud.tech/coop-cloud/godotenv) because we need inline comment parsing for environment files. You can upgrade the version here by running `go get git.coopcloud.tech/coop-cloud/godotenv@0<COMMID>` where `<commit>` is the latest commit you want to pin to. See [`abra#391`](https://git.coopcloud.tech/coop-cloud/abra/pulls/391) for more.
|
||||
We maintain a fork of [godotenv](https://github.com/Autonomic-Cooperative/godotenv) because we need inline comment parsing for environment files. You can upgrade the version here by running `go get github.com/Autonomic-Cooperative/godotenv@<commit>` where `<commit>` is the latest commit you want to pin to. At time of writing, `go get github.com/Autonomic-Cooperative/godotenv@b031ea1211e7fd297af4c7747ffb562ebe00cd33` is the command you want to run to maintain the above functionality.
|
||||
|
||||
### `docker/client`
|
||||
|
||||
|
|
|
|||
|
|
@ -2,76 +2,36 @@
|
|||
title: Install
|
||||
---
|
||||
|
||||
## Installer script source
|
||||
!!! warning
|
||||
|
||||
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)
|
||||
We've seen reports that `abra` under [WSL](https://learn.microsoft.com/en-us/windows/wsl/about) doesn't work due to an underlying bug in Docker context handling. See [`coop-cloud/organising#406`](https://git.coopcloud.tech/coop-cloud/organising/issues/406) and [`docker/for-win#13180`](https://github.com/docker/for-win/issues/13180) for more.
|
||||
|
||||
## Stable release
|
||||
|
||||
### Wget
|
||||
|
||||
```
|
||||
wget -q -O - https://install.abra.coopcloud.tech | bash
|
||||
```
|
||||
|
||||
### Curl
|
||||
|
||||
```
|
||||
curl https://install.abra.coopcloud.tech | bash
|
||||
```
|
||||
|
||||
## Release candidate
|
||||
|
||||
### Wget
|
||||
|
||||
```
|
||||
wget -q -O - https://install.abra.coopcloud.tech | bash -s -- --rc
|
||||
```
|
||||
|
||||
### Curl
|
||||
|
||||
```
|
||||
curl https://install.abra.coopcloud.tech | bash -s -- --rc
|
||||
```
|
||||
|
||||
## Manual verification
|
||||
## Installer script source
|
||||
|
||||
You can download the `abra` binary yourself from the [releases
|
||||
page](https://git.coopcloud.tech/coop-cloud/abra/releases) along with the
|
||||
`checksums.txt` file and verify it's integrity with the following command.
|
||||
|
||||
```bash
|
||||
sha256sum -c checksums.txt --ignore-missing
|
||||
```
|
||||
|
||||
If you see a line starting with `abra_...` which matches the filename you downloaded and it ends with `OK` - you're good to go!
|
||||
|
||||
```
|
||||
abra_X.X.X-beta_linux_x86_64: OK
|
||||
```
|
||||
|
||||
Otherwise, you downloaded a corrupted file and you should re-download it.
|
||||
|
||||
## Compile from source
|
||||
|
||||
Follow the guide [here](https://docs.coopcloud.tech/abra/hack/)
|
||||
You can view that [here](https://git.coopcloud.tech/coop-cloud/abra/src/branch/main/scripts/installer/installer).
|
||||
|
||||
## Using Docker
|
||||
|
||||
```
|
||||
docker run \
|
||||
-v $HOME/.abra:/.abra \
|
||||
git.coopcloud.tech/coop-cloud/abra app ls
|
||||
-v $HOME/.abra:/.abra \
|
||||
git.coopcloud.tech/coop-cloud/abra app ls
|
||||
```
|
||||
|
||||
!!! note
|
||||
If you're using symlinks, e.g. for [sharing
|
||||
`~/.abra`](/operators/handbook/#sharing-abra), add more `-v` options for
|
||||
each directory you're symlinking to, e.g. `-v
|
||||
$HOME/Projects/CoopCloud/apps:/home/user/Projects/CoopCloud/apps`
|
||||
If you're using symlinks, e.g. for [sharing
|
||||
`~/.abra`](/operators/handbook/#sharing-abra), add more `-v` options for each
|
||||
directory you're symlinking to, e.g. `-v
|
||||
$HOME/Projects/CoopCloud/apps:/home/user/Projects/CoopCloud/apps`
|
||||
|
|
|
|||
|
|
@ -4,16 +4,8 @@ title: Quick start
|
|||
|
||||
There are a few ways to get started, here are some entrypoints listed below:
|
||||
|
||||
<div class="grid cards" markdown>
|
||||
- If you're new around here and you'd like to learn how to deploy apps with `abra`, then a good place to start is the [new operators tutorial](/operators/tutorial). If you've already deployed some apps and would like to learn how to maintain them, then the [operators handbook](/operators/handbook) is the right place.
|
||||
|
||||
- __Operators__
|
||||
|
||||
If you're new around here and you'd like to learn how to deploy apps with `abra`, then a good place to start is the [new operators tutorial](/operators/tutorial). If you've already deployed some apps and would like to learn how to maintain them, then the [operators handbook](/operators/handbook) is the right place.
|
||||
|
||||
- __Maintainers__
|
||||
|
||||
If you're installing `abra` so you can do recipe packaging, take a look at the [new maintainers tutorial](/maintainers/tutorial). `abra` can help you check the quality of the recipe you've packaged and help you publish it to the public recipe catalogue. Then others can deploy your configuration :rocket:
|
||||
|
||||
</div>
|
||||
- If you're installing `abra` so you can do recipe packaging, take a look at the [new maintainers tutorial](/maintainers/tutorial). `abra` can help you check the quality of the recipe you've packaged and help you publish it to the public recipe catalogue. Then others can deploy your configuration :rocket:
|
||||
|
||||
If you run into any issues, please see the [troubleshooting page](/abra/trouble) :bomb:
|
||||
|
|
|
|||
|
|
@ -1,107 +0,0 @@
|
|||
---
|
||||
title: Recipes
|
||||
---
|
||||
|
||||
_Recipes_ are what we call the configuration file used to deploy apps with our `abra` CLI tool. A longer explanation is in the [glossary](/glossary#recipe). Our _Catalogue_ is a web interface for exploring the currently available configurations, therefore which apps can be deployed.
|
||||
|
||||
### Catalogue
|
||||
|
||||
Our catalogue is located at [recipes.coopcloud.tech](https://recipes.coopcloud.tech/) and regularly updated :cooking:
|
||||
|
||||
[Browse Our Recipes](https://recipes.coopcloud.tech/){ .md-button .md-button--primary }
|
||||
|
||||
The catalogue is a helpful place to easily understand the status of app recipes and the link to the source-code of the recipe. To understand the various scores on recipes, read further.
|
||||
|
||||
## Status, Features, Score
|
||||
|
||||
Each recipe `README.md` has a "metadata" section, to help communicate the overall status of the recipe, and which features are supported. Here's an example, from [the Wordpress recipe](https://git.coopcloud.tech/coop-cloud/wordpress/):
|
||||
|
||||
```
|
||||
<!-- metadata -->
|
||||
|
||||
* **Category**: Apps
|
||||
* **Status**: 3, stable
|
||||
* **Image**: [`wordpress`](https://hub.docker.com/_/wordpress), 4, upstream
|
||||
* **Healthcheck**: Yes
|
||||
* **Backups**: Yes
|
||||
* **Email**: 3
|
||||
* **Tests**: 2
|
||||
* **SSO**: No
|
||||
|
||||
<!-- endmetadata -->
|
||||
```
|
||||
|
||||
Currently, recipe maintainers need to update the scores in this section manually. The specific meanings of the scores are:
|
||||
|
||||
### Status (overall score)
|
||||
|
||||
| Score | Description |
|
||||
| ----- | ------------------------------------ |
|
||||
| [5](#){ .md-score .md-score-5 } | Everything in 4 + Single-Sign-On |
|
||||
| [4](#){ .md-score .md-score-4 } | Upstream image, backups, email, healthcheck, integration testing |
|
||||
| [3](#){ .md-score .md-score-3 } | Upstream image, missing 1-2 items from 4 |
|
||||
| [2](#){ .md-score .md-score-2 } | Missing 3-4 items from 4 or no upstream image |
|
||||
| [1](#){ .md-score .md-score-1 } | Alpha |
|
||||
|
||||
### Image
|
||||
|
||||
| Score | Description |
|
||||
| ----- | ------------------------------------ |
|
||||
| 4 | Official upstream image |
|
||||
| 3 | Semi-official / actively-maintained image |
|
||||
| 2 | 3rd-party image |
|
||||
| 1 | Our own custom image |
|
||||
|
||||
### Email
|
||||
|
||||
| Score | Description |
|
||||
| ----- | ------------------------------------ |
|
||||
| 3 | Automatic (using environment variables) |
|
||||
| 2 | Mostly automatic |
|
||||
| 1 | Manual |
|
||||
| 0 | None |
|
||||
| N/A | App doesn't send email |
|
||||
|
||||
### CI (Continuous Integration)
|
||||
|
||||
| Score | Description |
|
||||
| ----- | ------------------------------------ |
|
||||
| 3 | As 2, plus healthcheck |
|
||||
| 2 | Auto secrets + networks |
|
||||
| 1 | Basic deployment using `stack-ssh-deploy`, manual secrets + networks |
|
||||
| 0 | None |
|
||||
|
||||
### Single-Sign-On
|
||||
|
||||
| Score | Description |
|
||||
| ----- | ------------------------------------ |
|
||||
| 3 | Automatic (using environment variables) |
|
||||
| 2 | Mostly automatic |
|
||||
| 1 | Manual |
|
||||
| 0 | None |
|
||||
| N/A | App doesn't support SSO |
|
||||
|
||||
## Requesting Recipes
|
||||
|
||||
If you'd like to see a new recipe packaged there are two options for you. First is to contribte one as a _Maintainer_
|
||||
The second option is to make a request on the [`recipes-wishlist`](https://git.coopcloud.tech/coop-cloud/recipes-wishlist) repository issue tracker.
|
||||
|
||||
If no one is around to help, you can always take a run at it yourself, go to the [Maintainers](/maintainers/) section to help you on your way.
|
||||
|
||||
<div class="grid cards" markdown>
|
||||
|
||||
- __Contribute Recipes__
|
||||
|
||||
Do you not see the recipe for the app you use or make? We especially love recipe maintainers :heart:
|
||||
|
||||
[Create a Recipe](/maintainers/){ .md-button .md-button--primary }
|
||||
|
||||
- __Request A Recipe__
|
||||
|
||||
Don't feel up to the task? Open an issue in the `recipes-wishlist` repository
|
||||
|
||||
[Request Recipe](https://git.coopcloud.tech/coop-cloud/recipes-wishlist){ .md-button .md-button--primary }
|
||||
|
||||
</div>
|
||||
|
||||
We've seen nice things happen when the requesters are also willing to take an active role in testing the new recipe. Teaming up with whoever volunteers to help do the packaging is best.
|
||||
|
|
@ -20,12 +20,6 @@ Host example.com
|
|||
IdentityFile ~/.ssh/example@somewhere
|
||||
```
|
||||
|
||||
and your IdentityFile should be added to the authentication agent:
|
||||
|
||||
```
|
||||
ssh-add ~/.ssh/example@somewhere
|
||||
```
|
||||
|
||||
## "abra server ls" shows the wrong details?
|
||||
|
||||
You can use `abra server rm` to remove the incorrect details. Make sure to take a backup of your `~/.abra/servers/<domain>` first. You can then try to re-create by using `abra server add ...` again.
|
||||
|
|
|
|||
|
|
@ -20,10 +20,6 @@ abra upgrade --rc
|
|||
|
||||
> 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`
|
||||
|
||||
- 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.
|
||||
|
|
@ -1,10 +1,7 @@
|
|||
---
|
||||
title: Bylaws
|
||||
title: FAQ
|
||||
---
|
||||
|
||||
The following are the bylaws which the _Co-op Cloud: Federation_ has decided
|
||||
democratically and layout our governance processes :classical_building: :fist:
|
||||
|
||||
## What is the Co-op Cloud Federation?
|
||||
|
||||
> We're still working things out, here's what know so far!
|
||||
|
|
@ -6,42 +6,9 @@ Welcome to the Co-op Cloud Federation documentation!
|
|||
|
||||
This is the public facing page where we publish all things federation in the open.
|
||||
|
||||
<div class="grid cards" markdown>
|
||||
|
||||
- __Resolutions__
|
||||
|
||||
Our drafts, in-progress and passed resolutions ✊
|
||||
|
||||
[Read More](/federation/resolutions){ .md-button .md-button--primary }
|
||||
|
||||
- __Finance__
|
||||
|
||||
Learn about how we deal with money and how to get paid 💸
|
||||
|
||||
[Read More](/federation/finance){ .md-button .md-button--primary }
|
||||
|
||||
- __Membership__
|
||||
|
||||
See who's already joined us 🥰
|
||||
|
||||
[Our Members](/federation/membership){ .md-button .md-button--primary }
|
||||
|
||||
- __Minutes__
|
||||
|
||||
All minutes from our meetings 📒
|
||||
|
||||
[Past Meetings](/federation/minutes){ .md-button .md-button--primary }
|
||||
|
||||
- __Digital Tools__
|
||||
|
||||
Tools we use to organise online 🔌
|
||||
|
||||
[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>
|
||||
- [FAQ](/federation/faq): Take a look if you're curious about the Federation is about 🤓
|
||||
- [Resolutions](/federation/resolutions): All draft, in-progress and passed resolutions ✊
|
||||
- [Finance](/federation/finance): How we deal with money 💸
|
||||
- [Membership](/federation/membership): See who's already joined in 🥰
|
||||
- [Minutes](/federation/minutes): All minutes from our meetings 📒
|
||||
- [Digital tools](/federation/tools): Tools we use to organise online 🔌
|
||||
|
|
|
|||
|
|
@ -4,17 +4,14 @@ 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
|
||||
|
||||
| Name | Dues Paid | Notes | Contact |
|
||||
| --------- | --------- | -------- |-------- |
|
||||
| Agaric | - | - | `@wolcen:matrix.org` |
|
||||
| [Autonomic](https://autonomic.zone) | - | - | `@3wc`, `@cas`, `@knoflook`, `@travvy`, `@aadil` |
|
||||
| [Bonfire](https://bonfirenetworks.org) | - | - | `@mayel:matrix.org` + Ivan (`@cambriale:matrix.org`) |
|
||||
| [Doop.coop](https://doop.coop) | - | - | `@yusf:gottsnack.net` |
|
||||
| [EOTL](https://eotl.supply) | - | - | `@basebuilder:pub.solar` |
|
||||
| [Karrot](https://karrot.world) | - | - | `@nicksellen:matrix.org` |
|
||||
| [Klasse & Methode](https://codeberg.org/Klasse-Methode) | - | - | `@p4u1_f4u1:matrix.org` |
|
||||
| [Local IT](https://local-it.org/) | - | - | Philipp (`@yksflip:matrix.kaputt.cloud`) + `@moritz:matrix.local-it.org` |
|
||||
| Mirsal ™ | - | - | `@mirsal:1312.media` |
|
||||
| [UTAW](https://utaw.tech) | - | - | `@javielico:matrix.org` |
|
||||
| [BeWater](https://bewater.contact) | Waiver | - | `@decentral1se` |
|
||||
| [ruangrupa](https://ruangrupa.id) | - | - | Henry `@babystepper:matrix.org` |
|
||||
| Name | Dues paid up? | Notes | Contact |
|
||||
| -------- | -------- | -------- |-------- |
|
||||
| Agaric | - | - | `@wolcen:matrix.org` |
|
||||
| Flancia | - | - | `@vera:fairydust.space` |
|
||||
| Autonomic | - | - | `@3wc` `@cas` `@decentral1se` `@knoflook` `@travvy` |
|
||||
| Bonfire | - | - | `@mayel:matrix.org` + Ivan (`@cambriale:matrix.org`) |
|
||||
| Doop.coop | - | - | `@yusf:gottsnack.net` |
|
||||
| Local IT | - | - | Philipp (`@yksflip:matrix.kaputt.cloud`) + `@moritz:matrix.local-it.org` |
|
||||
| ruangrupa | - | - | Henry `@babystepper:matrix.org` |
|
||||
| UTAW | - | - | `@javielico:matrix.org` |
|
||||
| ??? | - | - | `@mirsal:1312.media` |
|
||||
|
|
|
|||
|
|
@ -1,82 +0,0 @@
|
|||
---
|
||||
title: 2023-05-03
|
||||
---
|
||||
|
||||
# Co-op Cloud Federation Meeting 2023-05-03
|
||||
|
||||
Notes from last meeting: https://docs.coopcloud.tech/federation/minutes/2022-03-03/
|
||||
|
||||
Metadata
|
||||
|
||||
* Time / date: May 3 @ 1500-1630 UTC https://time.is/0330PM_3_May_2023_in_UTC
|
||||
* Location: https://meet.jit.si/coop-cloud-federation-meeting
|
||||
* Attending: Autonomic (trav, 3wc), Local-IT (yksflip, Moritz), decentral1se (🐺 /free agent)
|
||||
* Facilitation: Calix
|
||||
* Notes: trav
|
||||
|
||||
Agenda
|
||||
|
||||
_(All times UTC, as sharp as possible)_
|
||||
|
||||
* Introductions / checkins (5m)
|
||||
* How you're doing
|
||||
* Which organisation are you attached to? (if applicable)
|
||||
* a fun (or terrible) Co-op Cloud experience you've had recently
|
||||
* Packaging Rustdesk server 🥳
|
||||
* Realising backupbot labels didn't work 😱
|
||||
* Upgrading with missing backups 😅 Deployed 18-20 apps at once, wrote a script 🤯
|
||||
* Immovable force meets unstoppable bug, no deployments ⛔
|
||||
* Decisions - what passed, any new proposals? (10m) https://docs.coopcloud.tech/federation/resolutions/
|
||||
* we review the existing resolutions
|
||||
* Resolution 005 / process
|
||||
* trav: sticking to 2 week deadline for proposals?
|
||||
* d1: there was a meeting where we talked about it being a small decision but then it became medium. G
|
||||
* trav: ahh mixups happen, I don't feel strongly ultimately.
|
||||
* yksflip: maybe check-in with cas but call it passed (?). 2 weeks is a good amount of time but can understand you'd want to move on more quickly.
|
||||
* 3wc: 2 week default good. Very async coordination, espeically if folks have to go back to their co-op to check-in. Fewer people will see it the shorter it is.
|
||||
* Moritz: how to know size of the decision?
|
||||
* 3wc: smallest decision size that seems fair.
|
||||
* d1 in chat: 'who is affected by the decision'
|
||||
* d1: 2 weeks seems good, simpler to stick to that going forward. Super duper emergency budget
|
||||
* What does the second point of Resolution 004 mean
|
||||
* 3wc: first Budget is a budget for these meetings.
|
||||
* Superduperemergencybudget
|
||||
* Trav: For emergency work?
|
||||
* d1: yes, but the part that's missing is to know what is super duper emergency. There are a lot of P1 bugs but they're not all show-stoppers. There are a number of things that need to be fixed quicker than 2 weeks
|
||||
* 3wc: emergency firefighter. Up to whoever proposes the budget as to what the structure would look like.
|
||||
* abra fixes Budget / proposal thingy
|
||||
* https://pad.autonomic.zone/Fp6Zi846TNqATulYFqcJqw
|
||||
* d1: if this was proposed today, wait 2 weeks and then I'd fix them. Or standing budget?
|
||||
* trav: suggestion is wait 2 weeks then implement? or agree standing budget?
|
||||
* 3wc: yes, but also passing emergency budget would also take 2 weeks, no?
|
||||
* d1: propose this and do 10 hours or do a "10 hours" proposal and fit this into it. Not show-stopping bugs but 2 weeks wont kill us.
|
||||
* trav: might be worth passing 10h/mo, something/month for fixes, maintenance / emergency. non-binding poll / gitea voting → what to work on. vs having to package bug work together. less bureaucracy.
|
||||
* d1: can re-work decision 6 into a maintenance budget. Curious how we want to bubble-up the bugs. Board? Label?
|
||||
* yksflip: standing maintenance makes sense to me.
|
||||
* federation bootstrap funds 🤑
|
||||
* trav: there's money leftover from donor
|
||||
* d1: 6k in the pot, get the work funded.
|
||||
* trav: buffer tho?
|
||||
* Moritz: I'm paid from Local IT. How to decide who is doing which fixes?
|
||||
* d1: people tend to do stuff they want to see done. Some way to share would be good....?
|
||||
* 3wc: tags. Tickets labeled as part of maintenance budget. If assigned to someone, they are point person. Plot twist: time expectation. Someone takes something on and it's unclear when that's going to happen. Claim things for up to a week or 2 but don't claim it until you're ready to work on it.
|
||||
* ** we love it **
|
||||
* **d1 to roll into maintenance proposal**
|
||||
* doop coop dues waiver https://pad.autonomic.zone/xgd7lLxzT520O4KRXuWyuQ#
|
||||
* 3wc: yusef posted, side project, low income, would like to participate. 1 year waiver of dues. They seem enthusiastic and helpful person to be around.
|
||||
* trav: can decide now? " Individuals/groups wanting to join Co-op Cloud who aren’t able to make a financial contribution may request a solidarity free membership." doesn't say how to make decision
|
||||
* d1: medium seems fine
|
||||
* Moritz: instead of dues perhaps doing some abra fixes
|
||||
* Philip: agree on waiving fees for them. How to define time to spend on project. Alternative membership fee, donate time?
|
||||
* 3wc: part of inspiration for fedration is Co-op Cycle: too complicated to track work and money. Have to track money so wont track work. Like the simplicity. Wage is €20/h, in-kind work contribution would be 30 minutes of work contribution per month.
|
||||
* d1: reflecting on unions etc, pay dues and also contribute. Something to think about.
|
||||
|
||||
* Checkouts
|
||||
|
||||
didn't get to:
|
||||
* Breakout groups?
|
||||
* Software tools
|
||||
* Finances
|
||||
* Outreach
|
||||
* Development
|
||||
* next meeting? Is it monthly? I forget.
|
||||
|
|
@ -1,79 +0,0 @@
|
|||
---
|
||||
title: 2024-02-01
|
||||
---
|
||||
|
||||
# Co-op Cloud Federation meeting 2024-02
|
||||
|
||||
Date poll: https://crab.fit/coop-cloud-federation-february-2024-576238
|
||||
|
||||
Previous notes: https://docs.coopcloud.tech/federation/minutes/2023-05-03/
|
||||
|
||||
## Agenda
|
||||
|
||||
- check-in
|
||||
- name
|
||||
- pronouns
|
||||
- organisation
|
||||
- how we're feeling
|
||||
- anything we want to get out of today
|
||||
- emotional support for abra bugs
|
||||
- missed october 2023 membership dues review ([R002](https://docs.coopcloud.tech/federation/resolutions/passed/002/)), what now?
|
||||
- [backup restore / testing update](https://pad.riseup.net/p/UEC2JUPGb6tmRCZ7RX9X-keep)
|
||||
- collective abra next release planning
|
||||
- ✅ bonfire co-op network hosting proposal
|
||||
- ✅ next meeting
|
||||
- check-out
|
||||
- how was the meeting?
|
||||
- recommendations for next meeting
|
||||
- what are you doing for the rest of the day?
|
||||
|
||||
## Notes
|
||||
|
||||
Here: Calix, Mayel, Moritz, p4u1, d1
|
||||
Facilitating: Calix
|
||||
Notes: Mayel
|
||||
|
||||
- local-it has test framework with Playwright to test deployment, eg. testing customised configs or modified recipes - not testing app functionality but rather customisation or integrations between apps, eg. SSO - so can check if an upgrade would break - would be nice to integrate the tests into the recipes to they can be linked to the version (ie. update recipe when updating a recipe/app) - in future want to automate into CI (eg drone runner) to auto-update recipes and check for failure - will publish test framework next week on coopcloud gitea - run them first on test deployments to check in advance if update works but also then run in prod to make sure thing runs correctly in prod (eg. if email notifs are working in each app) - this does require extra thinking (eg. deleting data created by tests)
|
||||
- sounds really cool! going to look into playwright. could be handy for federated apps
|
||||
- sounds like something that orgs like nlnet may fund, maybe can merge these into a proposal to fund this + the more boring coopcloud maintainance
|
||||
|
||||
## organise meeting schedule
|
||||
- would be nice to find a regular rythm for federation meetings instead of needing date polls
|
||||
- same time? once a month?
|
||||
- in social.coop TWG they've been getting 2-3 people showing up, maybe just because haven't polled for new regular meeting time for a while
|
||||
- need someone with capacity to organise (coordination role), whether it's setting up poll or prompting people to join, to get us all in the room
|
||||
- will someone set up a date poll for march? or re. meeting frequency / how we decide -> Moritz volunteered
|
||||
|
||||
### bonfire co-op network hosting proposal
|
||||
- https://bonfirenetworks.org/hosting/
|
||||
|
||||
what co-op cloud combined with servers.coop would do. idea comes from a need from bonfire team, people who are looking to adopt bonfire, individuals, small collectives, large organisations who might not have tech savvy to set up and maintain own hosting / instances, would rather have as a service .. but we decided early on we didn't want to offer hosting ourselves. and we don't want to host any flagship instances (because centralisation). calls for easy way for people to set up and maintain instances. not just infrastructure, labour, savvy, mnaintenance and support, backups. like community-supported agriculture, "community-supported software" = community gets a say in software, have a say in prioritising. large part of funds goes into infra and labour of maintaining / operating. split among participants.
|
||||
|
||||
last funding from NLNet, included milestone. prototype instance setup wizard and management dashboard. €3k to start. small tech component, organisational and infra.
|
||||
|
||||
what would m like from CC at this stage?
|
||||
|
||||
participants help with prototyping
|
||||
start small - organisational & infrastructural side is
|
||||
communities already want instances!
|
||||
not setup wizard required, just send us an email etc. do it by hand
|
||||
|
||||
budget avail now
|
||||
|
||||
one group focused on open science, one on digital radios, online communities around music. possibilities of them finding grants, other sources of income. donations from community members? assume = there would be funds eventually. might have to be a bit of upfront freebie service, especially as we're prototyping. closed beta as we're trying things out.
|
||||
|
||||
### missed october 2023 membership dues
|
||||
- we were going to review who's paying, how's the amount. we didn't! what to do.
|
||||
|
||||
### backup restore / testing update
|
||||
- after meeting about backup bot in januarry, need to document what already exists and what has been decided, there was a proposal - will followup async
|
||||
|
||||
### collective abra next release planning
|
||||
- some are in process of improving backup/restore (still WIP) and some bugs were also found, so now it's difficult to make a release - many are self-building abra so not an issue for them, but would be good to make a plan first (next time) to avoid large refactors that block releases
|
||||
- also plan around how long features take to implement, maybe during federation meetings
|
||||
- proposal for next abra release: some bugs are fixed in main branch but release blocked by backup stuff, so could create a new branch from point where backup stuff was not merged and create release from there, so don't need to worry about incomplete backup stuff, should be pretty easy, that way can finish backup with no rush
|
||||
- if we do so, need 1 or 2 people to run integration tests + fix any bugs that appear and then do the release - ideally 1 person who has released before (d1 volunteers) + another who hasn't (p4u1 volunteers)
|
||||
|
||||
|
||||
## check out
|
||||
- in future need to talk about how long meeting can go before starting + agenda prioritisation
|
||||
|
|
@ -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
|
||||
|
||||
|
||||
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
---
|
||||
title: Drafts
|
||||
---
|
||||
|
|
@ -1,75 +0,0 @@
|
|||
---
|
||||
title: "Resolution 013"
|
||||
---
|
||||
|
||||
!!! note
|
||||
|
||||
This resolution has been amended! The main change was to remove automatic
|
||||
git synchronisation; please see [the file
|
||||
history](https://git.coopcloud.tech/coop-cloud/docs.coopcloud.tech/commits/branch/main/docs/federation/resolutions/in-progress/013.md) for a full run-down.
|
||||
|
||||
- Budget 007: Operator sync
|
||||
- Date: 2024-01-??
|
||||
- Deadline: 2024-01-XX
|
||||
- Size: Large
|
||||
|
||||
### Summary
|
||||
|
||||
As highlighted in several tickets (e.g. [`#434`](https://git.coopcloud.tech/coop-cloud/organising/issues/434), [`#467`](https://git.coopcloud.tech/coop-cloud/organising/issues/467)), several operators working together on the same server routinely run into deployment instability. This is due to the fact that we do not store the deployment version of the apps.
|
||||
|
||||
With this proposal, we would like to address the synchronisation of app deployment versions. This is being called "Operator sync". What follows is the design proposal which has already received feedback from operators on [this pad](https://pad.riseup.net/p/IebZQkpe3OOpYyVT8f1j-keep).
|
||||
|
||||
### Details (Budget 007)
|
||||
|
||||
We add support a config file (`$ABRA_DIR/config.yml`) which has these defaults:
|
||||
|
||||
We also add a `abra config` command which has the following shape:
|
||||
|
||||
```
|
||||
🌻 ./abra config -h
|
||||
NAME:
|
||||
abra config - Manage system-wide Abra configuration
|
||||
|
||||
USAGE:
|
||||
abra config command [command options]
|
||||
|
||||
COMMANDS:
|
||||
generate, g Generate default configuration
|
||||
|
||||
OPTIONS:
|
||||
--help, -h show help
|
||||
```
|
||||
|
||||
If there is no `$ABRA_DIR/config.yml` or `sync: false`, nothing changes. When `sync: true`, *only* the `abra app deploy / upgrade / rollback` commands have new behaviour.
|
||||
|
||||
There is also a new command `abra app sync <domain>` which triggers a synchronisation.
|
||||
|
||||
When `abra app deploy/upgrade/rollback/sync` is run, here's what we do:
|
||||
|
||||
* Read the `OPERATOR_SYNC_VERSION` env var as the version to deploy / upgrade from / rollback from
|
||||
* upgrade: if deployed version does not match `OPERATOR_SYNC_VERSION`, warn before overview
|
||||
* rollback: same as above!
|
||||
|
||||
* Run the deployment
|
||||
* if successful, record a new `OPERATOR_SYNC_VERSION`
|
||||
* if unsuccessful, do not record a `OPERATOR_SYNC_VERSION` and ask operator to resolve
|
||||
|
||||
If `--chaos` is passed, we use the short commit hash instead of the version label.
|
||||
|
||||
Here's an example of the `OPERATOR_SYNC_VERSION` env var:
|
||||
|
||||
```
|
||||
# in ~/.abra/servers/example.com/matrix.example.com.env
|
||||
TYPE=matrix-synapse
|
||||
OPERATOR_SYNC_VERSION=4.0.0+v1.93.0 # managed by Abra
|
||||
```
|
||||
|
||||
Operator documentation will also be provided.
|
||||
|
||||
**Budget amount**: 200 EUR (10 hrs * 20 EUR/hr)
|
||||
|
||||
**Who will implement this**: (someone?)
|
||||
|
||||
**When will the money be spent**: Before mid-February 2024
|
||||
|
||||
**What is the money for**: Implementing the first steps of operator sync.
|
||||
|
|
@ -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**
|
||||
|
|
@ -0,0 +1,3 @@
|
|||
---
|
||||
title: In progress
|
||||
---
|
||||
|
|
@ -4,21 +4,15 @@ title: Resolutions
|
|||
|
||||
### Resolution Template
|
||||
|
||||
``` yaml
|
||||
---
|
||||
title: Resolution <number>
|
||||
---
|
||||
```javascript
|
||||
## Resolution <number>: <title> - <date>
|
||||
|
||||
- Topic: <title>
|
||||
- Date: 13-12-2023
|
||||
- Deadline: Date
|
||||
- Size: large or medium
|
||||
|
||||
### Summary
|
||||
|
||||
Who this affects, and what it does...
|
||||
Who this affects, and what it does
|
||||
|
||||
### Details
|
||||
|
||||
A narrative with details...
|
||||
A narrative with details
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,9 +1,7 @@
|
|||
---
|
||||
title: "Resolution 001"
|
||||
title: "Proposal 001: Decision Making Process - 2023-03-03"
|
||||
---
|
||||
|
||||
- Topic: Decision Making Process
|
||||
- Date: 2023-03-03
|
||||
- Deadline: 2023-03-03 (live voting)
|
||||
- Size: large
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,7 @@
|
|||
---
|
||||
title: "Resolution 002"
|
||||
title: "Resolution 002: Membership/Dues - 2023-03-22"
|
||||
---
|
||||
|
||||
* Topic: Membership/Dues
|
||||
* Date: 2023-03-22
|
||||
* Deadline: 2023-04-11
|
||||
* Passed on 2023-04-13
|
||||
* Size: Large
|
||||
|
|
|
|||
|
|
@ -1,9 +1,7 @@
|
|||
---
|
||||
title: "Resolution 003"
|
||||
title: "Resolution 003: Paid work - 2023-03-22"
|
||||
---
|
||||
|
||||
* Topic: Paid work
|
||||
* Date: 2023-03-22
|
||||
* Deadline: 2023-04-11
|
||||
* Passed on 2023-04-13
|
||||
* Size: Large
|
||||
|
|
|
|||
|
|
@ -1,9 +1,7 @@
|
|||
---
|
||||
title: "Resolution 004"
|
||||
title: "Resolution 004: Budget 001: Budgeting - 2023-03-22"
|
||||
---
|
||||
|
||||
* Topic: Budget 001: Budgeting
|
||||
* Date: 2023-03-22
|
||||
* Deadline: 2023-04-11
|
||||
* Passed on 2023-04-13
|
||||
* Size: Large
|
||||
|
|
|
|||
|
|
@ -1,9 +1,7 @@
|
|||
---
|
||||
title: "Resolution 005"
|
||||
title: "Resolution 005: Public federation membership, notes and decisions - 2023-04-14"
|
||||
---
|
||||
|
||||
* Topic: Public federation membership, notes and decisions
|
||||
* Date: 2023-04-14
|
||||
* Deadline: 2023-04-17
|
||||
* Passed: 2023-04-18
|
||||
* Size: medium
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
title: "Resolution 006"
|
||||
title: "Resolution 006: Budget 002: Resolution Writing-up - 2023-05-29"
|
||||
---
|
||||
|
||||
- Budget 002: Resolution Writing-up
|
||||
- Date: 2023-05-29
|
||||
# Resolution 006: Budget 002: Resolution Writing-up - 2023-05-29
|
||||
|
||||
- Deadline: 2022-06-12
|
||||
- Size: Large
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,7 @@
|
|||
---
|
||||
title: "Resolution 007"
|
||||
title: "Resolution 007: 1 year dues waiver for Doop.coop - 2023-06-19"
|
||||
---
|
||||
|
||||
- Topic: 1 year dues waiver for Doop.coop
|
||||
- Date: 2023-06-19
|
||||
- Deadline: 2023-07-03
|
||||
- Size: Medium
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,7 @@
|
|||
---
|
||||
title: "Resolution 008"
|
||||
title: "Resolution 008: Budget 003: Paying invoices - 2023-06-19"
|
||||
---
|
||||
|
||||
- Topic: Budget 003 Paying invoices
|
||||
- Date: 2023-06-19
|
||||
- Deadline: 2022-07-03
|
||||
- Size: Large
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
title: "Resolution 009"
|
||||
title: "Resolution 009: Federation common fund buffer - 2023-07-03"
|
||||
---
|
||||
|
||||
- Topic: Federation common fund buffer
|
||||
- Date: 2023-07-03
|
||||
## Resolution 009: Federation common fund buffer - 2023-07-03
|
||||
|
||||
- Deadline: 2023-07-17
|
||||
- Size: Large
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,9 @@
|
|||
---
|
||||
title: "Resolution 010"
|
||||
title: "Resolution 010: Budget 004: Critical fixes - 2023-07-03"
|
||||
---
|
||||
|
||||
- Topic: Budget 004: Critical fixes
|
||||
- Date: 2023-07-03
|
||||
## Resolution 010: Budget 004: Critical fixes - 2023-07-03
|
||||
|
||||
- Deadline: 2023-07-17
|
||||
- Size: Large
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,7 @@
|
|||
---
|
||||
title: "Resolution 011"
|
||||
title: "Resolution 011: Budget 005: Backup improvements - 2023-07-23"
|
||||
---
|
||||
|
||||
- Topic: Budget 005: Backup improvements
|
||||
- Date: 2023-07-23
|
||||
- Deadline: 2022-08-06
|
||||
- Size: Large
|
||||
|
||||
|
|
|
|||
|
|
@ -1,9 +1,7 @@
|
|||
---
|
||||
title: "Resolution 012"
|
||||
title: "Resolution 012: Budget 006: Abra integration test suite - 2023-09-09"
|
||||
---
|
||||
|
||||
- Budget 006: Abra integration test suite
|
||||
- Date: 2023-09-09
|
||||
- Deadline: 2023-09-23
|
||||
- Size: Large
|
||||
|
||||
|
|
|
|||
|
|
@ -1,45 +0,0 @@
|
|||
---
|
||||
title: "Resolution 014"
|
||||
---
|
||||
|
||||
- Topic: Budget 008: Critical Fixes
|
||||
- Date: 2023-12-06
|
||||
- Deadline: 2023-12-24
|
||||
- Size: Large
|
||||
|
||||
## Summary
|
||||
|
||||
We (decentral1se, wykwit, moritz, knoflook) have identified bugs and lacking features that are a big obstacle to using abra.
|
||||
|
||||
We have roughly estimated the work to fix the bugs to take between 27 and 75 hours. We would also like to request onboarding budget for two new developers to smoothly get started on the bug fixes (10 hours per person).
|
||||
|
||||
We'd like to request no more than 1900€ of budget to cover the labor and onboarding. If less than 95 hours is spent, the remaining budget will not be paid out.
|
||||
|
||||
## Details
|
||||
|
||||
estimating: small (1-3 hours), medium (3-8 hours), large (8-15 hours) & order is priority.
|
||||
|
||||
|
||||
| NAME | estimation |
|
||||
| ---- | ----- |
|
||||
| [#535 Comment parsing and modifiers](https://git.coopcloud.tech/coop-cloud/organising/issues/535) | Large |
|
||||
| [#519 abra app new `[<recipe>]` `[<version>]`](https://git.coopcloud.tech/coop-cloud/organising/issues/519) | Medium |
|
||||
| [#518 Abra fails silently if required image doesn't exist](https://git.coopcloud.tech/coop-cloud/organising/issues/518) | Medium |
|
||||
| [#527 abra catalogue generate `<recipe name>` ignores the specified recipe](https://git.coopcloud.tech/coop-cloud/organising/issues/527) | Small |
|
||||
| [#509 abra app remove could wait until volume is not in use](https://git.coopcloud.tech/coop-cloud/organising/issues/509) | Medium |
|
||||
| [#530 abra recipe fetch can only fetch a single recipe](https://git.coopcloud.tech/coop-cloud/organising/issues/530) | Medium |
|
||||
| [#525 prevent abra app cp from applying file permissions.](https://git.coopcloud.tech/coop-cloud/organising/issues/525) | Medium |
|
||||
| [#537 Fix the operators tutorial](https://git.coopcloud.tech/coop-cloud/organising/issues/537) | Medium |
|
||||
|
||||
Estimation: best case: (8 * 1) + (3 * 6) + (1 * 1) = 27 hours
|
||||
Estimation: worst case: (15 * 1) + (8 * 6) + (1 * 3) = 73 hours
|
||||
+ 10 hours for onboarding * 2 people = 47-93 hours
|
||||
|
||||
|
||||
**Budget amount**: 1900€/95 hours at maximum
|
||||
|
||||
**Who will implement this:** p4u1, wykwit, moritz, knoflook
|
||||
|
||||
**When will the money be spent:** Before the end of February 2024.
|
||||
|
||||
**What is the money for:** Fixing bugs and improving operator docs.
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
---
|
||||
title: "Resolution 015"
|
||||
---
|
||||
|
||||
- Topic: Klasse & Methode joins the Co-op Cloud Federation
|
||||
- Date: 25-01-2024
|
||||
- Deadline: 08-02-2024
|
||||
- Size: Large
|
||||
|
||||
### Summary
|
||||
|
||||
[Klasse & Methode - IT Kollektiv Stuttgart](https://codeberg.org/Klasse-Methode).
|
||||
|
||||
`@p4u1` has been active in Abra hacking & coordination on several issues. K & M
|
||||
manage a Co-op Cloud deployment with 9 apps running at the time of the
|
||||
proposal.
|
||||
|
||||
### Details
|
||||
|
||||
K & M is volunteer based and are unable to pay the membership fees at this time
|
||||
and ask for a waiver for 1 year. To be revisited on 25-01-2025.
|
||||
|
|
@ -1,48 +0,0 @@
|
|||
---
|
||||
title: "Resolution 016"
|
||||
---
|
||||
|
||||
- Topic: Budget 008: Backup-bot-two Documentation and Specification
|
||||
- Date: 27-01-2024
|
||||
- Deadline: 10th February 2024
|
||||
- Size: Large
|
||||
|
||||
### Summary
|
||||
|
||||
> (Co-written by p4u1 & d1)
|
||||
|
||||
The new backup-bot-two implementation is nearly finished. The only remaining step is to implement restore functionality. In a recently meeting with Moritz, p4u1 & d1, we discussed how to design and implement it. The mintues are [here](https://pad.riseup.net/p/UEC2JUPGb6tmRCZ7RX9X-keep).
|
||||
|
||||
In this meeting, we realised that there is already a lot of implicit, undocumented knowledge about how backup-bot-two & abra work together. How the restore interface will work is more or less designed in the meeting, with general agreement.
|
||||
|
||||
In order to communicate that design, we feel we need to have clear documentation and a specification on how things work. This will make sure we have consensus before commiting more budget to implementing the final step. It will also help operators pick up, use & extend backup-bot-two in the future.
|
||||
|
||||
In this resolution, we want to propose to write the initial documentation and specification for the new [backup-bot-two](https://git.coopcloud.tech/coop-cloud/backup-bot-two/).
|
||||
|
||||
The existing documentation for the old backupbot should be taken into account wherever possible.
|
||||
|
||||
### Details (Budget 008)
|
||||
|
||||
Documentation should be for:
|
||||
|
||||
- Operators using the backup-bot-two
|
||||
- Maintainers of recipes
|
||||
|
||||
The documentation should have:
|
||||
|
||||
- Examples on using Abra with the backupbot
|
||||
- Examples of recipe configurations
|
||||
- Detailed explanation of features and their limitations
|
||||
|
||||
The Specification should include:
|
||||
|
||||
- Detailed specification on how annotations work
|
||||
- With the specification it should be possible to implement backup and restore
|
||||
without looking at the backupbot-two code
|
||||
|
||||
---
|
||||
|
||||
- Budget amount: 200 EUR (10 hrs * 20 EUR/hr)
|
||||
- Who will implement this: p4u1
|
||||
- When will the money be spent: Before the end of February
|
||||
- What is the money for: Writing documentation and specification for backup-bot-two
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
---
|
||||
title: "Resolution 017"
|
||||
---
|
||||
|
||||
- Topic: BeWater joins the Co-op Cloud Federation
|
||||
- Date: 30-01-2024
|
||||
- Deadline: 21-02-2024
|
||||
- Size: Large
|
||||
|
||||
### Summary
|
||||
|
||||
> [BeWater Co-op](https://bewater.contact).
|
||||
|
||||
`@decentral1se` is a member and has been active in Abra hacking & coordination
|
||||
on several issues. BeWater maintains several small-scale Co-op Cloud
|
||||
deployments.
|
||||
|
||||
### Details
|
||||
|
||||
BeWater is just starting and we're currently unable to pay the membership fees
|
||||
at this time and ask for a waiver for 1 year. To be revisited on 30-01-2025.
|
||||
|
|
@ -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 🤗♥️
|
||||
|
|
@ -1,25 +0,0 @@
|
|||
---
|
||||
title: "Support Us"
|
||||
---
|
||||
|
||||
If you like what you see whilst browsing Co-op Cloud and would like to
|
||||
contribute financially, as opposed to with code, we currently receive donations
|
||||
via an [Open Collective account](https://opencollective.com/coop-cloud).
|
||||
|
||||
<div class="grid cards" markdown>
|
||||
|
||||
- __Infrastructure Support__
|
||||
|
||||
If you make use of our digital infrastructure and want to help out with
|
||||
maintenance costs, we wold be grateful :heart:
|
||||
|
||||
[Donate Now](https://opencollective.com/coop-cloud/contribute/infrastructure-sustainability-29878/checkout){ .md-button .md-button--primary }
|
||||
|
||||
- __Join The Federation__
|
||||
|
||||
If you want to be more actively involved as a supporter, consider joining
|
||||
our Federation :handshake_tone2:
|
||||
|
||||
[Learn More](/federation/){ .md-button .md-button--primary }
|
||||
|
||||
</div>
|
||||
|
|
@ -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:
|
||||
|
||||
- [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:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,180 +0,0 @@
|
|||
---
|
||||
title: Comparisons
|
||||
---
|
||||
|
||||
We think it's important to understand that *Co-op Cloud* is more than just
|
||||
software and technical configurations. It is also a novel organization of *how*
|
||||
to [create technology socially](https://docs.coopcloud.tech/federation).
|
||||
However, strictly technically speaking you may be wondering:
|
||||
|
||||
### What about `$alternative`?
|
||||
|
||||
We have various technical critiques of other similar projects which are already up-and-running in the ecosystem, as they don't necessarily meet our needs as a small tech co-op. However, Co-op Cloud isn't meant to be a replacement for these other projects.
|
||||
|
||||
Here is a short overview of the pros/cons we see, in relation to our goals and needs.
|
||||
|
||||
### Cloudron
|
||||
|
||||
[Cloudron](https://www.cloudron.io) is complete solution for running apps on your own server
|
||||
|
||||
**Pros**
|
||||
|
||||
- 👍 Decent web interface for app, domain & user management.
|
||||
- 👍 Large library of apps.
|
||||
- 👍 Built-in SSO using LDAP, which is compatible with more apps and often has a better user interface than OAuth.
|
||||
- 👍 Apps are actively maintained by the Cloudron team.
|
||||
|
||||
**Cons**
|
||||
|
||||
- 👎 Moving away from open source. The core is now proprietary software.
|
||||
- 👎 Libre tier has a single app limit.
|
||||
- 👎 Based on Docker images, not stacks, so multi-process apps (e.g. parsoid visual editor for Mediawiki) are a non-starter.
|
||||
- 👎 Difficult to extend apps.
|
||||
- 👎 Only supported on Ubuntu LTS.
|
||||
- 👎 Upstream libre software communities aren't involved in packaging.
|
||||
- 👎 Limited to vertical scaling.
|
||||
- 👎 Tension between needs of hosting provider and non-technical user.
|
||||
- 👎 LDAP introduces security problems - one vulnerable app can expose a user's password for all apps.
|
||||
- 👎 Bit of a [black box](https://en.wikipedia.org/wiki/Black_box).
|
||||
|
||||
### YunoHost
|
||||
|
||||
[YunoHost](https://yunohost.org) is an operating system aiming for the simplest administration of a server
|
||||
|
||||
**Pros**
|
||||
|
||||
- 👍 Lovely web interface for app, domain & user management.
|
||||
- 👍 Bigger library of apps.
|
||||
- 👍 Awesome backup / deploy / restore continuous integration testing.
|
||||
- 👍 Supports hosting apps in subdirectories as well as subdomains.
|
||||
- 👍 Doesn't require a public-facing IP.
|
||||
- 👍 Supports system-wide mutualisation of resources for apps (e.g. sharing databases by default)
|
||||
|
||||
**Cons**
|
||||
|
||||
- 👎 Upstream libre software communities aren't involved in packaging.
|
||||
- 👎 Uninstalling apps leaves growing cruft.
|
||||
- 👎 Limited to vertical scaling.
|
||||
- 👎 Not intended for use by hosting providers.
|
||||
|
||||
### Caprover
|
||||
|
||||
[CapRover](https://caprover.com) is an easy to use app/database deployment & web server manager for applications
|
||||
|
||||
**Pros**
|
||||
|
||||
- 👍 Bigger library of apps.
|
||||
- 👍 Easy set-up using a DigitalOcean one-click app.
|
||||
- 👍 Works without a domain name or a public IP, in non-HTTPS mode (good for homeservers).
|
||||
- 👍 Deploy any app with a `docker-compose.yml` file as a "One Click App" via the web interface.
|
||||
- 👍 Multi-node (multi-server) set-up works by default.
|
||||
|
||||
**Cons**
|
||||
|
||||
- 👎 Single-file app definition format, difficult to tweak using entrypoint scripts.
|
||||
- 👎 Nginx instead of Traefik for load-balancing.
|
||||
- 👎 Command-line client requires NodeJS / `npm`.
|
||||
- 👎 [Requires 512MB RAM for a single app](https://github.com/caprover/caprover/issues/28).
|
||||
- 👎 [Backup/restore is "experimental"](https://caprover.com/docs/backup-and-restore.html), and doesn't currently help with backing up Docker volumes.
|
||||
- 👎 Exposes its bespoke management interface to the internet via HTTPS by default.
|
||||
|
||||
### Ansible
|
||||
|
||||
[Ansible](https://www.ansible.com) mature automation and deployment tool.
|
||||
|
||||
**Pros**
|
||||
|
||||
- 👍 Includes server creation and bootstrapping.
|
||||
|
||||
**Cons**
|
||||
|
||||
- 👎 Upstream libre software communities aren't publishing Ansible roles.
|
||||
- 👎 Lots of manual work involved in things like app isolation, backups, updates.
|
||||
|
||||
### Kubernetes
|
||||
|
||||
[Kubernetes](https://kubernetes.io) (or K8s) is a system for automating deployment, scaling, and
|
||||
management of containerized applications.
|
||||
|
||||
|
||||
**Pros**
|
||||
|
||||
- 👍 Helm charts are available for some key apps already.
|
||||
- 👍 Scale all the things.
|
||||
|
||||
**Cons**
|
||||
|
||||
- 👎 Too big -- requires 3rd party tools to run a single-node instance.
|
||||
- 👎 Not suitable for a small to mid size hosting provider.
|
||||
|
||||
### Docker-compose
|
||||
|
||||
[Docker Compose](https://docs.docker.com/compose/) is a tool for defining and running multi-container applications.
|
||||
|
||||
**Pros**
|
||||
|
||||
- 👍 Quick to set up and familiar for many developers.
|
||||
|
||||
**Cons**
|
||||
|
||||
- 👎 Manual work required for process monitoring.
|
||||
- 👎 Secret storage not available yet.
|
||||
- 👎 Swarm is the new best practice.
|
||||
|
||||
### Doing it Manually (Old School)
|
||||
|
||||
If you are an absolute Shaman in a Shell and learning new gadgets just slows you down,
|
||||
have it, but maybe ask how old [is old enough](https://en.wikipedia.org/wiki/Printing_press)?
|
||||
|
||||
**Pros**
|
||||
|
||||
- 👍 Simple - just follow upstream instructions to install and update.
|
||||
|
||||
**Cons**
|
||||
|
||||
- 👎 Loads of manual work required for app isolation and backups.
|
||||
- 👎 Array of sysadmin skills required to install and maintain apps.
|
||||
- 👎 Hard to share configurations into the commons.
|
||||
- 👎 No idea who has done what change when.
|
||||
|
||||
|
||||
### Stackspin
|
||||
|
||||
[Stackspin](https://www.stackspin.net) deployment and management stack for a
|
||||
handful of popular team collaboration apps.
|
||||
|
||||
**Pros**
|
||||
|
||||
- 👍 Easy instructions to install & upgrade multiple tightly integrated apps.
|
||||
- 👍 Offers a unified SSO user experience.
|
||||
- 👍 Offers tightly integrated logging, monitoring, and maintenance.
|
||||
- 👍 Has a strong focus and attention to security.
|
||||
|
||||
**Cons**
|
||||
|
||||
- 👎 Upstream libre software communities aren't involved in packaging.
|
||||
- 👎 It is not designed to be a general specification.
|
||||
- 👎 Hard to share configurations into the commons.
|
||||
- 👎 Significantly limited library of eight apps.
|
||||
- 👎 Additional apps are treated as "External Apps" with only OAuth2/OpenID integration.
|
||||
- 👎 Requires a Kubernetes cluster.
|
||||
|
||||
|
||||
### Maadix
|
||||
|
||||
[Maadix](https://maadix.net) managed hosting and deployment of popular privacy preserving applications.
|
||||
|
||||
**Pros**
|
||||
|
||||
- 👍 Nice looking web interface for app, domain & user management.
|
||||
- 👍 Offers a paid hosting service to get up and running easily.
|
||||
|
||||
**Cons**
|
||||
|
||||
- 👎 Upstream libre software communities aren't involved in packaging.
|
||||
- 👎 It is not designed to be a general specification.
|
||||
- 👎 Hard to share configurations into the commons.
|
||||
- 👎 Limited library of apps.
|
||||
- 👎 Uses *OpenNebula*, *Ansible*, and *Puppet* as underlying technologies.
|
||||
- 👎 Appears to be only a team of two people.
|
||||
- 👎 Appears to be inactive on Mastodon and limited GitLab activity.
|
||||
|
|
@ -2,33 +2,16 @@
|
|||
title: Get in touch
|
||||
---
|
||||
|
||||
We welcome developers, sys-admins, designers, UX folks, Q&A testers, and passionate users to join us.
|
||||
Pick the right medium for your interests.
|
||||
## Email
|
||||
|
||||
<div class="grid cards" markdown>
|
||||
[`helo@coopcloud.tech`](mailto:helo@coopcloud.tech)
|
||||
|
||||
- __Chat__
|
||||
## Chat
|
||||
|
||||
[Matrix](https://matrix.org) is our chat platform of choice, we are happy to hear from you there :speech_left:
|
||||
### Matrix
|
||||
|
||||
[Join Chats](https://matrix.to/#/!xSMwGbdVehScXcIFwS:autonomic.zone?via=autonomic.zone&via=matrix.org&via=1312.media){ .md-button .md-button--primary }
|
||||
Here is a link to the [Matrix space](https://matrix.to/#/!xSMwGbdVehScXcIFwS:autonomic.zone?via=autonomic.zone&via=matrix.org&via=1312.media) to see all channels.
|
||||
|
||||
- __Codebases__
|
||||
## Forum
|
||||
|
||||
Get straight to looking at our code or filing issues, hop to our Gitea instance :sunglasses:
|
||||
|
||||
[Browse Code](https://git.coopcloud.tech/coop-cloud){ .md-button .md-button--primary }
|
||||
|
||||
- __Forum__
|
||||
|
||||
If you prefer communicating asynchronously with topical categories :tropical_drink:
|
||||
|
||||
[Our Forum](https://community.coops.tech/){ .md-button .md-button--primary }
|
||||
|
||||
- __Email__
|
||||
|
||||
If you like it old school, feel free to fire up port 25 and send us a `HELO` message :email:
|
||||
|
||||
[Email Us](mailto:helo@coopcloud.tech){ .md-button .md-button--primary }
|
||||
|
||||
</div>
|
||||
[`community.coops.tech`](https://community.coops.tech/)
|
||||
|
|
|
|||
|
|
@ -8,12 +8,7 @@ Co-op Cloud aims to make hosting libre software apps simple for small service pr
|
|||
|
||||
## Who is behind the project?
|
||||
|
||||
The project was started by workers at [Autonomic](https://autonomic.zone/) which
|
||||
is a [worker-owned co-operative](https://en.wikipedia.org/wiki/Worker_cooperative) who provides
|
||||
technologies and infrastructure to empower users to make a positive impact on
|
||||
the world. Numerous other like minded co-ops have since joined our
|
||||
[Federation](/federation/) and rely *Co-op Cloud* in production.
|
||||
|
||||
The project was started by workers at [Autonomic](https://autonomic.zone/) which is a [worker-owned co-operative](https://en.wikipedia.org/wiki/Worker_cooperative). We provide technologies and infrastructure to empower users to make a positive impact on the world. We're using Co-op Cloud in production, amongst other systems.
|
||||
|
||||
## Why Co-op Cloud?
|
||||
|
||||
|
|
@ -37,14 +32,126 @@ the world. Numerous other like minded co-ops have since joined our
|
|||
|
||||
## Why start another project?
|
||||
|
||||
We think our carefully chosen blend of technologies and our [social approach](/federation/) is quite unique in today's technology landscape.
|
||||
Please read our [initial project announcement post](https://autonomic.zone/blog/co-op-cloud/) for more on this.
|
||||
|
||||
Also see our [strategy page](../strategy/).
|
||||
|
||||
## How do I make a recipe for (package) an app?
|
||||
|
||||
Head on over to **Maintainers** section and see ["Package your first recipe"](/maintainers/tutorial/#package-your-first-recipe) for more.
|
||||
See ["Package your first recipe"](/maintainers/tutorial/#package-your-first-recipe) for more.
|
||||
|
||||
## What about `$alternative`?
|
||||
|
||||
We have various technical critiques of other similar projects which are already up-and-running in the ecosystem, as they don't necessarily meet our needs as a small tech co-op. However, Co-op Cloud isn't meant to be a replacement for these other projects.
|
||||
|
||||
Here is a short overview of the pros/cons we see, in relation to our goals and needs.
|
||||
|
||||
### Cloudron
|
||||
|
||||
#### Pros
|
||||
|
||||
- 👍 Decent web interface for app, domain & user management.
|
||||
- 👍 Large library of apps.
|
||||
- 👍 Built-in SSO using LDAP, which is compatible with more apps and often has a better user interface than OAuth.
|
||||
- 👍 Apps are actively maintained by the Cloudron team.
|
||||
|
||||
#### Cons
|
||||
|
||||
- 👎 Moving away from open source. The core is now proprietary software.
|
||||
- 👎 Libre tier has a single app limit.
|
||||
- 👎 Based on Docker images, not stacks, so multi-process apps (e.g. parsoid visual editor for Mediawiki) are a non-starter.
|
||||
- 👎 Difficult to extend apps.
|
||||
- 👎 Only supported on Ubuntu LTS.
|
||||
- 👎 Upstream libre software communities aren't involved in packaging.
|
||||
- 👎 Limited to vertical scaling.
|
||||
- 👎 Tension between needs of hosting provider and non-technical user.
|
||||
- 👎 LDAP introduces security problems - one vulnerable app can expose a user's password for all apps.
|
||||
- 👎 Bit of a [black box](https://en.wikipedia.org/wiki/Black_box).
|
||||
|
||||
### YunoHost
|
||||
|
||||
#### Pros
|
||||
|
||||
- 👍 Lovely web interface for app, domain & user management.
|
||||
- 👍 Bigger library of apps.
|
||||
- 👍 Awesome backup / deploy / restore continuous integration testing.
|
||||
- 👍 Supports hosting apps in subdirectories as well as subdomains.
|
||||
- 👍 Doesn't require a public-facing IP.
|
||||
- 👍 Supports system-wide mutualisation of resources for apps (e.g. sharing databases by default)
|
||||
|
||||
#### Cons
|
||||
|
||||
- 👎 Upstream libre software communities aren't involved in packaging.
|
||||
- 👎 Uninstalling apps leaves growing cruft.
|
||||
- 👎 Limited to vertical scaling.
|
||||
- 👎 Not intended for use by hosting providers.
|
||||
|
||||
### Caprover
|
||||
|
||||
#### Pros
|
||||
|
||||
- 👍 Bigger library of apps.
|
||||
- 👍 Easy set-up using a DigitalOcean one-click app.
|
||||
- 👍 Works without a domain name or a public IP, in non-HTTPS mode (good for homeservers).
|
||||
- 👍 Deploy any app with a `docker-compose.yml` file as a "One Click App" via the web interface.
|
||||
- 👍 Multi-node (multi-server) set-up works by default.
|
||||
|
||||
#### Cons
|
||||
|
||||
- 👎 Single-file app definition format, difficult to tweak using entrypoint scripts.
|
||||
- 👎 Nginx instead of Traefik for load-balancing.
|
||||
- 👎 Command-line client requires NodeJS / `npm`.
|
||||
- 👎 [Requires 512MB RAM for a single app](https://github.com/caprover/caprover/issues/28).
|
||||
- 👎 [Backup/restore is "experimental"](https://caprover.com/docs/backup-and-restore.html), and doesn't currently help with backing up Docker volumes.
|
||||
- 👎 Exposes its bespoke management interface to the internet via HTTPS by default.
|
||||
|
||||
### Ansible
|
||||
|
||||
#### Pros
|
||||
|
||||
- 👍 Includes server creation and bootstrapping.
|
||||
|
||||
#### Cons
|
||||
|
||||
- 👎 Upstream libre software communities aren't publishing Ansible roles.
|
||||
- 👎 Lots of manual work involved in things like app isolation, backups, updates.
|
||||
|
||||
### Kubernetes
|
||||
|
||||
#### Pros
|
||||
|
||||
- 👍 Helm charts are available for some key apps already.
|
||||
- 👍 Scale all the things.
|
||||
|
||||
#### Cons
|
||||
|
||||
- 👎 Too big -- requires 3rd party tools to run a single-node instance.
|
||||
- 👎 Not suitable for a small to mid size hosting provider.
|
||||
|
||||
### Docker-compose
|
||||
|
||||
#### Pros
|
||||
|
||||
- 👍 Quick to set up and familiar for many developers.
|
||||
|
||||
#### Cons
|
||||
|
||||
- 👎 Manual work required for process monitoring.
|
||||
- 👎 Secret storage not available yet.
|
||||
- 👎 [Swarm is the new best practice](https://github.com/BretFisher/ama/issues/8#issuecomment-367575011).
|
||||
|
||||
### Doing it Manually (Old School)
|
||||
|
||||
#### Pros
|
||||
|
||||
- 👍 Simple - just follow upstream instructions to install and update.
|
||||
|
||||
#### Cons
|
||||
|
||||
- 👎 Loads of manual work required for app isolation and backups.
|
||||
- 👎 Array of sysadmin skills required to install and maintain apps.
|
||||
- 👎 Hard to share configurations into the commons.
|
||||
- 👎 No idea who has done what change when.
|
||||
|
||||
## Which technologies are used?
|
||||
|
||||
|
|
@ -107,28 +214,13 @@ We are happy to see the compose specification emerging as a new open standard be
|
|||
|
||||
## Why Docker Swarm?
|
||||
|
||||
While many have noted that "swarm is dead" it is in fact [not dead](https://www.mirantis.com/blog/mirantis-will-continue-to-support-and-develop-docker-swarm/) (2020). As detailed in the [architecture overview](/intro/strategy/#container-orchestrator), *Swarm* offers an appropriate feature set which allows us to support zero-down time upgrades, seamless app rollbacks, automatic deploy failure handling, scaling, hybrid cloud setups and maintain a decentralised design.
|
||||
While many have noted that "swarm is dead" it is in fact [not dead](https://www.mirantis.com/blog/mirantis-will-continue-to-support-and-develop-docker-swarm/). As detailed in the [architecture overview](/operators/tutorial/#container-orchestrator), swarm offers an appropriate feature set which allows us to support zero-down time upgrades, seamless app rollbacks, automatic deploy failure handling, scaling, hybrid cloud setups and maintain a decentralised design.
|
||||
|
||||
While the industry is bordering on a [k8s](https://kubernetes.io/) obsession and the need to [scale down](https://microk8s.io/) a tool that was fundamentally built for massive scale, we are going with *Swarm* because it is the tool most suitable for [small technology](https://small-tech.org/).
|
||||
While the industry is bordering on a [k8s](https://kubernetes.io/) obsession and the need to [scale down](https://microk8s.io/) a tool that was fundamentally built for massive scale, we are going with swarm because it is the tool most suitable for [small technology](https://small-tech.org/).
|
||||
|
||||
The _Co-op Cloud Community’s_ forecast at the start of 2024 for the future of *Docker Swarm* is positive after five years after *Mirantis’s* acquisition of Docker Enterprise
|
||||
in 2018. Since then, their strategy has developed towards using *Docker Swarm* as an intermediary step between Docker/Docker-Compose, and *Kubernetes* – where
|
||||
previously it seemed like their aim was to migrate all their customers’ [deployments to Kubernetes](https://www.mirantis.com/blog/kubernetes-vs-swarm-these-companies-use-both) (Oct, 2022).
|
||||
*Mirantis* acquired Docker Enterprise in 2019 and today delivers enterprise-grade Swarm—either as a managed service or with enterprise support through Mirantis Kubernetes Engine.
|
||||
|
||||
There is reasonably healthy activity in their issue tracker with label [`area/swarm`](https://github.com/moby/moby/issues?q=+label%3Aarea%2Fswarm+).
|
||||
Additionally, we see it as reassuring that *Mirantis* has a growing number of pages relating to *Docker Swarm*:
|
||||
|
||||
- [Mirantis' Product Page](https://www.mirantis.com/software/swarm/)
|
||||
- [What's next for Swarm: New features, the same world-class support](https://www.mirantis.com/blog/what-s-next-for-swarm) (Oct, 2022)
|
||||
- [Docker Swarm Still Thriving Three Years after Mirantis Acquisition](https://www.mirantis.com/company/press-center/company-news/docker-swarm-still-thriving-three-years-after-mirantis-acquisition-often-running-side-by-side-with-kubernetes/) (Nov, 2022)
|
||||
|
||||
Lastly, it’s worth mentioning that much of the configuration involved in setting up *Docker Swarm*, particularly in terms of preparing images, and in managing the conceptual side, are transferable to other orchestration engines.
|
||||
We hope to see a container orchestrator tool that is not directly linked to a for-profit company emerge soon but for now, this is what we have.
|
||||
|
||||
If you want to learn more, see [dockerswarm.rocks](https://dockerswarm.rocks/) for a nice guide.
|
||||
See also this list of [`awesome-swarm`](https://github.com/BretFisher/awesome-swarm) by Bret Fisher.
|
||||
|
||||
If you want to learn more, see [dockerswarm.rocks](https://dockerswarm.rocks/) for a nice guide. See also [`BretFisher/awesome-swarm`](https://github.com/BretFisher/awesome-swarm).
|
||||
|
||||
## What licensing model do you use?
|
||||
|
||||
|
|
|
|||
|
|
@ -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`
|
||||
|
|
@ -1,105 +1,19 @@
|
|||
---
|
||||
title: Project Strategy
|
||||
title: Project strategy
|
||||
---
|
||||
|
||||
From our experiences working and organising as Autonomic, the tech co-op who [initiated Co-op Cloud](https://autonomic.zone/blog/co-op-cloud/), we know that the progressive tech movement lack reliable and cost-effective technical means for providing a sustainable alternative to _Big Tech_© services which are marketed as "[cloud computing](https://en.wikipedia.org/wiki/Cloud_computing)".
|
||||
!!! note "Yes, we are blog"
|
||||
|
||||
## Technological Saviors?
|
||||
Some leading thoughts are outlined in the [project launch blog post](https://autonomic.zone/blog/co-op-cloud/) also.
|
||||
|
||||
From our experiences working and organising as Autonomic, the tech co-op who initiated Co-op Cloud, we know that the progressive tech movement lack reliable and cost-effective technical means for providing an alternative to “Big Tech” cloud services.
|
||||
|
||||
The urgency for providing an alternative comes out of the understanding that the concentration of our digital lives within the private sphere of corporate providers (e.g. [GAFAM](https://degooglisons-internet.org/en/)) represents a loss of freedom due to the threat to our privacy and self-determination through surveillance and monopolisation.
|
||||
|
||||
As a movement, we cannot compete with corporate providers in terms of cost and scale. Their network effects and available capital means that no one project, product or organisation can create the required shift to a more widespread public interest technology.
|
||||
|
||||
> Technology alone will not save us
|
||||
>
|
||||
> Simply deploying libre software is not enough.
|
||||
Technology alone will not save us. Simply deploying libre software is not enough.
|
||||
|
||||
Our strategy is to mutualise our resources to facilitate this shift. _Co-op Cloud_ is an attempt to create a new shared resource - an open and democratically managed, open standards based, copyleft licensed, libre software infrastructure project.
|
||||
Our strategy is to mutualise our resources to facilitate this shift. Co-op Cloud is an attempt to create a new shared resource - an open and democratically managed, open standards based, copyleft licensed, libre software infrastructure project.
|
||||
|
||||
From this base, we can focus on the urgent and necessary social organising work that goes beyond the technical question.
|
||||
|
||||
## The Moving Parts
|
||||
|
||||
_Co-op Cloud_ is made up of a few simple, composable pieces. The system does not rely on any one specific implementation: each part may be replaced and/or extended as needed. We want to build a resilient and long-term sustainable project and that means allowing for different implementations, open formats and a diverse project organisation. Here are the main technical concepts listed below,
|
||||
|
||||
``` mermaid
|
||||
graph LR
|
||||
A[Libre Software\n Apps] --> B{Recipe Packaging};
|
||||
B --> C[CLI Tool];
|
||||
C --> D[Container\n Orchestrator];
|
||||
```
|
||||
|
||||
Once you [grok](https://en.wikipedia.org/wiki/Grok) this, you grok the moving parts of the entire project. You can then move on to [deploying your first app](/operators/tutorial/#deploy-your-first-app).
|
||||
|
||||
### Libre Software Apps
|
||||
|
||||
Libre software apps are tools- they take the shape of websites, mobile apps, and software clients that you may already use in your daily life, for example...
|
||||
|
||||
<div class="grid cards" markdown>
|
||||
|
||||
- :simple-nextcloud: __Nextcloud__
|
||||
- :simple-jitsi: __Jitsi__
|
||||
- :simple-wikimediacommons: __Mediawiki__
|
||||
- :fontawesome-solid-rocket: __Rocket.chat__
|
||||
|
||||
</div>
|
||||
|
||||
...and many more. These apps are also often referred to as _open-Source_ or _Free-Software_. These are tools that are created by volunteer communities who use [free software licenses] in order to build up the public software commons and offer more digital alternatives to [proprietary systems].
|
||||
|
||||
The communities who develop these softwares also publish them using [containers]. For example, here is the [Nextcloud hub.docker.com account] which allows end-users to quickly deploy a new Nextcloud instance.
|
||||
|
||||
There is a growing consensus in the free software community that containers are a useful and time saving format for distribution.
|
||||
|
||||
!!! question "Why did you choose to use containers?"
|
||||
|
||||
Learn more [in the FAQ section](/intro/faq/#why-containers).
|
||||
|
||||
[free software licenses]: https://www.gnu.org/philosophy/free-sw.html
|
||||
[nextcloud hub.docker.com account]: https://hub.docker.com/_/nextcloud
|
||||
[proprietary systems]: https://en.wikipedia.org/wiki/Proprietary_software
|
||||
[containers]: https://www.docker.com/resources/what-container
|
||||
|
||||
### Recipe Packaging Format
|
||||
|
||||
However, just having a container of an app is often not enough. The work required to deploy that app in a "production ready" setup is still too time intensive and often involves a duplication of effort.
|
||||
|
||||
Each service provider needs to deal with the same problems: stable versioning, backup plan, secret management, upgrade plan, monitoring and the list goes on.
|
||||
|
||||
Individual free software projects can't take on all this responsibility. They provide the containers as is, in a secure and ready-to-go manner but it is up to service providers to worry about how the app is deployed.
|
||||
|
||||
Therefore, Co-op Cloud proposes a packaging format, which we refer to as a recipe, that describes the entire production state of the app in a single place. This format uses the existing [standards based compose specification].
|
||||
|
||||
This is a file format which is most commonly used by the [Docker compose] tool but Co-op Cloud **does not** require the use of Docker compose itself. Furthermore, as described below, we also don't rely on the actual Docker CLI itself either. We do however use a lot of the underlying libraries.
|
||||
|
||||
!!! question "Why did you choose to use the compose specificiation?"
|
||||
Learn more [in the FAQ section](/intro/faq/#why-use-the-compose-specification).
|
||||
|
||||
[Each recipe] that Co-op cloud provides is described using the compose specification and makes use of the upstream project published container when possible (sometimes they don't publish one!).
|
||||
|
||||
This is the core of our approach to working with the ecosystem of free software communities. We want to maximise the chances of sharing work, knowledge and build solidarity through concrete co-operation.
|
||||
|
||||
[standards based compose specification]: https://compose-spec.io
|
||||
[docker compose]: https://docs.docker.com/compose/
|
||||
[each recipe]: /recipes/
|
||||
|
||||
### Container Orchestrator
|
||||
|
||||
Once we have our app packaged as a recipe, we need a deployment environment (e.g. a server & something to keep the containers running). Production deployments are typically expected to support a number of features which give hosters and end-users guarantees for stability.
|
||||
|
||||
The Co-op cloud makes use of [Docker swarm] as a deployment environment. It offers an approriate feature set which allows us to support zero-down time upgrades, seamless app rollbacks, automatic deploy failure handling, scaling, hybrid cloud setups and maintain a decentralised design.
|
||||
|
||||
!!! question "Why did you choose to use Docker Swarm?"
|
||||
|
||||
Learn more [in the FAQ section](/intro/faq/#why-docker-swarm).
|
||||
|
||||
[docker swarm]: https://docs.docker.com/engine/swarm/
|
||||
|
||||
### Command-line tool
|
||||
|
||||
Finally, we need a tool to read the recipe package format and actually deploy the app. For this, we have developed and published the [abra] command-line tool.
|
||||
|
||||
`abra` aims at providing a simple command-line interface for managing your own Co-op Cloud. You can bootstrap machines with the required tools, create new apps and deploy them. `abra` is written in [Go](https://go.dev/) and uses a lot of the libraries that the `docker` and `docker-compose` CLIs use but does not rely on those interfaces directly.
|
||||
|
||||
`abra` is our flagship command-line client but it does not need to be the only client. `abra` was designed in such a way that it complements a workflow which can still be done completely manually. If Co-op Cloud goes away tomorrow, our configuration commons would still be useful and usable.
|
||||
|
||||
[abra]: /abra/
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ This is a [compose specification](https://compose-spec.io/) compliant file that
|
|||
|
||||
### `.env.sample`
|
||||
|
||||
This file is a skeleton for environmental variables that should be adjusted by the user. Examples include: domain or PHP extension list. Whenever you create a new app with `abra app new` this file gets copied to the `~/.abra/servers/<server-domain>/<app-domain>.env` and when you run `abra app config <app-domain>` you're editing this file.
|
||||
This file is a skeleton for environmental variables that should be adjusted by the user. Examples include: domain or php extention list. Whenever you create a new app with `abra app new` this file gets copied to the `~/.abra/servers/<server-domain>/<app-domain>.env` and when you run `abra app config <app-domain>` you're editing this file.
|
||||
|
||||
### `abra.sh`
|
||||
|
||||
|
|
@ -391,17 +391,11 @@ 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 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`.
|
||||
|
||||
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
|
||||
|
||||
To generate an entire new copy of the catalogue:
|
||||
|
|
@ -431,34 +425,6 @@ You can pass `--publish` to have `abra` automatically publish those changes.
|
|||
|
||||
In order to have `abra` publish changes for you automatically, you'll have to have write permissons to the git.coopcloud.tech repository and your account must have a working SSH key configuration. `abra` will use the SSH based URL connection details for Git by automagically creating an `origin-ssh` remote in the repository and pushing to it.
|
||||
|
||||
## How is I make the catalogue automatically regenerate after new versions are published?
|
||||
|
||||
"I'd like to make it so that whenever I push a new git tag to the
|
||||
[`coop-cloud/rallly` repository](https://git.coopcloud.tech/coop-cloud/rallly)
|
||||
(probably [using `abra recipe
|
||||
release`](#how-do-i-release-a-new-recipe-version)), it automatically does the
|
||||
[recipe catalogue generation steps](#how-do-i-generate-the-recipe-catalogue)"
|
||||
|
||||
1. Check whether tag builds are already trying to run: go to
|
||||
https://build.coopcloud.tech, search for the recipe name (in this case taking
|
||||
you to https://build.coopcloud.tech/coop-cloud/rallly/settings). If there are
|
||||
failing builds, or if you see builds succeeding but catalogue regeneration
|
||||
doesn't seem to be happening, then either dive in and try and fix it, or ask
|
||||
for help in [`#coopcloud-tech`](https://matrix.to/#/#coopcloud-tech:autonomic.zone)
|
||||
2. Otherwise, click "activate repository". You probably want to set the "disable pull
|
||||
requests" and "disable forks" options; they won't work anyway, but the
|
||||
failures might be confusing.
|
||||
3. Make sure there is a `generate recipe catalogue` step in the recipe's
|
||||
`.drone.yml` -- if there isn't, you can copy [the one from
|
||||
`coop-cloud/rallly`](https://git.coopcloud.tech/coop-cloud/rallly/src/branch/main/.drone.yml#L24-L38) unchanged.
|
||||
4. That's it! Now, when you push a new tag, the recipe catalogue will regenerate
|
||||
automatically. You can test this by re-pushing a tag (e.g. `git push origin
|
||||
:0.5.0+3.5.1 && git push 0.5.0+3.5.1`)
|
||||
|
||||
## How does automatic catalogue regeneration work?
|
||||
|
||||
TODO
|
||||
|
||||
## How do I enable healthchecks
|
||||
|
||||
A healthcheck is an important and often overlooked part of the recipe configuration. It is part of the configuration that the runtime uses to figure out if a container is really up-and-running. You can tweak what command to run, how often and how many times to try until you assume the container is not up.
|
||||
|
|
@ -696,21 +662,6 @@ You should be able to deploy this overriden configuration now.
|
|||
|
||||
## 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"
|
||||
|
||||
This is an issue related to the way Git/`go-git` handle Git tags internally. We
|
||||
|
|
|
|||
|
|
@ -1,23 +1,8 @@
|
|||
---
|
||||
title: Maintainers
|
||||
title: Maintainers guide
|
||||
---
|
||||
|
||||
Welcome to the maintainers guide! Maintainers are typically individuals who have a stake in building up and maintaining our digital configuration commons, the recipe configurations. Maintainers help keep recipes configurations up to date, respond to issues in a timely manner, help new users within the community and recruit new maintainers when possible.
|
||||
|
||||
<div class="grid cards" markdown>
|
||||
|
||||
- __New Maintainers Tutorial__
|
||||
|
||||
If you want to package a recipe and/or become a maintainer, start here :rocket:
|
||||
|
||||
[Get Started](/maintainers/tutorial){ .md-button .md-button--primary }
|
||||
|
||||
- __Packaging Handbook__
|
||||
|
||||
One-stop shop for all you need to know to package recipes :package:
|
||||
|
||||
[Read Handbook](/maintainers/handbook){ .md-button .md-button--primary }
|
||||
|
||||
</div>
|
||||
|
||||
Maintainers are encouraged to submit documentation patches! Sharing is caring :sparkling_heart:
|
||||
- [New maintainers tutorial](/maintainers/tutorial): If you want to package a recipe and/or become a maintainer, start here :rocket:
|
||||
- [Packaging handbook](/maintainers/handbook): One-stop shop for all you need to know to package recipes :package:
|
||||
|
|
|
|||
|
|
@ -16,10 +16,10 @@ Depending on your familiarity with recipes, it might be worth reading [how a rec
|
|||
|
||||
The ideal scenario is when the upstream project provides both the packaged image and a compose configuration which we can build from. If you're in luck, you'll typically find a `Dockerfile` and a `docker-compose.yml` file in the root of the upstream Git repository for the app.
|
||||
|
||||
- **Tired**: Write your own image and compose file from scratch :sleeping:
|
||||
- **Wired**: Use someone else's image (& maybe compose file) :smirk_cat:
|
||||
- **Inspired**: Upstream image, someone else's compose file :exploding_head:
|
||||
- **On fire**: Upstream image, upstream compose file :fire:
|
||||
- **Tired**: Write your own image and compose file from scratch
|
||||
- **Wired**: Use someone else's image (& maybe compose file)
|
||||
- **Inspired**: Upstream image, someone else's compose file
|
||||
- **On fire**: Upstream image, upstream compose file
|
||||
|
||||
### Writing / adapting the `compose.yml`
|
||||
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
---
|
||||
title: Operators Handbook
|
||||
title: Operations handbook
|
||||
---
|
||||
|
||||
## Understanding `~/.abra`
|
||||
|
|
@ -205,6 +205,30 @@ 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.
|
||||
|
||||
## Validating `abra` binary checksums
|
||||
|
||||
You can download `abra` yourself from the [releases page](https://git.coopcloud.tech/coop-cloud/abra/releases) along with the `checksums.txt` file.
|
||||
|
||||
```bash
|
||||
grep $(sha256sum abra_[version]_[platform]) checksums.txt > /dev/null && echo "checksum OK"
|
||||
```
|
||||
|
||||
If "checksum OK" appears in your terminal - you're good to go!
|
||||
|
||||
Otherwise, you have downloaded a corrupted file.
|
||||
|
||||
## 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?
|
||||
|
||||
The requirements are:
|
||||
|
|
@ -214,12 +238,6 @@ The requirements are:
|
|||
1. Swarm mode initialised
|
||||
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
|
||||
wget -O- https://get.docker.com | bash
|
||||
|
|
@ -236,6 +254,18 @@ 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.
|
||||
|
|
@ -317,20 +347,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).
|
||||
|
||||
With `abra`, you can simply run the commands:
|
||||
|
||||
```
|
||||
$ abra app backup <domain>
|
||||
$ abra app restore <domain>
|
||||
```
|
||||
|
||||
With `abra`, you can simply run `abra app backup ...` & `abra app restore ...`.
|
||||
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?
|
||||
|
||||
MySQL / MariaDB:
|
||||
|
|
@ -455,28 +474,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
|
||||
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!
|
||||
|
|
|
|||
|
|
@ -1,23 +1,8 @@
|
|||
---
|
||||
title: Operators
|
||||
title: Operators Guide
|
||||
---
|
||||
|
||||
Welcome to the operators guide! Operators are typically individuals, members of tech co-ops or collectives who provide services powered by Co-op Cloud. This documentation is meant to help new & experienced operators manage their deployments as well as provide a space for sharing tricks & tips for keeping things running smoothly.
|
||||
Welcome to the operators guide! Operators are typically individuals, members of tech co-ops or collectives who provide services powered by Co-op Cloud. This documentation is meant to help new & experienced operators manage their deployments as well as provide a space for sharing tricks & tips for keeping things running smoothly. Operators are encouraged to submit documentation patches! Sharing is caring :sparkling_heart:
|
||||
|
||||
<div class="grid cards" markdown>
|
||||
|
||||
- __New Operators Tutorial__
|
||||
|
||||
If you want to become an operator, start your journey here :rocket:
|
||||
|
||||
[Get started](tutorial.md){ .md-button .md-button--primary }
|
||||
|
||||
- __Operators Handbook__
|
||||
|
||||
One-stop shop for all you need to know to manage a deployment :ribbon:
|
||||
|
||||
[Read Handbook](handbook.md){ .md-button .md-button--primary }
|
||||
|
||||
</div>
|
||||
|
||||
Operators are encouraged to submit documentation patches! Sharing is caring :sparkling_heart:
|
||||
- [New operators tutorial](/operators/tutorial): If you want to become an operator, start here :rocket:
|
||||
- [Operations handbook](/operators/handbook): One-stop shop for all you need to know to manage a deployment :ribbon:
|
||||
|
|
|
|||
|
|
@ -1,8 +1,83 @@
|
|||
---
|
||||
title: New Operators Tutorial
|
||||
title: New operators tutorial
|
||||
---
|
||||
|
||||
This tutorial assumes you understand the [frequently asked questions](/intro/faq/) as well as [the moving parts](/intro/strategy/) of the technical problems _Co-op Cloud_ solves. If yes, proceed :smile:
|
||||
## The moving parts
|
||||
|
||||
Co-op Cloud is made up of a few simple, composable pieces. The system does not rely on any one specific implementation: each part may be replaced and/or extended as needed.
|
||||
|
||||
We want to build a resilient and long-term sustainable project and that means allowing for different implementations, open formats and a diverse project organisation.
|
||||
|
||||
Here are the main technical concepts listed below, once you [grok](https://en.wikipedia.org/wiki/Grok) this, you grok the moving parts of the entire project. You can then move on to [deploying your first app](/operators/tutorial/#deploy-your-first-app).
|
||||
|
||||
### Libre software apps
|
||||
|
||||
Libre software apps are tools, websites & software clients that you may already use in your daily life: [Nextcloud], [Jitsi], [Mediawiki], [Rocket.chat] and [many more]!
|
||||
|
||||
These are tools that are created by volunteer communities who use [free software licenses] in order to build up the public software commons and offer more digital alternatives to [proprietary systems].
|
||||
|
||||
The communities who develop these softwares also publish them using [containers]. For example, here is the [Nextcloud hub.docker.com account] which allows end-users to quickly deploy a new Nextcloud instance.
|
||||
|
||||
There is a growing consensus in the free software community that containers are a useful and time saving format for distribution.
|
||||
|
||||
!!! question "Why did you choose to use containers?"
|
||||
|
||||
Learn more [in the FAQ section](/intro/faq/#why-containers).
|
||||
|
||||
[nextcloud]: https://nextcloud.com
|
||||
[jitsi]: https://jitsi.org
|
||||
[mediawiki]: https://mediawiki.org
|
||||
[rocket.chat]: https://rocket.chat
|
||||
[many more]: /recipes/
|
||||
[free software licenses]: https://www.gnu.org/philosophy/free-sw.html
|
||||
[nextcloud hub.docker.com account]: https://hub.docker.com/_/nextcloud
|
||||
[proprietary systems]: https://en.wikipedia.org/wiki/Proprietary_software
|
||||
[containers]: https://www.docker.com/resources/what-container
|
||||
|
||||
### The recipe packaging format
|
||||
|
||||
However, just having a container of an app is often not enough. The work required to deploy that app in a "production ready" setup is still too time intensive and often involves a duplication of effort.
|
||||
|
||||
Each service provider needs to deal with the same problems: stable versioning, backup plan, secret management, upgrade plan, monitoring and the list goes on.
|
||||
|
||||
Individual free software projects can't take on all this responsibility. They provide the containers as is, in a secure and ready-to-go manner but it is up to service providers to worry about how the app is deployed.
|
||||
|
||||
Therefore, Co-op Cloud proposes a packaging format, which we refer to as a recipe, that describes the entire production state of the app in a single place. This format uses the existing [standards based compose specification].
|
||||
|
||||
This is a file format which is most commonly used by the [Docker compose] tool but Co-op Cloud **does not** require the use of Docker compose itself. Furthermore, as described below, we also don't rely on the actual Docker CLI itself either. We do however use a lot of the underlying libraries.
|
||||
|
||||
!!! question "Why did you choose to use the compose specificiation?"
|
||||
Learn more [in the FAQ section](/intro/faq/#why-use-the-compose-specification).
|
||||
|
||||
[Each recipe] that Co-op cloud provides is described using the compose specification and makes use of the upstream project published container when possible (sometimes they don't publish one!).
|
||||
|
||||
This is the core of our approach to working with the ecosystem of free software communities. We want to maximise the chances of sharing work, knowledge and build solidarity through concrete co-operation.
|
||||
|
||||
[standards based compose specification]: https://compose-spec.io
|
||||
[docker compose]: https://docs.docker.com/compose/
|
||||
[each recipe]: /recipes/
|
||||
|
||||
### Container orchestrator
|
||||
|
||||
Once we have our app packaged as a recipe, we need a deployment environment (e.g. a server & something to keep the containers running). Production deployments are typically expected to support a number of features which give hosters and end-users guarantees for stability.
|
||||
|
||||
The Co-op cloud makes use of [Docker swarm] as a deployment environment. It offers an approriate feature set which allows us to support zero-down time upgrades, seamless app rollbacks, automatic deploy failure handling, scaling, hybrid cloud setups and maintain a decentralised design.
|
||||
|
||||
!!! question "Why did you choose to use Docker Swarm?"
|
||||
|
||||
Learn more [in the FAQ section](/intro/faq/#why-docker-swarm).
|
||||
|
||||
[docker swarm]: https://docs.docker.com/engine/swarm/
|
||||
|
||||
### Command-line tool
|
||||
|
||||
Finally, we need a tool to read the recipe package format and actually deploy the app. For this, we have developed and published the [abra] command-line tool.
|
||||
|
||||
`abra` aims at providing a simple command-line interface for managing your own Co-op Cloud. You can bootstrap machines with the required tools, create new apps and deploy them. `abra` is written in [Go](https://go.dev/) and uses a lot of the libraries that the `docker` and `docker-compose` CLIs use but does not rely on those interfaces directly.
|
||||
|
||||
`abra` is our flagship command-line client but it does not need to be the only client. `abra` was designed in such a way that it complements a workflow which can still be done completely manually. If Co-op Cloud goes away tomorrow, our configuration commons would still be useful and usable.
|
||||
|
||||
[abra]: /abra/
|
||||
|
||||
## Deploy your first app
|
||||
|
||||
|
|
@ -11,14 +86,11 @@ In order to deploy an app you need two things:
|
|||
1. a server with SSH access and a public IP address
|
||||
2. a domain name pointing to that server
|
||||
|
||||
This tutorial tries to help you make choices about which server and which DNS setup you need to run a _Co-op Cloud_ deployment but it does not go into great depth about how to set up a new server.
|
||||
The tutorial tries to help you make choices about which server and which DNS setup you need to run a Co-op Cloud deployment but it does not go into great depth about how to set up a new server.
|
||||
|
||||
??? question "Can `abra` help automate this?"
|
||||
!!! question "Can `abra` help automate this?"
|
||||
|
||||
Our `abra` tool can help bootstrap new servers & configure DNS records for
|
||||
you. We'll skip that for now since we're just getting started. For more on
|
||||
these topics after you finish the tutorial see the [operators
|
||||
handbook](/operators/handbook).
|
||||
`abra` can help bootstrap new servers & configure DNS records for you. We'll skip that for now since we're just getting started. See the [operators handbook](/operators/handbook) for more on these topics after you finish the tutorial.
|
||||
|
||||
### Server setup
|
||||
|
||||
|
|
@ -32,12 +104,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:
|
||||
|
||||
!!! 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
|
||||
wget -O- https://get.docker.com | bash
|
||||
|
|
@ -50,7 +116,7 @@ docker swarm init
|
|||
docker network create -d overlay proxy
|
||||
```
|
||||
|
||||
??? question "Do you support multiple web proxies?"
|
||||
!!! question "Do you support multiple web proxies?"
|
||||
|
||||
We do not know if it is feasible and convenient to set things up on an existing server with another web proxy which uses ports `:80` & `:443`. We'd happily receive reports and documentation on how to do this if you manage to set it up!
|
||||
|
||||
|
|
@ -65,43 +131,36 @@ Your entries in your DNS provider setup might look like the following.
|
|||
|
||||
Where `116.203.211.204` can be replaced with the IP address of your server.
|
||||
|
||||
??? question "How do I know my DNS is working?"
|
||||
!!! question "How do I know my DNS is working?"
|
||||
|
||||
You can use a tool like `dig` on the command-line to check if your server has the necessary DNS records set up. Something like `dig +short <domain>` should show the IP address of your server if things are working.
|
||||
|
||||
### Install `abra`
|
||||
### Command-line setup
|
||||
|
||||
Now we can install [`abra`](/abra) locally on your machine and hook it up to
|
||||
your server. We support a script-based installation method ([script source](https://git.coopcloud.tech/coop-cloud/abra/src/branch/main/scripts/installer/installer)):
|
||||
#### Install `abra`
|
||||
|
||||
Now we can install [`abra`](/abra) locally on your machine and hook it up to your server.
|
||||
|
||||
We support a script-based installation method (script source [here](https://git.coopcloud.tech/coop-cloud/abra/src/branch/main/scripts/installer/installer)):
|
||||
|
||||
```bash
|
||||
curl https://install.abra.coopcloud.tech | bash
|
||||
```
|
||||
|
||||
The installer will verify the downloaded binary checksum. If you prefer, you can
|
||||
[manually verify](/abra/install/#manual-verification) the binary, and then
|
||||
manally place it in one the directories in your `$PATH` variable. To validate
|
||||
that everything is working try listing the `--help` command or `-h` to view
|
||||
output:
|
||||
|
||||
```bash
|
||||
abra -h
|
||||
```
|
||||
|
||||
You may need to add the `~/.local/bin/` directory to your `$PATH` variable, in
|
||||
order to run the executable.
|
||||
The installer will verify the downloaded binary checksum. You may need to add the `~/.local/bin/` directory with your `$PATH` in order to run the executable. You can validate that everything is in working order by listing the default help output:
|
||||
|
||||
```bash
|
||||
export PATH=$PATH:$HOME/.local/bin
|
||||
abra -h # check it works
|
||||
```
|
||||
|
||||
If you run into issues during installation, [please report a ticket](https://git.coopcloud.tech/coop-cloud/organising/issues/new) :pray: Once you're all set up, we **highly** recommend configuring command-line auto-completion for `abra`. See `abra autocomplete -h` for more on how to do this.
|
||||
If you run into issues during installation, [please report a ticket](https://git.coopcloud.tech/coop-cloud/abra/issues/new) :pray: Once you're all set up, we **highly** recommend configuring command-line auto-completion for `abra`. See `abra autocomplete -h` for more on how to do this.
|
||||
|
||||
??? question "Can I install `abra` on my server?"
|
||||
!!! question "Can I install `abra` on my server?"
|
||||
|
||||
Yes, this is possible. However, the instructions for this setup are different. For more info see [this handbook entry](/operators/handbook/#running-abra-server-side).
|
||||
Yes, this is possible, see [this handbook entry](/operators/handbook/#running-abra-server-side) for more. The instructions for setup are a little different however.
|
||||
|
||||
### Add your server
|
||||
#### Add your server
|
||||
|
||||
Now you can connect `abra` with your server. You should have a working SSH configuration before you can do this (e.g. a matching `Host <server-domain>` entry in `~/.ssh/config` with the correct SSH connection details). That means you can run `ssh <server-domain>` on your command-line and everything Works :tm:.
|
||||
|
||||
|
|
@ -114,46 +173,35 @@ It is important to note that `<domain>` here is a publicy accessible domain name
|
|||
|
||||
You will now have a new `~/.abra/` folder on your local file system which stores all the configuration of your Co-op Cloud instance.
|
||||
|
||||
By now `abra` should have registered this server as managed. To confirm this run:
|
||||
`abra` should now register this server as managed in your server listing:
|
||||
|
||||
```
|
||||
abra server ls
|
||||
```
|
||||
|
||||
??? warning "Beware of SSH dragons :dragon_face:"
|
||||
!!! warning "Beware of SSH dragons"
|
||||
|
||||
Under the hood `abra` uses plain 'ol `ssh` and aims to make use of your
|
||||
existing SSH configurations in `~/.ssh/config` and interfaces with your
|
||||
running `ssh-agent` for password protected secret key files.
|
||||
`abra` uses plain 'ol SSH under the hood and aims to make use of your existing SSH configurations in `~/.ssh/config` and interfaces with your running `ssh-agent` for password protected secret key files.
|
||||
|
||||
Running `server add` with `-d` or `--debug` should help you debug what is going
|
||||
on under the hood. If you're running into SSH connection issues with `abra`
|
||||
take a moment to read [this troubleshooting
|
||||
entry](/abra/trouble/#ssh-connection-issues).
|
||||
Running `server add` with `-d/--debug` should help you debug what is going on under the hood. It's best to take a moment to read [this troubleshooting entry](/abra/trouble/#ssh-connection-issues) if you're running into SSH connection issues with `abra`.
|
||||
|
||||
??? question "How do I share my configs in `~/.abra`?"
|
||||
!!! question "How do I share my configs in `~/.abra`?"
|
||||
|
||||
It's possible and quite easy, for more see [this handbook entry](/operators/handbook/#understanding-app-and-server-configuration).
|
||||
It's possible and quite easy, see [this handbook entry](/operators/handbook/#understanding-app-and-server-configuration) for more.
|
||||
|
||||
### Web proxy setup
|
||||
|
||||
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
|
||||
supports automatic SSL certificate configuration and other quality-of-life
|
||||
features which make deploying libre apps more enjoyable.
|
||||
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.
|
||||
|
||||
**1. To get started, you'll need to create a new app:**
|
||||
To get started, you'll need to create a new app:
|
||||
|
||||
```bash
|
||||
abra app new traefik
|
||||
```
|
||||
|
||||
Choose your newly registered server and specify a domain name. By default `abra`
|
||||
will suggest `<app-name>.server.org` or prompt you with a list of servers.
|
||||
|
||||
|
||||
**2. Configure this new `traefix` app**
|
||||
Choose your newly registered server and specify a domain name.
|
||||
|
||||
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 +209,14 @@ You will want to take a look at your generated configuration and tweak the `LETS
|
|||
abra app config <traefik-domain>
|
||||
```
|
||||
|
||||
Every app you deploy will have one of these `.env` files, which contains
|
||||
variables which will be injected into app configurations when deployed. These
|
||||
files exist at relevantly named path:
|
||||
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.
|
||||
|
||||
```bash
|
||||
~/.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:**
|
||||
Now it is time to deploy:
|
||||
|
||||
```
|
||||
abra app deploy <traefik-domain>
|
||||
```
|
||||
|
||||
Voila. Abracadabra :magic_wand: your first app is deployed :sparkles:
|
||||
|
||||
|
||||
### Deploy Nextcloud
|
||||
|
||||
And now we can deploy apps. Let's create a new Nextcloud app.
|
||||
|
|
@ -197,7 +227,7 @@ abra app new nextcloud -S
|
|||
|
||||
The `-S` or `--secrets` flag is used to generate secrets for the app: database connection password, root password and admin password.
|
||||
|
||||
??? warning "Beware of password dragons :dragon:"
|
||||
!!! warning "Beware of password dragons"
|
||||
|
||||
Take care, these secrets are only shown once on the terminal so make sure to take note of them! `abra` makes use of the [Docker secrets](/operators/handbook/#managing-secret-data) mechanism to ship these secrets securely to the server and store them as encrypted data. Only the apps themselves have access to the values from here on, they're placed in `/run/secrets` on the container file system.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,23 +1,9 @@
|
|||
---
|
||||
title: Organisers
|
||||
title: Organisers Guide
|
||||
---
|
||||
|
||||
Welcome to the organisers guide! Organisers are folks who focus on the social work in the project. Speaking for the project at talks, helping new tech co-ops & collectives join, keeping an eye out for funding opportunities, seeing what things come up in the community chats, etc. It's important work.
|
||||
|
||||
<div class="grid cards" markdown>
|
||||
|
||||
- __Organisers Handbook__
|
||||
|
||||
One-stop shop for all you need to know to organise in the community :sparkles:
|
||||
|
||||
[Read Handbook](/organisers/handbook){ .md-button .md-button--primary }
|
||||
|
||||
- __Say Hello First__
|
||||
|
||||
If you like what you see, but are not sure how to best contribute :speech_left:
|
||||
|
||||
[Get In Touch](/get-involved/){ .md-button .md-button--primary }
|
||||
|
||||
</div>
|
||||
|
||||
We're still working out what it looks like to do this kind of work in the project. If you like the idea of this kinda of work and/or are already doing it, please send patches to improve this documentation :rocket:
|
||||
|
||||
- [Organising handbook](/organisers/handbook): One-stop shop for all you need to know to organise in the community :sparkles:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,83 @@
|
|||
---
|
||||
title: Recipes
|
||||
---
|
||||
|
||||
!!! note "Unsure of what a "recipe" is exactly?"
|
||||
|
||||
Not to worry, we've got you covered, check out our [glossary page entry](/glossary#recipe).
|
||||
|
||||
## Catalogue
|
||||
|
||||
The recipe catalogue is a web interface for exploring
|
||||
what kind of configurations we have available in the project and therefore what apps can be deployed.
|
||||
|
||||
It aims to be a helpful place to understand the status of apps, who is taking care of the configs and who is maintaining deployed instances of which app.
|
||||
|
||||
The recipe catalogue is available on [recipes.coopcloud.tech](https://recipes.coopcloud.tech/).
|
||||
|
||||
## Status / features / scoring
|
||||
|
||||
Each recipe README has a "metadata" section, to help communicate the overall status of the recipe, and which features are supported. Here's an example, from [the Wordpress recipe](https://git.coopcloud.tech/coop-cloud/wordpress/):
|
||||
|
||||
```
|
||||
<!-- metadata -->
|
||||
|
||||
* **Category**: Apps
|
||||
* **Status**: 3, stable
|
||||
* **Image**: [`wordpress`](https://hub.docker.com/_/wordpress), 4, upstream
|
||||
* **Healthcheck**: Yes
|
||||
* **Backups**: Yes
|
||||
* **Email**: 3
|
||||
* **Tests**: 2
|
||||
* **SSO**: No
|
||||
|
||||
<!-- endmetadata -->
|
||||
```
|
||||
|
||||
Currently, recipe maintainers need to update the scores in this section manually. The specific meanings of the scores are:
|
||||
|
||||
### Status (overall score)
|
||||
|
||||
- 5: everything in 4 + Single-Sign-On
|
||||
- 4: upstream image, backups, email, healthcheck, integration testing
|
||||
- 3: upstream image, missing 1-2 items from 4
|
||||
- 2: missing 3-4 items from 4 or no upstream image
|
||||
- 1: alpha
|
||||
|
||||
### Image
|
||||
|
||||
- 4: official upstream image
|
||||
- 3: semi-official / actively-maintained image
|
||||
- 2: 3rd-party image
|
||||
- 1: our own custom image
|
||||
|
||||
### Email
|
||||
|
||||
- 3: automatic (using environment variables)
|
||||
- 2: mostly automatic
|
||||
- 1: manual
|
||||
- 0: none
|
||||
- N/A: app doesn't send email
|
||||
|
||||
### CI
|
||||
|
||||
- 3: as 2, plus healthcheck
|
||||
- 2: auto secrets + networks
|
||||
- 1: basic deployment using `stack-ssh-deploy`, manual secrets + networks
|
||||
- 0: none
|
||||
|
||||
### Single-Sign-On
|
||||
|
||||
- 3: automatic (using environment variables)
|
||||
- 2: mostly automatic
|
||||
- 1: manual
|
||||
- 0: none
|
||||
- N/A: app doesn't support SSO
|
||||
|
||||
## Wishlist
|
||||
|
||||
If you'd like to see a new recipe packaged, make a request on the [recipes-wishlist](https://git.coopcloud.tech/coop-cloud/recipes-wishlist) repository issue tracker.
|
||||
|
||||
We've seen nice things happen when the requesters are also willing to take an active role in testing the new recipe. Teaming up with whoever volunteers to help do the packaging is best.
|
||||
|
||||
If no one is around to help, you can always take a run at it yourself, we have [a section](/maintainers/) ready to help you on your way.
|
||||
|
|
@ -4,14 +4,6 @@
|
|||
--md-primary-fg-color--dark: #ee4a33;
|
||||
}
|
||||
|
||||
/* Button styling tweaks */
|
||||
|
||||
.md-button {
|
||||
margin: .25em !important;
|
||||
padding: .15em .6em !important;
|
||||
font-size: .85em !important;
|
||||
}
|
||||
|
||||
/* Navbar styling tweaks */
|
||||
|
||||
.md-search__form {
|
||||
|
|
@ -46,37 +38,3 @@
|
|||
background-color: #6A9CFF !important;
|
||||
color: var(--md-primary-bg-color) !important;
|
||||
}
|
||||
|
||||
.md-score {
|
||||
display: inline-block;
|
||||
padding: .15em .75em;
|
||||
cursor: normal;
|
||||
border-radius: .25em;
|
||||
font-size: .85em;
|
||||
font-weight: 700;
|
||||
}
|
||||
|
||||
.md-score-5 {
|
||||
color: #ffffff !important;
|
||||
background-color: #28a745;
|
||||
}
|
||||
|
||||
.md-score-4 {
|
||||
color: #ffffff !important;
|
||||
background-color: #007bff;
|
||||
}
|
||||
|
||||
.md-score-3 {
|
||||
color: #ffffff !important;
|
||||
background-color: #ffc107;
|
||||
}
|
||||
|
||||
.md-score-2 {
|
||||
color: #ffffff !important;
|
||||
background-color: #dc3545;
|
||||
}
|
||||
|
||||
.md-score-1 {
|
||||
color: #ffffff !important;
|
||||
background-color: #343a40;
|
||||
}
|
||||
|
|
|
|||
93
mkdocs.yml
93
mkdocs.yml
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
site_author: Co-op Cloud
|
||||
site_name: "Co-op Cloud: Docs"
|
||||
site_name: "Co-op Cloud: Public Interest Infrastructure"
|
||||
site_url: https://docs.coopcloud.tech
|
||||
use_directory_urls: true
|
||||
|
||||
|
|
@ -26,57 +26,41 @@ theme:
|
|||
copyright: Copyleft 2023 Co-op Cloud
|
||||
|
||||
markdown_extensions:
|
||||
- meta
|
||||
- admonition
|
||||
- attr_list
|
||||
- codehilite:
|
||||
guess_lang: false
|
||||
- def_list
|
||||
- footnotes
|
||||
- md_in_html
|
||||
- meta
|
||||
- toc:
|
||||
permalink: true
|
||||
- pymdownx.betterem:
|
||||
smart_enable: all
|
||||
- pymdownx.details
|
||||
- pymdownx.emoji:
|
||||
emoji_generator: !!python/name:material.extensions.emoji.to_svg
|
||||
emoji_index: !!python/name:material.extensions.emoji.twemoji
|
||||
- pymdownx.magiclink
|
||||
- pymdownx.mark
|
||||
- pymdownx.smartsymbols
|
||||
- pymdownx.snippets
|
||||
- pymdownx.superfences
|
||||
- attr_list
|
||||
- pymdownx.tabbed
|
||||
- pymdownx.superfences
|
||||
- pymdownx.tilde
|
||||
- pymdownx.superfences:
|
||||
custom_fences:
|
||||
- name: mermaid
|
||||
class: mermaid
|
||||
format: !!python/name:pymdownx.superfences.fence_code_format
|
||||
- pymdownx.magiclink
|
||||
- pymdownx.emoji:
|
||||
emoji_index: !!python/name:materialx.emoji.twemoji
|
||||
emoji_generator: !!python/name:materialx.emoji.to_svg
|
||||
|
||||
nav:
|
||||
- "Introduction":
|
||||
- index.md
|
||||
- "Frequently Asked Questions": intro/faq.md
|
||||
- "Project Strategy": intro/strategy.md
|
||||
- "Comparisons": intro/comparisons.md
|
||||
- "Inspirations": intro/inspirations.md
|
||||
- "Project Status": intro/bikemap.md
|
||||
- "Managed Hosting": intro/managed.md
|
||||
- "Get In Touch": intro/contact.md
|
||||
- "Frequently asked questions": intro/faq.md
|
||||
- "Project strategy": intro/strategy.md
|
||||
- "Project status": intro/bikemap.md
|
||||
- "Managed hosting": intro/managed.md
|
||||
- "Get in touch": intro/contact.md
|
||||
- "Credits": intro/credits.md
|
||||
- "Operators":
|
||||
- "Operators Guide":
|
||||
- operators/index.md
|
||||
- "New Operators Tutorial": operators/tutorial.md
|
||||
- "Operations Handbook": operators/handbook.md
|
||||
- "Maintainers":
|
||||
- "New operators tutorial": operators/tutorial.md
|
||||
- "Operations handbook": operators/handbook.md
|
||||
- "Maintainers Guide":
|
||||
- maintainers/index.md
|
||||
- "New Maintainers Tutorial": maintainers/tutorial.md
|
||||
- "Packaging Handbook": maintainers/handbook.md
|
||||
- "Organisers":
|
||||
- "New maintainers tutorial": maintainers/tutorial.md
|
||||
- "Packaging handbook": maintainers/handbook.md
|
||||
- "Organisers Guide":
|
||||
- organisers/index.md
|
||||
- "Organisers Handbook": organisers/handbook.md
|
||||
- "Organising handbook": organisers/handbook.md
|
||||
- "Funding applications":
|
||||
- organisers/funding-applications/index.md
|
||||
- organisers/funding-applications/culture-of-solidarity.md
|
||||
|
|
@ -87,25 +71,21 @@ nav:
|
|||
- "Proposals":
|
||||
- organisers/proposals/index.md
|
||||
- organisers/proposals/federation.md
|
||||
- "Recipes":
|
||||
- recipes/index.md
|
||||
- "Abra":
|
||||
- abra/index.md
|
||||
- "Install": abra/install.md
|
||||
- "Quick Start": abra/quickstart.md
|
||||
- "Quick start": abra/quickstart.md
|
||||
- "Upgrade": abra/upgrade.md
|
||||
- "Design": abra/design.md
|
||||
- "Recipes": abra/recipes.md
|
||||
- "Hack": abra/hack.md
|
||||
- "Troubleshoot": abra/trouble.md
|
||||
- "Cheat Sheet": abra/cheat-sheet.md
|
||||
- "Get Involved":
|
||||
- get-involved/index.md
|
||||
- "Support Us": get-involved/support.md
|
||||
- "Federation":
|
||||
- federation/index.md
|
||||
- "Bylaws": federation/bylaws.md
|
||||
- "Finance": federation/finance.md
|
||||
- "Membership": federation/membership.md
|
||||
- "Code of Co-operation": federation/code-of-coop.md
|
||||
- "FAQ": federation/faq.md
|
||||
- "Resolutions":
|
||||
- federation/resolutions/index.md
|
||||
- "Passed":
|
||||
|
|
@ -121,24 +101,17 @@ nav:
|
|||
- federation/resolutions/passed/010.md
|
||||
- federation/resolutions/passed/011.md
|
||||
- federation/resolutions/passed/012.md
|
||||
- federation/resolutions/passed/014.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":
|
||||
- federation/resolutions/in-progress/013.md
|
||||
- federation/resolutions/in-progress/022.md
|
||||
- "In progress":
|
||||
- federation/resolutions/in-progress/index.md
|
||||
- "Draft":
|
||||
- federation/resolutions/drafts/index.md
|
||||
- "Finance": federation/finance.md
|
||||
- "Membership": federation/membership.md
|
||||
- "Minutes":
|
||||
- federation/minutes/index.md
|
||||
- "Recently":
|
||||
- federation/minutes/2024-03-29.md
|
||||
- federation/minutes/2024-02-01.md
|
||||
- "Archive":
|
||||
- "2022":
|
||||
- federation/minutes/2022-03-03.md
|
||||
- federation/minutes/2023-05-03.md
|
||||
- "Digital Tools": federation/tools.md
|
||||
- "Digital tools": federation/tools.md
|
||||
- "Glossary":
|
||||
- glossary/index.md
|
||||
|
||||
|
|
|
|||
|
|
@ -1,15 +1,4 @@
|
|||
markdown~=3.2
|
||||
|
||||
mkdocs~=1.5.3
|
||||
mkdocs-material~=9.5.7
|
||||
mkdocs-material-extensions~=1.3.1
|
||||
mkdocs-awesome-pages-plugin==2.9.2
|
||||
pygments~=2.16
|
||||
pymdown-extensions~=10.2
|
||||
|
||||
# Requirements for plugins
|
||||
babel~=2.10
|
||||
colorama~=0.4
|
||||
paginate~=0.5
|
||||
regex>=2022.4
|
||||
requests~=2.26
|
||||
mkdocs-material-extensions==1.3
|
||||
mkdocs-material==9.4.10
|
||||
mkdocs==1.5.3
|
||||
|
|
|
|||
Loading…
Reference in New Issue