Added the container index to the network-compute-ports trigger

[fomojola]

Useful for alternative proxy implementations. Updated the documentation for the network-compute-ports trigger to clarify the arguments

For alternate proxy implementations, the network-compute-ports trigger in the local docker scheduler allows for individual port mappings for each container instance. This PR adds the container index to the trigger (so an independent index of port mappings to container index can easily be maintained) and updates the documentation of the trigger to match (also, the documentation was missing a couple of arguments).

[josegonzalez]

Why would the container index be useful? Can you give me an example of an alternative proxy implementation that would use this?

[fomojola]

@josegonzalez I'm working on an alternate Haproxy proxy implementation: instead of regenerating the config file I'm using the Haproxy Runtime API (https://cbonte.github.io/haproxy-dconv/2.2/management.html) to link one of a number of backend servers to each of the Docker instances launched by the scheduler on each re-deploy. For each dokku app, I create a backend that looks like this:

backend ${APP}-backend
    mode http

    http-request track-sc0 src table st_src_global

    http-request set-header Host ${HOSTNAME}
    http-request replace-path /app/(.*) /\1
    option forwardfor
    option http-server-close
    server-template ${APP}-server- 1-1000 10.128.0.42:10000  maxconn 10 disabled

This starts up and instructs Haproxy to instantiate 100 servers inside that backend, all disabled. Whenever the scheduler is starting a new set of docker instances the proxy implementation does the following:

1. In the network-compute-ports trigger I proxy the port for each of the web process containers (by adding a unique -p : port mapping) and I store that mapping (so I know that container X has container port Y mapped to host port Z).
2. In the post-deploy trigger, I convert that mapping into instructions to feed to the Haproxy Runtime API that will enable/disable the appropriate set of Haproxy servers inside the Haproxy backend that maps to the APP (which I have as a parameter to the post-deploy trigger) as well as adjust the IP and port for each Haproxy server to link it to a specific container (so Haproxy server-X has its IP and port set to the appropriate host IP and port Z).

The container index makes it straightforward: ${APP}-server-${CONTAINER_INDEX} maps to the appropriate container, and I can disable all the other Haproxy backend servers that aren't in use (for example when a scale command reduces the number of containers of an app called v1 from 2 to 1, I can disable v1-server-2). I could introduce an alternate indexing scheme, but since one is already in use, I figured it would make the most sense to use it.

It works pretty well for the Docker Local Scheduler: Haproxy handles it seamlessly, and there's no rebuilding the config file. The only wrinkle is that I can't use zero-downtime deployment checks because the network-get-port trigger doesn't let me substitute the port properly, but I'm working on that.

[josegonzalez]

Thats pretty smart, if different from what I'd imagined. What would be needed for this to handle zero downtime checks?

[fomojola]

The only issue I'm having with zero downtime checks right now is that (at least for the docker local scheduler), this set of calls:

ipaddr=$(plugn trigger network-get-ipaddr "$APP" "$PROC_TYPE" "$cid") port=$(plugn trigger network-get-port "$APP" "$PROC_TYPE" "$cid" "$DOKKU_HEROKUISH")

at https://github.com/dokku/dokku/blob/master/plugins/scheduler-docker-local/scheduler-deploy#L117-L118 don't allow me to overwrite the port. So for example, if I implement that trigger in my proxy plugin and return the docker port mapping I get my port tacked on to the end of the internal port. So I see something like this for the host/port mapping (I decorated my local implementation with extra dokku_log_warn lines so I could get additional color on what was going on inside):

-----> Attempting pre-flight checks (web.1)
! [172.17.0.15][80
8211]

My port (8211) has been tacked on to the default port returned by the network-get-port trigger (80). Then the preflight checks fail because when it builds the curl request I see this:

CHECKS expected result:
CURL ARGS: -q --compressed --fail --location --noproxy 172.17.0.15 --max-time 10 -vv http://172.17.0.15:80
8211/ready.txt

My expectation is I'm doing something wrong here (just not sure what): this was my first plugin attempt and I was in a hurry as I'm vigorously defending against a much smarter person than me who wants to adopt Kubernetes, and that is a rabbit hole I'm desperate to avoid. Once this is cleaned up and documented would love to have the entire plugin released and available, along with the HAPROXY configuration parts.

Only took me a day from start to finish: I've been immensely pleased with Dokku. I am currently mapping out how to replace my home-grown deployment system across 20 servers with a single Dokku master. All I think I need is to figure out a plugin to publish the Docker images to a private registry, and then work through the Nomad scheduler config (it is missing a couple of the triggers that the local docker scheduler has, so might take a bit more of a slog) and I should be golden.

Thanks!

[josegonzalez]

Checkout the dokku-registry plugin for pushing images.

Re: the port issue, is network-compute-ports returning port 80 for your app? What is returning 8211?

I'd be happy to help chat in slack on this to come up with a solution, I'm personally a huge fan of Nomad and would love to have good reasons to work on it :)

[fomojola]

Would love to hop on slack: when/where should I go?

[josegonzalez]

http://dokku.viewdocs.io/dokku/getting-started/where-to-get-help/ <-- helpful link :)