On-going notes and scratchpad #2

New Issue

decentral1se · 2020-06-25T11:02:21Z

decentral1se commented

2020-06-25 11:02:21 +00:00

An open issue to track my thinking as I go along.

decentral1se commented

2020-06-25 11:06:12 +00:00

Current situation is that:

I've got a lot of configuration at https://git.autonomic.zone/compose-stacks which are made up of 1. a compose.yml file and 2. a .envrc and you basically just load a bunch of env vars into your command-line and then run docker stack deploy -c compose.yml mystackname
A bunch of those configs copy/pasta'd into https://git.autonomic.zone/autonomic-cooperative/?tab=&sort=recentupdate&q=.zone where I just removed all the env vars because I guess it will confuse anyone working with them.

Thinking now is that with all these configs, it is hard to keep them in sync. I don't quite know how to make a "single source of truth" for, say, the gitea compose.yml definition and then re-use that. Also, it is not clear how to make that configurable, for example, using postgresql instead of mariadb. Just to get things moving, I copy/pasta'd the configs so that we can make use of the services at Autonomic.

However, I'm going to let this sit and see if I can take a step back and think through some sort of super lightweight configuration layer that sits in front of the compose.yml and generates it? Or configures it? Orrrrrr, I don't know. But something to make 1. the maintenance efforts less 2. make it easy to understand how this all works 3. make it easy to make your own compose.yml app packages

Current situation is that: 1. I've got a lot of configuration at https://git.autonomic.zone/compose-stacks which are made up of 1. a compose.yml file and 2. a .envrc and you basically just load a bunch of env vars into your command-line and then run `docker stack deploy -c compose.yml mystackname` 2. A bunch of those configs copy/pasta'd into https://git.autonomic.zone/autonomic-cooperative/?tab=&sort=recentupdate&q=.zone where I just removed all the env vars because I guess it will confuse anyone working with them. Thinking now is that with all these configs, it is hard to keep them in sync. I don't quite know how to make a "single source of truth" for, say, the gitea compose.yml definition and then re-use that. Also, it is not clear how to make that configurable, for example, using postgresql instead of mariadb. Just to get things moving, I copy/pasta'd the configs so that we can make use of the services at Autonomic. However, I'm going to let this sit and see if I can take a step back and think through some sort of super lightweight configuration layer that sits in front of the compose.yml and generates it? Or configures it? Orrrrrr, I don't know. But something to make 1. the maintenance efforts less 2. make it easy to understand how this all works 3. make it easy to make your own compose.yml app packages

decentral1se commented

2020-06-25 11:07:38 +00:00

Another thought on https://git.autonomic.zone/autonomic-cooperative/?q=.zone&sort=recentupdate&tab= is that it is really specific to having Drone CI running for all the deployments (you need that extra infra) and separating it into its own repository for each app is a little bit of overkill (or feels like). So, wonder how it could become a monorepo and still have this "if you push a commit, it auto-deploys" mode of operating...

3wordchant referenced this issue

2020-09-05 00:07:12 +00:00

Monorepo / MagicApp: solving per-instance configuration #3

decentral1se commented

2020-09-05 15:59:50 +00:00

I suppose I'll close this off since not using it.

Seems to have served some sort of purpose in the linked issue!

I suppose I'll close this off since not using it. Seems to have served some sort of purpose in the linked issue!

decentral1se closed this issue

2020-09-05 15:59:50 +00:00

3wordchant referenced this issue

2022-11-05 14:40:48 +00:00