Dokku: Support TLS termination for TCP services

[mappu]

Hi,

User story

I have a custom (Dockerfile) application that has a web interface (port 80), binary interface (ports 411/6667) and needs TLS versions of all three (ports 443/4111/6697).

I currently achieve this on a dedicated server with Let's Encrypt on 443, and an nginx configuration that reuses this certificate for 4111/6697. But I want to run the application under dokku so that it can better share 80/443 with other dokku apps.

Of the six ports above,

|.|.
|---|---
|80/443 web ports| :heavy_check_mark: Dokku is designed for web apps so this is easy + works well;
|411/6667 binary ports| :heavy_check_mark: TCP forwarding is available in recent Dokku versions with dokku docker-options:add my-app-name deploy "-p X:Y"
|4111/6697 TLS binary ports| :x: No solution

Discussion

Some things I tried:

• docker-options can't hook in to the existing TLS cert
• AFAICT the dokku proxy system can't help
• nginx can do TLS on TCP but nginx.conf.sigil is stuck inside a top-level http block, not a stream block

I think in my situation, the workaround is to just add custom nginx configuration on the host, outside the dokku ecosystem. My initial concern was for how to integrate TLS certificates with how dokku-letsencrypt is requesting them, but it seems like the /home/dokku/APP/tls/server.{crt,key} paths are pretty stable.

This ticket is somewhat similar to the WONTFIX https://github.com/dokku/dokku/issues/2662 but i'm not so worried about routing on these ports (TLS on binary services is pretty rare), just getting TLS working at all.

In that ticket:

The proxy protocol should support it just fine, as it's just scheme:host-port:container-port, so you could imagine tcp:1234:1234 being something that nginx "knows" how to route.

It would be great if a builtin solution could add tcp-tls:44443:1234 as well. Or something like that.

[weyert]

Can't make a custom nginx sigil template for this app which covers this?

[josegonzalez]

A custom nginx.conf.sigil template won't work because of where the file is being included.

While folks have asked for non-http load balancing in the past, the complications from needing to do this are... annoying enough for me to not want to do this for free. I'm also not terribly interested in working on it as the majority of our users won't need it.

I'm happy to take pull requests for the functionality, and would also be happy to show off a way you might implement this.

• If the tcp or tcp-tls schemes are detected, pull _just_ those out and create a /home/dokku/APP/tcp.conf file. See this for examples.
  
  
  
  • Remember that hostnames cant be used for tcp load balancing
  
  
• During nginx-vhosts plugin installation, create a /etc/nginx/tcp-conf.d folder
• During nginx-vhosts plugin installation, detect if the stream block exists in /etc/nginx/conf.d. If it doesn't, add a block and have it do include /etc/nginx/tcp-conf.d/*.conf;
• During nginx-vhosts plugin installation, within /etc/nginx/tcp-conf.d/dokku.conf, add the following line:
  include /home/dokku/*/nginx.conf;

The above plan _should_ work and would probably neatly fit into our existing nginx proxy plugin. I'd 100% take a pull request implementing the above (including docs of course!).

If any of the following apply:

• You don't have time to work on a PR for this.
• You don't feel comfortable enough working with bash/golang to implement this.
• You really want me to work on it.

Feel free to send me an email at my github email and I'm happy to provide consulting rates.

[weyert]

I am wondering if it would be a good idea to leave this ticket open so it's easily listed?

[josegonzalez]

I have a policy - maybe I should outline it... - of closing enhancement tickets that I don't personally think will be used by the majority of our users _or_ that I'm interested in. In this case, I think both are true (but again, I'll take a PR).

Note: from experience, keeping issues open if they aren't implemented gives people the idea that we either plan to implement it or aren't maintaining the project. I want to avoid that perception.