By mrbagnall | 29 May 2017
I'm going to straight up admit that I am not a SOLR expert from a system administration standpoint. As such, I have a lot to learn about various configurations and setup options for getting SOLR working in different ways.
One recent challenge included the placement of SOLR within a subdirectory on a web site which is configured with SSL. This translates not only to easier access for SOLR within your web application (particularly if you are using an ajax technology such as Angular.JS) but also allows you set up SOLR within an SSL secure site without having to map ports and getting a separate or wildcard SSL for your SOLR instance.
My use case is as follows.
- I have an existing web application that needs to have SOLR integrated.
- The web application is available via http and https, but https is forced so that all communications happen over a SSL.
- The SOLR search application to be integrated is written in Angular.JS.
To accommodate this, I decided to engineer it as follows.
- Set up services so that the SOLR search is on the same domain as the web application in a sub directory (http://www.example.com/solr)
- The main application server is configured with SSL
- Use Docker to configure the SOLR search, networking model and general application setup via volume mapping of site files and configurations.
Using Apache, I set up a sub-directory proxy. Doing this within Docker requires a couple of considerations within your docker-compose.yml file. It isn't terribly difficult, but I am hoping this article will save someone some of the headaches I experienced while setting this up.
In my docker-compose.yml file, I configured different containers for the web piece and SOLR. These containers were strategically networked to communicate with each other without exposing SOLR to a public-facing port.
So we start off with our docker-compose.yml file which looks something similar to this:
Once this has been configured and executed, I imported my pre-indexed SOLR core so use with the application so that no indexing was required post install. The web application itself lives in the html directory which, as you can tell, is mapped to the document root of the web service.
I mapped the SOLR instance to the /solr subdirectory of my site by a slight change to the Apache configuration file. This can be done either within the main DocumentRoot property of the root site or within any VirtualHost directive. For my purposes I have this in the VirtualHost directive in my ssl.conf file for the site in question.
ProxyPass /solr http://ss:8983/solr
ProxyPassReverse /solr http://ss:8983/solr
Take note of the protocol and hostname. While we are accessing the site publically via the https protocol, Apache will communicate with SOLR via non-encrypted http. This saves you from having to install an SSL certificate within your SOLR server. While the communication between SOLR and Apache will not be encrypted, it will be for anything transmitted to the end user - so it is secure. The end result is this requires a single SSL certificate for the http server and not one for both http and SOLR. Also important is that because no ports are mapped on the SOLR container, there is no way to publically access SOLR without going through SSL.
It is also important to note that if you were to place the SSL certificate on SOLR, you would need to map to port 443. This would then require a different hostname as it is not standard procedure to run SSL over a non-standard SSL port. In fact, browsers will complain or simply refuse to do it.
The hostname is the same as the alias configured for your SOLR container within docker-compose.yml.
After a restart of Apache, you should be able to access via the /solr subdirectory to see the administrative interface of SOLR (also provide username and password if you have SOLR configured as such).
In this way, you can have both on the same SSL, but running from different containers.
All that was required was to configure the Angular.JS project to use the modified URL path without the port (8983) to query SOLR and everything worked very well.