Using docker with running process - docker

I've created this docker file which works for
FROM debian:9
ENV CF_CLI_VERSION "6.21.1"
# Install prerequisites
RUN ln -s /lib/ /lib64
RUN apt-get update && apt-get install curl -y
RUN curl -L "https://cli.run.pivotal.io/stable?release=linux64-binary&version=${CF_CLI_VERSION}" | tar -zx -C /usr/local/bin
And it works as expected, now I run it like following
docker run -i -t cf-cli cf -v
and I see the version
Now every command which I want to run is something like
docker run -i -t cf-cli cf -something
my question is how can I enter into container and do ls etc without every-time doing
docker run -i -t cf-cli ...
I want to enter to the container like you enter to machine.

Step 1:
Run the container in background:
docke run -d --name myapp dockerimage
Step2:
Exec into the containr myapp:
docker exec -it myapp bash
run any commands inside as u wish

Have a look at docker exec. You'll probably want something like docker exec -it containername bash depending on the shell installed in the container.

If I correcly understand you just need
docker exec -it <runningcontainername> bash

Related

Trying to copy a script into a detached Docker container, and execute it with docker exec

Right now I am setting my Docker instance running with:
sudo docker run --name docker_verify --rm \
-t -d daoplays/rust_v1.63
so that it runs in detached mode in the background. I then copy a script to that instance:
sudo docker cp verify_run_script.sh docker_verify:/.
and I want to be able to execute that script with what I expected to be:
sudo docker exec -d docker_verify bash \
-c "./verify_run_script.sh"
However, this doesn't seem to do anything. If from another terminal I run
sudo docker container logs -f docker_verify
nothing is shown. If I attach myself to the Docker instance then I can run the script myself but that sort of defeats the point of running in detached mode.
I assume I am just not passing the right arguments here, but I am really not clear what I should be doing!
When you run a command in a container you need to also allocate a pseudo-TTY if you want to see the results.
Your command should be:
sudo docker exec -t docker_verify bash \
-c "./verify_run_script.sh"
(note the -t flag)
Steps to reproduce it:
# create a dummy script
cat > script.sh <<EOF
echo This is running!
EOF
# run a container to work with
docker run --rm --name docker_verify -d alpine:latest sleep 3000
# copy the script
docker cp script.sh docker_verify:/
# run the script
docker exec -t docker_verify sh -c "chmod a+x /script.sh && /script.sh"
# clean up
docker container rm -f docker_verify
You should see This is running! in the output.

Create MakeFile that Runs Docker Image and Changes Directory?

I would like to create a makefile that runs a docker container, automatically mount the current folder and within the container CD to the shared directory.
I currently have the following which runs the docker image and mounts the directory with no issue. But I am unsure how to get it to change directory.
run:
docker run --rm -it -v $(PWD):/projects dockerImage bash
I've seen some examples where you can append -c "cd /projects" at the end so that it is:
docker run --rm -it -v $(PWD):/projects dockerImage bash -c "cd /projects"
however it will immediately exit the bash command afterwards. Ive also seen an example where you can append && at the end so that it is the following:
docker run --rm -it -v $(PWD):/projects dockerImage bash -c "cd /projects &&".
Unfortunately the console will just hang.
You can specify the working directory in your docker run command with the -w option. So you can do something like this:
docker run --rm -it -v $(PWD):/projects -w /projects dockerImage bash
You can find this option in the official docs here https://docs.docker.com/engine/reference/run/.

How to specify in Dockerfile that the image is interactive?

I have created a docker container that runs a command line tool. The container is supposed to be interactive. Am I somehow able to specify in the Dockerfile that the container is always started in interactive mode?
For reference this is the dockerfile:
FROM ubuntu:latest
RUN apt-get update && apt-get -y install curl
RUN mkdir adr-tools && \
cd adr-tools && \
curl -L https://github.com/npryce/adr-tools/archive/2.2.0.tar.gz --output adr-tools.tar.gz && \
tar -xvzf adr-tools.tar.gz && \
cp */src/* /usr/bin && \
rm -rf adr-tools
CMD ["/bin/bash"]
EDIT:
I know of the -it options for the run command. I'm explicitly asking for a way to do this in the docker file.
EDIT2:
This is not a duplicate of Interactive command in Dockerfile since my question addresses an issue with how arguments specified to docker run can be avoided in favor of specifying them in the Dockerfile whereas the supposed duplicate addresses an issue of interactive input during the build of the image by docker itself.
Many of the docker run options can only be specified at the command line or via higher-level wrappers (shell scripts, Docker Compose, Kubernetes, &c.). Along with port mappings and network settings, the “interactive” and “tty” options can only be set at run time, and you can’t force these in the Dockerfile.
You can use the docker run command.
docker build -t curly .
docker run -it curly curl https://stackoverflow.com
The convention is:
docker run -it IMAGE_NAME [COMMAND] [ARG...]
Where [COMMAND] is curl and [ARG...] are the curl arguments, which is https://stackoverflow.com in my example.
-i enables interactive process mode. You can't specify this in the Dockerfile.
-t allocates a pseudo-TTY for the container.
Are you looking for the -it option?
From the Docker documentation:
For interactive processes (like a shell), you must use -i -t together
in order to allocate a tty for the container process.
So, for example you can run it like:
docker run -it IMAGE_NAME [COMMAND] [ARG...]
Actually, in Ubuntu, I am running Apache Server in the background.
But for you, Try with below command and you should be able to go inside docker container.
docker exec -i -t your_container_name bash

Practically, what is the difference between docker run -dit(-itd) vs docker run -d?

I've used docker run -it to launch containers interactively and docker run -d to start them in background. These two options seemed exclusive. However, now I've noticed that docker run -dit (or docker run -itd) is quite common. So what is the difference? When -it is really needed together with -d?
Yes, sometimes, it's necessary to include -it even you -d
When the ENTRYPOINT is bash or sh
docker run -d ubuntu:14.04 will immediately stop, cause bash can't find any pseudo terminal to be allocated. You have to specify -it so that bash or sh can be allocated to a pseudo terminal.
docker run -dit ubuntu:14.04
If you want to use nano or vim with any container in the future, you have to specify -it when the image starts. Otherwise you'll get error. For example,
docker run --name mongodb -d mongo
docker exec -it mongodb bash
apt-get update
apt-get install nano
nano somefile
It will throw an error
Error opening terminal: unknown.

Why is it not possible to call locale-gen with sudo inside a docker container?

$ sudo docker run -it --rm --privileged=true debian-jessie su - dib -c /bin/bash
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
dib#4a199f1d95f9:~$ sudo locale-gen
Generating locales (this might take a while)...
en_US.UTF-8... done
$
At this point the docker container exists (not running any longer).
On the other hand, when using:
$ sudo docker run -it --rm --privileged=true debian-jessie /bin/bash
root#55e8d2ab53f1:/# locale-gen
Generating locales (this might take a while)...
en_US.UTF-8... done
Generation complete.
root#55e8d2ab53f1:/#
locale-gen runs fine without problems and the docker container continues to run.
Can somebody please explain, why the locale-gen runs fine in the second example but not in the first?
Are there any solutions or workarounds running locale-gen with sudo?
Technical background: the docker images were generated with diskimage-builder from OpenStack. I tested this with three images: debian-jessie, debian-stretch and ubuntu-trusty - all gave the same results.
For the files:
Did not find the root cause - but a workaround: starting the docker with runuser instead of su solved the problem for me:
sudo docker run -it --rm --privileged=true debian-jessie runuser -l dib -c /bin/bash

Resources