Share and learn in the Docker community.
Hi,
I just did below steps and docker ps returns exited(0) state, kindly review and any idea would be appreciated.
docker run -it confluentinc/cp-kafka-connect /bin/bash
docker ps -a
$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
86a6fc488a35 confluentinc/cp-kafka-connect “/bin/bash” About a minute ago Exited (0) 22 seconds ago sad_engelbart
Regards
Hello and good afternoon,
let’s recap what the command docker run -it confluentinc/cp-kafka-connect /bin/bash is doing:
run => start a container
confluentinc/cp-kafka-connect => based on this image
-it => run an interactive terminal in the container (see Docker run reference | Docker Documentation)
/bin/bash => instead of the command intended by the creator if the image use this command (see Docker run reference | Docker Documentation)
Alltogether this results in a shell in a container based on an image where the command intended by the image’s creator is not used.
If the command for a container exits the whole container is stopped. So if you exit this shell the container stops. That is working as designed.
I guess you want to create a container based on confluentinc/cp-kafka-connect and then have an interactive terminal into this container.
So first start the container and let it run in the background with
docker run -d confluentinc/cp-kafka-connect
then find out the container’s name or id with
docker ps -a
and now you can have an interactive terminal into this running container with
docker exec -it <containername|containerid> /bin/bash
If you exit this shell the container is still running in the background 
.
Hi Matthias,
Thanks for your kind explanation. I have followed your steps as below, but seems the contains is still exit status. Kindly review and any idea would be appreciated.
[opc@vm1 ~]$ docker run -d confluentinc/cp-kafka-connect
be12d77428ab38a08ed67aec1b9fcd0b60f23d9b161868754feeba1462cfd4b4
[opc@vm1 ~]$ docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
be12d77428ab confluentinc/cp-kafka-connect “/etc/confluent/dock…” 10 seconds ago Exited (1) 6 seconds ago crazy_nash
[opc@vm1 ~]$ docker exec -it be12d77428ab /bin/bash
Error response from daemon: Container be12d77428ab38a08ed67aec1b9fcd0b60f23d9b161868754feeba1462cfd4b4 is not running
[opc@vm1 ~]$
Regards
Hello,
You can still have a look at a container’s log even if it already has stopped with
docker logs <containerid|containername>
Maybe there is some hint why the container stops (i.e. some environment-variables are missing, could not connect to some other service, …)?
Hi Matthias,
Then, I getting below failed logs with docker logs cmd, may I ask how do we proceed to troubleshoot on this?
[opc@vm1 ~]$ docker exec -it 520f55284ea8 /bin/bash
Error response from daemon: Container 520f55284ea886535095d6170f25cfeb2324dd8cf7db556700e6994b28c17501 is not running
[opc@vm1 ~]$ docker logs 520f55284ea8
===> User
uid=1000(appuser) gid=1000(appuser) groups=1000(appuser)
===> Configuring …
CONNECT_BOOTSTRAP_SERVERS is required.
Command [/usr/local/bin/dub ensure CONNECT_BOOTSTRAP_SERVERS] FAILED !
===> User
uid=1000(appuser) gid=1000(appuser) groups=1000(appuser)
===> Configuring …
CONNECT_BOOTSTRAP_SERVERS is required.
Command [/usr/local/bin/dub ensure CONNECT_BOOTSTRAP_SERVERS] FAILED !
===> User
uid=1000(appuser) gid=1000(appuser) groups=1000(appuser)
===> Configuring …
CONNECT_BOOTSTRAP_SERVERS is required.
Command [/usr/local/bin/dub ensure CONNECT_BOOTSTRAP_SERVERS] FAILED !
[opc@vm1 ~]$
Thanks
Hello,
seems that at least the environment-variable CONNECT_BOOTSTRAP_SERVERSis missing.
From the image’s homepage at Docker Hub I got to this docker-compose.yml where a lot of environment-variables are set (using docker-compose.yml in this case - but can also be done using docker ...).
Hi Matthias,
As per your guidance, I have tried docker compose, but I don’t have much skills to configure on docker-compose.yml.
[opc@vm1 ~]$ docker-compose -f docker-compose.yml up -d
Creating network “opc_default” with the default driver
ERROR: Failed to Setup IP tables: Unable to enable SKIP DNAT rule: (iptables failed: iptables --wait -t nat -I DOCKER -i br-133400fa89d6 -j RETURN: iptables: No chain/target/match by that name.
(exit status 1))
What I would like to implement as below, would you please review and your guidance would be appreciated.
wget https://github.com/lensesio/stream-reactor/releases/download/1.2.3/kafka-connect-mqtt-1.2.3-2.1.0-all.tar.gz
mkdir -p kafka-connect-mqtt
tar -C kafka-connect-mqtt -xvf kafka-connect-mqtt-1.2.3-2.1.0-all.tar.gz
docker run -it confluentinc/cp-kafka-connect /bin/bash
mkdir -p /etc/kafka/plugins/lib
docker ps -a
cd kafka-connect-mqtt/
$ docker cp kafka-connect-mqtt-1.2.3-2.1.0-all.jar fdea37d324a0:/etc/kafka/plugins/lib/kafka-connect-mqtt-1.2.3-2.1.0-all.jar
Regards
I’m not a kafka-specialist - but I was able to run all of the mentioned commands successfully 
With docker run -it ... /bin/bash you end in a bash within a container. There you have to run the next command mkdir -p ....
Now open a new terminal and run the next commands - docker ps -a to get the container’s id|name and now you can go to the correct directory (where you uncompressed the .tar.gz-file) and use docker cp ... to copy a file into the container.
Now I went back to the terminal in the running container and checked/verified that the .jar-file is placed at the correct position.
yes, it’s able to run all of the mentioned commands successfully. But the problem is if you run docker ps -a the container status, it’s showing as “starting” for a few minutes, after that appearing as “unhealthy” from my end. It’s the problem which i want to get your helps, please kindly check from your side if getting same behavior as well.
The reason you (and I, too) read (unhealthy) is because a healthcheck implemented in the image fails. Normally a healthcheck (if used) checks that the process x is running inside the container or that there is something answering on port y. Even if the healthcheck fails (for whatever reason) the container is still running.
As the container was started with /bin/bash instead of the command/service/process intended by the image’s creator this is normal.
I haven’t read the whole kafka-documentation what to do next. But I can assure that the (unhealthy) is normal at this point.
If you went through the complete process of setting up your container (which seems a little more complicated compared to the images/containers I’ve used up to now) the result should be a container with a (healthy) status .
Thanks for your info. As the next steps of above, I have deployed these unhealthy container to kubernetes engine. Then with kubectl get pods, it returns the status of “crashloopbackoff”. Then proceed docker describe to see logs, there mentioned that status of crashloopbackoff was caused by “back-off restarting failed container”. That’s reason why I go back to docker container steps to look into issue. So, i wondering if the issue is caused by those docker steps.
Seems i don’t have right to post screenshot for your reference. if you need screenshot on those, let me know your email address. Thanks.
Now I am a little confused.
I prefer to proceed step by step and first somehow create an image that can be successfully started as a container. Afterwards you may add additional files to the container (if not already done during image-creation). And then you can take care of Kubernetes.
Where is the complete recipe which should be followed?
With this excerpt of a recipe (where did you get it from?)
we have a container running bash but not the service intended by the creator of the image confluentinc/cp-kafka-connect.
Happy sunday,
thank you for the link with the complete recipe.
If I have started the container with docker run -it confluentinc/cp-kafka-connect /bin/bash, copy a file into the container and then do a docker commit ... the result is an image. But If I start a container based on this newly created/commited image I again have a container running /bin/bash instead of /etc/confluent/docker/run (as in the image confluentinc/cp-kafka-connect).
So I believe that there is a error in the recipe. 