there were some issues with https://openlmis.atlassian.net/browse/OLMIS-6053
so Angola team has started working on adding SSL/TLS with Let’s Encrypt to the OpenLMIS architecture and here is our solution.
- we created an Nginx based proxy which handles HTTPS (all HTTP request being redirected to HTTPS),
- upgraded service-configuration service to handles getting and renewing a signed certificate from Let’s Encrypt.
- a separate Docker network for both openlmis/nginx and OpenLMIS-Angola/nginx-tls,
- a separate Docker network for every node except OpenLMIS-Angola/nginx-tls
- current architecture stays intact,
- services communicating with each other still send requests to openlmis/nginx and doesn’t involve the nginx-tls,
- additional layer hides all services and consul so for our users HTTPS is the only way to communicate with OpenLMIS.
- additional layers extend execution time approximately 6%.
We are still testing it but is this solution good enough to introduce it to the Core?
Thanks for putting together this clear overview! Do you know why the additional layers add the 6% execution time? While not huge, that is a non-trivial delay and more than I would have expected.
It is only one layer more, and services don’t involve it while communicating with each other.
So I think we could try to work on performance by adjusting the cache configuration of nginx-tls. At this point, nginx-tls has default cache configuration.
Thanks @wbulawa, this looks like it could be a well-desired contribution!
A few questions:
How does this work? Does the address(es) in settings.env then using an internal (Docker) address? Have more address settings been added?
Does this mean that a re-build/re-deploy of the Ref Distro is required to renew the cert? Every 6 months triggered manually?
Is this 6% with respect to using an AWS ELB with SSL? Or with an ELB without SSL? Or running without an ELB or anything else?
Another is SSL sessions, which is in part why I ask what the 6% is in reference to - AWS ELB w/ SSL termination is usually configured to utilize it.
If this could truly be an optional component (depending on what we discover here), one option could be that we accept it as an incubating component/service. Then it’s available and we could work on any improvements together until it’s recommended for general adoption.
Thanks for this!
Yes, BASE_URL is pointing to http://nginx-reverse-proxy which is internal docker address for openlmis/nginx.
No, we extended service-configuration to check every 12h if the certificate is relevant and we renew it automatically. Also, niginx-tls checks every 6h if it has to reload the certificate. Let’s Encrypt requires renewal of the certificate every 3 months.
The solution was compared to our instance without an additional layer (no ELB and no SSL).
docker-compose changes (service-configuration is based on certbot)
Thanks for the feedback!