В этой главе мы развернём базу данных, реализуем в приложении работу с БД и настроим автоматическое выполнение миграций и инициализации БД.

Приложение в этой главе не предназначено для использования в production без доработки. Готовое к работе в production приложение мы получим в конце руководства.

Подготовка окружения

Подготовьте рабочее окружение согласно c инструкциями главы “Подготовка окружения”, если это ещё не сделано.

Рабочее окружение работало, но перестало? Инструкции из этой главы не работают? Может помочь:

Работает ли Docker?

Запустим приложение Docker Desktop. Приложению понадобится некоторое время для того, чтобы запустить Docker. Если никаких ошибок в процессе запуска не возникло, то проверим, что Docker запущен и корректно настроен:

docker run hello-world

Результат успешного выполнения команды:

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
b8dfde127a29: Pull complete
Digest: sha256:9f6ad537c5132bcce57f7a0a20e317228d382c3cd61edae14650eec68b2b345c
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

При возникновении проблем обратитесь к документации Docker для их устранения.

Запустим приложение Docker Desktop. Приложению понадобится некоторое время для того, чтобы запустить Docker. Если никаких ошибок в процессе запуска не возникло, то проверим, что Docker запущен и корректно настроен:

docker run hello-world

Результат успешного выполнения команды:

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
b8dfde127a29: Pull complete
Digest: sha256:9f6ad537c5132bcce57f7a0a20e317228d382c3cd61edae14650eec68b2b345c
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

При возникновении проблем обратитесь к документации Docker для их устранения.

Запустим Docker:

sudo systemctl restart docker

Убедимся, что Docker запустился:

sudo systemctl status docker

Результат выполнения команды, если Docker успешно запущен:

● docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2021-06-24 13:05:17 MSK; 13s ago
TriggeredBy: ● docker.socket
       Docs: https://docs.docker.com
   Main PID: 2013888 (dockerd)
      Tasks: 36
     Memory: 100.3M
     CGroup: /system.slice/docker.service
             └─2013888 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

dockerd[2013888]: time="2021-06-24T13:05:16.936197880+03:00" level=warning msg="Your kernel does not support CPU realtime scheduler"
dockerd[2013888]: time="2021-06-24T13:05:16.936219851+03:00" level=warning msg="Your kernel does not support cgroup blkio weight"
dockerd[2013888]: time="2021-06-24T13:05:16.936224976+03:00" level=warning msg="Your kernel does not support cgroup blkio weight_device"
dockerd[2013888]: time="2021-06-24T13:05:16.936311001+03:00" level=info msg="Loading containers: start."
dockerd[2013888]: time="2021-06-24T13:05:17.119938367+03:00" level=info msg="Loading containers: done."
dockerd[2013888]: time="2021-06-24T13:05:17.134054120+03:00" level=info msg="Daemon has completed initialization"
systemd[1]: Started Docker Application Container Engine.
dockerd[2013888]: time="2021-06-24T13:05:17.148493957+03:00" level=info msg="API listen on /run/docker.sock"

Теперь проверим, что Docker доступен и корректно настроен:

docker run hello-world

Результат успешного выполнения команды:

Unable to find image 'hello-world:latest' locally
latest: Pulling from library/hello-world
b8dfde127a29: Pull complete
Digest: sha256:9f6ad537c5132bcce57f7a0a20e317228d382c3cd61edae14650eec68b2b345c
Status: Downloaded newer image for hello-world:latest

Hello from Docker!
This message shows that your installation appears to be working correctly.

При возникновении проблем обратитесь к документации Docker для их устранения.

Перезагружали компьютер после подготовки окружения?

Запустим кластер minikube, уже настроенный в начале главы “Подготовка окружения”:

minikube start

Выставим Namespace по умолчанию, чтобы не указывать его при каждом вызове kubectl:

kubectl config set-context minikube --namespace=werf-guide-app

Результат успешного выполнения команды:

😄  minikube v1.20.0 on Ubuntu 20.04
✨  Using the docker driver based on existing profile
👍  Starting control plane node minikube in cluster minikube
🚜  Pulling base image ...
🎉  minikube 1.21.0 is available! Download it: https://github.com/kubernetes/minikube/releases/tag/v1.21.0
💡  To disable this notice, run: 'minikube config set WantUpdateNotification false'

🔄  Restarting existing docker container for "minikube" ...
🐳  Preparing Kubernetes v1.20.2 on Docker 20.10.6 ...
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/google_containers/kube-registry-proxy:0.4
    ▪ Using image k8s.gcr.io/ingress-nginx/controller:v0.44.0
    ▪ Using image registry:2.7.1
    ▪ Using image docker.io/jettech/kube-webhook-certgen:v1.5.1
    ▪ Using image docker.io/jettech/kube-webhook-certgen:v1.5.1
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🔎  Verifying registry addon...
🔎  Verifying ingress addon...
🌟  Enabled addons: storage-provisioner, registry, default-storageclass, ingress
🏄  Done! kubectl is now configured to use "minikube" cluster and "werf-guide-app" namespace by default

Убедитесь, что вывод команды содержит строку:

Restarting existing docker container for "minikube"

Если её нет, значит был создан новый кластер minikube вместо использования старого. В таком случае повторите установку рабочего окружения с minikube с самого начала.

Теперь запустите команду в фоновом PowerShell-терминале и не закрывайте его:

minikube tunnel --cleanup=true

Запустим кластер minikube, уже настроенный в начале главы “Подготовка окружения”:

minikube start --namespace werf-guide-app

Выставим Namespace по умолчанию, чтобы не указывать его при каждом вызове kubectl:

kubectl config set-context minikube --namespace=werf-guide-app

Результат успешного выполнения команды:

😄  minikube v1.20.0 on Ubuntu 20.04
✨  Using the docker driver based on existing profile
👍  Starting control plane node minikube in cluster minikube
🚜  Pulling base image ...
🎉  minikube 1.21.0 is available! Download it: https://github.com/kubernetes/minikube/releases/tag/v1.21.0
💡  To disable this notice, run: 'minikube config set WantUpdateNotification false'

🔄  Restarting existing docker container for "minikube" ...
🐳  Preparing Kubernetes v1.20.2 on Docker 20.10.6 ...
🔎  Verifying Kubernetes components...
    ▪ Using image gcr.io/google_containers/kube-registry-proxy:0.4
    ▪ Using image k8s.gcr.io/ingress-nginx/controller:v0.44.0
    ▪ Using image registry:2.7.1
    ▪ Using image docker.io/jettech/kube-webhook-certgen:v1.5.1
    ▪ Using image docker.io/jettech/kube-webhook-certgen:v1.5.1
    ▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🔎  Verifying registry addon...
🔎  Verifying ingress addon...
🌟  Enabled addons: storage-provisioner, registry, default-storageclass, ingress
🏄  Done! kubectl is now configured to use "minikube" cluster and "werf-guide-app" namespace by default

Убедитесь, что вывод команды содержит строку:

Restarting existing docker container for "minikube"

Если её нет, значит был создан новый кластер minikube вместо использования старого. В таком случае повторите установку рабочего окружения с minikube с самого начала.

Случайно удаляли Namespace приложения?

Если вы непреднамеренно удалили Namespace приложения, то необходимо выполнить следующие команды, чтобы продолжить прохождение руководства:

kubectl create namespace werf-guide-app
kubectl create secret docker-registry registrysecret \
  --docker-server='https://index.docker.io/v1/' \
  --docker-username='<ИМЯ ПОЛЬЗОВАТЕЛЯ DOCKER HUB>' \
  --docker-password='<ПАРОЛЬ ПОЛЬЗОВАТЕЛЯ DOCKER HUB>'

Результат успешного выполнения команды:

namespace/werf-guide-app created
secret/registrysecret created
Ничего не помогло, окружение или инструкции по-прежнему не работают?

Если ничего не помогло, то пройдите главу “Подготовка окружения” с начала, подготовив новое окружение с нуля. Если и это не помогло, тогда, пожалуйста, расскажите о своей проблеме в нашем Telegram или оставьте Issue на GitHub, и мы обязательно вам поможем.

Подготовка репозитория

Обновим существующий репозиторий с приложением:

Выполним следующий набор команд в PowerShell:

cd ~/werf-guide/app

# Чтобы увидеть, какие изменения мы собрались вносить далее в этой главе, заменим все файлы приложения
# в репозитории новыми, уже измененными файлами приложения, которые содержат описанные далее изменения.
git rm -r .
cp -Recurse -Force ~/werf-guide/guides/examples/django/040_db/* .
git add .
git commit -m WIP
Посмотреть, какие именно изменения мы произведём
# Показать, какие файлы мы собираемся изменить.
git show --stat
# Показать изменения.
git show

Выполним следующий набор команд в Bash:

cd ~/werf-guide/app

# Чтобы увидеть, какие изменения мы собрались вносить далее в этой главе, заменим все файлы приложения
# в репозитории новыми, уже измененными файлами приложения, которые содержат описанные далее изменения.
git rm -r .
cp -rf ~/werf-guide/guides/examples/django/040_db/. .
git add .
git commit -m WIP
Посмотреть, какие именно изменения мы произведём
# Показать, какие файлы мы собираемся изменить.
git show --stat
# Показать изменения.
git show

Не работает? Попробуйте инструкции на вкладке “Начинаю проходить руководство с этой главы” выше.

Подготовим новый репозиторий с приложением:

Выполним следующий набор команд в PowerShell:

# Склонируем репозиторий с примерами в ~/werf-guide/guides, если он ещё не был склонирован.
if (-not (Test-Path ~/werf-guide/guides)) {
  git clone https://github.com/werf/website $env:HOMEPATH/werf-guide/guides
}

# Скопируем файлы приложения (пока без изменений) в ~/werf-guide/app.
rm -Recurse -Force ~/werf-guide/app
cp -Recurse -Force ~/werf-guide/guides/examples/django/030_assets ~/werf-guide/app

# Сделаем из директории ~/werf-guide/app git-репозиторий.
cd ~/werf-guide/app
git init
git add .
git commit -m initial

# Чтобы увидеть, какие изменения мы собрались вносить далее в этой главе, заменим все файлы приложения
# в репозитории новыми, уже измененными файлами приложения, которые содержат описанные далее изменения.
git rm -r .
cp -Recurse -Force ~/werf-guide/guides/examples/django/040_db/* .
git add .
git commit -m WIP
Посмотреть, какие именно изменения мы произведём
# Показать, какие файлы мы собираемся изменить.
git show --stat
# Показать изменения.
git show

Выполним следующий набор команд в Bash:

# Склонируем репозиторий с примерами в ~/werf-guide/guides, если он ещё не был склонирован.
test -e ~/werf-guide/guides || git clone https://github.com/werf/website ~/werf-guide/guides

# Скопируем файлы приложения (пока без изменений) в ~/werf-guide/app.
rm -rf ~/werf-guide/app
cp -rf ~/werf-guide/guides/examples/django/030_assets ~/werf-guide/app

# Сделаем из директории ~/werf-guide/app git-репозиторий.
cd ~/werf-guide/app
git init
git add .
git commit -m initial

# Чтобы увидеть, какие изменения мы собрались вносить далее в этой главе, заменим все файлы приложения
# в репозитории новыми, уже измененными файлами приложения, которые содержат описанные далее изменения.
git rm -r .
cp -rf ~/werf-guide/guides/examples/django/040_db/. .
git add .
git commit -m WIP
Посмотреть, какие именно изменения мы произведём
# Показать, какие файлы мы собираемся изменить.
git show --stat
# Показать изменения.
git show

Подготовка stateful-приложения

Сейчас наше приложение не использует БД и не хранит никаких данных (т.е. stateless). Поэтому, чтобы сделать его stateful, нам в первую очередь нужно подготовить приложение к работе с MySQL, которую мы будем использовать для хранения состояния.

Основные изменения, сделанные в нашем приложении:

  • Установлены зависимости для работы с MySQL.
  • Добавлена конфигурация доступа к БД.
  • Добавлена модель БД.
  • Добавлены маршруты, использующие новую модель.

Добавление endpoints /remember и /say в приложение

Добавим два новых endpoints, один из которых будет сохранять данные в БД (/remember), а второй — доставать их из БД (/say).

Наши новые контроллер и модель:

from django.http import HttpResponse, HttpResponseBadRequest
from .models import Talkers


def remember(request):
    req = request.GET

    if "answer" not in req:
        return HttpResponseBadRequest("You forgot the answer :(\n")

    if "name" not in req:
        return HttpResponseBadRequest("You forgot the name :(\n")

    data = Talkers()
    data.answer = req["answer"]
    data.name = req["name"]
    data.save()

    return HttpResponse("Got it.\n")


def say(request):
    obj = Talkers.objects.last()

    if obj is None:
        return HttpResponse("I have nothing to say.\n")

    return HttpResponse("{answer}, {name}!\n".format(answer=getattr(obj, "answer"), name=getattr(obj, "name")))
from django.http import HttpResponse, HttpResponseBadRequest from .models import Talkers def remember(request): req = request.GET if "answer" not in req: return HttpResponseBadRequest("You forgot the answer :(\n") if "name" not in req: return HttpResponseBadRequest("You forgot the name :(\n") data = Talkers() data.answer = req["answer"] data.name = req["name"] data.save() return HttpResponse("Got it.\n") def say(request): obj = Talkers.objects.last() if obj is None: return HttpResponse("I have nothing to say.\n") return HttpResponse("{answer}, {name}!\n".format(answer=getattr(obj, "answer"), name=getattr(obj, "name")))
from django.db import models


class Talkers(models.Model):
    answer = models.TextField()
    name = models.TextField()

    def __str__(self):
        return self.name
from django.db import models class Talkers(models.Model): answer = models.TextField() name = models.TextField() def __str__(self): return self.name

Добавим новые пути в список маршрутов:

...
path('remember', talkers_view.remember, name='remember'),
path('say', talkers_view.say, name='say'),
... path('remember', talkers_view.remember, name='remember'), path('say', talkers_view.say, name='say'),

Новые endpoints — /remember и /say — готовы к работе.

Развертывание и подключение MySQL

В реальной инфраструктуре базы данных могут быть развернуты как в Kubernetes, так и вне его. Вне Kubernetes базы данных могут развертываться и обслуживаться самостоятельно, либо могут использоваться managed-решения вроде Amazon RDS. Для нашего приложения, в целях демонстрации, мы развернём БД MySQL в Kubernetes с помощью простого StatefulSet:

---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql"
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        ports:
          - containerPort: 3306
        env:
          - name: MYSQL_DATABASE
            value: django
          - name: MYSQL_USER
            value: django
          - name: MYSQL_PASSWORD
            value: django
          - name: MYSQL_ROOT_PASSWORD
            value: django
  volumeClaimTemplates:
  - metadata:
      name: mysql-data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: "100Mi"
---
apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  selector:
    app: mysql
  ports:
  - name: mysql
    port: 3306
--- apiVersion: apps/v1 kind: StatefulSet metadata: name: mysql spec: serviceName: "mysql" selector: matchLabels: app: mysql template: metadata: labels: app: mysql spec: containers: - name: mysql image: mysql:5.7 ports: - containerPort: 3306 env: - name: MYSQL_DATABASE value: django - name: MYSQL_USER value: django - name: MYSQL_PASSWORD value: django - name: MYSQL_ROOT_PASSWORD value: django volumeClaimTemplates: - metadata: name: mysql-data spec: accessModes: ["ReadWriteOnce"] resources: requests: storage: "100Mi" --- apiVersion: v1 kind: Service metadata: name: mysql spec: selector: app: mysql ports: - name: mysql port: 3306

Вы также можете использовать базы данных, развернутые любым другим способом. В таком случае вам не нужно развертывать вышеупомянутый StatefulSet, все же дальнейшие инструкции остаются без изменений.

Теперь настроим приложение на работу с новой БД:

...
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'django',
        'USER': 'django',
        'PASSWORD': 'django',
        'HOST': 'mysql',
    }
}
... DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'django', 'USER': 'django', 'PASSWORD': 'django', 'HOST': 'mysql', } }

Инициализация и миграции БД

Есть несколько способов выполнять инициализацию и миграции БД при развертывании приложений в Kubernetes. Мы рассмотрим один простой, но хорошо работающий метод. В нем миграции БД (и, если требуется, инициализация) будут выполняться отдельной Job одновременно с развертыванием приложения и самой БД.

Чтобы выдержать очередность развертывания ресурсов, мы:

  1. Требуем от Job, которая выполнит инициализацию/миграции БД, дождаться доступности базы данных перед началом работы.
  2. Требуем от приложений перед тем, как запуститься, дождаться доступности базы данных и подготовки базы данных и выполнения миграций.

Таким образом, при деплое все K8s-ресурсы будут созданы одновременно, но начнут работу в следующем порядке:

  1. Запустится БД.
  2. Затем выполнится Job с инициализацией/миграциями БД.
  3. Затем запустятся приложения.

Реализуем это, добавив Job для выполнения миграций/инициализации базы данных:

apiVersion: batch/v1
kind: Job
metadata:
  # Версия Helm-релиза в имени Job заставит Job каждый раз пересоздаваться.
  # Так мы сможем обойти то, что Job неизменяема.
  name: "setup-and-migrate-db-rev{{ .Release.Revision }}"
spec:
  backoffLimit: 0
  template:
    spec:
      restartPolicy: Never
      initContainers:
      - name: waiting-mysql
        image: alpine:3.6
        command: [ '/bin/sh', '-c', 'while ! nc -z mysql 3306; do sleep 1; done' ]
      containers:
      - name: setup-and-migrate-db
        image: {{ .Values.werf.image.backend }}
        command:
        - python3
        - manage.py
        - migrate
apiVersion: batch/v1 kind: Job metadata: # Версия Helm-релиза в имени Job заставит Job каждый раз пересоздаваться. # Так мы сможем обойти то, что Job неизменяема. name: "setup-and-migrate-db-rev{{ .Release.Revision }}" spec: backoffLimit: 0 template: spec: restartPolicy: Never initContainers: - name: waiting-mysql image: alpine:3.6 command: [ '/bin/sh', '-c', 'while ! nc -z mysql 3306; do sleep 1; done' ] containers: - name: setup-and-migrate-db image: {{ .Values.werf.image.backend }} command: - python3 - manage.py - migrate
Зачем ждать выполнения 10 подряд успешных проверок доступности БД?

Это предохраняет нас от случая, когда mysqladmin ping выполняется только один раз и до того, как StatefulSet с MySQL начнёт перезапускаться при деплое. В таких случаях во время выполнения инициализации/миграций база данных может оказаться недоступна.

Также в образах с БД при первом запуске главный процесс БД может несколько раз перезапускаться (при этом без перезапуска контейнера). В таком случае, если проверять БД на доступность только один раз, то может оказаться, что после успешной однократной проверки запускаются миграции/инициализация в то же время, когда начинает перезапускаться сам процесс БД. От этого нас тоже страхует выполнение mysqladmin ping несколько раз подряд.

Количество успешных проверок подряд можно изменять — значение 10 приведено как пример.

Проверка работы приложения и БД

Развернём приложение:

werf converge --repo <ИМЯ ПОЛЬЗОВАТЕЛЯ DOCKER HUB>/werf-guide-app

Ожидаемый результат:

┌ ⛵ image backend
│ │ ┌ Store stage into <ИМЯ ПОЛЬЗОВАТЕЛЯ DOCKER HUB>/werf-guide-app
│ │ └ Store stage into <ИМЯ ПОЛЬЗОВАТЕЛЯ DOCKER HUB>/werf-guide-app (26.11 seconds)
│ ├ Info
│ │      name: <ИМЯ ПОЛЬЗОВАТЕЛЯ DOCKER HUB>/werf-guide-app:f2c2c9fec791d5b84cc7f7c7f0dd56c7c6e0bf91573c657fa0e888cb-1661342563986
│ │        id: e5b46760a75e
│ │   created: 2022-08-24 15:02:42 +0000 UTC
│ │      size: 124.2 MiB
│ └ Building stage backend/dockerfile (57.10 seconds)
└ ⛵ image backend (60.17 seconds)

┌ ⛵ image frontend
│ Use cache image for frontend/dockerfile
│      name: <ИМЯ ПОЛЬЗОВАТЕЛЯ DOCKER HUB>/werf-guide-app:776dd1b11f95e6a08e138ce50ac0c4ece93051b8522db3a905e71e0a-1661341020624
│        id: ef98a01890ab
│   created: 2022-08-24 14:36:58 +0000 UTC
│      size: 9.7 MiB
└ ⛵ image frontend (3.20 seconds)

┌ Waiting for resources to become ready
│ ┌ Status progress
│ │ DEPLOYMENT                                                           REPLICAS     AVAILABLE     UP-TO-DATE
│ │ werf-guide-app                                                       2/1          1             1
│ │ │   POD                       READY    RESTARTS     STATUS           ---
│ │ ├── guide-app-6454b7f4f6-5d6n 2/2      0            Running          Waiting for: replicas 2->1
│ │ │   8
│ │ └── guide-app-64756fd5fb-tt6k 0/2      0            ContainerCreatin
│ │     g                                               g
│ │ STATEFULSET                                                          REPLICAS     READY         UP-TO-DATE
│ │ mysql                                                                1/1          1             1
│ │ JOB                                                                  ACTIVE       DURATION      SUCCEEDED/FAILED
│ │ setup-and-migrate-db-rev4                                            1            3s            0/0
│ │ │   POD                       READY    RESTARTS     STATUS           ---
│ │ └── and-migrate-db-rev4-k7nmq 0/1      0            PodInitializing  Waiting for: pods should be terminated,
│ │                                                                      succeeded 0->1
│ └ Status progress
│
│ ┌ job/setup-and-migrate-db-rev4 po/setup-and-migrate-db-rev4-k7nmq container/setup-and-migrate-db logs
│ │ Operations to perform:
│ │   Apply all migrations: admin, auth, contenttypes, sessions, talkers
│ │ Running migrations:
│ │   No migrations to apply.
│ └ job/setup-and-migrate-db-rev4 po/setup-and-migrate-db-rev4-k7nmq container/setup-and-migrate-db logs
│
│ ┌ Status progress
│ │ DEPLOYMENT                                                           REPLICAS     AVAILABLE     UP-TO-DATE
│ │ werf-guide-app                                                       2->1/1       1             1                 ↵
│ │
│ │ │   POD                       READY    RESTARTS     STATUS
│ │ ├── guide-app-6454b7f4f6-5d6n 2/2      0            Running ->
│ │ │   8                                               Terminating
│ │ └── guide-app-64756fd5fb-tt6k 2/2      0            ContainerCreatin
│ │     g                                               g -> Running
│ │ STATEFULSET                                                          REPLICAS     READY         UP-TO-DATE
│ │ mysql                                                                1/1          1             1
│ │ JOB                                                                  ACTIVE       DURATION      SUCCEEDED/FAILED
│ │ setup-and-migrate-db-rev4                                            0            14s           0->1/0
│ │ │   POD                       READY    RESTARTS     STATUS
│ │ └── and-migrate-db-rev4-k7nmq 0/1      0            PodInitializing
│ │                                                     -> Completed
│ └ Status progress
└ Waiting for resources to become ready (13.68 seconds)

┌ Waiting for resources elimination: jobs/setup-and-migrate-db-rev3
└ Waiting for resources elimination: jobs/setup-and-migrate-db-rev3 (0.20 seconds)

Release "werf-guide-app" has been upgraded. Happy Helming!
NAME: werf-guide-app
LAST DEPLOYED: Wed Aug 24 15:03:15 2022
LAST PHASE: rollout
LAST STAGE: 0
NAMESPACE: werf-guide-app
STATUS: deployed
REVISION: 4
TEST SUITE: None
Running time 81.66 seconds

Если кажется, что процесс завис, а в сообщениях сплошные ошибки — все нормально, просто идет проверка на состояние MySQL, и нужно немного подождать (обычно не более 1-2 минут).

Попробуем обратиться на /say, который должен попытаться достать данные из БД:

curl http://werf-guide-app.test/say

Но так как в базе данных пока пусто, должно вернуться следующее:

I have nothing to say.

Тогда сохраним данные в БД через /remember:

curl "http://werf-guide-app.test/remember?answer=Love+you&name=sweetie"

Ожидаемый результат, означающий, что данные сохранены:

Got it.

Снова попробуем получить данные из БД через /say:

curl http://werf-guide-app.test/say

Ожидаемый успешный результат:

Love you, sweetie!

Также мы можем убедиться, что данные в базе действительно сохранены, запросив напрямую из БД содержимое таблицы:

kubectl -n werf-guide-app exec -it statefulset/mysql -- mysql -pdjango -e "SELECT * from talkers_talkers" django

Ожидаемый результат:

+----+----------+---------+
| id | answer   | name    |
+----+----------+---------+
|  1 | Love you | sweetie |
+----+----------+---------+

Готово!

Итогом этой главы стала реализация stateful-приложения, развертывание базы данных вместе с этим приложением, а также автоматическая инициализация БД и выполнение миграций. Подобный подход должен хорошо работать с любыми реляционными БД.

Как и прежде, увидеть все сделанные в этой главе изменения вы можете, выполнив команды, описанные в начале главы.

назад
далее