Containers and cloud deployments are made for each other. Using say, a Docker configuration file, you can pass that off to a cloud host, and get an environment whipped up in a declarative fashion without having to worry about all the ugly details of exactly how that happens. With tools like Docker’s Compose, you can spin up many components all in one big, declarative YAML block.
Or can you? Ricardo P was running into problems with deploying to the cloud. Specifically, when deploying to Azure, he got this error message: Linux Version is too long. It cannot be more than 4000 characters.
That’s such an odd message, and when Ricardo started digging around, it wasn’t really easy to see what it was referring to when it was talking about “Linux Version”.
But Ricardo wasn’t the only one with this problem, but the root cause is… surprising.
The Azure configuration stores a Base–64 encoded version of the docker-compose.yml
file in a field called linuxFxVersion
. An “artifact” of their storage system caps the size of that data to 4,000 bytes. Why is that field name holding that data? It’s unclear, and certainly leads to unclear error messages.
But there are other odd quirks. The Base–64 encoded version isn’t content aware- it encodes all of the text. Did you include comments in your compose file? Well, be ready, to count those against your filesize limit. Plus the Base–64 encoding makes the content even larger- folks would cut down their filesizes only to discover that they still blew out the upper limit.
This is clearly a situation where an existing field was adapted to a new purpose, but isn’t actually fit for that purpose. An ugly hack that got out into the wild, and probably can’t be reined back in, because every change breaks someone’s workflow. So now it lives on: breaking deployments, unable to be deprecated, the fix tied up in internal teams that have higher priorities, and making sure that one single forum thread gets lots and lots of hits.