- The Netherlands
- https://d1.hackers.moe
- Joined on
2020-03-23 -
-
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...
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