Наша биг дата проанализировала Telegram-чаты, форумы и разговоры в кулуарах IT-мероприятий и пометила объектные хранилища как инструмент, который ещё не все осмеливаются использовать в своих проектах. Хочу поделиться с вами своим опытом в формате статьи-воркшопа. Если вы пока не знакомы с этой технологией и паттернами её применения, надеюсь, эта статья поможет вам начать использовать её в своих проектах.
Зачем вообще говорить о хранении объектов?
С недавних пор я работаю Golang-разработчиком в Ozon. У нас в компании есть крутая команда админов и релиз-инженеров, которая построила инфраструктуру и CI вокруг неё. Благодаря этому я даже не задумываюсь о том, какие инструменты использовать для хранения файлов и как это всё поддерживать.
Но до прихода в Ozon я сталкивался с довольно интересными кейсами, когда хранение разных данных (документов, изображений) было организовано не самым изящным образом. Мне попадались SFTP, Google Drive и даже монтирование PVC в контейнер!
Использование всех этих решений сопряжено с проблемами, в основном связанными с масштабированием. Это и привело меня к знакомству с объектными хранилищами, ведь с их помощью можно красиво и удобно решать целый ряд задач.
TL;DR
Объектное хранилище – это дополнительный слой абстракции над файловой системой и хостом, который позволяет работать с файлами (получать доступ, хранить) через API.
Объектное хранилище может помочь вам в кейсах, когда необходимо хранить файлы пользователей в ваших приложениях, складывать статику и предоставлять доступ к ней через Ingress или хранить кеши вашего CI.
Все материалы к статье (исходники, конфиги, скрипты) лежат вот в этой репе.
Что такое объектное хранилище
Хранить данные нашего приложения можно различными способами, от хранения данных просто на диске до блоба в нашей БД (если она это поддерживает, конечно). Но будет такое решение оптимальным? Часто есть нефункциональные требования, которые нам хотелось бы реализовать: масштабируемость, простота поддержки, гибкость. Тут уже хранением файлов в БД или на диске не обойтись. В этих случаях, например, масштабирование программных систем, в которых хранение данных построено на работе с файловой системой хоста, оказывается довольно проблематичной историей.
И на помощь приходят те самые объектные хранилища, о которых сегодня и пойдёт речь. Объектное хранилище – это способ хранить данные и гибко получать к ним доступ как к объектам (файлам). В данном контексте объект – это файл и набор метаданных о нём.
Стоит ещё упомянуть, что в объектных хранилищах нет такого понятия, как структура каталогов. Все объекты находятся в одном «каталоге» – bucket. Структурирование данных предлагается делать на уровне приложения. Но никто не мешает назвать объект, например, так: objectScope/firstObject.dat .
Основное преимущество хранения данных в объектах – это возможность абстрагирования системы от технических деталей. Нас уже не интересует, какая файловая (или тем более операционная) система хранит наши данные. Мы не привязываемся к данным какими-то конкретными способами их представления, которые нам обеспечивает платформа.
В этой статье мы не будем сравнивать типы объектных хранилищ, а обратим наше внимание на класс S3-совместимых стораджей, на примере MinIO. Выбор обусловлен тем, что MinIO имеет низкий порог входа (привет, Ceph), а ещё оно Kubernetes Native, что бы это ни значило.
На мой взгляд, MinIO – это самый доступный способ начать использовать технологию объектного хранения данных прямо сейчас: его просто развернуть, легко управлять и его невозможно забыть. На протяжении долгого времени MinIO может удовлетворять таким требованиям, как доступность, масштабируемость и гибкость.
Вообще S3-совместимых решений на рынке много. Всегда есть, из чего выбрать, будь то облачные сервисы или self-hosted-решения. В общем случае мы всегда можем перенести наше приложение с одной платформы на другую (да, у некоторых провайдеров есть определённого рода vendor lock-in, но это уже детали конкретных реализаций).
Disclaimer: под S3 я буду иметь в виду технологию (S3-совместимые объектные хранилища), а не конкретный коммерческий продукт. Цель статьи – показать на примерах, как можно использовать такие решения в своих приложениях.
Кейс 1: прокат самокатов
В рамках формата статьи-воркшопа знакомиться с S3 в общем и с MinIO в частности мы будем на практике.
На практике часто возникает вопрос хранения и доступа к контенту, который генерируется или обрабатывается вашим приложением. Правильно выбранный подход может обеспечить спокойный сон и отсутствие головной боли, когда придёт время переносить или масштабировать наше приложение.
Давайте перейдём к кейсу. Представим, что мы пишем сервис для проката самокатов и у нас есть user story, когда клиент фотографирует самокат до и после аренды. Хранить медиаматериалы мы будем в объектном хранилище.
Для начала развернём наше хранилище.
Самый быстрый способ развернуть MinIO – это наш любимчик Docker, само собой.
С недавнего времени Docker – не такая уж и бесплатная штука, поэтому в репе на всякий случай есть альтернативные манифесты для Podman.
Запускать «голый» контейнер из терминала – нынче моветон, поэтому начнём сразу с манифеста для docker-compose.
# docker-compose.yaml
version: '3.7'
services:
minio:
image: minio/minio:latest
command: server --console-address ":9001" /data/
ports:
- "9000:9000"
- "9001:9001"
environment:
MINIO_ROOT_USER: ozontech
MINIO_ROOT_PASSWORD: minio123
volumes:
- minio-storage:/data
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"]
interval: 30s
timeout: 20s
retries: 3
volumes:
minio-storage:Сохраняем манифест и делаем $ docker-compose up в директории с манифестом.
Теперь мы можем управлять нашим хранилищем с помощью web-ui. Но это не самый удобный способ для автоматизации процессов (например, для создания пайплайнов в CI/CD), поэтому сверху ещё поставим CLI-утилиту:
$ go get github.com/minio/mc
И да, не забываем про export PATH=$PATH:$(go env GOPATH)/bin.
Cоздадим алиас в mc (залогинимся):
$ mc alias set minio http://localhost:9000 ozontech minio123
Теперь создадим bucket – раздел, в котором мы будем хранить данные нашего пользователя (не стоит ассоциировать его с папкой). Это скорее раздел, внутри которого мы будем хранить данные.
Назовем наш бакет “usersPhotos”:
$ mc mb minio/usersPhot
$ mc ls minio > [0B] usersPhotos
Теперь можно приступать к реализации на бэке. Писать будем на Golang. MinIO любезно нам предоставляет пакетик для работы со своим API.
Disclaimer: код ниже – лишь пример работы с объектным хранилищем; не стоит его рассматривать как набор best practices для использования в боевых проектах.
Начнём с подключения к хранилищу:
func (m *MinioProvider) Connect() error {
var err error
m.client, err = minio.New(m.url, &minio.Options{
Creds: credentials.NewStaticV4(m.user, m.password, ""),
Secure: m.ssl,
})
if err != nil {
log.Fatalln(err)
}
return err
}Теперь опишем ручку добавления медиа:
func (s *Server) uploadPhoto(w http.ResponseWriter, r *http.Request) {
// Убеждаемся, что к нам в ручку идут нужным методом
if r.Method != "POST" {
w.WriteHeader(http.StatusMethodNotAllowed)
return
}
// Получаем ID сессии аренды, чтобы знать, в каком контексте это фото
rentID, err := strconv.Atoi(r.Header.Get(HEADER_RENT_ID))
if err != nil {
logrus.Errorf("Can`t get rent id: %v\n", err)
http.Error(w, "Wrong request!", http.StatusBadRequest)
return
}
// Забираем фото из тела запроса
src, hdr, err := r.FormFile("photo")
if err != nil {
http.Error(w, "Wrong request!", http.StatusBadRequest)
return
}
// Получаем информацию о сессии аренды
session, err := s.database.GetRentStatus(rentID)
if err != nil {
logrus.Errorf("Can`t get session: %v\n", err)
http.Error(w, "Can`t upload photo!", http.StatusInternalServerError)
return
}
// Складываем данные в объект, который является своего рода контрактом
// между хранилищем изображений и нашей бизнес-логикой
object := models.ImageUnit{
Payload: src,
PayloadSize: hdr.Size,
User: session.User,
}
defer src.Close()
// Отправляем фото в хранилище
img, err := s.storage.UploadFile(r.Context(), object)
if err != nil {
logrus.Errorf("Fail update img in image strorage: %v\n", err)
http.Error(w, "Can`t upload photo!", http.StatusInternalServerError)
return
}
// Добавляем запись в БД с привязкой фото к сессии
err = s.database.AddImageRecord(img, rentID)
if err != nil {
logrus.Errorf("Fail update img in database: %v\n", err)
http.Error(w, "Can`t upload photo!", http.StatusInternalServerError)
}
}Загружаем фото:
func (m *MinioProvider) UploadFile(ctx context.Context, object models.ImageUnit) (string, error) {
// Получаем «уникальное» имя объекта для загружаемого фото
imageName := samokater.GenerateObjectName(object.User)
_, err := m.client.PutObject(
ctx,
UserObjectsBucketName, // Константа с именем бакета
imageName,
object.Payload,
object.PayloadSize,
minio.PutObjectOptions{ContentType: "image/png"},
)
return imageName, errНам надо как-то разделять фото до и после, поэтому мы добавим записи в базу данных:
func (s *PGS) AddImageRecord(img string, rentID int) error {
// Получаем информацию о сессии аренды
rent, err := s.GetRentStatus(rentID)
if err != nil {
logrus.Errorf("Can`t get rent record in db: %v\n", err)
return err
}
// В зависимости от того, были загружены фото до начала аренды
// или после её завершения, добавляем запись в соответствующее поле в БД
if rent.StartedAt.IsZero() {
return s.updateImages(rent.ImagesBefore, img, update_images_before, rentID)
}
return s.updateImages(rent.ImagesAfter, img, update_images_after, rentID)
}Ну и сам метод обновления записи в БД:
func (s *PGS) updateImages(old []string, new, req string, rentID int) error {
// Добавляем в список старых записей
// новую запись об изображении
old = append(old, new)
new = strings.Join(old, ",")
_, err := s.db.Exec(req, new, rentID)
if err != nil {
logrus.Errorf("Can`t update image record in db: %v\n", err)
}
return err
}Также мы могли бы напрямую через сервис вытаскивать и отдавать фото по запросу. Выглядело бы это примерно так:
func (s *Server) downloadPhoto(w http.ResponseWriter, r *http.Request) {
if r.Method != "GET" {
w.WriteHeader(http.StatusMethodNotAllowed)
return
}
rentID := r.URL.Query()["rid"][0]
if rentID == "" {
http.Error(w, "Can`t get rent-id from request", http.StatusBadRequest)
}
img, err := s.storage.DownloadFile(r.Context(), rentID)
if err != nil {
logrus.Errorf("Cant`t get image from image-storage: %v\n", err)
http.Error(w, "Can`t get image", http.StatusBadRequest)
}
s.sendImage(w, img.Payload)
}Ну и само получение файла из хранилища:
func (m *MinioProvider) DownloadFile(ctx context.Context, image string) (models.ImageUnit, error) {
reader, err := m.client.GetObject(
ctx,
UserObjectsBucketName,
image,
minio.GetObjectOptions{},
)
if err != nil {
logrus.Errorf("Cant`t get image from image-storage: %v\n", err)
}
defer reader.Close()
return models.ImageUnit{}, nil
}Но мы можем и просто проксировать запрос напрямую в MinIO, так как у нас нет причин этого не делать (на практике такими причинами могут быть требования безопасности или препроцессинг файлов перед передачей пользователю). Делать это можно, обернув всё в nginx:
server {
listen 8080;
underscores_in_headers on;
proxy_pass_request_headers on;
location / {
proxy_pass http://docker-samokater;
}
location /samokater {
proxy_pass http://docker-minio-api;
}
}
server {
listen 9090;
location / {
proxy_pass http://docker-minio-console;
proxy_redirect off;
}
}Получать ссылки на изображения мы будем через ручку rent_info:
func (s *Server) rentInfo(w http.ResponseWriter, r *http.Request) {
if r.Method != "GET" {
w.WriteHeader(http.StatusMethodNotAllowed)
return
}
rentID, err := strconv.Atoi(r.Header.Get(HEADER_RENT_ID))
if err != nil {
logrus.Errorf("Can`t get rent id: %v\n", err)
http.Error(w, "Wrong request!", http.StatusBadRequest)
return
}
session, err := s.database.GetRentStatus(rentID)
if err != nil {
logrus.Errorf("Can`t get session: %v\n", err)
http.Error(w, "Can`t rent info!", http.StatusInternalServerError)
return
}
// Обогащаем поля ссылками на изображения
session = enrichImagesLinks(session)
s.sendModel(w, session)
}И сам метод обогащения:
func enrichImagesLinks(session models.Rent) models.Rent {
for i, image := range session.ImagesBefore {
session.ImagesBefore[i] = fmt.Sprintf("%s/%s", ImageStorageSVCDSN, image)
}
for i, image := range session.ImagesAfter {
session.ImagesAfter[i] = fmt.Sprintf("%s/%s", ImageStorageSVCDSN, image)
}
return session
}Упакуем всё в docker-compose.yaml:
docker-compose.yaml
version: '3.7'
services:
minio:
image: minio/minio:latest
container_name: minio
restart: unless-stopped
command: server --console-address ":9001" /data/
ports:
- "9000:9000"
- "9001:9001"
environment:
MINIO_ROOT_USER: ozontech
MINIO_ROOT_PASSWORD: minio123
volumes:
- minio-storage:/data
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"]
interval: 30s
timeout: 20s
retries: 3
networks:
- app-network
samokater:
image: samokater:latest
container_name: samokater
build:
context: ./
dockerfile: samokater.Dockerfile
restart: unless-stopped
ports:
- 8080:8080
networks:
- app-network
environment:
SERVERPORT: :8080
DBPATH: user=postgres password=devpass dbname=postgres host=db port=5432 sslmode=disable
MINIOHOST: minio:9000
MINIOUSER: ozontech
MINIOPASS: minio123
depends_on:
- db
- minio
initDB:
image: mingration:latest
container_name: init
environment:
DBPATH: user=postgres password=devpass dbname=postgres host=db port=5432 sslmode=disable
build:
context: ./
dockerfile: mingration.Dockerfile
networks:
- app-network
depends_on:
- db
db:
container_name: db
image: postgres
restart: always
environment:
POSTGRES_PASSWORD: devpass
volumes:
- pg-storage:/var/lib/postgresql/data
ports:
- 5432:5432
networks:
- app-network
nginx:
image: nginx-custom:latest
build:
context: ./
dockerfile: nginx.Dockerfile
restart: unless-stopped
tty: true
container_name: nginx
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf
ports:
- 8000:80
- 443:443
networks:
- app-network
depends_on:
- samokater
networks:
app-network:
driver: bridge
volumes:
minio-storage:
pg-storage:Протестируем работу нашего приложения:
# Создаём сессию аренды
$ curl -i -X POST --header 'user_id:100' http://localhost:8080/api/v1/rent
HTTP/1.1 200 OK
{"ID":100,"Name":"","RentID":8674665223082153551}
# Добавляем пару фото до начала аренды
$ curl -i -X POST --header 'rent_id:8674665223082153551' --form photo=@/Users/ktikhomirov/image_1.png http://localhost:8080/api/v1/upload_photo --insecure
HTTP/1.1 200 OK
# Начинаем сессию аренды
$ curl -i -X POST http://localhost:8080/api/v1/rent_start -H "Content-Type: application/json" -d '{"ID":100,"RentID":8674665223082153551}'
HTTP/1.1 200 OK
# Завершаем сессию аренды
$ curl -i -X POST http://localhost:8080/api/v1/rent_stop -H "Content-Type: application/json" -d '{"ID":100,"RentID":8674665223082153551}'
HTTP/1.1 200 OK
# Добавляем фото после завершения аренды
$ curl -i -X POST --header 'rent_id:8674665223082153551' --form photo=@/Users/ktikhomirov/image_2.png http://localhost:8080/api/v1/upload_photo --insecure
# Получаем информацию об аренде
curl -i -X GET -H "rent_id:8674665223082153551" http://localhost:8080/api/v1/rent_info
HTTP/1.1 200 OK
{"ID":100,"Name":"","StartedAt":"2021-10-21T08:10:31.536028Z","CompletedAt":"2021-10-21T08:19:33.672493Z","ImagesBefore":["http://127.0.0.1:8080/samokater/100/2021-10-21T15:15:24.png","http://127.0.0.1:8080/samokater/100/2021-10-21T08:06:15.png"],"ImagesAfter":["http://127.0.0.1:8080/samokater/100/2021-10-21T08:21:06.png"],"RentID":8674665223082153551}
Кейс 2: хранение и раздача фронта
Ещё одна довольно популярная задача, для решения которой можно использовать объектные хранилища, – хранение и раздача фронта. Объектные хранилища пригодятся нам тут, когда захотим повысить доступность нашего фронта или удобнее им управлять. Это актуально, например, если у нас несколько проектов и мы хотим упростить себе жизнь.
Небольшая предыстория. Однажды я встретил довольно интересную практику в компании, где в месяц релизили по несколько лендингов. В основном они были написаны на Vue.js, изредка прикручивался API на пару простеньких ручек. Но моё внимание больше привлекло то, как это всё деплоилось: там царствовали контейнеры с nginx, внутри которых лежала статика, а над всем этим стоял хостовый nginx, который выполнял роль маршрутизатора запросов. Как тебе такой cloud-native-подход, Илон? В качестве борьбы с этим монстром мной было предложено обмазаться кубами, статику держать внутри MinIO, создавая для каждого лендинга свой бакет, а с помощью Ingress уже всё это проксировать наружу. Но, как говорится, давайте не будем говорить о плохом, а лучше сделаем!
Представим, что перед нами стоит похожая задача и у нас уже есть Kubernetes. Давайте туда раскатаем MinIO Operator. Стоп, почему нельзя просто запустить MinIO в поде и пробросить туда порты? А потому, что MinIO-Operator любезно сделает это за нас, а заодно построит High Availability-хранилище. Для этого нам всего лишь надо три столовые ложки соды... воспользоваться официальной документацией.
Для простоты установки мы вооружимся смузи Krew, который всё сделает за нас:
$ kubectl krew update
$ kubectl krew install minio
$ kubectl minio init
Теперь надо создать tenant. Для этого перейдём в панель управления. Чтобы туда попасть, прокинем прокси: $ kubectl minio proxy -n minio-operator
После прокидывания портов до нашего оператора мы получим в вывод терминала JWT-токен, с которым и залогинимся в нашей панели управления:
Далее нажимаем на кнопку «Добавить тенант» и задаём ему имя и неймспейс:
После нажатия на кнопку «Создать» мы получим креденшиалы, которые стоит записать в какой-нибудь Vault:
Теперь для доступа к панели нашего кластера хранилищ, поднимем прокси к сервису minio-svc и его панели управления:
# Поднимаем прокси к дашборду minio-svc
kubectl -n minio-operator port-forward service/minio-svc-console 9090:9090
# Поднимаем прокси к API minio-svc
kubectl -n minio-operator port-forward service/minio-svc-hl 9000:9000И вуаля! У нас есть высокодоступный отказоустойчивый кластер MinIO. Давайте прикрутим его к нашему GitLab CI и сделаем .gitlab_ci, чтобы в пару кликов деплоить фронт.
Вот так у нас будет выглядеть джоба для CI/CD на примере GitLab CI (целиком конфиг лежит в репе):
# gitlab-ci
deploy-front:
stage: deploy
image: minio/mc
script:
# Логинимся в MinIO
- mc config host add --insecure deploy $CI_OBJECT_STORAGE $CI_OBJECT_STORAGE_USER $CI_OBJECT_STORAGE_PASSWORD
# И всё собранное ранее переносим в наш бакет
- mc cp dist/* deploy/static --insecure -c -r
dependencies:
- build-frontДля того чтобы отдавать статику, добавим Ingress-манифест:
# static.yaml
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: example-static
labels:
app.kubernetes.io/name: example-static
app.kubernetes.io/version: "latest"
annotations:
cert-manager.io/cluster-issuer: letsencrypt-worker
kubernetes.io/ingress.class: nginx
kubernetes.io/tls-acme: "true"
nginx.ingress.kubernetes.io/proxy-body-size: 100m
nginx.ingress.kubernetes.io/secure-backends: "true"
nginx.ingress.kubernetes.io/ssl-redirect: "true"
nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
nginx.ingress.kubernetes.io/rewrite-target: /$1
spec:
tls:
- hosts:
- "domain.ru"
secretName: ssl-letsencrypt-example
rules:
- host: "domain.ru"
http:
paths:
- backend:
serviceName: minio-svc
servicePort: 9000
path: /(.+)
pathType: PrefixА если вдруг потребуется доступ из других неймспейсов, то мы можем создать ресурс ExternalName:
---
apiVersion: v1
kind: Service
metadata:
name: minio-svc
namespace: deploy
spec:
ports:
- port: 9000
protocol: TCP
targetPort: 9000
sessionAffinity: None
type: ExternalNameВместо вывода
Объектные хранилища – это класс инструментов, которые позволяют наделить систему высокодоступным хранилищем данных. Во времена cloud-native это незаменимый помощник в решении многих задач. Да, на практике могут случаться кейсы, в которых использование объектного хранения данных будет избыточным, но вряд ли это можно считать поводом совсем игнорировать этот инструментарий в других своих проектах.
Отдельно я бы посоветовал обратить внимание на S3-совместимые решения, если вы занимаетесь машинным обучением или BigData и у вас есть потребность в хранении большого количества медиаданных для их последующей обработки.
Рассмотренное в статье MinIO – это не единственный достойный инструмент, который позволяет работать с данной технологией. Существуют решения на основе Ceph и Riak CS и даже S3 от Amazon. У всех инструментов свои плюсы и минусы.
Желаю вам успехов в создании и масштабировании ваших приложений и надеюсь, что объектные хранилища вам будут в этом помогать!
Делитесь в комментариях о вашем опыте работы с объектными хранилищами и задавайте вопроы!
