Установка Consul в Unix/Linux

Consul — очередной продукт компании HashiCorp который имеет несколько компонентов, но в целом это инструмент для обнаружения и настройки служб в вашей инфраструктуре.

Основные функции в consul:

• Обнаружение служб (Service Discovery): consul клиенты могут предоставлять службы (такие как api или mysql), а другие клиенты могут использовать consul для поиска данных служб. Используя DNS или HTTP, приложения могут легко находить службы, от которых они зависят.
• Проверка работоспособности (Health Checking): consul клиенты могут предоставлять любое количество хелз_чеков, связанных с данным сервисом (например веб-сервер, возвращающий 200 OK) или с локальной нодой (использование памяти < 90%). Эта информация может использоваться оператором для мониторинга состояния кластера, и он используется компонентами обнаружения служб для маршрутизации трафика от «нездоровых хостов» (unhealthy hosts).
• Хранилище ключ-значение (KV Store): приложения могут использовать иерархическое хранилище ключей/значений Consul для любых целей, включая динамическую конфигурацию, метки функций, координацию, выбор лидеры (например — docker swarm) и многое другое. Простой HTTP API упрощает его использование.
• Мультицентр (Multi Datacenter): consul поддерживает множество центров обработки данных из коробки.

PS: Ссылки и версия консула базируется на тот момент времени, когда писалась статья! Если подходит она вам, используйте, иначе — поменяйте ссылку на актуальную.

Что такое discovery?

Discovery — это инструмент (или набор инструментов) для обеспечения связи между компонентами архитектуры. Используя discovery мы обеспечиваем связность между компонентами приложения, но не связанность. Discovery можно рассматривать как некий реестр метаинформации о распределенной архитектуре, в котором хранятся все данные о компонентах. Это позволяет реализовать взаимодействие компонентов с минимальным ручным вмешательством.

Discovery-сервис обеспечивает три основных функции, на которых базируется связность в рамках распределенной архитектуры:

• Консистентность метаинформации о сервисах в рамках кластера. Распределенная архитектура подразумевает, что компоненты можно масштабировать горизонтально, при этом они должны владеть актуальной информацией о состоянии кластера. Discovery-сервис обеспечивает (де)централизованное хранилище и доступ к нему для любого узла. Компоненты могут сохранять свои данные и информация будет доставлена ко всем заинтересованным участникам кластера.
• Механизм для регистрации и мониторинга доступности компонентов. Вновь добавляемые сервисы должны сообщить о себе, а уже запущенные обязаны проходить постоянную проверку на доступность. Это является необходимым условием для автоматической конфигурации кластера. Балансеры трафика и зависимые ноды обязательно должны иметь информацию о текущей конфигурации кластера для эффективного использования ресурсов.
• Механизм для обнаружения компонентов. Под обнаружением подразумевается механизм поиска сервисов, например, по ролям которые они выполняют. Мы можем запросить местоположение для всех сервисов определенной роли, не зная их точного количества и конкретных адресов, а зная лишь адрес discovery-сервиса.

Установка Consul в Linux

Имеется несколько способов чтобы установить консул на Linux ОС.

-=== СПОСОБ 1 — использовать готовый пакет ===- 

При использовании Linux 64 bit архитектурой:

$ cd /usr/local/src/ && curl -O https://releases.hashicorp.com/consul/1.0.2/consul_1.0.2_linux_amd64.zip

При использовании Linux 32 bit архитектурой:

$ cd /usr/local/src/ && curl -O https://releases.hashicorp.com/consul/1.0.2/consul_1.0.2_linux_386.zip

При использовании Linux arm архитектурой:

$ cd /usr/local/src/ && curl -O  https://releases.hashicorp.com/consul/1.0.2/consul_1.0.2_linux_arm.zip

При использовании Linux arm64 архитектурой:

$ cd /usr/local/src/ && curl -O https://releases.hashicorp.com/consul/1.0.2/consul_1.0.2_linux_arm64.zip

Расспаковываем его:

$ unzip consul.zip

Удалим старый архив:

# rm -f /usr/local/src/consul_*.zip

Переносим готовый к использованию пакет в нужное нам место:

# mv /usr/local/src/consul /usr/local/bin/consul

Выставляем право на выполнение:

# chmod +x /usr/local/bin/consul

Смотрим какая версия:

$ consul --version

Consul v1.0.2
Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use protocol >2 when speaking to compatible agents)

И переходим к использованию.

-=== СПОСОБ 2 — использовать docker контейнер ===- 

Немного позже будет материал!

Установка Consul в MacOS X

Имеется несколько способов чтобы установить консул на mac OS X.

-=== СПОСОБ 1 — использовать brew ===- 

Первое что стоит сделать — это установить homebrew на mac OS X, вот инструкция по использованию:

Установка Homebrew на Mac OS X

Давайте посмотрим, имеется ли нужный нам пакет в мак ОС Х, выполнив:

$ brew search consul

==> Searching local taps...
consul                                             consul-backinator                                  consul-template                                    envconsul
==> Searching taps on GitHub...
caskroom/cask/consul-cli
==> Searching blacklisted, migrated and deleted formulae...

If you meant "consul" specifically:
It was migrated from caskroom/cask to homebrew/core.

И, выполняем установку:

$ brew install consul

Смотрим какая версия:

$ consul --version

Consul v1.0.2
Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use protocol >2 when speaking to compatible agents)

Перейдем к настройке/использованию!

-=== СПОСОБ 2 — использовать готовый пакет ===- 

# cd /usr/local/src && curl -O https://releases.hashicorp.com/consul/1.0.2/consul_1.0.2_darwin_amd64.zip

Расспаковываем его:

$ unzip consul_1.0.2_darwin_amd64.zip

Удалим старый архив:

# rm -f /usr/local/src/consul_1.0.2_darwin_amd64.zip

Переносим готовый к использованию пакет в нужное нам место:

# mv /usr/local/src/consul /usr/local/bin/consul

Выставляем право на выполнение:

# chmod +x /usr/local/bin/consul

Смотрим какая версия:

$ consul --version

Consul v1.0.2
Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use protocol >2 when speaking to compatible agents)

-=== СПОСОБ 3 — использовать docker контейнер ===- 

Немного позже будет материал!

Установка Consul в FreeBSD

Имеется несколько способов чтобы установить консул на freeBSD ОС.

-=== СПОСОБ 1 — использовать готовый пакет ===- 

При использовании FreeBSD 32 bit архитектурой:

$ cd /usr/local/src/ && curl -O https://releases.hashicorp.com/consul/1.0.2/consul_1.0.2_freebsd_386.zip

При использовании FreeBSD 64 bit архитектурой:

$ cd /usr/local/src/ && curl -O https://releases.hashicorp.com/consul/1.0.2/consul_1.0.2_freebsd_amd64.zip

При использовании Linux arm архитектурой:

$ cd /usr/local/src/ && curl -O https://releases.hashicorp.com/consul/1.0.2/consul_1.0.2_freebsd_arm.zip

Расспаковываем его:

$ unzip consul.zip

Удалим старый архив:

# rm -f /usr/local/src/consul_*.zip

Переносим готовый к использованию пакет в нужное нам место:

# mv /usr/local/src/consul /usr/local/bin/consul

Выставляем право на выполнение:

# chmod +x /usr/local/bin/consul

Смотрим какая версия:

$ consul --version

Consul v1.0.2
Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use protocol >2 when speaking to compatible agents)

И переходим к использованию.

-=== СПОСОБ 2 — использовать docker контейнер ===- 

Немного позже будет материал!

Установка Consul в Solaris

-=== СПОСОБ 1 — использовать готовый пакет ===- 

При использовании Solaris 64 bit архитектурой:

$ cd /usr/local/src/ && curl -O https://releases.hashicorp.com/consul/1.0.2/consul_1.0.2_solaris_amd64.zip

Расспаковываем его:

$ unzip consul.zip

Удалим старый архив:

# rm -f /usr/local/src/consul_*.zip

Переносим готовый к использованию пакет в нужное нам место:

# mv /usr/local/src/consul /usr/local/bin/consul

Выставляем право на выполнение:

# chmod +x /usr/local/bin/consul

Смотрим какая версия:

$ consul --version

Consul v1.0.2
Protocol 2 spoken by default, understands 2 to 3 (agent will automatically use protocol >2 when speaking to compatible agents)

И переходим к использованию.

-=== СПОСОБ 2 — использовать docker контейнер ===- 

Немного позже будет материал!

Использование Consul в Unix/Linux

Для начала, посмотрим помощь:

# consul -h
Usage: consul [--version] [--help] <command> [<args>]

Available commands are:
    agent          Runs a Consul agent
    catalog        Interact with the catalog
    event          Fire a new event
    exec           Executes a command on Consul nodes
    force-leave    Forces a member of the cluster to enter the "left" state
    info           Provides debugging information for operators.
    join           Tell Consul agent to join cluster
    keygen         Generates a new encryption key
    keyring        Manages gossip layer encryption keys
    kv             Interact with the key-value store
    leave          Gracefully leaves the Consul cluster and shuts down
    lock           Execute a command holding a lock
    maint          Controls node or service maintenance mode
    members        Lists the members of a Consul cluster
    monitor        Stream logs from a Consul agent
    operator       Provides cluster-level tools for Consul operators
    reload         Triggers the agent to reload configuration files
    rtt            Estimates network round trip time between nodes
    snapshot       Saves, restores and inspects snapshots of Consul server state
    validate       Validate config files/directories
    version        Prints the Consul version
    watch          Watch for changes in Consul

#

Запуск Consul-агента

Чтобы запустить Consul-агента, служит команда:

$ consul agent -dev

Можно получить ошибку:

Error starting agent: Failed to get advertise address: Multiple private IPs found. Please configure one.

То решение будет добавление «-bind IP_of_YOUR_SERVER» опции в предедущую команду следующим образом:

$ consul agent -dev -bind 192.168.13.219

Где:

• 192.168.13.219 — ИП самого сервера с консул.

Опции:

• -datacenter — Этот флаг управляет батацентром, в котором работает агент. Если не указано, по умолчанию используется значение «dc1». Консул имеет первоклассную поддержку для нескольких центров обработки данных, но он полагается на правильную конфигурацию. Узлы в одном и том же центре данных должны находиться в одной локальной сети.
• -dev — Включает dev режим на серверe с onsul. Этот режим не предназначен для использования в ПРОД, так как он не записывает никаких данных на диск.
• -encrypt — Указывает секретный ключ для шифрования сетевого трафика в Consul. Этот ключ должен быть 16-байтным, кодированным Base64. Самый простой способ создать ключ шифрования — использовать «consul keygen» команду. Все узлы в кластере должны совместно использовать один и тот же ключ шифрования. Предоставленный ключ автоматически сохраняется в каталоге данных и автоматически загружается всякий раз, когда агент перезапускается.

Ну что, проверим доступные ноды следующей командой:

$ consul members
Node                   Address              Status  Type    Build  Protocol  DC   Segment
localhost.localdomain  192.168.13.219:8301  alive   server  1.0.2  2         dc1  <all>
$

Для детального вывода:

$ consul members -detailed
Node                   Address              Status  Tags
localhost.localdomain  192.168.13.219:8301  alive   build=1.0.2:b55059f,dc=dc1,id=fdbdd7ea-9e81-0604-7ba6-1c0dc57c5e73,port=8300,raft_vsn=3,role=consul,segment=<all>,vsn=2,vsn_max=3,vsn_min=2,wan_join_port=8302
$

Используем consul API, и выполним проверку того же самого:

$ curl localhost:8500/v1/catalog/nodes
[
    {
        "ID": "fdbdd7ea-9e81-0604-7ba6-1c0dc57c5e73",
        "Node": "localhost.localdomain",
        "Address": "192.168.13.219",
        "Datacenter": "dc1",
        "TaggedAddresses": {
            "lan": "192.168.13.219",
            "wan": "192.168.13.219"
        },
        "Meta": {
            "consul-network-segment": ""
        },
        "CreateIndex": 5,
        "ModifyIndex": 6
    }
]
$

ИЛИ, можно использовать:

# curl -s localhost:8500/v1/catalog/nodes | jq .

Consul умеет работать с запросами по DNS протоколу и при этом, вы можете юзать любой DNS-клиент для запросов. Данный DNS сервис (или как можно его еще назвать — интерфейс) распологается на локалхосте с 8600 портом. Консул может обрабатывать не толкьо простые запросы, но его можно использовать как resolver (для прозрачногоразрешения имен) и тем самым, проксируя внешние запросы на DSN сервер и дает возможность использовать  запросы в приватной зоне .consul самостоятельно. Для реализации примитивной DNS-балансировки в случае присутствия в каталоге нескольких сервисов с одинаковым именем и разными IP-адресами Consul случайно перемешивает IP-адреса в ответе.
Помимо прямого запроса на разрешение доменного имени в рамках кластера можно выполнять поиск (lookup). Поиск может быть выполнен как для сервиса (service lookup), так и для узла кластера (node lookup).
Формат доменного имени при DNS-запросе в рамках consul-кластера жестко определен и не подлежит изменению.

Используем DNS, и выполним проверку:

$ dig @127.0.0.1 -p 8600 localhost.localdomain.node.consul

; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.1 <<>> @127.0.0.1 -p 8600 localhost.localdomain.node.consul
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2475
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;localhost.localdomain.node.consul. IN	A

;; ANSWER SECTION:
localhost.localdomain.node.consul. 0 IN	A	192.168.13.219

;; Query time: 0 msec
;; SERVER: 127.0.0.1#8600(127.0.0.1)
;; WHEN: Mon Dec 18 22:29:57 EET 2017
;; MSG SIZE  rcvd: 78

Где:

• localhost.localdomain — доменное имя сервера.

Добавление служб под consul

Первое что нужно сделать — создать папку для конфигов:

# mkdir -p /etc/consul.d

И так, для примера, я возьму службу nginx и установлю ее:

# yum install nginx -y

Создаем конфиг, дял проверки сервиса nginx:

# vim /etc/consul.d/nginx.json

И прописываем:

{"service":
    {
    	"name": "nginx",
    	"tags": ["nginx"],
    	"port": 80
    }
}

Health check — это периодически выполняемая операция, по результатам которой можно определить состояние проверяемой системы. По факту это автоматический мониторинг, который поддерживает состояние кластера в работоспособном состоянии, вычищает неработающие узлы и сервисы и возвращает их в работу по факту восстановления работоспособности.

Consul поддерживает несколько видов проверок:

• Script check — запуск определенного скрипта на определенном узле с заданной периодичностью. В зависимости от кода выхода (любой отличный от нуля код будет означать, что проверка не прошла) включает или выключает узел или сервис.
• HTTP Check — проверка, которая пытается загрузить указанный URL, и в зависимости от кода ответа включает или выключает проверяемый объект (любые 2xx — все нормально, код 429 Too Many Requests генерирует предупреждение, остальные коды говорят об ошибке).
• TCP Check — проверка, которая пробует установить tcp-соединение с заданным интервалом к указанному адресу и порту. Невозможность установить соединение означает, что проверка не пройдена.
• TTL Check — проверка, которая должна периодически обновляться через HTTP API. Суть ее в том, что если некий сервис не обновил эту проверку в рамках определенного интервала, то он помечается как неработающий. Это пассивная проверка, то есть сервис сам должен периодически отчитываться о том, что он работает. Если за заданный интервал отчет не поступил, то проверка считается не пройденной.
• Docker Check — проверка для сервисов, работающих в docker-контейнерах. Consul, используя Docker Exec API, может выполнить скрипт, находящийся внутри контейнера. Результат проверки будет зависеть от кода выхода, любой отличный от нуля “провалит” проверку.

Проверим валидацию:

# consul validate /etc/consul.d/nginx.json
Config validation failed: data_dir cannot be empty

ИЛИ:

# consul agent -config-file=/etc/consul.d/nginx.json
==> data_dir cannot be empty

Запускаем:

# consul agent -dev -bind 192.168.13.219 -encrypt VwrJ/imSBeqpoJrxUsRFUA== --config-dir /etc/consul.d

Где:

• -encrypt VwrJ/imSBeqpoJrxUsRFUA== — Эта опция для шифровки (Данный ключ получен командой: # consul keygen).
• —config-dir /etc/consul.d — Путь где лежат службы для мониторинга.

Приведу пример вывода:

.........
    2017/12/18 22:54:28 [DEBUG] consul: Skipping self join check for "localhost.localdomain" since the cluster is too small
    2017/12/18 22:54:28 [INFO] consul: member 'localhost.localdomain' joined, marking health alive
    2017/12/18 22:54:28 [DEBUG] Skipping remote check "serfHealth" since it is managed automatically
    2017/12/18 22:54:28 [INFO] agent: Synced service "nginx"
    2017/12/18 22:54:28 [DEBUG] agent: Node info in sync
.........

Как видно с лога, все синкается консулом!

Добавление сервиса через REST API

HTTP REST API является основным средством управления кластером Сonsul и предоставляет очень широкий диапазон возможностей. В рамках API реализовано 10 endpoints, каждый из которых предоставляет доступ к конфигурации определенного функционального аспекта Consul. Подробное описание всех edpoints есть в документации Consul, а мы кратко опишем каждый из них для представления о возможностях API:

• acl — контроль доступа. Как можно понять из названия, acl управляет контролем доступа к сервисам Consul. Мы можем регулировать доступ на получение и изменение данных о сервисах, узлах, пользовательских событиях, а также управлять доступом к k/v-хранилищу.
• agent — управление агентом Consul. Управление локальным агентом Consul. Все операции, доступные на этом endpoint, затрагивают данные локального агента. Можно получить информацию о текущем состоянии агента, его роли в кластере, а также получить доступ к управлению локальными сервисами. Изменения, выполненные над локальными сервисами, будут синхронизированы со всеми узлами кластера.
• catalog — управление узлами и сервисами кластера. Управление глобальным реестром Consul. Здесь сосредоточена работа с узлами и сервисами. В рамках этого endpoint можно регистрировать и отключать сервисы и, в случае работы с сервисами, использование этого раздела более предпочтительно нежели работа через agent. Работа через catalog проще, понятнее и способствует анти-энтропии.
• coordinate — сетевые координаты. Consul использует сетевую томографию для вычисления сетевых координат. Эти координаты используются для построения эффективных маршрутов в рамках кластера и многих полезных функций, таких как, например, поиск ближайшего узла с заданным сервисом или переключение на ближайший датацентр в случае аварии. Функции API в этом разделе используются только для получения информации о текущем состоянии сетевых координат.
• event — пользовательские события. Обработка пользовательских событий. Пользовательские события используются для выполнения каких-либо действий в рамках кластера: например для автоматического деплоя, перезапуска сервисов, запуска определенных скриптов или иных действий в рамках процесса оркестрации.
• health — проверки доступности. Проверка текущего состояния узлов и сервисов. Данный endpoint используется только для чтения и возвращает текущее состояние узлов и сервисов, а также списки выполняемых проверок.
• kv — Key/Value хранилище. Этот endpoint имеет только один метод и используется для управления данными в распределенном key/value-хранилище, предоставленным Consul. Единственный метод в этом endpoint выглядит так: /v1/kv/[key]. Разница в обработке заключается в методе запроса. GET вернет значение по ключу, PUT сохранит новое значение или перезапишет старое, а DELETE удалит запись.
• query — подготовленные запросы. Управление подготовленными запросами (Prepared queries). Подобные запросы позволяют выполнять сложные манипуляции над конфигурацией Consul и могут быть сохранены и выполнены позже. Сохраненным запросам присваивается уникальный ID. C его помощью запрос может быть выполнен в любое время без необходимости повторной подготовки.
• session — сессии. Механизм сессий в Consul используется для построения распределенных блокировок. Сессии представляют собой связующий слой между узлами, выполняемыми проверками и k/v-хранилищем. У каждой сессии есть имя и оно может быть сохранено в хранилище. Имя используется для реализации блокировок в рамках последовательных действий с узлами и сервисами в конкурентном режиме. Механизм работы сессий описан в документации Consul.
• status — статус системы. Этот endpoint используется для получении информации о статусе кластера. Здесь можно узнать текущего лидера и получить информацию обо всех участниках кластера.

На ноде которой хотим что-то отмониторить (консулом), выполняем:

# curl -XPUT -d @req.json http://192.168.13.219:8500/v1/agent/service/register

Где:

• req.json — Это json в котором хранится регистрация службы. Пример я приводил выше, с использованием nginx.

Важно! Сервисы нужно добавлять через агент, который крутится на той же машине, что и сам сервис.

Выполним проверку всех сервисов следующей командой:

# curl -s localhost:8500/v1/catalog/services | python -m json.tool
{
    "consul": [],
    "nginx": [
        "nginx"
    ]
}

Или, если нужно проверить только конкретный сервис (на примере nginx),  то команда будет иметь вид:

# curl -s localhost:8500/v1/catalog/service/nginx | python -m json.tool
[
    {
        "Address": "192.168.13.219",
        "CreateIndex": 6,
        "Datacenter": "dc1",
        "ID": "e0cb60c3-5388-5ea8-bd80-55feee66b087",
        "ModifyIndex": 6,
        "Node": "localhost.localdomain",
        "NodeMeta": {
            "consul-network-segment": ""
        },
        "ServiceAddress": "",
        "ServiceEnableTagOverride": false,
        "ServiceID": "nginx",
        "ServiceName": "nginx",
        "ServicePort": 80,
        "ServiceTags": [
            "nginx"
        ],
        "TaggedAddresses": {
            "lan": "192.168.13.219",
            "wan": "192.168.13.219"
        }
    }
]

И еще, давайте дерним сервис и через DNS:

# dig @127.0.0.1 -p 8600 nginx.service.consul

; <<>> DiG 9.9.4-RedHat-9.9.4-51.el7_4.1 <<>> @127.0.0.1 -p 8600 nginx.service.consul
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41237
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nginx.service.consul.		IN	A

;; ANSWER SECTION:
nginx.service.consul.	0	IN	A	192.168.13.219

;; Query time: 0 msec
;; SERVER: 127.0.0.1#8600(127.0.0.1)
;; WHEN: Mon Dec 18 23:01:42 EET 2017
;; MSG SIZE  rcvd: 65

Работает как-то….

Хранилище ключ-значение (KV Store)

Хранилище, предоставляемое Consul является распределенной key-value базой данных и может использоваться для сохранения любых данных, доступных для любого участника кластера (в соответствии с правилами ACL, конечно же). Сервисы могут сохранять в этом хранилище данные, которые необходимы для других участников кластера. Это могут быть значения конфигурационных опций, результаты каких-либо вычислений или, как мы указали выше, k/v-хранилище может использоваться для реализации распределенных блокировок при помощи механизма сессий. Использование k/v-хранилища позволит нам сделать кластер более эффективным и уменьшить процент ручного вмешательства. Сервисы могут корректировать свое состояние в зависимости от информации в хранилище, гарантированно предоставленным кластером. Обратите внимание: не стоит сохранять в это хранилище какие-либо данные, связанные с бизнес-логикой ваших сервисов. Хранилище, предоставляемое Consul, используется для хранения и распространения метаинформации о состоянии участников кластера, а не о данных, которые они обрабатывают.

Проверим что имеется на данный момент в сторе:

# curl -v http://localhost:8500/v1/kv/?recurse

* About to connect() to localhost port 8500 (#0)
*   Trying ::1...
* Connection refused
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8500 (#0)
> GET /v1/kv/?recurse HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:8500
> Accept: */*
>
< HTTP/1.1 404 Not Found
< X-Consul-Index: 1
< X-Consul-Knownleader: true
< X-Consul-Lastcontact: 0
< Date: Mon, 18 Dec 2017 21:03:38 GMT
< Content-Length: 0
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host localhost left intact

Ага, ничего нет… Видно с вывода ошибки 404…

Сейчас добавлю чет:

# curl -X PUT -d 'test' http://localhost:8500/v1/kv/nginx/key_1
true

# curl -X PUT -d 'test' http://localhost:8500/v1/kv/nginx/key_2?flags=66
true

# curl -X PUT -d 'test' http://localhost:8500/v1/kv/nginx/sub/key_3
true

И проверям что у нас вышло:

# curl -s -v http://localhost:8500/v1/kv/?recurse | python -m json.tool


* About to connect() to localhost port 8500 (#0)
*   Trying ::1...
* Connection refused
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8500 (#0)
> GET /v1/kv/?recurse HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:8500
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< X-Consul-Index: 53
< X-Consul-Knownleader: true
< X-Consul-Lastcontact: 0
< Date: Mon, 18 Dec 2017 21:07:46 GMT
< Content-Length: 515
<
{ [data not shown]
* Connection #0 to host localhost left intact
[
    {
        "CreateIndex": 51,
        "Flags": 0,
        "Key": "nginx/key_1",
        "LockIndex": 0,
        "ModifyIndex": 51,
        "Value": "dGVzdA=="
    },
    {
        "CreateIndex": 52,
        "Flags": 66,
        "Key": "nginx/key_2",
        "LockIndex": 0,
        "ModifyIndex": 52,
        "Value": "dGVzdA=="
    },
    {
        "CreateIndex": 53,
        "Flags": 0,
        "Key": "nginx/sub/key_3",
        "LockIndex": 0,
        "ModifyIndex": 53,
        "Value": "dGVzdA=="
    }
]

Дерну только один какй-то ключик:

# curl -s -v http://localhost:8500/v1/kv/nginx/sub/key_3 | python -m json.tool


* About to connect() to localhost port 8500 (#0)
*   Trying ::1...
* Connection refused
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8500 (#0)
> GET /v1/kv/nginx/sub/key_3 HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:8500
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< X-Consul-Index: 53
< X-Consul-Knownleader: true
< X-Consul-Lastcontact: 0
< Date: Mon, 18 Dec 2017 21:09:11 GMT
< Content-Length: 176
<
{ [data not shown]
* Connection #0 to host localhost left intact
[
    {
        "CreateIndex": 53,
        "Flags": 0,
        "Key": "nginx/sub/key_3",
        "LockIndex": 0,
        "ModifyIndex": 53,
        "Value": "dGVzdA=="
    }
]

Удалить ключ можно следующим образом:

# curl -s -v -X DELETE http://localhost:8500/v1/kv/nginx/key_1

* About to connect() to localhost port 8500 (#0)
*   Trying ::1...
* Connection refused
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8500 (#0)
> DELETE /v1/kv/nginx/key_1 HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:8500
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Mon, 18 Dec 2017 21:10:10 GMT
< Content-Length: 5
<
true
* Connection #0 to host localhost left intact

Проверим:

# curl -s -v http://localhost:8500/v1/kv/nginx/key_1 | python -m json.tool


* About to connect() to localhost port 8500 (#0)
*   Trying ::1...
* Connection refused
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8500 (#0)
> GET /v1/kv/nginx/key_1 HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:8500
> Accept: */*
>
< HTTP/1.1 404 Not Found
< X-Consul-Index: 66
< X-Consul-Knownleader: true
< X-Consul-Lastcontact: 0
< Date: Mon, 18 Dec 2017 21:10:47 GMT
< Content-Length: 0
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host localhost left intact
No JSON object could be decoded

Чтобы удалить все данные, служит следующая команда:

# curl -s -v -X DELETE http://localhost:8500/v1/kv/nginx/?recurse


* About to connect() to localhost port 8500 (#0)
*   Trying ::1...
* Connection refused
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8500 (#0)
> DELETE /v1/kv/nginx/?recurse HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:8500
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: application/json
< Date: Mon, 18 Dec 2017 21:11:42 GMT
< Content-Length: 5
<
true
* Connection #0 to host localhost left intact

Сново проверим что вышло:

# curl -s -v http://localhost:8500/v1/kv/?recurse

* About to connect() to localhost port 8500 (#0)
*   Trying ::1...
* Connection refused
*   Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 8500 (#0)
> GET /v1/kv/?recurse HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:8500
> Accept: */*
>
< HTTP/1.1 404 Not Found
< X-Consul-Index: 73
< X-Consul-Knownleader: true
< X-Consul-Lastcontact: 0
< Date: Mon, 18 Dec 2017 21:12:01 GMT
< Content-Length: 0
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host localhost left intact

Да, все данные были удалены.

Можно изменять ваью для конкретного ключа:

# curl -X PUT -d 'test' http://localhost:8500/v1/kv/nginx/key_1
true

Можно проверить значение следующим образом:

# curl -s http://localhost:8500/v1/kv/nginx/key_1 | python -m json.tool| grep Value| cut -d":" -f 2| tr -d '"'| tr -d " "| base64 --decode
test

Т.е я декодировал его!

Проверим еще раз:

# curl -X PUT -d '2d test' http://localhost:8500/v1/kv/nginx/key_1
true

# curl -s http://localhost:8500/v1/kv/nginx/key_1 | python -m json.tool| grep Value| cut -d":" -f 2| tr -d '"'| tr -d " "| base64 --decode
2d test

Все четко и работает.

Веб ГУЙ для consul

Чтобы запустить веб мордочку для consul, нужно выполнить:

# consul agent -dev -bind 192.168.13.219 --config-dir /etc/consul.d -ui -client=192.168.13.219

После чего, открываем урл:

http://192.168.13.219:8500/ui

Т.к у меня консул на виртуальной машине и крутится на локалхосте/локальный IP, то логично сделать SSH тоннель на реальную машину следующим образом:

$ ssh -L 8500:192.168.13.219:8500 captain@192.168.13.219

Где:

• 8500 — Порт который откроется на вашей машине.
• 192.168.13.219:8500 — Создаст SSH тоннель для указанного IP + порта.
• captain@192.168.13.219 — Собственно, — логин (юзер) и IP сервера.

Вот что вышло:

Все выглядит просто и наглядно!

Настройка Consul в Unix/Linux

Первое что нужно сделать — создать папку для конфигов (если еще не создавали. Но это не так, т.к вышле это должно было выполняться):

# mkdir -p /etc/consul.d

Мой конфиг, выглядит следующим образом:

# cat  /etc/consul.d/20-agent.json

{
"server": true,
"datacenter": "dc1",
"bootstrap_expect": 3,
"data_dir": "/tmp/consul",
"log_level": "INFO",
"node_name": "consul-server1",
"addresses": {
	"http": "192.168.13.219"
	},
"acl_datacenter": "dc1",
"acl_default_policy": "deny",
"acl_master_token": "master_token_test",
"acl_down_policy":"deny",
"acl_token": "anonymous"
}

Проверяем:

# consul validate /etc/consul.d/20-agent.json

Configuration is valid!

Можно запускать и использовать.

Вот и все, статья «Установка Consul в Unix/Linux» завершена.