Nicolas De loof
Nicolas De loof
@hangyan yes indeed, just like `port` command can be used to obtain a public port binding, tool can make our life simpler with adequate commands :)
@mikesir87 imho canary or A/B deployement should not be expressed within a compose file, such deployment technique should better be used by Compose implementation on `compose up` for an existing...
@pchico83 quick question with your notation, how do you know which port enpoint1/api:8080 should be routed to, if service API has more than one port exposed?
ok, so we can't express port translation using this syntax, i.e. if I want publicly published port to be `443`, but my service expose `8080` and I expect the ingress...
The annotation you describe is exactly what we should hide behind adequate abstraction in the compose spec. i.e. by definition of my compose application, I'd like I can express "ssl-redirect",...
Related: https://github.com/docker/compose-spec/issues/22
This the terminology used by docker-compose. I don't have in mind a better noun to use here... As you said, most terms are used for various things by cloud providers.
related: https://github.com/compose-spec/compose-spec/issues/81
> I don't think there are plans to continue to move docker-compose forward with new features. There is, but we are still focussing on getting Compose 2 out (compose in...
yes indeed, sorry for the confusion. We definitively should have found a better name for "Compose v2". "Compose.Next"? "Compose.NewGen"? Naming things without ambiguity is one of the harder problem in...