Aus dem Leben mit Kubernetes: Wie wir DBMS (und nicht nur) aus Überprüfungsumgebungen in statische Umgebungen entfernt haben

1. Überprüfungsumgebungen können aus separaten Zweigen in Git-Repositorys erstellt werden, die von Entwicklern definiert wurden (sogenannte Feature-Zweige).
2. Sie können separate DBMS-Instanzen, Warteschlangenprozessoren, Caching-Dienste usw. haben. - im Allgemeinen alles für die vollständige Reproduktion der Produktionsumgebung.
3. Sie ermöglichen eine parallele Entwicklung und beschleunigen die Veröffentlichung neuer Funktionen in der Anwendung erheblich. Gleichzeitig können täglich Dutzende solcher Umgebungen erforderlich sein, weshalb die Geschwindigkeit ihrer Erstellung von entscheidender Bedeutung ist.

Das Problem und der Weg, es zu lösen

1. Um die Arbeit der QS-Ingenieure und einiger anderer Mitarbeiter zu vereinfachen, nehmen Sie alle in der Überprüfung verwendeten Datenbanken (und entsprechenden vhosts) in einer separaten - statischen - Umgebung heraus. Aus den im Projekt vorherrschenden Gründen war diese Art der Interaktion mit ihnen optimal.
2. Reduzieren Sie den Zeitaufwand für die Erstellung einer Überprüfungsumgebung. Der gesamte Prozess ihrer Erstellung von Grund auf ist impliziert, d.h. einschließlich Datenbankklonen, Migrationen usw.

• Beim Erstellen einer Überprüfungsumgebung sollte Folgendes einmal geschehen: Erstellen von Datenbanken in zwei DBMS (MongoDB und PostgreSQL), Wiederherstellen von Datenbanken aus einer Sicherung / Vorlage und Erstellen von vhost in RabbitMQ. Dies erfordert eine bequeme Möglichkeit zum Laden aktueller Speicherauszüge. (Wenn Sie zuvor Überprüfungsumgebungen hatten, haben Sie höchstwahrscheinlich bereits eine vorgefertigte Lösung dafür.)
• Nach Abschluss der Überprüfungsumgebung müssen Sie die Datenbank und den virtuellen Host in RabbitMQ löschen.

• Für die Initialisierungsaufgabe wird ein Hook verwendet pre-install, um sie zu starten, bevor alle Ressourcen in der Version erstellt werden.
• für die Löschaufgabe ein Hook post-delete.

Praktische Anwendung

{{- if .Values.global.review }}
---
apiVersion: batch/v1
kind: Job
metadata:
  name: db-create-postgres-database
  annotations:
    "helm.sh/hook": "pre-install"
    "helm.sh/hook-weight": "5"
spec:
  template:
    metadata:
      name: init-db-postgres
    spec:
      volumes:
      - name: postgres-scripts
        configMap:
          defaultMode: 0755
          name: postgresql-configmap
      containers:
      - name: init-postgres-database
        image: private-registry/postgres 
        command: ["/docker-entrypoint-initdb.d/01-review-load-dump.sh"]
        volumeMounts:
        - name: postgres-scripts
          mountPath: /docker-entrypoint-initdb.d/01-review-load-dump.sh
          subPath: review-load-dump.sh
        env:
{{- include "postgres_env" . | indent 8 }}
      restartPolicy: Never
{{- end }}

1. Job review-. review CI/CD Helm- (. if .Values.global.review ).
2. Job — , ConfigMap. , , . , hook-weight.
3. cURL , PostgreSQL, .
4. PostgreSQL : , shell- .

PostgreSQL

1. "Standard" -Wiederherstellung von der Sicherung;
2. Wiederherstellung mit Vorlagen .

---
apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: update-postgres-template
spec:
  schedule: "50 4 * * *"
  concurrencyPolicy: Forbid
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 3
  startingDeadlineSeconds: 600
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: Never
          imagePullSecrets:
          - name: registrysecret
          volumes:
          - name: postgres-scripts
            configMap:
              defaultMode: 0755
              name: postgresql-configmap-update-cron
          containers:
          - name: cron
            command: ["/docker-entrypoint-initdb.d/update-postgres-template.sh"]
          image: private-registry/postgres 
            volumeMounts:
            - name: postgres-scripts
              mountPath: /docker-entrypoint-initdb.d/update-postgres-template.sh
              subPath: update-postgres-template.sh
            env:
{{- include "postgres_env" . | indent 8 }}

#!/bin/bash -x

CREDENTIALS="postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@${POSTGRES_HOST}/postgres"

psql -d "${CREDENTIALS}" -w -c "REVOKE CONNECT ON DATABASE ${POSTGRES_DB_TEMPLATE} FROM public"
psql -d "${CREDENTIALS}" -w -c "SELECT pg_terminate_backend(pg_stat_activity.pid) FROM pg_stat_activity WHERE pg_stat_activity.datname = '${POSTGRES_DB_TEMPLATE}'"

curl --fail -vsL ${HOST_FORDEV}/latest_${POSTGRES_DB_STAGE}.psql -o /tmp/${POSTGRES_DB}.psql

psql -d "${CREDENTIALS}" -w -c "ALTER DATABASE ${POSTGRES_DB_TEMPLATE} WITH is_template false allow_connections true;"
psql -d "${CREDENTIALS}" -w -c "DROP DATABASE ${POSTGRES_DB_TEMPLATE};" || true
psql -d "${CREDENTIALS}" -w -c "CREATE DATABASE ${POSTGRES_DB_TEMPLATE};" || true
pg_restore -U ${POSTGRES_USER} -h ${POSTGRES_HOST} -w -j 4 -d ${POSTGRES_DB_TEMPLATE} /tmp/${POSTGRES_DB}.psql

psql -d "${CREDENTIALS}" -w -c "ALTER DATABASE ${POSTGRES_DB_TEMPLATE} WITH is_template true allow_connections false;"

rm -v /tmp/${POSTGRES_DB}.psql

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: postgresql-configmap
  annotations:
    "helm.sh/hook": "pre-install"
    "helm.sh/hook-weight": "1"
    "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded
data:
  review-load-dump.sh: |
    #!/bin/bash -x
    
 
 
    CREDENTIALS="postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@${POSTGRES_HOST}/postgres"

    if [ "$( psql -d "${CREDENTIALS}" -tAc "SELECT CASE WHEN EXISTS (SELECT * FROM pg_stat_activity WHERE datname = '${POSTGRES_DB}' LIMIT 1) THEN 1 ELSE 0 END;" )" = '1' ]
      then
          echo "Open connections has been found in ${POSTGRES_DB} database, will drop them"
          psql -d "${CREDENTIALS}" -c "SELECT pg_terminate_backend(pg_stat_activity.pid) FROM pg_stat_activity WHERE pg_stat_activity.datname = '${POSTGRES_DB}' -- AND pid <> pg_backend_pid();"
      else
          echo "No open connections has been found ${POSTGRES_DB} database, skipping this stage"
    fi

    psql -d "${CREDENTIALS}" -c "DROP DATABASE ${POSTGRES_DB}"

    if [ "$( psql -d "${CREDENTIALS}" -tAc "SELECT 1 FROM pg_database WHERE datname='${POSTGRES_DB}'" )" = '1' ]
      then
          echo "Database ${POSTGRES_DB} still exists, delete review job failed"
          exit 1
      else
          echo "Database ${POSTGRES_DB} does not exist, skipping"
    fi


    psql ${CREDENTIALS} -d postgres -c 'CREATE DATABASE ${POSTGRES_DB} TEMPLATE "loot-stage-copy"'

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: postgresql-configmap-on-delete
  annotations:
    "helm.sh/hook": "post-delete, pre-delete"
    "helm.sh/hook-weight": "1"
    "helm.sh/hook-delete-policy": before-hook-creation
data:
  review-delete-db.sh: |
    #!/bin/bash -e

    CREDENTIALS="postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@${POSTGRES_HOST}/postgres"

    psql -d "${CREDENTIALS}" -w postgres -c "DROP DATABASE ${POSTGRES_DB}"

1. Jede Nacht wird eine Datenbanksicherung durchgeführt, damit diese aus dem lokalen Netzwerk des Clusters heruntergeladen werden kann.
2. Zum Zeitpunkt der Erstellung der Überprüfungsumgebung wird die Datenbank geladen und aus dem Speicherauszug wiederhergestellt.
3. Wenn der Speicherauszug bereitgestellt wird, werden alle anderen Aktionen ausgeführt.

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: postgresql-configmap
  annotations:
    "helm.sh/hook": "pre-install"
    "helm.sh/hook-weight": "1"
    "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded
data:
  review-load-dump.sh: |
    #!/bin/bash -x

    CREDENTIALS="postgresql://${POSTGRES_USER}:${POSTGRES_PASSWORD}@${POSTGRES_HOST}/postgres"
    psql -d "${CREDENTIALS}" -w -c "DROP DATABASE ${POSTGRES_DB}" || true
    psql -d "${CREDENTIALS}" -w -c "CREATE DATABASE ${POSTGRES_DB}"

    curl --fail -vsL ${HOST_FORDEV}/latest_${POSTGRES_DB_STAGE}.psql -o /tmp/${POSTGRES_DB}.psql

    psql psql -d "${CREDENTIALS}" -w -c "CREATE EXTENSION ip4r;"
    pg_restore -U ${POSTGRES_USER} -h ${POSTGRES_HOST} -w -j 4 -d ${POSTGRES_DB} /tmp/${POSTGRES_DB}.psql
    rm -v /tmp/${POSTGRES_DB}.psql

Mongodb

1. Er ist in einem veralteten Zustand .
2. Nach den Ergebnissen unserer Tests haben wir keinen großen Unterschied in der Zeit der Datenbankwiederherstellung im Vergleich zur üblichen festgestellt mongo_restore. Ich stelle jedoch fest, dass die Tests als Teil eines Projekts durchgeführt wurden - in Ihrem Fall können die Ergebnisse völlig unterschiedlich sein.

1. Die Wiederherstellung kann beispielsweise lange dauern, wenn sich Ihr DBMS in einem Netzwerkdateisystem befindet (in Fällen ohne Produktionsumgebung). Anschließend können Sie das DBMS einfach von der Bühne auf einen separaten Knoten übertragen und den lokalen Speicher verwenden. Da dies keine Produktion ist, ist die Geschwindigkeit der Erstellung einer Überprüfung für uns kritischer.
2. Sie können jede Jobwiederherstellung in einem separaten Pod speichern, sodass Sie Migrationen und andere Prozesse, die vom Betrieb des DBMS abhängen, vorab ausführen können. So sparen wir Zeit, indem wir sie im Voraus ausfüllen.
3. Manchmal können Sie die Größe des Speicherauszugs reduzieren, indem Sie alte / irrelevante Daten löschen - soweit es ausreicht, nur die Datenbankstruktur zu belassen. Dies gilt natürlich nicht für Fälle, in denen ein vollständiger Speicherauszug erforderlich ist (z. B. für QS-Testaufgaben).

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: mongodb-scripts-on-delete
  annotations:
    "helm.sh/hook": "post-delete, pre-delete"
    "helm.sh/hook-weight": "1"
    "helm.sh/hook-delete-policy": before-hook-creation
data:
  review-delete-db.sh: |
    #!/bin/bash -x

    mongo ${MONGODB_NAME} --eval "db.dropDatabase()" --host ${MONGODB_REPLICASET}/${MONGODB_HOST}
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: mongodb-scripts
  annotations:
    "helm.sh/hook": "pre-install"
    "helm.sh/hook-weight": "1"
    "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded
data:
  review-load-dump.sh: |
    #!/bin/bash -x

    curl --fail -vsL ${HOST_FORDEV}/latest_${MONGODB_NAME_STAGE}.gz -o /tmp/${MONGODB_NAME}.gz

    mongo ${MONGODB_NAME} --eval "db.dropDatabase()" --host ${MONGODB_REPLICASET}/${MONGODB_HOST}
    mongorestore --gzip --nsFrom "${MONGODB_NAME_STAGE}.*" --nsTo "${MONGODB_NAME}.*" --archive=/tmp/${MONGODB_NAME}.gz --host ${MONGODB_REPLICASET}/${MONGODB_HOST}

the --db and --collection args should only be used when restoring from a BSON file. Other uses are deprecated and will not exist in the future; use --nsInclude instead

Rabbitmq

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: rabbitmq-configmap
  annotations:
    "helm.sh/hook": "pre-install"
    "helm.sh/hook-weight": "1"
    "helm.sh/hook-delete-policy": before-hook-creation,hook-succeeded
data:
  rabbitmq-setup-vhost.sh: |
    #!/bin/bash -x

    /usr/local/bin/rabbitmqadmin -H ${RABBITMQ_HOST} -u ${RABBITMQ_USER} -p ${RABBITMQ_PASSWORD} declare vhost name=${RABBITMQ_VHOST}
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: rabbitmq-configmap-on-delete
  annotations:
    "helm.sh/hook": "post-delete, pre-delete"
    "helm.sh/hook-weight": "1"
    "helm.sh/hook-delete-policy": before-hook-creation
data:
  rabbitmq-delete-vhost.sh: |
    #!/bin/bash -x

    /usr/local/bin/rabbitmqadmin -H ${RABBITMQ_HOST} -u ${RABBITMQ_USER} -p ${RABBITMQ_PASSWORD} delete vhost name=${RABBITMQ_VHOST}

Nachteile

1. Es stellt sich heraus, dass es sich um einen einzelnen Fehlerpunkt in Form einer Bühnenumgebung handelt.
2. Wenn eine Anwendung in einer Stage-Umgebung nur in einem Replikat ausgeführt wird, sind wir noch stärker von dem Host abhängig, auf dem diese Anwendung ausgeführt wird. Dementsprechend nimmt mit zunehmender Anzahl von Überprüfungsumgebungen die Last auf dem Knoten proportional zu, ohne dass diese Last ausgeglichen werden kann.

Fazit

PS

• " Tipps und Tricks von Kubernetes: Beschleunigen des Bootstraps großer Datenbanken ";
• " Ungehinderte RabbitMQ-Migration zu Kubernetes ";
• " Ungehinderte MongoDB-Migration nach Kubernetes ";
• " Führen von Teams, die gerade eine neue Anwendungsversion für Kubernetes bereitstellen ."