GitLab Documentation

Elasticsearch integration

Elasticsearch was Introduced in GitLab EE 8.4. Support for Amazon Elasticsearch was introduced in GitLab EE 9.0.

Why do you need this?

Elasticsearch is a flexible, scalable and powerful search service that saves developers time. Instead of developers creating duplicate code and wasting time, they can now search for code within other teams that will help their own project.

Who needs this?

  1. My team uses a plugin to find code from different teams
  2. Are developers from different teams creating the same code for their own projects?
  3. Are you looking to enable innersourcing?
  4. Do you you want to keep GitLab's search fast when dealing with huge amount of data?

If you answered yes to any of these, you should consider enabling Elasticsearch.

GitLab leverages the search capabilities of Elasticsearch and enables it when searching in:

Once the data is added to the database or repository and Elasticsearch is enabled in the admin area the search index will be updated automatically. Elasticsearch can be installed on the same machine as GitLab, or on a separate server, or you can use the [Amazon Elasticsearch][aws-elastic] service.

Requirements

GitLab version Elasticsearch version
GitLab Enterprise Edition 8.4 - 8.17 Elasticsearch 2.4 with Delete By Query Plugin installed
GitLab Enterprise Edition 9.0+ Elasticsearch 5.1 - 5.3

Install Elasticsearch

Elasticsearch is not included in the Omnibus packages. You will have to install it yourself whether you are using the Omnibus package or installed GitLab from source. Providing detailed information on installing Elasticsearch is out of the scope of this document.

You can follow the steps as described in the official web site or use the packages that are available for your OS.

Enable Elasticsearch

In order to enable Elasticsearch you need to have access to the server that GitLab is hosted on, and an administrator account on your GitLab instance. Go to Admin > Settings and find the "Elasticsearch" section.

The following Elasticsearch settings are available:

Parameter Description
Elasticsearch indexing Enables/disables Elasticsearch indexing. You may want to enable indexing but disable search in order to give the index time to be fully completed, for example. Also keep in mind that this option doesn't have any impact on existing data, this only enables/disables background indexer which tracks data changes. So by enabling this you will not get your existing data indexed, use special rake task for that as explained in Add GitLab's data to the Elasticsearch index.
Use experimental repository indexer Perform repository indexing using GitLab Elasticsearch Indexer.
Search with Elasticsearch enabled Enables/disables using Elasticsearch in search.
URL The URL to use for connecting to Elasticsearch. Use a comma-separated list to support clustering (e.g., "http://host1, https://host2:9200").
Using AWS hosted Elasticsearch with IAM credentials Sign your Elasticsearch requests using AWS IAM authorization or AWS EC2 Instance Profile Credentials. The policies must be configured to allow es:* actions.
AWS Region The AWS region your Elasticsearch service is located in.
AWS Access Key The AWS access key.
AWS Secret Access Key The AWS secret access key.

Add GitLab's data to the Elasticsearch index

Configure Elasticsearch's host and port in Admin > Settings. Then create empty indexes using one of the following commands:

# Omnibus installations
sudo gitlab-rake gitlab:elastic:create_empty_index

# Installations from source
bundle exec rake gitlab:elastic:create_empty_index RAILS_ENV=production

Then enable Elasticsearch indexing and run repository indexing tasks:

# Omnibus installations
sudo gitlab-rake gitlab:elastic:index_repositories_async

# Installations from source
bundle exec rake gitlab:elastic:index_repositories_async RAILS_ENV=production

This enqueues a number of Sidekiq jobs to index your existing repositories. You can view the jobs in the admin panel (they are placed in the elastic_batch_project_indexer) queue), or you can query indexing status using a rake task:

# Omnibus installations
sudo gitlab-rake gitlab:elastic:index_repositories_status

# Installations from source
bundle exec rake gitlab:elastic:index_repositories_status RAILS_ENV=production

Indexing is 65.55% complete (6555/10000 projects)

By default, one job is created for every 300 projects. For large numbers of projects, you may wish to increase the batch size, by setting the BATCH environment variable. You may also wish to consider throttling the elastic_batch_project_indexer queue, as this step can be I/O-intensive.

You can also run the initial indexing synchronously - this is most useful if you have a small number of projects, or need finer-grained control over indexing than Sidekiq permits:

# Omnibus installations
sudo gitlab-rake gitlab:elastic:index_repositories

# Installations from source
bundle exec rake gitlab:elastic:index_repositories RAILS_ENV=production

It might take a while depending on how big your Git repositories are (see Indexing large repositories).

If you want to run several tasks in parallel (probably in separate terminal windows) you can provide the ID_FROM and ID_TO parameters:

sudo gitlab-rake gitlab:elastic:index_repositories ID_FROM=1001 ID_TO=2000

Where ID_FROM and ID_TO are project IDs. Both parameters are optional. As an example, if you have 3,000 repositories and you want to run three separate indexing tasks, you might run:

sudo gitlab-rake gitlab:elastic:index_repositories ID_TO=1000
sudo gitlab-rake gitlab:elastic:index_repositories ID_FROM=1001 ID_TO=2000
sudo gitlab-rake gitlab:elastic:index_repositories ID_FROM=2001

Sometimes your repository index process gitlab:elastic:index_repositories or gitlab:elastic:index_repositories_async can get interrupted. This may happen for many reasons, but it's always safe to run the indexing job again - it will skip those repositories that have already been indexed.

As the indexer stores the last commit SHA of every indexed repository in the database, you can run the indexer with the special parameter UPDATE_INDEX and it will check every project repository again to make sure that every commit in that repository is indexed, it can be useful in case if your index is outdated:

sudo gitlab-rake gitlab:elastic:index_repositories UPDATE_INDEX=true ID_TO=1000

You can also use the gitlab:elastic:clear_index_status Rake task to force the indexer to "forget" all progresss, so retrying the indexing process from the start.

To index all wikis:

# Omnibus installations
sudo gitlab-rake gitlab:elastic:index_wikis

# Installations from source
bundle exec rake gitlab:elastic:index_wikis RAILS_ENV=production

The wiki indexer also supports the ID_FROM and ID_TO parameters if you want to limit a project set.

To index all database entities:

# Omnibus installations
sudo gitlab-rake gitlab:elastic:index_database

# Installations from source
bundle exec rake gitlab:elastic:index_database RAILS_ENV=production

If your instance is small enough you can index everything at once (database records, repositories, wikis):

# Omnibus installations
sudo gitlab-rake gitlab:elastic:index

# Installations from source
bundle exec rake gitlab:elastic:index RAILS_ENV=production

Disable Elasticsearch

Disabling the Elasticsearch integration is as easy as unchecking Search with Elasticsearch enabled and Elasticsearch indexing in Admin > Settings.

Special recommendations

Here are some tips to use Elasticsearch with GitLab more efficiently.

Indexing large repositories

Indexing large Git repositories can take a while. To speed up the process, you can temporarily disable auto-refreshing and replicating. In our experience you can expect a 20% time drop.

  1. Disable refreshing:

    curl --request PUT localhost:9200/_settings --data '{
        "index" : {
            "refresh_interval" : "-1"
        } }'
    
  2. Disable replication and enable it after indexing:

    curl --request PUT localhost:9200/_settings --data '{
        "index" : {
            "number_of_replicas" : 0
        } }'
    
  3. Create the indexes

  4. Enable replication again after the indexing is done and set it to its default value, which is 1:

    curl --request PUT localhost:9200/_settings --data '{
        "index" : {
            "number_of_replicas" : 1
        } }'
    
  5. Enable refreshing again (after indexing):

    curl --request PUT localhost:9200/_settings --data '{
        "index" : {
            "refresh_interval" : "1s"
        } }'
    
  6. A force merge should be called after enabling the refreshing above:

    curl --request POST 'http://localhost:9200/_forcemerge?max_num_segments=5'
    

To minimize downtime of the search feature we recommend the following:

  1. Configure Elasticsearch in Admin > Settings, but do not enable it, just set a host and port.

  2. Create empty indexes:

    # Omnibus installations
    sudo gitlab-rake gitlab:elastic:create_empty_index
    
    # Installations from source
    bundle exec rake gitlab:elastic:create_empty_index RAILS_ENV=production
    
  3. Index all repositories using the gitlab:elastic:index_repositories Rake task (see above). You'll probably want to do this in parallel.

  4. Enable Elasticsearch indexing.

  5. Run indexers for database, wikis, and repositories (with the UPDATE_INDEX=1 parameter). By running the repository indexer twice you will be sure that everything is indexed because some commits could be pushed while you performed the initial indexing. The repository indexer will skip repositories and commits that are already indexed, so it will be much shorter than the first run.

Troubleshooting

Exception "Can't specify parent if no parent field has been configured"

If you enabled Elasticsearch before GitLab 8.12 and have not rebuilt indexes you will get exception in lots of different cases:

Elasticsearch::Transport::Transport::Errors::BadRequest([400] {
    "error": {
        "root_cause": [{
            "type": "illegal_argument_exception",
            "reason": "Can't specify parent if no parent field has been configured"
        }],
        "type": "illegal_argument_exception",
        "reason": "Can't specify parent if no parent field has been configured"
    },
    "status": 400
}):

This is because we changed the index mapping in GitLab 8.12 and the old indexes should be removed and built from scratch again, see details in the 8-11-to-8-12 update guide.

Exception Elasticsearch::Transport::Transport::Errors::BadRequest

If you have this exception (just like in the case above but the actual message is different) please check if you have the correct Elasticsearch version and you met the other requirements. There is also an easy way to check it automatically with sudo gitlab-rake gitlab:check command.

Exception Elasticsearch::Transport::Transport::Errors::RequestEntityTooLarge

[413] {"Message":"Request size exceeded 10485760 bytes"}

This exception is seen when your Elasticsearch cluster is configured to reject requests above a certain size (10MiB in this case). This corresponds to the http.max_content_length setting in elasticsearch.yml. Increase it to a larger size and restart your Elasticsearch cluster.

AWS has fixed limits for this setting ("Maximum Size of HTTP Request Payloads"), based on the size of the underlying instance.

I indexed all the repositories but I can't find anything

Make sure you indexed all the database data as stated above (sudo gitlab-rake gitlab:elastic:index)