devops on tkainrad

Copy-paste ready commands to set up SGE, PBS/TORQUE, or SLURM clusters

Fri, 18 Oct 2019 00:00:00 +0000

Introduction

Local HPC clusters continue to play a vital role in scientific research. Many universities, research institutions, and companies continue to maintain on-site clusters despite the efforts of the big cloud providers to expand their offerings into this area.

The software systems responsible for making these clusters of computers work together can be called Distributed Research Management System. The most commonly used ones are SGE, PBS/TORQUE, and SLURM. Unfortunately, setting those up can be very painful. There is a lot of outdated information on the internet. It is required to fight with several different configuration files and minor issues can mean that no command will run properly.

Operating principle of a traditional resource-manager based computing cluster.

If your task is to set up a large system that will be used for many years and you have got several days to do this perfectly, this might not be a problem. However, if you just want to play around with the different systems, spending several hours until you can submit your first job is a very bleak outlook.

Therefore, I present copy-paste-ready instructions for setting up SGE, PBS/TORQUE, or SLURM on a single machine, which will act as the master and a compute node at the same time. All guides are tested on Ubuntu 18.04, but should work with little modification on most recent Linux installations. These commands can also serve to create container images or other automated setup workflows.

Naturally, caution is warranted when executing commands as a super user. If you apply the listed commands on a production system, please make sure you understand everything that is done.

Slurm

Trying to set up SLURM on my development machine in order to run some test suites that need to interface with SLURM cost me quite a bit of time. There are plenty of extensive tutorials available. In contrast to SGE and PBS, there is even an up-to-date official documentation. However, those resources cover much more than is needed for a single-node cluster and it is easy to get lost in the many configuration options that you will not need at first.

Fortunately, I found this thread in the Ubuntu forums, which is the basis for my SLURM instructions.

Start by installing munge and slurm:

sudo apt install munge slurm-wlm

Then, create a new file at /etc/slurm-llnl/slurm.conf with the following content:

ControlMachine=<YOUR-HOST-NAME>

MpiDefault=none

ProctrackType=proctrack/pgid
ReturnToService=1
SlurmctldPidFile=/var/run/slurm-llnl/slurmctld.pid
SlurmdPidFile=/var/run/slurm-llnl/slurmd.pid
SlurmdSpoolDir=/var/lib/slurm-llnl/slurmd
SlurmUser=slurm
StateSaveLocation=/var/lib/slurm-llnl/slurmctld
SwitchType=switch/none
TaskPlugin=task/none
#
# SCHEDULING
FastSchedule=1
SchedulerType=sched/builtin
SelectType=select/linear
#
# LOGGING AND ACCOUNTING
AccountingStorageType=accounting_storage/none
ClusterName=<YOUR-HOST-NAME>
JobAcctGatherType=jobacct_gather/none
SlurmctldLogFile=/var/log/slurm-llnl/slurmctld.log
SlurmdLogFile=/var/log/slurm-llnl/slurmd.log
#
# COMPUTE NODES
NodeName=<YOUR-HOST-NAME> CPUs=4 Sockets=1 CoresPerSocket=4 ThreadsPerCore=2 State=UNKNOWN
PartitionName=long Nodes=<YOUR-HOST-NAME> Default=YES MaxTime=INFINITE State=UP

You only need to replace <YOUR-HOST-NAME> with your actual hostname. Simply execute the hostname command if you are not sure what it is. Of course, you can also modify other settings, such as the number of CPUs, but the basic configuration from above should be enough for our 1-node cluster.

We are almost finished, just enable and start the manager slurmctld:

sudo systemctl enable slurmctld
sudo systemctl start slurmctld

Finally, enable and start the agent slurmd:

sudo systemctl enable slurmd
sudo systemctl start slurmd

Congratulations, your Slurm system should be up an running! Use sinfo to check the status of the manager and the agent. The command scontrol show node will give you information about your node setup.

If Slurm did not start, fear not, there is likely only a small fix required. Start by looking for an error message with

systemctl status slurmd.service

Does it say that the slurmd.pid file coud not be opened? If so, your slurm.conf file probably has different values for SlurmctldPidFile and SlurmdPidFile than your slurmctld.service file. Check by printing the latter:

less /usr/lib/systemd/system/slurmctld.service

It might show PIDFile=/run/slurmctld.pid, which means that we need to change SlurmctldPidFile and SlurmdPidFile in our /etc/slurm-llnl/slurm.conf to the following:

SlurmctldPidFile=/run/slurmctld.pid
SlurmdPidFile=/run/slurmd.pid

After that, try again to start slurmctld and slurmd with the above commands.

SGE

This one is not so simple.

Some parts of the following setup are taken from a public Dockerfile created by Robert Syme.

First, gain root permissions. On Ubuntu you can type sudo -i. All commands have to be executed with root permissions.

Then, create a new folder, let’s say via mkdir /opt/sge/installfolder. Set the new folder’s location as an environment variable in the current shell via

export INSTALLFOLDER=/opt/sge/installfolder.

Then, execute the following commands:

cd $INSTALLFOLDER
wget https://arc.liv.ac.uk/downloads/SGE/releases/8.1.9/sge-common_8.1.9_all.deb .
wget https://arc.liv.ac.uk/downloads/SGE/releases/8.1.9/sge-doc_8.1.9_all.deb .
wget https://arc.liv.ac.uk/downloads/SGE/releases/8.1.9/sge_8.1.9_amd64.deb .
dpkg -i ./*.deb

Then, download the following 4 files and place them also into the created folder, in our case into /opt/sge/installfolder:

Most of the magic will happen through those scripts and configuration files. After the download, we need to set some environment variables in the current shell:

export SGE_ROOT=/opt/sge
export SGE_CELL=default

We also need to set a new profile.d config via

ln -s $SGE_ROOT/$SGE_CELL/common/settings.sh /etc/profile.d/sge_settings.sh

Then, execute the following to install SGE and perform setup operations:

cd $SGE_ROOT && ./inst_sge -m -x -s -auto $INSTALLFOLDER/sge_auto_install.conf \\
&& sleep 10 \\
&& /etc/init.d/sgemaster.sge-cluster restart \\
&& /etc/init.d/sgeexecd.sge-cluster restart \\
&& sed -i "s/HOSTNAME/`hostname`/" $INSTALLFOLDER/sge_exec_host.conf \\
&& sed -i "s/HOSTNAME/`hostname`/" $INSTALLFOLDER/sge_hostgrp.conf \\
&& /opt/sge/bin/lx-amd64/qconf -Me $INSTALLFOLDER/sge_exec_host.conf

Now, our new cluster is already up and running. However, we still need to add users to the sgeusers group, which was defined in the sge_hostgrp.conf file you just applied. Only users from this group are allowed to submit jobs. Therefore, we run the following:

/opt/sge/bin/lx-amd64/qconf -au <USER> sgeusers

Finally, run $INSTALLFOLDER/sge_init.sh.

You can now delete the complete $INSTALLFOLDER, or at least run

rm $INSTALLFOLDER/*.deb

After a restart to load the new profile.d settings, all users that were added to sgeusers should be able to submit jobs. Test this via:

echo "echo Running test from $HOSTNAME" | qsub

PBS / Torque

This is a little simpler again. Most of the setup is taken from another blog. Some inspiration is also from a public Dockerfile available at Docker Hub.

First, gain root permissions. On Ubuntu you can type sudo -i. All commands have to be executed with root permissions.

We start by installing the relevant packages:

apt-get install torque-server torque-client torque-mom torque-pam

Installing these packages will create a default setup. Unfortunately, this is complex and would require complex changes to get to a working cluster. Instead, we stop all torque services and create a clean setup:

/etc/init.d/torque-mom stop
/etc/init.d/torque-scheduler stop
/etc/init.d/torque-server stop
pbs_server -t create
killall pbs_server

We start by setting localhost as the server host and allowing root to change the database configuration:

echo localhost > /etc/torque/server_name
echo localhost > /var/spool/torque/server_priv/acl_svr/acl_hosts
echo root@localhost > /var/spool/torque/server_priv/acl_svr/operators
echo root@localhost > /var/spool/torque/server_priv/acl_svr/managers

With the following commands, we set localhost also as compute node with 4 cores available:

echo "SERVER.DOMAIN np=4" > /var/spool/torque/server_priv/nodes
echo localhost > /var/spool/torque/mom_priv/config

Now, we can already start the daemon processes again:

/etc/init.d/torque-server start
/etc/init.d/torque-scheduler start
/etc/init.d/torque-mom start

After this qmgr is ready to start the scheduler:

qmgr -c 'set server scheduling = true'
qmgr -c 'set server keep_completed = 300'
qmgr -c 'set server mom_job_sync = true'

The following commands are to create a default queue and to configure it:

qmgr -c 'create queue batch'
qmgr -c 'set queue batch queue_type = execution'
qmgr -c 'set queue batch started = true'
qmgr -c 'set queue batch enabled = true'
qmgr -c 'set queue batch resources_default.walltime = 3:00:00'
qmgr -c 'set queue batch resources_default.nodes = 1'
qmgr -c 'set server default_queue = batch'

Finally, we allow our machine to submit to the new cluster:

qmgr -c 'set server submit_hosts = <hostname>'
qmgr -c 'set server allow_node_submit = true'

To test the setup, you can use the following command:

echo "echo Running test from $HOSTNAME" | qsub

Conclusion

The target audience for this post is probably very small. I decided to do it anyway, as there might be someone that can benefit immensely. Personally, I would have saved a lot of time if I found such a blog post a year ago. Also, I might need it again myself at some point.

Setting up a Linux Workstation for Software Development

Tue, 13 Aug 2019 00:00:00 +0000

Introduction

In my opinion, Linux is the best operating system for a software engineer, except they develop explicitly for Windows or macOS. Whenever I read about new features for the Windows Subsystem for Linux, I wonder why people settle for anything less than the real thing. Linux aids many of my workflows with its customizability, superior command-line experience, native support for containerization platforms, a dependable package management system, and many other features that I will describe in this blog post. macOS comes close, but, in my opinion, falls short due to exorbitant hardware costs and less room for customization.

Still, as with any other operating system, optimizing a Linux workstation for software development requires some configuration. In this post, I will present tools and concepts that I think are very helpful, but overlooked by many. I will try to show only things that are not specific to my workflows, but rather useful for almost any software engineer, DevOps specialist, or just regular productivity enthusiast. Naturally, many of the configuration options and tools covered in this post are subjective. Nevertheless, I am confident that my suggestions are a good place to start. They have served me well over the years and I continually try to optimize my setup. Hence, I very much appreciate any improvement you might suggest.

Prerequisites

A Linux machine
For this guide, I will use Ubuntu 20.04, which is the current LTS release. I am very happy with Ubuntu. Anything I don’t like can easily be changed. The biggest advantage over many other distributions is probably that the Ubuntu community is very large and it is usually easy to find people with similar problems. There is also a very active StackExchange community. However, most of the things covered in this post will apply to pretty much any Linux distribution and even macOS.

Some command-line experience
Much of this post is intended for people who feel right at home when they see a ~- character. If you are not comfortable working with command-lines and have no intention to change this, you can still read the other sections though.

Tweaking Ubuntu

Before we start any serious work, I will point out some changes to Ubuntu itself that I apply on all my machines.

Appearance

One of the first things I do after installing Ubuntu is to install the GNOME Tweak Tool:

sudo apt-get install gnome-tweak-tool

It enables complex modifications of the GNOME desktop environment. I recommend you play around with some of its options. For this guide, we will only consider the Appearance section. Specifically, we want to change the default Ubuntu theme to another one that provides better contrasts and an overall cleaner experience, namely the Adapta-gtk-theme, which is based on the Material Design guidelines.

sudo apt-get install adapta-gtk-theme

After installing the theme, you should restart the GNOME Tweak Tool, and you can then select Adapta-Eta as your new theme. The theme comes with some nice benefits that you wouldn’t think of at first. For example, it fixes the ridiculously small toolbar icons in the Eclipse IDE.

Adapta Theme elements (Source).

Unfortunately, the Adapta theme is no longer actively maintained. It is still a perfectly fine theme to use and if you notice any glitches, you can always switch themes with a couple clicks. A possible alternative is Materia, which also works well with the remainder of this blog post.

Nautilus Type-Ahead Search

The next thing I suggest is to change the Nautilus search behavior. With recent Ubuntu distributions, there is no type-ahead search in the standard file explorer. This means you can not start to type some letters and jump between files that start with these letters. Instead, Nautilus will enter a dedicated search mode that is confusing and quite slow for folders with a large number of files.

Fortunately, we can easily get the old behavior back:

sudo add-apt-repository ppa:lubomir-brindza/nautilus-typeahead
sudo apt dist-upgrade
killall nautilus # to force a restart

Searching through my /bin folder by typing ahead (Source).

There is a StackExchange answer that provides further details.

Hibernation

Another thing that is essential for me is hibernation. Usually, I will only shutdown my computer once a week or even less. However, I am not a big fan of suspending for long periods of time. Power outages could have unforeseen consequences and I simply feel a little better if my machines are off the grid altogether.

Unfortunately, setting up hibernation is tricky and can depend on your hardware. I updated this section multiple times already to contain the most robust solution, but you never quite know. If you don’t care about hibernation, you should probably skip this section and spare yourself the trouble.

In principle, hibernation is possible out of the box. Just type sudo systemctl hibernate. However, this is likely to fail with an error. My fix for this relies on a mixture of this and that blog post. First, we need to find out the current size of our swap file:

The below instructions assume that you use Ubuntu 20.04 with a swap file. This is the default for new installations. However, if you upgraded from a previous version, you might still have a swap partition. In this case, the process is similar, but not covered here.

sudo swapon --show # or `cat /proc/swaps`

If this is less than your main memory (RAM), you will need to increase it:

sudo swapoff -a
sudo fallocate -l <SIZE>G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
sudo swapon --show # to verify changed size

Next, we need to find out the UUID and offset of our now large enough swapfile:

sudo swap-offset /swapfile
> <OFFSET>
sudo findmnt -no SOURCE,UUID -T /swapfile 
> <UUID>

With this, we are almost done. Using the UUID and the file offset, we edit the following line in /etc/default/grub:

`GRUB_CMDLINE_LINUX_DEFAULT="quiet splash resume=UUID=<UUID> resume_offset=<OFFSET>"`

Then, we create a conf.d resume file. Simply do sudo nano /etc/initramfs-tools/conf.d/resume and add the content RESUME=UUID=<UUID> to the file. At last, we need to update grup and initramfs:

sudo update-grub
sudo update-initramfs -u -k all

And finally, you should be able to do sudo systemctl hibernate.

Please let me know if this approach doesn’t work on your system. I would like to include potential problems in this post, if there are any.

Boosting Command-Line Productivity

I believe that command-line proficiency can significantly boost developer productivity. This is especially true in times of DevOps and NoOps, where developers are supposed to handle deployment pipelines and cloud infrastructure. Fortunately, there are some tools that can help you become a command-line wizard.

Shortcuts

Before going forward, I would suggest to set up some general terminal shortcuts. Simply go to Edit -> Preferences -> Shortcuts. I like to replicate web browser shortcuts for opening new tabs and windows, closing tabs, and cycling between tabs.

Did you know that all common terminal emulators have an Undo shortcuts with Ctrl+Shift+-? Among many other things, my side-project KeyCombiner has a public collection of terminal shortcuts, many of which are barely known and still very useful.

However, using this interface, it is not possible to set up Ctrl+Tab and Ctrl+Shift+Tab as tab switching shortcuts. Gnome has some issues with using the Tab key in shortcut configurations. Thanks to this answer from the Ubuntu community, we can get around this. Simply execute the following in your terminal:

gsettings set org.gnome.Terminal.Legacy.Keybindings:/org/gnome/terminal/legacy/keybindings/ next-tab '<Primary>Tab'
gsettings set org.gnome.Terminal.Legacy.Keybindings:/org/gnome/terminal/legacy/keybindings/ prev-tab '<Primary><Shift>Tab'

Switching from Bash to Zsh

A couple of months ago, I made an important change in my life. I switched from Bash to Zsh.

There are a lot of blog posts, threads, and articles that compare Bash and Zsh, e.g.:

At the end it boils down to one thing: Plugin and theme support

Zsh has an amazing themes and plugins ecosystem. Theme support allows you to easily get a beautiful shell. Plugins range from simple auto-completion for all kinds of applications and tools(git, mvn, hugo, …) to complex stuff like improved search capabilities. Because of this fact alone, Zsh is superior to Bash.

However, chances are that you grew fond of Bash and that you get a bad feeling when somebody tells you that there is something better. I understand, it was the same for me. Still, I urge you to give it a shot. The transition is very painless since pretty much everything you like about Bash still works with Zsh. You will not have to learn new commands.

Installing Zsh

Installing Zsh on Ubuntu is very easy. We can use the regular package manager:

sudo apt install zsh

Then, we set Zsh as our new default shell:

chsh -s $(which zsh)

The chsh command updates the /etc/passwd file, but does not affect the current session. You need to log out and log in again to have zsh as your default shell.

Configuring Zsh History

For me there are few things worse than searching for an old shell command only to find out that the shell’s history size was set to a ridiculously low default number and that, because of this, the command was not saved.

Therefore, we extend the Zsh history size by putting this at the end of the ~/.zshrc configuration file:

HISTSIZE=10000000
SAVEHIST=10000000

For me, the command history is a tool to search for previous commands I might need now. I do not use it as a protocol for what I did when and in which exact order. Therefore, I use the following options to get rid of all duplicates in my history automatically:

## History command configuration
    
setopt HIST_IGNORE_ALL_DUPS # ignore duplicated commands history list

Also, I like to use multiple terminal sessions in parallel, potentially working on the same problem. For this, it helps a lot to share the same history among all sessions. It can be accomplished by

setopt SHARE_HISTORY # share command history data

If you are transitioning from Bash to Zsh, you probably want to keep your existing Bash history. In contrast to Bash, Zsh stores timestamps in its history file. Therefore, re-using the Bash history file does not work out of the box. Fortunately, all we need to do is to append some timestamp to all the commands from our previous Bash history and put them into the new Zsh history file. You could easily script this yourself or use one of the many good scripts that other people wrote, such as this one.

Zsh Features that are not in Bash

Once we have Zsh installed and finished our basic history configuration, we can start to take a look at some out-of-the-box features that make it stand out in comparison with Bash. If these do not impress you, keep in mind that the real big thing is plugin support, which I cover below.

Recursive Path Expansion

Zsh can do much more sophisticated expansions than Bash. This is documented in detail in the Zsh manual.

One feature that you can easily start to use is recursive path expansion. If you type cd /usr/local/b in Bash, you can then press Tab to expand this to cd /usr/local/bin. With Zsh, you can also type cd /u/lo/b and then press Tab. Zsh will recursively expand all path elements:

The above animation shows also that you can omit cd when changing directories.

Calculator: zcalc

Before switching to Zsh, I was often using the Python Shell as a calculator. However, this has a few downsides. Obviously, the Python Shell is not primarily developed to be a good calculator app. For example, simple operations, such as sqrt, require import statements, and there are no convenient ways to access results of previous lines.

The calculator script shipped with Zsh is a very simple and efficient solution. Before using it, it has to be loaded:

autoload -Uz zcalc

If you plan to use it often, you can add the autoload command to your ~/.zshrc.

Then, start the calculator with zcalc and do some calculations:

Results of previous operations can be accessed with the $-character.

Advanced Aliasing

Zsh has some unique aliasing capabilities.

Suffix Aliases
This means you can assign applications to file suffixes, e.g. alias -s txt=vscode will allow you to open a .txt file with Visual Studio Code by just typing file.txt.

Global Aliases
Global aliases are set with the -g flag and allow to specify a replacement for any part of a command. For example, if you set alias -g G=' | grep' you will be able to do the following:

To make aliases permanent, it is required to add them to your ~/.zshrc.

Installing ZSH plugins

Finally, it is time to explore the real strength of Zsh, which means installing plugins to boost our productivity above anything this anime character has ever seen before:

Package Manager: Oh my Zsh

A good place to start is to install Oh my Zsh, “a community-driven framework for managing your Zsh configuration.” Simply do:

wget https://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh -O - | zsh

Copy the template configuration file .zshrc.zsh-template in the .zshrc home directory and apply the configuration by executing the source command. Both can be done at once by executing the following line:

cp ~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc

Oh my Zsh comes with many themes and plugins that we only have to enable in the configuration file in order to use them. In the next section, we will start by selecting a pretty theme.

Theme: Agnoster

Personally, I like the agnoster theme. It works well with the Adapta-Eta Gnome theme we have set previously.

To enable a theme, set ZSH_THEME to the name of the theme in your ~/.zshrc, in my case this is ZSH_THEME=agnoster. If you have troubles with special characters not being shown properly, install the Powerline font package:

sudo apt-get install fonts-powerline

The Oh my Zsh GitHub wiki provides a well curated list of available themes along with screenshots.

All pictures and animations of terminals you see in this post show the Agnoster theme with slight modifications to the prompt. In particular, I removed the git-part of the prompt and added a newline part instead. If you would like to replicate this, edit your ~/.oh-my-zsh/themes/agnoster.zsh-theme and replace the ## Main prompt part close to the end with the following:

prompt_newline() {
  if [[ -n $CURRENT_BG ]]; then
    echo -n " %{%k%F{$CURRENT_BG}%}$SEGMENT_SEPARATOR
%{%k%F{$CURRENT_BG}%}$SEGMENT_SEPARATOR"
  else
    echo -n " %{%k%}"
  fi

  echo -n " %{%f%}"
  CURRENT_BG=''
}

## Main prompt
build_prompt() {
  RETVAL=$?
  prompt_status
  prompt_virtualenv
  prompt_aws
  prompt_context
  prompt_dir
  prompt_bzr
  prompt_hg
  prompt_newline
  prompt_end
}

Additionally, I recommend changing the font color of the directory part of the prompt from black to white. In my opinion, this provides better contrast with the dark blue background:

# Dir: current working directory
prompt_dir() {
  prompt_segment blue white '%~'
}

Basic Plugins

Next, you should enable some included plugins via adding them to your plugins setting in your ~/.zshrc file. After this step, it might look like this:

plugins=(colored-man-pages git python django mvn aws docker vscode)

You can browse all the plugins that come with Oh my Zsh in the official GitHub repository.

The above listed plugins are rather trivial, they provide command completion and define a set of aliases and shortcuts that come in handy when working with the respective tool. Nevertheless, this provides a real productivity boost. For example, finding out which git commands start with r becomes much simpler:

Jump to Frequently Used Directories

Most command-line work happens in just a handful of directories. For me, these are primarily the root folders of various software development projects. Of course, I could manually set aliases for these folders so that I can quickly switch between them, but this would be tedious.

Fortunately, there is a better solution with z. It tracks your most used directories and will take you to them via z <query>. The query can be any part of target directory’s path:

The software is already bundled with Oh my Zsh, simply add z to the list of plugins:

plugins=(z colored-man-pages git python django mvn aws docker vscode)

I could have probably included this one in the list of basic plugins above, but I wanted to highlight it because I find it particularly useful.

Supercharging History Search

The original Bash history search always bothered me. Repeatedly pressing Ctrl+r and hoping to get lucky at some point is very cumbersome if you have lots of similar commands containing the query. To be fair, there are also great additions for Bash that improve this situation, such as McFly.

However, this is about improving history search with Zsh. I believe the best solution is using peco-history. It is a Zsh plugin that relies on peco to interactively filter through your history file. Peco is a general-purpose interactive filtering tool that you can (and should!) also use as a stand-alone tool in your terminal. On Ubuntu, we can install it from the official repositories:

sudo apt-get install peco

Afterwards clone zsh-peco-history into the $ZSH_CUSTOM/plugins directory. Zsh will automatically resolve the pre-set shell variable:

git clone https://github.com/jimeh/zsh-peco-history.git $ZSH_CUSTOM/plugins/zsh-peco-history

Then, add zsh-peco-history to the list of plugins:

plugins=(zsh-peco-history z colored-man-pages git python django mvn aws docker vscode)

The plugin will be ready once you start a new terminal session.

The following animation shows that this improved history search was very helpful for writing this blog post. It allowed me to easily search for the exact commands I used when I set up my current machine:

Searching shell history with peco.

Autosuggestions

Our new history search is great. The bad news is that we will not use it very often, because there is something that is even better in most cases: zsh-autosuggestions
This plugin suggests completions for your commands as you type. By default, the suggested completion will be the first match in your history. This is how it looks like:

Using a suggested git command-line.

git clone https://github.com/zsh-users/zsh-autosuggestions ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-autosuggestions

Afterward, add zsh-autosuggestions to your plugins setting in your ~/.zshrc file:

plugins=(zsh-autosuggestions zsh-peco-history z colored-man-pages git python django mvn aws docker vscode)

Syntax Highlighting

Another great plugin is zsh-syntax-highlighting. It highlights commands while you are typing them. This is especially useful for catching syntax errors. Once again, install via git:

git clone https://github.com/zsh-users/zsh-syntax-highlighting.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/plugins/zsh-syntax-highlighting

Then, add zsh-syntax-highlighting to your plugins setting in your ~/.zshrc file:

plugins=(zsh-syntax-highlighting zsh-autosuggestions zsh-peco-history z colored-man-pages git python django mvn aws docker vscode)

Syntax highlighting also indicates whether a command is typed correctly.

Clipboard Tool

This one is not really a full-blown plugin. Oh my Zsh comes with a script called clipcopy out of the box. It is a simple tool that enables clipboard copy and past operations from the command-line:

<command> | clipcopy    # copies stdin to clipboard
clipcopy <file>         # copies the content of a file to clipboard

If this doesn’t work, you are probably missing xclip. Install it via

sudo apt-get install xclip

Somehow, I have a hard time remembering the name clipcopy, therefore I set a global alias as described above:

alias -g ctrlc=' | clipcopy'
echo "copythisinclipboard" ctrlc

If you don’t use Oh my Zsh, you can get the functionality of clipcopy via an actual plugin.

SSH Setup

One of the great advantages of using Linux instead of Windows is the out-of-the-box SSH support. Immediately after installing your distribution, you can start to access remote servers.

However, there is some room for streamlining your SSH tasks. You can avoid lots of repetitive typing if you modify your .ssh/config file and setup meaningful defaults for the machines you access regularly:

Host ec2-instance # you can freely chose a name here that will act as alias for this host
    HostName <ip-address or hostname>
    User tkainrad


Host cluster # you can freely chose a name here that will act as alias for this host
    HostName <ip-address or hostname>
    User tkainrad
    IdentityFile `/home/tkainrad/cluster_rsa.pub`

For more sophisticated settings, look up the ssh_config man page.

If you want to go one step further, you can set up public key authentication so you can login to your most-used remote hosts without having to re-enter your password each time. With ssh-copy-id, there is a simple tool that streamlines this process. If you have your hosts already configured via the .ssh/config file, just do

ssh-copy-id ec2-instance

By default, ssh-copy-id will take your public key in ~.ssh/id_rsa.pub. If you want to use different keys for each of your remote hosts, check out the man page page or this more extensive guide. If you use keys other than ~.ssh/id_rsa.pub you also have to add an IdentityFile entry to your .ssh/config settings. Afterwards, you will be able to access the machine by simply doing:

ssh ec2-instance

Additional Tools

A great terminal gets you a long way. However, some additional tools can help make your workstation more complete. In this section, I try to present some of my favorites that could be useful to almost anyone.

Text Editing: VSCode

For most of my more extensive software engineering projects, I use JetBrains products or Eclipse. I will not describe setting up those in this post, as this would easily mandate a separate article. However, I present a more lightweight editing environment that is often a better choice than to start up a full-blown IDE. For a software engineer, especially for one that deals also with DevOps workloads, it is the daily business to edit and view all kinds of text-based files, such as .txt, .csv, .md, xml, .yml, and .json. For this, it is essential to have a fast text editor which can deal with large files and still provides sophisticated editing features.

Previously, I used Sublime. For a couple of months now, I have switched to Visual Studio Code and I am still amazed by it. Comparing it to Sublime makes little sense in my opinion, because VSCode is just on a whole other level. Even for software projects with relatively simple technology stacks, such as this blog website, I now prefer VSCode over Eclipse or the JetBrains suite.

Screenshot of VSCode showing the default light theme (Light+) (Source).

The easiest way to install Visual Studio Code on Ubuntu is to visit the official website and to download the Debian package. You could have probably figured out how to do this yourself, but do you also know how to set VSCode as the default application for all text files? Simply do

xdg-mime default code.desktop text/plain

This will spare you the headache of doing Right-Click -> Properties -> Open With -> Set as default on every file type separately.

Switching to VSCode from Sublime (or any other editor) is a surprisingly pleasant experience. VSCode will recommend the most relevant plugins as you go. For example, if you open a .py file, some extensions for Python development will be recommended. Installing them is then just a click away and doesn’t even require a restart of the application. After some days of following VSCode’s recommendations and occasionally searching for some extensions manually, my setup was more complete and efficient than it ever was with Sublime.

VSCode Terminal with Agnoster

If you don’t intend to use the integrated VSCode terminal, you can safely skip this section.

If you followed this guide until here and you now open an integrated Terminal in VSCode, you will likely be a bit disappointed. There are several problems. With our current setup, we need a monospace font, and the coloring does not work nicely with VSCode’s light theme.

Fortunately, we can fix these things:

First, install the Menlo for Powerline font:

git clone https://github.com/abertsch/Menlo-for-Powerline.git
sudo mv "Menlo for Powerline.ttf" /usr/share/fonts/
sudo fc-cache -vf /usr/share/fonts/ # Refresh fonts cache

Then, we change our terminal prompt colors a little bit to be compatible with both light and dark themes. Open ~/.oh-my-zsh/themes/agnoster.zsh-theme and change prompt_context to the following:

# Context: user@hostname (who am I and where am I)
prompt_context() {
  if [[ "$USER" != "$DEFAULT_USER" || -n "$SSH_CLIENT" ]]; then
    prompt_segment cyan default "%(!.%{%F{yellow}%}.)%n@%m"
  fi
}

Finally, we apply the new font and the new colors in the VSCode settings. Press Ctrl+Shift+P and start to type Preferences: Open Settings (JSON). We can now add the following lines to settings.json:

    "terminal.integrated.fontFamily": "Menlo for Powerline", 
    "workbench.colorCustomizations": {
        "terminal.ansiBlue": "#01A0E4",
        "terminal.ansiCyan": "#B5E4F4",
    },

The integrated VSCode terminal now looks nice and has all the functionality of all of our Zsh plugins.

Sync Configuration Files: Mackup

So you just set up your desktop workstation, modified a bunch of configuration files, manually adjusted your VSCode keyboard shortcuts and now you want to do this also with your notebook?

The solution to this is one of my favorite tools of all: Mackup
It will use any software that can sync a folder, such as Dropbox, to keep your application settings in sync.

You can install it with pip:

pip install --upgrade mackup

If you have versioning troubles with pip or Python on Ubuntu 20.04, I recommend to do sudo apt install python-is-python3. It will symlink /usr/bin/python to python3 and hence make your transition to a world without Python 2 easier.

Once Mackup is installed, you can copy your application settings to Dropbox (per default) doing

mackup backup

To apply them at a different machine, just use

mackup restore

Behind the scenes, Mackup copies your configuration files to your Dropbox and then replaces the originals with symbolic links. Have a look at the GitHub Readme for more details.

Advanced Screenshots: Shutter

If you are coming from Windows, you probably use the Snipping Tool on a regular basis. With Screenshot, Ubuntu has a similar tool installed by default. However, there is another option that is superior to both the Windows Snipping Tool and the Ubuntu default: Shutter
Unfortunately, it is no longer included in the default package repositories since Ubuntu 18.10. So, we have to add a third-party PPA first:

sudo add-apt-repository ppa:linuxuprising/shutter
sudo apt-get install shutter

It is very simple to use and does not force you to become familiar with its advanced features. There are a few alternatives that are still actively developed, such as Flameshot. Unfortunately, those are missing a lot of Shutter’s more advanced features. So, I will stick with Shutter for as long as I can make it run on Ubuntu.

Pick Colors: Pick

If you do front-end development, chances are you need a color picking tool on your computer. The most commonly used tool on Ubuntu is GPick. However, it drives me crazy. Usually, I just want to pick a color and get the hex code into my clipboard. GPick makes this very hard. So instead, I recommend Pick, a simple and functional alternative.

Cheatsheet: KeyCombiner Desktop

Most people know KeyCombiner as a tool for browsing and learning shortcuts. However, its desktop app serves an additioanl purpose with its instant lookup feature: It is a context-aware cheatsheet that can show the shortcuts of the currently active application in addition to whatever key combinations and text snippets I have in my personal KeyCombiner collections.

To trigger it, I only have to press Super+Alt+C. The main advantage is that I don’t have to leave the current context and can resume work right after looking up the required piece of information:

KeyCombiner’s instant shortcut lookup for VSCode, Terminal, and Chrome.

Communication Hub: Ferdi

Did you ever see someone using their phone while sitting in front of their personal computer? Chances are, they were using a communication app that they could have used much more efficiently from their larger device with an actual keyboard. To get the benefit of receiving all notifications from all my communication tools, and to be able to respond easily, I use Ferdi. It is particularly useful if you have to monitor several Slack teams.

In contrast to most of its competitors (Rambox, Wavebox, Franz 5), Ferdi is completely free and open-source.

If you want Ferdi or any other software that is distributed via an AppImage to show up properly in the dock, have a look at appimaged. It is open-source software that monitors specific directories for AppImage files and installs them properly in the system.

Previous versions of this article recommended Station instead of Ferdi. However, Station pivoted to become a browser extension and is no longer an option for bundling communication channels outside of your regular browser.

Record Short Screencasts: Peek

Did you wonder how I created those fancy gifs showing my terminal? I thought so.

Peek is a very lightweight and simple tool to record short screencasts. To install it on Ubuntu do

sudo add-apt-repository ppa:peek-developers/stable
sudo apt update
sudo apt install peek

Peek in action. (Source).

During the creation of this article, I was made aware by a good friend and fellow software engineer of dedicated terminal recording tools, such as Terminalizer and asciinema. However, these require some initial setup work, especially if you want to show off a theme and require that your animated terminal looks exactly like your actual terminal.
Since I already recorded most of the animations, I decided to stay with Peek for this post. Nevertheless, if your use case is terminal recording, you should probably go with one of the linked projects instead of Peek.

Mail Client: Thunderbird

For mail, I use Thunderbird. I don’t particularly like it, but to my knowledge it is still the best desktop email client for Linux. Unfortunately, some minor design decisions make the program almost unusable for me in its default state. The reason I include this section about software that everyone knows already is mainly to highlight three changes I always make to the default setup:

By default, Thunderbird sorts messages by date ascending. I think that’s an unfortunate default. Who wants to scroll down constantly to see the newest messages? To change the sort order to descending (newest first), go to Preferences -> General -> Config Editor and set mailnews.default_sort_order to value 2. See this StackExchange answer for more details about default sorting orders and other options.
Install the No Message Pane Sort by Mouse add-on. With this extension, a click on the mail list table header will no longer change the defined sort order. Without it, misclicks while trying to select the first mail in the list are very annoying. Personally, I never want to change the sort order at all. However, it is still possible by holding Ctrl while clicking.
Finally, go to Preferences -> Composition and uncheck the Use Paragraph format instead of Body Text by default to prevent Thunderbird from adding absurd amounts of whitespace whenever you press the Enter key while composing a mail.

Are you already using Thunderbird on another computer? Fortunately, there is an easy way to migrate all your mail accounts and settings. Essentially, you can copy a hidden folder where Thunderbird stores all its data and move it to the new machine, as described in Mozilla’s official documentation.

If you know of a new fancy alternative to Thunderbird that handles parallel usage of several mail accounts well, please let me know.

Bonus Tip

If you have read this far, I am willing to share my most secret Linux hack with you. Joking aside, it is very helpful to know what to do when your Linux workstation freezes. For some reason, I did not know until a couple years ago. Maybe the following trick can help you to avoid some forced restarts in the future.

The most flexible way to re-gain control of a system that has frozen completely is pressing Ctrl+Alt+F3. Then, use top and other process monitoring tools to find the process IDs of the faulty processes. Then, simply kill them (e.g. type kill <pid>, killall, or kill -9). Afterward, you can get back to your work using Ctrl+Alt+F1. (Source).

Conclusion

I hope this post showed you some tools or practices that you didn’t know yet. I have had a good experience with all of them. Especially switching from Bash to Zsh and installing the described plugins came with a real productivity boost. If you feel that I left out something important, I’d be very interested to hear your suggestions.

If you are not mainly using Linux yet, the length of this post might give the impression that it is still a pain to set up a proper Linux workstation. However, you do not necessarily need all of the things I showed here. Also, everything covered in this post is very easy to install with minimal configuration overhead. I strongly believe that you would have a much harder time setting up a comparable Windows development workstation.

You can still spend your life setting up Linux. However, if you use a popular, well-supported distribution you definitely don’t have to. (Source: xkcd.com)

Using Hugo, GitLab Pages, and Cloudflare to create and run this Website

Sat, 01 Jun 2019 00:00:00 +0000

In this post, I outline how I develop and run this blog site. I briefly explain my technology choices and give detailed instructions about how to use the resulting stack to create such a project. If you stick with me until the end, you will know how to run a beautiful, easily customizable static website for free.

When I decided to start this blog for the reasons outlined in my first post, I was already familiar with GitLab Pages, and the MkDocs static site generator. I am using this combination for creating documentation websites, and it is working very well.

Therefore, it was an easy choice for me to also rely on GitLab Pages for this site. I will cover its features in a later section of this post. With hosting already covered, I just needed to create the actual site.

Creating the site with Hugo

Before starting this blog, the only static site generator I used in production environments was MkDocs, which is intended for documentation and clearly not a good choice for creating a personal blog site.

A good overview of more appropriate alternatives is given on staticgen.com. For my purpose, probably all the popular projects would have been good choices. I decided to go with Hugo for two reasons:

It is written in Go, a language with a promising future that I wanted to try out for a while already.
There is a very well-curated list of open-source themes directly on the official website.

So let’s get to work.

To get started on Ubuntu, we can execute just two commands to install hugo and create a new project:

# install hugo
sudo snap install hugo

# create a new project
hugo new site personal-blog

If you are not using Ubuntu, your system’s package manager likely provides a similarly easy experience. Refer to the official documentation for installation instructions for other operating systems.

Before we start to work on our site, we want to install a theme:

# install the theme
cd personal-blog
git init
git submodule add https://github.com/luizdepra/hugo-coder.git themes/hugo-coder

I like that Hugo is very forward about using GIT submodules to install themes. This makes it easy to apply changes to the theme while keeping the connection to the original theme project. In an upcoming blog post, I will detail which changes I made to the theme itself. For now, we are perfectly fine with the default Hugo-Coder theme.

We only need to apply some basic configuration. Simply replace the content of config.toml with the following:

baseurl = "http://www.example.com"
title = "johndoe"

theme = "hugo-coder"

[params]
    author = "John Doe"
    description = "John Doe's personal website"
    keywords = "blog,developer,personal"
    info = "Full Stack Magician"
    avatarurl = "images/avatar.jpg"
    footercontent = "Enter a text here."

[taxonomies]
    series = "series"

# Menu links
[[menu.main]]
    name = "Blog"
    weight = 1
    url  = "/posts/"

Then, we create the first post:

hugo new posts/my-first-post.md

For the theme to properly recognize the new blog post, we have to replace the content of the newly created /content/posts/my-first-post.md with the following:

+++
date = "2019-01-01"
title = "My first Post"
slug = "my-first-post" 
tags = []
categories = []
series = []
+++

Finally, we can get a first look at our new personal portfolio and blogging site, by starting up the Hugo development server. Simply type

hugo server

Then go to http://localhost:1313/ to see your new site:

Hugo coder default page.

Testing your site locally is great, but showing the whole world that you are John Doe, the Full Stack Magician is something else entirely. Luckily, we are very close to doing just that.

Hosting with GitLab Pages

GitLab Pages is similar to GitHub Pages. Both allow free hosting of static websites. GitLab Pages enables you to build the hosted static content via GitLab’s CI/CD features. This means that your site will automatically be rebuilt on every commit to the repository. Until the release of GitHub Actions, GitHub could not do this. Instead, you had to build the site locally and commit the static files to the repository. Nowadays, both GitLab and GitHub are perfectly fine choices to host your static site.

Naturally, we start by creating a new repository. Before pushing anything to this repository, you might want to perform some usual GIT maintenance tasks, such as creating a .gitignore file. If you do not know it yet, you should have a look at the gitignore.io service service. The site generates .gitignore files depending on your technology stack. For Hugo, it will for example exclude the /public/ folder, which is very much what we want, because we will build this folder via a GitLab CI pipeline on every push to the repository.

Once everything is in order, we can simply follow GitLab’s instructions for pushing our existing project folder:

cd personal-blog
git remote add origin git@gitlab.com:<path-to-your-repository>
git add .
git commit -m "Initial commit"
git push -u origin master

Finally, we get to the exciting part: Having our site built and published on every new commit to the repository. If you are not yet familiar with GitLab’s CI/CD features, check out their docs.

Fortunately, getting started is very simple. Simply put a file called .gitlab-ci.yml in the root of your project. This YAML configuration file holds all CI/CD configuration. For our Hugo-powered blog, the following file content is sufficient:

image: monachus/hugo

pages:
    script:
    - hugo
    artifacts:
        paths:
        - public
    only:
    - master

The first line specifies the docker base image to use for our pipeline. For this brief tutorial, we will not use any testing stages, instead, we have just one simple job called pages. It executes the hugo command, which will build the static site content in the public directory. Somewhat incidentally, this is also where GitLab Pages expects to find our static site content. The only thing left to do is publishing the public directory as a job artifact. The last two lines are optional and state that the site should only be built and published on commits to the master branch.

Once you push this file to your repository’s master branch, the static site will be built and published within a few minutes. Go to Settings->Pages to verify that everything is in order and to see the default URL of your new website. If you own a domain you would like to use rather than the default *.gitlab.io one, you can head to the docs or check out this more detailed tutorial.

However, before you do this, you may want to read the next section of this blog post, as the information given there could spare you some headaches.

Speeding up load times and configuring URL redirections with Cloudflare

Initially, I configured SSL for this site via Let’s Encrypt. In principle, this is a perfectly fine way to do it. There is a good tutorial in the official GitLab Docs.

However, it is a little bit tedious, as it requires frequent renewals, a process that can not be automated easily. Furthermore, I had problems redirecting from www. to non-www URLs with Namecheap, which is my domain name registrar. The issue was complicated by the fact that this site uses a .dev domain which is by default on the HSTS preload list. Namecheap seems to prefer selling their own SSL certificates rather than fully support and document working with Let’s Encrypt.

I solved all those issues at once by simply signing up to Cloudflare. The free version is perfectly fine for me. After signing up, Cloudflare provides very simple and precise instructions for getting started. Basically, you have to configure your domain to use their nameservers instead of the ones provided by your original domain name registrar.

Once your site is configured to run with Cloudflare, you can use their Page Rules feature to easily redirect traffic from the www. subdomain to your canonical non-www URL or the other way around.

Furthermore, Cloudflare provides SSL encryption out of the box from their servers to your clients. All your static sites hosted with GitLab Pages and served via Cloudflare will be accessible over HTTPS without any additional configuration. Of course, we also want to encrypt the traffic from Cloudflare to the origin GitLab Pages host. For this, Cloudflare offers Origin Certificates. I will not explain this further, as there is an excellent tutorial on this provided directly by GitLab.

Edit: With GitLab 12.1, released on July 22, 2019, it is possible to automatically get HTTPS certificates for GitLab Pages using Let’s Encrypt. Using Cloudflare Origin Certificates is still a perfectly fine approach, however, it is no longer more convenient than just using GitLab’s Let’s Encrypt integration.

Conclusion

The biggest advantage of this setup is its financial cost. Apart from buying the tkainrad.dev domain, creating this site did not cost any money. Furthermore, the page is now running at absolutely zero cost. This is not restricted to a limited timeframe, thanks to GitLab Pages.

Fortunately, we do not have to resort to chemistry puns to reduce our hosting bills. (Source: xkcd.com)

If you have basic programming skills, I highly recommend hosting your static sites with this free service instead of paying a monthly fee to a hosting provider.

High-performance Computing with AWS Parallelcluster

Tue, 07 May 2019 00:00:00 +0000

Overview

AWS ParallelCluster is a toolkit for automating the process of building, configuring, and managing clusters of virtual machines on the Amazon Elastic Compute Cloud (EC2) cloud. These clusters can be used similar to traditional HPC clusters, as illustrated below.

Operating principle of a traditional resource-manager based computing cluster.

The software is essentially a command-line tool written in Python that provides simple commands for creating, updating, stopping, starting, and deleting HPC clusters in the AWS EC2 cloud. Naturally, to provide these functionalities, the locally installed CLI has to use the web APIs of existing AWS services. The most important one of these services is AWS Cloudformation. It facilitates the creation and management of a collection of related AWS resources. A set of nodes belonging to a specific HPC cluster can be such a collection. Another essential service is Auto Scaling, providing dynamic elastic scaling of the number of compute nodes depending on the current workload. As a consequence, ParallelCluster can be configured to automatically add nodes when jobs are pending and not able to run due to the cluster being fully utilized.

Cloud elasticity allows automated addition and deletion of nodes depending on the current job queue size.

ParallelCluster is maintained directly by Amazon Web Services (AWS) and developed as an open source project accessible on GitHub. While the restriction to AWS is certainly disadvantageous, the official support from and for a specific cloud provider results in a stable and regularly updated product. The latter is especially important for any framework facilitating cluster computing in the cloud, because the tool has to be able to deal with new versions of operating systems, updates to cluster computing software and changes in the product palette of the supported cloud providers.

Performance Compared to On-Site Clusters

HPC in the cloud faces complex challenges that have to be overcome in order to compete with on-site clusters. Specifically, these include the interconnection networks between machines in the cloud datacenters, which are most often not built for supporting HPC applications, and secondly, a performance decrease due to virtualization.

Already in 2009, Napper et al. have used the LINPACK benchmark to assess the performance of HPC clusters allocated in the Amazon EC2 cloud. The sobering conclusion has been that, at least for communication intensive problems, HPC in the cloud can not yet make use of its potential strengths regarding scalability and cost saving. To the contrary, it has been shown that the achieved floating point operations per second (FLOPS) per dollar spent decrease exponentially as the allocated cluster grows. This is, as expected, due to the slow interconnection network and limited memory available on single nodes. One year later, in 2010, Jackson et al. have performed similar experiments and also encountered the familiar problem of slow network connections. They observed a clear correlation between the runtime of different distributed applications and the amount of time spent communicating. However, Jackson et al. have also shown that for applications requiring little communication between computing nodes, HPC cloud clusters can scale well.

The situation has since progressed further. Real world problems are often embarrassingly parallel or come close to it, enabling all benefits of cloud computing, even with sub-par interconnection networks. This development is illustrated by various case studies of different scientific fields, especially the computational life sciences. Novartis used the Amazon EC2 cloud with 87 000 on-demand CPU cores to vastly decrease computation time for a VS experiment, a scientific technique explained in detail in Section 2.5. HGST built a similarly strong cloud cluster of 70 000 cores to run a simulation for finding an optimal hard drive head design.

Getting Started

Perhaps the most important benefit of using a cloud cluster is the possibility to set it up in a couple of minutes. Provisioning a physical HPC cluster requires competent system administrators, air conditioned space for the machines, a large up-front hardware investement, etc. etc.

Getting started with AWS Parallelcluster only requires an AWS account and the ParallelCluster software. Detailed instructions for creating an account can be found at the official AWS website. The installation procedure for ParallelCluster is also well described at the official docs.

Before you can configure ParallelCluster, it is need to create an AWS Access Key. To do this, click on your Account name in the top right of the AWS management console browser application. There is an option My Security Credentials. Additionally, you should create an AWS EC2 Key Pair via Services -> EC2 -> Key Pairs -> Create Key Pair.

Finally, you can set up your local ParallelCluster installation. Simply type

pcluster configure

in a terminal window. ParallelCluster will ask for the access key you just created. This automated configuration process will further be able to retrieve default values for master_subnet_id and vpc_id. These are otherwise a little tedious to find out. In general, you can just press enter on all questions except aws_access_key_id and aws_secret_access_key. More sophisticated configuration can easily be applied later by directly modifying the file ~/.parallelcluster/config.

The following is a basic configuration for an elastic cluster with one to five compute nodes:

[aws]
aws_region_name = eu-central-1
aws_access_key_id = <AWS_ACCESS_KEY_ID>
aws_secret_access_key = <AWS_SECRET_ACCESS_KEY>

[cluster default]
vpc_settings = public
key_name = <AWS_KEY_NAME>
ebs_settings = custom
post_install = <POST_INSTALL_SCRIPT_DOWNLOAD_PATH>
base_os = ubuntu1604
maintain_initial_size = true
compute_instance_type = c4.2xlarge
initial_queue_size = 1
max_queue_size = 5

[vpc public]
master_subnet_id = <AWS_MASTER_SUBNET_ID>
vpc_id = <AWS_VPC_ID>

[global]
update_check = true
sanity_check = true
cluster_template = default

[ebs custom]
ebs_snapshot_id = <SNAPSHOT_ID>
volume_type = gp2

Once your configuration is finished, you can create your first cloud cluster with a simple:

pcluster create <cluster-name>

Naturally, for working with AWS and ParallelCluster, you will want to also look at the official documentation. In the following I list some of the most important resources:

Parts of this blog post have been taken from my thesis on Providing Transparent Remote Access to HPC Resources for Graphical Desktop Applications. If you are further interested in working with AWS Parallelcluster you can freely download it here. For a brief description of an in-production AWS Parallelcluster use case, check out the journal article that has emerged from the thesis.