Connection to host errors with stack test/repl and docker

[simon-nicholls]

Whilst stack exec is able to connect back to my host DB when docker is enabled, stack test and stack repl give a connection refused error.

Steps to reproduce

Have an integration test using a database connection.
Setup stack.yaml:

docker:
  enable: true
  run-args: ["--net=bridge", "--publish=8000:8000"]

Run command stack test.

Expected

I expected the tests to pass, as they do when running locally with stack --no-docker test.

Actual

I see errors of type uncaught exception: IOException of type NoSuchThing (connect: does not exist (Connection refused)).

Here's the underlying docker create command:

2017-01-31 11:18:53.737621: [debug] Process finished in 211ms: /usr/local/bin/docker create --net=host -e STACK_IN_CONTAINER=1 -e STACK_ROOT=/Users/Si/.stack -e STACK_PLATFORM_VARIANT=dkda49f7ca9b244180d3cfb1987cbc9743 -e HOME=/Users/Si/Source/Boutique/pster/.stack-work/docker/_home -e PATH=/opt/host/bin:/Users/Si/Source/Boutique/pster/.stack-work/docker/_home/.local/bin:/opt/host/bin:/opt/stackage/lts-7/extra/bin:/opt/stackage/lts-7/ghc/bin:/opt/stackage/lts-7/tools/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin -e PWD=/Users/Si/Source/Boutique/pster -v /Users/Si:/Users/Si -v /Users/Si/.stack:/Users/Si/.stack -v /Users/Si/Source/Boutique/pster:/Users/Si/Source/Boutique/pster -v /Users/Si/Source/Boutique/pster/.stack-work/docker/_home:/Users/Si/Source/Boutique/pster/.stack-work/docker/_home -w /Users/Si/Source/Boutique/pster -e USER=Si -e SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.6I7TrhRSAn/Listeners -v /private/tmp/com.apple.launchd.6I7TrhRSAn/Listeners:/private/tmp/com.apple.launchd.6I7TrhRSAn/Listeners -v /Users/Si/.stack/programs/x86_64-linux/stack-1.3.2/stack:/opt/host/bin/stack -t -i --net=bridge --publish=8000:8000 fpco/stack-build:lts-7.18 /opt/host/bin/stack --internal-re-exec-version=1.3.2 --internal-docker-entrypoint "DockerEntrypoint {deUser = Just (DockerUser {duUid = 1001, duGid = 20, duGroups = [20,1001,401,12,61,79,80,81,98,33,100,204,395,398,399], duUmask = 18})}" test :spec --verbose

Stack version

Version 1.3.2 x86_64 hpack-0.15.0

Method of installation

Homebrew install.

Other versions

Docker: Version 1.13.0 (15072)
Docker image: fpco/stack-build:lts-7.18
OS: macOS Sierra
DB: MongoDB v3.4.1 using port 27017, bound to all interfaces.

[Blaisorblade]

I expected the tests to pass, as they do when running locally with stack --no-docker test.

That's not necessarily the correct expectation. Especially with --net=bridge or most other Docker networking options: the Docker container has a separate IP address and so on... Mongo might not be listening on the newly created interface, and surely wouldn't be reachable at the loopback address (which would work when not using Docker or when using --net=host).

Using --net=host (what stack apparently uses by default, judging from your logs), the Docker container would instead share the network stack with the host.

Recommended replacement: replace run-args: ["--net=bridge", "--publish=8000:8000"] by just run-args: ["--publish=8000:8000"]. If not, investigate with https://docs.docker.com/engine/reference/run/#/network-settings at hand.

BTW, the command is passing before --net=host and I'm not sure which one wins, but my first guess is that "--net=bridge" wins since usually the later option does.

Also, your "reproduction" isn't really self-contained enough to try this out. There might be a million reasons the problem happens.

[Blaisorblade]

Closing for now, just to avoid leaving it open in case nothing happens. However, please reopen or comment if I turn out to be wrong, troubleshooting suggests further issues, or if the Stack documentation could be improved.

[simon-nicholls]

Those Stack Docker settings allow stack exec to work with the DB, so I would expect stack test to work too, if the tests themselves pass when run outside of Docker use.

I've used --net=bridge due to the macOS issue detailed here: #2455

[Blaisorblade]

Oh I see you're on Mac. So Docker is creating containers inside a separate Linux virtual machine.

Still, not enough logs to troubleshoot this, nor a reproduction. In particular, it's far from clear stack exec uses a container in this case. Please include --verbose logs for relevant operations.

Also: what kind of IP is being used to connect to the database?

I'm reopening for further investigation, but I'm still not sure stack can do much.

[simon-nicholls]

Coming back to this particular project, I find the database is being connected to. I'm going to put it down to an unforeseen consequence of unrelated system noodling for other work.

To round out the information for posterity, stack exec uses a container just fine for this bridge setup, allowing web access on port 8000. I connect to the DB using 192.168.1.100 - a DHCP reserved IP address - which can then be used with or without Docker as long as the DB is bound to all interfaces.

I still have errors for those integration tests when run via Docker, but I anticipate those to be something for me to deal with, and I'll close this issue.

Thx for your help, @Blaisorblade