Closed astromechza closed 2 months ago
I think the second example is far more compelling and generalisable. However my one concern is about how we publish resource service ports, such as mysql/postgres/etc if they have unique names associated with them.
We probably want to use a resource output to indicate what we want to publish when executing generate
. For example:
To publish a workload port that is normally intended to be internal and doesn't have a dns/route. We just indicate the workload-name. The port can either be an exact port or it can be the name of a Score service exposed by that workload.
--publish 8080:workload-name:80
To publish a resource port, eg a mysql or postgres DB port:
--publish 5432:TYPE.CLASS#ID.host:TYPE.CLASS#ID.port
Both of these options effectively convert into a HOST_PORT, COMPOSE_SERVICE, CONTAINER_PORT tuple which are injected into the final compose yaml as an override to services.COMPOSE_SERVICE.ports[]
Score currently supports the notion of a service port like:
Now generally this is an indicator that this particular port should be exposed to other services within the same network, but crucially not to external routes outside the network. That's generally what the route and dns resource types are for.
However, when using score-compose, there's often a need to test a service which just exposes a service port. The current mechanism is to write a companion compose file which can be interpreted together with the
compose.yaml
thatscore-compose
generates, and use this to override the published ports of the service.However, it would be much more clean if we had an easier way to just indicate - expose this service port. This could be done through annotations like we use in certain provisioners, or as a CLI argument to score compose itself.
Eg 1:
Eg 2:
What are folks thoughts?