Why HAProxy about next.filmfest.by HOT 2 CLOSED

@abitrolly

So I've been working on deploy and pipeline recently. My current goal is to enable automatic updates in production.

Some arguments

• we don't use Nginx anywhere today (there is production.yml, but it isn't used anymore)
• I tried to fit Nginx into my deployment scheme, but I couldn't
  • what I needed was upstream reconfiguration in runtime, but that's available only in Nginx+ (which is paid)
  • well, to be perfectly honest, I could live with Nginx, but that makes deployment pipeline more complicated without a real reason
• HAProxy and Nginx both work for our needs:
  • both can work as HTTP proxy
  • both protect worker pool from slow clients
  • both can do SSL termination

Why do I need upstream reconfiguration

So (Nginx|HAProxy) will act as an HTTP proxy. I want them to resolve app container via DNS name (instead of using IP addresses). However Nginx won't even start in this case - it performs DNS lookups at startup.

@nott, can we just use IP addresses?

Probably, yes (I haven't tried though)

@nott, if Nginx crashes at startup, can it just crash-loop until address can be resolved?

Probably, yes (well, changing IP address of app container will require manual restart of Nginx, but that still can be acceptable)

Instead of a conclusion

I don't have much experience with HAProxy too. But I can see this as a compromise for a simple (and I hope reliable) deployment scheme. You'll be able to review my PR anyway.

from next.filmfest.by.

we've switched to haproxy - we now use this haproxy.cfg

looks like haproxy is a better option for http proxy in dockerized environment these days because it can do dns resolving in run time

from next.filmfest.by.