The Hazards of Hands On Labs and the Humble SSH Client
Over the last three months, I have been delivering Docker "Hands on Labs" (HOLs) as part of the series of Oracle Code events in EMEA.
These labs have been fantastically well received. We've been over - subscribed on each occasion. We’ve tried to accommodate as many as we can, but still had to turn people away.
In Berlin, the session was so popular we even had some of the extra people sitting on the floor!
But running a HOL is never stress free – the audience will always manage to throw curve balls at you, no matter how many times you rehearse the lab beforehand.
And the things that cause the most grief are usually not the ones you expect to be difficult. So it was here. On each occasion, the most frequent issue we had was the humble SSH client.
To maximise the value of the lab time, as a pre – requisite, we had asked the attendees to install a Docker environment either natively on their laptops or in a VM.
Now we weren’t that surprised to find some of our attendees had not done their homework! So we had a plan B - a number of VMs with Docker installed running in the Oracle Cloud. Then the attendees without a Docker environment just needed to SSH into their allocated VMs and they’d be fine. At least that was the theory.
The first issue was that not all Windows users have an SSH client installed on their PC. If you’re a Linux (or Mac) user, this might seem odd, but there it is.
The second was that some actually did, but didn’t realise it - for example they had Git shell installed on their machine, and didn’t know it included SSH.
Thirdly we had people who had Putty installed – which doesn’t use the same key format as OpenSSH. So the keys had to be converted for Putty users.
FireSSH turns out to be a good answer to the problems of not having an SSH client (or not knowing about it), since it supports both Firefox and Chrome and pretty much everyone has one of those browsers.
FireSSH solved most of the “I have no SSH client” issues, and it’s certainly a better option than Putty, since it uses the same key format as Linux and Mac.
Where FireSSH fell down was when we found that some of our attendees had company laptops that were locked down so that they couldn’t SSH to the VMs. Personally, I can’t imagine using such a machine for development, but that’s what they had.
So we needed a solution that worked via port 80.
The answer was to use Secure Global Desktop. This is a piece of software that allows you to access a remote desktop environment, or even a specific application using only a browser.
To minimise navigation and potential confusion, we set up a VM in the Oracle Cloud as an SGD VM. Then we added a number of user accounts and configured each one to automatically start an SSH session to a specific Docker VM in the cloud.
So finally we were able to give attendees who had no Docker environment installed, a locked down PC and no SSH client a way to access a Docker environment so they could run the labs.
After that, the labs themselves ran pretty smoothly ;-)
These labs have been fantastically well received. We've been over - subscribed on each occasion. We’ve tried to accommodate as many as we can, but still had to turn people away.
In Berlin, the session was so popular we even had some of the extra people sitting on the floor!
But running a HOL is never stress free – the audience will always manage to throw curve balls at you, no matter how many times you rehearse the lab beforehand.
And the things that cause the most grief are usually not the ones you expect to be difficult. So it was here. On each occasion, the most frequent issue we had was the humble SSH client.
To maximise the value of the lab time, as a pre – requisite, we had asked the attendees to install a Docker environment either natively on their laptops or in a VM.
Now we weren’t that surprised to find some of our attendees had not done their homework! So we had a plan B - a number of VMs with Docker installed running in the Oracle Cloud. Then the attendees without a Docker environment just needed to SSH into their allocated VMs and they’d be fine. At least that was the theory.
The first issue was that not all Windows users have an SSH client installed on their PC. If you’re a Linux (or Mac) user, this might seem odd, but there it is.
The second was that some actually did, but didn’t realise it - for example they had Git shell installed on their machine, and didn’t know it included SSH.
Thirdly we had people who had Putty installed – which doesn’t use the same key format as OpenSSH. So the keys had to be converted for Putty users.
FireSSH turns out to be a good answer to the problems of not having an SSH client (or not knowing about it), since it supports both Firefox and Chrome and pretty much everyone has one of those browsers.
FireSSH solved most of the “I have no SSH client” issues, and it’s certainly a better option than Putty, since it uses the same key format as Linux and Mac.
Where FireSSH fell down was when we found that some of our attendees had company laptops that were locked down so that they couldn’t SSH to the VMs. Personally, I can’t imagine using such a machine for development, but that’s what they had.
So we needed a solution that worked via port 80.
The answer was to use Secure Global Desktop. This is a piece of software that allows you to access a remote desktop environment, or even a specific application using only a browser.
To minimise navigation and potential confusion, we set up a VM in the Oracle Cloud as an SGD VM. Then we added a number of user accounts and configured each one to automatically start an SSH session to a specific Docker VM in the cloud.
So finally we were able to give attendees who had no Docker environment installed, a locked down PC and no SSH client a way to access a Docker environment so they could run the labs.
After that, the labs themselves ran pretty smoothly ;-)
Comments
Post a Comment