Closed khuey closed 4 years ago
As I've previously mentioned, environment variable interpolation in cage
has really poorly-defined semantics, and it should almost always be replaced with pods/targets/$TARGET/common.env
variables instead. The core problem is that sometimes people want cage
to interpolate, and sometimes they want docker-compose
to interpolate, and sometimes cage
computes new values based on existing values (because cage
is basically just pipeline processor for transforming docker-compose.yml
files in various ways). So you inevitably end up with a nasty mismatch of things interpolated at cage
time and things interpolated at docker-compose
time.
As far as I can tell, the only workable long-term solution is to completely forbid environment variable interpolation in cage
. There may be another solution, but I don't see it right now.
What I would need to reconsider: A rigorous, well-defined solution to how interpolation should work, that:
cage
full access to any field.I'm also open to solutions about improving pods/targets
to handle new use cases. But I don't think it's a good idea to try to address these individual issues in an ad hoc fashion, because we'll just keep running into them every other week, and there will be no actual solution other than to add increasing numbers of dubious hacks. And we know from bitter experience with the original Ruby version of cage
that adding dubious hacks is very tempting and that it will end very badly. :-(
I think that ports should probably be retrieved from the docker daemon rather than reinterpolating the yaml.
Hello! cage
was very minimally maintained for several years, and I'm sorting through old issues. I'm going to go ahead and close this issue for inactivity, but please feel free to reopen it if anybody is still interested.
This will fail to print out a status entry for the container with
Error: cannot parse without interpolating environment variables '$PORT:80'