Публикувано на 15 август 2014 г. 2 версии

Въведение

Consul е разпределена, високодостъпна система за откриване и конфигуриране на услуги, базирана на центрове за данни. Може да се използва за представяне на услуги и възли в гъвкав и мощен интерфейс, който позволява на клиентите винаги да имат актуален изглед на инфраструктурата, от която са част.

Консул предоставя много различни функции, които се използват за предоставяне на последователна и достъпна информация за вашата инфраструктура. Това включва механизми за откриване на услуги и възли, система за маркиране, проверки на състоянието, базирани на консенсус изборни процедури, общосистемно съхранение на ключ/стойност и др. Използвайки консул във вашата организация, можете лесно да изградите сложно ниво на информираност за вашите приложения и услуги.

В последното ни ръководство предоставихме бърза демонстрация на някои от функционалностите на консула. В това ръководство ще започнем със създаването на готова за производство конфигурация на консула, която може да се използва за започване на внедряването на откриване на услуги за вашата инфраструктура.

Предпоставки и цели

В тази серия ще създадем система от сървъри, които ще могат да комуникират помежду си и да поддържат сервизна информация, пулове за съхранение ключ/стойност и други подробности за клиентските машини. Първите стъпки към подготовката на нашата система ще бъдат направени в това ръководство, тъй като ние инсталираме софтуера и автоматизираме някои от нашата конфигурация.

Консулската документация препоръчва да имате или 3, или 5 консул сървъри работи във всеки център за данни, за да се избегне загуба на данни в случай на отказ на сървър. Консул сървърите са компонентът, който прави тежката работа. Те съхраняват информация за услуги и информация за ключ/стойност. Необходим е нечетен брой сървъри, за да се избегнат задънени ситуации по време на избори.

Освен сървърите на консула могат да работят и други машини консул агенти. Консулските агенти са много леки и просто препращат заявки към сървърите. Те предоставят метод за изолиране на вашите сървъри и разтоварват отговорността за познаване на адресите на сървърите към самите агенти.

За да приложим някои от механизмите за сигурност в по-късно ръководство, трябва да назовем всички наши машини в рамките на един домейн. Това е така, че да можем да издадем заместващ SSL сертификат по-късно.

Подробностите за нашите машини са тук:

Роля на IP адреса на хоста
server1.example.com 192.0.2.1 bootstrap консул сървър
server2.example.com 192.0.2.2 консул сървър
server3.example.com 192.0.2.3 консул сървър
agent1.example.com 192.0.2.50 консул клиент

За тази демонстрация ще използваме 64-битови сървъри на Ubuntu 14.04, но всеки съвременен Linux сървър трябва да работи еднакво добре. Когато конфигурацията завърши, трябва да имате система, която да ви позволи лесно да добавяте услуги, проверки и възли.

Влезте във вашите машини като root потребител, за да изпълните стъпките в това ръководство.

Изтегляне и инсталиране на Consul

Ако още не сте инсталирали консул в първоначалното въведение в ръководството за консул, ще трябва да го направите сега. Ще инсталираме консул като приложение на системно ниво на всяка от четирите машини, които конфигурираме.

Преди да разгледаме приложението на консула, трябва да разархивираме, за да извлечем изпълнимия файл. Актуализирайте кеша на локалните системни пакети и след това инсталирайте пакета с помощта на apt:

Сега можем да вземем програмата за консул. Страницата на проекта на консула предоставя връзки за изтегляне към двоични пакети за Windows, OS X и Linux.

Отидете на страницата по-горе и щракнете с десния бутон върху операционната система и архитектурата, която представлява вашите сървъри. В това ръководство, тъй като използваме 64-битови сървъри, ще използваме връзката “amd64” под “linux”. Изберете „копиране на местоположението на връзката“ или друга подобна опция, която предлага браузърът ви.

Във вашия терминал преминете към директорията/usr/local/bin, където ще запазим изпълнимия файл. Въведете wget и интервал и след това поставете URL адреса, който сте копирали от сайта:

Сега можем да извлечем двоичния пакет, като използваме командата unzip, която инсталирахме по-рано. След това можем да премахнем компресирания файл:

Вече трябва да имате командата на консула на разположение на всичките си сървъри.

Създайте необходимата директория и структурата на системата

Можем лесно да изпробваме консула по неструктуриран начин, като използваме командата консул. Това ще ви позволи да тествате някои функционалности. Направихме това в последното ръководство, за да се запознаем със софтуера.

Ние обаче ще се опитаме да създадем по-надеждна система, която е по-лесна за управление, така че ще създадем някаква структура, която да направи тази работа. Изпълнете следните стъпки на всеки от вашите компютри (сървъри и клиенти).

Първото нещо, за което трябва да се погрижим, е да създадем потребител, специфичен за нашата задача. Това е стандартен случай на разделяне на привилегиите на потребителя, така че ние ще стартираме нашите консулски процеси със специален потребител.

Създайте потребителя сега, като напишете:

Можете да пропуснете всички подкани (може да искате да зададете парола. Тя ще се оплаче в противен случай), ако искате.

След това ще създадем конфигурационната йерархия, която ще съхранява различните конфигурации, които ще използваме в зависимост от начина, по който искаме да стартираме услугата. За да улесним това, ще направим родителска директория consul.d в конфигурационната структура/etc и ще поставим поддиректории, наречени bootstrap, server и client под това на всяка система:

По-късно можем да поставим нашите конфигурации във всяка от тях. Всеки сървър вероятно ще използва най-много две от тези директории, но ние ще създадем структурата за последователност на всеки хост.

Също така трябва да създадем място, където консулът може да съхранява постоянни данни между рестартиране. За тази цел ще създадем директория в/var/consul и ще я дадем на потребителя на консула, за да може той да управлява данните:

С тази структура на място, ние трябва да можем да започнем да създаваме нашите конфигурационни файлове.

Създаване на Bootstrap конфигурация

Първата конфигурация, която трябва да създадем, е за зареждане на клъстера. Това не е много често срещано събитие, тъй като е необходимо само за първоначално създаване на клъстера. Ние обаче ще създадем конфигурационния файл, за да можем бързо да започнем отново, в случай че клъстерът изпадне напълно.

Можете да поставите този конфигурационен файл само на един от вашите консулски сървъри или на всички тях, за да ви даде повече възможности за зареждане. Ще го поставим само на server1 за тази демонстрация.

Конфигурационните файлове се съхраняват в прост JSON, така че са доста лесни за управление. Създайте първия файл в поддиректорията на bootstrap:

В този файл можем да започнем, като посочим, че когато се използва тази конфигурация, консулът трябва да стартира като сървър в режим на bootstrap:

Трябва също да посочим центъра за данни, където ще живее нашият клъстер. Това може да е всяко име, което ви помага да идентифицирате физическото местоположение на клъстера. Consul е запознат с центъра за данни и тези обозначения ще ви помогнат да организирате различните си клъстери по център за данни.

Също така можем да преминем в директорията с данни, която създадохме в/var/consul. Консулът ще използва това, за да съхранява информация за състоянието на клъстера:

След това искаме да приложим някакво криптиране към протокола за шепот, който консулът използва. Той има тази функционалност, вградена с помощта на споделена тайна система. Тайната трябва да бъде 16-битов низ, кодиран в base-64. За да получим стойност, подходяща за тази стойност, временно ще излезем от файла.

В терминала можем да използваме командата consul, за да генерираме ключ с необходимата дължина и кодиране. Тип:

Копирайте генерираната стойност и отворете отново конфигурационния файл:

Използвайте копирания низ като стойност за параметъра за криптиране:

И накрая, ще добавим допълнителна информация, за да посочим нивото на регистрационния файл и да посочим, че искаме да използваме syslog за регистриране:

Запазете и затворете файла, когато приключите.

Създаване на редовна конфигурация на сървъра

Сега, след като завършим нашата конфигурация на bootstrap, можем да я използваме като основа за нашата обща конфигурация на сървъра. Конфигурацията на сървъра ще се използва, след като клъстерът бъде стартиран.

Започнете с копиране на файла за зареждане от server1 в поддиректория на сървъра на тази машина за редактиране:

Отворете файла, за да направите необходимите промени:

За да започнем, трябва да изключим флага на bootstrap, тъй като тази конфигурация е за конфигурации, които не са bootstrap.

Единственото нещо, което трябва да модифицираме за конфигурацията на сървъра, е да посочим IP адресите на другия сървър, към които този възел трябва да се опита да се присъедини, когато стартира. Това се грижи за автоматичното присъединяване, така че да не се налага да се присъединяваме ръчно към клъстера след стартиране на нашия сървър:

Параметърът за криптиране трябва да бъде еднакъв за всички участници в системата, така че копирането на файла вече се е погрижило за това изискване за нас. Имайте това предвид, когато създавате нови конфигурации.

Запазете файла, когато приключите.

Трябва да копирате съдържанието на този конфигурационен файл на другите машини, които ще действат като ваши консулски сървъри. Поставете ги във файл на /etc/consul.d/server/config.json точно както направихте в първия хост.

Единствената стойност, която трябва да промените на другите хостове, е IP адресите, с които той трябва да се опита да се свърже. Трябва да се уверите, че той се опитва да се свърже с първия сървър, вместо със собствения си IP. Например, вторият сървър в нашия пример ще има файл, който изглежда така:

Запазете и затворете файловете, които сте създали, когато приключите.

Създаване на клиентска конфигурация

Сега всички наши сървърни конфигурации са завършени. Можем да се съсредоточим върху това да подготвим и работи нашата клиентска машина с правилна конфигурация.

Отворете конфигурационен файл под клиентската директория на клиентската машина:

Отново ще използваме предишна конфигурация като основа за новата ни конфигурация. Копирайте съдържанието на един от сървърните файлове в този файл.

Ще започнем, като премахнем всяко споменаване на параметъра bootstrap, тъй като това се отнася само за конфигурациите на сървъра и промяната на параметъра на сървъра на false.

След това ще добавим параметър, указващ местоположението на директорията на уеб потребителския интерфейс. След малко ще придобием необходимите за това файлове. Мястото, където ще пребивават, е/home/консул/dist .

И накрая, искаме да коригираме параметъра start_join, за да изброява всички наши сървъри:

Запазете и затворете файла, когато приключите.

Изтегляне на уеб потребителски файлове

След като конфигурирахме клиента да обслужва уеб потребителския интерфейс, трябва да придобием действителните файлове, които ще ни позволят да направим това.

На уебсайта на консула щракнете с десния бутон на мишката върху връзката към уеб потребителския интерфейс на консула и изберете „копиране на местоположението на връзката“ или друга подобна опция, която имате.

На клиента използвайте su, за да станете потребител на консул. Ще настроим уеб директорията в домашната директория на потребителя на консула.

Сега въведете wget, последвано от интервал и поставете връзката, която сте копирали за изтегляне на уеб потребителския интерфейс. По време на писането това ще изглежда така:

Разархивирайте изтегления файл и премахнете zip файла:

Това ще създаде директория, наречена dist във вашата домашна директория. Това е директорията, към която насочихме параметъра на уеб потребителския интерфейс в конфигурационния файл.

Преди да продължим, трябва да излезете от сесията на потребителя на консула, за да се върнете в основната сесия:

Създайте скрипт за нов старт

Вече разполагаме с нашите конфигурационни файлове. След това можем да се съсредоточим върху създаването на скрипт за стартиране, така че нашите консулски екземпляри да се стартират автоматично при зареждане и да се рестартират в случай на проблем.

Тъй като стартирането на клъстер не е нещо, което ще трябва да правим често (през повечето време самият клъстер ще продължи и може да се наложи да се рестартира един възел и да се присъедини отново към клъстера), няма да включим фактора за зареждане в скрипта за стартиране. Скоро ще ви покажем как ръчно да завършите този процес.

Нашият скрипт за стартиране ще бъде подобен на нашите сървъри и на клиента. На един от сървърите на консула създайте файл в директорията/etc/init, за да съхраните вашата конфигурация на консула:

Ще копираме съдържанието на този файл на другите сървъри и след това ще го използваме като основа за конфигурацията на нашия клиент. В рамките на този файл първият бизнес ред е да се създаде описание на процеса. На нашите сървъри ще използваме:

След това посочваме условията, при които процесът ще започне. За тази услуга искаме услугата да започне, когато се монтира локалната файлова система и когато се изпълнява публичният мрежов интерфейс.

Също така искаме да уточним кога процесът трябва да спре. Използвайки стандартните нива на изпълнение на Linux, можем да му кажем да спре процеса, когато не е в някой от нормалните режими на работа (спиране на процеса при спиране или рестартиране на сървъра):

Можем да кажем на системата init да рестартира процеса, ако някога умре неочаквано. Също така искаме да посочим потребителя и групата, при които процесът трябва да се изпълнява. Не забравяйте, че създадохме потребителя и групата на консула, за да изолираме процеса:

И накрая, трябва да предоставим действителната команда, която искаме да изпълним. Това просто ще бъде командата на консула, изпълнявана в режим на агент. Ще преминем в директорията, която съдържа нашите спецификации за конфигурация на сървъра като аргумент на командата:

Запазете файла, когато приключите.

Копирайте съдържанието на този файл във файл, наречен /etc/init/consul.conf на всеки от вашите сървъри и на клиента.

На клиента трябва малко да модифицираме файла. Трябва да променим описанието, за да посочим факта, че това е клиентска машина. Също така трябва да променим конфигурационната директория, която се предава в действителната команда на консула.

Крайният файл трябва да изглежда по следния начин:

Запазете и затворете файла, когато приключите.

Начало на клъстера

Сега имаме всичко на място, за да създадем и работи бързо консулски клъстер. Процесът е сравнително прост.

На сървър, който съдържа конфигурационния файл на bootstrap (server1 в нашия случай), използвайте su, за да преминете за кратко към потребител на консул. След това можем да извикаме консул и да предадем в директорията на bootstrap като аргумент:

Услугата трябва да се стартира и да заеме прозореца на терминала. В режим bootstrap този сървър ще се самоизбере за лидер, създавайки основа за формиране на клъстера.

На вашите други консулски сървъри като root стартирайте консулската услуга, която току-що създадохме с скрипта за стартиране, като напишете:

Тези сървъри ще се свържат със заредения сървър, завършвайки клъстера. Към този момент имаме клъстер от три сървъра, два от които работят нормално, а един от тях е в режим на зареждане, което означава, че може да взема изпълнителни решения, без да се консултира с останалите сървъри.

Това не е това, което искаме. Искаме всеки от сървърите на еднаква основа. Сега, когато клъстерът е създаден, можем да изключим заредения екземпляр на консул и след това отново да влезем в клъстера като нормален сървър.

За да направите това, натиснете CTRL-C в терминала на заредения сървър:

Сега излезте обратно в основната си сесия и стартирайте консулската услуга, както направихте с останалите сървъри:

Това ще накара сървърът, стартиран преди това, да се присъедини към клъстера с непривилегировани привилегии, като доведе клъстера в крайното му състояние.

Сега, когато клъстерът е напълно работещ, клиентските машини могат да се свързват. На клиентската машина направете същата процедура като root:

Клиентът ще се свърже с клъстера като клиент. Можете да видите членовете на клъстера (сървъри и клиенти), като попитате консул за неговите членове на някоя от машините:

Свързване с уеб потребителския интерфейс

Конфигурирахме нашата клиентска машина да хоства уеб интерфейс към клъстера. Това обаче се обслужва на локалния интерфейс, което означава, че не е достъпен за нас чрез публичния интерфейс на машината.

За да получим достъп до уеб потребителския интерфейс, ще създадем SSH тунел към клиентската машина, която съдържа файловете на потребителския интерфейс. Консулът обслужва HTTP интерфейса на порт 8500. Ние ще тунелираме нашия локален порт 8500 към порта на клиентската машина 8500. На вашия локален компютър въведете:

Това ще се свърже с отдалечената машина, ще създаде тунел между нашия локален порт и отдалечения порт и след това ще постави връзката на заден план.

Във вашия локален уеб браузър вече можете да получите достъп до уеб интерфейса на консула, като напишете:

Това ще ви даде страницата за потребителски интерфейс по подразбиране:

производствена

Можете да използвате този интерфейс, за да проверите изправността на сървърите си и да получите преглед на вашите услуги и инфраструктура.

Когато приключите с използването на уеб потребителския интерфейс, можете да затворите SSH тунела. Потърсете номера на pid на процеса, като използвате командата ps и grep, за да потърсите номера на порта, който сме препратили:

Осветеният номер в изхода по-горе (на реда, който съдържа командата за тунелиране, която използвахме) е номерът на pid, който търсим. След това можем да предадем това на командата kill, за да затворим тунела:

Заключение

Вече трябва да имате стабилен начин за управление на вашите членове на консула. Консулският клъстер може да бъде стартиран и стартиран бързо и лесно. Допълнителни възли могат да бъдат конфигурирани бързо чрез копиране на конфигурационните файлове (конфигурация на консула и скрипт за стартиране) на съществуващите сървъри.

Въпреки че вече разполагаме с консулска среда, създадена по начин, който ни позволява лесно да управляваме нашите услуги, все още не сме осигурили напълно комуникацията си. В следващото ръководство ще се съсредоточим върху това как да настроим валидиране на SSL сертификат, за да криптираме и проверим RPC комуникациите на нашите членове.