Testdriving AWS CloudShell

After its announcement at AWS re:Invent I rushed to try out AWS's newest product: Cloudshell. A linux shell in your browser, connected into your AWS account. Not only that, but your "homedir" can store up to 1GB into persistent storage. That sounds awesome!

AWS-CLI

CloudShell is already installed with aws-cli (of course), but also with Python, Node.js and quite some other nice tooling. Here are the versions.

[cloudshell-user@ip-10-0-132-221 ~]$ python --version
Python 2.7.18

[cloudshell-user@ip-10-0-132-221 ~]$ python3 --version
Python 3.7.9

[cloudshell-user@ip-10-0-132-221 ~]$ node --version
v12.8.4

[cloudshell-user@ip-10-0-132-221 ~]$ perl --version

This is perl 5, version 16, subversion 3 (v5.16.3) built for x86_64-linux-thread-multi
(with 39 registered patches, see perl -V for more detail)

...

The one that was missing in my first minute of trying-out, was kubectl. However, as wget is present installing kubectl is as simple as stealing candy from a n00b.

% curl -LO "https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl"
...
% chmod 755 kubectl
% mv kubectl ~/bin/
% echo 'export PATH=$PATH:/home/cloudshell-user/bin/' >>~/.bashrc

Editors

Now, what kind of editors do we have?

Nano? Nope. Pico? Nope. Emacs? Nope. Vi? Yes. Yuk. So that needs some tweaking.

% sudo yum install nano emacs-nox
...


% emacs --version
GNU Emacs 25.3.1
Copyright (C) 2017 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of GNU Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING.
% nano --version
 GNU nano, version 2.9.8
 (C) 1999-2011, 2013-2018 Free Software Foundation, Inc.
 (C) 2014-2018 the contributors to nano
 Email: [email protected]    Web: https://nano-editor.org/
 Compiled options: --enable-utf8

And we have emacs and nano too! Unfortunately they are not persistant so that is a pity. But that's easily remedied by creating a little script that will install it whenever you need them.

~/bin scripts

As I usually have quite a lot of handy scripts that reside in my ~/bin/ directory, I'd like to copy those to my AWS Cloudshell too. But how? I cannot ssh into my laptop and I cannot ssh into my Cloudshell.

So we cheat. I created an S3 bucket, made a policy that only my cloudshell IAM user could access it. Through the web-interface I can drop my scripts in there (tgz'd) and using the aws-cli I can retrieve them easily:

[cloudshell-user@ip-10-0-13-99 ~]$ ls -sla bin/ | wc -l
1

[cloudshell-user@ip-10-0-13-99 ~]$ aws s3 cp s3://edv-dotfiles/dotfiles.tgz .
download: s3://edv-dotfiles/dotfiles.tgz to ./dotfiles.tgz    

[cloudshell-user@ip-10-0-13-99 ~]$ tar -zxf dotfiles.tgz

[cloudshell-user@ip-10-0-13-99 ~]$ ls -sla bin/ | wc -l
16

And I have my scripts! The fun can start...

Nuisances

There is one little thing that is a serious nuisance. I am VERY used to shell keyboard shortcuts.

CTRL-a and CTRL-e jump to the start and end of a line. That works flawlessly.

CTRL and left- or right-arrow keys jump from word to word. That also works perfectly.

But there is one keyboard shortcut that is not working as expecting. It is CTRL-w: delete a word before the cursor. In a browser, CTRL-w closes the current window. And that happens to me a LOT. It's obviously a problem on my side, but 25+ years of using shell shortcuts will not get out of my system that easily so I think I will have to live with it. I could remap the shortcut to no action in AutoHotKey but that would also be a nuisance when I do need to use CTRL-w in a regular browser. Ahwell.

Fortunately, CTRL+SHIFT+t reloads the page in a second or two, but every time this happens you lose your environment and history. So it's vital to set up your bash environment as perfectly as possible so you hardly ever need to switch between k8s/aws environments when you log on again. One way is to command your environment-switch scripts so that they change your .bashrc too. That way after each log-on you will jump right back in your latest kubernetes/aws/... environment.

Another way is to change your default k8s/aws environment files every time you switch, but that is a bit more cumbersome though perhaps less error prone. If you mess up your aws or k8s environments, you just need to reset them. But if you mess up your .bashrc, you may not be able to log on anymore... I haven't tested that yet, btw. And I am not eager to. But feel free to tell me your experiences with severly broken .bashrc files in the comments below.

Conclusion

I am *very* happy with Cloudshell. I use it very regularly nowadays. It does eat up more memory than a regular xterm - Chrome tabs are consuming quite some memory. But that is a price I am willing to pay.

There are two downsides though. Before Cloudshell I could see in my window manager where my shells were. Now they are inside my browser tabs, which makes looking for them a bit more cumbersome. And secondly Cloudshell times out when you don't use it. You then have to log on again and perhaps install the editors again. But anyone working remotely on secure servers has that time-out problem too.

My Cloudshell rating: four point five chainsaws!