Расскажу, как в целом выглядит моя инфра.

Будет несколько диаграмм с пояснениями и ссылки на инструменты, которыми пользуюсь.

Общая картина

На данный момент, у меня есть публичный сервис - этот блог, и он обслуживается в CloudFlare.

Также у меня есть различные приватные сервисы. Они могут жить в разных локациях, доступ к ним осуществляется через отдельный gateway-хост в отдельной локации.

В целом, оно всё выглядит так:

graph LR client owner github subgraph DNS domain[agrrh.com] subdomains[*.agrrh.com] end subgraph CloudFlare cf-pages end subgraph DC Foo gateway end subgraph DC Bar bar-worker[worker] end github -.-> cf-pages github -.-> bar-worker owner -.-> github gateway -->|vpn| bar-worker client --> domain --> cf-pages client --> subdomains --> gateway

Видно, что если упадет DC с gateway-ем, то всё превратится в тыкву, но этот ресурс описан в IaC-подходе и, при необходимости, легко дублируется в любой другой локации.

  • К даунтайму и recovery-работам я морально готов
  • Счета за ИТ-ландшафт сопоставимы со счетами за электричество

И в этом прелесть SRE-подхода, который не топит за девятки любой ценой, а старается дать нужный уровень отказоустойчивости за оптимальную цену.

Про блог

Как я уже сказал, блог работает в CloudFlare, а точнее на CloudFlare Pages.

Это такая JAMstack площадка, которая позволяет бесплатно хостить ваши HTML-странички и JS-код.

Кстати, домен тоже хостит CloudFlare.

Обновляется же контент при помощи GitHub Actions.

Как это происходит:

graph LR author client subgraph GitHub git-repo[agrrh/agrrh.com] actions[GitHub Actions] end subgraph CloudFlare domain[agrrh.com] cf-pages[CF Pages] end author -.->|update| git-repo -.->|trigger| actions -.->|deploy| cf-pages client --> domain --> cf-pages

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

  1. Я пишу статью в Markdown в любими текстовом редакторе.

    Локально смотрю, как оно выглядит, через hugo serve

  2. Когда мне нравится результат, то я коммичу изменения в репозиторий.

  3. GitHub по пушу в master-ветку запускает CI-процесс.

    Там бложик собирается в набор статичных HTML, JS, CSS (и XML) файлов и выкатывается в CloudFlare Pages.

Конечно, есть лаг в 1-2 минуты между внесением правок и моментом, когда изменения видны в браузере, но это комфортное время.

Про gateway-хост и сетевой доступ

Для доступа к площадкам я использую wireguard, про который все наверное уже в курсе, что он бодрее OpenVPN и прочих IPSec-ов.

Соответственно, если запросы извне должны попасть на какую-то мою виртуалку, то они проходят через gateway-хост и далее, по нужному туннелю, приезжают в нужный сервер.

В качестве балансировщика я использую Traefik.

На конечном хосте обычно какой-нибудь Kubernetes, ну или хотя бы какой-то игрушечный его вариант, если это домашний стенд для поиграться.

Если вы тоже хотите игрушечный Kubernetes, то предлагаю пощупать:

Трафик, получается, ходит таким образом:

graph LR client subgraph DC Foo traefik end subgraph DC Bar worker end client --> traefik -->|wireguard| worker

Wildcard TLS-сертификаты выписываются на gateway-хосте, соответственно.

Пример устройства конечного хоста

Как я уже сказал, обычно конечный хост – это какой-нибудь Kubernetes Worker.

Для управления конфигурацией сервисов я использую ArgoCD.

Кстати, ещё можно потыкать Google Config Sync, он очень крут в ситуации, когда вы хотите построить IT-платформу.

До FluxCD мои руки пока не дошли, но пацаны тоже хвалят.

Так как есть центральный инструмент для управления конфигурациями, то прцоессы на ноде сводятся к чему-то подобному:

  • Я пишу Application-манифест и коммичу его в репозиторий
  • ArgoCD видит изменения и разворачивает нужный сервис
  • Трафик через Ingress ходит в этот сервис
  • Сам сервис ходит туда, куда ему надо

Выглядит это так:

graph LR client external-services subgraph Config git end subgraph Kubernetes argocd ingress service-a service-b database[(database)] end client --> ingress --> service-a git -.-|sync| argocd argocd -.- ingress argocd -.- service-a argocd -.- service-b service-a & service-b --> database service-b --> external-services

Про надежность, наблюдаемость и прочее хорошее

А всего этого здесь нет, кря. 🦆

На самом деле, мне очень нравится копаться в метриках, проверять какие-то гипотезы и делать выводы.

Но надо признать, что всё описанное выше - это окружение-песочница.

Оно и нужно-то, чтобы было где развернуть новый прикольный сервис, и сколько-нибудь существенной нагрузки тут нет.

Пространство, чтобы упарываться в SRE-практики, надо искать не здесь.

Кстати!

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

Это был Nomad-кластер, живущий на трех континентах. Все ноды были free-tier от разных провайдеров, и периодически отваливались.

Но оно работало, а я получил тонну опыта и удовольствия.

В общем, всё отвалившееся здесь, я чиню в ручном режиме, по мере необходимости.

А метриками когда-нибудь хочу обложиться, да.