Dealing with Search service deployment

Solr has some internal behavior that make it a not so great fit for orchestrated container based environments. Some are mentioned bellow:

  • Solr performs better on block storage with good I/O and those usually involve some stickiness to worker nodes. While this is not impossible to setup in Kubernetes it is however not very convenient and reduces the benefit of using workload scheduler.
  • Solr is known to be quite resource greedy, in particular in terms of memory allocation. That has a direct impact on Kubernetes worker nodes sizing.
  • It uses some filesystem based locking mechanisms which do not play well with workload scheduling or the ephemeral nature of containers in general.

For that reason we recommend for production environments to install Search services alongside the Kubernetes cluster and configure the Helm charts to not deploy it and instead point the repository to the external one.

Configuring Helm chart

Below we explain how to configure the Helm chart to point the repository to a Solr instance outside of the kubernetes cluster.

Installing Solr instance(s) is out of the scope of this document, but it can be done following the Search service documentation, or by using the Ansible playbook (replication setup require an additional load-balancer), as explained here.

On the chart side you need to:

  • Tell the Helm to not create the Solr deployment
  • Give Helm the shared secret to use when contacting Solr.
  • Provide details so the repository can be configured properly

  • Tell the repository itself to use the solr6 flavor and to read that shared secret from the SOLR_SECRET key - global.search.flavor only drives the chart’s own resources (e.g. the alfresco-search deployment), the alfresco-repository subchart needs its own configuration.search set explicitly, otherwise it silently starts in elasticsearch mode with no solr.sharedSecret wired in

    global:
  search:
    url: http://internal-load-balancer-ac3a091cb.eu-west-1.elb.amazonaws.com/solr
    flavor: solr6
    securecomms: secret
    sharedSecret: d0ntT3llAny0n3
alfresco-search:
  enabled: false
alfresco-repository:
  configuration:
    search:
      flavor: solr6
      existingSecret:
        keys:
          solr-secret: SOLR_SECRET

In this example an internal load balancer is created and aims a target group composed of the slaves Solr nodes deployed on EC2 instances. All these resources should be deployed within the Kubernetes cluster’s VPC, so the traffic remains internal.