forked from toolshed/docs.coopcloud.tech
fixing merge conflict on mkdocs.yml
This commit is contained in:
158
docs/intro/comparisons.md
Normal file
158
docs/intro/comparisons.md
Normal file
@ -0,0 +1,158 @@
|
||||
---
|
||||
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.
|
||||
|
||||
|
||||
### 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.
|
||||
|
||||
|
||||
### 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.
|
||||
@ -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?
|
||||
|
||||
|
||||
@ -1,19 +1,105 @@
|
||||
---
|
||||
title: Project strategy
|
||||
title: Project Strategy
|
||||
---
|
||||
|
||||
!!! note "Yes, we are blog"
|
||||
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)".
|
||||
|
||||
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.
|
||||
## Technological Saviors?
|
||||
|
||||
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/
|
||||
|
||||
Reference in New Issue
Block a user