Как получить работоспособный vault

Репозиторий позволит вам получить полностью работоспособный vault в режиме HA, с бэкэндом для etcd, также в режиме HA. С одной стороны, эта среда является чисто экспериментальной и ни в коем случае не должна использоваться в проде. С другой стороны, он развертывает вам vault точно так, как оно должно быть в проде: по крайней мере, 3 узла кластера для соответствия требованиям affinity во имя отказоустойчивости. Вы можете использовать данный стенд, чтобы практиковать любые упражнения с vault, включая и стресс-шатание с выключением nod и контролем того, как он будет себя вести.

Как получить работоспособный  vault

Disclaimer

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

  1. playbooks написаны на скорую руку и не отлажены в prod среде.
  2. etcd развернут без использования PVC. данные хранятся локально на серверах, что не совсем правильно с точки зрения их сохранности.
  3. k8s кластер развернут с доработками под vagrant, и вообще вы должны все-таки сами писать свои плейбуки для разворачивания кластера, иначе как вы потом будете его дебажить и обслуживать?
  4. k8s кластер развернут в 1-мастеровом исполнении, что как бы тоже не особо хорошо с точки зрения отказоустойчивости
  5. 21 версия куба последняя в которой можно использовать версию v1beta1 для ingress (сейчас актуальная 20-я), с 22 версии это просто выкинут, т.е. примерно через пол-года: Warning: extensions/v1beta1 Ingress is deprecated in v1.14+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress. Официальный чарт волта под это просто не готов. Кроме того в скором времени k8s будет отказываться от docker в качестве container runtime. Поэтому (ну и ряду других причин) тут используется версия кластера 1.19.*; Это надо изучать и понимать о чем идет речь прежде чем принимать данный репозиторий за истину и повторять это на продакшене. Возможно я сделаю новую ветку с доработками под 22+ версию куба, когда она выйдет. Но это не точно. Удачного обучения!

Структура:

  1. vagrant — оркестратор виртуальных машин, его задача — поднять 4 ВМ, запустить ансибл и пробросить порт
  2. ansible — инструмент для установки и настройки компонент 3,4,5.
  3. docker — используется в качестве container runtime в k8s
  4. kubernetes — оркестратор контейнеров
  5. helm — пакетный менеджер в k8s. используется для установки компонент 6,7,8.
  6. etcd — база данных в кластерном отказоустойчивом режиме для хранения данных vault
  7. nginx ingress — веб сервер и контроллер для обеспечения доступа к vault по веб-интерфейсу
  8. vault — распределенное отказоустойчивое хранилище секретов

Requirements

Предупреждение, относящееся ко всем пунктам касательно установки софта: СТАВЬТЕ ТОЛЬКО АКТУАЛЬНЫЕ ВЕРСИИ С ОФИЦИАЛЬНЫХ САЙТОВ

Это важно, потому что в репозиториях убунты\дебиана находятся сильно устаревшие пакеты и вагрант из «apt-get» не будет работать с последней версией virtulabox. Могут также не сработать какие-то автоматизации или указания параметров, потому что «хз почему», вы только потеряете время на то, чтобы разобраться что не работает.

Я тестировал стенд на версиях vbox 6.1.18, vagrant 2.2.14, ansible 2.10.*

Для запуска стенда вам необходимо:

  • ОС linux/Macos. Для windows запустить стенд реально, с некоторыми танцами с бубном (на самом деле ничего сложного), но у меня нет возможности это проверить.
  • Не менее 8 ядрер процессора и не менее 8 Гб оперативной памяти. Эти настройки вы можете подкрутить в Vagrantfile. Но те что сейчас установлены — минимально необходимые (они же комфортные). Если у вас совсем прям все плохо по памяти, разворачивайте по 1 ноде, изменяя значение N в Vagrantfile и выполняя vagrant up --provision. Будет очень долго, но возможно сработает.
  • Virtualbox — качаем версию с официального сайта (для macos можно взять из brew).
  • Vagrant — качаем версию с официального сайта (для macos можно взять из brew).
  • Ansible — можно установить через pip (mac, linux) — предпочтительный вариант. Но в целом хватит и версии из репозиториев linux/brew.

Запуск стенда

Часть 1 (10-30 минут)

  1. склонировать себе репозиторий и перейти в него
  2. vagrant up # это действие поднимет вам всю инфраструктуру — оно может выполняться до 10-20 минут, в зависимости от железа и вашей скорости интернета.

Если вы видите следующую картинку, значит стенд был успешно развернут (failed=0). В случае неудачи разрешается начать вторую попытку развернуть стенд с помощью команды vagrant up —provision. Эта автоматизация идемпотентна и позволяет запускать очередь стенда любое количество раз, включая прерывание в любом месте (кроме, возможно, установки пакетов, тогда вам придется удалять файлы .lock ручками).

PLAY RECAP *********************************************************************
master                     : ok=35   changed=27   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
node-1                     : ok=13   changed=11   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
node-2                     : ok=13   changed=11   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
node-3                     : ok=13   changed=11   unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Часть 2 (5 минут)

После того как кластер установился вам необходимо выполнить первичную инициализацию vault

  1. Добавьте себе в /etc/hosts на основной ОС следующую строку: 127.0.0.1 vault.local
  2. (находясь в папке с проектом) vagrant ssh master
  3. sudo su
  4. kubectl -n vault exec -ti vault-0 sh
  5. vault operator init # вы получите 5 Unseal key и Initial Root Token. Сохраните их для дальнейшей работы со стендом!
  6. exit

Далее нам необходимо распечатать хранилище. Сделать это нужно в каждом из 3 контейнеров введя в каждом из них 3 раза Unseal key. У вас всего 5 ключей, для распечатывания достаточно любые 3. Ключи для одного контейнера должны быть разными, но вполне можно использовать одни и те же для распечатывания в разных контейнеров. Далее пример для vault-0, то же самое надо сделать для vault-1 и vault-2:

kubectl -n vault exec -ti vault-0 sh
vault operator unseal # ввести любой из Unseal key
vault operator unseal # ввести любой из Unseal key, кроме введенного на предыдущем шаге
vault operator unseal # ввести любой из Unseal key, кроме введенного на предыдущих шагах
# если после 3 операции мы увидели "Sealed false", считаем что для данного контейнера все готово, можно выходить
exit

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

Проверка что всё работает

  1. находясь на master-машине выполнить kubectl -n vault get po результат должен быть вот таким:
NAME                                    READY   STATUS    RESTARTS   AGE
etcd-vault-0                            1/1     Running   0          37m
etcd-vault-1                            1/1     Running   0          37m
etcd-vault-2                            1/1     Running   0          37m
vault-0                                 1/1     Running   2          37m
vault-1                                 1/1     Running   2          37m
vault-2                                 1/1     Running   2          37m
vault-agent-injector-784ccfc788-ltdt4   1/1     Running   0          37m
  1. Открыть браузер на основной ОС и ввести в адресную строку: vault.local:8080. В открывшейся странице ввести в качестве пароля root token. Если вас успешно авторизовало — стенд готов к работе.

Дополнительные материалы

Примеры полученных unseal key & root token

Unseal Key 1: OgDmp2lipCFAgXKZGkZa68AAAdw/B/AfNJroNQ5dzd+3
Unseal Key 2: lmuvE4FmdsCMKNBfg3sBhV5FeoyaaoC6WOfZRvHwgLPo
Unseal Key 3: 6n1IAYi5dRd0rYk1Vw7hOmdDKJhLH358EOsAO2iarhGP
Unseal Key 4: LaAk70GkOHo/gKWqBVSJq2o1f6LV2zuo/Aj+5qrIz4m6
Unseal Key 5: 4yfNK2VqJxTJd80g9I6FoNkpL+Zko62TUrKd355rRub2

Initial Root Token: s.Gr89FEDaONFk4o6rE52BBKuZ

Если будет ругаться в логах на то что не может достучаться до 10.96…

Выполнить на всех нодах:

systemctl stop kubelet
systemctl stop docker
iptables --flush
iptables -tnat --flush
systemctl start kubelet
systemctl start docker

Поскольку etcd сильно зависит от задержек ввода-вывода, целесообразно использовать SSD-диски в качестве хранилища.

Click to rate this post!
[Total: 2 Average: 5]

Leave a reply:

Your email address will not be published.