Skip to content

ten7/flightdeck-solr-8

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

30 Commits
 
 
 
 
 
 
 
 

Repository files navigation

Flight Deck

Flight Deck Solr

Flight Deck Solr is a minimalist Solr container for Drupal sites on Kubernetes and Docker. You can use it both for local development and production.

Features:

  • ConfigMap-friendly YAML configuration
  • Supports multiple cores
  • Supports custom cores via ConfigMaps or volumes

Tags and versions

There are several tags available for this container, each with different Solr and Drupal module support:

Tags Solr Version Search API Custom cores
latest 8.6 Yes Yes
x.y.z 8.6 Yes Yes

Configuration

Instead of a large number of environment variables, this container relies on a file to perform all runtime configuration, flightdeck-solr.yml. Inside the file, create following:

---
flightdeck_solr: {}

All configuration is done as items under the flightdeck_solr variable. See the following sections for details as to particular configurations.

You can provide this file in one of three ways to the container:

  • Mount the configuration file at path /config/solr/flightdeck-solr.yml inside the container using a bind mount, configmap, or secret.
  • Mount the config file anywhere in the container, and set the FLIGHTDECK_CONFIG_FILE environment variable to the path of the file.
  • Encode the contents of flightdeck-solr.yml as base64 and assign the result to the FLIGHTDECK_CONFIG environment variable.

Basic settings

---
flightdeck_solr:
  port: 8983
  cores: []

Where:

  • flightdeck_solr.port is the port on which to run Solr. Optional, defailts to 8983.
  • flightdeck_solr.cores is a list of cores to create.

Defining cores

This container supports multiple cores by defining an item under the flightdeck_solr.cores item:

---
flightdeck_solr:
  port: 8983
  cores:
    - name: "my_custom_core"
      confDir: "/solr-conf"
      dataDir: "/solr-data"
    - name: "my_other_core"
      type: "custom"
      confDir: "/other-conf"
      dataDir: "/other-data"

Each item has the following variables:

  • name is the name of the solr core. Required.
  • type is the type of Solr core to create. Optional, must be custom or empty.
  • confDir is the path inside the container at which the schema files are mounted. Required for custom cores.
  • dataDir is the path inside the container at which the core data is to be stored. Optional, defaults to /data/<name_of_the_core>.

Passing core configs inline

In some cases, you may wish to pass your solr core configs inline inside of flightdeck-solr.yml rather than as a mounted directory in the container. In that case, you can define the conf list.

Each item under the list represents a file in the core configuration directory:

---
flightdeck_solr:
  port: 8983
  cores:
    - name: "my_custom_core"
      type: "custom"
      conf:
        - name: "solrconfig.xml"
          content: |
            <?xml version="1.0" encoding="UTF-8" ?>

            <!DOCTYPE config [
              <!ENTITY extra SYSTEM "solrconfig_extra.xml">
              <!ENTITY index SYSTEM "solrconfig_index.xml">
            ]>

Where:

  • name is the name of the file to create.
  • content is the content of the file.

Encoding issues for inline conf

A drawback of inline configuration is that you need to escape it work in YAML. This can be frustrating an difficult. Instead, is recommended to base64 encode the content of the file, and use the content_base64 key instead:

---
flightdeck_solr:
  port: 8983
  cores:
    - name: "my_custom_core"
      type: "custom"
      conf:
        - name: "solrconfig.xml"
          content_base64: |
            PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiID8+Cgo8IURPQ1RZUEUgY29uZmln
            IFsKICAgPCFFTlRJVFkgZXh0cmEgU1lTVEVNICJzb2xyY29uZmlnX2V4dHJhLnhtbCI+CiAgIDwh
            RU5USVRZIGluZGV4IFNZU1RFTSAic29scmNvbmZpZ19pbmRleC54bWwiPgpdPgo=

What about Search API?

Flight Deck Solr supports Search API as fully custom cores. This is due to changes in how Search API Solr works, which requires you to generate a config.zip under Admin > Config > Search and metadata > Search API.

  1. First, create an empty core using this container.
  2. Generate the config.zip in Drupal.
  3. Update your docker-compose.yml to mount the extracted *.zip at the path specified by confDir.
  4. Update your flightdeck-solr.yml to be a custom core type.
  5. Restart the solr container.

Deployment on Kubernetes

Use the ten7.flightdeck_cluster role on Ansible Galaxy to deploy Solr as a statefulset:

flightdeck_cluster:
  namespace: "search"
  configMaps:
    - name: "solr_config"
      files:
        - name: "flightdeck-solr.yml"
          content: |
            flightdeck_solr:
              cores:
                - name: "my_custom_core"
                  confDir: "/config/my_custom_core"
  solr:
    configMaps:
      - name: "solr_config"
        path: "/config/my_custom_core"

Using with Docker Compose

Create the flightdeck-solr.yml file relative to your docker-compose.yml. Define the solr service mounting the file as a volume:

version: '3'
services:
  solr:
    image: ten7/flight-deck-solr
    volumes:
      - ./flightdeck-solr.yml:/config/solr/flightdeck-solr.yml
    ports:
      - "8003:8983"

Part of Flight Deck

This container is part of the Flight Deck library of containers for Drupal local development and production workloads on Docker, Swarm, and Kubernetes.

Flight Deck is used and supported by TEN7.

Debugging

If you need to get verbose output from the entrypoint, set flightdeck_debug to true or yes in the config file.

---
flightdeck_debug: yes

This container uses Ansible to perform start-up tasks. To get even more verbose output from the start up scripts, set the ANSIBLE_VERBOSITY environment variable to 4.

If the container will not start due to a failure of the entrypoint, set the FLIGHTDECK_SKIP_ENTRYPOINT environment variable to true or 1, then restart the container.

License

Flight Deck is licensed under GPLv3. See LICENSE for the complete language.