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 eines Containerimage

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 lazydocker. 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

Trivy

Trivy ist ein kleines in GO geschriebenes Programm. Die Installation unter Manjaro oder Arch erfolgt mir yay und ist schnell erledigt.

yay -S --noconfirm trivy

Was macht Trivy?

Trivy ist ein Securityscanner und untersucht Docker Images auf mögliche CVEs und gibt das Ergebnis in tabellarischer Form auf der Konsole aus.

Der Erste Check

Der Erster Check eines Images dauer in der Regel etwas länger, da die Datenbank zunächst aktualisiert werden muss.

2020-09-03T08:16:52.070+0200    WARN    You should avoid using the :latest tag as it is cached. You need to specify '--clear-cache' option when :latest image is changed
2020-09-03T08:16:52.088+0200    INFO    Need to update DB
2020-09-03T08:16:52.088+0200    INFO    Downloading DB...
18.25 MiB / 18.25 MiB [-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------] 100.00% 2.38 MiB p/s 8s

Auch ein folgender Scan sollte schneller ablaufen, da Trivy die Scanergebnisse einzelner Layer in dem Docker Image im Cache zwischenspeichert.