Posted on

Some Tips for CKA Exams

I’ve passed my CKA exam on my first attempt, it’s not hard because it’s the entry level certificate for Kubernetes but still a good preparation is necessary even for someone already experienced in Kubernetes.

First of all, the exam is fully hands-on: every question requires a set of commands done in a terminal provided in the browser. And what’s even better is that there’s a handful of real Kubernetes clusters provisioned for the test and can be accessed via the terminal. The exam provides 2 sessions of simulated CKA tests, which are very helpful to get familiar with the environment. Also the simulated tests are actually harder than the real ones.

Simulated exams by killer.sh

Most likely typing in the browser based terminal consumes the biggest portion of time, so it’s beneficial to practice Kubernetes and even Bash commands in advance. Here are some tips to improve the efficiency of the terminal:

  • There’s an alias k for kubectl, use k instead
  • Be familiar with a terminal based text editor, such as Vim
  • All commands can be re-used from the command history, ie. use ctrl-r to search previous commands instead of using up arrow multiple times
  • Use tab completion for kubectl commands as much as possible

As there are multiple Kubernetes clusters available for the test, it’s very important to make sure working on the correct cluster. Same goes for the namespace. So in the beginning of a question, execute the following 2 commands first:

# select the correct cluster
k config use-context <cluster-name>
# set the current namespace
k config set-context --current --namespace=<namespace>

Last but not least, if you use a Linux desktop to take the exam as I did, make sure to switch to an Xorg session. Wayland screen sharing doesn’t work properly with Chrome and your proctor won’t be happy to see a black screen.

Good luck 🙂

Posted on

Passing Environment Variables to Terraform with RegExp

In a Terraform template, an input variable can be used to set some configuration point for a resource, such as

variable "some_prefix" {
  type = string
}

resource "google_service_account" "some-sa" {
  account_id   = "${var.some_prefix}-sa"
  display_name = "Some Service Account"
}

In some scenario the input variable can get its value from an environment variable in the shell where terraform runs. It looks like

export TF_VAR_some_prefix=my-test
terraform plan

This is handy where there is just a few variables. If there are many input variables to be set from environment variables, I thought it’s cool to let sed have a go to reformat shell environment variables to Terraform .tfvars file which terraform can load automatically.

# tested with GNU sed 4.7 in Ubuntu 20.04
# given input
# KEY1=value1
# KEY2="value with space"
# ...
# expected output in tfvars file
# key1 = "value1"
# key2 = "value with space"
# ...
env | sed -r 's|^(.+)="*([^"]+)"*$|\L\1\E = "\2"|g' | terraform fmt > terraform.tfvars
# note:
# this only considers double quotes
# \L starts the transformation to lower case
# \E stops that
# the terraform fmt command is optional, just to make the .tfvars file linted with nice indentations

Reference:
– https://stackoverflow.com/questions/2777579/how-can-i-output-only-captured-groups-with-sed

🙂

Posted on

Share Environment Variables in GNU Make

I think writing up a cheat sheet for GNU Make and environment variables before Christmas is a good idea, right?

In GNU Make, by default a single line runs in its own shell. ie. 

# Makefile
test1:
  export key=asdf
  # GNU make's variable appears as $(key) while bash environment variable appears as $${key}, as the $ needs to be escaped
  echo $${key}
  
# run it
make test1

# the value `asdf` doesn't get passed to the next line because the next line runs in a separate shell

We can use backslash to fake multi-line like this:

# Makefile
test1:
  export key=asdf; \
  echo $${key}
  
 # run it
 make test1
 asdf

With .ONESHELL directive multiple lines in one target run in a same shell, which I prefer a lot:

# Makefile
.ONESHELL

test1:
  export key=asdf
  echo $${key}
  
# run it
make test1
asdf

A shell environment variable can be accessed inside a Makefile as a make variable with same name, eg.:

# Makefile
test1:
  echo $(key)
  
# run it with the required environment variable
key=asdf make test1
asdf

Here it’s getting more interesting, as shell environment variables will be copied into its sub-shell, in this case the make command runs in a sub-shell of current session. However if an environment variable is set in one target, the result is not available in a sibling target or its parent target. eg.:

# Makefile
test1:
  export key=asdf
  
test2: test1
  echo $${key}
  
# run it, can you guess the result?
make test2

# yep, blank again. the `test1` target in `test2` runs in a sub-shell and doesn't share environment variables with `test2`

To let test1 “export” environment variables to test2 target, I learned that eval command is quite handy in this situation:

# Makefile
.ONESHELL
test1:
  echo export key=asdf
  
test2:
  eval $$(make test1)
  echo $${key}
  
# run it
make test2
asdf

The reason this works is that the eval command will construct a new shell command using the arguments it gets, in this case, it’s export key=asdf from the output of test1 target. Then by running it, the value ‘asdf’ has been assigned to the variable ‘key’.

Hope this helps 🙂

Posted on

My Last Dota 2 Game

I started playing Dota 2 in 2014 because:

  • It was a fun game
  • Can run natively on Linux

I picked it up again when the lock down started in 2020, and played quite a lot in the following months. Until I thought I have had enough Dota, because:

  • The game was getting more complicated and punished casual players who don’t pay a lot of attention to each update
  • which made the game like chess but some rules change from time to time
  • Dota+ is a paid subscription which can help casual players a bit but
  • I became depending on the subscription
  • Also it’s harder to have fun without a fixed team. Maybe too many teenager players?

Anyways to my surprise after 400+ days without a single Dota 2 game, I actually felt better. Good bye Dota 2.

🙂