Abra brainstorm - apps as templates, YAML front-ends for end-users #21

New Issue

decentral1se · 2020-09-27T07:12:18Z

decentral1se commented

2020-09-27 07:12:18 +00:00

Let's take wordpress for example. All names off the top of the head and don't care if we change them.

In the root of the wordpress repository, we'd add a package.yml and in this file, it will have a specification on what an end-user would need to provide to deploy the application. This is like the YunoHost manifest.json. That might look like:

---
name: wordpress
arguments:
  domain:
    ask: your domain
    example: foo.com
secrets:
  - db_passwd
  - db_root_passwd

(We'll need to think about this hard because it already feels like too much.)

End-users would then download abra and run something like abra new wordpress and they would then be asked a few questions, like, what is the domain name, database password (with option to random generate) and so on. Those questions would be generated from the package.yml.

After filling those in, abra would spit out a ~/.abra/my.wordpress.domain.yml with everything that end-user entered (secrets and all for the first iteration).

---
name: wordpress
domain: foo.com
secrets:
  db_passwd: foo
  db_root_passwd: bar

(Again, would need to think about it...)

abra would then clone the wordpress repository to ~/.abra/clones and using my.wordpress.domain.yml as the injection of values, deploy the wordpress application to a pre-configured swarm.

Whatcha reckon?

Let's take [wordpress](https://git.autonomic.zone/compose-stacks/wordpress) for example. All names off the top of the head and don't care if we change them. In the root of the wordpress repository, we'd add a `package.yml` and in this file, it will have a specification on what an end-user would need to provide to deploy the application. This is like the YunoHost [manifest.json](https://github.com/YunoHost-Apps/nextcloud_ynh/blob/testing/manifest.json). That might look like: ```yaml --- name: wordpress arguments: domain: ask: your domain example: foo.com secrets: - db_passwd - db_root_passwd ``` (We'll need to think about this hard because it already feels like too much.) End-users would then download `abra` and run something like `abra new wordpress` and they would then be asked a few questions, like, what is the domain name, database password (with option to random generate) and so on. Those questions would be generated from the `package.yml`. After filling those in, `abra` would spit out a `~/.abra/my.wordpress.domain.yml` with everything that end-user entered (secrets and all for the first iteration). ```yaml --- name: wordpress domain: foo.com secrets: db_passwd: foo db_root_passwd: bar ``` (Again, would need to think about it...) `abra` would then clone the [wordpress](https://git.autonomic.zone/compose-stacks/wordpress) repository to `~/.abra/clones` and using `my.wordpress.domain.yml` as the injection of values, deploy the wordpress application to a pre-configured swarm. Whatcha reckon?

❤️ 1

decentral1se added the

help wanted

question

labels 2020-09-27 07:12:18 +00:00

3wordchant commented

2020-09-27 10:51:08 +00:00

Yeah this is pretty much exactly what I was thinking 👌 Thanks for kicking this off! ♥ (I maybe imagined storing clone in ~/.cache/abra or ~/.local/src/abra but I'm not complaining if it's .abra).

In your mind does the .abra dir handle multiple DOCKER_CONTEXTs or would that need multiple .abra dirs?

(We’ll need to think about this hard because it already feels like too much.)

It doesn't feel massively too-heavy to me.

I guess unless we're specifying more about each secret (how to generate it, where to store it etc) then we could skip having secrets in package.yml and just read it like we do in stack-ssh-deploy using yq read compose.yml --printMode p 'secrets.*'.

Last thing, what about optional add-ons like Mediawiki SimpleSAML, Wordpress SMTP, etc?

Yeah this is pretty much exactly what I was thinking 👌 Thanks for kicking this off! ♥ (I maybe imagined storing clone in `~/.cache/abra` or `~/.local/src/abra` but I'm not complaining if it's `.abra`). In your mind does the `.abra` dir handle multiple `DOCKER_CONTEXT`s or would that need multiple `.abra` dirs? > (We’ll need to think about this hard because it already feels like too much.) It doesn't feel _massively_ too-heavy to me. I guess unless we're specifying more about each `secret` (how to generate it, where to store it etc) then we could skip having `secrets` in `package.yml` and just read it like we do in `stack-ssh-deploy` using `yq read compose.yml --printMode p 'secrets.*'`. Last thing, what about optional add-ons like Mediawiki SimpleSAML, Wordpress SMTP, etc?

decentral1se commented

2020-09-27 16:45:48 +00:00

Yeah this is pretty much exactly what I was thinking 👌 Thanks for kicking this off! ♥

🖤

In your mind does the .abra dir handle multiple DOCKER_CONTEXTs or would that need multiple .abra dirs?

Oh right, yes, I think we should handle those multiple contexts. So, maybe a ~/.abra/abra.yml in we store all the contexts (along with any other "CLI-wide settings) and they can be switched through. Then each context has a highlevel ~/.abra/mycontext and in each we do the env var yml files and the clones?

I guess unless we’re specifying more about each secret (how to generate it, where to store it etc) then we could skip having secrets in package.yml and just read it like we do in stack-ssh-deploy using yq read compose.yml --printMode p 'secrets.*'.

Thing is, Gitea has strict requirements on length of secret and also character set. That is a pain in the ass. Also Mysql root passwords are constrained. So, I think we need to have length for sure. We can default to only ASCII on the generation.

Last thing, what about optional add-ons like Mediawiki SimpleSAML, Wordpress SMTP, etc?

I think we should just have a config.d in the template repository and then abra ask some questions. We can add something like optional to the package.yml or something to thread through options on configuration?

I might try to pick this apart into issues. It feels like a good time to start it because we've got all our infrastructure lined up for good CI, so now thinking about end-user CLI/yaml interactions based on the rad abra work so far.

I might try to do this in Python (easier nice CLI things) and generate a single binary which can be used like the current bash version. Shout if any of this sounds not good.

Will need some guidance on not going galaxy brain and keeping things simple :)

> Yeah this is pretty much exactly what I was thinking 👌 Thanks for kicking this off! ♥ 🖤 > In your mind does the .abra dir handle multiple DOCKER_CONTEXTs or would that need multiple .abra dirs? Oh right, yes, I think we should handle those multiple contexts. So, maybe a `~/.abra/abra.yml` in we store all the contexts (along with any other "CLI-wide settings) and they can be switched through. Then each context has a highlevel `~/.abra/mycontext` and in each we do the env var yml files and the clones? > I guess unless we’re specifying more about each secret (how to generate it, where to store it etc) then we could skip having secrets in package.yml and just read it like we do in stack-ssh-deploy using yq read compose.yml --printMode p 'secrets.*'. Thing is, Gitea has strict requirements on length of secret and also character set. That is a pain in the ass. Also Mysql root passwords are constrained. So, I think we need to have length for sure. We can default to only ASCII on the generation. > Last thing, what about optional add-ons like Mediawiki SimpleSAML, Wordpress SMTP, etc? I think we should just have a `config.d` in the template repository and then `abra` ask some questions. We can add something like `optional` to the `package.yml` or something to thread through options on configuration? --- I might try to pick this apart into issues. It feels like a good time to start it because we've got all our infrastructure lined up for good CI, so now thinking about end-user CLI/yaml interactions based on the rad `abra` work so far. I might try to do this in Python (easier nice CLI things) and generate a single binary which can be used like the current bash version. Shout if any of this sounds not good. Will need some guidance on not going galaxy brain and keeping things simple :)

3wordchant commented

2020-09-27 17:46:23 +00:00

I might try to pick this apart into issues..

I might try to do this in Python (easier nice CLI things) and generate a single binary which can be used like the current bash version..

Yeah this sounds 🅰➕, let's do it!

So, I think we need to have length for sure. We can default to only ASCII on the generation.

Right, sure thing. So secrets.db_password.length etc.?

I think we should handle those multiple contexts. So, maybe a ~/.abra/abra.yml in we store all the contexts ..

Perfect! Or ~/.abra/hosts/<CONTEXT>/ for the envs and ~/.abra/stacks / .abra/clones for the compose-stacks? (I figured stacks might be shared between contexts?)

I think we should just have a config.d in the template repository and then abra ask some questions. We can add something like optional to the package.yml or something to thread through options on configuration?

OK yeah can't quite picture this as yet but either I'll see it if you try it or give it some more thought this week.

> I might try to pick this apart into issues.. > > I might try to do this in Python (easier nice CLI things) and generate a single binary which can be used like the current bash version.. Yeah this sounds 🅰➕, let's do it! > So, I think we need to have length for sure. We can default to only ASCII on the generation. Right, sure thing. So `secrets.db_password.length` etc.? > I think we should handle those multiple contexts. So, maybe a ~/.abra/abra.yml in we store all the contexts .. Perfect! Or `~/.abra/hosts/<CONTEXT>/` for the envs and `~/.abra/stacks` / `.abra/clones` for the `compose-stacks`? (I figured stacks might be shared between contexts?) > I think we should just have a config.d in the template repository and then abra ask some questions. We can add something like optional to the package.yml or something to thread through options on configuration? OK yeah can't quite picture this as yet but either I'll see it if you try it or give it some more thought this week.

👍 1 🎉 1 🚀 1

decentral1se commented

2020-09-27 20:53:39 +00:00

Ok, rad ideas, will break out into other tickets.

Thanks so much for thinking along!

Ok, rad ideas, will break out into other tickets. Thanks so much for thinking along!

decentral1se closed this issue

2020-09-27 20:53:40 +00:00

Sign in to join this conversation.

No Milestone

No project

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coop-cloud/organising#21