Показать HN: Мы перешли с AWS на Hetzner, сэкономили 90%, сохранили ISO 27001 с Ansible ( medium.com/accounts_73078 ). Ранее в этом году я руководил нашей миграцией с AWS в европейское облако (Hetzner + OVHcloud), что было обусловлено затратами (мы сократили 90%) и суверенитетом данных (вопросы GDPR + CLOUD Act).
Мы самостоятельно перестроили ключевые функции AWS, используя Terraform для предоставления VPS и Ansible для всего: от усиления защиты (auditd, ufw, политики SSH) до непрерывных развертываний (с интеграцией Cloudflare). Наша настройка Prometheus + Alertmanager + Blackbox отслеживает инфраструктуру, приложения и истечение срока действия SSL с оповещениями, соответствующими стандарту ISO 27001. Loki + Grafana Agent обрабатывает журналы в объектном хранилище, совместимом с S3.
В стек входят: • Роли Ansible для PostgreSQL (с автоматизированным резервным копированием s3cmd + метрики Prometheus) • Задачи по усилению защиты (правила аудита, UFW, блокировка SSH, Chrony для синхронизации часов) • Развертывание веб-приложений с откатом + очистка Cloudflare • Полный мониторинг с Prometheus, Alertmanager, Grafana Agent, Loki и экспортерами • Автоматизация TLS через Certbot в Docker + Ansible
Я описал архитектуру, проблемы и извлеченные уроки: https://medium.com/@accounts_73078/goodbye-aws-how-we-kept-i…
Я с радостью поделюсь идеями, схемами или фрагментами, если людям это интересно, или отвечу на вопросы о подводных камнях, соответствии требованиям или моделировании затрат.
Я думаю, что наиболее часто упоминаемые проблемы — это загрязнение адресов Hetzner подозрительными людьми (можно решить с помощью «выходов» из AWS / Cloudflare), и вы работаете на оборудовании, которое имеет тенденцию выходить из строя / требует обновлений. Были ли какие-то опасения по этому поводу с вашей стороны?
И еще, Локи! Как вы справляетесь с нехваткой памяти в Loki Reader для этих надоедливых дальних запросов, и есть ли альтернативы?
Загрязнение: Мы передаем все, что видит пользователь, через Cloudflare, поэтому внешние пользователи (и боты) не взаимодействуют напрямую с нашими IP-адресами Hetzner/OVH. Мы блокируем наши IP-адреса на брандмауэре (ufw + Cloudflare IP allowlisting), поэтому только доверенные источники могут подключаться на уровне L4.
Сбои/обновления: Мы предоставляем услуги с помощью Terraform, поэтому развертывание замен или добавление емкости происходит быстро и детерминировано.
Мы отслеживаем метрики оборудования через Prometheus и экспортер узлов, чтобы получать ранние предупреждения. Пока (за 9 месяцев) не было сбоев оборудования, но это риск, который мы компенсируем с помощью этой автоматизации + дизайна.
Приложения в основном не содержат данных, и у нас есть (часто тестируемое) аварийное восстановление для базы данных.
Локи: Мы справляемся с нехваткой памяти,
• Различение пределов удержания и удержания индекса
• Настройка параллелизма запросов и максимального использования памяти с помощью конфигурации Loki + ограничений ресурсов systemd.
• Используйте метки в стиле Promtail + структурированное ведение журнала, чтобы запросы могли фильтровать на ранних этапах, а не выполнять регулярное выражение для всего содержимого журнала.
• Там, где нам нужен действительно глубокий поиск по истории, мы перекладываем нагрузку на инструменты доступа к хранилищу объектов или простую команду grep резервных копий — мы рассматриваем Loki как операционные журналы + nearline, а не как поисковую систему архивов.
Спасибо за подробный ответ! Похоже, вы в какой-то степени платформизировали себя(!), вы не думали о том, чтобы полностью перейти на k8s поверх железа (их машин), чтобы компенсировать некоторые опасения по поводу оборудования?
Хорошей альтернативой Loki является Victoria. Популярный, гораздо более производительный и авторитетный, но мы выбрали Loki из-за относительного размера и разнообразия сопровождающих в двух проектах. Ваши замечания очень обоснованы, и мы обошли это, как указано выше.
https://en.wikipedia.org/wiki/Атака_Сибиллы
Одним из преимуществ более дорогих провайдеров, по-видимому, является их хорошая репутация благодаря фактическому механизму PoW.
Зависит от варианта использования, верно? Я не принимаю трафик со случайных IP-адресов Hetzner — разрешены только IP-адреса Cloudflare.
Единственный потенциальный косвенный риск — это если ваш диапазон IP-адресов Hetzner VPS попадет в черный список (поскольку некоторые клиенты Hetzner используют его для атак Сивиллы или спама).
Или если инфраструктура Hetzner подверглась серьезному злоупотреблению, их восходящие или внутренние сети могли бы (теоретически) столкнуться с перегрузкой или проблемами с репутацией IP, но это вряд ли повлияет на производительность вашего индивидуального VPS.
Это зависит от того, что вы делаете в Hetzner и как вы ограничиваете доступ, но для корпоративного приложения, сертифицированного по ISO-27001, я считаю, что это крайне маловероятно.
Может быть интересно, но, похоже, не является допустимым «Показать HN»
* – https://news.ycombinator.com/showhn.html
Я думаю, было бы неплохо, если бы существовал европейский CloudFlare.
Да, было бы неплохо. Учитывая, что Cloudflare по какой-то причине ориентирован на разработчиков, я не против его сохранить.
То же самое, но Azure. Сэкономлено около 90%, с очень похожим стеком.
Это большая игра в облаке, которая заставляет предприятия полагаться на компетентность в своих странных абстракциях сервисов, что постепенно истощает довольно простую историю операций, которая обычно нужна предприятию.
Source: news.ycombinator.com