Иногда я ненавижу self-hosting: реальные проблемы и их решения
Самостоятельное размещение сервисов дома привлекает многих, но имеет свои подводные камни. В этом руководстве разберем основные разочарования в self-hosting и как с ними справиться.
Сложность настройки и обслуживания
При self-hosting вы несете полную ответственность за настройку и обслуживание каждого компонента стека. Каждое приложение требует индивидуального подхода к настройке, что может отнимать значительное время.
docker run -d
--name my-service
--restart unless-stopped
-p 8080:80
-v /data:/app/data
my-image:latestПроблемы с обновлениями
Обновления в самостоятельном хостинге — это не всегда просто нажатие кнопки 'обновить'. Проблемы могут возникать на любом этапе: во время подготовки к обновлению, непосредственно в процессе или после завершения.
docker service update --image myapp:2.0 --update-parallelism 1 --update-delay 10s myappУправление ресурсами
Расчет необходимых ресурсов — сложная задача. Неправильная оценка приводит либо к перерасходу средств на избыточные ресурсы, либо к плохой производительности сервисов.
docker run -d
--name my-service
--memory="512m"
--cpus="1.5"
my-image:latestОбновления безопасности
Вам самостоятельно придется отслеживать и применять патчи безопасности. Пропуск обновлений безопасности может привести к компрометации системы.
trivy image my-image:latestКонфигурация файрволов
Настройка файрволов и правил доступа — сложная и ответственная задача. Неправильная конфигурация может заблокировать доступ к сервисам или оставить систему уязвимой.
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow ssh
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enableУправление бэкапами
Самостоятельное создание и хранение резервных копий — отдельный вызов. Восстановление после сбоя может быть не таким простым, как в облачных сервисах.
borg init --encryption=repokey /path/to/repo
borg create /path/to/repo::backup-$(date +%Y-%m-%d) /path/to/backup
borg list /path/to/repoМасштабирование
Масштабирование self-hosted решений требует значительных усилий. Горизонтальное масштабирование требует не только настройки ПО, но и часто дополнительного оборудования.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: myapp-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: myapp
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70Альтернативы self-hosting
Иногда проще и надежнее использовать готовые облачные решения, а self-hosting применять только там, где это действительно оправдано.
rclone sync /local/folder remote:cloud-folder --progress