We recently had the idea to create a VNC Desktop APB that would deploy a pod running VNC. The idea was that this might be useful for troubleshooting connectivity issues within the cluster by including a web browser along with the bind-utils and net-tools packages.
As with most APB's we've developed, there were several iterations before we ended up with something we were satisfied with sharing. The earliest version of the APB created a deployment config for a pod running a VNC server and an associated service. But this meant you had to manually configure a standard VNC viewer to connect to the pod. The service also wasn't accessible from outside of the cluster, which could make connecting to it difficult.
At this point, we decided it would be much easier to use if we had noVNC running so that we could connect to the VNC server by pointing a web browser at a route. Once we got noVNC working we realized we had something interesting. Whether troubleshooting, trying out different desktops, or maybe even setting up kiosks by launching multiple instances in different namespaces this APB shows some potential.
The Containers
With most APB's there are at least 2 containers to think about creating. The first is the application container that will run the service you want to deploy and the second is the APB container that will handle the logic for deploying the container. As mentioned this is how we started with the VNC APB. As we moved on we added a second VNC container using a different version of Fedora as the base and the noVNC container to make connecting easier, for a total of four containers.
The vnc-desktop Containers
Running VNC within a container actually proved to be very easy. By using the -fg
flag vncserver remains in the foreground. The remainder of the logic in the entry point script deals with arbitrary UID support and configuring the environment based on choices made by the user.
By changing just the FROM statement in the Dockerfile we were able to create containers for both Fedora 27 and Fedora 28.
The vnc-client Container
This container was very easy to create thanks to a launch script that was recently added to noVNC. Aside from installing dependency packages all we needed to do is clone the git repository, link the vnc.html file, and set the entry point to start the script.
RUN git clone https://github.com/novnc/novnc
RUN ln -sf /novnc/vnc.html /novnc/index.html
ENTRYPOINT /novnc/utils/launch.sh --vnc vnc-desktop:5901
The APB Container
The VNC Desktop APB is pretty standard. Right now we have included two plans, with each plan being tied to a version of Fedora.
One of the first questions that came up when developing the APB was which desktop to use. But since APB's make choices easy we decided to make several available. Right now we have nine options available and would like to add Gnome and Cinnamon if we can figure out how to get them running in a container.
As you might imagine users will also probably prefer one shell and initial resolution combination over others so we made multiple options available for each. Each of these parameters are passed into the container as environment variables on the vnc-desktop pod where they are acted on by the entry point script.
- name: de
title: Desktop Environment
type: enum
enum: ['fvwm', 'i3', 'KDE', 'LXDE', 'LXQt', 'MATE', 'Sugar', 'twm', 'Xfce']
default: 'Xfce'
updatable: true
- name: deshell
title: Shell
type: enum
enum: ['bash', 'csh', 'ksh', 'sh']
default: 'bash'
updatable: true
- name: resolution
title: Desktop Resolution
type: enum
enum: ['800x600', '1024x768', '1280x1024', '1360x768', '1440x900', '1920x1080']
default: '1360x768'
updatable: true
These parameters are exposed in the UI as drop downs where users can make their selections.
Connecting
Once choices are made and the APB completes provisioning you will be left with two pods and a route.
Clicking on the link will open a new window. When you press connect you'll be prompted for a password.
You should now have a VNC session running in your browser:
Updating Your Choices
You may have noticed in the snippet above that each of the parameters included a line, updatable: true
. We have also included the updates_to
option on each plan. By doing so users can now edit the provisioned service and switch between distributions and desktop environments, resolutions, and shell combinations at will until they find something that suits their needs. The YouTube demo linked below demonstrates this functionality.
YouTube
Code Links
VNC Desktop APB
https://github.com/fusor/dockerfiles/tree/master/vnc-desktop:f28
Fedora 27 Container
noVNC Container
About the author
Browse by channel
Automation
The latest on IT automation that spans tech, teams, and environments
Artificial intelligence
Explore the platforms and partners building a faster path for AI
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
Explore how we reduce risks across environments and technologies
Edge computing
Updates on the solutions that simplify infrastructure at the edge
Infrastructure
Stay up to date on the world’s leading enterprise Linux platform
Applications
The latest on our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Developer resources
- Customer support
- Red Hat value calculator
- Red Hat Ecosystem Catalog
- Find a partner
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit