Da vida com o Kubernetes: como removemos o DBMS (e não apenas) dos ambientes de revisão para os estáticos

1. Os ambientes de revisão podem ser criados a partir de ramificações separadas nos repositórios Git definidos pelos desenvolvedores (as chamadas ramificações de recursos).
2. Eles podem ter instâncias DBMS separadas, processadores de filas, serviços de cache, etc. - em geral, tudo para a reprodução completa do ambiente de produção.
3. Eles permitem o desenvolvimento paralelo, acelerando significativamente o lançamento de novos recursos no aplicativo. Ao mesmo tempo, dezenas desses ambientes podem ser necessários todos os dias, e é por isso que a velocidade de sua criação é crítica.

O problema e a maneira de resolvê-lo

1. Para simplificar o trabalho dos engenheiros de controle de qualidade e de alguns outros funcionários, retire todos os bancos de dados (e vhosts correspondentes) usados ​​na revisão, em um ambiente estático separado. Pelas razões prevalecentes no projeto, essa maneira de interagir com elas foi ótima.
2. Reduza o tempo necessário para criar um ambiente de revisão. Todo o processo de sua criação a partir do zero está implícito, ou seja, incluindo clonagem de banco de dados, migrações etc.

• Ao criar um ambiente de revisão, o seguinte deve ocorrer uma vez: a criação de bancos de dados em dois DBMSs (MongoDB e PostgreSQL), a restauração de bancos de dados de um backup / modelo e a criação de vhost no RabbitMQ. Isso exigirá uma maneira conveniente de carregar dumps atuais. (Se você já tinha revisado ambientes antes, provavelmente já possui uma solução pronta para isso.)
• Após a conclusão do ambiente de revisão, você deve excluir o banco de dados e o host virtual no RabbitMQ.

• para a tarefa de inicialização, usaremos um gancho pre-installpara iniciá-lo antes de criar todos os recursos no release;
• para a tarefa de exclusão, um gancho post-delete.

Implementação prática

{{- 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. Recuperação "padrão" do backup;
2. Recuperação usando modelos .

---
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. Todas as noites, é feito um backup do banco de dados para que possa ser baixado da rede local do cluster.
2. No momento da criação do ambiente de revisão, o banco de dados é carregado e restaurado a partir do dump.
3. Quando o dump é implantado, todas as outras ações são executadas.

---
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. Ele está em um estado obsoleto .
2. De acordo com os resultados de nossos testes, não encontramos uma grande diferença no tempo de recuperação do banco de dados em comparação com o usual mongo_restore. No entanto, observo que o teste foi realizado como parte de um projeto - no seu caso, os resultados podem ser completamente diferentes.

1. A recuperação pode demorar, por exemplo, se o DBMS estiver localizado em um sistema de arquivos de rede (para casos que não estejam no ambiente de produção). Em seguida, você pode simplesmente transferir o DBMS do palco para um nó separado e usar o armazenamento local. Como isso não é produção, a velocidade de criação de uma revisão é mais crítica para nós.
2. Você pode levar cada recuperação de tarefa para um pod separado, permitindo pré-executar migrações e outros processos que dependem da operação do DBMS. Assim, economizamos tempo preenchendo-os com antecedência.
3. Às vezes, você pode reduzir o tamanho do dump excluindo dados antigos / irrelevantes - até o ponto em que é suficiente deixar apenas a estrutura do banco de dados. Obviamente, isso não ocorre nos casos em que é necessário um dump completo (por exemplo, para tarefas de teste de controle de qualidade).

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

desvantagens

1. Acontece um único ponto de falha na forma de um ambiente de palco.
2. Se um aplicativo em um ambiente de estágio for executado apenas em uma réplica, ficaremos ainda mais dependentes do host no qual esse aplicativo é executado. Consequentemente, com um aumento no número de ambientes de revisão, a carga no nó aumenta proporcionalmente sem a capacidade de equilibrar essa carga.

Conclusão

PS

• “ Dicas e truques do Kubernetes: acelerando a inicialização de grandes bancos de dados ”;
• “ Migração desobstruída do RabbitMQ para Kubernetes ”;
• " Migração desobstruída do MongoDB para o Kubernetes ";
• “ Executando equipes no processo de entrega de uma nova versão do aplicativo para o Kubernetes .”