Compare commits

..

1 Commits

Author SHA1 Message Date
decentral1se cb9026bd76
beta release post 2022-06-03 11:27:34 +02:00
1 changed files with 56 additions and 38 deletions

View File

@ -16,55 +16,57 @@ We're delighted to announce that the public beta of Co-op Cloud is here at last!
Before we dive in, if you're new to the project, [you'll probably want to start with our project launch post on `autonomic.zone`](https://autonomic.zone/blog/co-op-cloud/), and if you're still curious, follow along on [our (sometimes) monthly blog posts](https://coopcloud.tech/blog/) to get the full context.
So, what does "alpha" and "beta" quality software even mean!?
So, what does "alpha" and "beta" quality software even mean?
Alpha meant that the project could fundamentally change at any time! Things were still super experimental and we were trying to find out how to make things work.
Alpha meant that the project could fundamentally change at any time! Things were still super experimental and we were trying to find out how to make things work. Beta means things won't fundamentally change! We're pretty confident that we have a stable base now, the moving parts of the project fit well together and things are relatively easy to maintain as we bring in new changes.
Beta means things won't fundamentally change! We're pretty confident that we have a stable base now, the moving parts of the project fit well together and things are relatively easy to maintain as we bring in new changes.
Despite the experimental nature of the project so far, we've seen a lot of people picking up Co-op Cloud, setting up deployments and getting rad with us. Folks are reporting back that it is helping them get their work done, and fits their needs. It makes daily work convenient, and is relatively easy to learn.
Despite the experimental nature of the project so far, we've seen a lot of people picking up Co-op Cloud, setting up deployments and getting rad with us. Folks are reporting back that it is helping them get their work done, and fits their needs. It makes daily work convenient, and is relatively easy to learn. To everyone who took the risk of getting involved in the alpha and even pre-alpha stages of this project: you are amazing and we couldn't have done it without you :heart:
To everyone who took the risk of getting involved in the alpha and even pre-alpha stages of this project: you are amazing and we couldn't have done it without you :heart:
## The beta bikemap in review
At the start of all this, we laid our goals out in a document we called [The Beta Bikemap](https://pad.autonomic.zone/s/C3uuqfSCk) (because roads are usually for cars, and bikes > cars). While we believe we did not yet fully address 3 of the goals ([Continuous integration testing for apps](https://pad.autonomic.zone/s/C3uuqfSCk#Continuous-integration-testing-for-apps), [Payments and billing](https://pad.autonomic.zone/s/C3uuqfSCk#Payments-and-billing), [Pen Testing/security](https://pad.autonomic.zone/s/C3uuqfSCk#Pen-Testingsecurity)) we're happy to say we think we did a good job with the 12 others!
At the start of all this, we laid our goals out in a document we called [the beta bikemap](https://pad.autonomic.zone/s/C3uuqfSCk) (because roads are usually for cars, and bikes > cars). While we believe we did not yet fully address 3 of the goals ([Continuous integration testing for apps](https://pad.autonomic.zone/s/C3uuqfSCk#Continuous-integration-testing-for-apps), [Payments and billing](https://pad.autonomic.zone/s/C3uuqfSCk#Payments-and-billing), [Pen Testing/security](https://pad.autonomic.zone/s/C3uuqfSCk#Pen-Testingsecurity)), we think we did a good job with the 12 others!
In retrospect, it was quite an ambitious plan. Here is the breakdown of the bikemap and an overview of what we achieved on each point.
### [Command-line tool sustainability](https://pad.autonomic.zone/s/C3uuqfSCk#Command-line-tool-sustainability)
In the early days, we started off with a [Bash implementation of `abra`](https://git.coopcloud.tech/coop-cloud/abra-bash), our command-line tool for administrating Co-op Cloud deployments. One of our more ambitious goals was to re-implement this Bash script in a programming language which would help us work with data structures, formats & 3rd party APIs in a more manageable way.
In the early days, we started off with a [Bash implementation of `abra`](https://git.coopcloud.tech/coop-cloud/abra-bash), our command-line tool for administrating Co-op Cloud deployments. One of our more galaxy brain ideas was to re-implement this Bash script in a programming language which would help us work with data structures, formats and 3rd party APIs in a more manageable way.
We've since managed to successfully implement [`abra` in the Go programming language](https://git.coopcloud.tech/coop-cloud/abra)! There were some serious doubts along the way about whether we were just getting lost in a [second system syndrome](https://en.wikipedia.org/wiki/Second-system_effect) (yes, our Bash implementation was "small, elegant, and successful" :smile:) but we managed! Here's to 16,766 lines of Go code :beers:. Some of the improvements include:
We've since implemented [`abra` in the Go programming language](https://git.coopcloud.tech/coop-cloud/abra)! There were some serious doubts along the way about whether we were just getting lost in a [second system syndrome](https://en.wikipedia.org/wiki/Second-system_effect) (yes, our Bash implementation was "small, elegant, and successful" :smile:) but we managed! Here's to 16,766 lines of Go code :beers:.
- Abra is now distributed as a statically compiled single binary which is simple to install and start using. The binary works for several popular platforms, and we've seen a huge reduction in reported installation issues.
Some of the improvements include:
- New features such as the scripts interface, cloud server/DNS integration and recipe catalogue generation command, while staying feature complete with the original Bash implementation.
- `abra` is now distributed as a statically compiled single binary which is simple to install and start using. The binary works for several popular platforms, and we've seen a reduction in reports for installation problems.
- Improvements to abra's test-suite-of-sorts, release automation & management, and fairly [comprehensive documentation](https://docs.coopcloud.tech/abra/).
- The Go implementation has feature parity with the Bash implementation but also gained new special powers! For example, the scripts interface, cloud server/DNS integration and recipe catalogue generation.
- No longer relying on having Docker installed on your local work machine. We've managed to make `abra` a fully compatible Docker daemon client which can interact via the remote HTTP API. This makes us more resilient, reducing our reliance on corporate tools for our community needs.
- Improvements to the `abra` test-suite-of-sorts, release automation & management, and fairly [comprehensive documentation](https://docs.coopcloud.tech/abra/).
- `abra` no longer relies on having Docker installed on your local work machine. We've managed to make it a fully compatible Docker daemon client which can interact via the remote HTTP API. This makes us more resilient, reducing our reliance on corporate tools for our community needs.
### [Versioning and deploy stability](https://pad.autonomic.zone/s/C3uuqfSCk#Versioning-and-deploy-stability)
One of our main goals for `abra` and Co-op Cloud apps was stability. We want things to run smoothly when we maintain and upgrade our deployments. We've been working hard on this one and have managed to come up with several moving parts which we think help make Co-op Cloud deployments more reliable.
A core goal for Co-op Cloud is stability. We want things to run smoothly when we maintain and upgrade our deployments. We've been working hard on this one and have managed to come up with several moving parts which we think help make Co-op Cloud deployments more reliable.
- Recipes can be versioned & published with `abra` to our [recipe catalogue](https://recipes.coopcloud.tech/). Each recipe uses a [variation](https://docs.coopcloud.tech/maintainers/handbook/#how-are-recipes-are-versioned) of [semantic versioning](https://semver.org/) which helps maintainers communicate what kind of changes are coming in the new version.
- We've [extensively documented](https://docs.coopcloud.tech/maintainers/) ways to work with and maintain recipes so that anyone can join in and help.
- We've [documented](https://docs.coopcloud.tech/maintainers/) ways to work with and maintain recipes so that anyone can join in and help.
- We've implemented `deploy` / `upgrade` / `rollback` commands in `abra` so that folks can easily control the deployment state of their apps. We've set up a system of [release notes](https://docs.coopcloud.tech/maintainers/handbook/#how-do-i-write-version-release-notes) for recipes so that maintainers can leave helpful notes for operators when doing deployments. These notes are shown at deploy-time, so operators will be warned and hopefully avoid any heartbreak.
- We've implemented commands in `abra` so that operators can easily control the deployment state of their apps (e.g. `deploy`/`upgrade`/`rollback`). We've set up a system for [release notes](https://docs.coopcloud.tech/maintainers/handbook/#how-do-i-write-version-release-notes) so that operators can leave helpful notes for other operators when doing deployments. These notes are shown at deploy-time, so operators will be warned and hopefully avoid any heartbreak.
- `abra catalogue generate` features an implementation which parses all recipe repositories and generates [a JSON format catalogue listing](https://recipes.coopcloud.tech/recipes.json). The data for this catalogue is gathered automagically from the recipe `README.md` files. This catalogue is then consumed by `abra` in order to reason about deployment state and determine available versions.
- `abra` is able to parse all recipe repositories in order to generate [a JSON recipe catalogue listing](https://recipes.coopcloud.tech/recipes.json). This catalogue is then consumed by `abra` in order to reason about deployment state and determine available versions.
### [Backup and restore](https://pad.autonomic.zone/s/C3uuqfSCk#Backup-and-restore)
Standardising the way backup/restore are done was always seen as a boon for time-saving and re-use as it is one of the main guarantees that turns a deployment into a "production deployment".
Standardising the way backup/restore is done was always seen as a boon for time-saving and re-use. Being able to back up and restore app data is often seen as one of the main ways a regular deployment turns into a "production deployment".
We struggled to arrive at a single "works for everyone" solution. Instead, we aimed for a general solution which is flexible and also open to other approaches. We've heard from several groups who do backups very differently, so we had to have something that was customisable.
We developed two approaches to doing backup/restore. One using `abra` (e.g. `abra app backup` / `abra app restore`) and another using a [run-time bot](https://git.coopcloud.tech/coop-cloud/backup-bot-two). [We documented](https://docs.coopcloud.tech/maintainers/handbook/#how-do-i-configure-backuprestore) both of these methods and have seen several folks using it to great effect.
We developed two approaches to doing backup/restore. One using `abra` (e.g. `abra app backup` / `abra app restore`) and another using a [run-time bot](https://git.coopcloud.tech/coop-cloud/backup-bot-two). [We documented](https://docs.coopcloud.tech/maintainers/handbook/#how-do-i-configure-backuprestore) both of these methods and have seen several operators making use of them.
The core of our approach was to use [Docker object labels](https://docs.docker.com/config/labels-custom-metadata/) to mark backup/restore commands inside the recipe configuration. This suited our approach of maintaining the entire production state of the deployment inside the recipe.
Tools like `abra` and `backup-bot-two` can read these labels at run-time and do backup/restore work. Other implementations are possible and we welcome change sets.
The core of our approach was to use [Docker object labels](https://docs.docker.com/config/labels-custom-metadata/) to mark backup/restore commands inside the recipe configuration. This suits our approach of maintaining the entire production state of the deployment inside the recipe. Tools like `abra` and `backup-bot-two` can then read these labels at run-time and do backup/restore work.
### [Co-op Cloud “The Organisation”](https://pad.autonomic.zone/s/C3uuqfSCk#Co-op-Cloud-%E2%80%9CThe-Organisation%E2%80%9D)
@ -78,6 +80,8 @@ Beyond this, we'd like to give a huge shout-out to the folks who are using Co-op
Lists are always incomplete but we'll try anyway! Here is the cast of Co-op Cloud Comrades so far:
(PS. sorry if we forgot you! Please let us know and we'll add you in :fingers_crossed:)
- [Local-IT](https://local-it.org) (operators, maintainers)
- [Threndol Tutoring](https://threndoltutoring.com/) (end-users)
- [ruangrupa & `lumbung.space`](https://lumbung.space/about/) (end-users)
@ -92,12 +96,18 @@ Lists are always incomplete but we'll try anyway! Here is the cast of Co-op Clou
- [Third Sector Accountancy](https://www.thirdsectoraccountancy.coop/) (end-users)
- [Anarchy Rules](https://anarchyrules.info/) (end-users)
- [Doop Coop](https://doop.coop) (design work & feedback)
- [bath.social](https://about.bath.social/) (operators & maintainers)
- [Bonfire](https://bonfirenetworks.org/) (operators & maintainers)
- [Tante Wandel](https://wandelgut.de/projekte/einkaufskooperative-tante-wandel/) (end-users)
- [WASHNote](https://washnote.org) (operators)
- [Solisoft](https://solisoft.top/) (operators & maintainers)
- [Forum voor Anarchisme](https://www.forumvooranarchisme.nl/en/home) (operators)
### [Compensating contributors](https://pad.autonomic.zone/s/C3uuqfSCk#Compensating-contributors)
We didn't want to be another project which asks people to do free work them. Instead, we set up an [Open Collective](https://opencollective.com/coop-cloud), [wrote clear documentation about how to get paid](https://docs.coopcloud.tech/get-involved/#compensation) and simply paid people for their contributions!
We didn't want to be another project which asks people to do free work them. Instead, we set up an [Open Collective](https://opencollective.com/coop-cloud), [wrote clear documentation](https://docs.coopcloud.tech/get-involved/#compensation) and simply paid people for their contributions!
We're proud to report that we paid out around 2,000 euros worth of funding for contributions by external contributors. It was a pleasure to open up space for people to actually get paid for their work and to re-distribute the available funding to other individuals, groups and projects.
We're proud to report that we paid out around 2,000 euros worth of funding for work done by external contributors. It was a pleasure to open up space for people to actually get paid for their free software work and to re-distribute the available funding to other individuals, groups and projects.
We think more libre software projects should be thinking about how to use money for building collective power. In the (slightly edited) words of [LURK](https://lurk.org/):
@ -105,19 +115,23 @@ We think more libre software projects should be thinking about how to use money
### [Wider libre apps selection](https://pad.autonomic.zone/s/C3uuqfSCk#Wider-libre-apps-selection)
We wanted to expand the choice of libre software apps that folks could deploy so that different needs could be met. Certainly, we've seen that a lot of experimentation and testing needs to happen in order to understand if a software is a good pick. Also, we wanted to make it easy to package new apps for Co-op Cloud.
We wanted to expand the choice of libre software apps that operators could deploy so that different needs could be met. Certainly, we've seen that a lot of experimentation and testing needs to happen in order to understand if a libre software is a good pick.
We now currently have 90+ libre software apps packaged under our [`git.coopcloud.tech/coop-cloud/...`](https://git.coopcloud.tech/coop-cloud) repository listing. Most of those appear also under the [recipe catalogue listing](https://recipes.coopcloud.tech/) or will slowly appear once maintainers bring them into the catalogue.
We now currently have 90+ libre software apps packaged under our [`git.coopcloud.tech/coop-cloud/...`](https://git.coopcloud.tech/coop-cloud) repository listing. Most of those appear also under the [recipe catalogue listing](https://recipes.coopcloud.tech/) or will begin to appear once maintainers bring them into the catalogue.
We expanded the [recipe documentation](https://docs.coopcloud.tech/maintainers/) in order to make it clear how to work with recipes in Co-op Cloud. We've since seen several new folks jump in and start packaging libre software without much help or guidance from us.
Also, we wanted to make it easy to package new apps for Co-op Cloud. We expanded the [recipe documentation](https://docs.coopcloud.tech/maintainers/) in order to make it clear how to work with recipes in Co-op Cloud. We've since seen several new folks jump in and start packaging libre software without much help or guidance from us.
### [Documentation](https://pad.autonomic.zone/s/C3uuqfSCk#Documentation)
[`docs.coopcloud.tech`](https://docs.coopcloud.tech/) has been heavily revamped and redesigned from the ground up! We expanded the idea of "roles" in the project, such as "operators" and "maintainers" and made sure to document all the recipe packaging tips, tricks & hacks. Writing solid documentation has been our focus and will continue to be.
[`docs.coopcloud.tech`](https://docs.coopcloud.tech/) has been heavily revamped and redesigned from the ground up!
We expanded the idea of "roles" in the project, such as "operators" and "maintainers" and made sure to document all the recipe packaging tips, tricks & hacks.
Writing solid documentation has been our focus and will continue to be.
### [UI / UX testing](https://pad.autonomic.zone/s/C3uuqfSCk#UI--UX-testing)
We have been doing extensive interface and experience testing since the pre-alpha stages of the project. This is mainly due to ["dog fooding"](https://en.wikipedia.org/wiki/Eating_your_own_dog_food) we've taken.
We have been doing extensive interface design and end-user experience testing since the pre-alpha stages of the project. This is mainly due to the ["dog fooding"](https://en.wikipedia.org/wiki/Eating_your_own_dog_food) approach we've been taking.
We have been using `abra` extensively in our own deployments and projects for the entire period. We've encouraged other collectives to join us in this process and raise issues when they run into problems.
@ -125,29 +139,33 @@ The results can be seen in [263 closed reports](https://git.coopcloud.tech/coop-
### [Portability testing (software/hardware)](https://pad.autonomic.zone/s/C3uuqfSCk#Portability-testing-softwarehardware)
We wanted Co-op Cloud deployments to run on new and old hardware and of course be compatible with current day cloud providers.
We wanted Co-op Cloud deployments to run on new and old hardware and of course be compatible with current cloud providers.
Thankfully, `abra` can be cross-compiled to support several mainstream platforms: GNU/Linux, ARM (several versions) and MacOS. All versions can be seen on our [`abra` release page](https://git.coopcloud.tech/coop-cloud/abra/releases).
`abra` can be cross-compiled to support several mainstream platforms: GNU/Linux, ARM (several versions) and MacOS. All versions can be seen on our [`abra` release page](https://git.coopcloud.tech/coop-cloud/abra/releases).
We set up release automation for automagic cross-platform builds and also see space for supporting new platforms as the needs arise.
### [Cloud provisioning portability](https://pad.autonomic.zone/s/C3uuqfSCk#Cloud-provisioning-portability-Hetzner-DO-Linode-etc)
A fact of reality today is that a lot of democratic tech collectives are in a position of only being able to use corporate cloud server providers. This is due to a lot of reasons (and we're also working on [changing that](https://servers.coop/)) but we didn't want to ignore this and not have some form of support for it.
A fact of life today is that a lot of democratic tech collectives are in a position of only being able to use corporate cloud server providers. This is due to a lot of reasons (and we're also working on [changing that](https://servers.coop/)) but we didn't want to ignore this and not have some form of support for it.
`abra` now supports the creation of servers through integrations with [Servers.coop](https://servers.coop) and [Hetzner](https://www.hetzner.com/) via the `abra server new` command interface.
`abra` now supports the creation of servers through integrations with [Servers.coop](https://servers.coop) and [Hetzner](https://www.hetzner.com/) via the `abra server new` command interface. We support one co-op provider and one corporate provider.
Also, it's possible to work with cloud-based DNS providers via `abra` via the `abra record` command interface. Creating, editing and removing DNS records via [Gandi](https://www.gandi.net/en-GB) is currently supported.
We are happy to have these implementations to show what is possible. They are extendable and we are happy to receive change sets for new integrations based on needs.
We are happy to have these implementations to show what is possible.
### [Design and aesthetics](https://pad.autonomic.zone/s/C3uuqfSCk#Cloud-provisioning-portability-Hetzner-DO-Linode-etc)
We established branding and a aesthetic through conversation about our values and how we want the project to be represented. This design brief was then implemented across all our public sites such as [`coopcloud.tech`](https://coopcloud.tech), [`docs.coopcloud.tech`](https://docs.coopcloud.tech) & [`recipes.coopcloud.tech`](https://recipes.coopcloud.tech).
We established branding and aesthetics through conversation about our values and how we want the project to be represented.
This design brief was then implemented across all our public sites such as [`coopcloud.tech`](https://coopcloud.tech), [`docs.coopcloud.tech`](https://docs.coopcloud.tech) & [`recipes.coopcloud.tech`](https://recipes.coopcloud.tech).
### [Public communications](https://pad.autonomic.zone/s/C3uuqfSCk#Public-communications)
Beyond organising the project internally, we also wanted to communicate clearly to both a general public and a more technical audience what it is exactly that we are doing. We wanted to build up an online community infrastructure, so that we could invite people to join the discussion and stay informed.
Beyond organising the project internally, we also wanted to communicate clearly to two groups: a general public and democratic tech collectives.
We wanted to build up an online community infrastructure, so that we could invite people to join the discussion and stay informed.
We've managed to run our public communication through several mediums:
@ -159,7 +177,7 @@ We've managed to run our public communication through several mediums:
## Beta :point_right: :question:
As the public beta is now in effect, we are focusing on the following:
As the public beta is now in effect, we are generally interested in the following focuses:
- Making time to welcome new folks into the project.
@ -181,7 +199,7 @@ We feel it is important to emphasise that funding democratic technology collecti
All our work is copyleft licensed and made open and available as a digital configuration commons for others to re-use and build upon. ["Code paid by the people should be available to the people!"](https://publiccode.eu/)
Furthermore, our governance and organising models are open & for voluntary participation following the spirit of [the co-operative principles](https://www.ica.coop/en/cooperatives/cooperative-identity), so we are also building our social & political commons.
Furthermore, our governance and organising models are open & for voluntary participation, following the spirit of [the co-operative principles](https://www.ica.coop/en/cooperatives/cooperative-identity). So we also focus on building our social and political commons.
As members of [Autonomic](https://autonomic.zone/), the idea of Co-op Cloud was rooted in our practical needs. We needed a democratically organised digital infrastructure project we could rely on. However, more than that, the project was also conceived as a way to put into practice our anti-capitalist politics. We still see Co-op Cloud as a way other collectives can organise to dismantle "Big Tech" today.
@ -189,8 +207,8 @@ As members of [Autonomic](https://autonomic.zone/), the idea of Co-op Cloud was
We'd love to see more folks [get involved](https://docs.coopcloud.tech/get-involved/) :tada:
If you're thinking about setting up a technology co-op, you have a software stack sitting around waiting for you to pick up now. We have the technology. It's built by tech co-ops for tech co-ops.
If you're thinking about setting up a technology co-op, you have a software stack sitting around waiting for you to pick up now. We have the technology. It's built by tech co-ops for tech co-ops. If you're curious but don't know where to start, [get in touch](https://docs.coopcloud.tech/intro/contact/) anyway!
We even have [these amazing flyers](/pdf/flyercoopcloud.pdf) now! Print, distribute, share, spread the word :trumpet:
We even have [these amazing flyers](/pdf/flyercoopcloud.pdf) now (massive thanks to `@analuisa`)! Print, distribute, share, spread the word :trumpet:
:v: