From b926d3d975ca882909ae1e20d409f6a5e44a323e Mon Sep 17 00:00:00 2001 From: decentral1se Date: Tue, 6 Feb 2024 00:54:27 +0100 Subject: [PATCH 01/10] fix: use single source of deps Closes https://git.coopcloud.tech/coop-cloud/organising/issues/564 --- Dockerfile | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/Dockerfile b/Dockerfile index 8b1710b..45ab3ea 100644 --- a/Dockerfile +++ b/Dockerfile @@ -8,7 +8,4 @@ WORKDIR /docs RUN apk add --no-cache curl -RUN pip install \ - mkdocs-material~=9.5.7 \ - mkdocs-material-extensions~=1.3.1 \ - mkdocs-awesome-pages-plugin==2.9.2 +RUN pip install -r requirements.txt From 24b996acb9562ac0793bc99649e94f08c91644f8 Mon Sep 17 00:00:00 2001 From: iexos Date: Tue, 6 Feb 2024 09:39:19 +0000 Subject: [PATCH 02/10] maintainers handbook: fix typo --- docs/maintainers/handbook.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/maintainers/handbook.md b/docs/maintainers/handbook.md index a2cfc50..3832cc8 100644 --- a/docs/maintainers/handbook.md +++ b/docs/maintainers/handbook.md @@ -433,7 +433,7 @@ You can pass `--publish` to have `abra` automatically publish those changes. [`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)" +[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 From 1b3c788722a0c925adfc136996837f28f8da6d9f Mon Sep 17 00:00:00 2001 From: decentral1se Date: Wed, 7 Feb 2024 11:23:57 +0100 Subject: [PATCH 03/10] fix: dates --- docs/federation/resolutions/in-progress/017.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/federation/resolutions/in-progress/017.md b/docs/federation/resolutions/in-progress/017.md index c4dbfd8..746671a 100644 --- a/docs/federation/resolutions/in-progress/017.md +++ b/docs/federation/resolutions/in-progress/017.md @@ -1,8 +1,8 @@ --- -title: "Resolution 17: BeWater joins the Co-op Cloud Federation - 30-01-2024" +title: "Resolution 17: BeWater joins the Co-op Cloud Federation - 07-02-2024" --- -- Deadline: 13-02-2024 +- Deadline: 21-02-2024 - Size: Large ### Summary From 4960b301e079485dd9d45f963a46fdfd1dc3e953 Mon Sep 17 00:00:00 2001 From: basebuilder Date: Mon, 12 Feb 2024 12:09:56 +0100 Subject: [PATCH 04/10] Add first pass of a Support Us page --- docs/get-involved/support.md | 25 +++++++++++++++++++++++++ mkdocs.yml | 1 + 2 files changed, 26 insertions(+) create mode 100644 docs/get-involved/support.md diff --git a/docs/get-involved/support.md b/docs/get-involved/support.md new file mode 100644 index 0000000..08a8d54 --- /dev/null +++ b/docs/get-involved/support.md @@ -0,0 +1,25 @@ +--- +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). + +
+ +- __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 } + +- __Joining 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 } + +
diff --git a/mkdocs.yml b/mkdocs.yml index fa26c39..6ea1ca1 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -91,6 +91,7 @@ nav: - "Cheat Sheet": abra/cheat-sheet.md - "Get Involved": - get-involved/index.md + - "Support Us": get-involved/support.md - "Federation": - federation/index.md - "FAQ": federation/faq.md From 3ae0ac10b3af8ea9c175125967fc3c85da88af54 Mon Sep 17 00:00:00 2001 From: basebuilder Date: Tue, 13 Feb 2024 23:21:27 +0100 Subject: [PATCH 05/10] fix Join The Federation on Support Us page --- docs/get-involved/support.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/get-involved/support.md b/docs/get-involved/support.md index 08a8d54..69d3dbb 100644 --- a/docs/get-involved/support.md +++ b/docs/get-involved/support.md @@ -15,7 +15,7 @@ via an [Open Collective account](https://opencollective.com/coop-cloud). [Donate Now](https://opencollective.com/coop-cloud/contribute/infrastructure-sustainability-29878/checkout){ .md-button .md-button--primary } -- __Joining Federation__ +- __Join The Federation__ If you want to be more actively involved as a supporter, consider joining our Federation :handshake_tone2: From 1172da919cd3de0890d2a687b45fb12cbce62d14 Mon Sep 17 00:00:00 2001 From: basebuilder Date: Wed, 14 Feb 2024 10:05:10 +0100 Subject: [PATCH 06/10] add emoji sprinkles to Maintainers Handbook :) --- docs/maintainers/tutorial.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/maintainers/tutorial.md b/docs/maintainers/tutorial.md index 15357dc..d0c08de 100644 --- a/docs/maintainers/tutorial.md +++ b/docs/maintainers/tutorial.md @@ -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 -- **Wired**: Use someone else's image (& maybe compose file) -- **Inspired**: Upstream image, someone else's compose file -- **On fire**: Upstream image, upstream compose file +- **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: ### Writing / adapting the `compose.yml` From d4c39ab0744cdee76aa46b8f14ee487bc72c297f Mon Sep 17 00:00:00 2001 From: basebuilder Date: Wed, 14 Feb 2024 11:26:33 +0100 Subject: [PATCH 07/10] maintainers handbook, fix mispelling --- docs/maintainers/handbook.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/maintainers/handbook.md b/docs/maintainers/handbook.md index 3832cc8..6409be0 100644 --- a/docs/maintainers/handbook.md +++ b/docs/maintainers/handbook.md @@ -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 extention list. Whenever you create a new app with `abra app new` this file gets copied to the `~/.abra/servers//.env` and when you run `abra app config ` 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 extension list. Whenever you create a new app with `abra app new` this file gets copied to the `~/.abra/servers//.env` and when you run `abra app config ` you're editing this file. ### `abra.sh` From 8c85a7928d6dbaff69c823a8cccceb876430ebfa Mon Sep 17 00:00:00 2001 From: basebuilder Date: Wed, 21 Feb 2024 15:17:52 +0100 Subject: [PATCH 08/10] move 'What about -> Comparisons page --- docs/intro/comparisons.md | 121 ++++++++++++++++++++++++++++++++++++++ docs/intro/faq.md | 112 ----------------------------------- mkdocs.yml | 1 + 3 files changed, 122 insertions(+), 112 deletions(-) create mode 100644 docs/intro/comparisons.md diff --git a/docs/intro/comparisons.md b/docs/intro/comparisons.md new file mode 100644 index 0000000..34903a8 --- /dev/null +++ b/docs/intro/comparisons.md @@ -0,0 +1,121 @@ +--- +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 + +#### 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. diff --git a/docs/intro/faq.md b/docs/intro/faq.md index fbc17a3..c278fec 100644 --- a/docs/intro/faq.md +++ b/docs/intro/faq.md @@ -40,118 +40,6 @@ Also see our [strategy page](../strategy/). 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? diff --git a/mkdocs.yml b/mkdocs.yml index 6ea1ca1..cda5ac0 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -54,6 +54,7 @@ nav: - index.md - "Frequently asked questions": intro/faq.md - "Project strategy": intro/strategy.md + - "Comparisons": intro/comparisons.md - "Project status": intro/bikemap.md - "Managed hosting": intro/managed.md - "Get in touch": intro/contact.md From c3cc6fc1c6dc56013c3a0cce05fc4feb1813d0fa Mon Sep 17 00:00:00 2001 From: basebuilder Date: Wed, 21 Feb 2024 16:10:36 +0100 Subject: [PATCH 09/10] add Stackspin Comparison --- docs/intro/comparisons.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/docs/intro/comparisons.md b/docs/intro/comparisons.md index 34903a8..6fdc807 100644 --- a/docs/intro/comparisons.md +++ b/docs/intro/comparisons.md @@ -119,3 +119,22 @@ Here is a short overview of the pros/cons we see, in relation to our goals and n - 👎 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 + +#### 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. From 0ddd0bff661edc22ff23deefc5078297d2518033 Mon Sep 17 00:00:00 2001 From: basebuilder Date: Wed, 21 Feb 2024 17:00:38 +0100 Subject: [PATCH 10/10] add Maadix to Comparisons page --- docs/intro/comparisons.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/docs/intro/comparisons.md b/docs/intro/comparisons.md index 6fdc807..4d48564 100644 --- a/docs/intro/comparisons.md +++ b/docs/intro/comparisons.md @@ -138,3 +138,21 @@ Here is a short overview of the pros/cons we see, in relation to our goals and n - 👎 Significantly limited library of eight apps. - 👎 Additional apps are treated as "External Apps" with only OAuth2/OpenID integration. - 👎 Requires a Kubernetes cluster. + + +### Maadix + +#### 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.