Suche
  • Robin Nepomuk Mai

Wordpress auf Kubernetes in 15 Minuten installieren

”Wie schnell kann man ein skalierbares Wordpress System aufsetzen?" fragten uns die YouTuber von Shishawg. Die Social Media Experten erleben exponentielles Wachstum und brauchen daher eine Hostinglösung die ohne Probleme mitwachsen kann.


Unsere Antwort kam wie aus der Pistole geschossen "auf unserer Kubernetes Plattform 15 Minuten!". Top, die Wette gilt!


Vorraussetzungen:

  • Kubernetes 1.12+

  • Helm 3.0+

  • Persistent Volume Support

  • Reverse Proxy ist bereits konfiguriert

  • Volumes können dynamisch provisioniert werden


Warum Kubernetes und Helm?

Kubernetes ist ein auf Container Technologie basierendes Clustersystem. Durch bereits fertig paketierte Container, die lediglich konfiguriert werden müssen, ist die Konfiguration effizient und die Skalierung sehr einfach. Bei großen Lastanstiegen ist es ohne weiteres möglich weitere Container binnen Sekunden zu starten um die Last zu verteilen. Kubernetes besitzt unzählige Abstraktionsschichten über die man nahezu jeden Layer eines Rechenzentrums konfigurieren kann, allerdings sind diese Strukturen oft sehr ähnlich.

Helm bietet uns hier standardisierte Templates, sogenannte Charts, zu nutzen.

Dadurch sind wir nicht mehr in der Not alles von Hand anzulegen, sondern können uns darauf konzentrieren nur die für uns notwendigen und vom Standard abweichenden Parameter, wie zum Beispiel Passwörter, Hostname, etc., anzupassen. Alle anderen Einstellungen des Charts werden übernommen.


Für unser Deployment nutzen wir die das Wordpress Helm Chart von Bitnami.


Values.yaml vorbereiten


# Konfiguration des Docker Images
image:
  registry: docker.io
  repository: bitnami/wordpress
  tag: 5.3.2-debian-10-r32
  pullPolicy: IfNotPresent
  debug: false

# Initiale Wordpress Einstellungen
wordpressUsername: shishawg
wordpressPassword: "supersecurepassword;)"
wordpressEmail: info@shishawg
wordpressFirstName: Shisha
wordpressLastName: WG
wordpressBlogName: ShishaWG
wordpressTablePrefix: wp_
wordpressScheme: http
wordpressSkipInstall: false
allowEmptyPassword: true


# Mit welcher Strategie sollen Container innerhalb eines Upgrades ausgetauscht werden?
updateStrategy:
  type: RollingUpdate

# Wir möchten eine Wordpress Instanz starten. Bei Lastszenarien kann hier der Count erhöht werden, um automatische weitere Container laufen zu lassen
replicaCount: 1

# Mit Requests werden Ressourcen, auch wenn sie nicht gebraucht werden, fest reserviert. Nützlich um overcommitment der Cluster Ressourcen zu verhindern.
resources:
  limits: {}
  requests:
    memory: 512Mi
    cpu: 300m

# Unter welchem User und mit welchen Rechten soll der Container ausgeführt werden?
securityContext:
  enabled: true
  fsGroup: 1001
  runAsUser: 1001

# Der LivenessProbe überprüf den Zustand des Containers. Ist dieser für einen längeren Zeitraum unhealthy wird er neu gestartet.
healthcheckHttps: true
livenessProbe:
  enabled: true
  initialDelaySeconds: 120
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 6
  successThreshold: 1
# ReadinessProbes bestimmen ab wann ein Container bereit ist Traffic zu empfangen. Wird zum Beispiel ein neue Version deployed, ist aber unhealthy, wird der Traffic weiterhin auf die alte, aber funktionierende, Version geleitet.
readinessProbe:
  enabled: true
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 6
  successThreshold: 1

# Ein Kubernetes Service ist für die In-Cluster Kommunikation zuständig und expose die Ports des Containers.
service:
  type: ClusterIP
  port: 80
  httpsPort: 443
  httpsTargetPort: https
  metricsPort: 9117
  nodePorts:
    http: ""
    https: ""
    metrics: ""

# Ingress Controller sind für das externe Routing zuständig. CertManager ist deaktiviert. Der bei uns eingesetzt Revers Proxy Traefik übernimmt die Zertifikatsverwaltung.
Besitzt ein Ingress Controller die Annotation "traefik" wird automatisch mit einer http Challenge ein Zertifikat für den angegebenen Hostname bei Let's Encrypt angefragt.
ingress:
  enabled: true
  certManager: false
  hostname: shishawg.de
  annotations:
    kubernetes.io/ingress.class: traefik

# Der Storage des Wordpress Containers soll in einem kleinen Volume persistiert werden.
persistence:
  enabled: true
  accessMode: ReadWriteOnce
  size: 10Gi

# Als Abhängigkeit hat Wordpress eine MySQL/MariaDB Datenbank. Die kann recht einfach mitkonfiguriert werden. 
mariadb:
  enabled: true
  replication:
    enabled: false
  db:
    name: wordpress
    user: mariadb
    password: "supersecurepassword;)"
  master:
    persistence:
      storageClass: do-block-storage
      enabled: true
    accessModes:
      - ReadWriteOnce
    size: 8Gi

# Zu guter Letzt teilen wir Wordpress mit wie seine Datenbank erreichbar ist.
externalDatabase:
  host: mariadb
  user: mariadb
  password: ""supersecurepassword;)"
  database: wordpress
  port: 3306



Helm Deployment

Wir nutzen das Helm Chart Repository von Bitnami. Dieses müssen wir zuerst hinzufügen.

helm repo add bitnami https://charts.bitnami.com/bitnami

Danach kann das Chart, das mit unserer values.yaml konfiguriert wird, deployed werden.

helm install -n shishawg wordpress bitnami/wordpress -f wordpress.yaml

Fertig

Hat alles geklappt ist der Blog nun erreichbar. In unter 15 Minuten natürlich ;)

8 Ansichten

©2020 by Nepomuk Software UG & Co. KG 

Made with ☕️ in Büdingen

Impressum Datenschutzerklärung

Alle Preise für Geschäftskunden zzgl. 19 % MWST.