В предыдущей статье мы говорили о том, как собрать кластер Consul с контролем Acl. В этой статье в основном рассказывается о значении большой серии конфигурационных файлов из предыдущей статьи.
1. Инструкции по настройке
№ 1.1 Исправления
В предыдущей статье про машинное планирование неправильно был написан порт агента клиента консула. Вот еще один пост о правильном планировании машины.
1.2 Давайте сначала рассмотрим настройку агента сервера consul.
В предыдущем разделе были предоставлены три файла конфигурации: consul-server1.json, consul-server2.json и consul-server3.json. Среди них у consul-server1.json больше всего параметров, и вот смысл каждой конфигурации:
{
"datacenter":"dc1",
"primary_datacenter":"dc1",
"bootstrap_expect":1,
"start_join":[
"10.211.55.25",
"10.211.55.26"
],
"retry_join":[
"10.211.55.25",
"10.211.55.26"
],
"advertise_addr": "10.211.55.28",
"bind_addr": "10.211.55.28",
"server":true,
"connect":{
"enabled":true
},
"node_name":"consul-server1",
"data_dir":"/opt/consul/data/",
"enable_script_checks":false,
"enable_local_script_checks":true,
"log_file":"/opt/consul/log/",
"log_level":"info",
"log_rotate_bytes":100000000,
"log_rotate_duration":"24h",
"encrypt":"krCysDJnrQ8dtA7AbJav8g==",
"acl":{
"enabled":true,
"default_policy":"deny",
"enable_token_persistence":true,
"tokens":{
"master":"cd76a0f7-5535-40cc-8696-073462acc6c7",
"agent":"deaa315d-98c5-b9f6-6519-4c8f6574a551"
}
}
}
- центр данных Этот флаг указывает центр данных, в котором работает агент. Если он не указан, по умолчанию используется «dc1». Consul имеет первоклассную поддержку нескольких центров обработки данных, но она зависит от правильной настройки. Узлы в одном центре обработки данных должны находиться в одной локальной сети.
- primary_datacenter: указывает центр обработки данных, который является полномочным для информации ACL. Он должен быть предоставлен для включения ACL.
- bootstrap_expect: Consul будет ждать, пока указанное количество серверов станет доступным, прежде чем загружать кластер. Это позволяет автоматически выбирать начального лидера.
- start_join: массив строк, указывающих адреса других агентов сервера consul. Эта конфигурация попытается добавить два узла consul-server2 и consul-server3 для формирования кластера при запуске.
- retry_join: продолжить повторное подключение, если start_join не работает. Интервал повтора можно установить с помощью retry_interval, значение по умолчанию — 30 с; максимальное количество повторов можно установить с помощью retry_max, значение по умолчанию — 0, что означает неограниченное количество повторов. Что касается retry_interval и retry_max, здесь используются значения по умолчанию.
- bind_addr: адрес для привязки для внутренней связи кластера. Это IP-адрес, который должен быть доступен для всех остальных узлов в кластере. По умолчанию это «0.0.0.0», что означает, что Consul будет связываться со всеми адресами на локальном компьютере и объявлять первый доступный частный IPv4-адрес остальной части кластера. Консул завершит работу с ошибкой при запуске, если доступно более одного частного IPv4-адреса. Если указано "[::]", Consul объявит первый доступный публичный IPv6-адрес. Consul завершит работу с ошибкой при запуске, если доступно несколько общедоступных IPv6-адресов. Consul использует как TCP, так и UDP, и оба используют один и тот же порт. Если у вас есть брандмауэр, обязательно разрешите оба протокола.
- реклама_адрес: изменить адрес, который мы объявляем другим узлам в кластере. По умолчанию используется адрес, указанный параметром -bind.
- server: Является ли это узлом агента сервера.
- connect.enabled: начинать лиConsul Connect, который включен здесь.
- node_name: имя узла.
- data_dir: каталог, в котором агент хранит состояние.
- enable_script_checks: следует ли включать проверки работоспособности для выполнения сценариев на этом агенте. Есть дыры в безопасности, по умолчанию стоит false, вот отдельное напоминание.
- enable_local_script_checks: аналогично enable_script_checks, но разрешает их только в том случае, если они определены в локальном файле конфигурации. Проверки сценариев, определенные при регистрации HTTP API, по-прежнему не разрешены.
- log-file: перенаправить все сообщения журнала Consul Agent в файл. Здесь указывается каталог /opt/consul/log/.
- log_rotate_bytes: указывает количество байтов, которое должно быть записано в журнал, прежде чем потребуется ротация. Если не указано иное, количество байтов, которые можно записать в файл журнала, не ограничено.
- log_rotate_duration: указывает максимальную продолжительность записи журнала, прежде чем его нужно будет ротировать. Если не указано иное, журнал ротируется ежедневно (24 часа). Единицами измерения могут быть «нс», «нас» (или «мкс»), «мс», «с», «м», «ч», например заданные значения. на 24 часа
- encrypt: используется для шифрования данных, которыми обмениваются протокол Consul Gossip. Перед запуском каждого сервера вы можете настроить одно и то же значение UUID или использовать команду consul keygen из командной строки для его создания.
- acl.enabled: Включить ли acl.
- acl.default_policy: «разрешить» или «запретить»; по умолчанию «разрешить», но это изменится в будущем основном выпуске. Политика по умолчанию управляет поведением маркера, когда никакие правила не совпадают. В режиме «разрешить» ACL представляет собой черный список: разрешено любое действие, не запрещенное явно. В режиме «запретить» ACL представляет собой белый список: блокируйте любые операции, которые явно не разрешены.
- acl.enable_token_persistence: Возможные значения: true или false. При значении true набор токенов, используемых API, будет сохранен на диск и перезагружен при перезапуске брокера.
- acl.tokens.master: имеет полномочия глобального управления, то есть максимальные полномочия. Это позволяет операторам запускать систему ACL, используя хорошо известные идентификаторы токен-ключей. Для всех агентов сервера необходимо установить одно и то же значение, для которого можно задать случайный UUID. Это значение имеет наибольший авторитет, поэтому следите за его соблюдением.
- acl.tokens.agent: используется клиентом и сервером для выполнения внутренних операций, таких как обновление API каталога, антиэнтропийная синхронизация и т. д.
1.3 Поговорим о настройке consul-client1.
Я опубликую информацию о конфигурации снова.
{
"datacenter":"dc1",
"primary_datacenter":"dc1",
"advertise_addr": "10.211.55.27",
"start_join":[
"10.211.55.25",
"10.211.55.26",
"10.211.55.28"
],
"retry_join":[
"10.211.55.25",
"10.211.55.26",
"10.211.55.28"
],
"bind_addr":"10.211.55.27",
"node_name":"consul-client1",
"client_addr":"0.0.0.0",
"connect":{
"enabled":true
},
"data_dir":"/opt/consul/data/",
"log_file":"/opt/consul/log/",
"log_level":"info",
"log_rotate_bytes":100000000,
"log_rotate_duration":"24h",
"encrypt":"krCysDJnrQ8dtA7AbJav8g==",
"ui":true,
"enable_script_checks":false,
"enable_local_script_checks":true,
"disable_remote_exec":true,
"ports":{
"http":7110
},
"acl":{
"enabled":true,
"default_policy":"deny",
"enable_token_persistence":true,
"tokens":{
"agent":"deaa315d-98c5-b9f6-6519-4c8f6574a551"
}
}
}
Здесь start_join, retry_join — адреса указанного агента сервера. Еще одна не упомянутая конфигурация — client_addr, ui, ports.http. Далее объясняются по очереди:
- client_addr: Consul будет привязывать адрес клиентского интерфейса, включая HTTP и DNS серверы
- ui: включает встроенный сервер веб-интерфейса и соответствует требуемым маршрутам HTTP.
- ports.http: изменение порта http по умолчанию.
2. Использование токена ACL
2.1 Для чего используется токен ACL?
Кто-то может сказать, что вы просили собрать окружение и прочитать инструкцию по настройке, какой толк от такого кластера Консул с управлением ACL?
Полное название ACL Access Control List, что означает список контроля доступа.Сейчас мы сгенерировали кластер с контролем ACL, а это значит, что не все могут зарегистрироваться у меня, и никто не может получить список услуг, как я-тоже то есть, если вы хотите выполнить какую-либо операцию на Consul, вам нужен соответствующий токен, который является токеном ACL.
2.2 Можно ли работать без токена?
Чтобы имитировать общий HTTP-запрос, я загружаю его здесь.Postman, да здесь не используется командная строка curl. Теперь мы ввод почтальонаhttp://127.0.0.1:7110/v1/catalog/nodesВы обнаружите, что узел не может его получить:
2.3 Нельзя не принести токен, можете ли вы принести токен с меньшими разрешениями?
Как упоминалось ранее, главный токен — это токен с наибольшим авторитетом, и если он задан таким образом, будут использоваться все части. Что делать, если две разные части регистрируют службу с одним и тем же именем, и что, если служба из другого отдела не зарегистрирована. Короче говоря, можно ли разрешения дать немного, ответ да. Сначала поговорим о цели: 1. Сервисы разных отделов должны иметь свои префиксы, например deptA для отдела A, например deptB для отдела B 2. Разные отделы могут менять только свои услуги.
2.3.1 Сначала зарегистрируйте службу для каждого из двух отделов
Зарегистрируйте сервис deptA-pingbaidu1, обратите внимание на выбранный здесь метод PUT.
PUT http://127.0.0.1:7110/v1/agent/service/register?token=cd76a0f7-5535-40cc-8696-073462acc6c7
{
"ID": "deptA-pingbaidu1",
"Name": "deptA-pingbaidu",
"Tags": [
"primary",
"v1"
],
"Address": "127.0.0.1",
"Port": 8000,
"Meta": {
"my_version": "4.0"
},
"EnableTagOverride": false,
"Check": {
"DeregisterCriticalServiceAfter": "90m",
"HTTP": "http://www.baidu.com/",
"Interval": "10s"
}
} 
На скриншоте когда возвращаемый статус 200 значит успешная регистрация
PUT http://127.0.0.1:7110/v1/agent/service/register?token=cd76a0f7-5535-40cc-8696-073462acc6c7
{
"ID": "deptB-pingMe1",
"Name": "deptB-pingMe",
"Tags": [
"primary",
"v1"
],
"Address": "127.0.0.1",
"Port": 7000,
"Meta": {
"my_version": "4.0"
},
"EnableTagOverride": false,
"Check": {
"DeregisterCriticalServiceAfter": "90m",
"HTTP": "https://blog.csdn.net/yellowstar5",
"Interval": "10s"
}
} 
2.3.2. Создайте два токена и позвольте отделам A и B управлять своими услугами
Во-первых, давайте создадим политику отдела A, что означает, что все узлы имеют права на запись (разрешения на запись включают чтение) и могут записывать только сервисы, начинающиеся с отдела A.
2.3.2.1 Сначала сгенерируйте токен отдела A
node_prefix "" {
policy = "write"
}
service_prefix "deptA"{
policy = "write"
}
Ниже приведен конкретный процесс генерации 1. Создайте новую политику и сохраните ее.
2.3.2. 2. Генерация токена отдела B
Вам нужно только немного изменить политику.Другие отделы аналогичны отделу А, поэтому карты здесь нет.
node_prefix "" {
policy = "write"
}
service_prefix "deptB"{
policy = "write"
}
2.3 Используйте разные токены для получения списка услуг
В итоге получаем токены отдела А и отдела Б, а так же токен мастера Мой токен для deptA здесь: 8764c083-0acb-e11e-433d-8d8803db9bd2 Токен отдела B: 052f467f-9581-cc7c-a8a5-84d8df51dc9d Главный токен: d76a0f7-5535-40cc-8696-073462acc6c7. Давайте проверим это с почтальоном, чтобы увидеть список сервисов, возвращаемых разными токенами.
deptA-token http://127.0.0.1:7110/v1/agent/services?token=8764c083-0acb-e11e-433d-8d8803db9bd2
Ссылаться на:
woohoo.consul.IO/API/Аргентина/Да… woohoo.consul.IO/docs/argentina/…После статьи она будет размещена на WeChat как можно скорее.Приглашаю обратить внимание на мой публичный аккаунт WeChat.Давайте общаться и учиться вместе.