HashiCorp — Consul

Thank you for reading this post, don't forget to subscribe!

HashiCorp — Consul. Пожа­луй, это один из клю­че­вых про­грамм­ных про­дук­тов для HashiCorp. Он обес­пе­чи­ва­ет реги­стра­цию, дере­ги­стра­цию и хра­не­ние инфор­ма­ции о рабо­та­ю­щих IT сер­ви­сах в сети орга­ни­за­ции. Так­же он пред­став­ля­ет собой хра­ни­ли­ще KeyValue дан­ных. Такая свое­об­раз­ная СУБД вку­пе с досту­пом к ней через про­то­кол HTTP дела­ет Consul эффек­тив­ным инстру­мен­том в совре­мен­ной IT инфра­струк­ту­ре. Боль­шин­ство осталь­ных про­дук­тов HashiCorp может исполь­зо­вать Consul в каче­стве бек­эн­да для хра­не­ния сво­ей инфор­ма­ции. Это каса­ет­ся и Terraform, и Vault, и Nomad. Полу­ча­ет­ся свое­об­раз­ная коопе­ра­ция, даю­щая воз­мож­ность орга­ни­зо­вать отка­зо­устой­чи­вость и рас­пре­де­лен­ность про­дук­тов HashiCorp. При этом ана­ло­гич­ная мето­ди­ка может быть при­ме­не­на и исполь­зо­ва­на в сто­рон­них про­грамм­ных про­дук­тах для орга­ни­за­ции хра­не­ния информации.

Сра­зу же хоте­лось бы обо­зна­чить сфе­ру при­ме­не­ния Consul. Как бы он хорош не был — дале­ко не всем он будет нужен или при­не­сет замет­ную поль­зу. Дан­ный про­грамм­ный про­дукт будет наи­бо­лее инте­ре­сен тем, кто исполь­зу­ет в сво­ей инфра­струк­ту­ре мик­ро­сер­вис­ную архи­тек­ту­ру, а так­же удоб­ным, как писал выше, в соче­та­нии с про­чи­ми про­дук­та­ми HashiCorp. Функ­ци­о­нал Service Discovery, кото­рый явля­ет­ся основ­ным в рабо­те Consul, исполь­зу­ет­ся во мно­гих IT ком­па­ни­ях, ори­ен­ти­ро­ван­ных на предо­став­ле­ние Highload сер­ви­сов. Если же Ваша орга­ни­за­ция зани­ма­ет­ся экс­плу­а­та­ци­ей стан­дарт­ных покуп­ных IT реше­ний, либо IT сер­ви­сов, бази­ру­ю­щих­ся на моно­лит­ной архи­тек­ту­ре, то ско­рее все­го про­грамм­ное обес­пе­че­ние Consul будет не акту­аль­ным для Вас.

Как запустить

Суще­ству­ет 2 вер­сии HashiCorp Consul — Open Source и Enterprise. Если пер­вая доступ­на бес­плат­но абсо­лют­но всем, то вто­рая с доба­воч­ным функ­ци­о­на­лом уже сто­ит денег и тре­бу­ет покуп­ки соот­вет­ству­ю­щих лицензий.

Соглас­но рефе­ренсной архи­тек­ту­ры, нам необ­хо­ди­мы 3 вир­ту­аль­ные маши­ны на базе Linux, кото­рые будут исполь­зо­вать­ся для созда­ния кла­сте­ра Consul. На них уста­нав­ли­ва­ет­ся бинар­ник Consul, кото­рый ска­чи­ва­ет­ся с сай­та https://releases.hashicorp.com/consul. При этом нуж­но выбрать тре­бу­е­мую вер­сию соф­та и исполь­зу­е­мую архи­тек­ту­ру. К сло­ву ска­зать, один и тот же бинар­ник исполь­зу­ет­ся как на сер­ве­рах кла­сте­ра Consul, так и на кли­ент­ских маши­нах, кото­рые обра­ща­ют­ся к дан­но­му кла­сте­ру через дан­ный уста­нов­лен­ный агент. После того, как нуж­ный бинар­ник зака­чан и поме­щен в дирек­то­рию /usr/bin/ на сер­ве­рах кла­сте­ра, нам нуж­но создать фай­лы настро­ек Consul. К сожа­ле­нию из короб­ки ниче­го кро­ме испол­ня­е­мо­го фай­ла от Hashicrop мы не полу­чим. При­ве­ду в каче­стве при­ме­ра сле­ду­ю­щие конфигурации.

Файл /etc/consul.d/config.json, в кото­ром опи­сы­ва­ют­ся основ­ные пара­мет­ры рабо­ты Consul на сер­ве­ре. В част­но­сти ука­зы­ва­ет­ся ip адрес, к кото­ро­му будет при­вя­зан сер­вис, а так­же ip адре­са всех сер­ве­ров Consul в кластере.

В фай­ле /etc/systemd/system/consul.service про­пи­сы­ва­ем пара­мет­ры для запус­ка и управ­ле­ния рабо­той сер­ви­са Consul в системе.

Созда­ем отдель­но­го поль­зо­ва­те­ля и групу для запус­ка Consul, так­же про­во­дим необ­хо­ди­мые мани­пу­ля­ции с раз­ре­ше­ни­я­ми фай­лов. После это­го по сути мож­но запус­кать кла­стер в работу.

Как использовать

Итак, когда сер­ве­ра Consul рабо­та­ют, мож­но попро­бо­вать полу­чить от них то, для чего они пред­на­зна­че­ны. Это преж­де все­го Service Discovery. Consul предо­став­ля­ет несколь­ко вари­ан­тов вза­и­мо­дей­ствия с кла­сте­ром в этом процессе.

Во-пер­вых, реги­стра­ция рабо­ты тех или иных сер­ви­сов с помо­щью спе­ци­аль­ных кон­фи­гу­ра­ци­он­ных фай­лов на вир­ту­ал­ках, где уста­нов­лен Consul агент. Так же с помо­щью обра­ще­ния напря­мую к аген­ту мож­но как узна­вать о рабо­то­спо­соб­но­сти сер­ви­сов в сети, так и реги­стри­ро­вать их в системе.

Ниже при­мер кон­фи­гу­ра­ци­он­но­го фай­ла, кото­рый в руч­ном режи­ме реги­стри­ру­ет сер­вис в Consul.

В дан­ной кон­фи­гу­ра­ции ука­зан сер­вис в при­вяз­ке к ip адре­су и пор­ту, где он рабо­та­ет, а так­же спо­соб про­вер­ки его жиз­не­де­я­тель­но­сти с помо­щью ути­ли­ты curl. Если ука­зан­ная в кон­фи­гу­ра­ции про­вер­ка будет неуспеш­на, то сер­вис авто­ма­ти­че­ски будет дерегистрирован.

Во-вто­рых, исполь­зо­ва­ние HTTP API интер­фей­са систе­мы Consul. С помо­щью это­го API так­же мож­но реги­стри­ро­вать, дере­ги­стри­ро­вать сер­ви­сы, а так­же полу­чать инфор­ма­цию об их ста­ту­се. С помо­щью HTTP API по сути любое при­ло­же­ние само в авто­ма­ти­че­ском режи­ме может уве­дом­лять о сво­ем ста­ту­се, поз­во­ляя эффек­тив­но мас­шта­би­ро­вать при­ло­же­ния с мил­ли­о­на­ми пользователей.

В-тре­тьих, DNS интер­фейс Consul, поз­во­ля­ет полу­чать инфор­ма­цию из его базы дан­ных с помо­щью обыч­ных DNS запро­сов любо­му кли­ен­ту в сети. С помо­щью неслож­ных мани­пу­ля­ций мож­но инте­гри­ро­вать Consul с внут­рен­ни­ми DNS сер­ве­ра­ми орга­ни­за­ции. Это поз­во­ля­ет абсо­лют­но про­зрач­но при­ло­же­ни­ям исполь­зо­вать Service Discovery без каких-либо изме­не­ний внут­ри кода.

Так, к при­ме­ру, что­бы узнать ip адрес сер­ви­са test-service, кото­рый мы ранее заре­ги­стри­ро­ва­ли в нашей Service Discovery систе­ме, мож­но вос­поль­зо­вать­ся запро­сом типа A к DNS систе­ме в зоне service.consul. Вывод коман­ды dig пред­став­лен ниже. Надо доба­вить, что по умол­ча­нию сер­ви­сы реги­стри­ру­ют­ся в DNS в под­зоне service.consul. В слу­чае необ­хо­ди­мо­сти наиме­но­ва­ние этой зоны мож­но перенастроить.

dig test-service.service.consul