De la vie avec Kubernetes: comment nous avons supprimé le SGBD (et pas seulement) des environnements de révision aux statiques

1. Les environnements de révision peuvent être créés à partir de branches distinctes dans des référentiels Git définis par les développeurs (les soi-disant branches de fonctionnalités).
2. Ils peuvent avoir des instances SGBD distinctes, des processeurs de file d'attente, des services de mise en cache, etc. - en général, tout pour la reproduction intégrale de l'environnement de production.
3. Ils permettent un développement parallèle, accélérant considérablement la sortie de nouvelles fonctionnalités dans l'application. Dans le même temps, des dizaines de ces environnements peuvent être nécessaires chaque jour, c'est pourquoi la vitesse de leur création est critique.

Le problème et la façon de le résoudre

1. Pour simplifier le travail des ingénieurs QA et de certains autres employés, supprimez toutes les bases de données (et les hôtes correspondants) utilisées dans la revue, dans un environnement séparé - statique -. Pour des raisons qui prévalaient dans le projet, cette façon d'interagir avec eux était optimale.
2. Réduisez le temps de création de l'environnement de révision. Tout le processus de leur création à partir de zéro est impliqué, c'est-à-dire y compris le clonage de bases de données, les migrations, etc.

• Lors de la création d'un environnement de révision, les opérations suivantes doivent se produire une fois: la création de bases de données dans deux SGBD (MongoDB et PostgreSQL), la restauration de bases de données à partir d'une sauvegarde / d'un modèle et la création de vhost dans RabbitMQ. Cela nécessitera un moyen pratique de charger les décharges de courant. (Si vous aviez déjà examiné des environnements, vous avez probablement déjà une solution prête à l'emploi pour cela.)
• Une fois l'environnement d'examen terminé, vous devez supprimer la base de données et l'hôte virtuel dans RabbitMQ.

• pour la tâche d'initialisation, nous utiliserons un hook pre-installpour le lancer avant de créer toutes les ressources dans la version;
• pour la tâche de suppression, un crochet post-delete.

Mise en œuvre pratique

{{- 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. Récupération "standard" à partir d'une sauvegarde;
2. Récupération à l'aide de modèles .

---
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. Chaque nuit, une sauvegarde de la base de données est effectuée afin de pouvoir la télécharger depuis le réseau local du cluster.
2. Au moment de la création de l'environnement de révision, la base de données est chargée et restaurée à partir du vidage.
3. Lorsque le vidage est déployé, toutes les autres actions sont effectuées.

---
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. Il est dans un état déprécié .
2. Selon les résultats de nos tests, nous n'avons pas trouvé de grande différence dans le temps de récupération de la base de données par rapport à l'habituel mongo_restore. Cependant, je note que les tests ont été effectués dans le cadre d'un projet - dans votre cas, les résultats peuvent être complètement différents.

1. La récupération peut prendre du temps, par exemple, si votre SGBD se trouve sur un système de fichiers réseau (pour les cas qui ne sont pas avec un environnement de production). Ensuite, vous pouvez simplement transférer le SGBD de l'étape vers un nœud distinct et utiliser le stockage local. Comme il ne s'agit pas de production, la vitesse de création d'une revue est plus critique pour nous.
2. Vous pouvez prendre chaque récupération de travail dans un module distinct, ce qui vous permet de pré-exécuter les migrations et d'autres processus qui dépendent du fonctionnement du SGBD. Nous gagnons donc du temps en les complétant à l'avance.
3. Parfois, vous pouvez réduire la taille du vidage en supprimant les données anciennes / non pertinentes - au point qu'il suffit de ne laisser que la structure de la base de données. Bien sûr, ce n'est pas pour les cas où un vidage complet est requis (par exemple, pour les tâches de test d'assurance qualité).

---
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}

désavantages

1. Il se révèle un seul point de défaillance sous la forme d'un environnement scénique.
2. Si une application dans un environnement de scène ne s'exécute que dans une seule réplique, nous devenons encore plus dépendants de l'hôte sur lequel cette application s'exécute. En conséquence, avec une augmentation du nombre d'environnements d'examen, la charge sur le nœud augmente proportionnellement sans la capacité d'équilibrer cette charge.

Conclusion

PS

• « Trucs et astuces de Kubernetes: accélérer le bootstrap des grandes bases de données »;
• « Migration sans obstacle de RabbitMQ vers Kubernetes »;
• " Migration non obstruée de MongoDB vers Kubernetes ";
• « Diriger des équipes en train de fournir une nouvelle version d'application à Kubernetes .»