Best practices

On this page we will discuss some best practices for deploying and managing your pipelines on a production grade.

1. DocumentStore persistency

When using autoprovisioning of documentstores in your pipeline, it is great for development purposes.

In a production grade setup however, it is recommended to use a persistent DocumentStore and run it outside of Kubernetes.

If you are running on one of the cloud providers you can use a managed service like AWS RDS, Azure SQL or Google Cloud SQL or OpenSearch (formerly known as Elasticsearch) for this purpose.

This will relief a lot of day2 operational burden from your shoulders.

It is important: the operator does not provision production grade documentstores (for now). If you want to have a production setup, you need to provision the documentstores yourself.**

2. One pipeline per pipeline definition

Most likely you will also have two pipelines at least, one for indexing and one for querying. We recommend to have a separate pipeline definition for each pipeline (despite how we showed it in the example for training purposes).

This would mean you have one Haystack pipeline deployment for indexing, and one for querying.

Example pipeline_indexing.yaml:

    - name: indexing
      nodes:
        - name: FileTypeClassifier
          inputs: [File]
        - name: TextFileConverter
          inputs: [FileTypeClassifier.output_1]
        - name: Preprocessor
          inputs: [TextFileConverter]
        - name: Retriever
          inputs: [Preprocessor]
        - name: DocumentStore
          inputs: [Retriever]

Example pipeline_querying.yaml:

  pipelines:
    - name: query
      nodes:
        - name: Retriever
          inputs: [Query]

The above means you can assign resources and scale each pipeline independently.

3. One pipeline per namespace

It is recommended to have one pipeline per namespace. There is no guarantee that pipelines in the same namespace will not interfere with each other. So we recommend that you handle namespaces as a boundary for your tenants. This will also make it easier to do permissions management and network policies.

Example: Developer A has a pipeline in namespace dev-a and Developer B has a pipeline in namespace dev-b.

4. Monitoring & Alerting

Currently the operator provides the following states for a pipeline:

• Running: when the pipeline is running

• Failed: when the pipeline is in a failed state, but can be recovered

• Error: when the pipeline is in an error state, unrecoverable

• Pending: when the pipeline is not yet running

You can alert on these states stored in the Kubernetes object at .status.phase. You can also monitor pipeline object events for more detailed information.