[bug] Docker build is not pushed to container registry

[debasis09]

Describe the bug

In my python application I am using detect_pii and provenance_embeddings lib from guardrails-ai.It is working as expected.

Now I created a Docker file and has written a github action workflow to build the docker image and push it to a container registry.
While building the docker image during the installation of detect_pii and provenance_embeddings I got several issues and found that it is because of numpy version.Now the installation is correct , image is built but image is not getting pushed to container registry .I am getting below error while the image is being written to layers.

`

Error:

#16 preparing build cache for export
#16 writing layer sha256:081a3493c0e761c11da41712a3b88b1fe8be04136a1dcb26c8f44c4b2433633e done
#16 writing layer sha256:0b61b7b259eb3d2247ad58d1a46d5db155a8db279900e911a6cd824168cc53e4
#16 writing layer sha256:0b61b7b259eb3d2247ad58d1a46d5db155a8db279900e911a6cd824168cc53e4 0.2s done
#16 writing layer sha256:3c5caa9a28e74de53b117107558107449522110aa9a695f26328c4cccf95b48a
#16 writing layer sha256:3c5caa9a28e74de53b117107558107449522110aa9a695f26328c4cccf95b48a done
#16 writing layer sha256:40d734479f1486a126c248a001290d9d4fcb6c6f2018c508a91125938bf3404c 0.0s done
#16 writing layer sha256:99ab3df87e74d15b2c7da222bbac7c0cdc0a3858579982e9f4de3840bac84134
#16 preparing build cache for export 38.3s done
#16 writing layer sha256:99ab3df87e74d15b2c7da222bbac7c0cdc0a3858579982e9f4de3840bac84134 38.0s done
#16 ERROR: error writing layer blob: failed to copy: failed to send write: write /tmp/.buildx-cache/ingest/44eca930b84e16fa67395824aedec982c33ef3311b274e4f983910dbfc7fb179/data: no space left on device: unknown

exporting cache to client directory:

---

WARNING: local cache import at /tmp/.buildx-cache not found due to err: could not read /tmp/.buildx-cache/index.json: open /tmp/.buildx-cache/index.json: no such file or directory
ERROR: failed to solve: error writing layer blob: failed to copy: failed to send write: write /tmp/.buildx-cache/ingest/44eca930b84e16fa67395824aedec982c33ef3311b274e4f983910dbfc7fb179/data: no space left on device: unknown
Error: buildx failed with: ERROR: failed to solve: error writing layer blob: failed to copy: failed to send write: write /tmp/.buildx-cache/ingest/44eca930b84e16fa67395824aedec982c33ef3311b274e4f983910dbfc7fb179/data: no space left on device: unknown

`

To Reproduce
I am attaching the docker file over here.
Note: If I am not using the installation of 2 guardrails in my docker file then the issue is not coming.It is able to push the image into container registry.But when I am using guardrail packages in my docker this issue is coming

Dockerfile_guardrail.txt

Expected behavior
Image should be created and pushed to container registry.

Please provide me a docker file using which I will not get any issue

Library version:
Version (e.g. 0.1.5)

Additional context
Add any other context about the problem here.

[CalebCourier]

@debasis09 according to the error you shared this is a disk space issue on the Github action runner you are using. The cause of this likely the size of the ML models that back the validators you are installing. For some of the larger models, like the one DetectPII uses, we offer remote inference endpoints that the validators can use instead of downloading and running the model locally (or in the container in this case).

To use this feature you will need to configure guardrails to enable remote inferencing as shown in the Dockerfile examples, specifically by running this line before performing any validator installations:

RUN guardrails configure --enable-metrics --enable-remote-inferencing --token $GUARDRAILS_TOKEN

Then when you install a validator that supports remote inferencing, you can opt out of downloading its ML model:

guardrails hub install hub://guardrails/detect_pii --no-install-local-models

[debasis09]

@CalebCourier thanks for your response.I was going thru the dockerfile..I have 2 questions in my mind..

1. Where do I find the GUARDRAILS_TOKEN ? is the remote inferencing mean to connect another remote server which is not hosted by us?
2. Basically we were trying to create a guardrail server for us.which can host multiple guardrails and our another python application act as client can access those guardrails using api's. can we do that without getting this build issue?

[CalebCourier]

@debasis09 good questions,

1. You can generate a free token here https://hub.guardrailsai.com/keys to use the remote inference endpoints we host. The remote inference feature I'm referencing means that instead of the validator downloading the ML model during installation and running it locally, it will make a request to a server we host instead to run the same model. It is also possible to host these models yourself in order to standup private remote inference endpoints. Let us know if this is a route you're interested in and we can share more details.
2. You can certainly accomplish what you've described. The build issue you're encountering is purely a result of a lack of enough disk space on the Github action runner you're using. The two ways around this are to use remote inference, which I describe above, or to run the build on a larger runner. Github talks about how to use larger runners here: https://docs.github.com/en/actions/using-github-hosted-runners/using-larger-runners/about-larger-runners. Since the build is simply a Docker build, you could also use any other CI you have access to, i.e. Jenkins, AWS Codebuild, etc., as long as the CI server's instance size can support the disk space requirements for the validators' underlying ML models.

[debasis09]

@CalebCourier ,Thank you very much for your response. It is really helpful. another question I would like to ask if I want to deploy the server image which I am creating into kubernetes cluster then will the below configuration is fine?

containers: - image: {{ .Values.image }}:{{ .Values.version }} name: {{ .Values.appName }} imagePullPolicy: Always ports: - containerPort: 8090 name: http protocol: TCP resources: limits: cpu: 800m memory: 1024Mi requests: cpu: 500m memory: 512Mi

[CalebCourier]

@debasis09 we don't use kubernetes internally, but these are the container specs we launch with on other platforms:
cpu: 1024 MB
memory: 2048 MB

Additionally, the default port for the image is 8000, you can change this to w/e port you'd like but besides updating the port binding in your startup command, you may also need to pass the new port as the third argument when calling create_app