Това е четвъртата публикация от поредицата блогове, подчертаваща новите функции в мрежата от услуги на Consul.
Миналия месец в HashiConf EU обявихме Консул 1.6.0. Тази версия предоставя набор от нови възможности за управление на трафика от ниво 7, включително разделяне на трафика L7, което позволява разполагане на канарски услуги.
Тази публикация в блога ще ви преведе през стъпките, необходими за разделяне на трафика между две услуги нагоре по веригата.
»Canary Deployments
Разгръщането на Canary е техника за внедряване на нова версия на услуга, като същевременно се избягва престой. По време на разгръщане на канарче прехвърляте малък процент от трафика към нова версия на услуга, като същевременно наблюдавате нейното поведение. Първоначално изпращате възможно най-малкото количество трафик към новата услуга, като същевременно генерирате значими данни за ефективността. С придобиването на доверие в новата версия бавно увеличавате дела на трафика, който обработва. В крайна сметка версията на канарчетата обработва 100% от целия трафик, като в този момент старата версия може да бъде напълно оттеглена и след това премахната от околната среда.
Новата версия на услугата се нарича канарска версия, като препратка към „канарчето в въглищна мина“.
За да определите правилната функция на новата услуга, трябва да имате възможност за наблюдение във вашето приложение. Данните за метрики и проследяване ще ви позволят да определите, че новата версия работи както се очаква, а не да изхвърля грешки. За разлика от внедряванията в синьо/зелено, които включват преминаване към нова версия на услуга в една стъпка, разполаганията на Canary използват по-постепенен подход, който ви помага да се предпазите от грешки в услугата, които се проявяват само с определен товар.
»Предпоставки
Стъпките в това ръководство използват функцията за мрежови услуги на Consul, Consul Connect. Ако все още не сте запознати с него, можете да научите повече, като следвате това ръководство.
Създадохме демо среда за стъпките, които описваме тук. Околната среда разчита на Docker и Docker Compose. Ако все още нямате Docker и Docker Compose, можете да ги инсталирате от страницата за инсталиране на docker.
" Околен свят
Демонстрационната архитектура, която ще използвате, се състои от 3 услуги, публична уеб услуга, две версии на услугата API и сървър Consul. Услугите представляват двустепенно приложение; уеб услугата приема входящ трафик и прави повикване нагоре към услугата API. Ще си представите, че версия 1 на услугата API вече работи в производствен и обработващ трафик и че версия 2 съдържа някои промени, които искате да изпратите в разгръщане на канарче. 
За да разположите версия 2 на вашата услуга за API, ще:
- Стартирайте екземпляр на услугата v2 API във вашата производствена среда.
- Настройте разделяне на трафика, за да сте сигурни, че v2 не получава никакъв трафик в началото.
- Регистрирайте v2, така че консулът да може да изпраща трафик към него.
- Бавно преместете трафика към v2 и начин от v1, докато новата версия обработва целия трафик.
»Стартиране на демо среда
Първо клонирайте репото, съдържащо източника и примери за тази публикация в блога.
Променете директориите в клонираната папка и стартирайте демонстрационната среда с docker-compose up. Тази команда ще се изпълнява на преден план, така че ще трябва да отворите нов прозорец на терминала, след като я стартирате.
Следните услуги автоматично ще стартират във вашата локална среда на Docker и ще се регистрират в Consul. Консул сървърна уеб услуга с Envoy sidecar API услуга версия 1 с Envoy sidecar
Можете да видите конфигурацията на Consul в папката consul_config, а дефинициите на услугата в папката service_config.
След като всичко се стартира и стартира, можете да видите състоянието на регистрираните услуги, като разгледате потребителския интерфейс на консула на http: // localhost: 8500. Всички служби трябва да преминат здравните си проверки.
Извийте крайната точка на уеб, за да сте сигурни, че цялото приложение работи. Ще видите, че уеб услугата получава отговор от версия 1 на API услугата.
Първоначално ще искате да внедрите версия 2 на API услугата в продукцията, без да изпращате трафик към нея, за да сте сигурни, че тя се представя добре в нова среда. Предотвратете преминаването на трафика към версия 2, когато го регистрирате, ще настроите превантивно разделяне на трафика, за да изпратите 100% от трафика си до версия 1 на услугата API и 0% към все още неразположената версия 2. Разделяне на трафикът използва новите функции на Layer 7, вградени в Consul Service Mesh.
»Конфигуриране на разделяне на трафика
Разделянето на трафика използва записи за конфигуриране (въведени в Consul 1.5 и 1.6) за централно конфигуриране на услугите и проксите на Envoy. Има три записа за конфигуриране, които трябва да създадете, за да разрешите разделянето на трафика: По подразбиране на услугата за услугата API, за да зададете протокола на HTTP. Service Splitter, който определя разделението на трафика между подмножествата на услугите. Service Resolver, който определя кои екземпляри на услуги са версия 1 и 2.
»Конфигуриране на услугите по подразбиране
Разделянето на трафика изисква приложението нагоре по веригата да използва HTTP, защото разделянето се извършва на слой 7 (при заявка по заявка). Ще кажете на Консул, че вашата услуга нагоре по веригата използва HTTP, като зададете протокола в конфигурационен запис „услуга по подразбиране“ за услугата API. Тази конфигурация вече е във вашата демо среда на l7_config/api_service_defaults.json. Изглежда така.
Полето вид обозначава типа запис на конфигурацията, който дефинирате; за този пример, услуги по подразбиране. Полето с име определя коя услуга се отнася за конфигурацията по подразбиране за услугата. (Стойността на това поле трябва да съвпада с името на услуга, регистрирана в Consul, в този пример api.) Протоколът е http .
За да приложите конфигурацията, можете да използвате CLI на Consul или API. В този пример ще използваме крайната точка за въвеждане на конфигурация на HTTP API, която е достъпна на http: // localhost: 8500/v1/config. За да приложите конфигурацията, използвайте операция PUT в следната команда.
За повече информация относно конфигурационните записи по подразбиране на услугата вижте документацията
»Конфигуриране на Service Resolver
Следващият запис за конфигурация, който трябва да добавите, е Service Resolver, който ви позволява да дефинирате как откриването на услуги на Consul избира екземпляри на услуги за дадено име на услуга.
Разрешителите на услуги ви позволяват да филтрирате подмножества от услуги въз основа на информация в регистрацията на услугата. В този пример ще дефинираме подмножествата „v1“ и „v2“ за API услугата въз основа на регистрираните му метаданни. API услуга версия 1 в демонстрацията вече е регистрирана с таговете v1 и версията на метаданните на услугата: 1. Когато регистрирате версия 2, ще му дадете тага v2 и версията на метаданните: 2. Полето за име е зададено на името на услугата в каталога на услугите на Consul.
Решателят на услугата вече е във вашата демо среда на l7_config/api_service_resolver.json и изглежда така.
Приложете записа за конфигурация на разделител на услуги, като използвате същия метод, който сте използвали в предишния пример.
За повече информация относно разрешителите на услуги вижте документацията.
»Конфигуриране на разделяне на услуги - 100% от трафика към версия 1
След това ще създадете конфигурационен запис, който ще разделя проценти трафик към подмножествата на вашата услуга нагоре по веригата, които току-що сте дефинирали. Първоначално искате разделителят да изпрати целия трафик към v1 на вашата услуга нагоре по веригата, което предотвратява изпращането на трафик към v2, когато го регистрирате. В производствен сценарий това ще ви даде време да се уверите, че v2 на вашата услуга работи и работи както се очаква, преди да й изпратите какъвто и да е реален трафик.
Конфигурационният запис за разделяне на услуги е от вид сплитер за услуги. Името му указва коя услуга ще действа сплитъра. Полето разделяне взема масив, който дефинира различните разделяния; в този пример има само две разделения; обаче е възможно да конфигурирате по-сложни сценарии. Всяко разделяне има тежест, която определя процента на трафика, който да се разпредели във всяка подгрупа на услугата. Общите тегла за всички разделяния трябва да са равни на 100. За първоначалното ни разделяне ще конфигурираме целия трафик да бъде насочен към сервизната подмножество v1.
Конфигурацията на услугата сплитер вече съществува във вашата демо среда на l7_config/api_service_splitter_100_0.json и изглежда така.
Приложете този запис за конфигуриране, като издадете друга заявка за PUT към крайната точка за въвеждане на конфигурация на консула на HTTP API.
Този сценарий е първият етап от нашето разполагане на Канарските острови; вече можете да стартирате новата версия на вашата услуга, без тя веднага да бъде използвана от групата за балансиране на натоварването нагоре по веригата.
»Стартирайте и регистрирайте API услуга версия 2
След това ще стартирате канарската версия на API услугата (версия 2) и ще я регистрирате с настройките, които сте използвали в конфигурационните записи за разрешаване и разделяне. Стартирайте услугата, регистрирайте я и стартирайте страничната кош за свързване със следната команда. Тази команда ще се изпълнява на преден план, така че ще трябва да отворите нов прозорец на терминала, след като я стартирате.
Проверете дали услугата и нейният прокси са се регистрирали, като потърсите нови v2 тагове до API услугата и прокситата на страничната лента на API в потребителския интерфейс на Consul.
»Конфигуриране на разделяне на услуги - 50% Версия 1, 50% Версия 2
Сега, когато версия 2 се изпълнява и е регистрирана, следващата стъпка е постепенното увеличаване на трафика към нея чрез промяна на теглото на подмножеството на услугата v2 в конфигурацията на сервизен сплитер. Нека да увеличим теглото на услугата v2 до 50%. Помня; общото тегло на услугата трябва да е равно на 100, така че вие също намалявате теглото на подмножество v1 до 50. Конфигурационният файл вече е в демо средата ви на l7_config/api_service_splitter_50_50.json и изглежда така.
Приложете конфигурацията както преди.
Сега, когато сте увеличили процента на трафик до v2, навийте отново уеб услугата. Ще видите трафик, разпределен равномерно в двата подгрупи на услугата.
Ако всъщност изпълнявате разгръщане на канарчета, бихте искали да изберете много по-малък процент за първоначалното си разделяне: възможно най-малкият процент, който ще ви даде надеждни данни за производителността на услугата. След това бавно бихте увеличили процента, като повторите тази стъпка, докато придобихте доверие във версия 2 на вашата услуга. Някои компании в крайна сметка могат да изберат да автоматизират нарастването въз основа на предварително зададени прагове за производителност.
»Конфигуриране на разделяне на услуги - 100% версия 2
След като се уверите, че новата версия на услугата работи правилно, можете да изпратите 100% от трафика към подмножество версия 2. Конфигурацията за 100% разделяне на версия 2 изглежда така.
Приложете го с повикване до крайната точка на конфигурацията на HTTP API, както направихте преди.
Сега, когато отново навиете уеб услугата. 100% от трафика се изпраща към подмножество версия 2.
Обикновено в производствена среда вече бихте премахнали услугата версия 1, за да освободите капацитет във вашия клъстер. Поздравления, сега завършихте внедряването на версия 2 на вашата услуга.
" Почисти
За да спрете и премахнете създадените от вас контейнери и мрежи, ще стартирате docker-compose два пъти: веднъж за всяка от изпълнените команди за docker съставяне. Тъй като контейнерите, които сте създали във втората команда за съставяне, се изпълняват в мрежата, която сте създали с първата команда, ще трябва да свалите средите в обратния ред, в който сте ги създали.
Първо ще спрете и премахнете контейнерите, създадени за v2 на API услугата.
След това ще спрете и премахнете контейнерите и мрежата, която сте създали в първата команда за съставяне на докер.
»Обобщение
В този блог ви преведохме през стъпките, необходими за извършване на Canary разгръщане, използвайки разделяне на трафика и резолюция. За по-задълбочена информация относно разполагането на Канарски острови, Данило Сато написа отлична статия на уебсайта на Мартин Фаулър.
Усъвършенстваното управление на трафика L7 в 1.6.0 не се ограничава до разделяне. Той също така включва HTTP базирана маршрутизация и нови настройки за разделителна способност на услугата. В комбинация тези функции позволяват усъвършенствано маршрутизиране на трафика и отказ на услугата. Всички нови настройки за управление на трафика L7 могат да бъдат намерени в документацията. Ако искате да отидете по-далеч, комбинирайте го с нашето ръководство и L7 Observability, за да приложите част от мониторинга, необходим за нови внедрявания на услуги.
Моля, имайте предвид, че Consul 1.6 RC не е подходящ за производствени внедрения. Ще се радваме на всякакви отзиви или съобщения за грешки, които имате в нашите проблеми с GitHub, и можете да задавате въпроси в новия ни форум на общността.