Hacker News new | past | comments | ask | show | jobs | submit login

I would argue that you are using images wrong. An image should not contain credentials, and should be independent of deployment. We use the same image to test, deploy to staging, etc.

We always have a manually managed reverse proxy in front. For us, it takes care of TLS, caching, and makes me personally feel better than having the app HTTP/TLS stack facing the internet. This is just an nginx container with `/etc/nginx` mounted.

We also run certbot in a container. The two share a volume holding certs, and we do `certonly --webroot` to grab new certs. The container is not permanent, but launched from a script that essentially wraps certbot. Just need to disable the TLS vhost for a bit manually, and don’t forget to setup cron to refresh.




> We always have a manually managed reverse proxy in front. For us, it takes care of TLS, caching, and makes me personally feel better than having the app HTTP/TLS stack facing the internet. This is just an nginx container with `/etc/nginx` mounted.

well that is both your prerogative as well as your expenditure. We work in regulated spaces (finance in India) and dont get to have a lot of leeway in hosting and infrastructure. Docker is a lifesaver that way. Which is why we like letsencrypt, but it is a blocker for those of us using docker to run nginx itself.


Not sure I follow, we run nginx and certbot in Docker too? It's just that we manually manage its configuration, and need the extra (not too cumbersome) steps to get a cert up.

I usually copy a vhost config from one of our templates, comment out the TLS vhost, reload nginx, request cert, uncomment TLS vhost, reload nginx.

So, I'm not sure what's not possible in your setup? Unless there's a limitation on what kind of volumes you can connect to your containers?




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: