Skip to main content

Terraform azurerm provider version 4 setzt die Subscription ID als Mandatory Attribute

· 2 min read
Janno Tjarks
DevOps Engineer
note

Das Verhalten ist identisch bei terraform und opentofu. Im Folgenden wird opentofu bzw. die tofu cli genutzt.

info

Sämtlicher Beispiel-Code und Skripte finden sich auf GitHub.

Die Skripte sind speziell fuer UNIX-Systeme geschrieben und erwarten eine bash oder z-Shell.

Mit der Version 4 des terraform azurerm providers, wurde die Subscription ID aus Azure zum Pflichtfeld zur Erstellung neuer Ressourcen. Dies betrifft nicht nur den tofu apply, sondern auch bereits das tofu plan.

Vorher wurde bei Nutzung der Azure CLI immer die aktive Subscription aus dem User-Kontext genutzt.

Beim Fehlen der Subscription ID im Provider Block wirft der Aufruf von tofu plan nun die folgende Fehlermeldung:

Planning failed. OpenTofu encountered an error while generating this plan.


│ Error: `subscription_id` is a required provider property when performing a plan/apply operation

│ with provider["registry.opentofu.org/hashicorp/azurerm"],
│ on main.tf line 11, in provider "azurerm":
│ 11: provider "azurerm" {

Das einfachste Vorgehen ist natürlich, die Subscription ID direkt im Provider Block zu setzen:

provider "azurerm" {
subscription_id = "cf4ea9ae-cfef-4132-a5a1-c507a07a3371"
features {}
}

Alternativ dazu kann auch auf eine Umgebungsvariable mit dem Namen ARM_SUBSCRIPTION_ID gesetzt werden.

export ARM_SUBSCRIPTION_ID=cf4ea9ae-cfef-4132-a5a1-c507a07a3371

Um ein ähnliches Verhalten wie vorm Update der Version 4 beizubehalten, kann man sich via Azure CLI und dem CLI-Tool jq die aktuelle Subscription ID aus dem aktiven User-Kontext filtern und diese dann als Umgebungsvariable setzen.

export ARM_SUBSCRIPTION_ID=$(az account show | jq -r .id)

HTTP Redirect mit ingress-nginx im Kubernetes

· One min read
Janno Tjarks
DevOps Engineer

Mit der ingress-nginx annotation nginx.ingress.kubernetes.io/permanent-redirect koennen simpel HTTP Redirects umgesetzt werden

Ich nutze, wie z.B. fuer diesen Blog, gerne Azure Static Web Apps. Allerdings haben diese den Nachteil, das die Root einer Domain nicht als Custom Domain genutzt werden kann, so z.B. bei meiner Homepage - www.tjarks.dev, weil auf der root kein CNAME gesetzt werden darf/kann.

Um dennoch Zugriff via der root (tjarks.dev) moeglich zu machen, habe ich einen Ingress fuer den Host tjarks.dev in meinem Kubernetes Cluster gebaut, welcher auf Basis der nginx.ingress.kubernetes.io/permanent-redirect annotation ein Redirect auf https://www.tjarks.dev vornimmt.

nginx.ingress.kubernetes.io/permanent-redirect: https://www.tjarks.dev

Mehr Informationen zu der annotation koennen in der ingress-nginx Dokumentation gefunden werden.

Snippet

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: tjarks-dev
kubernetes.io/ingress.class: "nginx"
cert-manager.io/cluster-issuer: "letsencrypt-prod"
annotations:
nginx.ingress.kubernetes.io/permanent-redirect: https://www.tjarks.dev
spec:
ingressClassName: nginx
tls:
- hosts:
- tjarks.dev
secretName: tjarks-dev-tls
rules:
- host: tjarks.dev

Natives Wayland in Electron Apps

· One min read
Janno Tjarks
DevOps Engineer

Standardmaessig erwarten Electron Apps auch im Jahr 2024 X11 als Windowing System. Daher werden auf Wayland-Sytemen Electron Apps meist mit XWayland gestartet. Die Folge ist die bekannte Blurriness/Unschaerfe.

Allerdings beherrschen aktuelle Electron Apps bereits nativen Wayland Support. Hierbei spielt es auch keine Rolle, ob die Programme via Paketmanager lokal installiert wurden oder mit Flatpak.

Genutzt wird die sogenannte OZONE platform abstraction layer des Chromium Projektes. Als Platform kann mittels des command flags --ozone-platform=wayland die Nutzung von Wayland erzwungen werden.

Es folgen Beispiele zu VS Code und Obsidian in der Flatpak Variante.

Beispiele

VS Code

code --ozone-platform=wayland

Obsidian (Flatpak)

flatpak run --socket=wayland md.obsidian.Obsidian --ozone-platform=wayland

OpenTofu Binary bauen

· 3 min read
Janno Tjarks
DevOps Engineer

Nach einem Lizenzwechsel bei Terraform entstand mit dem OpenTofu Projekt ein Fork, damit die bekannte Toolchain weiterhin als Open-Source weiterentwickelt werden kann

Aktuell gibt es noch keine offizielen Binaries vom OpenTofu Projekt. Die Installation ist jedoch grundsaetzlich sehr simpel gehalten, da es sich um Go Tool handelt. Der Quellcode findet sich auf Github unter opentofu/opentofu.

Zum Bauen der Binaries wird der Go compiler benoetigt. Die notwendige Version ist im Git-Repository von OpenTofu in der Datei .go-version angegeben. Nach einem Download des Git-Repository kann in dessen Root-Verzeichnis der folgende Befehl ausgefuehrt werden:

go install .

Dadurch wird das OpenTofu CLI Tool zuerst compiliert und dann Go executable directory installiert. Mit dem Kommando go env GOPATH wird der Pfad zum Go executable directory ausgegeben.

Empfohlen ist, dass der GOPATH in die PATH Variable hinzugefuegt wird. Dadurch kann opentofu mit einem einfachen Aufruf von opentofu ausgefuehrt werden.

➜ 11:40PM janno opentofu (main) ✔ opentofu
Usage: tofu [global options] <subcommand> [args]

The available commands for execution are listed below.
The primary workflow commands are given first, followed by
less common or more advanced commands.

Main commands:
init Prepare your working directory for other commands
validate Check whether the configuration is valid
plan Show changes required by the current configuration
apply Create or update infrastructure
destroy Destroy previously-created infrastructure

All other commands:
console Try OpenTofu expressions at an interactive command prompt
fmt Reformat your configuration in the standard style
force-unlock Release a stuck lock on the current workspace
get Install or upgrade remote OpenTofu modules
graph Generate a Graphviz graph of the steps in an operation
import Associate existing infrastructure with a OpenTofu resource
login Obtain and save credentials for a remote host
logout Remove locally-stored credentials for a remote host
metadata Metadata related commands
output Show output values from your root module
providers Show the providers required for this configuration
refresh Update the state to match remote systems
show Show the current state or a saved plan
state Advanced state management
taint Mark a resource instance as not fully functional
test Execute integration tests for OpenTofu modules
untaint Remove the 'tainted' state from a resource instance
version Show the current OpenTofu version
workspace Workspace management

Global options (use these before the subcommand, if any):
-chdir=DIR Switch to a different working directory before executing the
given subcommand.
-help Show this help output, or the help for a specified subcommand.
-version An alias for the "version" subcomm

Das Collatz-Problem

· One min read
Janno Tjarks
DevOps Engineer

Beim einem Besuch bei der Linux User Group in Bremen Anfang des Jahres, lernte ich das Collatz-Problem - auch (3n+1)-Vermutung genannt - kennen.

Hierbei handelt es sich um ein mathematisches Problem, das 1937 vom Mathematiker Lothar Collatz formuliert wurde. Collatz erdachte den folgenden Bildungssatz:

  • Beginne mit irgendeiner natürlichen Zahl, wo gilt n > 0
  • Ist n gerade, so nimm als nächstes n / 2
  • Ist n ungerade, so nimm als nächstes 3n + 1
  • Wiederhole die Vorgehensweise mit der erhaltenen Zahl

Dessen dazugehoerige Vermutung lautet:

Die Zahlenfolge mündet immer in den Zyklus 4, 2, 1, egal, mit welcher positiven natürlichen Zahl man beginnt.

Trotz mehreren Aufrufen und mehreren Preisgeldern konnte bis zum Erscheinen dieses Eintrages die Vermutung nicht bestaetigt werden.

Wer Interesse hat, sich das Collatz-Problem einmal auf Software-Ebene anzusehen, kann einen Blick auf mein Github-Profil legen. Dort findet sich Sourcecode unter JannoTjarks/collatz, wo ich mich dem ganzen einmal genaehert habe. Es ist in Go geschrieben; daher verhaeltnismaessig gut lesbar! ;)

Markdown Reader in Visual Studio Code

· 2 min read
Janno Tjarks
DevOps Engineer

Visual Studio Code besitzt einen built-in Markdown Reader, aufrufbar über die Command Palette

Visual Studio Code hat seit seinem ersten Release in 2015 eine unglaublich große Nutzerbasis akquiriert - sowohl bei allen Arten von Softwareentwicklern als auch SysAdmins und NetAdmins.
Gleichzeitig halfen DevOps Plattformen wie Github oder auch Static site generators, z.B. Hugo oder Jekyll, beim Durchbruch von Markdown zur de-facto Standardsyntax für Dokumentation aller Art.
Daher bietet Visual Studio Code auch bereits im Default ohne Extensions aus dem Marketplace nützlich Features zum Schreiben in Markdown.

Visual Studio Code besitzt einen built-in Markdown Reader, der aufrufbar ist über die Command Palette oder über die Tastenkürzel CTRL+Shift+V bzw. Ctrl+K V. CTRL+Shift+V öffnet ein neues Tab innerhalb von Visual Studio Code, während Ctrl+K V hingegen eine Side-by-side Anzeige öffnet.

Side by Side View in VS Code

Da ich selber neovim Nutzer bin, kann ich mir den Hinweis nicht ersparen, dass eine ähnliche Funktionalität in Neovim mit dem Plugin markdown-preview.nvim nachgerüstet werden kann.

Desweiteren kann ich für Visual Studio Code Nutzer auch das Plugin markdownlint empfehlen, welche auf das gleichnamige Open-Source Tool basiert. Markdownlint ist ein Style Checker, der den geschrieben Markdown Text anhand fester Regel überprüft und so beim Schreiben von syntaktisch sauberen Markdown unterstützt. Zu dem Thema Markdownlint wird sicherlich in Zukunft noch ein eigener Post erscheinen.

Tastenkürzel

ActionWindows/LinuxMacOS
Side-by-side ViewCtrl+K VCmd+K V
View in new TabCTRL+Shift+VCmd+Shift+V

Dieser Blog ist mit Markdown verfasst; genutzt wird das built-in Blog Plugin von Docusaurus