Docker-compose jupyterhub issue

Question

I have a docker-compose setup with the following setup:

./
+-- .env
+-- docker-compose.yml
+-- jupyterhub/
| +-- Dockerfile
| +-- jupyter-config.py
+-- jupyterlab/
| +-- Dockerfile
+-- reverse-proxy/
+-- traefik.toml

I follow the recipe from opendreamkit.org and manage to get the system up and running. However, when I run the command docker-compose down and up again I get the following error:

*jupyterhub_hub | [E 2020-03-31 08:28:38.108 JupyterHub user:477] Unhandled error starting tester1's server: The 'ip' trait of a Server instance must be a unicode string, but a value of None was specified.

I suspect it* has something to do with the following Message I get when I build the system:

WARNING: The DOCKER_NETWORK_NAME variable is not set. Defaulting to a blank string.

But I was wondering if anyone could provide with me a workaround or explanation to why this error occur? Thanks in advance for any help in the matter(during these Corona times)

edit: my file docker-compose.yml

version: '3'

services:
  # Configuration for Hub+Proxy
  jupyterhub:
    build: jupyterhub                # Build the container from this folder.
    container_name: jupyterhub_hub   # The service will use this container name.
    volumes:                         # Give access to Docker socket.
      - /var/run/docker.sock:/var/run/docker.sock
    environment:                     # Env variables passed to the Hub process.
      DOCKER_JUPYTER_IMAGE: jupyterlab_img
      DOCKER_NETWORK_NAME: ${COMPOSE_PROJECT_NAME}_default
      HUB_IP: jupyterhub_hub
    labels:                          # Traefik configuration.
      - "traefik.enable=true"
      - "traefik.frontend.rule=Host:x.x.x.x"

  # Configuration for reverse proxy
  reverse-proxy:
        image: traefik
        ports:
                - "80:80"
                - "443:443"
                - "8080:8080"
        volumes:
                - ./reverse-proxy/traefik.toml:/etc/traefik/traefik.toml
                - /var/run/docker.sock:/var/run/docker.sock
                - /etc/certs:/etc/certs

  # Configuration for the single-user servers
  jupyterlab:
    build: jupyterlab
    image: jupyterlab_img
    command: echo

volumes:
  jupyterhub_data:

networks:
  jupyter:
          #  internal:

user_465139 · Answer

Disclaimer: take this answer with a huge pinch of salt as I am just learning how to run JupyterHub and JupyterLab in Docker containers. And in all fairness to all JupyterHub and Docker and Traefik experts, it is not easy for a beginner to figure out which settings to use.

I had the same problem as the OP, but his solution (in the comment of 2020-04-06) didn't work for me. What did work was the following entry in jupyterhub_config.py:

c.DockerSpawner.remove = True

This removes the JupyterLab containers after their users log out of JupyterHub. If they are left to "linger", then the "Unhandled error starting tester1's server: The 'ip' trait of a Server instance must be a unicode string..." will occur if the same user logs in again. Don't ask me why. Inspiration came from this SO question.

PS: I used Docker version 19.03.12 in an Ubuntu 20.04.1 host, Traefik Version 2.2, JupyterHub and -Lab Version 1.2.2.

user_12247535 · Answer

Command docker-compose down kill current network. After docker-compose up -d new network is being created with same name, but different NetworkID. You can check NetworkID of containers with:

docker inspect --format='{{range .NetworkSettings.Networks}}{{.NetworkID}}{{end}}' CONTAINER_ID

I suppose this is the main reason of error:

The 'ip' trait of a Server instance must be a unicode string, but a value of None was specified

because in order to restart specific user container after docker-compose down you can disconnect it from old network, connect to new one:

docker network disconnect NETWORK_NAME CONTAINER_ID
docker network connect NETWORK_NAME CONTAINER_ID

and finally, you can start this container after logging in JupyterHub web-interface under a specific user, which container got this error.

Indeed, in this situation you can use Laryx Decidua answer to remove containers after docker-compose down. Another option is to create an external network like in this accepted answer: https://stackoverflow.com/a/51476836/12247535

More about this behavior / problem of docker-compose in thread https://github.com/docker/compose/issues/5745

Docker-compose jupyterhub issue

2 Answers