https://setka.ru/posts/019cf7c6-f574-7bc3-b9ea-4d00da51a50a Глава вторая, те же, там же. В ссылке выше были описаны идеи и планы реализаций. Здесь же будет уже конкретика и точное описание того, что будет использовано, как и для чего. Стоит помнить, что все инструменты свободны в распространении и бесплатны. Все скрипты и файлы конфигураций доступны в Github и вы можете поднять такую же инфраструктуру для своих проектов. Данную схему я проектировал соло, имея двух миддлов на подхвате, которые выполняли уже четко описанные задачи. Проектировал по ранее полученному опыту системного администратора, прочитанным материалам и логике. Первым этапом стал роутинг. Роутинг сервисов обслуги и сервисов бизнеса. Роутинг сервисов был обозначен как North-South и весь трафик север-юг роутился по поддоменам и занимался этим Caddy. Caddy написан на Go, достаточно шустрый чтобы служить нам шлюзом. Шлюз смотрел на поддомены и отправлял трафик по назначению. Поддомены: cnsl-consul, nmd-nomad, vlt-vault, s3 и minio-наш cdn, registry-наше хранилище артефактов, tmc-teamcity. По всем роутам отзывались, соответственно сервисы администрирования, доступ по сокетным парам отрезали iptables, а позже пришлось дополнительно прятаться за CF. Проектируя инфру, я понимал, что я не затащу сюда Kuber, с которым у меня уже был определенный опыт. Для проекта такого масштаба K8 будет не то что оверинжинирингом, а выглядеть как, "когда у меня в руках молоток, все очень похоже на гвоздь". Но тем не менее оркестратор был нужен, мониторинг, health check, failover, единообразный запуск, перезапуск, остановка, scaling (желательно) и желательно чтобы это было максимально автоматически, а базовые действия были доступны менеджерам, без участия разработчиков. Выбор пал на Nomad. Он отвечает всем вышеперечисленным требованиям и достаточно легкий в плане ресурсов. Сделал связку классическую из набора HashiCorp. В Consul разбил инфраструктуру на data centers, таким образом сервера и клиенты кластeров Nomad всегда были связаны только с одним окружением и запускали сервисы только отмеченные суффиксом и описаны конфигом, сообщающим, на которую ноду (клиент Nomad) поедет сервис (East | West). Там же определялись выделяемые ресурсы, которые будут доступны в ноде. И это тоже регулировалось в дашборде, не привлекая разработчиков. Запуск, перезапуск, остановка, миграция по регионам. Consul помимо обязанностей Service Dicsovery и мониторинга состояний кластеров, использовался так же как KeyValue хранилище. В предыдущих сервисах местами был нужен Redis и он везде был заменен на Consul. Полная связка инструментов HashiCorp выглядит как: Кластеры Nomad, поделенные на регионы под управлением Consul, разделяющий кластеры на датацентры по типу окружения, хранящий данные клиентов и секретов Vault. Сервисы предсказуемо запущены и имеют мониторинг состояния. Секреты хранятся в Vault и в неактивном состоянии находятся в зашифрованном виде. Все сервисы собираются налету из шаблона докер и отправляются в Nexus, и где хранятся согласно суффикса артефакта. Python или Debian пакеты, и Docker образы. Все это дело максимально автоматизировано с тем, что у юзера минимум шансов сделать то, что он делает чаще и лучше всего - затупить. И я снова почти уперся в лимит сетки и расказать про процессы мне придется уже в третьей главе. Но. Давайте вы скажете, нужна она, эта глава? Или я работаю в стол, так я не хочу :( Крч, комментарии!