Comments 15
Кстати, коллеги, заберите еще саму архитектурную диаграмму для draw.io - https://drive.google.com/file/d/1Nq9JfDMtppRNA-fh46pyHextfX1SlgfM/view?usp=sharing
Пригодится, если будете в документации описывать что-то похожее у себя.
Не думали просто постгрю взять в качестве backend?
Нет, а в чем целесообразность? Для Vault все равно нужно зашифрованное key-value хранилище, которое будет служить бэкендом. Raft-протокол тут подходит как нельзя лучше. Плюс, с использованием интегрированного хранилища количество точек отказа уменьшается до одного бинарника, по сути.
PostgreSQL тут будет дополнительной сущностью, которую тоже нужно обслуживать.
- name: Copy the certificates to the vault config dir for the first time
shell: |
rsync -L /etc/letsencrypt/live/{{ inventory_hostname }}/privkey.pem /etc/vault.d/privkey.pem
rsync -L /etc/letsencrypt/live/{{ inventory_hostname }}/fullchain.pem /etc/vault.d/fullchain.pem
chown vault:vault /etc/vault.d/privkey.pem
chown vault:vault /etc/vault.d/fullchain.pem
pkill -SIGHUP vault
args:
creates: /etc/vault.d/fullchain.pemЗачем тут этот башсибл? Что мешало нормальный модуль copy использовать?
В этой части мануала я предполагаю, что у вас уже есть мастер-образ, на базе которого вы разворачиваете ВМ. Мы для этих целей используем Packer от тех же Hashicorp, чтобы подготовить Oracle Linux с нашими публичными ключами и системными пользователями, от имени которых будет работать Ansible.
Если все равно делаете образы, то почему сразу туда Vault с необходимыми настройками не запечь? Какой смысл поднимать из образа голый линукс, а потом накатывать на него плейбук для разворачивания Vault? Получается лишняя потеря времени на поднятие кластера. И инфраструктура получается не иммутабельная.
У нас исторически так сложилось. Ванильный золотой образ с минимальными изменениями, а все остальное уже описано Ansible. Мы думали над подходом с запеканием готовых образов, но в итоге все равно будет нужно выкатывать плейбуки, чтобы внести минимальные изменения, поправить конфигурацию, обновить версии пакетов на актуальные.
Для некоторых систем мы это используем.
Пересобирать образ каждый раз не всегда удобно, хотя и дает "замороженную" версию узла. Но да, такой подход тоже возможен.
Кстати, а как вы обновляете кластер при таком подходе? Сносите весь кластер, поднимаете с нуля новой версией кода, а потом восстанавливаете данные из бэкапа?
Нет, не сносим. Обновление идёт в соответствии с рекомендациями вендора.
Начинаем с текстового кластера. Так как он является репликой, то он сразу же позволяет нам провести интеграционное тестирование на том уровне, который требуется заказчику.
После того, как мы убедились в отсутствии регрессий, обновляем продуктивный кластер. Обычно это поэтапное обновление по одной ноде в роли follower с лидером в самом конце. Всё это, конечно, под прикрытием снапшотов на случай, если что-то пойдет не так.
Zero-downtime с Vault невозможен, но в нормальной ситуации переключение занимает сотни миллисекунд.
Если вы проводите обновление путем накатки плейбука и обновления пакетов наживую, то по факту у вас получаются не эквивалентные образы. Различие точно будет набегать между тестовой версией и продакшеном, и даже между нодами одного кластера может со временем набежать заметная разница в конфигурации тех же пакетов и библиотек.
Соглашусь отчасти. Но ключевые пакеты имеют фиксированную версию, как тот же Vault. Конфигурация у них будет идентичной. Единственная разница, которая может появиться между средами - версии второстепенных пакетов, которые могли получить мелкое обновление между двумя циклами обновлений. Это не критично.
Но я понимаю вашу мысль насчёт immutable infrastructure. Это тоже отличный подход и один из вариантов.
После восстановлении снапшота на резервном кластере Vault на нём распечатываете?
Hashicorp Vault — собираем непрямую репликацию через ведро