Недавно мы публиковали статью про производительность Vault с разными бэкендами, а сегодня расскажем, как делать бэкапы — и снова на разных бэкендах: Consul, GCS (Google Cloud Storage), PostgreSQL и Raft.

Как известно, HashiCorp предоставляет нативный метод бэкапа только для одного бэкенда — Integrated Storage (Raft Cluster), представленного как GA в апреле прошлого года. В нем можно снять снапшот всего одним curl’ом и не беспокоиться о каких-либо нюансах.

В остальных же случаях придется выкручиваться самим, придумывая, как правильно реализовывать бэкап. Очевидно, что во время резервного копирования Vault часть данных может меняться, из-за чего мы рискуем получить некорректные данные. Поэтому важно искать пути для консистентного бэкапа.

Vault — Open Source-решение от HashiCorp для управления секретами. Его изначальная ориентированность на модульность и масштабируемость позволяет запускать как небольшой dev-сервер Vault на своем ноутбуке, так и полноценный HA-кластер для production-сред.

Начиная работать с Vault, мы задались двумя вопросами:

1. Какой бэкенд (т.е. место, где физически хранятся секреты; им может быть локальная файловая система или решение на основе реляционных БД и других хранилищ) использовать и что по этому поводу говорят сами авторы?

2. Какую производительность и нагрузку может выдержать выбранная нами архитектура?

По первому вопросу все сначала кажется предельно простым: HashiCorp рекомендует единственный правильный вариант — Consul. Не сказать, что удивительно, если знать/посмотреть на авторов этого продукта. А вот со вторым вопросом все сложнее. Но почему в принципе нас это волновало?