Docker Community Forums

Share and learn in the Docker community.

Docker failing to correctly process valid yaml config?

(Nate Finch) #1

I’m trying to deploy Discourse, which uses a docker container. My app.yaml was produced using the Go yaml parser but I get this error when I try to start the container:

Invalid containerPort: 8000520

Here’s my app.yml:

Note that the strings aren’t quoted, but that’s still valid yaml. Anyone have a clue what’s going on?

(Sven Dowideit) #2

app.yml isn’t a Docker cfg file - perhaps you’re after Discourse support?

(Nate Finch) #3

Hmm ok, thanks. I'm new to docker so didn't realize that file was specific to discourse.

(Nate Finch) #4

Just for posterity, I’ll post my resolution here:

I figured it out, partially through using online validators that were changing the second exposed port from 2222:22 into 133342

It didn’t have anything to do with the lack of spaces before the dashes for the array (though I had several people mention that).

Here’s some trivia, that may help if someone else hits this (which is not beyond possibility):

YAML 1.1 defines what they call a “base 60 float” of the form 12:34:56.90 so it’s basically like hours, minutes, seconds, fractional seconds. But it means that if you happen to be using unquoted strings that happen to only have numbers and colons in them… yaml parsers will assume they’re a float, not a string.

So here’s what was happening: the ruby parser sees 80:80 and realizes that :80 cannot be base 60 (only the first number can be over 60) and so then falls back to it being a string. But it sees 2222:22 and says, right, ok, so that’s like 2222 minutes and 22 seconds, and so thinks it’s 2222*60+22 = 133342 seconds, and thus, that’s what it gets converted into. How that causes discourse/docker to think the port is 8000520, I may never know… probably multiple levels of implicit conversions in wacky and weird ways.

But just in case you ever see anyone with unquoted strings listed for their ports… beware if the port on the right is lower than 60, yaml will assume the whole thing is a float.

The reason the Go parser was fine with this is that it specifically does not support base 60 floats, at least in part because they were eliminated in the yaml 1.2 spec.

(Sven Dowideit) #5

wow. thank you very much for the update!

(Nate Finch) #6

Hmm ok, thanks. I’m new to docker so didn’t realize that file was specific
to discourse.

(Sven Dowideit) #7

wow. thank you very much for the update!

(Phillip Green II) #8

I was just recently bitten by this same problem and I wanted to follow up with the solution. To prevent the parser from interpreting 2222:20 as base 60, wrap it with double quotes so it is interpreted as a string.


  • 2222:22
  • “2222:22”

(Nate Finch) #9

Follow up - the go yaml parser has since been updated to make sure to put quotes around strings that could be misinterpreted as base 60, so this should never happen with yaml generated from go code… but still very possible with handwritten yaml (and possibly other parsers that aren’t 100% correct).