chore: import upstream snapshot with attribution
CodeQL / Analyze (python) (push) Has been cancelled
Update Platform Components Table / update (push) Has been cancelled
Docker image release / Build base image (push) Has been cancelled
Sync docs with Docusaurus / sync (push) Has been cancelled
Tests / Check if changed (push) Has been cancelled
Tests / format (push) Has been cancelled
Tests / check-imports (push) Has been cancelled
Tests / Unit / macos-latest (push) Has been cancelled
Tests / Unit / ubuntu-latest (push) Has been cancelled
Tests / Unit / windows-latest (push) Has been cancelled
Tests / mypy (push) Has been cancelled
Tests / Integration / ubuntu-latest (push) Has been cancelled
Tests / Integration / macos-latest (push) Has been cancelled
Tests / Integration / windows-latest (push) Has been cancelled
Tests / notify-slack-on-failure (push) Has been cancelled
Tests / Mark tests as completed (push) Has been cancelled
CodeQL / Analyze (python) (push) Has been cancelled
Update Platform Components Table / update (push) Has been cancelled
Docker image release / Build base image (push) Has been cancelled
Sync docs with Docusaurus / sync (push) Has been cancelled
Tests / Check if changed (push) Has been cancelled
Tests / format (push) Has been cancelled
Tests / check-imports (push) Has been cancelled
Tests / Unit / macos-latest (push) Has been cancelled
Tests / Unit / ubuntu-latest (push) Has been cancelled
Tests / Unit / windows-latest (push) Has been cancelled
Tests / mypy (push) Has been cancelled
Tests / Integration / ubuntu-latest (push) Has been cancelled
Tests / Integration / macos-latest (push) Has been cancelled
Tests / Integration / windows-latest (push) Has been cancelled
Tests / notify-slack-on-failure (push) Has been cancelled
Tests / Mark tests as completed (push) Has been cancelled
This commit is contained in:
@@ -0,0 +1,117 @@
|
||||
---
|
||||
title: "Docker"
|
||||
id: docker
|
||||
slug: "/docker"
|
||||
description: "Learn how to deploy your Haystack pipelines through Docker starting from the basic Docker container to a complex application using Hayhooks."
|
||||
---
|
||||
|
||||
# Docker
|
||||
|
||||
Learn how to deploy your Haystack pipelines through Docker starting from the basic Docker container to a complex application using Hayhooks.
|
||||
|
||||
## Running Haystack in Docker
|
||||
|
||||
The most basic form of Haystack deployment happens through Docker containers. Becoming familiar with running and customizing Haystack Docker images is useful as they form the basis for more advanced deployment.
|
||||
|
||||
Haystack releases are officially distributed through the [`deepset/haystack`](https://hub.docker.com/r/deepset/haystack) Docker image. Haystack images come in different flavors depending on the specific components they ship and the Haystack version.
|
||||
|
||||
:::info
|
||||
At the moment, the only flavor available for Haystack is `base`, which ships exactly what you would get by installing Haystack locally with `pip install haystack-ai`.
|
||||
:::
|
||||
|
||||
You can pull a specific Haystack flavor using Docker tags: for example, to pull the image containing Haystack `2.12.1`, you can run the command:
|
||||
|
||||
```shell
|
||||
docker pull deepset/haystack:base-v2.12.1
|
||||
```
|
||||
|
||||
Although the `base` flavor is meant to be customized, it can also be used to quickly run Haystack scripts locally without the need to set up a Python environment and its dependencies. For example, this is how you would print Haystack’s version running a Docker container:
|
||||
|
||||
```shell
|
||||
docker run -it --rm deepset/haystack:base-v2.12.1 python -c"from haystack.version import __version__; print(__version__)"
|
||||
```
|
||||
|
||||
## Customizing the Haystack Docker Image
|
||||
|
||||
Chances are your application will be more complex than a simple script, and you’ll need to install additional dependencies inside the Docker image along with Haystack.
|
||||
|
||||
For example, you might want to run a simple indexing pipeline using [Chroma](../../document-stores/chromadocumentstore.mdx) as your Document Store using a Docker container. The `base` image only contains a basic install of Haystack, but you need to install the Chroma integration (`chroma-haystack`) package additionally. The best approach would be to create a custom Docker image shipping the extra dependency.
|
||||
|
||||
Assuming you have a `main.py` script in your current folder, the Dockerfile would look like this:
|
||||
|
||||
```shell
|
||||
FROM deepset/haystack:base-v2.12.1
|
||||
|
||||
RUN pip install chroma-haystack
|
||||
|
||||
COPY ./main.py /usr/src/myapp/main.py
|
||||
|
||||
ENTRYPOINT ["python", "/usr/src/myapp/main.py"]
|
||||
```
|
||||
|
||||
Then you can create your custom Haystack image with:
|
||||
|
||||
```shell
|
||||
docker build . -t my-haystack-image
|
||||
```
|
||||
|
||||
## Complex Application with Docker Compose
|
||||
|
||||
A Haystack application running in Docker can go pretty far: with an internet connection, the container can reach external services providing vector databases, inference endpoints, and observability features.
|
||||
|
||||
Still, you might want to orchestrate additional services for your Haystack container locally, for example, to reduce costs or increase performance. When your application runtime depends on more than one Docker container, [Docker Compose](https://docs.docker.com/compose/) is a great tool to keep everything together.
|
||||
|
||||
As an example, let’s say your application wraps two pipelines: one to _index_ documents into a Qdrant instance and the other to _query_ those documents at a later time. This setup would require two Docker containers: one to run the pipelines as REST APIs using [Hayhooks](../hayhooks.mdx) and a second to run a Qdrant instance. For more information on configuring Hayhooks using Docker Compose, see the [official Hayhooks documentation](https://deepset-ai.github.io/hayhooks/getting-started/quick-start-docker/).
|
||||
|
||||
For building the Hayhooks image, we can easily customize the base image of one of the latest versions of Hayhooks, adding required dependencies required by [`QdrantDocumentStore`](../../document-stores/qdrant-document-store.mdx). The Dockerfile would look like this:
|
||||
|
||||
```dockerfile Dockerfile
|
||||
FROM deepset/hayhooks:v1.16.0
|
||||
|
||||
RUN pip install qdrant-haystack sentence-transformers
|
||||
|
||||
CMD ["hayhooks", "run", "--host", "0.0.0.0"]
|
||||
|
||||
```
|
||||
|
||||
We wouldn’t need to customize Qdrant, so their official Docker image would work perfectly. The `docker-compose.yml` file would then look like this:
|
||||
|
||||
```yaml
|
||||
services:
|
||||
qdrant:
|
||||
image: qdrant/qdrant:latest
|
||||
restart: always
|
||||
container_name: qdrant
|
||||
ports:
|
||||
- 6333:6333
|
||||
- 6334:6334
|
||||
expose:
|
||||
- 6333
|
||||
- 6334
|
||||
- 6335
|
||||
configs:
|
||||
- source: qdrant_config
|
||||
target: /qdrant/config/production.yaml
|
||||
volumes:
|
||||
- ./qdrant_data:/qdrant_data
|
||||
|
||||
hayhooks:
|
||||
build: . # Build from local Dockerfile
|
||||
container_name: hayhooks
|
||||
ports:
|
||||
- "1416:1416"
|
||||
volumes:
|
||||
- ./pipelines:/pipelines
|
||||
environment:
|
||||
- HAYHOOKS_PIPELINES_DIR=/pipelines
|
||||
- LOG=DEBUG
|
||||
depends_on:
|
||||
- qdrant
|
||||
|
||||
configs:
|
||||
qdrant_config:
|
||||
content: |
|
||||
log_level: INFO
|
||||
```
|
||||
|
||||
For a functional example of a Docker Compose deployment, check out the [“RAG indexing and querying with Elasticsearch”](https://github.com/deepset-ai/hayhooks/tree/main/examples/rag_indexing_query) example from GitHub.
|
||||
@@ -0,0 +1,269 @@
|
||||
---
|
||||
title: "Kubernetes"
|
||||
id: kubernetes
|
||||
slug: "/kubernetes"
|
||||
description: "Learn how to deploy your Haystack pipelines through Kubernetes."
|
||||
---
|
||||
|
||||
import ClickableImage from "@site/src/components/ClickableImage";
|
||||
|
||||
# Kubernetes
|
||||
|
||||
Learn how to deploy your Haystack pipelines through Kubernetes.
|
||||
|
||||
The best way to get Haystack running as a workload in a container orchestrator like Kubernetes is to create a service to expose one or more [Hayhooks](../hayhooks.mdx) instances.
|
||||
|
||||
## Create a Haystack Kubernetes Service using Hayhooks
|
||||
|
||||
As a first step, we recommend to create a local [KinD](https://github.com/kubernetes-sigs/kind) or [Minikube](https://github.com/kubernetes/minikube) Kubernetes cluster. You can manage your cluster from CLI, but tools like [k9s](https://k9scli.io/) or [Lens](https://k8slens.dev/) can ease the process.
|
||||
|
||||
When done, start with a very simple Kubernetes Service running a single Hayhooks Pod:
|
||||
|
||||
```yaml
|
||||
kind: Pod
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: hayhooks
|
||||
labels:
|
||||
app: haystack
|
||||
spec:
|
||||
containers:
|
||||
- image: deepset/hayhooks:v1.16.0
|
||||
name: hayhooks
|
||||
imagePullPolicy: IfNotPresent
|
||||
resources:
|
||||
limits:
|
||||
memory: "512Mi"
|
||||
cpu: "500m"
|
||||
requests:
|
||||
memory: "256Mi"
|
||||
cpu: "250m"
|
||||
|
||||
---
|
||||
|
||||
kind: Service
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: haystack-service
|
||||
spec:
|
||||
selector:
|
||||
app: haystack
|
||||
type: ClusterIP
|
||||
ports:
|
||||
# Default port used by the Hayhooks Docker image
|
||||
- port: 1416
|
||||
|
||||
```
|
||||
|
||||
After applying the above to an existing Kubernetes cluster, a `hayhooks` Pod will show up as a Service called `haystack-service`.
|
||||
<ClickableImage src="/img/6eb9fb0c7b00367bfbe8182ffc7c3746f3f3d03b720e963df045e28160362d7f-Screenshot_2025-04-15_at_16.15.28.png" alt="Kubernetes Lens interface showing the hayhooks Pod running in the default namespace with status Running" />
|
||||
|
||||
Note that the `Service` defined above is of type `ClusterIP`. That means it's exposed only _inside_ the Kubernetes cluster. To expose the Hayhooks API to the _outside_ world as well, you need a `NodePort` or `Ingress` resource. As an alternative, it's also possible to use [Port Forwarding](https://kubernetes.io/docs/tasks/access-application-cluster/port-forward-access-application-cluster/) to access the `Service` locally.
|
||||
|
||||
To do that, add port `30080` to Host-To-Node Mapping of our KinD cluster. In other words, make sure that the cluster is created with a node configuration similar to the following:
|
||||
|
||||
```yaml
|
||||
kind: Cluster
|
||||
apiVersion: kind.x-k8s.io/v1alpha4
|
||||
nodes:
|
||||
- role: control-plane
|
||||
# ...
|
||||
extraPortMappings:
|
||||
- containerPort: 30080
|
||||
hostPort: 30080
|
||||
protocol: TCP
|
||||
```
|
||||
|
||||
Then, create a simple `NodePort` to test if Hayhooks Pod is running correctly:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
name: haystack-nodeport
|
||||
spec:
|
||||
selector:
|
||||
app: haystack
|
||||
type: NodePort
|
||||
ports:
|
||||
- port: 1416
|
||||
targetPort: 1416
|
||||
nodePort: 30080
|
||||
name: http
|
||||
```
|
||||
|
||||
After applying this, `hayhooks` Pod will be accessible on `localhost:30080`.
|
||||
|
||||
From here, you should be able to manage pipelines. Remember that it's possible to deploy multiple different pipelines on a single Hayhooks instance. Check the [Hayhooks overview](../hayhooks.mdx) or the [official Hayhooks documentation](https://deepset-ai.github.io/hayhooks/) for more details.
|
||||
|
||||
## Auto-Run Pipelines at Pod Start
|
||||
|
||||
Hayhooks can load Haystack pipelines at startup, making them readily available when the server starts. You can leverage this mechanism to have your pods immediately serve one or more pipelines when they start.
|
||||
|
||||
At startup, it will look for deployed pipelines on the path specified at `HAYHOOKS_PIPELINES_DIR`, then load them.
|
||||
|
||||
A [deployed pipeline](https://github.com/deepset-ai/hayhooks?tab=readme-ov-file#deploy-a-pipeline) is essentially a directory which must contain a `pipeline_wrapper.py` file and possibly other files. To preload an [example pipeline](https://github.com/deepset-ai/hayhooks/tree/main/examples/pipeline_wrappers/chat_with_website), you need to mount a local folder inside the cluster node, then make it available on Hayhooks Pod as well.
|
||||
|
||||
First, ensure that a local folder is mounted correctly on the KinD cluster node at `/data`:
|
||||
|
||||
```yaml
|
||||
kind: Cluster
|
||||
apiVersion: kind.x-k8s.io/v1alpha4
|
||||
nodes:
|
||||
- role: control-plane
|
||||
# ...
|
||||
extraMounts:
|
||||
- hostPath: /path/to/local/pipelines/folder
|
||||
containerPath: /data
|
||||
```
|
||||
|
||||
Next, make `/data` available as a volume and mount it on Hayhooks Pod. To do that, update your previous Pod configuration to the following:
|
||||
|
||||
```yaml
|
||||
kind: Pod
|
||||
apiVersion: v1
|
||||
metadata:
|
||||
name: hayhooks
|
||||
labels:
|
||||
app: haystack
|
||||
spec:
|
||||
containers:
|
||||
- image: deepset/hayhooks:v1.16.0
|
||||
name: hayhooks
|
||||
imagePullPolicy: IfNotPresent
|
||||
command: ["/bin/sh", "-c"]
|
||||
args:
|
||||
- |
|
||||
pip install trafilatura && \
|
||||
hayhooks run --host 0.0.0.0
|
||||
volumeMounts:
|
||||
- name: local-data
|
||||
mountPath: /mnt/data
|
||||
env:
|
||||
- name: HAYHOOKS_PIPELINES_DIR
|
||||
value: /mnt/data
|
||||
- name: OPENAI_API_KEY
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: openai-secret
|
||||
key: api-key
|
||||
resources:
|
||||
limits:
|
||||
memory: "512Mi"
|
||||
cpu: "500m"
|
||||
requests:
|
||||
memory: "256Mi"
|
||||
cpu: "250m"
|
||||
volumes:
|
||||
- name: local-data
|
||||
hostPath:
|
||||
path: /data
|
||||
type: Directory
|
||||
|
||||
```
|
||||
|
||||
Note that:
|
||||
|
||||
- We changed the Hayhooks container `command` to install the `trafilatura` dependency before startup, since it's needed for our [chat_with_website](https://github.com/deepset-ai/hayhooks/tree/main/examples/pipeline_wrappers/chat_with_website) example pipeline. For a real production environment, we recommend creating a custom Hayhooks image as described [here](docker.mdx#customizing-the-haystack-docker-image).
|
||||
- We make Hayhooks container read `OPENAI_API_KEY` from a Kubernetes Secret.
|
||||
|
||||
Before applying this new configuration, create the `openai-secret`:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Secret
|
||||
metadata:
|
||||
name: openai-secret
|
||||
type: Opaque
|
||||
data:
|
||||
# Replace the placeholder below with the base64 encoded value of your API key
|
||||
# Generate it using: echo -n $OPENAI_API_KEY | base64
|
||||
api-key: YOUR_BASE64_ENCODED_API_KEY_HERE
|
||||
```
|
||||
|
||||
After applying this, check your Hayhooks Pod logs, and you'll see that the `chat_with_website` pipelines have already been deployed.
|
||||
<ClickableImage src="/img/2dbf42dd2db1cb355ee7222d7f8e96c45b611200d83ca289be3456264a854c38-Screenshot_2025-04-16_at_09.19.14.png" alt="Kubernetes Lens interface displaying pod logs with application startup messages and deployed pipeline confirmation" />
|
||||
|
||||
## Roll Out Multiple Pods
|
||||
|
||||
Haystack pipelines are usually stateless, which is a perfect use case for distributing the requests to multiple pods running the same set of pipelines. Let's convert the single-Pod configuration to an actual Kubernetes `Deployment`:
|
||||
|
||||
```yaml
|
||||
apiVersion: apps/v1
|
||||
kind: Deployment
|
||||
metadata:
|
||||
name: haystack-deployment
|
||||
spec:
|
||||
replicas: 3
|
||||
selector:
|
||||
matchLabels:
|
||||
app: haystack
|
||||
template:
|
||||
metadata:
|
||||
labels:
|
||||
app: haystack
|
||||
spec:
|
||||
initContainers:
|
||||
- name: install-dependencies
|
||||
image: python:3.12-slim
|
||||
workingDir: /mnt/data
|
||||
command: ["/bin/bash", "-c"]
|
||||
args:
|
||||
- |
|
||||
echo "Installing dependencies..."
|
||||
pip install trafilatura
|
||||
echo "Dependencies installed successfully!"
|
||||
touch /mnt/data/init-complete
|
||||
volumeMounts:
|
||||
- name: local-data
|
||||
mountPath: /mnt/data
|
||||
resources:
|
||||
requests:
|
||||
memory: "64Mi"
|
||||
cpu: "100m"
|
||||
limits:
|
||||
memory: "128Mi"
|
||||
cpu: "250m"
|
||||
containers:
|
||||
- image: deepset/hayhooks:v1.16.0
|
||||
name: hayhooks
|
||||
imagePullPolicy: IfNotPresent
|
||||
command: ["/bin/sh", "-c"]
|
||||
args:
|
||||
- |
|
||||
pip install trafilatura && \
|
||||
hayhooks run --host 0.0.0.0
|
||||
ports:
|
||||
- containerPort: 1416
|
||||
name: http
|
||||
volumeMounts:
|
||||
- name: local-data
|
||||
mountPath: /mnt/data
|
||||
env:
|
||||
- name: HAYHOOKS_PIPELINES_DIR
|
||||
value: /mnt/data
|
||||
- name: OPENAI_API_KEY
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: openai-secret
|
||||
key: api-key
|
||||
resources:
|
||||
requests:
|
||||
memory: "256Mi"
|
||||
cpu: "250m"
|
||||
limits:
|
||||
memory: "512Mi"
|
||||
cpu: "500m"
|
||||
volumes:
|
||||
- name: local-data
|
||||
hostPath:
|
||||
path: /data
|
||||
type: Directory
|
||||
|
||||
```
|
||||
|
||||
Implementing the above configuration will create three pods. Each pod will run a different instance of Hayhooks, all serving the same example pipeline provided by the mounted volume in the previous example.
|
||||
|
||||
<ClickableImage src="/img/f3f0ac4b22a37039f0837c22b0cb8b640937bbb0db4acfcbdf7bd016b545d84a-Screenshot_2025-04-16_at_09.32.07.png" alt="Kubernetes Lens interface showing three haystack-deployment pods in Running status with their resource configurations" />
|
||||
|
||||
Note that the `NodePort` you created before will now act as a load balancer and will distribute incoming requests to the three Hayhooks Pods.
|
||||
@@ -0,0 +1,73 @@
|
||||
---
|
||||
title: "OpenShift"
|
||||
id: openshift
|
||||
slug: "/openshift"
|
||||
description: "Learn how to deploy your applications running Haystack pipelines using OpenShift."
|
||||
---
|
||||
|
||||
# OpenShift
|
||||
|
||||
Learn how to deploy your applications running Haystack pipelines using OpenShift.
|
||||
|
||||
## Introduction
|
||||
|
||||
OpenShift by Red Hat is a platform that helps create and manage applications built on top of Kubernetes. It can be used to build, update, launch, and oversee applications running Haystack pipelines. A [developer sandbox](https://developers.redhat.com/developer-sandbox) is available, ideal for getting familiar with the platform and building prototypes that can be smoothly moved to production using a public cloud, private network, hybrid cloud, or edge computing.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
The fastest way to deploy a Haystack pipeline is to deploy an OpenShift application that runs Hayhooks. Before starting, make sure to have the following prerequisites:
|
||||
|
||||
- Access to an OpenShift project. Follow RedHat's [instructions](https://developers.redhat.com/developer-sandbox) to create one and start experimenting immediately.
|
||||
- Hayhooks is installed. Run `pip install hayhooks` and make sure it works by running `hayhooks --version`. Read more about Hayhooks in our [overview](../hayhooks.mdx) or the [official Hayhooks documentation](https://deepset-ai.github.io/hayhooks/).
|
||||
- You can optionally install the OpenShift command-line utility `oc`. Follow the [installation instructions](https://docs.openshift.com/container-platform/4.15/cli_reference/openshift_cli/getting-started-cli.html) for your platform and make sure it works by running `oc—h`.
|
||||
|
||||
## Creating a Hayhooks Application
|
||||
|
||||
In this guide, we’ll be using the `oc` command line, but you can achieve the same by interacting with the user interface offered by the OpenShift console.
|
||||
|
||||
1. The first step is to log into your OpenShift account using `oc`. From the top-right corner of your OpenShift console, click on your username and open the menu. Click **Copy login command** and follow the instructions.
|
||||
|
||||
2. The console will show you the exact command to run in your terminal to log in. It’s something like the following:
|
||||
```
|
||||
oc login --token=<your-token> --server=https://<your-server-url>:6443
|
||||
```
|
||||
|
||||
3. Assuming you already have a project (it’s the case for the developer sandbox), create an application running the Hayhooks Docker image available on Docker Hub:
|
||||
Note how you can pass environment variables that your application will use at runtime. In this case, we disable Haystack’s internal telemetry and set an OpenAI key that will be used by the pipelines we’ll eventually deploy in Hayhooks.
|
||||
```
|
||||
oc new-app deepset/hayhooks:v1.16.0 -e HAYSTACK_TELEMETRY_ENABLED=false -e OPENAI_API_KEY=$OPENAI_API_KEY
|
||||
```
|
||||
|
||||
4. To make sure you make the most out of OpenShift's ability to manage the lifecycle of the application, you can set a [liveness probe](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/):
|
||||
```
|
||||
oc set probe deployment/hayhooks --liveness --get-url=http://:1416/status
|
||||
```
|
||||
|
||||
5. Finally, you can expose our Hayhooks instance to the public Internet:
|
||||
```
|
||||
oc expose service/hayhooks
|
||||
```
|
||||
|
||||
6. You can get the public address that was assigned to your application by running:
|
||||
|
||||
```
|
||||
oc status
|
||||
```
|
||||
|
||||
In the output, look for something like this:
|
||||
|
||||
```
|
||||
In project <your-project-name> on server https://<your-server-url>:6443
|
||||
|
||||
http://hayhooks-XXX.openshiftapps.com to pod port 1416-tcp (svc/hayhooks)
|
||||
```
|
||||
|
||||
7. `http://hayhooks-XXX.openshiftapps.com` will be the public URL serving your Hayhooks instance. At this point, you can query Hayhooks status by running:
|
||||
```
|
||||
HAYHOOKS_HOST=hayhooks-XXX.openshiftapps.com HAYHOOKS_PORT=80 hayhooks status
|
||||
```
|
||||
|
||||
8. Lastly, deploy your pipeline as usual:
|
||||
```
|
||||
HAYHOOKS_HOST=hayhooks-XXX.openshiftapps.com HAYHOOKS_PORT=80 hayhooks pipeline deploy-files -n my_pipeline /path/to/my_pipeline_dir
|
||||
```
|
||||
Reference in New Issue
Block a user