Can we list the udp and tcp ports separately? And pass them in somehow to the enabled proxy plugin. That way the plugin can do as it wants.

I think we disable the proxy plugin and treat it like a background app for our nginx implementation. Nothing else we can do anyhow.

@josegonzalez I'm not clear on the context of your two sections there. Can you clarify please?

if we see a dockerfile with udp port exposures, do we automatically disable proxy or do we just leave it to the user?

Ah ok. Haven't even touched dockerfile stuff yet but I play around with some test deploys and report back.

Disable the proxy == no zero-downtime. Ports just change. Want a light-weight way of having the same ports without the overhead of nginx or haproxy? Create a proxy plugin that does it via iptables.

I don't particularly like the idea of:

• check if new container passes checks.
• turn off all existing containers.
• start the new ones.

Sounds risky, people will complain that their apps don't work, and will be a mess to keep track of.

I mean it was a "feature" of dokku years ago if there was port collision, the old container was simply shut down first. But I'll defer to you guys since I don't utilize the use case, so I have not vested interest.

Do you have docs for that feature?

Fixed get_app_urls() for non-proxied dockerfile apps with exposed ports.

This dockerfile

FROM node:4

EXPOSE 3001/udp
EXPOSE  3000/tcp
EXPOSE 3003

COPY . /app
WORKDIR /app
RUN npm install

CMD npm start

Yields these URLS:

dokku.me:32779->3000/tcp (container)
dokku.me:32773->3001/udp (container)
dokku.me:32778->3003/tcp (container)

Please let me know if I missed anything here

Do you have docs for that feature?

you have to go way back! like here:

I'll poke around more today.

@josegonzalez I'd like to drop the custom template path variable and support it similarly to how we handle the Procfile in #1915

What do you mean?

Meaning we'll search for it in /app or WORKDIR (only in the case of dockerfile apps of course)

I don't like the additional complexity it adds and we don't support this anywhere else. Additionally there is a community plugin to help store your "dokku-isms" in a subfolder and move them appropriately at deploy time.

https://github.com/mikexstudios/dokku-app-configfiles

Fine by me, just document it.

Ah! That plugin is out of date but the point still stands about additional complexity and it being the only place we support this sort of custom pathing. Feels janky.

@josegonzalez I'll need @pmclanahans's changes to copy_from_image

Time to break any installs of master!

@sseemayer This is maybe interesting for the Let's encrypt plugin. I guess the plugin should be ported to the new templating.