0

I'm testing a Docker container for development. And at the moment I just want to provision it with some libraries. After which I want to connect to it and test that I have all the libraries I need.

At the moment, my Dockerfile is just

FROM ubuntu:18.04

RUN apt update
RUN apt install -y git curl cmake libx11-dev libglu1-mesa-dev libxrandr-dev libxinerama-dev libxcursor-dev libxi-dev zlib1g-dev libasound2-dev libgtk2.0-dev libjack-jackd2-dev jq

But once it finishes building it terminates.

What CMD should I put at the end to keep it alive so I can shell in from another terminal?

1 Answer 1

1

Disclaimer: This is very much an anti-pattern since it looks like you are trying to create something similar to a VM, or at the very least a pet that you modify in place rather than making all your changes via code and redeploying a new container for each change.

That disclaimer aside, you just need a command that will hang indefinitely. The most common one I've seen in a tail -f /dev/null, e.g.:

FROM ubuntu:18.04

RUN apt update \
 && apt install -y \
      cmake \
      curl \
      git \
      jq \
      libasound2-dev \
      libglu1-mesa-dev \
      libgtk2.0-dev \
      libjack-jackd2-dev \
      libx11-dev \
      libxcursor-dev \
      libxinerama-dev \
      libxi-dev \
      libxrandr-dev \
      zlib1g-dev

CMD [ "tail", "-f", "/dev/null" ]

I've also rearranged the Dockerfile to merge the update and install commands, this is a best practice for Dockerfile's since it avoids having a stale apt update command used from the cache when you change the apt install command months later. Also, putting each package on a separate line is better for version control to see what changed if you add a single new package.

When using this, you would docker run -d --name your_container your_image to run it in the background, and then docker exec -it your_container /bin/bash to open a shell.

3
  • Thanks. My use case is I want to have a container with all the libraries I need to compile some code I'm working on. So the source code is external to the container and connected via volume. When you say this is an antipattern, are you saying I shouldn't use Docker for this?
    – interstar
    Commented Apr 8, 2019 at 13:57
  • 1
    @interstar I'm saying you would typically run the build with your code as the docker build process and include the resulting binary in a release image, usually with a multi-stage build. What I'm steering you away from is having a persistent mutable environment that would take time to recreate if a docker rm was run on your container.
    – BMitch
    Commented Apr 8, 2019 at 14:01
  • No. Sure. I'm not trying to make a mutable container. Once I try to compile my code inside, and discover what other dependencies are missing then I'll be adding them in the Dockerfile
    – interstar
    Commented Apr 8, 2019 at 16:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.