Research on all relevant deployment technologies (DevOps) for Onion Services: build a first matrix of technologies, recipes and strategies, incorporating it into the specs (#40).
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
This is a comprehensible yet incomplete list of deployment tools for Onion
Services.
It covers some of the most relevant tools to be considered.
Projects that were too basic or evidently unmaintained were removed from the
result set.
During conversations with @anarcat and @hiro, initial conclusion was:
To narrow down implementations to Ansible (low requirements, only Python and
SSH; popularity).
But if I understood correctly, also consider Terraform (which is able to
handle infrastructure deployment). @irl also pointed some advantages of
using Terraform when deployng to AWS and CloudFront.
Puppet should not be considered initially, given the centralized architecture
it uses.
To clarify how we're using Terraform right now, we're deploying EC2 instances and then generating the Ansible inventory from the AWS EC2 metadata. We don't yet have modules for generating keys or any of the other cool things to make it cloud native. Ansible is deploying EOTK, which consists of just copying the keys (onion + ssl server certs) and templating an EOTK configuration file.
Related to a more general "DevOps" stack, @anarcat sent me this: Towards a Modular DevOps Stack - DEV Community. I'm not sure this is the way to go right now, but it's worth gathering these kind of references as well.
I've read OnionGroove spec and found it very interesting. While my project already tackles some of these ideas (agnostic deployment, frontend/backend via ingress, scalability, monitoring) using the k8s's operator approach, I still need to implement vanguards and hopefully provide users a set of sane defaults for their onion services.
I have some questions:
Question #1 with re signaling and coordination/maintenance activities:
E.g, when implementing vanguards for onion balance a state file have to be replicated to the backend instance. In k8s I can use an object storage service, message queue os k8's API itself to distribute and signal other nodes (although this will be limited to the local cluster). Would OG provide some sort of daemon to coordinate such activities among the instance members?
Question #2 regarding providers
Is it intended for each platform provider to parse oniongroove project files/structure and adapt it to the target platform? Are providers part of the scope of the OnionGroove project or shall they be created outside it?
I've read OnionGroove spec and found it very interesting.
Thanks! I really appreciate feedback, especially from those that are developing Onion Service deployment tools.
While my project already tackles some of these ideas (agnostic deployment, frontend/backend via ingress, scalability, monitoring) using the k8s's operator approach, I still need to implement vanguards and hopefully provide users a set of sane defaults for their onion services.
Would OG provide some sort of daemon to coordinate such activities among the instance members?
That's a very important question!
I'm inclined to say that Oniongroove should not try to enforce a standard way to do this, since this might conflict to each tool/library way to manage state/content/files/etc across nodes. I simply could not found any reason to standardize this.
I think Oniongroove as a tool that's stays in a higher level of abstraction, where operators define providers, Onion Services and their overall behavior, while each implementor (k8s, Ansible, Terraform etc) have it's own business logic to ensure the desired state is applied in the nodes.
Is it intended for each platform provider to parse oniongroove project files/structure and adapt it to the target platform? Are providers part of the scope of the OnionGroove project or shall they be created outside it?
The spec is still unfinished and needs a feedback, ideas and suggestions. That said, initially the idea is that Oniongroove is responsible to parse it's configuration and adapt to each target platform format, using the "separation of concerns" design principle and to centralize this stage in a central place. So Oniongroove could have separate "modules" to do the translation for each implementor. But maybe there are reasons to consider a different approach :)