Overriding entrypoint and command in docker-compose.yml

Docker Engine Compose
1

I’m trying to override an ENTRYPOINT and CMD in a compose file. I’ve gotten a working solution, but I can’t seem to reduce it.

Here is an example service container that launches a bash shell for me to work in with a virtual environment activated:

  # Ephemeral api service
  x-api:
    entrypoint: /bin/bash -c "/bin/bash -c \"$${@}\""
    command: |
      /bin/bash -c "
        set -e
        source ~/.env/api/bin/activate
        p-api config
        /bin/bash || exit 0
      "
    depends_on: *platform-depends_on
    environment: {<<: *platform-environment}
    image: *platform-image
    ports:
      - "5000:5000"
    volumes: *platform-volumes
    working_dir: /srv/api

Three (or is it 4? or 5?) layers of bash shells seems to be over complicated. Is there a simpler solution?

2

didn’t try it out, but does something like the following work?

entrypoint: /bin/bash
command: "--init-file ~/.env/api/bin/activate p-api config"
3

(1) Docker containers are plenty of isolation themselves. In your Dockerfile, don’t bother creating a virtual environment, just pip install packages into the “global” space (on an Ubuntu base you’ll see files in `/usr/local/lib/python2.7/dist-packages’).

(2) Or, this is a fine use case for an entrypoint script:

#!/bin/sh
. /root/.env/api/bin/activate
p-api config
exec "$@"

Also note that the activate script is strictly optional, and you could instead

#!/bin/sh
/root/.env/api/bin/p-api config
exec "$@"

and not change the $PATH for the main container execution.

4

@dmaze I actually have to use multiple virtualenvs as my project has multiple python apps with different dependencies and I shouldn’t allow them to conflict with each other.

Interestingly, I came across pipenv on a hacker news submission of mine last night, and created a nice Dockerfile that bootstraps Debian with pyenv, a custom python runtime, and pipenv for a usecase similar to mine.

@think the init file solution looks like a potential sol’n. Thanks!

5

In which case, each app should ideally be inside a separate container, each of which has it’s own tailored python environment.

1 Like