First Post

Introduction

For quite a while now I wanted to start some kind of creative outlet for thoughts. No idea how well this will go, but here we are.

I had the domain afoch.net for a while now, and barely used it. The name afoch.net is German dialect for “just don’t”.

What will this blog about? No idea, but “things I wish I had found a blogpost about earlier” seems like a reasonable choice.

The Thing I wish I had found a blogpost about earlier

Hugo starts a webserver for having that WYSIWYG experience. Usability wise this is very convenient and reduces friction. Immediate feedback when typing, with little to no guesswork on how to do display the content. A great feature. The problem starts when - like me - you have been bitten by dependency and dependencies dependencies getting picked up by other projects too often. Out of necessity I decided to learn docker to separate runtime dependencies. Very quickly this ballooned into having toolchains only in docker containers and Makefiles starting containers, invoking the same Makefile - this time from within the container - getting invoked to produce an executable. Yes the overhead was enromous, but I have built my ivory tower to be safe from the dangers annoyances of dependency hell and was happy up there.

I was so happy up there that I would do all this even for an application written in Go.

Which by default produces static binaries.

Which do not pull in some shared object from somewhere to resolve its symbols.

Which resolve dependency hell during build time.

Yes, putting the hugo runtime in its own container to render Markdown to HTML is overkill questionable quite possibly a stupid idea an academic exercise.

Anyway…

When starting the hugo webserver it happily reports which URL it is reachable from. Opening the URL in a browser yields ERR_CONNECTION_RESET. Huh? Surprising. Checking commandline for typos and mixups yielded nothing obvious. Inspecting the docker container using docker inspect hugo_container also showed the correct port mapping and expected network mode. Docker recognizes the port mapping correctly. Isolating a webserver from the host is a standard usecase for docker. This should, and has in the past, work out of the box. No fenagling of iptables required. Something other must block traffic between host and container.

Is the webserver running at all? Yes. docker exec -it into the container and asking for network statistics clearly shows a listening connection on the correct IP address by the correct program.

But is the host side listening on the connection? Yes. Hrm. Docker does not seem to be the problem here. From the browsers error it looks like the application does not even receive the request. Must be some interaction between host and port network from dockers point of view and how it binds to a port.

Sure enough, in the getting started guide of docker there is an explanation what is happening:

Binding to 127.0.0.1 only exposes a container’s ports to the loopback interface.

Binding to 0.0.0.0, however, exposes the container’s port on all interfaces of the host, making it available to the outside world.

And sure enough, by invoking hugo with --bind "0.0.0.0" the webserver in the container is now reachable from the host. This changes the output netstat produces in the container to:

Why tho?

When binding to 127.0.0.1, the application binds to the containers loopback interface, which is different to the hosts loopback interface. The loopback interface is used for network traffic originating from and destined to the same machine. As far as the containers OS is concerned, the host OS is another machine. The application would listen to traffic from within the container, not from outside.

Why would the port be listed as LISTENING on the host then? Because Docker was still listening on the port, since it got mapped to 127.0.0.1:1313 on the host. The container behind did not have any application listening tho, which results in a ERR_CONNECTION_RESET error in the browser.

• Docker