acromedia / ansible-role-solr-core-config

Copy a config set from an arbitrary location (ie one that ships with the solr drupal module) into the solr core's config directory

ansible-role-solr-core-config

Copy a config set from an arbitrary location into Solr's core config directory, and apply the correct ownership + permissions.

This is meant to be used in conjunction with (and after) GeerlingGuy's solr role.

Warning: All of the contents of /{{ solr_home }}/data/{{ solr_core_name }}/conf will be replaced by the contents of {{ solr_core_conf_source }}. If you want your conf dir backed up, you'll need to do that before running this role.

Requirements

• Your solr core must already exist.
  • If you're using GeerlingGuy's solr role, then list your core name as one of the items in the solr_cores variable. Or create your core manually in the Solr UI. Or run the solr cli to create your core. Once your core is created, the directory specified by solr_core_conf_dest will exist, and this role can do its job.
• If Solr is on the same server as Drupal, the core conf files can be copied from it. Use solr_core_conf_source for this.
  • Drupal 7 config can be obtained from the search api module.
  • Drupal 8 solr config must be generated by Drupal (which seems awkward, because it is).
  • Either way, commit your solr config files and deploy them to your server before you use this role.
• If Solr is on a different server from Drupal, the core conf files can be copied from the Ansible controller (eg, your locahost). Use solr_core_conf_local_source for this.

Role Variables

Required:

• solr_core_name: Name of the solr core that the conf files will be attached to
• One of solr_core_conf_local_source OR solr_core_conf_source:
  • solr_core_conf_local_source: Absolute path to the directory on the ansible controller that contains your config set. If this variable is set, any previous value for solr_core_conf_source is ignored.
  • solr_core_conf_source: Absolute path to the directory on the server that contains your solr schema files. This can be used when you've committed your schema files to your drupal repository, and then your CI deploy job has already placed them on the server, ready for processing by this role.

Optional:

• solr_service_name: In case your solr service is named something other than solr.
• solr_home: In case your solr files were configured somewhere other than /var/solr
• solr_core_conf_dest: Defaults to "{{ solr_home }}/data/{{ solr_core_name }}/conf". You shouldn't ever need to change this. It's only noted here, because it's very easy to miss creating your core before using t his role. This role does not create the solr core for you. See the Requirements section above.

Dependencies

• geerlingguy.solr

Example Playbooks

    - hosts: web_servers
      become: true 
      gather_facts: true
      roles:
        - name: Install Solr 8 for use by my Drupal 9 site
          role: geerlingguy.solr 
          solr_cores: 
           - siteXYZcore
           
        - name: Configure my drupal 9 site 
          role: acromedia.virtual-host 
          #  ... etc etc etc... 

        - name: Configure the solr core for my D9 site, whose config I generated from my local lando dev environment, and then deployed to my server.
          role: acromedia.solr-core-config
          vars:
            solr_core_conf_source: /var/www/vhosts/siteXYZ/src/solr_conf
            solr_core_name: siteXYZcore

    # When using the same role more than once in the same playbook, it's safest to separate them into thier own plays.
    - hosts: web_servers  
      become: true 
      gather_facts: true
      roles:
        - name: Install solr 6 alongside the default solr 6 install, to support my Drupal 7 site
          role: geerlingguy.solr 
          solr_version: "6.6.6"
          solr_service_name: solr6
          solr_port: "8986"
          solr_home: "/var/{{ solr_service_name }}"
          solr_cores: 
           - mySolr6core

        - name: Configure my drupal 7 site 
          role: acromedia.virtual-host 
          #  ... etc etc etc... 
          
        - name: Configure solr core for my D7 site, whose config comes from the search_api_solr module.
          role: acromedia.solr-core-config
          vars:
            solr_core_conf_source: /var/www/vhosts/siteABC/public_html/modules/contrib/search_api_solr/solr-conf/6.x
            solr_core_name: mySolr6core
            solr_service_name: solr6
            solr_home: /var/solr6

- hosts: servers
  roles:
    - name: Use locally committed solr schema (which we generated from Drupal 8), to configure a solr core
      role: acromedia.solr-core-config
      vars:
        solr_core_conf_local_source: "{{ playbook_dir }}/solr/config"
        solr_core_name: coreBFG

License

GPLv3

Author Information

Acro Media Inc.

ansible-role-solr-core-config's Issues

What if the solr server isn't the same machine as where the config files live?

E.g. what if solr runs on its own instance? Can we add an option to copy config files from the running host machine, in the case where the solr config files were committed to the ansible playbook repository, instead of the drupal repository?

Molecule tests run twice in gitlab actions??

Tests appear to be going through two full runs ... obviously this is not needed.

Drupal 8 stock search api module config files don't work - must be generated by drupal

Ran in to a site recently where we had to use the config bundle that was retrieved from the Admin UX at /admin/config/search/search-api ... the stock config template from the module was incomplete and resulted in errors.

Add a cron job to restart solr nightly

If solr service is running for a very long time, the log file is taking up GBs. As there is no logrotation, if we restart the solr service, the log files will be recreated.
We need to make sure that our playbook adds a cron to restart solr services every night so that it doesn't consume lot of disk space.

Add an option to override solr open file and max process limit

Call to service restart is wrong

Ansible is building the cron job string as

0 8 * * * service /opt/solr/bin/solr restart > /dev/null

which is backwards. The path to the service should be fully qualified, but the service name should just be its name.

Role should stop if requirements are not met

If the config source, the config dest, or the core itself does not exist, then the role happily and quietly skips tasks, and does not affect any changes. This invariably wastes time trying to figure out what happened. Put a couple of assertions in to stop the role with a meaningful error message.