Support docker compose for "the hard way"
Is your feature request related to a problem? Please describe. As a forgetful prosumer I always forget the docker calls to launch my services but don't have my own kubernetes cluster ;) I simply define my services in docker-compose files which works well enough for me.
Describe the solution you'd like I would like to amend the tutorial with the commands for docker compose or add a sample docker-compose.yml to bring up a working open-webui instance prepared for code execution.
Own work I looked up how to transform all these docker flags into docker compose and this is what i came up with:
open-webui:
build:
context: .
args:
OLLAMA_API_BASE_URL: '/ollama/api'
dockerfile: Dockerfile
image: ghcr.io/open-webui/open-webui:main
security_opt:
- seccomp:unconfined
- apparmor=unconfined
- label=type:container_engine_t
container_name: open-webui
volumes:
- open-webui:/app/backend/data
- /sys/fs/cgroup:/sys/fs/cgroup:rw
- /proc:/proc2:rw
The only flag that I didn't manage to set in docker compose is bind-recursive=disabled for procfs Is that absolutely necessary? Seems like that isn't possible yet in docker-compose yet https://github.com/docker/compose/issues/11792
Once the serivce is up, I ask it to curl a site and it errors out like this:
Environment needs setup work: /sys/fs/cgroup/cgroup.subtree_control not found; make sure you are using cgroups v2
but I guess that might be issue https://github.com/EtiennePerot/open-webui-code-execution/issues/14 .
bind-recursive=disabled for procfs Is that absolutely necessary?
It is necessary if your host machine's /proc mount has submounts, which on many Linux distributions it does (e.g. /proc/sys/fs/binfmt_misc). Otherwise, Docker will try to mount /proc along with all its submounts to /proc2, and thus the container still doesn't get an unobstructed view of procfs. So yes, it is usually necessary. :(
However privileged=true should work for Docker Compose, so perhaps the setup guide can contain Docker Compose instructions for the "easy way", but explain why the hard way doesn't have such instructions.
Once the serivce is up, I ask it to curl a site and it errors out like this:
Environment needs setup work: /sys/fs/cgroup/cgroup.subtree_control not found; make sure you are using cgroups v2but I guess that might be issue #14
Indeed.
Actually I think this may also be worked around by adding systempaths=unconfined in the security_opt list, instead of having a procfs mount at all. Can you try it? @jmtatsch
@EtiennePerot Unfortunately that does not help
[Code execution update available: v0.8.0] Environment needs setup work: /sys/fs/cgroup/cgroup.subtree_control not found; make sure you are using cgroups v2
I can't execute commands directly in the environment I'm running in, but you can easily do it yourself.
Please don't forget to push v0.8.0 to the hub ;)
With v0.8.0 and that cgroup valve deactivated I get:
Bash: Code error: /dev/stdin: line 1: ping: command not found (ping -c 4 heise.de)
I guess one would need to autoinstall necessary commandline tools like iputils-ping ?
Please don't forget to push v0.8.0 to the hub ;)
Ah yes, sorry I forgot to push v0.8.0 to the Open WebUI site. Done.
With v0.8.0 and that cgroup valve deactivated I get:
Yes, you should deactivate the valve if your system doesn't have cgroups v2, per issue #14.
I guess one would need to autoinstall necessary commandline tools like iputils-ping ?
If you get all the way to an error like "ping: command not found", then it sounds like the code evaluation sandbox is starting up properly and everything is working. It just can't run the ping tool because it's not installed in the Open WebUI container image, as you've guessed. Try running some other simpler utility like just date.
Update here: Once https://github.com/google/gvisor/commit/6adc0720b2e66d3dee7e115d93ec3347f9a8a212 makes it into a gVisor release, the need for the /proc mount will go away, so this will make it possible to use Docker Compose for "the hard way". I will leave this issue open until a docker compose file is documented as well.
Hey, just the issue I was looking for, as I am using OpenWebUI's docker-compose. Guess I will be watching this issue too.
Done now that the gVisor release no longer requires this. The setup docs now also have a minimal Docker compose file for reference.
I have downloaded the latest gvisor and installed it for docker so this works: docker run --rm --runtime=runsc hello-world
I have also applied the minimal docker compose changes but this results in
What is the current date and time?
profile
qwen2.5:32b
Environment needs setup work: procfs is obstructed; please mount a new procfs mount somewhere in the container, e.g. /proc2 (`--mount=type=bind,source=/proc,target=/proc2,readonly=false,bind-recursive=disabled`)
The provided information indicates there was an issue executing the command to get the current date and time due to an environment setup problem. Specifically, it mentions that procfs is obstructed and suggests mounting a new procfs mount somewhere in the container.
Since I don't have access to real-time data from your system or a way to execute commands successfully based on the given context, I can't provide you with the current date and time directly. If you need this information, you would typically run date on your local machine, but make sure that your environment is correctly set up if you encounter similar issues as described in the context.
For a general idea without executing the command, you could check the current date and time from any digital clock or use an online service to get it.
Seems like docker compose is missing: runtime: "runsc" but then it seems stuck at Checking for updates...
@jmtatsch The latest code no longer checks for procfs, so if you still get a "procfs is obstructed" error, you are using an old version of the tool/function. Please update it. I haven't created a new release out of it yet, so use the code directly from GitHub:
- Tool: https://raw.githubusercontent.com/EtiennePerot/safe-code-execution/master/open-webui/tools/run_code.py
- Function: https://raw.githubusercontent.com/EtiennePerot/safe-code-execution/master/open-webui/functions/run_code.py
Note also that you cannot use gVisor to run the Open WebUI container itself, because otherwise the code execution tool/function running within wouldn't work (gVisor doesn't support running inside gVisor itself). The Open WebUI container needs to run with the default container runtime, not runsc.
Works like a charm with the updated code. Thank you.
Works for me too.