Another recently encountered problem: how to make Docker container DNS work when the configured DNS server is blocked.
The answer is simple:
/etc/docker/daemon.json contains the docker daemon configuration, and you can specify additional defaults. In this case, I added my local DNS server first, followed by the Google public DNS server (which I prefer not to use generally, but am OK with a docker container using).
"dns": ["192.168.1.1", "22.214.171.124"]
I wonder if there's a market for a docker image with a basic caching resolver like dnscache already configured? It's small, efficient, and removes the need for overriding configurations like this.
So I ran into an interesting problem recently. I run a number of websites with custom software, this blog being one of them. I use Let's Encrypt to automatically obtain SSL certificates for them, since they are personal sites that don't do e-commerce and the free cert is fine. They are running on Tomcat, using JSP and servlets, with a database backend, and Apache HTTPD in front handling the SSL part. If it wasn't for the SSL part, I would be happy with Tomcat serving them directly. Load is not really a big concern, given the size. But to fit in with the automatic certificates, I need Apache HTTPD in front.
That broke for me recently, when some software got updated and was slow to percolate downwards. When the fixes finally did percolate, the renewals still didn't work. Why not? Because the renewal process needs to access urls with Apache that were being forwarded to Tomcat. Tomcat of course had no idea what to do with them.
Once I figured out the problem it was easy to solve; make sure the url needed by Let's Encrypt was not one of those forwarded. But that broke my (easy, default) configuration of just forwarding everything to Tomcat. And there's no way to specify an inverted forward (eg, forward everything EXCEPT the Let's Encrypt requests).
1) Forward only *.jsp and /servlet/*. This is pretty standard, and lets Apache HTTPD serve images and other static files which would be important if I was more worried about performance, but has a number of other issues. For example, suddenly my permissions have to allow for both tomcat and apache ... even if my update process is an automated deploy of a war file extracted by tomcat. And I can't use normal directory urls (like "/directory/") unless I either provide a DirectoryIndex of index.jsp (which gets forwarded, but isn't what I want the url to be) or prefix it with servlet.
2) Forward *.jsp, /servlet/*, and everything from each additional webapp (like "/weblog/*"). This mostly works (especially since my ROOT webapp is usually small) but needs to be updated each time I need a new webapp added and for each site.
So why hasn't someone solved this problem by writing an Apache HTTPD plugin or module that can actually ask Tomcat what urls it wants to handle and which are handled dynamically, so Apache HTTPD can avoid this configuration step and handle it automatically?
There is an option in Tomcat that dates back to Tomcat 3.3 that tries to do something like this by auto-generating Apache configuration files. I suspect this is not exactly what I am looking for. But it's an interesting problem.