В этой главе в приложении появится функциональность, которая позволит загружать и скачивать файлы. Будут рассмотрены особенности работы с файлами в Kubernetes, а также продемонстрирован рабочий пример с использованием S3-хранилища.

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

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

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

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

Работает ли 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/rails/050_s3/* .
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/rails/050_s3/. .
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/werf-guides $env:HOMEPATH/werf-guide/guides
}

# Скопируем файлы приложения (пока без изменений) в ~/werf-guide/app
rm -Recurse -Force ~/werf-guide/app
cp -Recurse -Force ~/werf-guide/guides/examples/rails/040_db ~/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/rails/050_s3/* .
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/werf-guides ~/werf-guide/guides

# Скопируем файлы приложения (пока без изменений) в ~/werf-guide/app
rm -rf ~/werf-guide/app
cp -rf ~/werf-guide/guides/examples/rails/040_db ~/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/rails/050_s3/. .
git add .
git commit -m WIP
Посмотреть, какие именно изменения мы произведём
# Показать, какие файлы мы собираемся изменить
git show --stat
# Показать изменения
git show

Как хранить файлы

Контейнеры, развертываемые в Kubernetes, часто будут создаваться и удаляться автоматически — например, из-за обновления Deployment. Это значит, что мы не можем хранить файлы, создающиеся приложением, прямо в файловой системе контейнера. Потому что так файлы будут:

  • доступны только одному контейнеру/реплике приложения, а не всем,
  • удаляться при удалении контейнера.

Поэтому контейнеры должны хранить в своей файловой системе только те данные, которые можно потерять.

Кстати, когда такая возможность есть, файловую систему контейнера даже переключают в read-only, что улучшает безопасность и позволяет убедиться, что приложение действительно не сохраняет данные локально.

Но что делать, если какие-то данные все-таки нужно хранить? Для этого обычно используют развертываемые отдельно базы данных. В частности, для хранения обычных файлов часто используют нереляционные базы данных вроде объектных хранилищ. И особенно часто для хранения файлов используют объектные хранилища, предоставляющие API, совместимый с Amazon S3 API.

Далее мы продемонстрируем, как хранить файлы не в локальной файловой системе, а в S3-совместимом хранилище, чтобы ваши приложения оставались stateless и не испытывали проблем при работе с Kubernetes.

Включение Active Storage

Для работы с объектным хранилищем нам потребуется включить компонент Active Storage.

Базовая конфигурация для Active Storage перенесена в наше приложение из скелета нового Rails-приложения, сгенерированного следующей командой (из команды убрано --skip-active-storage):

rails new --database mysql --skip-keeps --skip-action-mailer --skip-action-mailbox --skip-action-text --skip-active-job --skip-action-cable --skip-sprockets --skip-spring --skip-listen --skip-turbolinks --skip-jbuilder --skip-test --skip-system-test --skip-bootsnap .

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

  1. Добавлен gem aws-sdk-s3 в Gemfile.
  2. Добавлен пакет rails-activestorage в package.json.
  3. Включен active_storage/engine в config/application.rb и проинициализирован Active Storage в packs/application.js.
  4. Создана миграция для создания таблиц, требуемых для работы Active Storage.
  5. Создан конфигурационный файл config/storage.yml.

Добавление endpoint’ов /upload и /download в приложение

Для демонстрации работы загрузки и отдачи файлов мы добавим два новых endpoints, один из которых будет загружать файл в S3-совместимое объектное хранилище (/upload), а другой — отдавать его оттуда (/download).

Добавим новый контроллер и модель:

class S3FileController < ActionController::API
  def download
    begin
      file = S3File.find(0)
    rescue ActiveRecord::RecordNotFound => e
      render plain: "You haven't uploaded anything yet.\n" and return
    end

    send_data file.file.download, filename: file.file.blob.filename.to_s, type: file.file.blob.content_type, disposition: "inline"
  end

  def upload
    unless params.dig(:file).present?
      render plain: "You didn't pass the file to upload :(\n" and return
    end

    begin
      file = S3File.find(0)
    rescue ActiveRecord::RecordNotFound => e
      file = S3File.new
    end
    file.update(id: 0)
    file.file.attach(params[:file])
    file.save()

    render plain: "File uploaded.\n"
  end
end
class S3FileController < ActionController::API def download begin file = S3File.find(0) rescue ActiveRecord::RecordNotFound => e render plain: "You haven't uploaded anything yet.\n" and return end send_data file.file.download, filename: file.file.blob.filename.to_s, type: file.file.blob.content_type, disposition: "inline" end def upload unless params.dig(:file).present? render plain: "You didn't pass the file to upload :(\n" and return end begin file = S3File.find(0) rescue ActiveRecord::RecordNotFound => e file = S3File.new end file.update(id: 0) file.file.attach(params[:file]) file.save() render plain: "File uploaded.\n" end end
class S3File < ActiveRecord::Base
  has_one_attached :file
end
class S3File < ActiveRecord::Base has_one_attached :file end

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

...
get '/download', to: 's3_file#download'
post '/upload', to: 's3_file#upload'
... get '/download', to: 's3_file#download' post '/upload', to: 's3_file#upload'

Также добавим миграцию для создания таблиц:

class CreateS3Files < ActiveRecord::Migration[6.1]
  def change
    create_table :s3_files do |f|
    end
  end
end
class CreateS3Files < ActiveRecord::Migration[6.1] def change create_table :s3_files do |f| end end end

После этого сгенерируем и сохраним новую db/schema.rb.

Новые endpoint’ы — /upload и /download — добавлены. Осталось только настроить для них работу с хранилищем.

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

Для демонстрации, в качестве S3-совместимого объектного хранилища мы будем использовать MinIO, но вместо него может использоваться и любое другое S3-хранилище (например, Amazon S3).

Обратите внимание, что если вы используете иное S3-хранилище, то создание нижеописанных StatefulSet и Job для MinIO не потребуется, но остальные инструкции останутся актуальными.

Добавим StatefulSet с MinIO:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: minio
spec:
  serviceName: minio
  selector:
    matchLabels:
      app: minio
  template:
    metadata:
      labels:
        app: minio
    spec:
      containers:
      - name: minio
        image: minio/minio
        args: ["server", "/data", "--console-address", ":9001"]
        ports:
        - containerPort: 9000
          name: minio
        - containerPort: 9001
          name: console
        volumeMounts:
        - name: minio-data
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: minio-data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 100Mi

---
apiVersion: v1
kind: Service
metadata:
  name: minio
spec:
  selector:
    app: minio
  ports:
  - port: 9000
    name: minio
  - port: 9001
    name: console
apiVersion: apps/v1 kind: StatefulSet metadata: name: minio spec: serviceName: minio selector: matchLabels: app: minio template: metadata: labels: app: minio spec: containers: - name: minio image: minio/minio args: ["server", "/data", "--console-address", ":9001"] ports: - containerPort: 9000 name: minio - containerPort: 9001 name: console volumeMounts: - name: minio-data mountPath: /data volumeClaimTemplates: - metadata: name: minio-data spec: accessModes: ["ReadWriteOnce"] resources: requests: storage: 100Mi --- apiVersion: v1 kind: Service metadata: name: minio spec: selector: app: minio ports: - port: 9000 name: minio - port: 9001 name: console

Создадим Job для настройки MinIO:

apiVersion: batch/v1
kind: Job
metadata:
  name: "setup-minio-rev{{ .Release.Revision }}"
spec:
  backoffLimit: 0
  template:
    spec:
      restartPolicy: Never
      containers:
      - name: setup-minio
        image: minio/mc
        command:
        - sh
        - -euc
        - |
          is_minio_available() {
            tries=$1
            i=0
            while [ $i -lt $tries ]; do
              curl -sSL http://minio:9000/minio/health/live || return 1
              i=$((i+1))
              sleep 1
            done
          }

          # Дожидаемся доступности MinIO.
          until is_minio_available 10; do
            sleep 1
          done

          # Настроим доступ к нашем инстансу MinIO.
          mc alias set minio http://minio:9000 minioadmin minioadmin

          # Создадим bucket для нашего приложения.
          mc mb --ignore-existing minio/werf-guide-app
apiVersion: batch/v1 kind: Job metadata: name: "setup-minio-rev{{ .Release.Revision }}" spec: backoffLimit: 0 template: spec: restartPolicy: Never containers: - name: setup-minio image: minio/mc command: - sh - -euc - | is_minio_available() { tries=$1 i=0 while [ $i -lt $tries ]; do curl -sSL http://minio:9000/minio/health/live || return 1 i=$((i+1)) sleep 1 done } # Дожидаемся доступности MinIO. until is_minio_available 10; do sleep 1 done # Настроим доступ к нашем инстансу MinIO. mc alias set minio http://minio:9000 minioadmin minioadmin # Создадим bucket для нашего приложения. mc mb --ignore-existing minio/werf-guide-app

Добавим в приложение конфигурацию для подключения к MinIO:

minio:
  service: S3
  endpoint: http://minio:9000
  region: us-east-1
  bucket: werf-guide-app
  access_key_id: minioadmin
  secret_access_key: minioadmin
  force_path_style: true
minio: service: S3 endpoint: http://minio:9000 region: us-east-1 bucket: werf-guide-app access_key_id: minioadmin secret_access_key: minioadmin force_path_style: true

И задействуем для хранения файлов сконфигурированный MinIO storage:

...
config.active_storage.service = :minio
... config.active_storage.service = :minio

Теперь MinIO готов к развертыванию, а приложение — настроено на хранение файлов в нём.

Проверка работы хранилища

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

werf converge --repo <имя пользователя Docker Hub>/werf-guide-app

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

...
┌ ⛵ image backend
│ ┌ Building stage backend/dockerfile
│ │ backend/dockerfile  Sending build context to Docker daemon  338.4kB
│ │ backend/dockerfile  Step 1/25 : FROM ruby:2.7 as base
│ │ backend/dockerfile   ---> 1faa5f2f8ca3
...
│ │ backend/dockerfile  Step 25/25 : LABEL werf-version=v1.2.13+fix12
│ │ backend/dockerfile   ---> Running in 14e4091f77b4
│ │ backend/dockerfile  Removing intermediate container 14e4091f77b4
│ │ backend/dockerfile   ---> a13f82df04f3
│ │ backend/dockerfile  Successfully built a13f82df04f3
│ │ backend/dockerfile  Successfully tagged 5ee7a784-4b47-402c-8fe1-b15af1418df0:latest
│ │ ┌ Store stage into .../werf-guide-app
│ │ └ Store stage into .../werf-guide-app (13.79 seconds)
│ ├ Info
│ │      name: .../werf-guide-app:2fafb795aa5ea01de13a6095eeca262552b79dddfedc887b1781bc5f-1630413036132
│ │        id: a13f82df04f3
│ │   created: 2021-08-31 15:30:35 +0300 MSK
│ │      size: 366.3 MiB
│ └ Building stage backend/dockerfile (23.83 seconds)
└ ⛵ image backend (30.97 seconds)

┌ ⛵ image frontend
│ ┌ Building stage frontend/dockerfile
│ │ frontend/dockerfile  Sending build context to Docker daemon  338.4kB
│ │ frontend/dockerfile  Step 1/29 : FROM ruby:2.7 as base
│ │ frontend/dockerfile   ---> 1faa5f2f8ca3
...
│ │ frontend/dockerfile  Step 29/29 : LABEL werf-version=v1.2.13+fix12
│ │ frontend/dockerfile   ---> Running in 0eba0fb1b573
│ │ frontend/dockerfile  Removing intermediate container 0eba0fb1b573
│ │ frontend/dockerfile   ---> b9bbdb91f081
│ │ frontend/dockerfile  Successfully built b9bbdb91f081
│ │ frontend/dockerfile  Successfully tagged c5c02694-3157-4e24-a6f5-e3efddf1fcf5:latest
│ │ ┌ Store stage into .../werf-guide-app
│ │ └ Store stage into .../werf-guide-app (14.95 seconds)
│ ├ Info
│ │      name: .../werf-guide-app:8dd338dab9cf7e58c1aafbd3c99589c68517812054d38d5eca46b69e-1630413035974
│ │        id: b9bbdb91f081
│ │   created: 2021-08-31 15:30:35 +0300 MSK
│ │      size: 9.5 MiB
│ └ Building stage frontend/dockerfile (24.97 seconds)
└ ⛵ image frontend (32.04 seconds)

Release "werf-guide-app" does not exist. Installing it now.

┌ Waiting for release resources to become ready
│ ┌ Status progress
│ │ DEPLOYMENT      REPLICAS  AVAILABLE  UP-TO-DATE
│ │ werf-guide-app  1/1       0          1
│ │ │    POD                         READY  RESTARTS  STATUS    ---
│ │ └──  guide-app-6b89879785-pklns  0/2    0         Init:0/1  Waiting  for:  available  0->1
│ │ STATEFULSET  REPLICAS  READY  UP-TO-DATE
│ │ minio        1/1       0      1
│ │ │    POD  READY  RESTARTS  STATUS             ---
│ │ └──  0    0/1    0         ContainerCreating  Waiting  for:  ready  0->1
│ │ mysql        1/1       1      1
│ │ JOB                        ACTIVE  DURATION  SUCCEEDED/FAILED
│ │ setup-and-migrate-db-rev1  1       3s        0/0
│ │ │    POD                        READY  RESTARTS  STATUS             ---
│ │ └──  and-migrate-db-rev1-jhlh8  0/1    0         ContainerCreating  Waiting  for:  pods  should  be  terminated,  succeeded  0->1
│ │ setup-minio-rev1           1       3s        0/0
│ │ │    POD               READY  RESTARTS  STATUS             ---
│ │ └──  minio-rev1-v72nq  0/1    0         ContainerCreating  Waiting  for:  pods  should  be  terminated,  succeeded  0->1
│ └ Status progress
...
│ ┌ deploy/werf-guide-app po/werf-guide-app-6b89879785-pklns container/wait-db-readiness logs
│ │ rails aborted!
│ │ ActiveRecord::ConnectionNotEstablished: Cant connect to MySQL server on 'mysql' (115)
│ │
│ │ Caused by:
│ │ Mysql2::Error::ConnectionError: Cant connect to MySQL server on 'mysql' (115)
│ │
│ │ Tasks: TOP => db:migrate:status
│ │ (See full trace by running task with --trace)
│ └ deploy/werf-guide-app po/werf-guide-app-6b89879785-pklns container/wait-db-readiness logs
│
│ ┌ job/setup-and-migrate-db-rev1 po/setup-and-migrate-db-rev1-jhlh8 container/setup-and-migrate-db logs
│ │ mysqladmin: connect to server at 'mysql' failed
│ │ error: 'Cant connect to MySQL server on 'mysql' (115)'
│ │ Check that mysqld is running and that the socket: '/var/run/mysqld/mysqld.sock' exists!
│ └ job/setup-and-migrate-db-rev1 po/setup-and-migrate-db-rev1-jhlh8 container/setup-and-migrate-db logs
|
│ ┌ job/setup-and-migrate-db-rev1 po/setup-and-migrate-db-rev1-jhlh8 container/setup-and-migrate-db logs
│ │ mysqladmin: connect to server at 'mysql' failed
│ │ error: 'Access denied for user 'root'@'172.17.0.1' (using password: YES)'
│ └ job/setup-and-migrate-db-rev1 po/setup-and-migrate-db-rev1-jhlh8 container/setup-and-migrate-db logs
│
│ ┌ deploy/werf-guide-app po/werf-guide-app-6b89879785-pklns container/wait-db-readiness logs
│ │ rails aborted!
│ │ ActiveRecord::NoDatabaseError: Unknown database 'werf-guide-app'
│ │
│ │ Caused by:
│ │ Mysql2::Error: Unknown database 'werf-guide-app'
│ │
│ │ Tasks: TOP => db:migrate:status
│ │ (See full trace by running task with --trace)
│ └ deploy/werf-guide-app po/werf-guide-app-6b89879785-pklns container/wait-db-readiness logs
│
│ ┌ job/setup-and-migrate-db-rev1 po/setup-and-migrate-db-rev1-jhlh8 container/setup-and-migrate-db logs
│ │ Created database 'werf-guide-app'
│ └ job/setup-and-migrate-db-rev1 po/setup-and-migrate-db-rev1-jhlh8 container/setup-and-migrate-db logs
│
│ ┌ job/setup-minio-rev1 po/setup-minio-rev1-v72nq container/setup-minio logs
│ │ Added "minio" successfully.
│ │ Bucket created successfully "minio/werf-guide-app".
│ └ job/setup-minio-rev1 po/setup-minio-rev1-v72nq container/setup-minio logs
...
│ ┌ deploy/werf-guide-app po/werf-guide-app-6b89879785-pklns container/wait-db-readiness logs
│ │
│ │ database: werf-guide-app
│ │
│ │  Status   Migration ID    Migration Name
│ │ --------------------------------------------------
│ │    up     20210817162438  Create talkers
│ │    up     20210817164348  Add name to talkers
│ │   down    20210830170827  Create active storage tablesactive storage
│ │   down    20210830171006  Create s3 files
│ │
│ └ deploy/werf-guide-app po/werf-guide-app-6b89879785-pklns container/wait-db-readiness logs
│
│ ┌ Status                     progress
│ │ DEPLOYMENT      REPLICAS  AVAILABLE  UP-TO-DATE
│ │ werf-guide-app  1/1       0->1       1
│ │ │    POD                         READY  RESTARTS  STATUS
│ │ └──  guide-app-6b89879785-pklns  2/2    0         PodInitializing  ->  Running
│ │ STATEFULSET  REPLICAS  READY  UP-TO-DATE
│ │ minio        1/1       1      1
│ │ │    POD  READY  RESTARTS  STATUS
│ │ └──  0    1/1    0         Running
│ │ mysql        1/1       1      1
│ │ JOB                        ACTIVE  DURATION  SUCCEEDED/FAILED
│ │ setup-and-migrate-db-rev1  0       24s       1/0
│ │ │    POD                        READY  RESTARTS  STATUS
│ │ └──  and-migrate-db-rev1-jhlh8  0/1    0         Completed
│ │ setup-minio-rev1           0       25s       1/0
│ │ │    POD               READY  RESTARTS  STATUS
│ │ └──  minio-rev1-v72nq  0/1    0         Completed
│ └ Status                     progress
└ Waiting for release resources to become ready (30.31 seconds)

NAME: werf-guide-app
LAST DEPLOYED: Tue Aug 31 15:30:55 2021
NAMESPACE: werf-guide-app
STATUS: deployed
REVISION: 1
TEST SUITE: None
Running time 65.26 seconds

Обратимся на /download, который должен попытаться достать файл из S3:

curl http://werf-guide-app/download

Так как пока никаких файлов не загружено, получим:

You haven't uploaded anything yet.

Тогда создадим новый файл и загрузим его в S3:

echo "This is file content." > file.txt
curl -F "file=@file.txt" http://werf-guide-app/upload
"This is file content." | Out-File -Encoding ascii -FilePath file.txt
curl.exe -F "file=@file.txt" http://werf-guide-app/upload

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

File uploaded.

Снова попробуем получить файл из хранилища:

curl http://werf-guide-app/download

В ответ должно отобразиться содержимое файла:

This is file content.

Также убедимся, что файл сохранился и достаётся именно из хранилища. Для этого сначала запустим контейнер с утилитой mc для взаимодействия с MinIO:

kubectl run mc --image=minio/mc --rm -it --command -- bash

Теперь, оказавшись внутри контейнера, выполним команды:

# Настроим подключение к MinIO.
mc alias set minio http://minio:9000 minioadmin minioadmin
# Получим содержимое сохранённого файла из S3.
mc cat "minio/werf-guide-app/$(mc ls minio/werf-guide-app | awk 'NR==1 {print $5}')"

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

This is file content.

Теперь, если нам требуется работать с файлами, мы можем получать и хранить их в объектном хранилище, а не в файловой системе контейнера. При таком подходе Pod’ы приложения могут создаваться и удаляться без проблем: файлы не потеряются, будут доступны с любой реплики Deployment’а приложения, а файловая система на узлах Kubernetes не будет заполняться ненужными файлами.

Не забывайте: в контейнере можно хранить только те данные, которые можно потерять. Все остальные данные нужно хранить в соответствующих базах данных/хранилищах. Такой подход, в частности, подтверждается лучшими практиками от инженеров Google Cloud.