supabase / cli

Supabase CLI. Manage postgres migrations, run Supabase locally, deploy edge functions. Postgres backups. Generating types from your database schema.
https://supabase.com/docs/reference/cli/about
MIT License
1.05k stars 205 forks source link

Issues Running `supabase start` within a devcontainer without `network_mode: "host"` #1939

Open InnovateWorldio opened 8 months ago

InnovateWorldio commented 8 months ago

Describe the bug Unable to successfully run supabase start within a devcontainer when not using network_mode: "host"

To Reproduce If I use the below compose.yml file from within the .devcontainer folder and run supabase start I receive the error service not healthy: [supabase_rest_langchain supabase_edge_runtime_langchain]

version: '3.8'
services:
  dev:
    container_name: dev
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - ..:/workspace
    environment:
      - NVIDIA_VISIBLE_DEVICES=all
    user: vscode
    command: sleep infinity
    deploy:
      resources:
        reservations:
          devices:
          - driver: nvidia
            capabilities: [gpu]
    ports:
      - "5173:5173"

Expected behavior If I use the below compose.yml file from within the .devcontainer folder and run supabase start everything works. I would expect to not need to use network_mode: "host".

version: '3.8'
services:
  dev:
    container_name: dev
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - ..:/workspace
    environment:
      - NVIDIA_VISIBLE_DEVICES=all
    user: vscode
    command: sleep infinity
    deploy:
      resources:
        reservations:
          devices:
          - driver: nvidia
            capabilities: [gpu]
    network_mode: "host"

Additional Notes

System information

sweatybridge commented 8 months ago

Have you tried docker-in-docker dev container?

{
  "image": "mcr.microsoft.com/devcontainers/universal:2",
  "features": {
    "ghcr.io/devcontainers/features/docker-in-docker:1": {
      "version": "latest"
    }
  }
}

This is necessary if you don't want to use host network mode because cli needs to launch additional containers from inside your dev container to start the local stack.

In addition, you probably also need to expose your docker daemon on a tcp socket and set env var DOCKER_HOST=tcp://host.docker.internal:2375 inside your devcontainer. This is similar to they way docker is setup on gitlab pipeline.

InnovateWorldio commented 8 months ago

I have been using docker-outside-of-docker so that I can manage any of my containers created through Docker Desktop on Windows. I currently have Windows with Docker Desktop running with Ubuntu 20.10 WSL. From within WSL I load my projects VSCode devconatainer with the associated Dockerfile, dev.compose.yml, settings.json, task.json and devcontainer.json files.

I went ahead and tried the docker-in-docker method and it worked fine without using network_mode: "host" but the supabase containers created didn't show up in the Windows Docker Desktop. This also causes the port mapping not to match what the output of running supabase start shows.

When using docker-outside-of-docker, if I only initialize the db or some of the other services without using network_mode: "host" they start successfully. It is only the supabase_rest and supabase_edge_runtime that fails to load.

If instead I don't use the devcontainer and just go to my project in WSL and run bunx supabase start the containers all start correctly.

I am able to start other containers like ollama from within my devcontainer without network_mode: "host" and they also work successfully. It just seems to be an issue with supabase_rest and supabase_edge_runtime.

I'll look around for a potential solution.

FelixZY commented 7 months ago

Related to #87

clingle commented 7 months ago

Writing this to hopefully help others with a similar issue in the future:

I initially tried to mount the Unix socket (/var/run/docker.sock) and add network_mode: "host" into my devcontainer.json configuration but Supabase edge functions weren't working correctly. I figured out that supabase-cli was trying to bind mount my devcontainer path (/workspace/supabase/functions) on my host machine with this configuration, resulting in an empty /home/deno/functions path within the edge-runtime container.

The fix was to use the docker-in-docker configuration mentioned above.

Example .devcontainer/settings.json file:

{
  "name": "Supabase Dev Container",
  "build": {
    "dockerfile": "Dockerfile"
  },
  "features": {
    "ghcr.io/devcontainers/features/docker-in-docker:2": {}
  },
  "customizations": {
    "vscode": {
      "extensions": [
        "denoland.vscode-deno",
        "ms-azuretools.vscode-docker"
      ]
    }
  },
  "remoteUser": "node"
}

The Dockerfile mentioned in the settings.json installs the Deno CLI for the VSCode Deno plugin:

#.devcontainer/Dockerfile
FROM mcr.microsoft.com/devcontainers/typescript-node:20

ENV DENO_INSTALL=/home/node/.deno
RUN curl -fsSL https://deno.land/install.sh | sh \
  && chown -R node:node /home/node/.deno