startNakadi not working (docker compose plus docker for mac)

[dehora]

From https://github.com/zalando/nakadi/issues/439#issuecomment-248659201

I've been having issues running Nakadi locally for some time now as well when using ./gradlew startNakadi.

I've had a similar experience since the project switched over to compose with v2 syntax.

From https://github.com/zalando/nakadi/pull/414#issuecomment-250667280 it seems this combination is known to be an issue:

docker for mac has a bug docker/docker#22753 and it event does not work for the current docker-compose file.

I understand the benefits to compose, but it's not ideal to exclude developers like this, especially those working on clients to support the project. Ideally it needs to be documented how to get up and running or that there are known problems with the project's current choice of docker configuration. In the meantime this can act as a covering ticket until it's fixed.

/ @adyach @dr4ke616 @kanuku @rcillo @valgog

[adyach]

@dehora as far as I understand the purpose of docker-compose was to address development process of Nakadi itself and unload gradle build file. I always thought that for the integration purposes it is better to use integration environment like sandbox or staging which is fully set up to the latest available version.

Also we mentioned in our README file how to start Nakadi especially for Mac OS: this and this Note: Docker for Mac OS (previously in beta) version 1.12 (1.12.0 or 1.12.1) currently is not supported due to the bug in networking host configuration Nakadi requires recent versions of docker and docker-compose. In particular, docker-compose >= v1.7.0

Nevertheless, I strongly believe we have to support our users to simplify integrations with Nakadi.

[dehora]

Ok, I've made some progress:

• remove docker for mac (1.12.1)
• install docker toolbox

and with that setup, docker-compose up -d --build will bring up a cluster.

The cluster functions within docker, but the 8080 port isn't forwarded to the host mac. That requires port forwarding via virtualbox:

and then startNakadi will stop spinning since the server is available:

A couple of things then:

If the project is not going to support anyone using docker for mac, then readme needs to be updated to provide clear instructions in one place (it's a big readme). Macs are super-common in Zalando (and in general), and the docker project leans towards telling people to use docker for mac rather than docker toolbox:

As an aside Confluent's docker repo has this warning as a headline item in its readme file:

I guess they've had a lot of people running into this. I think Nakadi needs something similar. I get that most people on this ticket will figure out the workaround, but I'm thinking of the next 100 developers that will end up banging their head against this.

The alternative is running all four subsytems in a single container. I know that's not idiomatic docker, and the project has deliberately moved anyway from it to single function containers, but the majority of people working with Nakadi just need something that comes up with minimal fuss. I understand going back to a monocontainer might not be an option. But either way, the documentation needs an update :)

[dehora]

@adyach @dr4ke616 @kanuku @rcillo @valgog I guess in conclusion then, a doc update and some animated howto gifs should be enough to address this for mac users and close the ticket.

[valgog]

Does not portmapping work?

[valgog]

@dehora I think it can still work in Docker for Mac

See docker-compose run --service-ports

Also https://docs.docker.com/compose/faq/#/whats-the-difference-between-up-run-and-start

It looks like one should not use docker-compose up for testing things.

Maybe would should put gradle into a container and run it from docker-compose with dependencies :D

[valgog]

@v-stepanov Slava, do you remember why we needed to pin the network type to host in docker-container?

[dehora]

Does not portmapping work?

In Docker for Mac, not via Kitematic's manual settings at least; port settings were not being preserved through the UI, nor were they present after running compose with its port declarations. Kitematic with docker toolbox has the same behaviour, here's what it looks like:

Ii'm guessing you'd can't edit them after the fact with this kind of compose setup - I hadn't seen this in Kitematic until yesterday. But editing port mappings via virtualbox works.

Also iirc, the nodes weren't finding each other using d4m never mind being accessible from the host machine (I'd need to reinstall d4m to confirm that).

[valgog]

@dehora it looks like there is not way to force docker-compose to perform up command and also map the ports :(

Another issue is that network_type: host seems to be not working in Docker for Mac

[cesarcneto]

Just wanted to emphasize @dehora 's issue.

I have just run through all these issues mentioned here. Mainly because I followed README without checking issues -- yes, shame on me :) -- and, in the end, I just removed network_type: declaration from docker-compose.yml (which defaults to bridge) and used docker-compose up.

Since Nakadi is already open sourced, maybe you guys could think of having a docker-compose-dev.yml file to make the development process easier, like this docker-compose.txt, and update the README as well :)

I would say that it could considered part of the PR #414 scope. What you guys think?

[lmontrieux]

This is related to #413, and as @cesarcneto mentions, should be part of the PR #414 scope. I'm closing this to refocus the discussion in a single issue.