Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Opportunities to enhance demo #1

Open
ryanrussell opened this issue May 17, 2020 · 5 comments
Open

Opportunities to enhance demo #1

ryanrussell opened this issue May 17, 2020 · 5 comments

Comments

@ryanrussell
Copy link

ryanrussell commented May 17, 2020

Cool Concept.

There are a lot of examples of these around the web, but a single REPO with various use cases implemented in each proxy could save people a lot of headache.

Some use case examples that would be nice for each proxy:

  • Deploy to docker/docker-compose/swarm/kubernetes commands
  • example of www/non-www redirect each way with 301 for non-canonical
  • Managing https certs with LetsEncrypt
  • multi-domain setup examples for each proxy
  • examples of how to route a redirect in each proxy engine. If you need to have a 301 from old.html -> /new/, a functional example for each would be really helpful. A wildcard example would be even more illustrative.
  • Be clear on which versions are supported. Traefik 1.7 vs 2 are different syntax, this could confuse new users.

I hope you continue to build this repo out!

@azrikahar
Copy link
Owner

azrikahar commented May 17, 2020

There are a lot of examples of these around the web, but a single REPO with various use cases implemented in each proxy could save people a lot of headache.

Yes this is true. Had to piece together a lot of sources when trying to learn each of the reverse proxies here and perhaps some of the gatchas in each of them.

Deploy to docker/docker-compose/swarm/kubernetes commands

Just out of curiosity, do you mean docker as in docker run commands? Can't deny I love docker-compose after using it, but you are right since it would allow people familiar with docker run commands to understand the docker compose file. That in turn achieve the aim of this repo which is learning through familiarity to transition further or another similar setup.

As for swarm and kubernetes, to be frank I just started to dip my toe into swarm mode haha. I do hope either someone else or me (when I learn it fully & kubernetes eventually) can give more input on these two.

Managing https certs with LetsEncrypt

This is what I planned to do next when there's just Caddy, nginx-proxy & Traefik! Now I just gotta make sure I understand it for HAProxy before adding this.

Be clear on which versions are supported. Traefik 1.7 vs 2 are different syntax, this could confuse new users.

This also bugged me earlier today. Definitely need to highlight this for Traefik, but I am also looking to set the versions explicitly for others as well since now all of them are using the latest tag. If there are major versions in future, it might break. Thanks again for highlighting this!


As for other suggestions, they are definitely good but I have to say as of now I still don't have experience doing those myself haha. I do hope I can add them in the future.

@mister2d
Copy link

For a reference of how HAProxy and Letsencrypt can be used together, take a look at the nmarus/haproxy-certbot Docker image.

@azrikahar
Copy link
Owner

For a reference of how HAProxy and Letsencrypt can be used together, take a look at the nmarus/haproxy-certbot Docker image.

I did look into it before, but sadly it seems like it's not updated anymore. However I did try to check out the forks and found this: https://github.com/bisand/docker-haproxy-certbot/blob/master/Dockerfile

It seems to be a fairly clean approach since it builds on top of the official HAProxy image and it's up-to-date. Docker hub link: https://hub.docker.com/r/bisand/haproxy-certbot

Do you guys think we can proceed with this image in our HTTPS cert with Let's Encrypt example? Just asking in case there are some considerations I missed.

@mister2d
Copy link

For a reference of how HAProxy and Letsencrypt can be used together, take a look at the nmarus/haproxy-certbot Docker image.

I did look into it before, but sadly it seems like it's not updated anymore. However I did try to check out the forks and found this: https://github.com/bisand/docker-haproxy-certbot/blob/master/Dockerfile

It seems to be a fairly clean approach since it builds on top of the official HAProxy image and it's up-to-date. Docker hub link: https://hub.docker.com/r/bisand/haproxy-certbot

Do you guys think we can proceed with this image in our HTTPS cert with Let's Encrypt example? Just asking in case there are some considerations I missed.

Yeah I know it's not updated, but it provides a good reference point.

The one issue I've found with those certbot enabled images is that if there's an issue with your HAProxy config it will trigger a restart of the entire container which forces multiple attempts against Letsencrypt for cert renewal checks. This in turn causes a period of lockout from the amount of attempts to Letsencrypt.

The second issue is that you can't perform hitless restarts or reloads of HAProxy while it's being controlled by supervisord.

Otherwise they work fine and I still use them on my home setup. I'm planning to break the images out separately to enable HAProxy to have the ability to load its certificates from a Consul.

@azrikahar
Copy link
Owner

azrikahar commented May 25, 2020

The one issue I've found with those certbot enabled images is that if there's an issue with your HAProxy config it will trigger a restart of the entire container which forces multiple attempts against Letsencrypt for cert renewal checks. This in turn causes a period of lockout from the amount of attempts to Letsencrypt.

The second issue is that you can't perform hitless restarts or reloads of HAProxy while it's being controlled by supervisord.

These are very valid concerns indeed, especially the lockout. I think for now I'll just add sort of a warning or recommendation to use the LE staging server so we can make sure everything is running okay first. Once everything is fine, then we'll turn off or remove the staging server lines to get actual valid certs.

Aside from this particular potential issue, there are various caveats that may be unique to each reverse proxy as well so it is not easy to cover all of them (though it's hard for me to ignore because of my self-diagnosed OCD when it comes to having a holistic info... ).

With that said, I think it's best to just proceed first and enhance later on once this gets more user attention, hopefully contributors too!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants