Compare commits
1
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
 fauno
|
3485290a90
|
+1
-2
@@ -1,3 +1,2 @@
|
||||
site/
|
||||
.venv
|
||||
*~
|
||||
.venv
|
||||
@@ -26,32 +26,6 @@ wget -q -O - https://install.abra.coopcloud.tech | bash
|
||||
curl https://install.abra.coopcloud.tech | bash
|
||||
```
|
||||
|
||||
### NixOS
|
||||
|
||||
The install example is based on the [using nix flakes wiki page](https://nixos.wiki/wiki/flakes#Using_nix_flakes_with_NixOS).
|
||||
|
||||
1. Add the flake to your inputs
|
||||
```nix
|
||||
inputs = {
|
||||
abra = {
|
||||
url = "git+https://git.coopcloud.tech/toolshed/abra.git";
|
||||
};
|
||||
};
|
||||
```
|
||||
2. Add abra package to system packages, replace _x86_64-linux_ with the value according to your system
|
||||
```nix
|
||||
{
|
||||
pkgs,
|
||||
abra,
|
||||
...
|
||||
}:
|
||||
{
|
||||
environment.systemPackages = with pkgs; [
|
||||
abra.packages.x86_64-linux.default
|
||||
];
|
||||
}
|
||||
```
|
||||
|
||||
## Release candidate
|
||||
|
||||
### Wget
|
||||
|
||||
+1
-1
@@ -45,7 +45,7 @@ use it! We could really use your input.
|
||||
|
||||
| Feature | Explanation |
|
||||
| ----------- | ----------- |
|
||||
| Multi-node | The vast majority of Co-op Cloud installs are single node. There is a lack of [CSI](https://github.com/olljanat/csi-plugins-for-docker-swarm?tab=readme-ov-file) support for coordinating storage across multiple hosts when using Swarm mode, which means we kind of throw out [a bunch](https://docs.docker.com/engine/swarm/#feature-highlights) of the features of Swarm mode. However, there is growing interest in multinode setups and a push to improve our understanding. [Here's what we know so far, and some hints on getting started.](/operators/multinode) |
|
||||
| Multi-node | It is possible but it doesn't seem like anyone in our community is really doing this? Please report in to `#coop-cloud-tech-future-brain:autonomic.zone` to discuss your usage if you are using multi-node swarm! We believe the majority of Co-op Cloud installs are single node. There is also a lack of [CSI](https://github.com/olljanat/csi-plugins-for-docker-swarm?tab=readme-ov-file) support for coordinating storage across multiple hosts when using Swarm mode. This means we kind of throw out [a bunch](https://docs.docker.com/engine/swarm/#feature-highlights) of the features of Swarm mode. |
|
||||
|
||||
## Limitations
|
||||
|
||||
|
||||
+37
-20
@@ -7,24 +7,27 @@ title: Finance
|
||||
|
||||
## Agreeing to spend money (Budgets)
|
||||
|
||||
The Federation agrees on Budget items as large decisions that must pass a resolution [reference](https://docs.coopcloud.tech/federation/resolutions/passed/004/). All paid work must be within a Budget. Each budget has an associated "Project" on OpenCollective. Current approved budgets are:
|
||||
|
||||
* [Abra Critical Fixes](https://opencollective.com/coop-cloud/projects/4-abra-critical-fixes) - see also [critical fixes budget resolution](https://docs.coopcloud.tech/federation/resolutions/passed/010/)
|
||||
* [Kite Flying](https://opencollective.com/coop-cloud/projects/13-kite-flying) - see also [kite flying budget resolution](https://docs.coopcloud.tech/federation/resolutions/passed/024/)
|
||||
* [Federation Radmin](https://opencollective.com/coop-cloud/projects/014-federation-radmin) - see also [radmin budget resolution](https://docs.coopcloud.tech/federation/resolutions/passed/029/)
|
||||
* [Website Development](https://opencollective.com/coop-cloud/projects/041-website-development) - see also [website development budget resolution](https://docs.coopcloud.tech/federation/resolutions/passed/041/)
|
||||
|
||||
## Sending and receiving money
|
||||
|
||||
Money is managed through The Co-op Cloud Open Collective account. Platform 6 is [the fiscal host](https://docs.opencollective.com/help/fiscal-hosts/fiscal-hosts) for the Co-op Cloud Open Collective account.
|
||||
It's slightly complicated, because money is complicated, but here's how it works. There are two moving parts:
|
||||
|
||||
Transactions are submitted through Open Collective, approved by the Federation and paid out by our fiscal host.
|
||||
* The Co-op Cloud Open Collective
|
||||
* The Autonomic Wise account
|
||||
|
||||
Autonomic is [the fiscal host](https://docs.opencollective.com/help/fiscal-hosts/fiscal-hosts) for the Co-op Cloud Open Collective (OC).
|
||||
|
||||
OC helps us make all expenses and transfers transparent to the Federation. No actual money is handled via the OC interface. All payments are done via the Autonomic [Wise](https://wise.com) account. The total sum of the available funds shows on the OC page is the actual amount that is held in the Autonomic Wise account.
|
||||
|
||||
Autonomic Co-op members commit to support the federation by doing the financial adminstration work for the time being. Autonomic is publicy registered, has a bank account, files taxes etc. All financial comings/goings are kept on the books internally at Autonomic. This could be further mutualised or another collective could pick this up in the future.
|
||||
|
||||
Autonomic does not eat the transfer costs from the Wise account when paying out expense for members. That is charged to the Federation common fund.
|
||||
|
||||
### How to get paid via Open Collective
|
||||
|
||||
* [Create an account on Open Collective](https://opencollective.com/create-account)
|
||||
* Go to the [Co-op Cloud Open Collective](https://opencollective.com/coop-cloud/projects)
|
||||
* Find the appropriate Project
|
||||
* Go to the [Co-op Cloud Open Collective](https://opencollective.com/coop-cloud)
|
||||
* Click [SUBMIT EXPENSE](https://opencollective.com/coop-cloud/expenses/new)
|
||||
|
||||
**Important** Please include bank details in your expense so that we can make a bank transfer. We do not currently support payments via Paypal and other platforms.
|
||||
@@ -33,22 +36,36 @@ If you urgently need the money, please let us know on the Co-op Cloud Finance ch
|
||||
|
||||
Finally, please let us know what your username/email is for your Open Collective account so we can add you to the team. This helps us build up the view of our community from the perspective of our Open Collective page.
|
||||
|
||||
#### Invoice Requirements
|
||||
### How to pay someone via Wise
|
||||
|
||||
Invoices are required to be submitted with your expense. Open Collective can generate an invoice for you if you select this option. Please include the hours worked and any work tickets if applicable in the line items of your invoice.
|
||||
> **Note**: only Autonomic Co-op members can do this
|
||||
|
||||
#### What transfer type do we use for payments?
|
||||
* First off, be wary of two things: 1) the currency conversion 2) the transaction fees of Wise. For 1) we have the complicating factor that the OC represents the common fund in GBP but our internal Wise jar is EUR. Then you're getting deeper into trouble if someone wants to get paid in e.g. USD.
|
||||
|
||||
Platform 6 dispenses other payments as bank transfers via [Wise](https://wise.com), please allow up to a week for pay out.
|
||||
* In order to cover the transaction fee, you need to fake do the transfer to see what you'll be charged and then add that to what you withdraw from the jar. This is because Autonomic does not eat the cost of the transfer from Wise, that is charged to the Federation.
|
||||
|
||||
### Contributing to Co-op Cloud
|
||||
* First step is to withdraw cash from the Co-op Cloud jar. It will automatically be transferred to the general EUR jar because the Co-op Cloud jar is also in EUR.
|
||||
|
||||
[Contribute to Co-op Cloud](https://opencollective.com/coop-cloud#category-CONTRIBUTE)
|
||||
* To transfer to USD, you don't have to use USD, you can use GBP/EUR directly. It's easier to make the direct payment from the jar you transferred it to. This is purely because it is easier to follow it in the accounting bookkeeping later on.
|
||||
|
||||
* When making the payment, do the following:
|
||||
* Select international transfer, choose your requird `$currency`
|
||||
* Put correct amount in "recipient gets exactly" to get Wise to figure out the correct amount
|
||||
* Open the invoice in Open Collective and look for the expense number, e.g. "Expense #132373" and put this in the reference number of the payment
|
||||
* Note how long the transfer will take (Wise should tell you)
|
||||
|
||||
* Mark the expense as paid in Open Collective. Use the "manual" method.
|
||||
|
||||
* Let the member know the payment is on the way and how long it will take (if you have time).
|
||||
|
||||
#### FAQ
|
||||
|
||||
##### What transfer type do we use for USD?
|
||||
|
||||
`ACH`. If you see `Abartn`, that is the `ACH routing number`.
|
||||
|
||||
### Tiers on Open Collective
|
||||
|
||||
* Infrastructure Sustainability: Folks who are making use of Co-op Cloud digital infrastructure (e.g. [git.coopcloud.tech](https://git.coopcloud.tech)) and want to help out with maintenance costs. All recurring donations are spent directly on running costs and system adminstration labour. Thanks for considering!
|
||||
* Federation Membership: Dues paid by members of the Co-op Cloud Federation. Please see [Resolution 002: Membership/Dues 2023-03-22](https://docs.coopcloud.tech/federation/resolutions/passed/002/) for more information. There may be further decisions made around dues, please refer to the Federation documentation on [docs.coopcloud.tech/federation](https://docs.coopcloud.tech/federation).
|
||||
* One-time Contribution: Just stopping in and want to support? Thanks! [Come say hi!](https://docs.coopcloud.tech/intro/contact/)
|
||||
|
||||
When scheduling membership dues, please make them from the OpenCollective account associated with your co-op/collective/project. If you do not have an account for your project and are paying with a personal account, please let us know in the Co-op Cloud Finance channel.
|
||||
|
||||
*Please note that Open Collective charges recurring contributions on the 1st of the month*
|
||||
* Federation Membership: Dues paid by members of the Co-op Cloud Federation. Please see "Resolution 002: Membership/Dues 2023-03-22" for more information. There may be further decisions made around dues, please refer to the Federation documentation on [docs.coopcloud.tech/federation](https://docs.coopcloud.tech/federation).
|
||||
|
||||
@@ -4,7 +4,7 @@ title: Ford foundation
|
||||
|
||||
# Ford foundation
|
||||
|
||||
> Status: **rejected**
|
||||
> Status: **pending**
|
||||
|
||||
* [Previous material](https://notes.bonfire.cafe/nlnet-bonfire-coopcloud-hosting)
|
||||
* [Application](https://fordfoundation.forms.fm/2023-digital-infrastructure-insights-fund-rfp/forms/9724)
|
||||
|
||||
@@ -44,7 +44,7 @@ Beyond our grant funding, and support in terms of time and technical resources f
|
||||
|
||||
### 4. Compare your own project with existing or historical efforts. (eg what is new, more thorough, or otherwise different)
|
||||
|
||||
We maintain an ongoing analysis of Co-op Cloud compared to other options in the [Co-op Cloud documentation](https://docs.coopcloud.tech/intro/faq/#what-about-alternative).
|
||||
We maintain an ongoing analysis of Co-op Cloud compared to other options in the [Co-op Cloud documentation](https://docs.coopcloud.tech/faq/#what-about-alternative).
|
||||
|
||||
Overall, Co-op Cloud has architectural and organisational advantages over existing libre options like Yunohost and [Caprover](https://caprover.com), and our open governance and libre licencing make Co-op Cloud a better long-term, pro-social choice than proprietary platforms like [Cloudron](https://cloudron.io). Versus options like [Ansible](https://ansible.com) or [Kubernetes](https://kubernetes.io), Co-op Cloud aims to be usable by less-technical users, to reduce their reliance on third parties to manage their data and tools.
|
||||
|
||||
|
||||
@@ -17,3 +17,23 @@ We try to gather as many "case studies" as possible, stories & concrete examples
|
||||
## Monthly updates
|
||||
|
||||
We have decided we'll try to do monthly progress updates. These will be published on the Co-op Cloud blog. It's a pretty loose format and we're basically just copy/pasta'ing things to a public pad during the month: ["This month in Co-op Cloud"](https://pad.autonomic.zone/YHKn4vHORmS6wjN1t2zi5A?both). Feel free to add your items to the monthly agenda and they will be included! All the previous posts can be seen [here](https://coopcloud.tech/blog/).
|
||||
|
||||
## Kite Flying Hours
|
||||
|
||||
The "Kite Flying Hour" is a weekly public moment where anyone can "drop by" into a Jitsi call and ask/do/propose whatever and meet some people who are currently working on the project. We haven't worked it all out but our process for now is the following.
|
||||
|
||||
Someone from Autonomic will volunteer to be present and talk about the project for an hour weekly from 15:00 CEST - 16:00 CEST. We announce the hour via our socials: A [pinned toot](https://social.coop/web/statuses/106528094828958420) on [`@coopcloud@social.coop`](https://social.coop/@coopcloud) and a post to the `#coopcloud:autonomic.zone` room.
|
||||
|
||||
Here is some invitation boilerplate which you can use:
|
||||
|
||||
> Hey folks, you're all warmly invited to the Co-op Cloud Kite Flying Hour at `$X_TIME` `$Y_TZ` `$Z_DATE` over in [meet.jit.si/CoopCloudKiteFlyingHour](https://meet.jit.si/CoopCloudKiteFlyingHour)!
|
||||
>
|
||||
> Inspired by exquisite childhood memories of [flying kites, eating popsicles and looking at clouds](https://norwichhistory.org/norwich-a-z-j-is-for-jigsaw/), it's an open hour to come hang out online and discuss/co-work/lurk/etc. around the [Co-op Cloud](https://coopcloud.tech/) project.
|
||||
>
|
||||
> There are no "stupid questions"! It's a space to inquire, be curious and have a good time and get to know each other.
|
||||
>
|
||||
> We take notes and doodle on [this collaboratively editable pad](https://pad.autonomic.zone/VtyrLUl9RWaJGgEDrncQUw?view). If you don't have time to attend, feel free to drop your questions and some contact details also, so we can get in touch. This is only the first Kite Flying Hour in a recurring series of Kite Flying Hours.
|
||||
>
|
||||
> Hope to see you there! ☁️ 🌞 🖥️
|
||||
|
||||
To work around Hedgedoc length limits, [we keep past content from the kite-flying pad here](./kite-flying-pad-archive).
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -6,25 +6,19 @@ title: Membership
|
||||
|
||||
| Name | Dues Paid | Notes | Contact |
|
||||
| --------- | --------- | -------- |-------- |
|
||||
| [Agaric](https://agaric.coop/) | ⭕ | - | `@wolcen:matrix.org` |
|
||||
| [Autonomic](https://autonomic.zone) | ⭕ | - | `@3wc`, `@cas`, `@knoflook`, `@travvy`, `@aadil` |
|
||||
| [Bonfire](https://bonfirenetworks.org) | ✅ | - | `@mayel:matrix.org` + Ivan (`@cambriale:matrix.org`) |
|
||||
| [Bunk Computer Cooperative](https://bunk.computer) | ✅ | - | `@maren@bunk.computer` + `@sorrel@bunk.computer` |
|
||||
| [CoQuest - IT Coop Stuttgart](https://coquest.coop/en) | ✅ | voting rights waived | `hallo@coquest.coop` |
|
||||
| [Democratic Tech Fund](https://democratictech.fund/) | ✅ | - | `@wtebbens` + `@mikemh` |
|
||||
| [Doop.coop](https://doop.coop) | ⭕ | - | `@yusf:gottsnack.net` |
|
||||
| [eCommons](https://ecommons.nl) | ✅ | - | `@dannygroenewegen:matrix.org` |
|
||||
| [EOTL](https://eotl.supply) | ✅ | - | `@basebuilder:pub.solar` |
|
||||
| [Karrot](https://karrot.world) | ⭕ | - | `@nicksellen:matrix.org` |
|
||||
| [Klasse & Methode](https://klasse-methode.it) | Waiver | - | `@p4u1_f4u1:matrix.org` |
|
||||
| [Local IT](https://local-it.org/) | ✅ | - | `@moritz:matrix.local-it.org` + `@simon_sth:matrix.org`|
|
||||
| [Merri-bek tech](https://www.merri-bek.tech/) | ✅ | - | `coop-cloud-delegate@merri-bek.tech`|
|
||||
| [MIR](https://mirnet.org/) | ✅ | - | `@sixsmith:matrix.org` |
|
||||
| [Red Abya Yala](https://abyayala.sutty.nl/) | ⭕ | - | `@fauno:sutty.nl` |
|
||||
| [RTM](https://resisttechmonopolies.online) | ✅ | - | `@ammaratef45:matrix.org` + `@linnealovespie:matrix.org`|
|
||||
| [ruangrupa](https://ruangrupa.id) | ⭕ | - | Henry `@babystepper:matrix.org` |
|
||||
| [UTAW](https://utaw.tech) | ⭕ | - | `@javielico:matrix.org` |
|
||||
| Amras | Waiver | - | `coop-cloud@joinmeonmy.quest` |
|
||||
| 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://klasse-methode.it) | - | - | `@p4u1_f4u1:matrix.org` |
|
||||
| [Local IT](https://local-it.org/) | - | - | `@moritz:matrix.local-it.org` + `@simon_sth:matrix.org`|
|
||||
| Mirsal ™ | - | - | `@mirsal:1312.media` |
|
||||
| [UTAW](https://utaw.tech) | - | - | `@javielico:matrix.org` |
|
||||
| `@decentral1se` | Waiver | - | `@decentral1se` |
|
||||
| Mirsal ™ | ✅ | - | `@mirsal:1312.media` |
|
||||
|
||||
| [ruangrupa](https://ruangrupa.id) | - | - | Henry `@babystepper:matrix.org` |
|
||||
| [RTM](https://resisttechmonopolies.online) | ✅ | - | `@ammaratef45:matrix.org` + `@linnealovespie:matrix.org`|
|
||||
| [MIR](https://mirnet.org/) | ✅ | - | `@sixsmith:matrix.org` |
|
||||
| [Red Abya Yala](https://abyayala.sutty.nl/) | - | - | `@fauno:sutty.nl` |
|
||||
| [Merri-bek tech](https://www.merri-bek.tech/) | - | - | `coop-cloud-delegate@merri-bek.tech`|
|
||||
|
||||
@@ -1,131 +0,0 @@
|
||||
# Community Call "Cooperative Clouds with Kollicloud"
|
||||
|
||||
## Date: 2026-05-21 12:00 UTC
|
||||
|
||||
## Attendance
|
||||
Hosting: Simon, Wouter Tebbens (Free Knowledge Institute)
|
||||
|
||||
Minutes: amras
|
||||
|
||||
Present: Carla, d1 (coop cloud), Danny (eCommons), Graham (innovation.coop), Jeff, iexos, KawaiiPunk (Autonomic, Co-op Cloud, Tech Care Co-op), mikemh, Moritz, Simon, steven
|
||||
|
||||
## Resources
|
||||
- [Video recording, and a report by Wouter Tebbens](https://freeknowledge.eu/cooperative-clouds-in-practice-kollicloud-shows-how-affordable-sovereign-infra-is-already-here)
|
||||
- [Announcement fediverse toot](https://social.coop/@fkinstitute/116566545446152790)
|
||||
- [Post-show fediverse toot](https://social.coop/@fkinstitute/116618445246768053)
|
||||
|
||||
## Minutes
|
||||
|
||||
### Admin
|
||||
Only the presentation will be recorded. Recording switched off for Q&A and conversation.
|
||||
|
||||
### Democratic Tech Fund
|
||||
[Website](https://democratictech.fund/)
|
||||
- w: Democratic Tech means: the community impacted by tech takes responsibility for its own tech. Beyond OSS, OSS+governance+economics.
|
||||
- Tech monopolies take political power over a lot of people in our society; impacted+dependant. This is why we work on digital autonomy. Not just technical, but social capacity, appropriate technologies + economics & governance models. This can't be done alone, need to do in a network fashion.
|
||||
- 3 domains: collaborative workspaces, decentralized social media, tools for cooperative organizing. We're collectively studying what exists, what works, what people need and how we respond to those needs.
|
||||
- Democratic Tech Fund works on discovery of the tech and collective fund raising, vouch funding, public+private match funding. Early stage, building one step at a time. Tough to get started, but in good company.
|
||||
- Thanks to ecommons we have a doc server on outline, thank you to d1 for help with running that on a coop cloud recipe.
|
||||
- We're asking for donations for DTF.
|
||||
|
||||
### Kollicloud
|
||||
[Website](https://kollicloud.de/)
|
||||
|
||||
Introducing: Simon, Carla, Moritz from [Local-IT](https://local-it.org)
|
||||
|
||||
- Q(w): what is the relationship of Kollicloud to the coop cloud federation
|
||||
|
||||
> Simon presenting & talking
|
||||
|
||||
- Local-IT is a small non-profit.(35 members, 6 part time). Focused on education and networking events to move orgs away from big tech. Digital Sovereingty and free software for society.
|
||||
- Building on Co-Op cloud's amazing infrastructure:
|
||||
- configuration commons + abra tool
|
||||
- not going into details, want to focus on demo w/ alakazam
|
||||
- The deployment process with abra is fairly manual, not a lot is preconfigured.
|
||||
- When I discovered this, focus was less on the federation aspect but the tech aspect. After talks at CCC etc, focused more on how we want to govern/collaborate at Local-IT and DTF. This makes Co-op Cloud distinct form similar projects.
|
||||
- KolliCloud is a ready-to-use integrated hosting toolkit for clubs, NGOs and collectives in Germany (no international right now). Bundle of 15 apps + SSO, backups, monitoring so it can be deployed quickly.
|
||||
|
||||
#### 3 hosting flavors
|
||||
- self-hosting with alakazam. We have guides in german on the kollicloud website. Hope to translate to English soon.
|
||||
- Managed hosting: we offer support.
|
||||
- Collective hosting approach, intermediate between self and managed hosting. Share not only the integrated config but also the infra. Multiple admins on the same infra, cogoverning multiple instances. More on this later.
|
||||
|
||||
#### alakazam
|
||||
- core of kollicloud; meta-config layer.
|
||||
- Managing 230 apps by hand is not an option (if we wanted to do everything with abra)
|
||||
- alakazam's commands help us orchestrate instances on multiple VMs, multiple docker swarm instances per VM.
|
||||
- hierarchical yaml configs -> generate env files, with different override for testing/production stages.
|
||||
- one secret can be shared between multiple instances
|
||||
- batch updates, each coop cloud recipe is checked for upgrades, verify nothing broke in testing, and if nothing breaks push to prod. A month ago we did this with our 230 apps.
|
||||
|
||||
#### Configuration hierarchy:
|
||||
- defaults set, with default app settings grouped by domain.
|
||||
- We have defaults for subdomains of our apps
|
||||
- ovverrides as you move deeper into the hierarchy; the closer the config is to the instance, the higher prio.
|
||||
- a lot of configs depend on app combinations, e.g. authentik (SSO+ident) with nextcloud - alakzam knows what to enable in the authentik and nextcloud env files to make them work together.
|
||||
- We want to move these combinations out of global, to per-recipe.
|
||||
|
||||
#### Demo, deploying an instance:
|
||||
- File structure:
|
||||
- usually we have one file that specifies backup+monitoring+traffic, named after the vm.
|
||||
- we then have 1 file per instance on that vm, which specifies apps to deploy. Usually, it's enough to name the app, don't need to specify custom configs. Ongoing work: feature packs.
|
||||
- alakazam command, layered:
|
||||
`alakazam group_dir/server_dir/instance.yml <command>`
|
||||
> running config command
|
||||
> running secret command
|
||||
|
||||
- I commented out the part of the secrets code which prints secrets, for privacy
|
||||
- w: time for murphy's law
|
||||
- after waiting a minute, error printed in `alakazam.py` (known issue), just rerun secrets.
|
||||
> running deploy command
|
||||
- deploy dumps all the abra commands in stdout
|
||||
- w: a lot of magic happening :)
|
||||
> S continues talking while we wait for deployment
|
||||
- half a year ago, had a discussion in the coop cloud channel: "the future is not self-hosted". For most people, sh is too difficult, it's only an option for a tech niche. We need a way for everyone to use the tech, not just those who can provide their own software for themselves. Co-op cloud solves a lot of this, because shared recipes are convenient. One of the first things I do when I want to try out new software is I search for a coop cloud recipe; makes it very easy. The next step at KolliCloud is to integrate it with backups, monitoring, defaults.
|
||||
|
||||
- When I was using abra, I procrastinated on SSO, and every time I tried it was problematic. KolliCloud is a lot more convenient, because you don't have to think where what secret goes etc.
|
||||
- w: demo deployment is up, just opened it https://login.dtf.dev.kolli.cloud/
|
||||
> returning to demo
|
||||
- s: alakazam deploy won't try to deploy what's already deployed.
|
||||
- w: not working on my side
|
||||
- s: right, we need to run a few more commands
|
||||
- w: we're actually short on time, maybe we can move to questions?
|
||||
|
||||
### Questions
|
||||
- Q(w): what orgs are using kolli cloud?
|
||||
- [Lambda Bundesverband](https://lambda-online.de/) - germany's largest queer youth org. We host their IT tools, next cloud and stuff. We also host a queer support tool, which allows queer people to get in contact with them. This is integrated in the backend with Zammad via Matrix/Element and Signal-Bridge. So people who respond to questions are replying in matrix chat.
|
||||
- Valentin provides them with computers+preinstalled software, tightly integrated with kollicloud, we're providing hosting.
|
||||
- Q(w): how large are these groups?
|
||||
- s: 100+ users, not sure how many active at once. But this is more than we aim for. We usually aim for up to 100.
|
||||
- Moritz: we also have a voluteer fire brigade.
|
||||
- Q(w): why only associations and clubs? This tooling could be useful in other types of orgs.
|
||||
- M: Local-IT is an association; easier to provide tools for usecases similar to our own. We also have funding that supports associations in Germany, that's why our main focus is on associations.
|
||||
- M: for commercial orgs, we have to check/vet if we can stand behind it. So we're open to providing for commercial orgs, but only aligned with our values. There are a lot of associations in Germany.
|
||||
- w: Thank you Simon for your presentation! Switching off recording now.
|
||||
- Q(d1): Love the "where actual work sits" slide - progression from coop cloud to kollicloud. I want to hear about the economic side. We know the economics of hosting are shit; we're approaching the most underfunded parts of society and asking them to pay us for something they get 'for free'. How can we make this sustainable in the long term? Interested in the mutualization of labor, shared admin layer. Does that come in to the economics of this?
|
||||
- S: Mostly funding from various sources; calculated we need like 500 instances to pay 2-3 part-time jobs.
|
||||
- S: on shared admin, we need to work on this more. The idea is set - a couple people have admin rights+ssh keys on a server with e.g. 7 VMs. Admins can then assist each other, like "I'm going on holiday; please help if my community's infra breaks". A lot of people are engaged in communities; if each has a cloud like ours then a federated cloud might not be so far away.
|
||||
- d1: seems that our ideas are leading to this point on the horizon.
|
||||
- Q(Graham): Interested in that economics question, but also interested in how robust the stack is. It's not a mainstream tech stack, for all of it. How might this apply to small businesses, small cooperatives? It needs to be rock solid if someone runs a business on this.
|
||||
- S: Main reasons we're not targetting small businesses is our own availability. If something goes down, we can't address it in minutes/hours. This expectation is less for associations.
|
||||
- S: I think this stack is quite stable. Most problems arise when the FOSS we use becomes unavailable because of premiumizing. E.g. software makes SSO premium and we have to ask if we have backup options or if we need to spend money on licenses.
|
||||
- M: the stack is quite stable; biggest problems arise from software. Some of what we deploy is maintained a single person in their spare time, so there are bugs/instabilities in the software itself.
|
||||
- M: updates can break a lot of stuff, which is why we test for two weeks on our own servers first before we deploy for production for all the associations. Testing updates is the biggest factor in stability. But there are still bugs we can do nothing about. When we have important security patches, we need to deploy updates even with bugs. You probably know these problems if you self-host open source software.
|
||||
- w: Proposal: could you keep this demo deployed so everyone can have a look?
|
||||
- Q(mikemh): across all the accounts you operate; are there patterns emerging with the apps or configs people are using? Can you have an expectation of what people will need?
|
||||
- S, M: that's what we're doing with the default configs. We expect most users want to deploy with these configs. We learn from our users and put that into our defaults.
|
||||
- Q(w): what if we want to add a new app, that's not in kollicloud? Is that a lot of work? How do you go about that in contact with the co-cop cloud federation?
|
||||
- S: I have a slide for this!
|
||||
- S: Not a lot of work. But you need a well-maintained CC recipe (needs to run).
|
||||
- S: If we need it to integrate we add it to combine.yml.
|
||||
- S: If we want to specify defaults we put them in the kolli-config repo, based on the diff of the config compared to CC's default.
|
||||
|
||||
> Demo finishes deploying, it works!
|
||||
|
||||
- w: beautiful dashboard with powerdul applications. You're offering a powerful methodology for collaboration. Really promising.
|
||||
-S: thank you! Wanted to show more, but ran out of time.
|
||||
- Q(w): how long will you keep this demo site open?
|
||||
- M: for the next few hours.
|
||||
- M: we have other demo instances; you can ask us for credentials :)
|
||||
- w: please post those in the matrix channels!
|
||||
- w: another world is possible; you are doing it!
|
||||
@@ -16,9 +16,24 @@ Welcome to the organisers guide! Organisers are folks who focus on the social wo
|
||||
|
||||
If you like what you see, but are not sure how to best contribute :speech_left:
|
||||
|
||||
[Get In Touch](/intro/contact/){ .md-button .md-button--primary }
|
||||
[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:
|
||||
|
||||
## Kite Flying Hours
|
||||
|
||||
The "Kite Flying Hour" is a weekly public moment where anyone can "drop by" into a Jitsi call and ask/do/propose whatever and meet some people who are currently working on the project. We haven't worked it all out but our process for now is the following.
|
||||
|
||||
Someone from Autonomic will volunteer to be present and talk about the project for an hour weekly, alternating between 12 and 19 UTC each week. We announce the hour via our socials: A [pinned toot](https://social.coop/@coopcloud/113555815289767778) on [`@coopcloud@social.coop`](https://social.coop/@coopcloud) and a post to the `#coopcloud:autonomic.zone` room.
|
||||
|
||||
Here is some invitation boilerplate which you can use:
|
||||
|
||||
> Hey folks, you're all warmly invited to the Co-op Cloud Kite Flying Hour at `$X_TIME` `$Y_TZ` `$Z_DATE` over in [vs.autistici.org/CoopCloudKiteFlyingHour](https://vs.autistici.org/CoopCloudKiteFlyingHour)!
|
||||
>
|
||||
> Inspired by exquisite childhood memories of [flying kites, eating popsicles and looking at clouds](https://norwichhistory.org/norwich-a-z-j-is-for-jigsaw/), it's an open hour to come hang out online and discuss/co-work/lurk/etc. around the [Co-op Cloud](https://coopcloud.tech/) project.
|
||||
>
|
||||
> There are no "stupid questions"! It's a space to inquire, be curious and have a good time and get to know each other.
|
||||
>
|
||||
> We take notes and doodle on [this collaboratively editable pad](https://pad.autonomic.zone/VtyrLUl9RWaJGgEDrncQUw). If you don't have time to attend, feel free to drop your questions and some contact details also, so we can get in touch. This is only the first Kite Flying Hour in a recurring series of Kite Flying Hours.
|
||||
|
||||
@@ -1,16 +0,0 @@
|
||||
# resolution 045: automatic membership pause
|
||||
|
||||
topic: automatic membership pause
|
||||
date: 2026-09-03
|
||||
deadline: 2026-09-17
|
||||
size: large
|
||||
|
||||
## Problem
|
||||
|
||||
According to [Resolution 001](https://docs.coopcloud.tech/federation/resolutions/passed/001/) a Large decision requires "more than 50% of total number of federation members 👍 votes". This works well as long as enough members are active. But as with every organisation it is normal that that some members become inactive at some point.
|
||||
|
||||
## Resolution
|
||||
|
||||
If a member does not give a vote for the last 3 resolutions its membership will be paused automatically. Paused memberships are not counted in the total 👍 votes required for a large resolution. The membership gets active again once they give their next vote. If a member sees that another member is inactive they can update their status on the website. If a member status was inactive for one year its membership is automatically canceled.
|
||||
|
||||
Members that have their voting rights waived are excluded from the automatic membership pause.
|
||||
@@ -1,35 +0,0 @@
|
||||
---
|
||||
title: "Resolution 039: Amras Ciaszczyk to join the federation as a member"
|
||||
---
|
||||
|
||||
- Topic: Resolution 039: Amras Ciaszczyk to join the federation as a member
|
||||
- Date: 12-05-2026
|
||||
- Deadline: 26-05-2026
|
||||
- Size: large
|
||||
|
||||
## Summary
|
||||
|
||||
Amras maintains one of our recipes and facilitates half of kite-flying sessions, their membership will allow participation in the decision making and mutual accountability.
|
||||
|
||||
## Details
|
||||
|
||||
In Amras' own words:
|
||||
|
||||
|
||||
> I started using abra a few years ago, when I needed a stack to
|
||||
host services for my polycule. Last year, I talked with d1 at CCC and
|
||||
became more involved in the community. Since then, I've taken on
|
||||
facilitating the 12 UTC Kite Flying sessions and assigned myself as the
|
||||
mumble recipe's maintainer.
|
||||
|
||||
> I'm also in the process of starting a small hosting, advice, and
|
||||
services provider under community-first and sustainability principles.
|
||||
|
||||
> I'm already active in the Co-op Cloud community and on the periphery of
|
||||
a few organizing discussions. I'd like to formalize my role and become a
|
||||
bona fide member. My main motivation is to submit and vote on proposals
|
||||
related to the tasks I'm performing.
|
||||
|
||||
@ammaratef45:matrix.org from [RTM](https://resisttechmonopolies.online/) is happy to vouch!
|
||||
|
||||
To talk to Amras they are @amras0000:matrix.org and can be emailed at r039@joinmeonmy.quest
|
||||
@@ -1,20 +0,0 @@
|
||||
# resolution 040: a collective member provides loomio instead of dues
|
||||
|
||||
topic: a collective member provides loomio instead of dues
|
||||
date: 2026-05-28
|
||||
deadline: 2026-06-04
|
||||
size: large
|
||||
|
||||
## problem
|
||||
using matrix emojis for voting has several issues:
|
||||
- it's hard to retain records of voting
|
||||
- easy double counting since collectives can have multiple delegates
|
||||
- matrix clients vary in how bad they are with seeing reactions
|
||||
|
||||
## resolution
|
||||
[loomio](https://www.loomio.com/) has been suggested and regarded as a good alternative for voting. We have a [recipe](https://git.coopcloud.tech/coop-cloud/loomio/) for it and it's maintained by members of [rtm](https://resisttechmonopolies.online/).
|
||||
|
||||
|
||||
I propose a) we migrate to using loomio for voting without a change to voting rules.
|
||||
|
||||
in the spirit of mutual aid, self-reliance, and cooperativism, I also propose b) we hire a federation member to self-host and manage the loomio instance for us with the option to waive their dues in exchange.
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
title: "Resolution 041: Budget 017: Website development"
|
||||
---
|
||||
|
||||
- Topic: Budget 017: Website development
|
||||
- Date: 2026-06-02
|
||||
- Deadline: 2026-06-15
|
||||
- Size: Large
|
||||
|
||||
## Description
|
||||
|
||||
Budget 017 proposes to compensate [Sutty](https://sutty.coop.ar/en/) for
|
||||
the new Co-op Cloud website development, according to the user
|
||||
experience research process from [Resolution
|
||||
035](/federation/resolutions/passed/035/) for the total amount of 3500
|
||||
EUR, paid in 3 installments.
|
||||
|
||||
The budget will cover the website development of the [prototype that was
|
||||
the result of the UX
|
||||
research](https://nube.yanapak.abyaya.la/s/eM8AMbACNbEm3qY).
|
||||
|
||||
Please see [the full proposal
|
||||
text](https://vvvvvvaria.org/~decentral1se/cc/CoopCloud-2025WebsiteProposal-Sutty.pdf)
|
||||
for all details.
|
||||
|
||||
As per previous communications, there is around 4000 to 5000 EUR
|
||||
destined to website development, out of which we're budgeting 3500 EUR
|
||||
for website development. The reminder of the budget is reserved for new
|
||||
features or maintenance (ie. recipes, SSO, etc.)
|
||||
|
||||
## Budget
|
||||
|
||||
The budget total is:
|
||||
|
||||
* 1250 EUR at start.
|
||||
* 1250 EUR after the first month.
|
||||
* 1000 EUR at final delivery.
|
||||
* **3500 EUR total.**
|
||||
@@ -1,22 +0,0 @@
|
||||
---
|
||||
title: "Resolution 042: Bunk Computer Cooperative to join the federation as a member"
|
||||
---
|
||||
|
||||
- Topic: Resolution 042: Bunk Computer Cooperative to join the federation as a member
|
||||
- Date: 2026-06-18
|
||||
- Deadline: 2026-07-03
|
||||
- Size: large
|
||||
|
||||
## Summary
|
||||
|
||||
Bunk Computer Cooperative uses abra and coop cloud to manage infrastructure for their clients. Bunk has also contributed to the Keycloak and Nextcloud recipes, and one Bunk member is doing financial administration for the federation.
|
||||
|
||||
## Details
|
||||
|
||||
In Maren's words:
|
||||
|
||||
> Bunk has been using coop cloud since we started our co-op. Once we learned about co-op cloud, it was apparent to all three of our members that co-op cloud's structure was super smart. Tooling maintained by a federation of the co-ops that use it is set up for long term sustainability, and we want to contribute to that sustainability just as we benefit from it. We hope to upstream our work on co-op cloud whenever possible, and have already done some of that with Nextcloud and Keycloak.
|
||||
|
||||
@ammaratef45:matrix.org from [RTM](https://resisttechmonopolies.online/) happy offered to vouch.
|
||||
|
||||
Bunk's representative to the federation will be Maren. She can be reached at `@maren:matrix.bunk.computer` on Matrix or `maren@bunk.computer` on email.
|
||||
@@ -1,23 +0,0 @@
|
||||
---
|
||||
title: "Resolution 043: eCommons to join the federation as a member"
|
||||
---
|
||||
|
||||
- Topic: Resolution 043: eCommons to join the federation as a member
|
||||
- Date: 2026-08-04
|
||||
- Deadline: 2026-08-18
|
||||
- Size: large
|
||||
|
||||
## Summary
|
||||
|
||||
[eCommons](https://ecommons.space/en) runs multiple Co-op Cloud recipes for several commons-based organisations in the Netherlands, uses Alakazam to manage their instances, and has contributed to various recipes.
|
||||
|
||||
## Details
|
||||
|
||||
At eCommons we build and operate shared digital infrastructure for our commons-based member organisations in the Netherlands: cooperative housing groups, food co-ops, and similar communities that want to keep their data, collaboration, and tools in their own hands. We use Co-op Cloud to run and manage these instances across our members, and use Alakazam to operate our growing set of apps.
|
||||
|
||||
Along the way we've contributed to several recipes we depend on. Co-op Cloud's federated model, tooling maintained collectively by the co-ops that use it, matches how we think infrastructure should be built and sustained. And we'd like to formalize our participation in the federation.
|
||||
|
||||
@fauno:sutty.nl from Red Abya Yala is happy to vouch for us.
|
||||
|
||||
eCommons' representative to the federation will be Danny. He can be reached at
|
||||
`@dannygroenewegen:matrix.org` on Matrix or `danny@ecommons.nl` by email.
|
||||
@@ -1,26 +0,0 @@
|
||||
---
|
||||
title: "Resolution 044: CoQuest to join the federation as a member"
|
||||
---
|
||||
|
||||
- Topic: Resolution 044: CoQuest to join the federation as a member
|
||||
- Date: 2026-08-19
|
||||
- Deadline: 2026-09-02
|
||||
- Size: large
|
||||
|
||||
## Summary
|
||||
|
||||
*CoQuest - IT Coop Stuttgart* offers hosting with co-op cloud for paid customers from the non-profit and coop sector. It acts as co-maintainer for several recipes and does abra development.
|
||||
|
||||
## Details
|
||||
|
||||
CoQuest already hosts services for several customers and plans to extend their hosting services in the future:
|
||||
|
||||
> We welcome clients and partners who share our values and work with us towards a more just, solidary, and sustainable world. We are especially keen to cooperate with worker-owned enterprises, cooperatives, non-profit associations, and initiatives of the community supported economy, as well as works councils and trade unions. Together we want to realize projects in culture, education, social welfare, and ecology.
|
||||
|
||||
More information at [coquest.coop](https://coquest.coop)
|
||||
|
||||
Some of CoQuest's members are also active at Klasse & Methode and therefore Klasse & Methode vouches for CoQuest.
|
||||
CoQuest will waive it's voting rights in the federation.
|
||||
|
||||
CoQuest's representative to the federation will be p4u1. He can be reached at
|
||||
`@p4u1_f4u1:matrix.org` on Matrix or `member@coquest.coop` by email.
|
||||
@@ -31,10 +31,4 @@ Pick the right medium for your interests.
|
||||
|
||||
[Email Us](mailto:helo@coopcloud.tech){ .md-button .md-button--primary }
|
||||
|
||||
- __Online call__
|
||||
|
||||
Join our weekly(ish) low-pressure drop-in call, "Kite flying"
|
||||
|
||||
[Fly a kite](/intro/kite-flying){ .md-button .md-button--primary }
|
||||
|
||||
</div>
|
||||
|
||||
@@ -12,7 +12,7 @@ We are happy to have designers, critical thinkers, artists, hackers, documenters
|
||||
|
||||
There are a number of "roles" such as "operator", "maintainer", "organiser" which we've tried to come up with to make it more clear how you can relate to the project and how you can find ways to be involved which suit your interests. If you don't fit one of these roles, that is fine.
|
||||
|
||||
We have [an irregular online check-in](/intro/kite-flying) for contributors of this project to let each other know what we're working on, how much time we've spent on it and how to coordinate further work.
|
||||
We have [an irregular online check-in](/federation/organisers/#kite-flying-hours) for contributors of this project to let each other know what we're working on, how much time we've spent on it and how to coordinate further work.
|
||||
|
||||
We have a [status page](/intro/bikemap) showing what we are aiming to achieve in the near future. That gives a good overview of where we're going together.
|
||||
|
||||
|
||||
@@ -1,11 +0,0 @@
|
||||
# Kite-flying
|
||||
|
||||
The "Kite Flying Hour" is a weekly public moment where anyone can "drop by" into a Jitsi call and ask/do/propose whatever and meet some people who are currently working on the project.
|
||||
|
||||
We meet on Thursdays, alternating between 12 and 19 UTC each week. You can find out when the next call is by adding [our shared calendar](https://coopcloud.tech/ics/kite-flying.ics) to your calendar application, or look out for an announcement via [`@coopcloud@social.coop`](https://social.coop/@coopcloud) and a post to the `#coopcloud:autonomic.zone` room.
|
||||
|
||||
Participation in kite-flying can be compensated at €20/hour; see Co-op Cloud Federation [Resolution 024](/federation/resolutions/passed/024) for details.
|
||||
|
||||
We take notes and doodle on [this collaboratively editable pad](https://pad.autonomic.zone/VtyrLUl9RWaJGgEDrncQUw?view). If you don't have time to attend, feel free to drop your questions and some contact details also, so we can get in touch.
|
||||
|
||||
To work around Hedgedoc length limits, [we keep past content from the kite-flying pad here](/federation/kite-flying-pad-archive).
|
||||
@@ -13,7 +13,5 @@ title: Managed hosting
|
||||
*Co-op Cloud* is still [beta quality software](https://en.wikipedia.org/wiki/Software_release_life_cycle#Beta) :bomb: but you can still work with a tech co-op or collective to host some part or all of your online digital services with it. Organisations who want to support the project can get in touch with *Co-op Cloud* service providers via the following list for a quote on what they're looking for and how much it will cost. Service providers can then factor in some percentage of the cost to co-fund the development of this project.
|
||||
|
||||
- [Autonomic Co-op](https://autonomic.zone) (contact: [`helo@autonomic.zone`](mailto:boop@autonomic.zone))
|
||||
- [soulhub-IT](https://soulhub-it.de) (managed hosting, see [price calculator](https://soulhub-it.de/produkte/))
|
||||
- [makeITsocial](https://makeitsocial.net) (managed hosting, see [price calculator](https://makeitsocial.net/kolli-cloud/))
|
||||
- [Local-IT](https://local-it.org/) ([selfhosting](https://wiki.local-it.org/s/kollicloud-wiki/doc/selfhosting-guide-1xZJt8UIha) & cooperative hosting, contact: [`info@local-it.org`](mailto:info@local-it.org))
|
||||
- [eCommons](https://ecommons.nl) (contact: [`info@ecommons.nl`](mailto:info@ecommons.nl))
|
||||
- [CoQuest - IT Coop Stuttgart](https://coquest.coop) (managed hosting, contact: [`hello@coquest.coop`](mailto:hello@coquest.coop))
|
||||
|
||||
@@ -32,16 +32,7 @@ You can start by reading The Maintainers Proposal: [`R025`](https://docs.coopclo
|
||||
|
||||
It is important that only recipe maintainers have write permissions to the repository. As it currently stands, every member of the [Co-operators Team](https://git.coopcloud.tech/org/coop-cloud/teams/co-operators) has write permissions to all recipe repositories for convenience while we are missing enough maintainers.
|
||||
|
||||
To change this:
|
||||
|
||||
1. Log into git.coopcloud.tech as an administrator account (e.g. `coopcloud`)
|
||||
2. Create a new team on [`git.coopcloud.tech/coop-cloud/teams`](https://git.coopcloud.tech/org/coop-cloud/teams) with the following settings:
|
||||
|
||||
- Name: e.g. `mycoolrecipe-maintainers`
|
||||
- Repository access: Specific repositories
|
||||
- Permission: Administrator access
|
||||
3. Add maintainers as "Team Members" on the "members" tab, and add the recipe repository on the "repositories" tab
|
||||
3. Remove your recipe repository from the [list of repositories for the Co-operators Team](https://git.coopcloud.tech/org/coop-cloud/teams/co-operators/repositories) so that write permissions are removed.
|
||||
To change this, create a new team on [`git.coopcloud.tech/coop-cloud/teams`](https://git.coopcloud.tech/org/coop-cloud/teams) for your specific recipe, e.g. `mycoolrecipe-maintainers`. Add yourself and any other maintainers and don't forget to add the recipe repository itself on the repositories tab. Remove your recipe repository from the [list of repositories for the Co-operators Team](https://git.coopcloud.tech/org/coop-cloud/teams/co-operators/repositories) so that write permissions are removed.
|
||||
|
||||
### Repository Permissions
|
||||
|
||||
|
||||
@@ -264,10 +264,6 @@ At time of writing (Jan 2022), we think there is a limitation in our design whic
|
||||
|
||||
This may be possible to overcome if someone really needs it, we encourage people to investigate. We've found that often there are limitations in the actual software which don't support this anyway and several of the current operators simply use a new domain per app.
|
||||
|
||||
## Can I add worker nodes to my docker swarm?
|
||||
|
||||
At time of writing (Sep 2026), we officially only support single-node swarms. However, we are working on improving our tools and understanding to support multi-node in the future. If you'd like to get involved, [here is what we know so far](/operators/multinode).
|
||||
|
||||
## How do I bootstrap a server for running Co-op Cloud apps?
|
||||
|
||||
The requirements are:
|
||||
|
||||
@@ -1,272 +0,0 @@
|
||||
---
|
||||
title: Multinode Best Practices
|
||||
---
|
||||
|
||||
## Who This How-To Guide is For
|
||||
|
||||
Configuring coop cloud on multiple nodes poses some difficult problems, and we have not yet streamlined this process. For the sake of security and sanity, you should have a good understanding of the following before you attempt this:
|
||||
|
||||
- VPN configuration, understanding how authentication and encryption are handled.
|
||||
- Firewalls, and `iptables` in particular.
|
||||
- Managing and synchronizing files on a network (e.g. sftp, nfs, rsync)
|
||||
|
||||
What follows is our best knowledge to date. Tread carefully, for here be dragons.
|
||||
|
||||
## Before You Start
|
||||
|
||||
**1. *On every node*, make sure docker is installed and running.
|
||||
|
||||
```bash
|
||||
docker run hello-world
|
||||
```
|
||||
|
||||
**2. *On every node*, ensure kernel modules `ip_vs`[^ip_vs] and `br_netfilter`[^br_netfilter] are loaded.
|
||||
|
||||
```bash
|
||||
lsmod | grep -E "^ip_vs |^br_netfilter "
|
||||
```
|
||||
|
||||
??? Why?
|
||||
|
||||
- `ip_vs` enables multiple Linux kernels to act as *one* virtual server, coordinating request handling and processing with eachother over IP. [kernelconfig.io](https://www.kernelconfig.io/config_ip_vs)
|
||||
- `br_netfilter` enables the kernelspace netfilter capability for bridge network interfaces. Without this kernel module, docker needs to route swarm packets via a slow and insecure userland proxy to communicate with the other docker networks. [Serverfault answer](https://serverfault.com/a/964491), [kernelconfig.io](https://www.kernelconfig.io/CONFIG_BRIDGE_NETFILTER?q=br_netfilter&kernelversion=7.2.4&arch=x86)
|
||||
|
||||
**3. Choose one node to be the manager node.
|
||||
|
||||
Ensure you can connect to this node with `ssh`.
|
||||
|
||||
!!! info "If your server isn't reachable"
|
||||
|
||||
If your manager node is not your main traefik proxy, `abra` may complain about the server not being reachable from the Internet. You can use the `-D` flag to ignore this warning.
|
||||
|
||||
??? warning "Do you need multiple manager nodes?"
|
||||
|
||||
It's easiest to start your setup by choosing only one node in your swarm to be the manager (the others will be worker nodes). If you need multiple manager nodes, e.g. to improve uptime, [read this first](https://docs.docker.com/engine/swarm/how-swarm-mode-works/nodes/#manager-nodes).
|
||||
|
||||
**4. establish a trusted network connection between each worker node and the manager.
|
||||
|
||||
This can be
|
||||
|
||||
- A standard "hub-and-spokes" VPN like strongswan, where worker nodes are connected to the manager node,
|
||||
- Or a mesh VPN like tailscale, where all nodes are connected together.
|
||||
|
||||
??? info "Use a route-based VPN"
|
||||
|
||||
There are two types of VPN implementations: policy-based and route-based. They differ in that route-based VPNs create a distinct network interface for trusted traffic. We'll be using this interface in the next step.
|
||||
|
||||
**5. *On every node*, using `iptables`[^iptables], block ingress on ports `2377/tcp`, `4789/udp`, `7946/udp`, `7946/tcp` except when it comes from a trusted interface. [Docker docs](https://docs.docker.com/engine/swarm/swarm-tutorial/#open-protocols-and-ports-between-the-hosts).
|
||||
|
||||
E.g., if trusted packets arrive on `vpn0`:
|
||||
|
||||
```bash
|
||||
iptables -A INPUT -p tcp --dport 2377 -i !vpn0 -j DROP
|
||||
iptables -A INPUT -p udp --dport 4789 -i !vpn0 -j DROP
|
||||
iptables -A INPUT -p udp --dport 7946 -i !vpn0 -j DROP
|
||||
iptables -A INPUT -p tcp --dport 7946 -i !vpn0 -j DROP
|
||||
```
|
||||
|
||||
??? warning "Use iptables, not nftables"
|
||||
|
||||
All hosts must use `iptables` as the firewall backend, not `nftables`. Nftables support in Docker is experimental, and docker swarm mode hasn't been migrated to support nftables yet. [docker docs](https://docs.docker.com/engine/network/firewall-nftables).
|
||||
|
||||
## Configuring the Swarm and Abra
|
||||
|
||||
**1. In `abra`, create a server using the manager node. (Refer to the [New Operators' Tutorial](https://docs.coopcloud.tech/operators/tutorial/) for a refresher on how to do this.)
|
||||
|
||||
When calling `docker swarm init`, include `--advertise-addr` and point to the trusted interface of your VPN.
|
||||
|
||||
**2. On the *manager node*, call
|
||||
|
||||
```bash
|
||||
docker swarm join-token worker
|
||||
```
|
||||
|
||||
**3. On a *worker node*, call the command provided, e.g.
|
||||
|
||||
```bash
|
||||
docker swarm join --token MYTOKEN M.Y.I.P:2377
|
||||
```
|
||||
|
||||
**4. On the *manager node*, verify the node is in the swarm:
|
||||
|
||||
```bash
|
||||
docker node ls
|
||||
```
|
||||
|
||||
## Volume Duplication
|
||||
|
||||
!!! warning "Docker swarm does not synchronize volume data between nodes."
|
||||
|
||||
- If services on the same recipe deploy on different nodes, they will not have access to any volumes shared between them.
|
||||
- If a service dies or is stopped, and docker swarm deploys it to a different node, it will not have access to its existing volume data.
|
||||
|
||||
You must choose one of these strategies:
|
||||
|
||||
**1. Using placement constraints, restrict apps to always run on specific nodes.
|
||||
|
||||
**2. Choose a networked filesystem (e.g. nfs, rclone) and use its *docker volume plugin* to synchronize volume data between worker nodes.
|
||||
|
||||
Both strategies are described below.
|
||||
|
||||
### How to restrict apps to specific nodes
|
||||
|
||||
**1. In your *abra config*, create a new compose file and set appropriate deploy.placement.constraints for each service. For example:
|
||||
|
||||
`~/.abra/compose/compose.restrict-nextcloud.yml`
|
||||
|
||||
```yml
|
||||
---
|
||||
version: "3.8"
|
||||
|
||||
services:
|
||||
web:
|
||||
deploy:
|
||||
placement:
|
||||
constraints:
|
||||
- node.labels.nextcloud_node == true
|
||||
app:
|
||||
deploy:
|
||||
placement:
|
||||
constraints:
|
||||
- node.labels.nextcloud_node == true
|
||||
cron:
|
||||
deploy:
|
||||
placement:
|
||||
constraints:
|
||||
- node.labels.nextcloud_node == true
|
||||
cache:
|
||||
deploy:
|
||||
placement:
|
||||
constraints:
|
||||
- node.labels.redis_node == true
|
||||
# nb: redis does not share volumes with other services,
|
||||
# so it could be deployed on a separate node.
|
||||
```
|
||||
|
||||
**2. On your *worker node*, assign the appropriate labels:
|
||||
|
||||
```bash
|
||||
docker node update --label-add nextcloud_node=true --label-add redis_node=true <worker_hostname>
|
||||
```
|
||||
|
||||
**3. On the *abra server*, Add your compose file to your app's config. E.g.:
|
||||
|
||||
```bash
|
||||
abra app config my.app
|
||||
```
|
||||
|
||||
```yml
|
||||
...
|
||||
COMPOSE_FILE="compose.yml"
|
||||
COMPOSE_FILE="$COMPOSE_FILE:../../compose/compose.restrict-nextcloud.yml"
|
||||
...
|
||||
```
|
||||
|
||||
**4. Deploy the app.
|
||||
|
||||
**5. Confirm all the services were correctly assigned:
|
||||
|
||||
```bash
|
||||
docker node ps <worker_hostname> | grep "Running"
|
||||
```
|
||||
|
||||
??? info "You can make much more complex setups with placement constraints and node configurations"
|
||||
|
||||
- [Placement constraints (about)](https://docs.docker.com/engine/swarm/services/#control-service-placement)
|
||||
- [Placement constraints (compose file reference)](https://docs.docker.com/reference/compose-file/deploy/#placement)
|
||||
- [Node labels (how to)](https://docs.docker.com/engine/swarm/manage-nodes/#add-or-remove-label-metadata)
|
||||
|
||||
### How to Use docker volume plugins
|
||||
|
||||
!!! warning "Do not use this strategy to synchronize database volumes."
|
||||
|
||||
Instead:
|
||||
- optionally configure a distributed database across your nodes (unknown what tools are best).
|
||||
- be careful when using `db` services in your recipes. Ignore them in favor of a dedicated database instance, or restrict the services to a dedicated node.
|
||||
- in your app configuration, use `DB_HOST` and similar environment variables to point to your network's database host.
|
||||
|
||||
!!! warning "Use the S3 protocol wherever a recipe allows it."
|
||||
|
||||
S3 is much more efficient at synchronizing large amounts of data. We recommend [garage](https://git.coopcloud.tech/coop-cloud/garage).
|
||||
On the other hand, avoid using `s3fs` to store docker volumes - this can cause race conditions because S3 does not allow file locking.
|
||||
|
||||
**1. Choose a machine to be your dedicated volume data store.
|
||||
|
||||
**2. On your *data storage machine*, choose and install a network-accessible file store. Just about anything can be made to work (with tradeoffs): ssh, nfs, NextCloud, WebDav, ProtonDrive, etc.
|
||||
|
||||
**3. Ensure your file store can be securely accessed from every worker node.
|
||||
|
||||
**4. *On every node in your swarm*, install a dedicated docker volume plugin for your file store, or use a generic middleware like [Rclone](https://rclone.org/docker/).
|
||||
|
||||
**5. In your *abra config*, create a custom compose file and configure the plugin on all of your recipe's volumes. E.g.:
|
||||
|
||||
`~/.abra/compose/compose.nextcloud-rclone.yml`
|
||||
|
||||
```yml
|
||||
---
|
||||
version: "3.8"
|
||||
|
||||
volumes:
|
||||
nextcloud:
|
||||
driver: rclone
|
||||
driver_opts:
|
||||
...
|
||||
nextapps:
|
||||
driver: rclone
|
||||
driver_opts:
|
||||
...
|
||||
nextdata: # note: you should use S3 for the majority of your data.
|
||||
driver: rclone
|
||||
driver_opts:
|
||||
...
|
||||
nextconfig:
|
||||
driver: rclone
|
||||
driver_opts:
|
||||
...
|
||||
# here we skip the redis volume, because its cache data
|
||||
# doesn't need to be persisted between nodes
|
||||
```
|
||||
|
||||
**6. Include the compose file in your instance's config. E.g.
|
||||
|
||||
```bash
|
||||
abra app config my.app
|
||||
```
|
||||
|
||||
```yml
|
||||
...
|
||||
COMPOSE_FILE="compose.yml"
|
||||
COMPOSE_FILE="$COMPOSE_FILE:../../compose/compose.nextcloud-rclone.yml"
|
||||
...
|
||||
```
|
||||
|
||||
**7. Deploy the app
|
||||
|
||||
**8. Optionally, verify the volumes are no longer on disk:
|
||||
|
||||
```bash
|
||||
docker volume ls
|
||||
sudo ls /var/lib/docker/volumes/
|
||||
```
|
||||
|
||||
**9. Optionally, destroy any volumes that were previously created:
|
||||
|
||||
```bash
|
||||
docker volume prune -a
|
||||
```
|
||||
|
||||
## Additional Notes
|
||||
|
||||
- Manager nodes should be placed on your most reliable machines, since without them workers cannot deploy services. Because of this, you may want to constrain critical apps to run only on managers: `node.role == manager`.
|
||||
- If an app needs certain resources to be available (e.g. 4 GiB RAM), you can set a resource constraint, which ensures the app can only be scheduled on nodes with that resource available. [See docker docs](https://docs.docker.com/reference/compose-file/deploy/#resources)
|
||||
- A Docker swarm cluster should have an odd number of manager nodes. 1 manager is sufficient, and 3 managers is the minimum for redundancy. [See docker docs](https://docs.docker.com/engine/swarm/how-swarm-mode-works/nodes/#manager-nodes)
|
||||
- When using a swarm with worker nodes, some information will be invisible to abra. In particular, `abra app logs` and `abra app ps` will (at time of writing) give incomplete information. Here are some workarounds:
|
||||
- Instead of `abra app logs example.com app`, call `docker service logs example_com_app` on a manager node.
|
||||
- In addition to `abra app ps example.com`, try: `docker node ps <node_name> | grep example_com`, `docker service ps example_com_app`, `docker service ls -f name=example_com`, `docker stats`
|
||||
- Abra can only interact with manager nodes; worker nodes lack permissions to run most of abra's commands. When creating an `abra server`, remember to connect to a manager node.
|
||||
|
||||
### Additional Resources
|
||||
|
||||
- [nix-config by papiris](https://codeberg.org/papiris/nix-config/src/branch/main/overlays/virtualisation/docker.nix) (multi-node Co-op Cloud, docker within systemd-nspawn)
|
||||
- [SweHarris blog post](https://www.sweharris.org/post/2017-07-30-docker-placement/) about docker swarm placement
|
||||
- [OneUpTime article](https://oneuptime.com/blog/post/2026-03-20-portainer-service-placement-constraints/view) by @nawazdhandala about docker swarm placement
|
||||
@@ -56,7 +56,7 @@ Abra can't deploy any applications in future steps unless it can run `docker` co
|
||||
groups | grep docker
|
||||
|
||||
# if the docker group doesn't already exist, add it manually
|
||||
sudo groupadd docker
|
||||
groupadd docker
|
||||
|
||||
# add user to docker group
|
||||
sudo usermod -aG docker $USER
|
||||
|
||||
+2
-11
@@ -66,7 +66,6 @@ nav:
|
||||
- "Inspirations": intro/inspirations.md
|
||||
- "Project Status": intro/bikemap.md
|
||||
- "Managed Hosting": intro/managed.md
|
||||
- "Kite flying hour": intro/kite-flying.md
|
||||
- "Get In Touch": intro/contact.md
|
||||
- "Credits": intro/credits.md
|
||||
- intro/get-involved.md
|
||||
@@ -134,22 +133,15 @@ nav:
|
||||
- federation/resolutions/passed/031.md
|
||||
- federation/resolutions/passed/033.md
|
||||
- federation/resolutions/passed/034.md
|
||||
- federation/resolutions/passed/035.md
|
||||
- federation/resolutions/passed/036.md
|
||||
- federation/resolutions/passed/037.md
|
||||
- federation/resolutions/passed/038.md
|
||||
- federation/resolutions/passed/039.md
|
||||
- federation/resolutions/passed/041.md
|
||||
- federation/resolutions/passed/040.md
|
||||
- federation/resolutions/passed/042.md
|
||||
- federation/resolutions/passed/043.md
|
||||
- federation/resolutions/passed/044.md
|
||||
- "Stalled":
|
||||
- federation/resolutions/stalled/013.md
|
||||
- federation/resolutions/stalled/030.md
|
||||
- "In Progress":
|
||||
- federation/resolutions/in-progress/045.md
|
||||
- federation/resolutions/index.md
|
||||
- federation/resolutions/in-progress/035.md
|
||||
- federation/resolutions/in-progress/037.md
|
||||
- "Minutes":
|
||||
- federation/minutes/index.md
|
||||
- "Recently":
|
||||
@@ -193,7 +185,6 @@ plugins:
|
||||
- redirects:
|
||||
redirect_maps:
|
||||
"get-involved/support/index.md": intro/support.md
|
||||
"faq.md": intro/faq.md
|
||||
|
||||
repo_name: toolshed/docs.coopcloud.tech
|
||||
repo_url: https://git.coopcloud.tech/toolshed/docs.coopcloud.tech/
|
||||
|
||||
Reference in New Issue
Block a user