Как Dark разгръща код за 50 мс

Колкото по-бърз е процесът на разработка, толкова по-бързо се развива технологичната компания.

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

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

Скоростта на тези пайплайни влияе на скоростта на разработка. При най-добрите екипи разгръщането отнема 5–10 минути, но обикновено всичко отнема много по-дълго време, а за едно разгръщане са необходими няколко часа.

В Dark това отнема 50 мс. Петдесет. Милосекунди.. Dark — това е комплексно решение с програмен език, редактор и инфраструктура, създадено специално за непрекъсната доставка, и всички аспекти на Dark, включително самият език, са изградени с мисъл за сигурно мигновено разгръщане.

Защо пайплайните за непрекъсната доставка са толкова бавни?

Да кажем, че имаме уеб-приложение на Python и вече сме създали страхотен и съвременен пайплайн за непрекъсната доставка. За разработчика, който всеки ден работи по този проект, разгръщането на едно незначително изменение изглежда приблизително така:

Направяне на промени

• Създаване на нов клон в git
• Направяне на промени с включен превключвател за функцията
• Модулно тестване за проверка на промените с включен и изключен превключвател за функцията

Пул-реквест

• Комит на промените
• Изпращане на промените в отдалечено хранилище на github
• Пул-реквест
• CI билдът се изпълнява автоматично във фонов режим
• Преглед на кода
• Още няколко прегледа, ако е необходимо
• Сливане на промените с мастера в git.

CI се изпълнява на мастера

• Инсталиране на фронтенд зависимости чрез npm
• Билд и оптимизация на HTML+CSS+JS ресурси
• Изпълнение на модулни и функционални тестове на фронтенда
• Инсталиране на Python зависимости от PyPI
• Изпълнение на модулни и функционални тестове на бэкенда
• Тестване на интеграция и на двата края
• Изпращане на фронтенд ресурсите в CDN
• Билд на контейнер за Python приложението
• Изпращане на контейнера в регистър
• Актуализиране на манифеста на Kubernetes

Смяна на стария код с нов

• Kubernetes стартира няколко инстанции на нов контейнер
• Kubernetes изчаква инстанциите да станат работещи
• Kubernetes добавя инстанции в HTTP балансьора на натоварване
• Kubernetes изчаква да спрат да се използват старите инстанции
• Kubernetes спира старите инстанции
• Kubernetes повтаря тези операции, докато новите инстанции не заменят всички стари

Включване на нова функция с превключвател

• Новият код се активира само за него самия, за да се увери, че всичко е наред
• Новият код се активира за 10% от потребителите, следят се оперативни и бизнес метрики
• Новият код се активира за 50% от потребителите, следят се оперативни и бизнес метрики
• Новият код се активира за 100% от потребителите, следят се оперативни и бизнес метрики
• Накрая повтаряте цялата процедура, за да премахнете стария код и превключвателя

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

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

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

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

Разбира се, това е много добре обмислен пайплайн. Екипът, който го е създал, не е пестил време и пари за бързо разгръщане. Обикновено пайплайните за разгръщане са много по-бавни и ненадеждни.

Реализация на непрекъсната доставка в Dark

Непрекъснатото доставяне е толкова важно за Dark, че от самото начало насочихме усилията си към време под една секунда. Прегледахме всички стъпки в процеса, за да елиминираме излишното, а останалото доведохме до съвършенство. Ето как премахвахме стъпките.

Джесси Фразел (Jessie Frazelle) създаде нова дума deployless (без нужда от разгръщане) на конференцията Future of Software Development в Рейкявик.

Веднага решихме, че Dark ще бъде основан на концепцията „deployless“ (благодарим на Джесси Фразел за неологизма). Deployless означава, че всеки код моментално се разгръща и е готов за употреба в производството. Разбира се, няма да пропуснем дефектен или непълен код (принципите на безопасност ще опиша по-долу).

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

Dark стартира интерпретатори в облака. Да кажем, че пишете код във функция или обработчик на HTTP или събития. Изпращаме разликата в абстрактното синтактично дърво (реализация на кода, която нашият редактор и сървъри използват вътрешно) на нашите сървъри и след това стартираме този код, когато получаваме заявки. Така разгръщането изглежда просто като скромен запис в база данни — моментално и елементарно. Разгръщането става толкова бързо, защото включва само най-основното.

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

Безопасно разгръщане

Структуриран редактор

Кодът в Dark се пише в редактора на Dark. Структурираният редактор не допуска синтактични грешки. По същество, в Dark дори няма анализатор. Докато въвеждате текст, ние директно работим с абстрактното синтактично дърво (AST), както Paredit, Sketch-n-Sketch, Tofu, Prune и MPS.

Всеки незавършен код в Dark има допустима семантика на изпълнение, точно като typed holes в Hazel. Например, ако промените извикването на функция, ние запазваме старата функция, докато новата не стане използваема.

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

Режими на редактиране

Вие пишете код в Dark в два случая. Първият: пишете нов код и сте единственият потребител. Например, той е в REPL, и други потребители никога не получат достъп до него, или това е нов HTTP маршрут, на който не се позовавате никъде. Тук можете да работите без никакви предпазни мерки, и в момента именно така работите в средата за разработка.

Втората ситуация: кодът вече се използва. Ако през кода минава трафик (функции, обработчици на събития, бази данни, типове), трябва да се внимава. Затова блокираме целия използван код и изискваме да се използват по-структурирани инструменти за редактиране. За структурираните инструменти ще разкажа по-долу: превключватели на функции за HTTP и събитийни обработчици, мощна платформа за миграция за бази данни и нов метод за управление на версии за функции и типове.

Превключватели на функции

Един от начините да премахнете излишната сложност в Dark е да решите няколко проблема с едно решение. Превключвателите на функции изпълняват много различни задачи: замяна на локалната среда за разработка, git клонове, разпространение на код и, разбира се, традиционно бавно и контролиранo освобождаване на нов код.

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

Превключвателите на функции са вградени в езика Dark и дори незавършените превключватели изпълняват задачата си — ако условието в превключвателя не е изпълнено, ще се изпълнява старият блокиран код.

Среда за разработка

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

Вместо да създават клонирана локална среда, превключвателите в Dark създават нова пясъчница в продукцията, която замества средата за разработка. В бъдеще планираме да създадем пясъчници за други части на приложението (например, мигновени клонирания на базата данни), въпреки че за момента това не изглежда толкова важно.

Клонове и разгръщания

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

Най-ефективният начин е използването на превключватели на функции (освен това е и най-лесният за разбиране и използване). С тях може напълно да се откажем от двете други метода. Особено полезно е да се премахне разгръщането — ако все пак използваме превключватели на функции, за да активираме кода, тогава стъпката за превключване на сървърите на новия код само създава излишни рискове.

Git е сложен за използване, особено за начинаещи, което наистина го ограничава, но пък има удобни клони. Ние изгладихме много от недостатъците на git. Dark позволява редактиране в реално време и предлага възможност за съвместна работа в стил Google Документи, така че да не се налага да изпращате код и можете по-рядко да правите ребазиране и сливане.

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

Версиониране

За промяна на функции и типове използваме версииране. Ако искате да промените функция, Dark създава нова версия на тази функция. След това можете да извикате тази версия чрез превключвателя в HTTP обработчика или събитията. (Ако това е функция дълбоко в графа на извикванията, по време на повикването се създава нова версия на всяка функция. Може да изглежда като излишно, но функциите не пречат, ако не ги използвате, така че дори няма да го забележите.)

По същите причини версираме и типовете. За нашата система от типове говорихме подробно. в предишния пост.

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

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

Нови версии на пакети и стандартната библиотека

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

Скриншот на част от автоматичния процес в Dark, показващ две версии на функцията Dict::get. Dict::get_v0 е връщал тип Any (от който се отказваме), а Dict::get_v1 връща тип Option.

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

Dark също предоставя уникална възможност: тъй като изпълняваме вашия работен код, можем сами да тестваме новите версии, сравнявайки изходните данни за новите и старите заявки, за да ви уведомим за промените. В резултат на това обновлението на пакетите, което често се извършва на сляпо (или изисква внимателно тестване за сигурност), представлява много по-малки рискове и може да се случи автоматично.

Нови версии Dark

Преводът от Python 2 на Python 3 се разпростря за десетилетие и все още остава проблем. Тъй като създаваме Dark за непрекъсната доставка, е нужно да се вземат предвид тези езикови промени.

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

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

Миграции на бази данни

За безопасна миграция на база данни съществува стандартна формула:

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

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

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

Достъпът до данъчните хранилища в Dark се осъществява чрез версиирани имена на променливи. Например, хранилището за данни Users първоначално ще се нарича Users-v0. Когато се създаде нова версия с различен тип, името се променя на Users-v1. Ако данните са запазени през Users-v0, а вие се обръщате към тях през Users-v1, се прилага функция за надграждане. Ако данните са запазени през Users-v1, а вие се обръщате към тях през Users-v0, се прилага функция за връщане назад.

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

Използвайтеключовете за функции, за да насочите повикванията къде Users-v0 към версия Users-v1. Това може да стане по един HTTP обработчик наведнъж, за да се намалят рисковете, а също така ключовете работят за отделни потребители, за да можете да проверите, че всичко работи, както се очаква. Когато потребителите на Users-v0 свършат, Dark автоматично преобразува всичките останали данни във фонов режим от стария формат в нов. Вие дори няма да забележите.

Тестиране

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

Освен това, Dark изпълнява вашата инфраструктура в продукция, което отваря нови възможности. Ние автоматично запазваме HTTP заявките в инфраструктурата на Dark (в момента запазваме всички заявки, но по-късно искаме да преминем на вземане на проби). Тестуваме новия код по тях и извършваме модулни тестове, и при желание можете лесно да преобразувате интересни заявки в модулни тестове.

От какво сме се освободили

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

Сравнение на стандартен пайплайн за непрекъсната доставка (вляво) и непрекъсната доставка Dark (вдясно). В Dark доставката се състои от 6 стъпки и един цикъл, докато традиционната версия включва 35 стъпки и 3 цикъла.

В Dark разпределението включва само 6 стъпки и 1 цикъл (стъпки, които се повтарят няколко пъти), докато съвременният пайплайн за непрекъсната доставка се състои от 35 стъпки и 3 цикъла. В Dark тестовете стартират автоматично, и вие дори не го виждате; зависимостите се инсталират автоматично; всичко, свързано с git или Github, вече не е нужно; не е нужно да събирате, тествате и изпращате Docker контейнери; разгръщането в Kubernetes вече не е необходимо.

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

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

Отговарям на въпроси за това на HackerNews.

За да научите повече за устройството Dark, прочетете статията за Dark, абонирайте се за нас в Twitter (или за мене) или запишете се за бета версия и получавайте известия за следващите постове. Ако отивате на StrangeLoop през септември, ела при нас за старта.

Източник: habr.com