DEV Community: Michael Friedrich

Efficient DevSecOps Pipelines in a Cloud Native World - free workshop

Michael Friedrich — Fri, 10 Dec 2021 16:37:58 +0000

Getting started with CI/CD has become more easy with the DevOps platform era. GitLab provides a new pipeline editor to help with onboarding, and allow to prevent common configuration mistakes.

Pipelines and their definitions are always changing, and a work in progress similar to source code development. It is easy to create a long lasting pipeline which blocks reviews from fast feedback, or waste ten thousands of dollars of cloud compute resources.

The overall question is - how to create efficient DevSecOps pipelines, and make use of all available options: Configuration, resources, CI/CD infrastructure, Security and Observability.

Based on the talk I had created after creating the CI/CD Pipeline Efficiency docs after a CI monitoring webinar ...

... I have now built a 10+ hours workshop for Open Source Automation Days 2021 with old and new best practices for everyone to learn and benefit. I've added new topics focussing on auto-scaling and cloud native deployments, whilst enriching the configuration examples with many hidden gems.

Yesterday, a discussion about a great blog post "Let's make faster GitLab CI/CD pipelines" on Hacker News inspired me to share the workshop and now blog about it. You can find all workshops in the GitLab Developer Evangelism handbook.

You can learn async at your own pace, with the slides providing the exercises and the solutions in a workshop project. Note that there is one exercise which needs preparations for auto-scaling which is described in the slides.

The following topics will be practiced:

Introduction: CI/CD meets Dev, Sec and Ops
CI/CD: Terminology and first steps
- Pipeline Editor
Analyse & Identify
- Learn using the GitLab CI Pipeline Exporter to monitor the exercise project throughout the workshop.
Efficiency actions
- Config Efficiency: CI/CD Variables in variables, job templates (YAML anchors, extends), includes (local, remote), rules and conditions (if, dynamic variables, conditional includes), !reference tags (script, rules), maintain own CI/CD templates (include templates, override config values), parent-child pipelines, multi project pipelines, better error messages to fix failures fast
- Resource Use Efficiency: Identification, max pipeline duration analysis, fail fast with stages grouping, fail fast with async needs, analyse blocking stages pipeline (solution with needs), matrix builds for parallel execution (pratice: combine matrix and extends, combine matrix and !reference), extends merge strategies (with and without !reference)
- CI/CD Infrastructure Efficiency: Optimization ideas, custom build images, optimize builds with C++ as example, GitLab runner resource analysis (sharing, tags, external dependencies, Kubernetes), local runner exercise, resource groups, storage usage analysis, caching (Python dependency exercise, including when:always on failed jobs)
- Auto-scaling: Overview, AWS auto-scaling with GitLab Runner with Terraform, insights into Spot Runners on AWS Graviton
Group discussion
- Deployment Strategies: IaC, GitOps, Terraform, Kubernetes, registries
- Security: Secrets in CI/CD variables, Hashicorp Vault, secrets scanning, vulnerability scanning
- Observability: CI/CD Runner monitoring, SLOs, quality gates, CI/CD Tracing
- More efficiency ideas: Auto DevOps, Fast vs Resources, Conclusion and tips

Take your time with learning, the workshop has a lot of topics inside. Let me know how it goes, and join https://forum.gitlab.com/ for questions and feedback (please tag @dnsmichi ). 🤗

Start exploring now

Everyone Can Contribute - learned a new gem from this workshop? Blog about it and share on social tagging @dnsmichi @gitlab! 💡

Blog originally published on https://dnsmichi.at/2021/12/10/efficient-devsecops-pipelines-in-a-cloud-native-world-free-workshop/

Use Homebrew Bundle to manage software installation on macOS

Michael Friedrich — Mon, 30 Nov 2020 15:37:55 +0000

Automation is iteration. First you'll find a way to make it work, and share your learnings - feedback and best practices help make it even better. When I first published my dotfiles - Document and automate your Macbook setup blog post, Nate suggested to use Homebrew bundle for a more clean management approach.

Homebrew bundle follows the same idea as known from Ruby bundle, has a Brewfile and specific keywords for packages to install.

First Steps with Homebrew Bundle

tap: Add more brew third-party repos
cask: Install application casks (Gimp, etc.)
brew: Install packages
mas: Install App store items (requires brew install mas)

You can also override the default cask installation path:

$ vim Brewfile

cask_args appdir: "/Applications"

tap "homebrew/cask"

cask "gimp"

brew "git"

mas "Slack", id: 803453959

Run it to see how it works.

$ brew bundle
Using homebrew/cask
Using gimp
Using git
Using Slack
Homebrew Bundle complete! 4 Brewfile dependencies now installed.

git from Homebrew is newer than the macOS Git binary.

$ git --version
git version 2.29.2

$ /usr/bin/git --version
git version 2.24.3 (Apple Git-128)

Homebrew's Git is installed into /usr/local/bin which has a priority in the PATH environment variable.

$ which git
/usr/local/bin/git

$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

Existing Homebrew Setup? No Problem

bundle provides the dump sub command which writes a new Brewfile with your current setup.

brew bundle dump

Homebrew automatically installs the bundle tap the first time the command is invoked, no extra preparations needed.

You can either use this file to continue working, or start fresh in your own Brewfile. You can also manually install software first and then analyse how a dump looks like.

Caveats with GNU tools (sed, tar, ...)

You can install GNU tools to avoid different parameters and behaviour with the native UNIX representation of sed, tar, etc. Homebrew provides binaries prefixed with the g character, so even an updated PATH variable won't help, requiring you to call gsed instead of sed. To keep compatibility with existing Linux scripts, I used symlinks created inside a brew setup script:

BREW_PREFIX=$(brew --prefix)
ln -s "${BREW_PREFIX}/bin/gsed" "${BREW_PREFIX}/bin/sed"

This isn't possible inside a Brewfile. Luckily this can be automated in your PATH, as the Homebrew formulas provide these symlink overrides on their own:

$ brew info gnu-sed

GNU "sed" has been installed as "gsed".
If you need to use it as "sed", you can add a "gnubin" directory
to your PATH from your bashrc like:

    PATH="/usr/local/opt/gnu-sed/libexec/gnubin:$PATH"

$ ls -la /usr/local/opt/gnu-sed/libexec/gnubin
total 0
drwxr-xr-x  3 mfriedrich  staff   96 Jan 15  2020 .
drwxr-xr-x  5 mfriedrich  staff  160 Jan 15  2020 ..
lrwxr-xr-x  1 mfriedrich  staff   14 Jan 15  2020 sed -> ../../bin/gsed

Collect the inventory from all GNU tools and render an update for your environment file. You can automate this task with this inventory snippet added to .oh-my-zsh/custom/path.zsh or .zshrc:

# GNU utils path overrides as default CLI tools
if type brew &>/dev/null; then
  HOMEBREW_PREFIX=$(brew --prefix)
  for d in ${HOMEBREW_PREFIX}/opt/*/libexec/gnubin; do export PATH=$d:$PATH; done
fi

If you prefer to use symlinks, you can do so too instead of the export. Keep in mind that the PATH environment is generated on each new terminal, while symlinks can run stale.

A complete example

Follow the iteration in this merge request and open the dotfiles repository to learn more.

My Brewfile focusses on my work as Developer Evangelist at GitLab with a local Linux-ified CLI environment and Docker. Heavier workloads are shifted into cloud environments. Image manipulation tools help with automating tasks for blog posts and workshops.

I'm also not pinning specific versions for packages, this is not supported by Homebrew bundle either.

cask_args appdir: "/Applications"

# Tap Homebrew
tap "homebrew/bundle"
tap "homebrew/cask"
tap "homebrew/cask-fonts"
tap "homebrew/cask-versions"
tap "homebrew/core"
tap "homebrew/services"

cask "java"
cask "visual-studio-code"
cask "firefox"
cask "vlc"
cask "wireshark"
cask "gimp"
cask "inkscape"
cask "jitsi-meet"
cask "handbrake"
cask "vagrant"
cask "spotify"

# System
brew "mas"
brew "curl"
brew "wget"
brew "git"
brew "vim"
brew "openssl"
brew "coreutils"
brew "moreutils"
brew "findutils"
brew "binutils"
brew "rename"
brew "gnu-sed"
brew "gnu-tar"
brew "gawk"
brew "gnutls"
brew "gnu-indent"
brew "gnu-getopt"
brew "tree"
brew "htop"
brew "pidof"
brew "pstree"
brew "grep"
brew "openssh"
brew "rsync"
brew "ssh-copy-id"
brew "screen"
brew "gmp"
brew "nmap"
brew "socat"
brew "rlwrap"
brew "dnstracer"

# Images, Audio, Video
brew "imagemagick"
brew "gifsicle"
brew "gifify"
brew "ffmpeg"

# Archive & Git
brew "xz"
brew "p7zip"
brew "git"
brew "git-lfs"
brew "tig"
brew "hub"

# Extract rpm file content with rpm2cpio *.rpm | cpio -ivd
brew "rpm2cpio"

# JSON
brew "jq"
brew "jo"

# Dev
brew "ruby"
brew "yarn"
brew "rbenv"
brew "python"
brew "go"
brew "cmake"
brew "openjdk"
brew "kind"

# GitLab Pages
brew "hugo"

# App Store
mas "1Password 7", id: 1333542190
mas "Slack", id: 803453959
mas "Telegram", id: 747648890
mas "uBlock", id: 1385985095

GitLab CI/CD pipelines and container registry for ARM Cortex firmware builds

Michael Friedrich — Thu, 21 May 2020 19:36:16 +0000

You'll learn best about a specific tool or program by helping users with their problems and questions. I have experienced this when starting with Nagios/Icinga more than 10 years ago. Today I am trying to help the GitLab community and learn myself a lot. Often I just have an idea but never tackled the code or environment myself.

Today I have found a question on the GitLab forums on the first steps with CI/CD. It actually involved building source code for an ARM Cortex hardware architecture:

to build a small cortex-m4 firmware

The question was about a specific build step and make not being found. Also, whether the Docker-in-Docker image build really is the correct way of doing it.

Never did that before for ARM Cortex builds. The question also included a link to the project repository and its .gitlab-ci.yml with all the details there. It also showed the build error right in front of me.

Guess what I did next? Right, the power of open source and collaboration - I forked the repository into my account!

Analyse the first make error

The Docker-in-Docker approach is used to build a new image providing the cortex-m4 hardware specific build tools. Among the container build steps there was one which executed a test.sh script which ran make.

Ok, then let's just see how to install make into the docker:git image. Wait, which OS is that?

$ docker run -ti docker:git sh

/ # cat /etc/os-release
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.11.6
PRETTY_NAME="Alpine Linux v3.11"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://bugs.alpinelinux.org/"

/ # apk add make

OK: 26 MiB in 26 packages

The CI build runs fine now, the script does something. But does it really compile the binaries ... it is executed in the outer Alpine Docker container, not inside the newly created build image.

Build the image, then compile inside the image

Then I remembered the two stages for GitLab CI/CD and the container registry:

First, create a new build image with your tool chain. Push that into the container registry.
Second, define a new job which uses this image to spawn a container and compile the source code from the repository

To better visualize this, let's create two stages as well:

stages:
  - prepare
  - build

Tip

Use the Web IDE for syntax highlighting and direct CI/CD feedback in the upper right corner.

To prepare this environment, define these variables: DOCKER_DRIVER is read by the CI/CD Runner environment in the background, while the IMAGE_TAG allows a shorter variable reference for the GitLab registry URL to the container image.

variables:
  DOCKER_DRIVER: overlay2
  IMAGE_TAG: $CI_REGISTRY_IMAGE:$CI_COMMIT_REF_SLUG

Build and push the Docker image

The next step is to define the build image. Ensure that the Dockerfile is located in the main repository.

Wait, there was Docker-in-Docker? Yes, the CI/CD runners use the Docker executor, so every job on its own is run inside a container.

A container does not run any services by default.
You want to build a new Docker image inside this job container.
There is no Docker daemon answering docker login at first.

The trick here is to virtually share the runner's Docker daemon socket with the job container building the image. This happens in the background, only visible with the settings for image: docker and service: docker:dind.

Things to note:

The job name prepare/image can be freely defined and is just an example.
The image is defined in the job scope and uses the DinD docker:git image
The job belongs to the prepare stage
Before any script is run, the login into the container registry is persisted once
The docker:dind service must be running to communicate with the outside Docker daemon
The script invokes building the Docker image and tagging it accordingly. If this steps success, it pushes the newly tagged image to authenticated container registry.

# Build the docker image first
prepare/image:
  image: docker:git
  stage: prepare

  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_JOB_TOKEN" $CI_REGISTRY

  services:
  - docker:dind

  script:
    - docker build --pull -t "$IMAGE_TAG" .
    - docker push "$IMAGE_TAG"

Compile the source code

The reason for creating the Docker image is a different architecture and specific cross compilation requirements for the ARM Cortex architecture. A similar approach is needed when building binaries for Raspberry Pis with using QEMU for example.

Things to note:

Use the previously tagged image
Assign the job to the build stage
Run the compilation steps in a script provided in the same Git repository. It is located in scripts/build.sh.
The binaries need to be stored somewhere. The easiest way is to define them as artifacts and store them on the GitLab server in the job.

# Build the source code based on the newly created Docker image
build/source:
  image: $IMAGE_TAG
  stage: build
  script:
    - ./scripts/build.sh 
  artifacts:
    paths:
      - "thermo/*.bin"

Conclusion

I didn't achieve this in one shot, so don't fear a build to fail and another Git commit to attempt to fix it. The hardest challenge is to understand the code and scripts from someone else, and iteratively learn.

Open source definitely helps as we can collaborate and work on the different challenges. You can see my attempt in this merge request.

More questions on GitLab CI/CD first steps? Hop onto the forum and maybe we'll write another dev.to post from our findings!

Emojis everywhere - supercharged with Alfred workflows

Michael Friedrich — Fri, 24 Apr 2020 13:52:20 +0000

I fell in love with macOS because of the gestures and workflows. Alfred improves this behaviour with custom workflows and many more convenient shortcuts for locking the screen.

There are various reasons to use a workflow with shortcuts:

Speed & productivity, avoiding context switches.
The editor window doesn't support emojis (outside of GitLab, GitHub, etc., typing :heart has no effect).
You don't want to type, search and copy on Emojipedia all the time.

The Alfred Powerpack allows you to add custom workflows. You'll need to pay for the Alfred license but the time savings are well invested imho. Keep in mind that there are more workflows and the possibility to create your own.

The emoji workflow for Alfred needs to be downloaded and imported into Alfred. Considering that you replaced Spotlight with Alfred, use the following shortcut and type emoji to trigger the workflow:

Cmd + Space
emoji

Then type as you go and search for the emoji. Cursor up/down for selection, and Enter to copy it to the clipboard.

heart
Enter

Now you can easily insert it your text flow.

Alt + Tab
Cmd + v

The more often you use the emoji workflow, the less you need to type. Mine looks like this:

Cmd + space
e
<shows emoji, enter to autocomplete>
Enter
<heart is the first one>
Enter

Alt + tab
Cmd + v

Now let's spread the emoji love everywhere! ❤️❤️❤️

dotfiles - Document and automate your Macbook setup

Michael Friedrich — Fri, 17 Apr 2020 14:45:32 +0000

Why dotfiles

When I first started working on Windows, Linux and macOS many years ago, there was this steep learning curve. Not everything on the system had a good default for improved productivity, often tools were missing to create your own work environment.

At first glance, I started writing blog posts and shared my findings with everyone. This had the benefit that I exactly knew where these snippets can be found. Many years ago, systems were not so reliable and often a full operating system reinstall worked better than troubleshooting existing problems.

After some years, many best practices had been documented in blog posts and were hard to apply in one go. Especially with working in many areas for development, professional services, ops and support, different settings and tools have been applied. At that point I had created a wiki page with text and screenshots.

The wiki page allowed for many revisions, and was kept in the internal Confluence since it contained company sensitive information. I often was asked how my Linux and macOS setup looks like and if I could share best practices.

Then I learned that users share their configuration and setup commands in a Git repository which is called “dotfiles”. At first glance, a dotfile is a hidden file on a Linux/Unix system, containing tool specific settings. Common tools are Git, vim, bash storing their configuration in a dotfile in the user’s home directory.
These dotfiles were enriched with scripts to install additional software via package managers, and to apply certain runtime configuration after the work environment was setup the first time.

dotfiles on my Macbook

My first steps with dotfiles started at the point where updating the Confluence wiki became troublesome. It also was the only left bastion where I could not write documentation in Markdown. Within the dotfiles Git repository, best practice always has been a README.md file which describes more details and tips. Copying snippets and scripts for everyone also has become easier. Users can even fork the repository and use this as a basis for their own work environments.

Navigate into my dotfiles repository to learn more. The following sections highlight some of my daily best practices as a Developer Evangelist at GitLab.

ZSH with OhMyZSH

macOS Catalina uses ZSH by default. Therefore I was looking into best practices and soon learned about OhMyZSH as shell framework. It comes with nice plugins which provide a native Git shell integration as well as exporting credentials as environment variables.

In addition to the built-in functionality, it is easy to add custom aliases and settings. Avoid clutter inside the main .zshrc file, instead extend .oh-my-zsh/custom/aliases.zsh for example. The following alias allows to clean up the local git branches very easily:

# Delete all remote tracking Git branches where the upstream branch has been deleted
alias git_prune="git fetch --prune && git branch -vv | grep 'origin/.*: gone]' | awk '{print \$1}' | xargs git branch -d"

Git Configuration

My Git configuration is rather simple. The reason I keep it inside the dotfiles repository is that I always forget about the Git CLI commands to set them properly. Over the years, all my preferred customizations have been applied in Git itself. The only minimalistic addons are a custom git log command and the credential helper setting. I need that for storing the GitLab personal token and not being asked by git push/pull all the time.

$ cat ~/.gitconfig

[user]
    name = Michael Friedrich
    email = mfriedrich@gitlab.com
        signingkey = D14A1F16
[alias]
        l  = log --graph --pretty=format:'%Cred%h%Creset %C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative --
[credential]
    helper = osxkeychain

The Git shell prompt integration is done with OhMyZSH as plugin. Previously I had done this with a customized Bash profile. I decided to go for ZSH with macOS Catalina and my new job at GitLab.

vim Configuration

Even with habits changed to using VS Code/Atom or the Web IDE, I am still very fast with vim, especially with spell checking included. I've been carrying this .vimrc file around for more than 10 years now and it always helped :) Here is the best of - there is more inside with syntax highlighting and restoring the cursor on re-open.

set viminfo='20,<1000,s1000,:20,%,n~/.viminfo “ Increase buffer size for search
set history=50            " keep 50 lines of command line history
set ruler                      " show the cursor position all the time
set nofixeol                 " don't fix end-of-line errors
"set background=dark
set background=light
set showcmd              " Show (partial) command in status line.
set showmatch           " Show matching brackets.

Install favorite software and tools

Homebrew is my favorite package manager on macOS. It ranges from adding simple tools like “htop” to applications not available in the app store like “Gimp”.

In order to keep things simple, the brew_once.sh script takes care of installing Homebrew, enabling the cask system for applications and installs wget/curl to setup OhMyZsh.

./brew_once.sh

Additional software is installed with the “brew.sh script. This can be re-run any time to ensure the same state is applied. This will be useful if an application was accidentally removed. Please fork the repository and adjust everything for your likings!

./brew.sh

The script takes care of installing the following:

GNU utils (sed, awk, tar, sha256sum). The macOS utils differ a bit and may break scripts made for Linux.
System tools (htop, pidof, pstree, grep, screen, nmap, ssh-copy-id, tree)
Images (imagemagick) for easy conversions
Archive and Git (git, git-lfs, p7zip, xz, tig, hub)
JSON (jq, jo)
Development (Ruby, Python, Go, Redis)
Applications as cask (Java, Atom, VS Code, Firefox, VLC, Gimp, Vagrant)

Enhanced Workflows with Alfred

Alfred is not only a Spotlight replacement for opening applications or searching files. The major selling points are custom workflows accessible by quick typing. Picking HTML color codes, querying DNS records or copying emojis all over the place have become easier with quick shortcuts.

Tired of locking your screen on macOS? Cmd+Space, l, Enter after Alfred has learned that l means lock. Yep, it remembers the most often typed commands.

Trackpad and Keyboard

I always used to have a mouse with me for my previous notebooks, and the change to the trackpad always worried me. Move the mouse, click here and on it goes. When I got my first iPad, I got introduced to just tapping and approving.

I’ve learned that this setting can be enabled on macOS too for the trackpad which is my preferred input method since then. In order to automate this setting, run the following CLI commands:

defaults write com.apple.driver.AppleBluetoothMultitouch.trackpad Clicking -bool true
defaults -currentHost write NSGlobalDomain com.apple.mouse.tapBehavior -int 1
defaults write NSGlobalDomain com.apple.mouse.tapBehavior -int 1

Another thing I prefer using - the right click for accessing the actions toolbar. By default, the secondary click is available with two fingers. My improved workflow prefers the right bottom corner of the trackpad. You can either change this inside the trackpad preferences or run these CLI commands:

defaults write com.apple.driver.AppleBluetoothMultitouch.trackpad TrackpadCornerSecondaryClick -int 2
defaults write com.apple.driver.AppleBluetoothMultitouch.trackpad TrackpadRightClick -bool true
defaults -currentHost write NSGlobalDomain com.apple.trackpad.trackpadCornerClickBehavior -int 1
defaults -currentHost write NSGlobalDomain com.apple.trackpad.enableSecondaryClick -bool true

Last but not least using tab for changing the focus area in windows is a must have. This is hidden in the keyboard shortcut settings as use keyboard navigation to move focus between controls.

defaults write NSGlobalDomain AppleKeyboardUIMode -int 3

Additional ideas and commands can be found in this repository.

Documentation

Everything else is stored in the GitLab repository, including the documentation in Markdown format. Additional screenshots can be put there too into the doc/images directory for example.
There is no need to carry an extra wiki page around and everyone can access the repository via URL. You can also download the whole archive and work offline.

The best thing about my dotfiles repository - it is open source and we can learn, share, suggest together :-)
Do you have a cool idea for making this even more convenient? Fork the repository and send a merge request please!

This blog post was originally posted on about.gitlab.com/blog.