[Системное администрирование, Системное программирование, DevOps] Режим высокой доступности HashiCorp Vault (HA) (перевод)
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
Hashicorp Vault — open-source инструмент для управления секретами (пароли, ключи API и т.д.),
Vault может работать в режиме высокой доступности (HA) для защиты от сбоев за счет запуска нескольких серверов Vault. Vault обычно ограничивается пределами операций ввода-вывода серверной части Vault, а не требованиями к вычислениям. Некоторые серверные модули хранения, например Consul, предоставляют дополнительные функции координации, которые позволяют Vault работать в конфигурации высокой доступности, в то время как другие обеспечивают более надежный процесс резервного копирования и восстановления.
При работе в режиме высокой доступности серверы Vault имеют два дополнительных состояния: резервное и активное. В кластере Vault активным будет только один экземпляр, который будет обрабатывать все запросы (чтение и запись), а все резервные узлы перенаправляют запросы на активный узел.
ПРИМЕЧАНИЕ. Начиная с версии 0.11, эти резервные узлы могут обрабатывать большинство запросов только для чтения и вести себя как узлы реплики для чтения. Эта функция Performance Standby Nodes включена в Vault Enterprise Premium, а также доступна для Vault Enterprise Pro за дополнительную плату. Это особенно полезно для обработки больших объемов запросов. Прочтите документацию по рабочим узлам и руководство для получения более подробной информации.
Это руководство проведет вас через простую реализацию кластера Vault Highly Available (HA). Хотя это не исчерпывающее или предписывающее руководство, которое можно использовать в качестве примера прямого подключения, оно охватывает основы, достаточные для информирования вашей собственной производственной установки.
Примерное время на выполнение
25 минут
Предпосылки
Это промежуточное руководство по работе с Vault предполагает, что у вас есть практические знания о Vault и Consul.
Шаги
Наша цель в этом руководстве, — настроить Vault HA, состоящий из:
· 2 серверов Vault: 1 активный и 1 резервный
· Кластер из 3-х серверов Consul
Справочная диаграмма
На этой диаграмме для справки показаны простые детали архитектуры:
Мы будем выполнять эти шаги:
- Шаг 1. Настройка кластера серверов Consul
- Шаг 2. Запуск и проверка состояния кластера Consul
- Шаг 3. Настройка клиентских агентов Consul на узлах Vault
- Шаг 4. Настройка серверов Vault
- Шаг 5. Запуск Vault и его проверка
Для реализации целей этого руководства мы будем использовать программное обеспечение с открытым исходным кодом Vault и Consul; настройка будет аналогична для версии Enterprise.
Шаг 1. Настройка кластера серверов Consul
Наши серверы Consul в этом руководстве будут определяться только IP-адресом, но также обозначены меткой:
- consul_s1: 10.1.42.101
- consul_s2: 10.1.42.102
- consul_s3: 10.1.42.103
Двоичный файл Consul находится в /usr/local/bin/consul, но если в вашем случае не так, вы можете соответствующим образом изменить ссылки на пути.
Имея это в виду, вот начальная точка базовой конфигурации сервера Consul:
{
"server": true,
"node_name": "$NODE_NAME",
"datacenter": "dc1",
"data_dir": "$CONSUL_DATA_PATH",
"bind_addr": "0.0.0.0",
"client_addr": "0.0.0.0",
"advertise_addr": "$ADVERTISE_ADDR",
"bootstrap_expect": 3,
"retry_join": ["$JOIN1", "$JOIN2", "$JOIN3"],
"ui": true,
"log_level": "DEBUG",
"enable_syslog": true,
"acl_enforce_version_8": false
}
Обратите внимание, что некоторые значения содержат заполнители переменных, а остальные имеют разумные значения по умолчанию. Вы должны заменить следующие значения в вашей конфигурации сервера Consul на основе примера:
- $NODE_NAME — это уникальная метка для узла; в нашем случае это будут consul_s1, consul_s2 и consul_s3 соответственно.
- $CONSUL_DATA_PATH: абсолютный путь к каталогу данных Consul; убедитесь, что этот каталог доступен для записи пользователю процесса Consul.
- $ADVERTISE_ADDR: задает адрес, чтобы серверы Consul объявляли другим серверам в кластере. Не должно быть установлено в 0.0.0.0; для этого руководства он должен быть установлен на IP-адрес сервера Consul в каждом экземпляре файла конфигурации или 10.1.42.101,10.1.42.102 и 10.1.42.103 соответственно.
- $JOIN1, $JOIN2, $JOIN3: в этом примере используется метод retry_join для присоединения агентов сервера к формированию кластера; Таким образом, значения для этого руководства будут 10.1.42.101, 10.1.42.102 и 10.1.42.103 соответственно.
Обратите внимание, что веб-интерфейс пользователя включен ("ui": true), и Consul будет вести журнал на уровне DEBUG в системный журнал ("log_level": "DEBUG"). Для целей этого руководства acl_enforce_version_8 установлено в false, поэтому нам не нужно беспокоиться о списках ACL в этом руководстве. Тем не менее, вы могли бы включить списки ACL в производственной среде и следовать руководству Consul ACL.
Создайте файл конфигурации для каждого сервера Vault и сохраните его как /usr/local/etc/consul/client_agent.json.
Пример consul_s1.json
{
"server": true,
"node_name": "consul_s1",
"datacenter": "dc1",
"data_dir": "/var/consul/data",
"bind_addr": "0.0.0.0",
"client_addr": "0.0.0.0",
"advertise_addr": "10.1.42.101",
"bootstrap_expect": 3,
"retry_join": ["10.1.42.101", "10.1.42.102", "10.1.42.103"],
"ui": true,
"log_level": "DEBUG",
"enable_syslog": true,
"acl_enforce_version_8": false
}
Пример consul_s2.json
{
"server": true,
"node_name": "consul_s2",
"datacenter": "dc1",
"data_dir": "/var/consul/data",
"bind_addr": "0.0.0.0",
"client_addr": "0.0.0.0",
"advertise_addr": "10.1.42.102",
"bootstrap_expect": 3,
"retry_join": ["10.1.42.101", "10.1.42.102", "10.1.42.103"],
"ui": true,
"log_level": "DEBUG",
"enable_syslog": true,
"acl_enforce_version_8": false
}
Пример consul_s3.json
{
"server": true,
"node_name": "consul_s3",
"datacenter": "dc1",
"data_dir": "/var/consul/data",
"bind_addr": "0.0.0.0",
"client_addr": "0.0.0.0",
"advertise_addr": "10.1.42.103",
"bootstrap_expect": 3,
"retry_join": ["10.1.42.101", "10.1.42.102", "10.1.42.103"],
"ui": true,
"log_level": "DEBUG",
"enable_syslog": true,
"acl_enforce_version_8": false
}
Консул Сервер systemd
У вас есть двоичные файлы Consul и базовая конфигурация, и теперь вам просто нужно запустить Consul на каждом экземпляре сервера; systemd популярен в большинстве современных дистрибутивов Linux, поэтому, имея это в виду, вот пример файла systemd unit:
### BEGIN INIT INFO
# Provides: consul
# Required-Start: $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Consul agent
# Description: Consul service discovery framework
### END INIT INFO
[Unit]
Description=Consul server agent
Requires=network-online.target
After=network-online.target
[Service]
User=consul
Group=consul
PIDFile=/var/run/consul/consul.pid
PermissionsStartOnly=true
ExecStartPre=-/bin/mkdir -p /var/run/consul
ExecStartPre=/bin/chown -R consul:consul /var/run/consul
ExecStart=/usr/local/bin/consul agent \
-config-file=/usr/local/etc/consul/client_agent.json \
-pid-file=/var/run/consul/consul.pid
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
KillSignal=SIGTERM
Restart=on-failure
RestartSec=42s
[Install]
WantedBy=multi-user.target
Обратите внимание, что вас может заинтересовать изменение следующих значений в зависимости от стиля, стандартного уровня соблюдения иерархии файловой системы и т. Д. –
- config-file
- pid-file
После того как файл модуля определен и сохранен (например, /etc/systemd/system/consul.service), обязательно выполните перезагрузку демона systemctl daemon-reload, а затем вы можете запустить службу Consul на каждом сервере.
Шаг 2. Запуск и проверка состояния кластера Consul
Убедитесь, что права собственности и разрешения верны в каталоге, который вы указали для значения data_dir, а затем запустите службу Consul в каждой системе и проверьте статус:
$ sudo systemctl start consul
$ sudo systemctl status consul
● consul.service - Consul server agent
Loaded: loaded (/etc/systemd/system/consul.service; enabled; vendor preset: enabled)
Active: active (running) since Mon 2018-03-19 17:33:14 UTC; 24h ago
Main PID: 2068 (consul)
Tasks: 13
Memory: 13.6M
CPU: 0m 52.784s
CGroup: /system.slice/consul.service
└─2068 /usr/local/bin/consul agent -config-file=/usr/local/etc/consul/client_agent.json -pid-file=/var/run/consul/consul.pid
После запуска всех агентов сервера Consul, давайте проверим статус кластера Consul:
$consul members
Node Address Status Type Build Protocol DC Segment
consul_s1 10.1.42.101:8301 alive server 1.0.6 2 dc1 <all>
consul_s2 10.1.42.102:8301 alive server 1.0.6 2 dc1 <all>
consul_s3 10.1.42.103:8301 alive server 1.0.6 2 dc1 <all>
Кластер выглядит хорошо, показаны все 3 сервера; Прежде чем продолжить, убедитесь, что у нас есть лидер:
$consul operator raft list-peers
Node ID Address State Voter RaftProtocol
consul_s2 536b721f-645d-544a-c10d-85c2ca24e4e4 10.1.42.102:8300 follower true 3
consul_s1 e10ba554-a4f9-6a8c-f662-81c8bb2a04f5 10.1.42.101:8300 follower true 3
consul_s3 56370ec8-da25-e7dc-dfc6-bf5f27978a7a 10.1.42.103:8300 leader true 3
Приведенный выше вывод показывает, что consul_s3 является текущим лидером кластера в этом примере. Теперь вы можете перейти к настройке сервера Vault.
Шаг 3. Настройка клиентских агентов Consul на узлах Vault
Узлам сервера Vault требуются двоичные файлы Consul и Vault на каждом узле. Consul будет настроен как агент клиента, а Vault будет настроен как сервер.
Конфигурация агента клиента Consul
Поскольку Consul используется для обеспечения серверной части высокодоступного хранилища, вам необходимо настроить локальные клиентские агенты Consul на серверах Vault, которые будут взаимодействовать с кластером серверов Consul для регистрации проверок работоспособности, обнаружения служб и координации переключения HA кластера (лидерство кластера).
Обратите внимание, что не рекомендуется подключать серверы Vault напрямую к серверам Consul.
Агенты клиента Consul будут использовать тот же адрес, что и серверы Vault, для сетевой связи с кластером серверов Consul, но они будут связывать client_address только с интерфейсом обратной связи, так что Vault может подключиться к нему через интерфейс обратной связи.
Вот пример конфигурации для агента клиента Consul:
{
"server": false,
"datacenter": "dc1",
"node_name": "$NODE_NAME",
"data_dir": "$CONSUL_DATA_PATH",
"bind_addr": "$BIND_ADDR",
"client_addr": "127.0.0.1",
"retry_join": ["$JOIN1", "$JOIN2", "$JOIN3"],
"log_level": "DEBUG",
"enable_syslog": true,
"acl_enforce_version_8": false
}
Аналогично тому, что вы сделали на шаге 1, замените следующие значения в своей конфигурации агента клиента Consul соответственно:
- $NODE_NAME — это уникальная метка для узла; в нашем случае это будут consul_c1 и consul_c2 соответственно.
- $CONSUL_DATA_PATH: абсолютный путь к каталогу данных Consul; убедитесь, что этот каталог доступен для записи пользователю процесса Consul.
- $BIND_ADDR: это должно быть установлено на адрес, который вы предпочитаете, чтобы серверы Consul объявляли другим серверам в кластере, и не должно быть установлено на 0.0.0.0; в этом руководстве он должен быть установлен на IP-адрес сервера Vault в каждом экземпляре файла конфигурации или 10.1.42.201 и 10.1.42.202 соответственно.
- $JOIN1, $JOIN2, $JOIN3: в этом примере используется метод retry_join для присоединения агентов сервера для формирования кластера; Таким образом, значения для этого руководства будут 10.1.42.101, 10.1.42.102 и 10.1.42.103 соответственно.
Создайте файл конфигурации для каждого сервера Vault и сохраните его как /usr/local/etc/consul/client_agent.json.
Пример consul_c1.json
{
"server": false,
"datacenter": "dc1",
"node_name": "consul_c1",
"data_dir": "/var/consul/data",
"bind_addr": "10.1.42.201",
"client_addr": "127.0.0.1",
"retry_join": ["10.1.42.101", "10.1.42.102", "10.1.42.103"],
"log_level": "DEBUG",
"enable_syslog": true,
"acl_enforce_version_8": false
}
Пример consul_c2.json
{
"server": false,
"datacenter": "dc1",
"node_name": "consul_c2",
"data_dir": "/var/consul/data",
"bind_addr": "10.1.42.202",
"client_addr": "127.0.0.1",
"retry_join": ["10.1.42.101", "10.1.42.102", "10.1.42.103"],
"log_level": "DEBUG",
"enable_syslog": true,
"acl_enforce_version_8": false
}
systemd юнит файл Consul сервера
У вас есть двоичные файлы Consul и базовая конфигурация агента клиента, и теперь вам просто нужно запустить Consul на каждом из экземпляров сервера Vault. Вот пример файла модуля systemd:
### BEGIN INIT INFO
# Provides: consul
# Required-Start: $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Consul agent
# Description: Consul service discovery framework
### END INIT INFO
[Unit]
Description=Consul client agent
Requires=network-online.target
After=network-online.target
[Service]
User=consul
Group=consul
PIDFile=/var/run/consul/consul.pid
PermissionsStartOnly=true
ExecStartPre=-/bin/mkdir -p /var/run/consul
ExecStartPre=/bin/chown -R consul:consul /var/run/consul
ExecStart=/usr/local/bin/consul agent \
-config-file=/usr/local/etc/consul/client_agent.json \
-pid-file=/var/run/consul/consul.pid
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
KillSignal=SIGTERM
Restart=on-failure
RestartSec=42s
[Install]
WantedBy=multi-user.target
При необходимости измените следующие значения:
- -config-file
- -pid-file
После того как файл модуля определен и сохранен (например, /etc/systemd/system/consul.service), обязательно выполните перезагрузку демона systemctl daemon-reload, а затем вы можете запустить службу Consul на каждом сервере Vault.
Запустите Consul и проверьте его состояние кластера, чтобы убедиться, что права собственности и разрешения верны в каталоге, который вы указали для значения data_dir, а затем запустите службу Consul в каждой системе и проверьте статус:
$ sudo systemctl start consul
$ sudo systemctl status consul
● consul.service - Consul client agent
Loaded: loaded (/etc/systemd/system/consul.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2018-03-20 19:36:49 UTC; 6s ago
Main PID: 23758 (consul)
Tasks: 11
Memory: 9.8M
CPU: 571ms
CGroup: /system.slice/consul.service
└─23758 /usr/local/bin/consul agent -config-file=/usr/local/etc/consul/client_agent.json -pid-file=/var/run/consul/consul.pid
После запуска всех клиентских агентов Consul проверьте статус кластера Consul:
$consul members
Node Address Status Type Build Protocol DC Segment
consul_s1 10.1.42.101:8301 alive server 1.0.6 2 dc1 <all>
consul_s2 10.1.42.102:8301 alive server 1.0.6 2 dc1 <all>
consul_s3 10.1.42.103:8301 alive server 1.0.6 2 dc1 <all>
consul_c1 10.1.42.201:8301 alive client 1.0.6 2 arus <default>
consul_c2 10.1.42.202:8301 alive client 1.0.6 2 arus <default>
Приведенные выше выходные данные показывают 3 агента сервера Consul и 2 агента клиента Consul в кластере. Теперь вы можете настроить серверы Vault.
Шаг 4. Настройка серверов Vault
Теперь, когда у нас есть кластер Consul, состоящий из 3-х серверов и 2-х клиентских агентов для наших серверов Vault, давайте вместе получим конфигурацию для Vault и сценарий запуска, чтобы мы могли запустить настройку Vault HA.
Наши серверы Vault в этом руководстве определяются только IP-адресом, но также обозначаются меткой:
- vault_s1: 10.1.42.201
- vault_s2: 10.1.42.202
В нашем файле конфигурации мы настроим следующее:
- tcp listener
- consul storage backend
- Параметры высокой доступности
В этом разделе предполагается, что двоичный файл Vault находится в /usr/local/bin/vault.
Конфигурация Vault
listener "tcp" {
address = "0.0.0.0:8200"
cluster_address = "0.0.0.0:8201"
tls_disable = "true"
}
storage "consul" {
address = "127.0.0.1:8500"
path = "vault/"
}
api_addr = "$API_ADDR"
cluster_addr = "$CLUSTER_ADDR"
Мы устанавливаем следующие параметры для нашего tcp-слушателя:
- address ("127.0.0.1:8200") — указывает адрес, к которому нужно привязаться для прослушивания.
- cluster_address ("127.0.0.1:8201") — указывает адрес для привязки для запросов кластера сервер-сервер. По умолчанию это значение на один порт больше, чем значение адреса. Обычно это не требуется настраивать, но может быть полезно в случае, если серверы Vault изолированы друг от друга таким образом, что им нужно переключаться через балансировщик нагрузки TCP или какую-либо другую схему для разговора.
Эта конфигурация позволяет прослушивать все интерфейсы (например, так, чтобы команда Vault для адреса обратной связи была успешной).
Мы также устанавливаем параметры высокой доступности Vault (api_addr и cluster_addr). Чаще всего нет необходимости настраивать эти два параметра при использовании Consul в качестве серверной части хранилища Vault, поскольку Consul будет пытаться автоматически обнаруживать и объявлять адрес активного узла Vault. Однако для некоторых конфигураций кластера может потребоваться их явная установка (например, доступ к Vault через балансировщик нагрузки).
Для простоты предположим, что клиенты в нашем сценарии подключаются непосредственно к узлам Vault (а не через балансировщик нагрузки). Просмотрите документацию Client Redirection, чтобы получить дополнительную информацию о шаблонах доступа клиентов и их последствиях.
Обратите внимание, что некоторые значения содержат заполнители переменных, а остальные имеют разумные значения по умолчанию. Вы должны заменить следующие значения в конфигурации вашего собственного сервера Vault на основе примера:
- $API_ADDR: указывает адрес (полный URL) для объявления другим серверам Vault в кластере для перенаправления клиентов. Это также можно сделать с помощью переменной среды VAULT_API_ADDR. Как правило, это должен быть полный URL-адрес, указывающий на значение адреса слушателя. В нашем сценарии это будут http://10.1.42.201:8200 и http://10.1.42.202:8200 соответственно.
- $CLUSTER_ADDR: указывает адрес для объявления другим серверам Vault в кластере для пересылки запросов. Это также можно сделать с помощью переменной среды VAULT_CLUSTER_ADDR. Это полный URL, например api_addr. В нашем сценарии это будут https://10.1.42.201:8201 и https://10.1.42.202:8201 соответственно.
Обратите внимание, что схема здесь (https) игнорируется; все члены кластера всегда будут использовать TLS с закрытым ключом / сертификатом.
Пример vault_s1.hcl
listener "tcp" {
address = "0.0.0.0:8200"
cluster_address = "10.1.42.201:8201"
tls_disable = "true"
}
storage "consul" {
address = "127.0.0.1:8500"
path = "vault/"
}
api_addr = "http://10.1.42.201:8200"
cluster_addr = "https://10.1.42.201:8201"
Пример vault_s2.hcl
listener "tcp" {
address = "0.0.0.0:8200"
cluster_address = "10.1.42.202:8201"
tls_disable = "true"
}
storage "consul" {
address = "127.0.0.1:8500"
path = "vault/"
}
api_addr = "http://10.1.42.202:8200"
cluster_addr = "https://10.1.42.202:8201"
systemd юнит файл Vault сервера
У вас есть двоичные файлы Vault и базовая конфигурация вместе с настроенными локальными агентами клиента. Теперь вам просто нужно запустить Vault на каждом экземпляре сервера. Вот пример файла модуля systemd:
### BEGIN INIT INFO
# Provides: vault
# Required-Start: $local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Vault server
# Description: Vault secret management tool
### END INIT INFO
[Unit]
Description=Vault secret management tool
Requires=network-online.target
After=network-online.target
[Service]
User=vault
Group=vault
PIDFile=/var/run/vault/vault.pid
ExecStart=/usr/local/bin/vault server -config=/etc/vault/vault_server.hcl -log-level=debug
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
KillSignal=SIGTERM
Restart=on-failure
RestartSec=42s
LimitMEMLOCK=infinity
[Install]
WantedBy=multi-user.target
Обратите внимание, что вас может заинтересовать изменение следующих значений в зависимости от стиля, стандартного уровня соблюдения иерархии файловой системы и т. д.
- -config
- -log-level
Как только файл модуля определен и сохранен, например, /etc/systemd/system/vault.service, обязательно выполните перезагрузку демона systemctl daemon-reload, а затем вы можете запустить службу Vault на каждом сервере.
Шаг 5. Запуск Vault и его проверка
Запустите службу Vault в каждой системе и проверьте состояние:
$ sudo systemctl start vault
$ sudo systemctl status vault
● vault.service - Vault secret management tool
Loaded: loaded (/etc/systemd/system/vault.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2018-03-20 20:42:10 UTC; 42s ago
Main PID: 2080 (vault)
Tasks: 12
Memory: 71.7M
CPU: 50s
CGroup: /system.slice/vault.service
└─2080 /usr/local/bin/vault server -config=/home/ubuntu/vault_nano/config/vault_server.hcl -log-level=debu
Теперь вам нужно перейти к инициализации и распечатыванию каждого экземпляра Vault.
Как только это будет сделано, проверьте статус Vault на каждом из серверов.
Активный сервер Vault:
$ vault status
Key Value
--- -----
Seal Type shamir
Sealed false
Total Shares 5
Threshold 3
Version 0.9.5
Cluster Name vault
Cluster ID 0ee91bd1-55ec-c84f-3c1d-dcc7f4f644a8
HA Enabled true
HA Cluster https://10.1.42.201:8201
HA Mode active
Резервный сервер Vault:
vault status
Key Value
--- -----
Seal Type shamir
Sealed false
Total Shares 5
Threshold 3
Version 0.9.5
Cluster Name vaultron
Cluster ID 0ee91bd1-55ec-c84f-3c1d-dcc7f4f644a8
HA Enabled true
HA Cluster https://10.1.42.201:8201
HA Mode standby
Active Node Address: http://10.1.42.201:8200
Теперь серверы Vault работают в режиме высокой доступности (HA), и вы можете записать секрет из активного или резервного экземпляра Vault и увидеть его успешное выполнение в качестве теста пересылки запросов. Кроме того, вы можете закрыть активный экземпляр (sudo systemctl stop vault), чтобы смоделировать сбой системы и увидеть, как резервный экземпляр принимает на себя лидерство.
Следующие шаги
Прочтите "Повышение безопасности", чтобы узнать о передовых методах развертывания Vault для повышения уровня защиты в production среде.
===========
Источник:
habr.com
===========
===========
Автор оригинала: HashiCorp
===========Похожие новости:
- [Системное администрирование, Программирование, IT-инфраструктура, DevOps] Тонкости настройки CI/CD: как работает GitLab runner, когда использовать Docker-in-Docker и где пригодится Argo CD
- [Apache, Big Data, DevOps, Kubernetes] Вебинар «Разворачиваем приложение на Spark в Kubernetes» 4 февраля от Mail.ru Group
- [Высокая производительность, Хранилища данных, DevOps, Data Engineering] Business Intelligence на больших данных — наш опыт интеграции
- [Анализ и проектирование систем, ERP-системы, Управление разработкой, DevOps] Как сделать хорошую интеграцию? Часть 2. Идемпотентные операции – основа устойчивой интеграции
- [Системное администрирование] Таков путь! Эволюция бэкапов в Timeweb: от rsync до ZFS
- [Системное программирование, C, Изучение языков] 4 ошибки, которые легко и просто допустить в языке С
- [Open source, Системное администрирование, IT-инфраструктура] Подготовка к импортозамещению, или Куда бежать, на что смотреть и к кому обратиться за помощью
- [Тестирование IT-систем, Системное администрирование, Программирование, ООП, DevOps] Востребованные IT-профессии. Свежая аналитика по России
- [Информационная безопасность, Системное администрирование] Автоматизация аудита безопасности информационных систем или SCAP ликбез
- [Open source, Git, Системы управления версиями, Системы сборки, DevOps] Вышел релиз GitLab 13.7 с проверяющими для мерж-реквестов и автоматическим откатом при сбое
Теги для поиска: #_sistemnoe_administrirovanie (Системное администрирование), #_sistemnoe_programmirovanie (Системное программирование), #_devops, #_hashicorp_vault, #_sistemnoe_administrirovanie (
Системное администрирование
), #_sistemnoe_programmirovanie (
Системное программирование
), #_devops
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 24-Ноя 16:22
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
Hashicorp Vault — open-source инструмент для управления секретами (пароли, ключи API и т.д.), Vault может работать в режиме высокой доступности (HA) для защиты от сбоев за счет запуска нескольких серверов Vault. Vault обычно ограничивается пределами операций ввода-вывода серверной части Vault, а не требованиями к вычислениям. Некоторые серверные модули хранения, например Consul, предоставляют дополнительные функции координации, которые позволяют Vault работать в конфигурации высокой доступности, в то время как другие обеспечивают более надежный процесс резервного копирования и восстановления. При работе в режиме высокой доступности серверы Vault имеют два дополнительных состояния: резервное и активное. В кластере Vault активным будет только один экземпляр, который будет обрабатывать все запросы (чтение и запись), а все резервные узлы перенаправляют запросы на активный узел.  ПРИМЕЧАНИЕ. Начиная с версии 0.11, эти резервные узлы могут обрабатывать большинство запросов только для чтения и вести себя как узлы реплики для чтения. Эта функция Performance Standby Nodes включена в Vault Enterprise Premium, а также доступна для Vault Enterprise Pro за дополнительную плату. Это особенно полезно для обработки больших объемов запросов. Прочтите документацию по рабочим узлам и руководство для получения более подробной информации. Это руководство проведет вас через простую реализацию кластера Vault Highly Available (HA). Хотя это не исчерпывающее или предписывающее руководство, которое можно использовать в качестве примера прямого подключения, оно охватывает основы, достаточные для информирования вашей собственной производственной установки. Примерное время на выполнение 25 минут Предпосылки Это промежуточное руководство по работе с Vault предполагает, что у вас есть практические знания о Vault и Consul. Шаги Наша цель в этом руководстве, — настроить Vault HA, состоящий из: · 2 серверов Vault: 1 активный и 1 резервный · Кластер из 3-х серверов Consul Справочная диаграмма На этой диаграмме для справки показаны простые детали архитектуры:  Мы будем выполнять эти шаги:
Для реализации целей этого руководства мы будем использовать программное обеспечение с открытым исходным кодом Vault и Consul; настройка будет аналогична для версии Enterprise. Шаг 1. Настройка кластера серверов Consul Наши серверы Consul в этом руководстве будут определяться только IP-адресом, но также обозначены меткой:
Двоичный файл Consul находится в /usr/local/bin/consul, но если в вашем случае не так, вы можете соответствующим образом изменить ссылки на пути. Имея это в виду, вот начальная точка базовой конфигурации сервера Consul: {
"server": true, "node_name": "$NODE_NAME", "datacenter": "dc1", "data_dir": "$CONSUL_DATA_PATH", "bind_addr": "0.0.0.0", "client_addr": "0.0.0.0", "advertise_addr": "$ADVERTISE_ADDR", "bootstrap_expect": 3, "retry_join": ["$JOIN1", "$JOIN2", "$JOIN3"], "ui": true, "log_level": "DEBUG", "enable_syslog": true, "acl_enforce_version_8": false } Обратите внимание, что некоторые значения содержат заполнители переменных, а остальные имеют разумные значения по умолчанию. Вы должны заменить следующие значения в вашей конфигурации сервера Consul на основе примера:
Обратите внимание, что веб-интерфейс пользователя включен ("ui": true), и Consul будет вести журнал на уровне DEBUG в системный журнал ("log_level": "DEBUG"). Для целей этого руководства acl_enforce_version_8 установлено в false, поэтому нам не нужно беспокоиться о списках ACL в этом руководстве. Тем не менее, вы могли бы включить списки ACL в производственной среде и следовать руководству Consul ACL. Создайте файл конфигурации для каждого сервера Vault и сохраните его как /usr/local/etc/consul/client_agent.json. Пример consul_s1.json {
"server": true, "node_name": "consul_s1", "datacenter": "dc1", "data_dir": "/var/consul/data", "bind_addr": "0.0.0.0", "client_addr": "0.0.0.0", "advertise_addr": "10.1.42.101", "bootstrap_expect": 3, "retry_join": ["10.1.42.101", "10.1.42.102", "10.1.42.103"], "ui": true, "log_level": "DEBUG", "enable_syslog": true, "acl_enforce_version_8": false } Пример consul_s2.json {
"server": true, "node_name": "consul_s2", "datacenter": "dc1", "data_dir": "/var/consul/data", "bind_addr": "0.0.0.0", "client_addr": "0.0.0.0", "advertise_addr": "10.1.42.102", "bootstrap_expect": 3, "retry_join": ["10.1.42.101", "10.1.42.102", "10.1.42.103"], "ui": true, "log_level": "DEBUG", "enable_syslog": true, "acl_enforce_version_8": false } Пример consul_s3.json {
"server": true, "node_name": "consul_s3", "datacenter": "dc1", "data_dir": "/var/consul/data", "bind_addr": "0.0.0.0", "client_addr": "0.0.0.0", "advertise_addr": "10.1.42.103", "bootstrap_expect": 3, "retry_join": ["10.1.42.101", "10.1.42.102", "10.1.42.103"], "ui": true, "log_level": "DEBUG", "enable_syslog": true, "acl_enforce_version_8": false } Консул Сервер systemd У вас есть двоичные файлы Consul и базовая конфигурация, и теперь вам просто нужно запустить Consul на каждом экземпляре сервера; systemd популярен в большинстве современных дистрибутивов Linux, поэтому, имея это в виду, вот пример файла systemd unit: ### BEGIN INIT INFO
# Provides: consul # Required-Start: $local_fs $remote_fs # Required-Stop: $local_fs $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Consul agent # Description: Consul service discovery framework ### END INIT INFO [Unit] Description=Consul server agent Requires=network-online.target After=network-online.target [Service] User=consul Group=consul PIDFile=/var/run/consul/consul.pid PermissionsStartOnly=true ExecStartPre=-/bin/mkdir -p /var/run/consul ExecStartPre=/bin/chown -R consul:consul /var/run/consul ExecStart=/usr/local/bin/consul agent \ -config-file=/usr/local/etc/consul/client_agent.json \ -pid-file=/var/run/consul/consul.pid ExecReload=/bin/kill -HUP $MAINPID KillMode=process KillSignal=SIGTERM Restart=on-failure RestartSec=42s [Install] WantedBy=multi-user.target Обратите внимание, что вас может заинтересовать изменение следующих значений в зависимости от стиля, стандартного уровня соблюдения иерархии файловой системы и т. Д. –
После того как файл модуля определен и сохранен (например, /etc/systemd/system/consul.service), обязательно выполните перезагрузку демона systemctl daemon-reload, а затем вы можете запустить службу Consul на каждом сервере. Шаг 2. Запуск и проверка состояния кластера Consul Убедитесь, что права собственности и разрешения верны в каталоге, который вы указали для значения data_dir, а затем запустите службу Consul в каждой системе и проверьте статус: $ sudo systemctl start consul
$ sudo systemctl status consul ● consul.service - Consul server agent Loaded: loaded (/etc/systemd/system/consul.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2018-03-19 17:33:14 UTC; 24h ago Main PID: 2068 (consul) Tasks: 13 Memory: 13.6M CPU: 0m 52.784s CGroup: /system.slice/consul.service └─2068 /usr/local/bin/consul agent -config-file=/usr/local/etc/consul/client_agent.json -pid-file=/var/run/consul/consul.pid После запуска всех агентов сервера Consul, давайте проверим статус кластера Consul: $consul members
Node Address Status Type Build Protocol DC Segment consul_s1 10.1.42.101:8301 alive server 1.0.6 2 dc1 <all> consul_s2 10.1.42.102:8301 alive server 1.0.6 2 dc1 <all> consul_s3 10.1.42.103:8301 alive server 1.0.6 2 dc1 <all> Кластер выглядит хорошо, показаны все 3 сервера; Прежде чем продолжить, убедитесь, что у нас есть лидер: $consul operator raft list-peers
Node ID Address State Voter RaftProtocol consul_s2 536b721f-645d-544a-c10d-85c2ca24e4e4 10.1.42.102:8300 follower true 3 consul_s1 e10ba554-a4f9-6a8c-f662-81c8bb2a04f5 10.1.42.101:8300 follower true 3 consul_s3 56370ec8-da25-e7dc-dfc6-bf5f27978a7a 10.1.42.103:8300 leader true 3 Приведенный выше вывод показывает, что consul_s3 является текущим лидером кластера в этом примере. Теперь вы можете перейти к настройке сервера Vault. Шаг 3. Настройка клиентских агентов Consul на узлах Vault Узлам сервера Vault требуются двоичные файлы Consul и Vault на каждом узле. Consul будет настроен как агент клиента, а Vault будет настроен как сервер.  Конфигурация агента клиента Consul Поскольку Consul используется для обеспечения серверной части высокодоступного хранилища, вам необходимо настроить локальные клиентские агенты Consul на серверах Vault, которые будут взаимодействовать с кластером серверов Consul для регистрации проверок работоспособности, обнаружения служб и координации переключения HA кластера (лидерство кластера). Обратите внимание, что не рекомендуется подключать серверы Vault напрямую к серверам Consul. Агенты клиента Consul будут использовать тот же адрес, что и серверы Vault, для сетевой связи с кластером серверов Consul, но они будут связывать client_address только с интерфейсом обратной связи, так что Vault может подключиться к нему через интерфейс обратной связи. Вот пример конфигурации для агента клиента Consul: {
"server": false, "datacenter": "dc1", "node_name": "$NODE_NAME", "data_dir": "$CONSUL_DATA_PATH", "bind_addr": "$BIND_ADDR", "client_addr": "127.0.0.1", "retry_join": ["$JOIN1", "$JOIN2", "$JOIN3"], "log_level": "DEBUG", "enable_syslog": true, "acl_enforce_version_8": false } Аналогично тому, что вы сделали на шаге 1, замените следующие значения в своей конфигурации агента клиента Consul соответственно:
Создайте файл конфигурации для каждого сервера Vault и сохраните его как /usr/local/etc/consul/client_agent.json. Пример consul_c1.json {
"server": false, "datacenter": "dc1", "node_name": "consul_c1", "data_dir": "/var/consul/data", "bind_addr": "10.1.42.201", "client_addr": "127.0.0.1", "retry_join": ["10.1.42.101", "10.1.42.102", "10.1.42.103"], "log_level": "DEBUG", "enable_syslog": true, "acl_enforce_version_8": false } Пример consul_c2.json {
"server": false, "datacenter": "dc1", "node_name": "consul_c2", "data_dir": "/var/consul/data", "bind_addr": "10.1.42.202", "client_addr": "127.0.0.1", "retry_join": ["10.1.42.101", "10.1.42.102", "10.1.42.103"], "log_level": "DEBUG", "enable_syslog": true, "acl_enforce_version_8": false } systemd юнит файл Consul сервера У вас есть двоичные файлы Consul и базовая конфигурация агента клиента, и теперь вам просто нужно запустить Consul на каждом из экземпляров сервера Vault. Вот пример файла модуля systemd: ### BEGIN INIT INFO
# Provides: consul # Required-Start: $local_fs $remote_fs # Required-Stop: $local_fs $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Consul agent # Description: Consul service discovery framework ### END INIT INFO [Unit] Description=Consul client agent Requires=network-online.target After=network-online.target [Service] User=consul Group=consul PIDFile=/var/run/consul/consul.pid PermissionsStartOnly=true ExecStartPre=-/bin/mkdir -p /var/run/consul ExecStartPre=/bin/chown -R consul:consul /var/run/consul ExecStart=/usr/local/bin/consul agent \ -config-file=/usr/local/etc/consul/client_agent.json \ -pid-file=/var/run/consul/consul.pid ExecReload=/bin/kill -HUP $MAINPID KillMode=process KillSignal=SIGTERM Restart=on-failure RestartSec=42s [Install] WantedBy=multi-user.target При необходимости измените следующие значения:
После того как файл модуля определен и сохранен (например, /etc/systemd/system/consul.service), обязательно выполните перезагрузку демона systemctl daemon-reload, а затем вы можете запустить службу Consul на каждом сервере Vault. Запустите Consul и проверьте его состояние кластера, чтобы убедиться, что права собственности и разрешения верны в каталоге, который вы указали для значения data_dir, а затем запустите службу Consul в каждой системе и проверьте статус: $ sudo systemctl start consul
$ sudo systemctl status consul ● consul.service - Consul client agent Loaded: loaded (/etc/systemd/system/consul.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2018-03-20 19:36:49 UTC; 6s ago Main PID: 23758 (consul) Tasks: 11 Memory: 9.8M CPU: 571ms CGroup: /system.slice/consul.service └─23758 /usr/local/bin/consul agent -config-file=/usr/local/etc/consul/client_agent.json -pid-file=/var/run/consul/consul.pid После запуска всех клиентских агентов Consul проверьте статус кластера Consul: $consul members
Node Address Status Type Build Protocol DC Segment consul_s1 10.1.42.101:8301 alive server 1.0.6 2 dc1 <all> consul_s2 10.1.42.102:8301 alive server 1.0.6 2 dc1 <all> consul_s3 10.1.42.103:8301 alive server 1.0.6 2 dc1 <all> consul_c1 10.1.42.201:8301 alive client 1.0.6 2 arus <default> consul_c2 10.1.42.202:8301 alive client 1.0.6 2 arus <default> Приведенные выше выходные данные показывают 3 агента сервера Consul и 2 агента клиента Consul в кластере. Теперь вы можете настроить серверы Vault. Шаг 4. Настройка серверов Vault Теперь, когда у нас есть кластер Consul, состоящий из 3-х серверов и 2-х клиентских агентов для наших серверов Vault, давайте вместе получим конфигурацию для Vault и сценарий запуска, чтобы мы могли запустить настройку Vault HA. Наши серверы Vault в этом руководстве определяются только IP-адресом, но также обозначаются меткой:
В нашем файле конфигурации мы настроим следующее:
В этом разделе предполагается, что двоичный файл Vault находится в /usr/local/bin/vault. Конфигурация Vault listener "tcp" {
address = "0.0.0.0:8200" cluster_address = "0.0.0.0:8201" tls_disable = "true" } storage "consul" { address = "127.0.0.1:8500" path = "vault/" } api_addr = "$API_ADDR" cluster_addr = "$CLUSTER_ADDR" Мы устанавливаем следующие параметры для нашего tcp-слушателя:
Эта конфигурация позволяет прослушивать все интерфейсы (например, так, чтобы команда Vault для адреса обратной связи была успешной). Мы также устанавливаем параметры высокой доступности Vault (api_addr и cluster_addr). Чаще всего нет необходимости настраивать эти два параметра при использовании Consul в качестве серверной части хранилища Vault, поскольку Consul будет пытаться автоматически обнаруживать и объявлять адрес активного узла Vault. Однако для некоторых конфигураций кластера может потребоваться их явная установка (например, доступ к Vault через балансировщик нагрузки). Для простоты предположим, что клиенты в нашем сценарии подключаются непосредственно к узлам Vault (а не через балансировщик нагрузки). Просмотрите документацию Client Redirection, чтобы получить дополнительную информацию о шаблонах доступа клиентов и их последствиях. Обратите внимание, что некоторые значения содержат заполнители переменных, а остальные имеют разумные значения по умолчанию. Вы должны заменить следующие значения в конфигурации вашего собственного сервера Vault на основе примера:
Обратите внимание, что схема здесь (https) игнорируется; все члены кластера всегда будут использовать TLS с закрытым ключом / сертификатом. Пример vault_s1.hcl listener "tcp" {
address = "0.0.0.0:8200" cluster_address = "10.1.42.201:8201" tls_disable = "true" } storage "consul" { address = "127.0.0.1:8500" path = "vault/" } api_addr = "http://10.1.42.201:8200" cluster_addr = "https://10.1.42.201:8201" Пример vault_s2.hcl listener "tcp" {
address = "0.0.0.0:8200" cluster_address = "10.1.42.202:8201" tls_disable = "true" } storage "consul" { address = "127.0.0.1:8500" path = "vault/" } api_addr = "http://10.1.42.202:8200" cluster_addr = "https://10.1.42.202:8201" systemd юнит файл Vault сервера У вас есть двоичные файлы Vault и базовая конфигурация вместе с настроенными локальными агентами клиента. Теперь вам просто нужно запустить Vault на каждом экземпляре сервера. Вот пример файла модуля systemd: ### BEGIN INIT INFO
# Provides: vault # Required-Start: $local_fs $remote_fs # Required-Stop: $local_fs $remote_fs # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Vault server # Description: Vault secret management tool ### END INIT INFO [Unit] Description=Vault secret management tool Requires=network-online.target After=network-online.target [Service] User=vault Group=vault PIDFile=/var/run/vault/vault.pid ExecStart=/usr/local/bin/vault server -config=/etc/vault/vault_server.hcl -log-level=debug ExecReload=/bin/kill -HUP $MAINPID KillMode=process KillSignal=SIGTERM Restart=on-failure RestartSec=42s LimitMEMLOCK=infinity [Install] WantedBy=multi-user.target Обратите внимание, что вас может заинтересовать изменение следующих значений в зависимости от стиля, стандартного уровня соблюдения иерархии файловой системы и т. д.
Как только файл модуля определен и сохранен, например, /etc/systemd/system/vault.service, обязательно выполните перезагрузку демона systemctl daemon-reload, а затем вы можете запустить службу Vault на каждом сервере. Шаг 5. Запуск Vault и его проверка Запустите службу Vault в каждой системе и проверьте состояние: $ sudo systemctl start vault
$ sudo systemctl status vault ● vault.service - Vault secret management tool Loaded: loaded (/etc/systemd/system/vault.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2018-03-20 20:42:10 UTC; 42s ago Main PID: 2080 (vault) Tasks: 12 Memory: 71.7M CPU: 50s CGroup: /system.slice/vault.service └─2080 /usr/local/bin/vault server -config=/home/ubuntu/vault_nano/config/vault_server.hcl -log-level=debu Теперь вам нужно перейти к инициализации и распечатыванию каждого экземпляра Vault. Как только это будет сделано, проверьте статус Vault на каждом из серверов. Активный сервер Vault: $ vault status
Key Value --- ----- Seal Type shamir Sealed false Total Shares 5 Threshold 3 Version 0.9.5 Cluster Name vault Cluster ID 0ee91bd1-55ec-c84f-3c1d-dcc7f4f644a8 HA Enabled true HA Cluster https://10.1.42.201:8201 HA Mode active Резервный сервер Vault: vault status
Key Value --- ----- Seal Type shamir Sealed false Total Shares 5 Threshold 3 Version 0.9.5 Cluster Name vaultron Cluster ID 0ee91bd1-55ec-c84f-3c1d-dcc7f4f644a8 HA Enabled true HA Cluster https://10.1.42.201:8201 HA Mode standby Active Node Address: http://10.1.42.201:8200 Теперь серверы Vault работают в режиме высокой доступности (HA), и вы можете записать секрет из активного или резервного экземпляра Vault и увидеть его успешное выполнение в качестве теста пересылки запросов. Кроме того, вы можете закрыть активный экземпляр (sudo systemctl stop vault), чтобы смоделировать сбой системы и увидеть, как резервный экземпляр принимает на себя лидерство. Следующие шаги Прочтите "Повышение безопасности", чтобы узнать о передовых методах развертывания Vault для повышения уровня защиты в production среде. =========== Источник: habr.com =========== =========== Автор оригинала: HashiCorp ===========Похожие новости:
Системное администрирование ), #_sistemnoe_programmirovanie ( Системное программирование ), #_devops |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 24-Ноя 16:22
Часовой пояс: UTC + 5