Already a fan of Google Cloud Shell? For just tips and tricks, without the introduction, click here.

Contents

• Introduction
• Tips and Tricks
  • Shortcuts
  • Customisation
• Wrapping Up

Introduction

Context

At the start of 2020, I made the decision to use a Chromebook as my primary device and move to SaaS/web-based tools permanently. If it's something you're considering - I'd highly recommend it and there are tons of articles on the web outlining why you should and how you can make the transition.

For me the reason was simple: The Browser > A Device.

But one thing that I really struggled with for a long-time was having a cloud-based replacement for my development environment. The problem can be addressed in a number of different ways though, and I would highly recommend reading the following for more in-depth views on the topics:

My Favorite Cloud IDEs. Eliminate the hassle of managing… | by David Kramer | Better Programming

David Kramer ・ Feb 19, 2021 ・

Medium

Why I use a cloud-based development environment and how you can too

Mike ・ Mar 31 '20

#productivity #ide #editor #vscode

Theia 1.0 - Finally a Good Browser IDE

Sven Efftinge ・ Mar 31 '20

#productivity #vscode #opensource #devops

So what did I land on? Google Cloud Shell

Why? It's basically a free Linux development machine accessed through the web browser or a mobile app.

Is it perfect? Will it work for every developer? No.

While alternatives exist, I find the flexibility and accessibility of Google Cloud Shell to be superior for my workflows than the likes of CodeSandbox or GitPod.

So let's move onto what Google Cloud Shell actually is, and what we get for our low, low price of £0 p/m.

What is Google Cloud Shell?

Google Cloud Shell is essentially a web-based interface to an ephemeral Linux virtual machine hosted in the Google Cloud Platform.

More specifically, Google provides you with an e2-small Linux virtual machine with 2 vCPU cores (limited to 25% CPU Time, but burstable) and 2GB RAM and a 1Gbps (125MB/s download/upload) network connection.

And if that's not enough for your workloads, you can "boost" your Cloud Shell machine which will re-provision all sessions for the following 24 hours on an e2-medium instance type instead. This boosts the 2 vCPU cores to 50% CPU Time and doubles both the RAM (to 4GB) and the network connection (to 2Gbps/250MB/s).

Note: Use boost only when you need! You are subject to certain "limits".

Not bad! The catch?

The VM only lasts for the life of the session and gets deleted an hour after you leave the session.

Okay fair enough, what about storage?

That's where things get interesting, from the docs:

Cloud Shell provisions 5 GB of free persistent disk storage mounted as your $HOME directory on the virtual machine instance. This storage is on a per-user basis and is available across projects. All files you store in your home directory, including installed software, scripts and user configuration files like .bashrc and .vimrc, persist between sessions.

So when the virtual machine gets terminated and discarded, your $HOME directory does not.

This means that anything you configure, install or store in your $HOME directory can be used every time you load up Cloud Shell, but anything outside of that directory is wiped away.

This is very powerful if used correctly.

For instance, imagine you want to clone and work on your favourite GitHub repo:

1. Clone that repo into /tmp/my-project and when the VM is discarded and deleted, those files will be gone.
2. Clone it into $HOME/my-project and you can access those files over and over again.

Flexibility is a powerful thing! (Within the limits of course!)

So how do you access it? Through the web browser.

But there are a few things you need to do beforehand:

1. Sign-up/Sign-in to a Google Account
2. Access the Google Cloud Platform Console
3. Click on the "Activate Cloud Shell" icon.

Once it loads up you'll be presented with the two parts of Google Cloud Shell:

1. The terminal.
2. The Theia-based Code Editor.

But that's not the only way to access it - there's also a mobile application for iOS and Android.

So you can access it from literally anywhere!

And it's that flexibility and accessibility that has driven me to write these tips and tricks. You can do a lot with Google Cloud Shell if you're willing to spend some time with it.

So, onto my tips and tricks!

Tips and Tricks

Shortcuts

Accessing Cloud Shell through the Cloud console is not the only way you can get to it!

Open Cloud Shell Directly

Here's a link to open Google Cloud Shell directly in its own tab:

https://console.cloud.google.com/cloudshell/editor?cloudshell=true&shellonly=true

Note: The '&shellonly=true' means 'Don't open the code editor'

Open Cloud Shell Code Editor Directly

If you want to open just the code editor without the terminal:

https://ssh.cloud.google.com/devshell/proxy?authuser=0&port=970&cloudshell_retry=true&devshellProxyPath=%2F&environment_name=default&environment_id=default

Note: If your Cloud Shell VM isn't active, this link won't work!
Tip: Append #/path/to/directory to the URL to open that directory in the editor!

Clone a GitHub Repo via its URL.

Much like the way GitPod behaves, you can clone any GitHub or BitBucket repository automatically through visiting a specific URL:

https://ssh.cloud.google.com/cloudshell/editor?shellonly=true&cloudshell_git_repo={URL LINK TO REPO}

Note: Cloud Shell will clone any repo into the $HOME/cloudshell_open directory.
Hint: Other parameters for this URL can be found on this page.

Clone the GitHub Repo from the repo itself

Or, if you add the following bookmark to your bookmarks bar, it will automatically take the URL of the page you are on and clone that.

javascript:{window.location='https://ssh.cloud.google.com/cloudshell/editor?shellonly=true&cloudshell_git_repo='+encodeURIComponent(window.location.href)}

Add a 'Clone this in Cloud Shell' badge to your repo

You can also embed a Shields.io badge to our repo's README to allow others to automatically clone the repo to their Cloud Shell.

[![Open in Cloud Shell](https://img.shields.io/badge/Google%20Cloud%20Shell-Clone-5391FE?style=for-the-badge&logo=gnu-bash&logoColor=white)](https://ssh.cloud.google.com/cloudshell/editor?cloudshell_git_repo=***{REPO URL HERE}***&shellonly=true)

Customisation

For those who want to change the look and feel of Cloud Shell or want to really stretch the boundaries of what it can do, there are a few things we can change:

Custom Startup Script (.customize_environment)

If you find yourself needing tools or packages that aren't included in the list of packages that Cloud Shell has pre-installed, create a file called .customize_environment in your $HOME directory.

As described in the docs, this script is run as root when the VM is created.

You could install packages, make configuration changes or just remove some of the things Google bakes into the image.

When the script completes, the file /google/devshell/customize_environment_done is created. Log output is available at /var/log/customize_environment.

Remove the Google sign-in message

On every login to Cloud Shell, you will see the following:

Welcome to Cloud Shell. Type "help" to get started.

This is part of the init_help.sh script located at /etc/profile.d/init_help.sh that runs on every login.

Unfortunately, to stop this message appearing on every login we need to delete this file as part of our .customize_environment script. (See below)

Stop README-cloudshell.txt being recreated

If you delete the README-cloudshell.txt file from your $HOME directory, you will notice that Google helpfully recreates it the next time we log in.

This is part of the init_help.sh script located at /etc/profile.d/init_help.sh that runs on every login.

Unfortunately, to stop this message appearing on every login we need to delete this file as part of our .customize_environment script. (See below)

Remove the init_help.sh script

To remove the /etc/profile.d/init_help.sh script and stop the above two behaviours, add the following to your .customize_environment file:

#!/bin/sh

# File to remove
file="/etc/profile.d/init_help.sh"

if [ -f $file ] ; then
    rm $file
fi

Note: Deleting this file will also delete the messages that tell you which GCP project you have selected. You can see how to add these back in with the "customise the login message" tip.
Note: This also removes the 'help' alias.

Customise the login message

To add a custom welcome message, you just need to copy in a bash script to /etc/profile.d/ that will get executed on login.

However, when the script runs it does not have access to the $HOME directory so any scripts will need to be hosted externally.

Add code similar to this to your .customize_environment file:

#!/bin/sh
echo 'Getting custom login message script...'
wget -P /etc/profile.d/ https://URL/path/to/your/init_welcome.sh
chmod +x /etc/profile.d/init_welcome.sh

Note: Replace URL/path/to/your/init_welcome.sh script with a publicly accessible bash script.

As an example, this is the bash script I use for my login:

Hint: Lines 8-13 will print out the current GCP project, exactly as in the original init_help.sh script.

This means my Cloud Shell login looks like this:

Customise bash prompt (and keep GCP project functionality)

As with any Linux environment, you can customise the Bash prompt to add any number of things by changing the PS1 variable. In Google Cloud Shell, the PS1 variable is set by the /google/devshell/bashrc.google file on login, which is referenced by your $HOME/.bashrc file.

Note: This file contains a number of Cloud Shell-specific settings so I wouldn't recommend removing this source from your .bashrc.

To replace the prompt format, set the PS1 variable after the source "/google/devshell/bashrc.google" block.

If like me, you want to augment or modify the existing prompt, add the following to the end of your .bashrc:

export PS1='🌀 \e[1m\033[38;5;202m\]\u@ndsn-shell \e[0m\[\033[00m\]in \e[1m\[\033[1;34m\]\w\e[0m$([[ -n $DEVSHELL_PROJECT_ID ]] && printf " \[\033[1;33m\](%s)" ${DEVSHELL_PROJECT_ID} )\[\033[00m\]'
if [[ -n $TMUX ]]; then
  export PS1+='\[\033k$([[ -n $DEVSHELL_PROJECT_ID ]] && printf "(%s)" ${DEVSHELL_PROJECT_ID} || printf "cloudshell")\033\\\]'
fi
export PS1+="\033[38;5;2m\]\$(__git_ps1 ' [⎇ %s]')\[\033[00m\] ↣ "

Which results in:

🌀 me@ndsn-shell in /my/path (gcp-project-name) [⎇ master] ↣

Screenshot:

Install Chromium dependencies (for headless browser testing)

I like to use puppeteer for headless browser testing, but when it tries to download and use Chromium there are a lot of dependencies that aren't installed by default. Install them with:

sudo apt-get install gconf-service libasound2 libatk1.0-0 libatk-bridge2.0-0 libc6 libcairo2 libcups2 libdbus-1-3 libexpat1 libfontconfig1 libgcc1 libgconf-2-4 libgdk-pixbuf2.0-0 libglib2.0-0 libgtk-3-0 libnspr4 libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 libx11-6 libx11-xcb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxext6 libxfixes3 libxi6 libxrandr2 libxrender1 libxss1 libxtst6 ca-certificates fonts-liberation libappindicator1 libnss3 lsb-release xdg-utils wget

Note: Source: Puppeteer Troubleshooting

Install code-server (Web-based VSCode)

While the Theia-based code editor that comes with Cloud Shell is okay, it doesn't support much modification. You can't add plugins for other languages and you don't have any nice git integration.

A while ago, Christian Hees outlined in a Medium post how it was possible to install and run code-server (web-based VSCode) on Google Cloud Shell. This meant that we could extend our code editing capabilities within Cloud Shell and allowed us to extend the use-cases for which it was useful.

His steps were simple and still work, but there is now an even quicker way to install and run code-server from the official docs:

curl -fsSL https://code-server.dev/install.sh | sh -s -- --method=standalone
PATH="$HOME/.local/bin:$PATH"

Which installs to $HOME/.local. Then to start the application you can just run code-server --auth=none.

Note: Having code-server on your PATH may not persist across sessions, so you may need to periodically run PATH="$HOME/.local/bin:$PATH" to get the code-server command to work.

Hint: While perfectly usable in normal mode, use Boost Mode (above) to get a snappier experience.

I like to change the ~/.config/code-server/config.yml to the following:

bind-addr: 127.0.0.1:5000
auth: none
cert: false

Which changes the port to 5000 and disables the authentication (since Cloud Shell handles this).

Note: There is an open issue with code-server at the moment that prevents GitHub sign-in. See here for more details and a workaround.

Wrapping Up

I hope that some of these tips and tricks will enable you to make Google Cloud Shell work for your particular workflow.

While it may not be a suitable cloud development environment for all workloads, it is totally free and with a little customisation can be a powerful extension to your productivity toolset.

Let me know what you think!

• Did any these tips or tricks help?
• Any other tips or tricks that you have for Google Cloud Shell?
• What do you use for your Cloud Development Environment?

🧡 Tom Anderson
www.thomas-anderson.net
Liked something I did and want to help me out?