MDV

Das kleine Programm mdv kann Markdown auf der Konsole rendern, sodass ein vereinfachtes lesen gegenüber des Quelltextes auf der Konsole möglich wird.

Installation

Der Terminal Markdown Viewer lässt sich einfach per yay aus dem AUR Repository installieren.

 yay -S --noconfirm terminal_markdown_viewer

Markdown anzeigen

Das Programm befindet sich nach der Installation in /usr/bin/mdv und steht daher mit dem Paket pyhton-markdown im Konflikt.

Mit Scrolling

Man kann den Output von mdv nach less pipen, aber dann werden in der Standardeinstellung die Escape Colorsequenzen nicht angewendet und man hat nur Zeichensalat. Damit less nun diese interpretiert, muss der Parameter -r angegeben werden. Daraus ergibt sich nun folgender Aufruf von mdv:

mdv readme.md | less -r

Eine Vereinfachung ist, wenn man sich einen simplen Wrapper dafür anlegt. Dieser muss in dem ausführbaren Pfad liegen und vor /usr/bin eingebunden sein.

#!/bin/bash
mdv $0 | less -r

Midnight Commander

Mit F3 kann man im MC Dateien anschauen. Die Dateierweiterungen lassen sich konfigurieren, sodass man für die Endung .md für Markdown Dateien einen neuen externen Viewer definieren kann.

Hier kommt nun wieder less -R ins Spiel. Definiert man folgenden Regulären Ausdruck in der Datei ~/.config/mc/mc.ext welche sich über Befehl -> Erweiterungsdatei bearbeiten editieren lässt:

# Markdown
regex/i/\.md?$
    View=/usr/bin/mdv %f | less -R

dann kann man mit F3 auf die Markdown Datei die sich im Hintergrund bei MC anzeigen lassen.

Speicherung der Credentials für GIT auf der Komandozeile

Oft ist es so, dass man auf einem Server (wo man nur die Kommandozeile zur Verfügung hat) sehr mühselig jedes Mal beim Pushen oder Pullen die Credentials einzugeben. GIT kann diese dauerhaft speichern, was den Komfort deutlich erhöhen kann. Ob dieses zu einem Sicherheitsrisiko führt, ist hier nicht Thema und wird nicht weiter betrachtet.

File Storage einrichten

git config --global credential.helper 'store --file ~/.my-credentials'

Skopeo

Das CLI Tool Skopeo ist ein nützlicher Helfer, wenn es um Arbeiten mit Images insbesondere das Kopieren geht.

Installation

Die Installation unter Manjaro erfolgt mit yay oder Pacman.

  yay -S skopeo

bzw. mit pacman

  pacman -S skopeo

Beispiele

Die Anwendungsmöglichkeiten sind vielfältig. Ich werde diesen Artikel später erweitern.

Kopieren eine Containers

Als Beispiel verwende ich hier eine sehr einfache lokale Registry, um Kopien von Images zu hosten. In diese Registry sollen zur Anschauung ein Image kopiert werden.

Setup lokale Registry

Zunächst benötigen wir für das Beispiel eine lokale Registry. Diese ist mit Docker schnell aufgesetzt. Die lokale Registry lauscht auf dem Port 5000.

docker container run -d --name registry.localhost -v local_registry:/var/lib/registry --restart always -p 5000:5000 registry:2

Nun kann man unter localhost:5000 die Registry verwenden. Um in die Logs zu schauen verwende ich . Dieses ermöglich mir einen einfachen Einblick in den Container und die Logausgaben. Weitere coole Features kann man unter lazydocker auf GitHub nachlesen.

Image mit Skopeo kopieren

Mit dem copy Parameter können Images bequem von einer Registry zu einer anderen kopiert werden. In dem Beispiel wollen wir das offizielle Nginx Image in die lokale (insecure registry) kopieren. Da es eine unsichere Registry ist und nur HTTP spricht, muss der Parameter –dest-tls-verify=false gesetzt sein, da sonst keine Verbindung mit dem HTTP Protokoll zu Satnde kommt.

skopeo copy --dest-tls-verify=false docker://nginx:latest docker://registry.localhost:5000/nginx:latest

Kopie von Skopeo überprüfen

Das neu kopierte Image kann schnell mit curl überprüft werden.

curl -s localhost:5000/v2/_catalog | jq
{
  "repositories": [
    "nginx"
  ]
}

Gitea Helm Chart

Seit kurzem gibt es ein Gitea Helm Chart das von Gitea betreut wird. In diesem Artikel zeige ich wie man einfach eine neue Instanz von Gitea mit K3D ausetzen kann.

Install on K3D/K3S Cluster

Die Installation mittels Helm ist einfach. Zunächst muss das Repository von Gitea hinzugefügt werden. Ein obligatorisches helm repo update aktualisiert alle Repositorys, so dass nun eine Installation erfogen kann.

Für die Installation sind minimale Parameter anzupassen:

Parameter Beschreibung Wert
persistence.size PVC Größe Gitea 100Mi
postgresql.persistence.size PVC Größe Postgres 100Mi
ngress.enabled Ingress erlauben true
ingress.hosts[0] Host FQDN gitea.XXX.org
persistence.storageClass StorageClass local-path

Achtung: K3D/K3S erzeugt automatisch eine Storage Class local-path. Der Name der Storage Class muss daher hier in dem Gitea Helm Chart angepasst werden.

helm repo add gitea-charts https://dl.gitea.io/charts/
helm repo update

helm install gitea gitea-charts/gitea \
    -n gitea --create-namespace \
    --set persistence.size=100Mi \
    --set postgresql.persistence.size=100Mi \
    --set ingress.enabled=true \
    --set ingress.hosts[0]=gitea.XXX.org \
    --set persistence.storageClass=local-path

Kubectl Autovervollständigung für die Bash

Das zentrale Administrationsprogramm kubectl bietet die Möglichkeit Bash Completion zu erstellen, so dass die Autovervollständigung funktioniert.

Installation der Bash-Completion

Falls die bash-completion nicht nicht installiert sein sollte, so kann dieses mit:

yay -S --noconfirm install bash-completion

schnell installiert werden.

Hinweis: Damit die Completion wirksam wird, muss man sich einmal an der Shell abmelden.

Bash Completion einbauen

Zunächst muss die aktuelle Beschreibung der Autovervollständigung erzeugt und unter /etc/bash_completion.d gespeichert werden.

sudo kubectl completion bash > /etc/bash_completion.d/kubectl

Sofortige Wirkung

Die neue Autovervollständigung würde erst ziehen, wenn man sich an einer neuen Sitzung der Bash anmeldet. Es gibt aber auch die Möglichkeit mit source dieses zu umgehen.

 source /etc/bash_completion.d/kubectl

Jetzt sollte die Autovervollständigung in der Bash für kubectl funktionieren.

k als Alias für kubectl

Wer k als Alias für kubectl gesetzt hat wird enttäuscht sein, da es nämlich nicht wie erwartet funktioniert. Für das Komando k sind die Autovervollständigungen schlicht nicht definiert.

Fügen sie complete -F __start_kubectl k mit in ihre .bashrc ein. Dann wird auch das Alias k die Autovervollständigung anzeigen.

echo 'complete -F __start_kubectl k' >>~/.bashrc

Lens

Lens plattformunabhängiges Dashboard für Kubernetes Cluster. Es integriert sogar die Installation von Helm Charts aus einem Helm Repository von der UI. Hier lassen sich vor der Installation Parameter anpassen. Installierte Charts können auch wieder entfernt werden. Getestet habe ich das mit einem lokalen K3D Cluster.

Insgesamt macht das Programm von seinem Umfang und der Optik einen guten Eindruck.

Installation

Die Installation geht unter Manjaro oder Arch Linux schell mit yay:

yay -S --noconfirm lens-bin 

ArgoCD Ingress patchen

In einem ArgoCD Cluster habe ist in dem Ops Repository in dem Ingress ein anderer Host angegeben, als den den ich gerade in dem laufenden Cluster benötige.

Eine Änderung (ein Commit) kam für den schnellen Test nicht in Frage und ein neues Repository wollte ich auch nicht dafür erstellen. Also musste das Ingress gepatcht werden.

Die Liferay Instanz läuft in dem Namespace liferay-prod und der FQDN soll auf k8s-liferay.domain.de geändert werden. Hierfür eignet sich jq hervorragend. Es wird das Value für den Host gesetzt und per Pipe direkt wieder angewendet.

k get -n liferay-prod ing/nginx-ingress -o json | jq '(.spec.rules[].host) |= "k8s-liferay.domain.de"' | kubectl apply -f -

Installation von CodiMD in einen K3D Cluster

CodiMD ist ein Webbasierter Editor für Markdown und Extensions. In diesem Artikel beschreibe ich kurz die Probleme die ich beim Deployment in einem K3D Cluster hatte, bevor ich die Anwendung lokal nutzen konnte.

Installation von CodiMD mit Helm

Bei der Installation von CodiMD sind insgesamt 2 Probleme aufgetaucht, die eine reibungslose Installation verhindert haben.

Docker Registry

Bei meinem Versucht die Installation durchzuführen, schlug immer das Downloaden des Images von CodiMD fehl. Erst die Änderung des Registry Eintrags in dem Helm Chart auf die standard Docker Hub Registry, vermag das Image hackmdio/hackmd zu pullen.

image:
  pullPolicy: Always
  pullSecrets: []
  registry: registry.hub.docker.com
  repository: hackmdio/hackmd
  tag: 2.1.0

Die Storage Class ist nicht gesetzt

PVC konnte nicht geclaimt werden. In der Default Einstellung steht Storage Class auf ‚-‚, was aber anscheinend nicht dem Default aus Kubernetes entspricht, sodass kein Claim gesteckt werden kann. Und somit fährt der CodiMD Container nie hoch. Erst das Setzen der Storage Class auf local-path schafft hier abhilfe.

  imageStorePersistentVolume:
    accessModes:
    - ReadWriteOnce
    enabled: true
    size: 10Gi
    storageClass: local-path
    volumeMode: Filesystem

K3D / K3S Storage class

K3S unterstützt OOTB die Kubernetes Storage Class local-path. Diese ist auch die default Einstellung in Kubernetes, was man mit kubectl get storagesclass leicht überprüfen kann.

k get storageclass
NAME                   PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
local-path (default)   rancher.io/local-path   Delete          WaitForFirstConsumer   false                  14d

yq ist das Schweizer Messer für YAML Dateien

Leider gibt es zwei Programme die den Namen yq besitzen und auch den selben Zweck erfüllen. Beide Programme behandeln YAML Dateien auf der Konsole.

In diesem Artikel beschreibe ich die Version von Mike Farah. Für Arch basierende Distributionen wie Manjaro gibt es yq allerdings noch nicht.

Das PKGBUILD

Leider gibt es im AUR Repository noch keinen Eintrag, sodass ich kurzerhand das folgende PKGBUILD zusammengestrikt habe.

# Maintainer: Sascha Pfau

pkgname=yq
pkgdesc="portable command-line YAML processor written in Go"
pkgver=3.3.4
pkgrel=0
arch=('i686' 'x86_64')
url="https://github.com/mikefarah/yq"
license=('MIT')
makedepends=('go' 'rsync')
source=("https://github.com/mikefarah/yq/archive/${pkgver}.tar.gz")
sha256sums=('b0c44a742a9b6eed25a48ff04bb30e3e05c6c2d5a0c869f9d0d7f778dfd40f05')

# See https://wiki.archlinux.org/index.php/Go_package_guidelines
prepare(){
  cd "$pkgname-$pkgver"
  mkdir -p build
}

build() {
  cd "$pkgname-$pkgver"
  GOPATH="$srcdir" go build -v 
}

package() {
  install -Dm755 "$pkgname-$pkgver"/$pkgname "$pkgdir"/usr/bin/$pkgname
}

Funktionsübersicht

In der folgenden Tabelle sind die grundlegenden Kommandos aufgeführt.

Kommando Beschreibung
read Werte auslesen
validate
compare YAML Dateien vergleichen
write Werte schreibe
create YAML Dateien erstellen
delete
merge
prefix

Bash completion

Kubernetes Konfiguration bearbeiten

Da Kubernetes die Manifeste in YAML Dateien sichert und einliest, eignet sich yq hervoragend um diese zu bearbeiten. Die herkömmlichen Tools awk, sed etc. kommen hier schnell an ihre Grenzen. Zumal yq auch mit multi document YAML Dateien umgehen kann.

Beispiel

In dem Beispiel verwende ich ein Gitea Konfiguration die aus einem Dokument besteht.

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: gitea
  namespace: env
  labels:
    name: gitea
spec:
  replicas: 1
  strategy:
    rollingUpdate:
      maxSurge: 0
      maxUnavailable: 1
    type: RollingUpdate
  template:
    metadata:
      labels:
        name: gitea
    spec:
      # Initial rights settings when creating disk can be incorrect
      # for the git user in the gitea container: Use init container to set the rights
      initContainers:
        - name: init-disk
          image: busybox:latest
          command:
            - /bin/chown
            - 1000:1000
            - /data
          volumeMounts:
            - name: gitea
              mountPath: "/data"
      containers:
        - name: gitea
          image: "gitea/gitea:latest"
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 3000
            - containerPort: 22
          volumeMounts:
            - name: gitea
              mountPath: "/data"
            - name: gitea-config
              mountPath: /data/gitea/conf
          resources:
            requests:
              cpu: 10m
              memory: 50Mi
            limits:
              cpu: 1
              memory: 200Mi
      volumes:
        - name: gitea
          persistentVolumeClaim:
            claimName: gitea
        - name: gitea-config
          configMap:
            name: gitea-config
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: gitea-ingress
  namespace: gitea
  annotations:
    traefik.ingress.kubernetes.io/affinity: "true"
spec:
  rules:
    - host: k8s-gitea.domain.duckdns.org
      http:
        paths:
          - backend:
              serviceName: gitea
              servicePort: 443
            path: /
---
apiVersion: v1
kind: Service
metadata:
  name: gitea
  namespace: env
  labels:
    name: gitea
spec:
  ports:
    - name: gitea
      port: 443
      targetPort: 3000
    - name: gitea-ssh
      port: 22
      targetPort: 22
  selector:
    name: gitea
  type: ClusterIP
  sessionAffinity: ClientIP
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  labels:
    app: gitea
  name: gitea
  namespace: gitea
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Mi
---
apiVersion: v1
kind: Namespace
metadata:
  labels:
    name: gitea
  name: gitea

Für die Nutzung des Manifests sind zuvor noch der Host in dem Ingress angepasst werden.

Host lesen

yq r -d1 install.yaml spec.rules[0].host

Gibt den Value des Hosts aus:

k8s-gitea.domain.duckdns.org  

Host überschreiben

yq w -i -d1 install.yaml spec.rules[0].host k8s-gitea.neuedomain.duckdns.org