I have google cloud VM instance running Ubuntu 18 and I have installed ngnix and pulled this docker image https://github.com/lensesio/fast-data-dev. But the problem is I cannot access container when i run following command
docker run -d -p 2181:2181 -p 3030:3030 -p 8081-8083:8081-8083 \
-p 9581-9585:9581-9585 -p 9092:9092 -e ADV_HOST=[VM_EXTERNAL_IP] \
-e RUNNING_SAMPLEDATA=1 lensesio/fast-data-dev
It is supposed to work on myexternalip:3030 but it doesn't open. I assume because I have to expose docker ports to external web because
curl 0.0.0.0:3030
returns response. I opened mentioned ports in the command above in the firewall.
You need to make sure those ports you expose in docker are opened both in the Instance and in the VPC firewall.
In Google Cloud you can deploy a container inside a Compute Engine instance when you create it (see Deploying a container on a new vm instace).
It is easier (and faster) than doing it on your own, and you all your container port mappings defined in the same place you open the firewall ports.
BTW - Don't use the IP address 0.0.0.0: it's the unspecified newtwork address.
It might be filtered silently by firewalls or routers. Use the loopback address - 127.0.0.1
In order to expose the port 3030 on the public IP (VM_EXTERNAL_IP) at the Instance , at VPC level there must be a rule on the firewall for the specific protocol/port to allow it.[1]
A generic broad scope allow firewall rule definition would be [2]:
gcloud compute --project=[PROJECT] firewall-rules create allow-lenses-io-3030 --direction=INGRESS --priority=1000 --network=default --action=ALLOW --rules=tcp:3030 --source-ranges=0.0.0.0/0
You can limit the scope of the rule as needed/wanted/required.[3]
[1] https://cloud.google.com/vpc/docs/firewalls
[2] https://cloud.google.com/sdk/gcloud/reference/compute/firewall-rules/create
[3] https://cloud.google.com/vpc/docs/using-firewalls
Ran this on my VM, and I got this error:
docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/create: dial unix /var/run/docker.sock: connect: permission denied.
See 'docker run --help'.
If you are getting the same error above, you would need to check the file permission by running this command
~$ ls -la /var/run/docker.sock
After changing the file permission to 666 by running this command below:
sudo chmod 666 /var/run/docker.sock
This should be the file permission
srw-rw-rw- 1 root docker 0 Dec 17 14:40 /var/run/docker.sock
Then, I was able to successfully run your command
docker run -d -p 2181:2181 -p 3030:3030 -p 8081-8083:8081-8083 -p 9581-9585:9581-9585 -p 9092:9092 -e ADV_HOST=[VM_EXTERNAL_IP] -e RUNNING_SAMPLEDATA=1 lensesio/fast-data-dev
Unable to find image 'lensesio/fast-data-dev:latest' locally
latest: Pulling from lensesio/fast-data-dev
05e7bc50f07f: Pull complete
476521bd3084: Pull complete
c4c2aa517a1c: Pull complete
7f1b06a24ab4: Pull complete
bae2eaa88cbb: Pull complete
2d9ee69ece21: Pull complete
4da70d410da1: Pull complete
59abe7119ed3: Pull complete
ed6eaf2a0a19: Pull complete
25aa81bc4e49: Pull complete
8ccac59252e2: Pull complete
225a5ca8c99d: Pull complete
6d7f2dab62f4: Pull complete
Digest: sha256:a40302e35e1e11839bcfe12f6e63e0d665f098249e0ce9c111a2e212215f8841
Status: Downloaded newer image for lensesio/fast-data-dev:latest
051711522df0198d2f94825dee8d2556e137c7b31501b68cd73541ae8d4286d7
Related
I have a server with Truenas scale in it. I tried to follow this tutorial.
The concept goes within this lines:
Server: Truenas Scale, vm(ubuntu server) in truenas, docker inside the vm.
The goal is to create docker containers in the vm but use the nfs shared folders to save the data from the containers. Al thought the process is intimidating with a number of nonsense here and there, i manage to deploy the nfs and the vm and make the vm to "talk" to the host machine(truenas) following the guide above.
Truenas:
ip: 192.168.2.144
user:docker(1000)
group:docker(1000)
pool:main
datasheet:docker-vm
shared-path: ":/mnt/main/docker-vm/docker"
VM(Ubuntu):
ip:192.168.2.143
uid:docker(1000)
gid:docker(1000)
The proces to mount the shared path to the VM is:
$ sudo mkdir /nfs
$ sudo mount 192.168.2.144:/mnt/main/docker-vm/docker
$ sudo touch /nfs/hello_world // Output: Permission denied.
To solve this problem we have to do the next step:
After that you have to go to the true nas UI and add the user "docker" as Maproot User and the group "docker" as Maproot Group and the host ip(in this case 192.168.2.143) to the UNIX (NFS) Shares.
After that i am able to:
$ touch /nfs/hello_world
$ ls /nfs //Output : -rw-rw-rw- 1 docker docker 0 Oct 9 12:36 helo_wold
The next step is to create the Portainer container and store the files in the nfs:
$ mkdir /nsf/portainer_data
$ docker run -d -p 8000:8000 -p 9443:9443 --name portainer --restart=always -v
/var/run/docker.sock:/var/run/docker.sock -v /nfs/portainer_data:/data
portainer/portainer-ce:latest
The docker run command return this error:
docker: Error response from daemon: error while creating mount source path
'/nfs/portainer_data': mkdir /nfs: read-only file system.
I am frustrated cuz i am able to create files and folders to the /nfs as user but the docker can't? I hope i covered the problem enough and someone can help me.
I have a docker file userPermissionDenied.df, here is its content:
FROM busybox:1.29
USER 1000:1000
ENTRYPOINT ["nc"]
CMD ["-l", "-p", "80", "0.0.0.0"]
I run the following commands:
> docker image build -t fooimg -f userPermissionDenied.df .
> docker container run fooimg
Now I expect the following output:
> nc: bind: Permission denied
But I am not getting any output at all:
the container just hangs. Why?
I am learning Docker through the Docker in Action by Jeff Nickoloff and that is where I got the use case from.
Given that you are running the nc command as a non-root user (due to the USER 1000:1000 directive in your Dockerfile), you might expect to see a "permission denied" error of some sort when nc tries to bind port 80.
In earlier versions of Docker that is exactly what would have happened, but a few years ago Docker was modified so that containers run with net.ipv4.ip_unprivileged_port_start=0, which means there are no longer any "privileged ports": any UID can bind any port.
You can see this setting by running sysctl inside a container:
$ docker run -it --rm -u 1000:1000 alpine sysctl -a |grep net.ipv4.ip_unprivileged_port_start
net.ipv4.ip_unprivileged_port_start = 0
the container just hangs. Why?
The container isn't "hanging"; it is successfully running nc -l -p 80, which is waiting for a connection to the container on port 80. If you were to use curl or some other tool to connect to port 80 in that container, it would display any data send over the connection and then the container would exit when the connection is closed.
I am following this blog on how to connect to a docker instance: https://phoenixnap.com/kb/how-to-ssh-into-docker-container. It mentions using docker attach <name>
Trying this on my ec2 instance gives us:
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
849844c1e3a5 6501862...us-east-618356524 "docker-entrypoint.s…" About a minute ago Up About a minute 0.0.0.0:32788->8401/tcp ecs-prod-clia-lab-5-Applicationprodclia-lab-8c88d2e0bc83cfb1230
Now let's try to `docker attach <instance-name>
$ docker attach ecs-prod-clia-lab-5-Applicationprodclia-lab-8c88d2e0bc83cfb1230
Error: No such container: ecs-prod-clia-lab-5-Applicationprodclia-lab-8c88d2e0bc83cfb1230
So that actually does not work? What is the correct way to do this?
To get a shell in a running container, do this:
$ docker exec -it <container-id> /bin/sh
The attach sub-command gives you access to a running containers stdout. That's not what you want here
However, if your conainer is meant to provide SSH as a service, you'll need to run it in such a way that it's exposed on the host, on some available port (like 2222).
The you'd simply "SSH in" like this:
$ ssh 127.0.0.1 -p 2222
I'm on a fresh Fedora CoreOS which comes with Docker version 19.03.11.
My core user is in the docker group:
[core#localhost ~]$ groups
core adm wheel sudo systemd-journal docker
Following the deployment instructions for portainer, I create a new Portainer container like this (as core or root, it doesn't even matter):
$ docker volume create portainer_data
$ docker run -d -p 9000:9000 -p 8000:8000 --name portainer --restart always -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer
And when I try to connect to the local daemon:
Permissions of /var/run/docker.sock:
[core#localhost ~]$ ll /var/run/docker.sock
srw-rw----. 1 root docker 0 Aug 2 10:02 /var/run/docker.sock
Even if I chmod o+rw /var/run/docker.sock it doesn't work. This indicates that the problem might be in the container itself so I tried to access it but I can't:
[core#localhost ~]$ docker exec -it portainer sh
OCI runtime exec failed: exec failed: container_linux.go:349: starting container process caused "exec: \"sh\": executable file not found in $PATH": unknown
All resources I found so far suggest to add the user to the docker group, which I did, reboot the machine, which I did, or set 666 on /var/run/docker.sock, which I did but prefer not to. Nothing helped.
Any idea what's wrong and how to fix it?
If it is a SELinux issue, try first to follow portainer/portainer issue 849
Correct way is to add :z to the volume mapping, so you're not defeating the purpose of docker.
Like so:
docker run -d -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock:z portainer/portainer
Also we need a way to add the z or Z flag in Portainer for new containers. This has been a feature since 1.7 e.g. 2015 in Docker.
That, or using dpw/selinux-dockersock
Thanks to MrPaperbag on the Portainer Discord I found out it's because of a restriction by SELinux.
Found the solution here: https://nanxiao.me/en/selinux-cause-permission-denied-issue-in-using-docker/
Either run docker run with --privileged, or set SELinux mode as permissive using setenforce 0. Probably there's a way to properly configure SELinux instead of just circumventing it, however, for my use case this is good enough.
My container of play/scala application starts at [info] p.c.s.AkkaHttpServer - Listening for HTTP on /0.0.0.0:9000. But I am unable to connect to it from the browser. I am running the container on my windows machine after having build the image using Docker for Windows
The Dockerfile is
FROM openjdk:8
WORKDIR deploy
COPY target/universal/myapp-1.0.zip .
COPY conf/logback_dev.xml ./logback.xml
COPY conf/application_dev.conf ./application.conf
RUN unzip myapp-1.0.zip
RUN chmod +x myapp-1.0/bin/myapp
EXPOSE 9000
ENTRYPOINT myapp-1.0/bin/myapp -Dplay.http.secret.key=changemeplease -Dlogger.file=/deploy/logback.xml -Dconfig.file=/deploy/application.conf
I am starting the container as docker run myApp -p 9000:9000 -network="host" and also tried docker run myApp -p 9000:9000 -network="host"
UPDATE
this is interesting.
If I specify image name before port then the application isn't reachable
docker run myApp -p 9000:9000
In docker container ps -a, I see (no mapping of localhost:9000 to 9000)
C:\Users\manuc>docker container ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
4d16547cd96d myApp "/bin/sh -c 'myApp…" 10 seconds ago Up 9 seconds 9000/tcp, 9042/tcp ecstatic_bell
but if I specify port before image name, then the application is reachable
docker run -p 9000:9000 myApp
In docker container ps -a, I see mapping of localhost:9000 -> 9000
C:\Users\manuc>docker container ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
24b571cc0057 myApp "/bin/sh -c 'MyApp…" 39 seconds ago Up 38 seconds 0.0.0.0:9000->9000/tcp, 9042/tcp silly_yalow
Things to do when your container is not behaving like you want:
Check if your application is running in your computer.
After you run your container, check if it is healthy with docker ps. If it is not healthy, the problem is usually in your application.
Ensure it is running without errors, check logs with docker logs <container-id>. If logs are ok, problem is usually in the container network configuration.
Ensure you can access your application with docker exec -it <container-id> bash. And try to access port with curl or wget. If it is not reachable problem can be in iptables, firewall, or your application.
If you can ensure all the steps above working as expected. The problem is in docker network configuration.
Docker network host only works in linux, not mac and windows. You can run container with docker run -p 9000:9000 myapp. Checkout documentation: https://docs.docker.com/network/host/#:~:text=The%20host%20networking%20driver%20only,the%20docker%20service%20create%20command.
General form of the docker run command is docker run [OPTIONS] IMAGE[:TAG|#DIGEST] [COMMAND] [ARG...] as you can see in documentation. You need to specify port options before image name.