Skip to content

Docker

Jump to bottom
Alyssa Dai edited this page Nov 15, 2023 · 6 revisions

Internal port vs host port

In the context of docker compose and within a docker network services talk to each other on their internal port number, and not the port that is exposed to the host. For example, given a stack with the following config

name: api
services:
  api:
    environment:
      NB_API_ALLOWED_ORIGINS: '*'
      NB_API_PORT: "8000"
      NB_GRAPH_ADDRESS: graph
      NB_GRAPH_DB: test_data/query
      NB_GRAPH_PASSWORD: admin
      NB_GRAPH_PORT: "5820"
      NB_GRAPH_USERNAME: admin
      NB_RETURN_AGG: "false"
    image: neurobagel/api:test
    networks:
      default: null
    ports:
    - mode: ingress
      target: 8000
      published: "8888"
      protocol: tcp
  graph:
    image: stardog/stardog:8.2.2-java11-preview
    networks:
      default: null
    ports:
    - mode: ingress
      target: 5820
      published: "5821"
      protocol: tcp
    volumes:
    - type: bind
      source: /home/ubuntu/stardog_root_test
      target: /var/opt/stardog
      bind:
        create_host_path: true
  query:
    environment:
      API_QUERY_URL: http://localhost:8000/
    image: neurobagel/query_tool:latest
    networks:
      default: null
    ports:
    - mode: ingress
      target: 3000
      published: "3000"
      protocol: tcp
networks:
  default:
    name: api_default

The api will be sending its requests to the port 5820 and not 5821.

Note

This may introduce issues for the API -> graph connection when the running API is not in the same Docker network as the graph, e.g. if you have locally spun up an API using Python but want to communicate with a Dockerized graph endpoint. In this scenario, you would likely need to manually specify the host port for the graph container in the query URL, rather than using the container port.

Setting environment variables

docker compose

  • environment instruction for a specific serve (in docker-compose.yml)
    • Defines variables to be set inside the container (compose config file itself cannot see the variables)
  • env_file instruction for a specific service (in docker-compose.yml)
    • Only sets variables inside the container (compose config file itself cannot see the variables)
    • Can replace / works without environment instruction to set variables in the container
    • Values inside specified env file can be quoted or unquoted, with same result in docker compose config
  • --env-file CLI argument (e.g., docker compose --env-file custom.env ...)
    • Only seen by the compose config itself, UNLESS the environment instruction is also used (in which case, variables that are defined under environment which also have a value inside the specified env file are passed to and can be used inside the container)
    • Essentially just for specifying a custom path for the .env file, and works the same as having a file named .env (in which case the --env-file argument is not needed)
    • Does not care about quotes around variable values in the file

Some important references:

docker CLI (docker run)

All three options below can set variables inside the container.

  • ENV instruction in dockerfile
    • Should work the same as --env / -e command-line argument (e.g., docker run -e MYVAR=MYVALUE)
    • Quotes are needed for variable values with spaces
    • Not required for an environment variable to be available to code in the container, such as if one of the below two options are used
  • --env-file CLI argument
  • --env/-e CLI argument
    • Quotes are needed for variable values with spaces, will override the same variable set via ENV instruction in the dockerfile

Some important references:

Clone this wiki locally