9 ms·
Ask HN: A Better Docker Compose?
In docker compose you have a flat list of services and you manually weave them together with configuration.
Then in an effort to secure things you add on frontend/backend networks to isolate containers from each other.
services:
proxy:
build: ./proxy
networks:
- frontend
app:
build: ./app
networks:
- frontend
- backend
db:
image: mysql
networks:
- backend
You add config to share credentials between services.
services:
app:
build: ./app
environment:
DB_PASSWORD_FILE: /run/secrets/db_root_password
secrets:
- db_root_password
db:
image: mysql
environment:
MYSQL_ROOT_PASSWORD_FILE: /run/secrets/db_root_password
secrets:
- db_root_password
secrets:
db_root_password:
file: ./secrets/db_root_password.txt
Is there a way to abstract away these extra configuration steps and keep it simple yet secure by default?
If you would express db as a dependency/resource of app, could you infer that you could put it in a seperate network and have the credentials automatically link?
'As a developer' I'm not really interested in the network specifics or which credentials, I just want them to talk securely and minimize any attack vectors and keep any configuration to a minimum.
With tens of apps, their databases and transversal connections, how to do you keep the configuration to a minimum?
Googling around I found;
humanitec:
https://docs.humanitec.com/integrations/resource-types/mariadb
They express something as 'resources', a dependency type that can be provisioned automatically with inputs and outputs that then can be injected in the application env vars:
mysql://${externals.my-db.username}:${externals.my-db.password}@${externals.my-db.host}:${externals.my-db.port}/${externals.my-db.name}
you're limited to a limited set of drivers ofcourse and how would you express an app1 to app2 dependency?
juju:
https://juju.is/
Each app is packaged in a charm which seems to be a yaml declaring inputs, dependencies and other meta data and optional python code that can respond to certain lifecycle hooks
https://discourse.charmhub.io/t/implementing-relations/1051
name: my-node-app
...
requires:
database:
interface: mongodb
provides:
website:
interface: http
Things can seemingly be autowired based on what interface they provide and require?
So just make a list of apps until everything resolves?
Does anyone have experience with these tools or others like it?
How do you stop others and yourself from drowning in credentials, certificates, env vars, jvm params and k8s yaml(times every environment)
How do you do (not the configuration management) but manage an inventory of what configuration is needed to run your environment (or a subset for ci)?
- SpeedilyDamage 4y agoI'm not really sure what problem you're trying to solve here; if you want to follow DRY, there are YAML tricks you can use[0], but if you want docker-compose to "figure it all out" itself, I don't think there are a safe set of assumptions it could make to reliably meet your expectations. Also I'm not sure it really matters; again this would help to understand your question better, because I think you're trying to solve a problem that may not exist in your threat model. [0] https://medium.com/@kinghuang/docker-compose-anchors-aliases-extensions-a1e4105d70bd https://medium.com/@kinghuang/docker-compose-anchors-aliases...
- klysm 4y agoI find systemd works pretty well
- canadaduane 4y agoI'm curious if you run docker containers via systemd units? Or are you suggesting no docker?
- klysm 4y agoI use systemd to run the containers
- huimang 4y agoI solve the secrets problem by using ansible to provision the host system and build the compose file, and ansible-vault to handle the secrets. You can also dynamically build a compose file for example: export COMPOSE_FILE="$(ls -1 services/*/compose.yml | paste -sd ":" -)" In general I don’t have many issues with the docker-compose.yml format.
- mooreed 4y agoAt the risk of sounding clichè/unhelpful. > “you can solve every problem by adding or removing an abstraction layer” Have you considered generating your YAML/JSON config with something that composes? If you are open to it you might be interested in dhall [1] as it’s a config language with variables, functions and imports. I have used it for pet projects and I could see how it could offer some tidy encapsulation patterns for larger, more complicated production applications. [1]: https://dhall-lang.org/ https://dhall-lang.org/