Привет! Меня зовут Максим Базуев, я мобильный разработчик. Последние 6 лет занимаюсь разработкой гибридных мобильных приложений с использованием веб-технологий.
Сейчас я работаю над стартапом — мобильным приложением в тематике повышения продуктивности. Пока оно не в релизе. У меня маленькая команда, одна крошечная виртуалка на 1 ГБ RAM, 1 CPU и 20 ГБ диска (и там у меня Kubernetes).
В этой статье я решил поделиться своим кейсом:
с каким стеком я работаю;
какую роль занимает бэкенд и какие сервисы висят на виртуалке;
как я познакомился с werf и почему выбрал его;
зачем использую werf, с какими проблемами столкнулся при развёртывании и чем помогла утилита.
Мой кейс будет полезен тем, кто ещё не знаком с werf — утилитой для доставки приложений в Kubernetes, — а также спецам из мира разработки, которые смотрят на K8s и ищут подходящие инструменты для работы с ним.
Стек разработки
Моё мобильное приложение — гибридное. Оно использует платформу CapacitorJS (для обёртки веба в мобильное приложение от экс-разработчиков Cordova) и поддерживает офлайн-режим как основную функциональность. При появлении подключения к интернету происходит отправка пакета мутаций на бэкенд, чтобы синхронизировать состояние между устройствами пользователя.
На стороне бэкенда реализовано решение tRPC, представляющее собой type-safe API уровня end-to-end, поскольку клиент и сервер разработаны на TypeScript и находятся в одном монорепозитории. Это позволяет мне обеспечить надёжность взаимодействия между компонентами и ускорить разработку. Для валидации и парсинга данных использую библиотеки Zod и SuperJSON. Они позволяют передавать различные типы данных между клиентом и сервером и не вспоминать, где какой тип в структуре данных, что экономит много времени.
Бэкенд в данной архитектуре выполняет роль синхронизации данных между клиентскими устройствами. У нас небольшой набор сервисов: приложение бэкенда и PostgreSQL, развёрнутый с использованием OpenEBS на компактной виртуальной машине с интеграцией Traefik Ingress. Благодаря OpenEBS получается минимальная задержка при работе с диском, что полностью меня устраивает. Ещё планирую добавить сервис для сбора логов с бэкенда, но пока не определился, какой именно инструмент выбрать, так как не сильно разбираюсь в этой области, смотрю в сторону Fluent Bit.
Внедрение в проект werf и мои ошибки
Примерно 2–3 года назад я начал изучать видеоролики по Kubernetes на YouTube. Два месяца назад я решил установить оркестратор и понял, что ему нужно много ресурсов. Тогда я начал искать его реализацию на GitHub и наткнулся на k0s, который полностью совместим с Kubernetes и не требует огромного количества ресурсов.
А ещё во время своего YouTube-исследования благодаря докладам компании «Флант» я познакомился с Open Source-решением werf. Я сразу установил утилиту, а затем развернул свой бэкенд вместе с базой данных, добавленной в зависимости чарта. В итоге werf используетсяу меня как для staging, так и для production.
В процессе внедрения я столкнулся с несколькими ошибками при деплойменте. Например, забыл добавить один из секретов в нужное пространство имён. Однако werf предоставил мне статус и логи работы в режиме реального времени. Утилита уведомила о возникшей 401-й ошибке и подсказала, что чего-то не хватает. Я погуглил и нашёл ответ: необходимо добавить секреты к образу. В итоге ошибки быстро исправились, и мой бэкенд с базой данных был готов к работе всего за несколько минут.
# Пример добавления секрета для Docker Registry (с которым у меня была ошибка).
kubectl create secret docker-registry NAME --docker-username=user --docker-password=passwordРабота с секретами в werf
Важными факторами в выборе werf для меня стали возможность работы с секретами и их хранение в репозитории с помощью команды werf helm secret values edit .helm/secret-values.yaml. В дополнение к этой идее я установил SOPS от Mozilla, что решило проблемы с совместным использованием секретов между членами команды и CI-системой. Честно говоря, работа с секретами заслуживает отдельной статьи.
# Пример конфигурации SOPS.
creation_rules:
- age: >-
age1j25…Команду werf converge используем для деплоя и развёртывания сервиса backend и admin (админ-панель):
# backend.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: backend
spec:
replicas: {{ index $.Values.backend.replicas $.Values.werf.env }}
selector:
matchLabels:
app: backend
template:
metadata:
labels:
app: backend
annotations:
checksum/secretmap-app-envs: '{{ include (print $.Template.BasePath "/secret-app-envs.yaml") . | sha256sum }}' # Если поменяли секреты, то и под обновляет секреты.
spec:
imagePullSecrets:
- name: {{ $.Release.Namespace }}-regcred
containers:
- image: {{ $.Values.werf.image.backend }}
name: backend
ports:
- containerPort: 3000
envFrom:
- secretRef:
name: app-envs
Для развёртывания мобильных приложений я использую систему Fastlane, и в этом процессе очень удобно работать с SOPS для управления секретами. В SOPS я храню все свои секреты, включая секретный ключ werf, который также шифруется, ключи от кластера Kubernetes (dev, prod), keystore для подписи Android-сборки, ключ App Store Connect API, аккаунт для доступа к облаку.
В процессе CI/CD я активно использую секреты werf, так как они необходимы для сборки моих продуктов. Их можно шифровать с помощью SOPS. У меня есть только один ключ SOPS — Age key, и этого достаточно для расшифровки секретов. А с помощью .sops.yaml можно указать права для конкретных ключей, например по Regex для /.*\.dev\..*/ указать ключи для разработчиков, а доступ к проду будет иметь ограниченный круг лиц. Если я не буду хранить секретный ключ werf в SOPS, то мне придётся следить за его сохранностью отдельно.
# Пример конфигурации SOPS с разграничением прав на dev и prod.
creation_rules:
- path_regex: .*\.dev\..*
age: >-
age1j25…,
age1r…
- age: >-
age1j25…# Пример команды для шифрования секрета.
sops -e secrets/terraform.sa.key.dev.json > secrets/terraform.sa.key.dev.enc.json
# Пример команды для расшифровки секрета.
sops -d secrets/terraform.sa.key.dev.enc.json > secrets/terraform.sa.key.dev.json
# Пример sh-файлика для расшифровки секретов в папке.
#!/bin/sh
find . -name '*.enc.*' | xargs -n 1 -I '{}' echo sops -d {} \> {} | sed -E 's/\.enc//2' | bash
Гитерминизм
Мне особенно понравился гитерминизм в werf. Я активно использую его в коммуникации между бэкенд- и фронтенд-разработкой. Мобильное приложение, админ-панель и бэкенд живут в одном репозитории. Линтинг изменившихся ручек на бэкенде показывает сразу ошибки на мобильном приложении и админ-панели и не даст замержить их в основную ветку, пока ошибки не будут исправлены. Так я могу не беспокоиться об ошибках несовместимости бэкенд- и фронтенд-кода в окружении prod и staging.
# Пример конфигурации файла гитерминизма.
# https://werf.io/docs/v2/reference/werf_giterminism_yaml.html
giterminismConfigVersion: 1
config:
goTemplateRendering:
allowEnvVariables:
- SENTRY_AUTH_TOKEN
- VITE_APP_API_BASEВся инфраструктура хранится в Terraform-модулях внутри этого же репозитория, что позволяет отслеживать в Git состояние инфраструктуры проекта, включая информацию о том, в каком облаке что размещено. Такой подход, где всё представлено в виде кода (as a code), упрощает процесс адаптации для нового разработчика — достаточно выдать доступ по его Age-ключу к staging-окружению, и он сможет начать экспериментировать.
# Пример развертки кластера K0s в Terraform.
terraform {
required_providers {
k0s = {
source = "alessiodionisi/k0s"
version = "0.2.2"
}
}
}
variable "vm_address" {
type = string
}
variable "cluster_name" {
type = string
}
variable "ssh_key_path" {
type = string
}
variable "vm_user" {
type = string
default = "bazumax"
}
variable "kubeconfig_path" {
type = string
}
resource "k0s_cluster" "k0s" {
name = "main"
version = "1.28.7+k0s.0"
hosts = [
{
role = "controller+worker"
no_taints = true
install_flags = [
"--enable-k0s-cloud-provider=true",
"--enable-cloud-provider=true"
]
ssh = {
address = var.vm_address
port = 22
user = var.vm_user
key_path = var.ssh_key_path
}
},
]
config = file("${path.module}/k0s.config.yaml")
}
resource "local_file" "private_key" {
content = k0s_cluster.k0s.kubeconfig
filename = var.kubeconfig_path
depends_on = [k0s_cluster.k0s]
}
output "kubeconfig" {
sensitive = true
value = k0s_cluster.k0s.kubeconfig
}
output "kubeconfig_file" {
sensitive = true
value = var.kubeconfig_path
depends_on = [local_file.private_key]
}# Пример развёртки собственного легкого registry для образов приложения.
# https://artifacthub.io/packages/helm/twuni/docker-registry
# values.yaml - https://artifacthub.io/packages/helm/twuni/docker-registry?modal=values
resource "helm_release" "registry" {
name = "twuni-registry"
repository = "https://helm.twun.io"
chart = "docker-registry"
create_namespace = true
values = [
templatefile("${path.module}/registry/values.yaml",
{
htpasswd = "${var.registry.htpasswd}"
host = "registry.${var.domain}"
})
]
}Вместо заключения
Итак, werf выручил меня с Kubernetes. Он не только помог быстро поднять всё на моей крошечной виртуалке, но и с секретами теперь полный порядок. При этом теперь есть согласованность кода между разными частями проекта. Если вы ищете инструмент для простого и предсказуемого процесса доставки приложений в Kubernetes в небольшой команде, рекомендую присмотреться к werf — он действительно облегчает жизнь разработчика и дарит чувство безопасности при выкатке изменений.
Если у вас будут вопросы по гибридной разработке, можете написать мне в Telegram, постараюсь ответить и помочь.
P. S.
Читайте также в нашем блоге: