For many years, the cloud was a realm I mostly explored at work during the day. When it came time to climb back down the beanstalk and hang up my plumber overalls and pipe wrench, I was perfectly happy to exist on traditional Linux virtual private servers or physical machines at home like my MacBook and my good ol’ Commodore 64.
I recently had the need to create a personal cloud, to take advantage of off-site, secure, immutable cloud storage, as a protection against the rise of attacks from ransomware highwaymen targeting individuals. After having success with Microsoft Azure for this purpose, I decided to explore more of what Azure had to offer for an individual developer and hobbyist.
I spent some time pondering a simple proof-of-concept to explore Azure’s container services and weigh the options available for the various projects that bounce around inside my head. It didn’t take long for me to settle on a simple idea to play around in this new arena: Running an emulated Commodore 64 in the Azure Cloud.
Before jumping right into Azure, I first blew the cobwebs off my Docker skills and worked toward building a container on my local machine that would run the VICE Commodore Emulator, on a Linux kernel, and using the Ubuntu distro to provide the libraries and other software it needs.
I also had familiarity with running X11 programs remotely on Linux servers, so this seemed like an easy reach to be able to run the graphical VICE program and display it outside the container. Still…despite the fact that VICE emulates 1980s era Commodore computers, it seems to have fairly demanding requirements for graphics and audio capabilities on the host machine, and I was initially worried that I might eventually need a more powerful (and expensive) GPU on the container’s host within Azure cloud. I started down the path of using an NVIDIA base image for my Docker container, but fortunately I determined that having a GPU device and associated drivers is not required to get VICE up and running.
In the end, getting VICE to run in a Docker container and display remotely via X11 forwarding all worked out very well, and I was greeted with the welcoming blue Commodore 64 screen as the fruits of my labors.
Once I had a Commodore 64 running happily in my local Docker container, I dove into the Azure documentation on running containers within their cloud. After an initial wrong turn with attempting to run VICE using Azure’s Web App Service[1], I quickly found a tutorial for Azure’s Container Registry[2] that blew away the obscurity of jargon and cryptic references, and launched me into the “I’ve Got This” stratosphere and flying free toward my goal.
Knowledge is power, so it wasn’t long before I saw the happy blue screen of my Commodore 64 again, this time from the container running in the Azure cloud!
Having reached this point, the biggest challenge and disappointment was not involving Azure, Docker, or VICE, but rather discovering just how absolutely terrible X11 forwarding is for a usable experience in this case. I had done X11 forwarding before, even from remote Linux servers, but trying to use it over the internet and through the tunneling that occurs within the Azure networking stack makes it even worse than you could imagine. I was able to painstakingly enter and run the 10 PRINT program shown above, but it was an exercise in discipline and patience.
According to those that have come before me, VNC was the next avenue I needed to explore, so I rolled up my sleeves and went back into the Dockerfile, to add the ability to access VICE in the container via VNC. This didn’t take much more effort, and sure enough, interacting with the Commodore 64 using VNC was so much better!
My eventual goal for this proof-of-concept (hence the Part 1 in the title of this post) will be to utilize VICE serial networking and tcpser to communicate with the Commodore machine, at which point I won’t need to access the graphics output all. Nevertheless, I am extremely happy to reach my first goal of running an emulated Commodore 64 in the Azure Cloud!
Instructions
Docker
If you want to run your own Commodore 64 container in Azure, below is a brief set of instructions that outlines the basics. I’m not going to spend much time explaining Docker containers or the initial setup of Azure, so there may be a fair amount of reading you may want to do either beforehand or if you get stuck along the way. Nevertheless, I will try to provide enough here to make this a copy-and-paste affair resulting in a working demonstration, and will hopefully give you enough of a foundation to explore more on your own if this is a realm that is new to you.
Disclaimer: Please be aware that these instructions provide a demonstration for learning purposes only and are not at all intended to be a guide for how to run a container in Azure in a secure and proper way. In fact, running a container in Azure with SSH or especially VNC accessible remotely is extremely dangerous unless you know exactly what you are doing, and even then you’re probably the type of person who enjoys hang gliding or eating that delicious muffin you just dropped on the floor. You have been warned.
That said, my commodore-cloud repository on GitHub has all you need to build a Docker container that will run the VICE Commodore Emulator accessible via SSH and VNC.
https://github.com/awhitney42/commodore-cloud
Clone this repository from GitHub, and run the Docker command to build the container.
sudo docker build -t commodorecloud:v1 .If the container builds successfully, run the docker container locally in a detached state (-d), publishing port (-p) 2222 within the container to port 2222 on the host for SSH as well as port 5900 to 5900 for VNC.
sudo docker run -d -p 2222:2222 -p 5900:5900 commodorecloud:v1If the container runs successfully, you can always view the container process using the docker ps command.
sudo docker ps
Now, try to connect to container using SSH. The password for the vice user can be seen in the Dockerfile that was checked out from the git repo.
ssh -v -p 2222 vice@0.0.0.0If you can connect to the Linux container, then everything is looking good for it having been built and configured correctly for running sshd and VICE using supervisord. Take a moment while you are connected to the container instance to run a ‘ps -ef’ command and make sure that ‘x64sc’ and ‘x11vnc’ are both running. The former is the VICE emulator and the latter is the VNC server.
The final test is to try to access the running VICE machine by connecting to the container’s VNC server. Run the VNC client of your choice (I am using Vinagre on my local Ubuntu desktop), and connect to 0.0.0.0. The VNC password can also be found in the Dockerfile.
Assuming all the bits and pieces up to now have fallen into place, you will be greeted with a VICE window displaying the happy blue Commodore 64 screen!
Azure
Now that you have a working Docker container, you need to create a container registry in Azure and then build and deploy your container to it. If you get stuck at any point with the following instructions, keep in mind that they are mostly covering a specific scenario from this tutorial: Build and deploy container images in the cloud with Azure Container Registry Tasks
Before you begin, you must complete the following prerequisites.
- Setup an Azure account and gain access to it in the Azure Portal.
- Install the Azure CLI on your local machine and sign in to your account with it.
Having access to your account from the Azure CLI, you must first create a resource group and a container registry inside it. We will leverage a few Azure Container Registry (ACR) task commands available with the Azure CLI for some of the common commands needed when working with Azure Container Registries. You will likely need to modify the commands below to change “commodorecloud” to something globally unique.
export ACR_NAME='commodorecloud' # Container Registry name
export RES_GROUP=$ACR_NAME # Resource Group name
# Create Resource Group
az group create --resource-group $RES_GROUP --location eastus
# Create Container Registry
az acr create --resource-group $RES_GROUP --name $ACR_NAME --sku Standard --location eastusNow that you have a container registry, you can use another ACR task to build your container image within it.
az acr build --registry $ACR_NAME --image commodorecloud:v1 .Assuming the container image built successfully, the next step is to the deploy the container to Azure. Before you can proceed, you must first create an Azure Key Vault if you don’t already have one. You must also create a Service Principal and store its credentials in your key vault. The creation of the vault, the service principal, and associated credentials are a one-time step to be able to deploy containers to this registry.
AKV_NAME=$ACR_NAME-vault
az keyvault create --resource-group $RES_GROUP --name $AKV_NAME
# Create service principal, store its password in AKV (the registry *password*)
az keyvault secret set \
--vault-name $AKV_NAME \
--name $ACR_NAME-pull-pwd \
--value $(az ad sp create-for-rbac \
--name $ACR_NAME-pull \
--scopes $(az acr show --name $ACR_NAME --query id --output tsv) \
--role acrpull \
--query password \
--output tsv)
# Store service principal ID in AKV (the registry *username*)
az keyvault secret set \
--vault-name $AKV_NAME \
--name $ACR_NAME-pull-usr \
--value $(az ad sp list --display-name $ACR_NAME-pull --query [].appId --output tsv)You’ve now created an Azure Key Vault and stored two secrets in it:
$ACR_NAME-pull-usr: The service principal ID, for use as the container registry username.$ACR_NAME-pull-pwd: The service principal password, for use as the container registry password.
Now that these service principal creds are stored in your key vault, it is finally time to deploy the container to it.
az container create \
--resource-group $RES_GROUP \
--name acr-tasks \
--image $ACR_NAME.azurecr.io/commodorecloud:v1 \
--registry-login-server $ACR_NAME.azurecr.io \
--registry-username $(az keyvault secret show --vault-name $AKV_NAME --name $ACR_NAME-pull-usr --query value -o tsv) \
--registry-password $(az keyvault secret show --vault-name $AKV_NAME --name $ACR_NAME-pull-pwd --query value -o tsv) \
--dns-name-label $ACR_NAME \
--query "{FQDN:ipAddress.fqdn}" \
--output table \
--ip-address public \
--ports 2222 5900 6400When it has been deployed, make sure to take note of the Fully Qualified Domain Name (FQDN) for you container. You will use this to access your container remotely.
If all went well up until this point, I imagine you’re feeling flushed with the excitement of success and anticipation of the prize at the end. It is time to verify that your container is deployed and running in Azure. If your a cautious and careful sort of person, you can check its status in the Azure Portal, and you should see the container instance in a “Running” state.
If you’re ready to jump right to the final test. Just like you did when your Docker container was running on your local machine, you can now SSH to your container in Azure, making sure to specify port 2222.
ssh -p 2222 vice@nullcommodorecloud.eastus.azurecontainer.ioWith luck you were able to SSH to your container and gain access to a shell prompt for it.
Just like with the local Docker container instance, it would be a good idea at this point to run ‘ps -ef’ and make sure you see the ‘x64sc’ and ‘x11vnc’ processes running.
Finally it is the moment you’ve been waiting for. Time to fire up VNC and connect to your FQDN hostname. If your fates are aligned with the ways of the cloud, then you should now see the glowing azure splendor of your running Commodore 64 in the Cloud!!
Congratulations, you have arrived at your destination! You have climbed to the pinnacle of running the best 8-bit computer in existence, up in the billowing heights aglow with cerulean hues: A Commodore 64 in the Cloud!
Notes
[1] Don’t get me wrong, Azure Web Apps are great if you want a lightweight web application or service that runs in a container. The restriction of only being able to expose ports 80 and 443 to the public internet made this a no go for my Commodore 64 proof-of-concept, where I wanted to access X11 over SSH, VNC, and eventually tcpser.
[2] Tutorial: Build and deploy container images in the cloud with Azure Container Registry Tasks