![]() It lets you open a local port and forward traffic via stdin/stdout to any command you specify. " tcpserver" is an open source utility that's available in most linux package repositories. Connect a VNC session to a pod with a virtual desktop running in it (see: XVFB).Run a one-time migration script on data in a staging cluster without needing to create a container for it.Access the production database from local database tools without needing to fiddle with auth (usually localhost has root auth).Attach a TCP debugger to a pod running locally.Check what the /healthz HTTP endpoint of a pod is returning in a production cluster.But along the way, I picked up a few tools to help debug these kinds of issues, so it wasn’t a complete waste of time.It's a common scenario: You want a port on your local computer to magically forward traffic to your pod/container (or vice-versa.) Use cases Of course I was a little irritated that the issue ended up being a “Remote X11 for Dummies” issue. So one more change to the run script: docker run -net=host -env="DISPLAY" -volume="$HOME/.Xauthority:/root/.Xauthority:rw" xeyesĪnd it finally worked. The file needs to wind up in /root since that is the default user running processes inside the container. There are a few ways to pass X11 authentication through to the container I think the easiest is to give the container access to the. Once the problem was identified, fixing it was easy. ![]() I had discounted this possibility out of a misguided belief that X11 authentication issues led to different error messages. That was when I realized that the issue must be X11 authentication. Sure enough I could see X11 traffic briefly over that port when running xeyes inside the interactive container. Out of an excess of paranoia, I ran tcpdump on the host: (This is CentOS 7, so the old standby netstat is no longer there by default.) So why can’t it open the display? I next installed nc inside the container, and used that great little program to confirm that I could connect to localhost:6010. Time to create an interactive session so we can do a little debug: docker run -it -net=host -env="DISPLAY" -rm xeyes /bin/bashīy using ss -an inside the container we can see that something is listening on port 6010. The error message was still Error: Can't open display, just as when I was using bridge mode. Our Docker run command is now: docker run -net=host -env="DISPLAY" -rm xeyes As long as network isolation isn’t a necessity, this works quite well. So the bound port isn’t visible from inside the container.įortunately, Docker has a “host” network mode, where it allows the container to see the same network stack that the host uses. In bridge mode, the lo interface inside the container is different from the lo interface on the host. However, in this case, the SSH daemon only binds its port to the lo interface on the host. This works because Docker creates a “bridge” interface and handles routing all outgoing traffic to the right address. Usually processes in a Docker container “just work” as a network client for example, running yum in a CentOS container, like we did in the Dockerfile above, works just fine. So we need our Docker container to connect to port 6010 on the host. All traffic is forwarded through the SSH connection, where the SSH client sends it on to whatever X server is configured. ![]() The port is opened on the remote machine by the SSH daemon on behalf of the SSH client. Usually the ports start at 6010, which corresponds with a DISPLAY environment variable of localhost:10.0. With SSH X11 forwarding, instead of a UNIX domain socket, clients communicate with a TCP/IP socket on port 6000+(display number). However, in this case the X server was on the other side of an SSH tunnel from the machine running the Docker container. Normally, to allow the client to connect to the X server would mean mapping the local UNIX domain socket into the Docker container using the -volumeargument. However, this still won’t work because xeyes won’t be able to connect to the X server. For starters, we need to pass our DISPLAY environment variable through to the container: Of course, it isn’t quite that simple, because xeyes inside the container won’t be able to see our X server. from the directory with the Dockerfile and have an image we can run with docker run xeyes. This Dockerfile will do the trick: FROM centos I did a little searching on Docker Hub, but didn’t immediately find what I wanted. First step, to remove as many variables as possible, was to make a Docker container with a basic X11 client application for testing. The goal was to get a GUI program to run, in Docker, with the X server on the other side of an SSH tunnel. Docker is an interesting technology to work with, because sometimes it feels like just regular coding, and sometimes it feels like typing with oven mitts on.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |