Abra brainstorm - apps as templates, YAML front-ends for end-users #21
Labels
No Label
automation
bug
community organising
democracy
design
documentation
duplicate
enhancement
finance
funding
help wanted
invalid
publishing
question
security
wontfix
No Milestone
No project
No Assignees
2 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: coop-cloud/organising#21
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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:(We'll need to think about this hard because it already feels like too much.)
End-users would then download
abra
and run something likeabra 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 thepackage.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).(Again, would need to think about it...)
abra
would then clone the wordpress repository to~/.abra/clones
and usingmy.wordpress.domain.yml
as the injection of values, deploy the wordpress application to a pre-configured swarm.Whatcha reckon?
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 multipleDOCKER_CONTEXT
s or would that need multiple.abra
dirs?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 havingsecrets
inpackage.yml
and just read it like we do instack-ssh-deploy
usingyq read compose.yml --printMode p 'secrets.*'
.Last thing, what about optional add-ons like Mediawiki SimpleSAML, Wordpress SMTP, etc?
🖤
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?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.
I think we should just have a
config.d
in the template repository and thenabra
ask some questions. We can add something likeoptional
to thepackage.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 sounds 🅰➕, let's do it!
Right, sure thing. So
secrets.db_password.length
etc.?Perfect! Or
~/.abra/hosts/<CONTEXT>/
for the envs and~/.abra/stacks
/.abra/clones
for thecompose-stacks
? (I figured stacks might be shared between contexts?)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.
Ok, rad ideas, will break out into other tickets.
Thanks so much for thinking along!