Але пост не про те, що я оновив macOS. Річ у тім, що я цього разу оновлення вирішив провести на чисту (без всіляких бекапів чи іншого, форматування в нуль й встановлення на чистий ноутбук) й ознайомитись з усіма налаштуваннями й застосунками, які там у нього є. Тобто, я рекурсивно заходив в кожен пункт, який я бачив, чи то в налаштуваннях системи, чи то в якомусь застосунку й знайомився що там взагалі відбувається.

Тож в цьому пості я б хотів поділитись налаштуваннями macOS, які, на мою думку, могли б бути корисними чи зручними. І звісно ж, в сучасному світі, без жирного дисклеймера не обійтись. Тож скажу, що це те, як мені зручно працювати за ноутбуком на macOS. Можливо, хтось дізнається звідси про якусь галочку в налаштуваннях, якої йому не вистачало, тож… все в цьому пості суто субʼєктивне.

Почнімо вже говорити про те, як в мене налаштований macOS.

Terminal

Profiles

За замовчуванням, я використовую профіль Homebrew:

І єдине, що я кардинально змінюю в профілі — це шрифт. Річ у тім, що я використовую Fish Shell, про який поговоримо згодом, з темами, яким потрібні додаткові гліфи. Цих гліфів немає в шрифтах за замовчуванням, а тому я додатково ставлю собі шрифт від GitHub, який називається Monaspace. Він же використовується і для роботи безпосередньо з кодом, а не лише в терміналі.

Але, не поспішайте ставити його по посиланню зверху :)

В шрифті від GitHub теж немає потрібних гліфів для теми в терміналі, а тому я хоч і ставлю Monaspace, але ставлю пропатчений від Nerd Fonts:

І вже цей шрифт йде в мене як основний шрифт для термінала: Monaspice Neon Nerd Font Mono. Його, до речі, можна і через brew поставити.

Essentials

Довго не буду затримуватись на цій частині, бо кожен хто займається розробкою точно має ці інструменти. Особисто для себе я ставлю лише дві речі: Command Line Developer Tools та Homebrew.

Перша в мене йде суто для того, щоб git був, ну і Homebrew як пакетний менеджер для встановлення того ж Shell, про який я зараз трішки розкажу.

Fish Shell

Чим мене купив Fish Shell свого часу, так це своїм автозаповненням команд по Tab. Раніше, я сидів і на всяких oh-my-zsh і потім ще й oh-my-fish був, грався багато де. Але в кінці — все одно залишився на Fish й досі ним користуюсь із коробки, ніяк не налаштовуючи його.

Напевно, найбільше що мені подобається у Fish й тим, чим я найчастіше користуюсь — це його автозаповненням по Tab та автозаповненням команд при їх наборі.

Майже з кожною розповсюдженою командою будуть йти автокомпліти. При роботі з Git, він буде вам пропонувати гілки обирати при git switch чи коміти при git cherry-pick й тому подібне, ну ви зрозуміли. І ще багато чого. Просто для прикладу, як це виглядає з git, якщо я, наприклад, не знаю, які в нього є команди та що вони роблять:

Пошук в історії команд по Ctrl+R дає можливість знайти будь-що, що ви колись набирали. Він використовує fuzzy finder, тож ось я набирав, до прикладу cocoapods:

Коротше… не буду довго на цьому зупинятись, бо краще про нього розповісти детальніше окремо. Знаю, що є прихильники й zsh і що “та це все є в zsh і набагато краще там зроблено”… Але на мою думку, те як це реалізовано та, що важливо, працює з коробки у Fish Shell, мені подобається найбільше.

Тож, якщо ви ще ніколи не пробували Fish Shell, то спробуйте, можливо вам сподобається.

Theme

За замовчуванням у Fish Shell стоїть доволі проста тема, яка мені не подобається. Тож я додатково встановлюю ще тему bobthefish.

Встановлюю я її за допомогою Fisher - це такий типу “плагін-менеджер” для Fish Shell. Ну і не забуваю ввімкнути підтримку Nerd Fonts за допомогою set --universal theme_nerd_fonts yes. Всі ці нюанси з темою та шрифтами описані в документації теми.

І в результаті, я отримую зручний для себе термінал, в якому я відчуваю себе доволі продуктивно.

Time Machine

Раніше, я недооцінював цей інструмент та не вважав вартим його налаштовувати. Напевно, це тягнеться в мене ще з часів Windows. Коли з часом, нагромаджувались записи в реєстрах, системні файли — все це змішувалось з твоїми власними даними й в результаті через рік ти отримував купу сміття змішаного з твоїм власним й вже не розбереш звідки куди йде. І що простіше вже було просто з нуля перевстановити систему та не тягнути за собою всю ту історію, яка б точно дала б якісь конфлікти налаштувань й так далі.

Проте, я трохи розібрався поверхнево з тим, як влаштовані в сучасній macOS системні розділи та користувацькі. І виявилось, що сама операційна система та системний розділ — це взагалі Read Only система, яка монтується із snapshot. Тобто все що стосується самої системи ви в принципі не можете ніяк змінити чи повпливати, а тобто і зламати. А ваш користувацький розділ — це взагалі окремий розділ, який монтується на /Volumes/Data. І от саме він і копіюється в Time Machine, ігноруючи системні файли.

Що це означає для мене, як для людини, яка постійно боролась зі сміттям після довгого використання Windows? А банально те, що можливо є сенс робити собі бекапи з Time Machine, та не перейматись, що воно буде тягнути за собою історію всіх попередніх версій системних файлів чи їх налаштувань та потенційно бути причинами конфліктів між різними версіями. Мої файли — це мої файли й вони копіюються, а все інше не попадає в копію.

Тому я також почав користуватись Time Machine, але подивимось як піде й чи мені сподобається.

Safari

Тут багато не напишеш, але я все ж деякі невеличкі моменти змінюю в ньому.

Перш за все, я вмикаю попередження, коли мене намагаються перевести на сайт по HTTP:

Потім, вимикаю взагалі всі AutoFill, окрім паролів. Мало того, що вони мене просто бісять завжди своїм віджетом, який питає що ти хочеш обрати, так це ще й з перспективи безпеки не дуже.

Ну і звісно, остання, але найбільш бісяча частина Safari за замовчуванням — відкривати нове вікно браузера з пустими вкладками. Я одразу ж це змінюю на “відкривати всі вкладки, які були в попередній сесії”:

Тому, по Safari в мене питань загалом немає, але є деякі бісячі моменти, які я змінюю в налаштуваннях.

System Settings

Apple Account Sign-In

До цього питання я ставлюсь доволі серйозно, бо за моїм Apple Account-ом зберігаються в тому числі й паролі до всіх інших моїх сервісів. А тому, я вважаю, що ставлення до пароля на Apple Account має бути як до мастер-пароля. Спеціальні символи, числа, маленькі та великі букви — все це треба, щоб було в паролі.

Окрім цього, мій акаунт ще додатково захищений фізичним ключем YubiKey. Тому, навіть якщо мій пароль зламали, без фізичного ключа до акаунта не дістатись:

Ну і на всяк випадок, я ще додаю контакти близьких, які можуть допомогти мені відновити акаунт, або отримати доступ до нього у випадку моєї смерті.

Wi-Fi

Для тих, хто обожнює приватність в Інтернеті, якої не існує, в меню Wi-Fi можна ввімкнути ротацію MAC адрес та ховати свій IP. Для цього потрібно відкрити налаштування вашої конкретної мережі, до якої ви підʼєднались:

Network

В меню Network я вмикаю Firewall й додатково вмикаю Stealth Mode в його налаштуваннях:

Three Finger Drag

Одна з моїх найулюбленіших можливостей трекпада на macOS - перетягувати вікна чи виділяти текст не тримаючи натиснутим його однією рукою, поки тягнеш іншою, а просто використовувати жест із трьома пальцями. Ви починаєте вести рукою по трекпаду трьома пальцями й macOS буде вважати це як натиснуту кнопку, яку ви утримуєте. Вмикається це в Accessibility → Pointer Control → Trackpad Options:

Desktop & Dock

Док на macOS за замовчуванням це взагалі найбільш бісяча частина для мене. Мені зручніше, коли док використовується лише як менеджмент відкритих застосунків, а не як звалище всього що є і що потенційно тобі може знадобитись. Тому, я в налаштуваннях дока вимикаю взагалі все, що повʼязане з його Suggestions, викидую взагалі всі застосунки звідти, поки там не залишиться лише Finder та кошик.

Окрім цього, вимикаю ще один бісячий момент, коли macOS ховає всі відкриті вікна, коли ти натискаєш на робочий стіл. Все це можна вимкнути в Desktop & Dock:

Night Shift

Одна цікава деталь, яка особисто мені подобається, це Night Shift. Його можна налаштувати по графіку й коли буде вже ставати темніше, то температура кольорів на дисплеї буде ставати теплішою. Хочете вірте, хочете ні, але особисто я бачу різницю і ввечері за ноутбуком справді трохи легше сидиться в контексті очей.

Touch ID & Password

Ще одна цікава деталь, це можливість розблокувати свій MacBook своїм Apple Watch. Якщо ви це вмикаєте, то вже не потрібно навіть і палець чи пароль. Ваш годинник поруч і ноутбук автоматично розблоковується сам. А вам на Apple Watch приходить сповіщення, що ваш ноутбук було розблоковано.

iCloud

Для того, щоб я не втрачав свої дані у випадку втрати ноутбука чи встановленні нового, я активно користуюсь iCloud-ом. В меню Saved to iCloud в мене ввімкнено взагалі все для всіх застосунків, щоб вони синхронізувались з iCloud.

А щоб воно було більш захищеним, я додатково налаштував Advanced Data Protection, який повністю шифрує всі ваші дані вашим ключем:

iPhone Mirroring

Це, напевно, зʼявилось з останнім оновленням macOS Tahoe, але виявилась дуже зручною штукою, якою я реально користуюсь.

Ви можете звʼязати свій ноутбук з вашим телефоном й керувати ним з ноутбука. Це буває корисно, коли телефон десь стоїть заряджається, або стоїть на станції тощо. Тут вам приходить сповіщення, на яке треба відреагувати, але вам не хочеться вставати та йти діставати свій телефон.

Відкриваєте цей застосунок та й керуєте телефоном як наче ви його в руках тримаєте:

Закінчуємо

Ідея з цим постом мені прийшла доволі сумбурно сьогодні вдень. Я не знаю, чи було це взагалі комусь корисним, чи ні, але захотілось написати про те, що особисто мені доводиться налаштовувати додатково в macOS після її встановлення. Тобто, маю на увазі, що якщо щось працює із коробки так, як мені потрібно, то я його відповідно не налаштовую, а значить і в цей пост воно не потрапило.

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

Тож, закривши своє бажання про щось сьогодні написати, бажаю вам гарного вечора :)

В чому проблема?

На невеликих обсягах коду, проблеми ніякої нема. Викликали компілятор, той же TypeScript, а він вам виплюнув JavaScript кудись в dist й ви поїхали працювати далі. Коли за розмірами цей проєкт невеликий, то й проблем немає — це швидко.

Але довгострокові проєкти живуть достатньо довго, щоб обрости такою кількістю коду, компіляція якого починає займати багато часу. Це впливає на швидкість, з якою розробники отримують відповідь на питання “а чи скомпілювався мій код?”.

Додаємо сюди ще й той факт, що існують інші проєкти, які живуть в тому ж репозиторії. Тобто у вас один репозиторій не просто з одним TypeScript проєктом, а з десятками, а то й сотнями. Тож якщо ви викличете TypeScript компілятор в репозиторії для всіх цих проєктів, то чекати ви будете ще довше.

Так і зʼявляється необхідність надати розробникам можливість збирати лише частину репозиторію, а не весь. От подивимось на це з погляду розробника.

Ви клонуєте репозиторій, в якому працюють декілька команд і там зберігаються сотні окремих TypeScript проєктів. Бібліотеки, застосунки, допоміжні скрипти й так далі. Але працюєте ви зараз лише з одним конкретним застосунком.

Після впровадження вами змін у свій застосунок, ви викликаєте збірку репозиторію, а воно вам починає викликати TypeScript компілятор по всьому репозиторію й ви сидите чекаєте 5 хвилин, хоча вам потрібно було викликати лише збірку вашого застосунку та збірку всіх пакетів, від кого ви залежите, чи від вас. Незручно, правда?

Вітаємо концепцію інкрементальної збірки

Для менеджменту нашого репозиторію ми використовуємо Rush. Одна із цікавих можливостей цього інструменту є те, що ви можете задавати свої власні команди, які потім стають командами самого rush. Ці налаштування живуть в окремому файлі command-line.json, де і відбувається опис команд.

До прикладу, скажімо, що ми хочемо зробити команду build, яка буде викликати скрипти збірки для всіх проєктів в репозиторії. Підемо в command-line.json та додамо нову команду build.

Я спеціально пропускаю деякі налаштування, щоб сфокусуватись саме на інкрементальній збірці, не беручи до уваги інші аспекти можливостей Rush.

{
  "commandKind": "bulk",
  "enableParallelism": true,
  "name": "build"
}

Цим описом ми кажемо Rush, що ми хочемо мати команду з назвою build, виклик якої має викликати скрипт build із package.json всіх проєктів в репозиторії (commandKind зі значенням bulk означає, що команда має викликатись в усіх проєктах). А enableParallelism дозволяє запускати їх паралельно.

Тепер, ми можемо зробити в консолі rush build і отримати запуск всіх build скриптів з усіх package.json файлів усіх проєктів в репозиторії, ще й паралельно. Ну а там зазвичай йде виклик TypeScript компілятора, тому де-факто це саме компіляція.

Але ладно якщо ви вперше склонували репозиторій й вперше викликали rush build. В цьому випадку, логічно було б зібрати всіх, бо ніхто ж не зібраний ще. Проте, я б очікував, що наступного разу, коли я викличу rush build, воно не буде наново викликати TypeScript компілятор, якщо в мене вже є зібраний проєкт, який я не чіпав. В Rush це питання одного прапорця incremental:

{
  "commandKind": "bulk",
  "enableParallelism": true,
+ "incremental": true,
  "name": "build"
}

Додавши всього цей прапорець для нашого build, ми вже маємо повністю інкрементальну команду build. Тепер, якщо я викличу цю команду вперше, то, звісно, буде збиратись весь репозиторій. Проте, якщо я викличу її ще раз, то воно взагалі нічого збирати не буде — змін же не було.

На прикладі нашого репозиторію, з яким ми зараз працюємо, це виглядає так. Перший виклик цієї команди на пустому репозиторії (маю на увазі, що всі кеші холодні), збірка займає приблизно хвилину. Найдовше йдуть проєкти на Next.js чи Svelte.

$ rush build
Rush Multi-Project Build Tool 5.153.2 - https://rushjs.io
Node.js version is 20.19.1 (LTS)

Starting "rush build"
Analyzing repo state... DONE (0.06 seconds)

==[ SUCCESS: 43 operations ]===================================================
rush build (1 minute 2.2 seconds)

Тепер, якщо я одразу ж викликаю rush build ще раз, ми вже маємо зовсім інші числа.

$ rush build
Rush Multi-Project Build Tool 5.153.2 - https://rushjs.io
Node.js version is 20.19.1 (LTS)

Starting "rush build"
Analyzing repo state... DONE (0.06 seconds)

==[ SKIPPED: 43 operations ]===================================================
rush build (0.10 seconds)

Як бачите, Rush взагалі пропустив виклик build скриптів в усіх проєктах, бо, логічно, вони не були змінені, а значить і сенсу їх наново збирати — немає.

Тож, як це взагалі працює?

Як реалізована інкрементальна збірка в Rush?

От уявімо, що станом на зараз в нас холодний репозиторій (таке враження, наче я щойно термін вигадав, якого ніде в книгах не бачив, якісь репозиторії холодні, а не кеші… коротше я знову про те, що репозиторій ще ніколи не збирався).

Ми викликаємо команду rush build і він починає лізти в кожен проєкт в репозиторії та викликати там скрипт build із package.json. Як тільки збірка одного з проєктів завершується, Rush робить доволі класичну річ — бере хеші всіх файлів цього проєкту.

Через те що Rush знає рамки вашого проєкту (ви явно вказуєте шлях до нього при реєстрації), то він знає і хеші яких файлів йому треба дістати. В результаті цієї операції він отримує JSON, де він записує, який файл і який хеш він мав. Це виглядає якось так:

{
  "files": {
    "repo/services/lookout/Dockerfile": "b6bbd8d808a7b0d26692ca8b2324e89e25296f11",
    "repo/services/lookout/eslint.config.js": "c36008e6107cc988c554a8ffd5e8913c796bbe4a",
    "repo/services/lookout/src/App.ts": "1784f1b34f84478a042a757702632f585a8ddc3c",
    // and so on...
  }
}

Окрім цього, він ще додає команду, яка викликалась на цих файлах. Це робиться для того, щоб у випадку зміни скрипту, він викликався, а не пропускався.

{
   "files": {
     "repo/services/lookout/Dockerfile": "b6bbd8d808a7b0d26692ca8b2324e89e25296f11",
     "repo/services/lookout/eslint.config.js": "c36008e6107cc988c554a8ffd5e8913c796bbe4a",
     "repo/services/lookout/src/App.ts": "1784f1b34f84478a042a757702632f585a8ddc3c",
     // and so on...
   }
+  "arguments": "tsc --project tsconfig.build.json"
}

Тепер, Rush знає, що раніше викликалась команда tsc --project tsconfig.build.json на файлах з ось такими хешами. Залишилось лише зберегти цю інформацію в тимчасовій теці, що він і робить — зберігає цей файл у теці з проєктом repo/services/lookout/.rush/temp/package-deps_build.json.

Наступний виклик rush build бачить, що вже є файл зі станом попередньої збірки, тож звіряємось… Якщо цього разу аргументи команди не змінились, тобто все та ж tsc --project tsconfig.build.json й при цьому хеші всіх файлів зараз такі ж самі, як і записані у файл — це значить, що проєкт не змінювався, як і його скрипт збірки. А тому виклик tsc можна повністю пропустити.

Чи обмежені ми де його використовувати?

На моєму досвіді — ні. В результаті, ми зробили три інкрементальні команди build, lint та test. Майже в усіх наших проєктах є TypeScript, тому build це в нас tsc. Аналогічно майже всі використовують ESLint, а тому lint це в нас eslint. Ну і test це в нас jest або mocha на старіших проєктах.

Кожна з них описана в Rush аналогічно до того, як я розповідав вище. Продублюю ще раз, але вже повний опис однієї із таких команд, наприклад lint:

{
  "allowWarningsInSuccessfulBuild": false,
  "commandKind": "bulk",
  "description": "The `rush lint` command typically runs ESLint to check code quality across all packages in parallel. The linting process can be customized in each package's scripts.",
  "disableBuildCache": false,
  "enableParallelism": true,
  "ignoreDependencyOrder": true,
  "ignoreMissingScript": false,
  "incremental": true,
  "name": "lint",
  "safeForSimultaneousRushProcesses": false,
  "summary": "Lints all projects using ESLint.",
  "watchForChanges": false
}

З такою конфігурацією, якщо дуже коротко, поведінка команди rush lint наступна. Викликай lint команду з усіх package.json скриптів. Роби це паралельно на всіх доступних ядрах процесора, ігноруючи топологію залежностей (для аналізу це не потрібно). Якщо автор проєкту не надавав команду lint у своєму package.json - кинь помилку. Ну і, звісно, роби це інкрементально!

Додаємо трохи цукру для розробників

Я врешті додав ще одну команду rush all. Але вона дуже проста за своїм визначенням:

{
  "commandKind": "global",
  "description": "The `rush all` command is a convenience command that runs build, lint, and test in sequence across all packages, ensuring code is built, linted, and tested in one go.",
  "name": "all",
  "safeForSimultaneousRushProcesses": true,
  "shellCommand": "rush build && rush lint && rush test",
  "summary": "Runs build, lint, and test commands for all projects."
}

Тобто тепер, замість того, щоб розробники викликали всі три команди окремо, коли вони хочуть переконатись, що все працює, тепер вони роблять це однією. Зручно ж!

До того, оскільки всі ці три команди мають інкрементальну збірку, команда rush all теж такою можна назвати. І тепер розробник під час своєї роботи, щоразу як йому треба щось зібрати, просто викликає rush all.

Запустімо rush all на холодному репозиторії:

$ rush all
Rush Multi-Project Build Tool 5.153.2 - https://rushjs.io
Node.js version is 20.19.1 (LTS)

Starting "rush all"

Starting "rush build"
Analyzing repo state... DONE (0.06 seconds)
==[ SUCCESS: 43 operations ]===================================================
rush build (1 minute 5.6 seconds)

Starting "rush lint"
Analyzing repo state... DONE (0.07 seconds)
==[ SUCCESS: 43 operations ]===================================================
rush lint (40.22 seconds)

Starting "rush test"
Analyzing repo state... DONE (0.07 seconds)
==[ SUCCESS: 43 operations ]===================================================
rush test (31.00 seconds)

На холодному репозиторії повна збірка всього репозиторію зайняла приблизно дві хвилини. Але наступний виклик цієї ж команди, без змін в проєктах, вже набагато швидший:

$ rush all
Rush Multi-Project Build Tool 5.153.2 - https://rushjs.io
Node.js version is 20.19.1 (LTS)

Starting "rush all"

Starting "rush build"
Analyzing repo state... DONE (0.06 seconds)
==[ SKIPPED: 43 operations ]===================================================
rush build (0.10 seconds)

Starting "rush lint"
Analyzing repo state... DONE (0.07 seconds)
==[ SKIPPED: 43 operations ]===================================================
rush lint (0.09 seconds)

Starting "rush test"
Analyzing repo state... DONE (0.07 seconds)
==[ SKIPPED: 43 operations ]===================================================
rush test (0.09 seconds)

Всього забираючи лише дві секунди й ті, для того, щоб Node.js запустити :)

Наступного разу, коли розробник на повністю зібраному репозиторії, внесе деякі зміни в якісь застосунки чи пакети, то його rush all збере тільки необхідну для цього частку, пропускаючи будь-які процеси повʼязані з кодом, який він не змінив.

Які плюси для розробників?

Маючи таку систему, команди розробників мають всі плюси монорепозиторіїв, щоб ділитись кодом між застосунками, лінкувати їх локально для пришвидшеної локальної розробки й тому подібне. Але при цьому, нівелюється проблема, коли треба було кожного разу збирати репозиторій весь й чекати довгий час лиш для того, щоб зрозуміти, чи мій рядок коду правильно написаний.

Тож тепер, це питання декількох секунд, можливо десятків секунд, якщо багато змінено, для того, щоб отримати повністю зібраний репозиторій з усіма проєктами локально + вашими змінами.

Я ось цей “гумор” про пʼятничні деплої взагалі не розумію. Ну бо це не гумор, це якась хвора стигма в професіональному оточенні. Люди, щоб нормалізувати певні явища, інколи застосовують гумор до них. І через це, сприйняття змінюється з “щось, що можна поліпшити, бо це проблема” на “ха-ха, та це ж нормально, посміємось, це не проблема”. Але, хай там як, цей пост не про когнітивні пастки та викривлення. Про них можна написати й окремий пост, де розповісти про те, як наш мозок обдурює сам себе - дуже цікаві штуки насправді.

А в цьому пості я вирішив сфокусуватись на одній ідеї, яка безпосередньо й дозволяє в більшості випадків деплоїти в пʼятницю й не боятись нікого зламати. Але перед тим як я підійду конкретно до цієї теми, я зайду трішки здалеку. Чому? Та банально, тому що в мене зараз на це є настрій. Ну і, тому що вважаю, що донести цю ідею й пояснити чому вона працює - важливо, як мінімум для мене. Тож я почну трішки здалеку і пропоную почати з дуже простого кейсу.

CLI параметри

Ви всі у своїй роботі використовуєте CLI параметри. Чи то ви працюєте з git, чи то з curl, чи купа інших програм. Щоб скорегувати програму, аби вона виконувала ті дії, які вам потрібні, ви зазвичай вказуєте підкоманди чи параметри. Ну от візьмімо за простий приклад команду curl:

curl google.com

Викликавши цю команду ви очікувано отримаєте якийсь HTML у себе в терміналі:

Але що ви робите, коли ви хочете змінити поведінку програми, не змінюючи саму програму? Ви передаєте параметри (якщо програма їх підтримує звісно). Ну от, наприклад, ми хочемо подивитись на детальнішу інформацію стосовно зʼєднання і додаємо параметр:

curl --verbose google.com

Додали прапорець --verbose і викликали програму:

І ось ми вже бачимо зовсім іншу поведінку програми, яка не просто видає HTML, а ще й додатково виводить в термінал інформацію про зʼєднання.

Так от до чого я це все веду? От подумайте, у вас є одна і та ж сама програма, яку ми викликали вперше і вдруге. Той же самий curl, за тим же самим шляхом, той же самий файл. Але при цьому, ми отримали різні поведінки, залежно від вказаних параметрів від користувача.

Наведу ще один приклад.

Змінні середовища

Я підозрюю, що багато з вас, хто читає цей пост, працює з вебом. Тож ви точно чули про environment variables. Це звичайні пари ключ\значення, які операційна система прокидає у ваш процес. І вже ваш процес може прочитати ці пари та дістати значення. Зазвичай їх часто використовують для довгоживучих серверів, але й не тільки. Так ось.

Скажімо, у вас є сервіс, який пише деякі логи, щоб краще розуміти що відбувається. Але ви, по класиці, зробили так, що у вас є рівні логів. Ну це зазвичай щось типу error, warn та info. І от, наприклад, info логів у вас багато і ви б хотіли їх вимкнути. Багато бібліотек надають цю можливість, вказуючи через LOG_LEVEL рівень логів, які ви б хотіли писати.

Тож ви запустили свій сервіс, вказали йому в змінних оточення LOG_LEVEL=warn і таким чином вимкнули інформаційні логи.

А тепер питання. Чи змінювали ви щось у своїй програмі для цього? Чи може у бібліотеці, яку ви використовуєте? Не думаю. Ви можете розгорнути такий же самий сервіс, вказати йому інший LOG_LEVEL і ви отримаєте два однакових сервіси, але які вже виконують різні шматки коду, скажімо так. І все це без зміни самого коду.

Що між ними спільного?

Думаю, цих двох прикладів достатньо, щоб передати ось цю концепцію - мати код, хід якого можна контролювати зовнішніми чинниками.

І це неважливо насправді як саме реалізовується ця концепція. Як я і показав на прикладах, в CLI це можуть бути параметри до самої програми. В сервісах це можуть бути змінні середовища.

Всіх їх обʼєднує одна риса - не змінюючи код програми, ми можемо контролювати її хід.

Прості реалізації

Ну от, познайомились з ідеєю. Але ідеї ідеями, але без прикладу буде неповноцінно. Як би ми могли дуже просто реалізувати ось цю концепцію з “зроби мені А, якщо X, а якщо ні, то зроби B”. Я буду частково використовувати для цього псевдокод, але дуже сильно відрізнятись від реальної реалізації воно не буде. Ну і як ви вже могли зрозуміти, звісно тут велику роль відіграє if statement.

Ну от візьмемо той же curl, як би це могло виглядати там?

// These are some other functions somewhere else in the program
declare class Connection {}
declare function doingAllTheStuffWith(url: string): Connection;
declare function outputVerboseInfoFor(connection: Connection): void;
declare function outputResponseFrom(connection: Connection): void;

import { parseArgs } from "node:util";

const args = parseArgs({
  options: {
    verbose: { type: "boolean", default: false },
    url: { type: "string", default: "" },
  },
});

const connection = doingAllTheStuffWith(args.values.url);

// !!!
// This is the important part for this blog post
if (args.values.verbose === true) {
  outputVerboseInfoFor(connection);
}

outputResponseFrom(connection);

Зверніть увагу, що наш код з самого початку може видавати verbose логи для нашого псевдо Connection. Але! Робитиме він це лише за умови, що йому прокинули параметр --verbose. В усіх інших випадках, програма банально не зайде в ту гілку, вона буде пропущена.

Аналогічно можна було б зробити й за допомогою змінних оточення. Додамо альтернативний спосіб ввімкнути наші verbose логи:

if (args.values.verbose === true || typeof process.env["CURL_VERBOSE"] !== "undefined") {
  outputVerboseInfoFor(connection);
}

І ось в нас вже є програма, хід якої ми можемо змінювати лише вказуючи додаткові параметри чи змінні оточення.

Дочитали ви до цього місця і такі думаєте “Жека, ну це ж смішно, ми й так це розуміємо”. І матимете рацію. Ви ж знаєте, я полюбляю йти від простого до складного, тож зараз я почну ускладнювати вам задачку.

Прапорець або ввімкнений, або вимкнений

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

Така бінарна логіка може працювати в короткострокових програмах по типу CLI утиліт чи щось подібне. Для одного сценарію ви викликали програму з одним набором параметрів, а для іншого сценарію - з іншими.

Якщо ж ми починаємо говорити про довгострокові сервери, які постійно працюють, то ми ж не будемо для кожного запиту підіймати окремий сервіс з іншим набором змінних оточення. Правда ж?

Ось це і є проблема. Маючи описаний вище підхід, ми то, звісно, можемо підняти сервіс з одним набором конфігурацій, але цей набір буде працювати або для всіх, або ні для кого.

Що як, я б хотів підняти сервіс, але щоб той код, який я написав, працював лише для мене. А у мого колеги він би не відпрацьовував? І тим паче не відпрацьовував би для наших користувачів? Хоч він вже і на проді. Іншими словами, наш if має вміти робити щось типу такого:

- if (args.values.verbose === true || typeof process.env["CURL_VERBOSE"] !== "undefined") {
+ if (thisIsMineRequestAndNoOneElse) {
  outputVerboseInfoFor(connection);
}

Ось тут ми й приходимо до того, що я так люблю - ускладнення!

Прийняття рішення в run-time

Для того, щоб ми могли реалізувати цей умовний thisIsMineRequestAndNoOneElse, нам вже недостатньо мати ту статичну інформацію, яку ми маємо, коли передаємо її через прапорці чи через змінні оточення. Бо цієї інформації банально недостатньо, щоб зрозуміти хто є хто у запиті.

Тому наший if має кудись сходити з якимись даними й щоб цей хтось нам сказав чи це має бути true, чи false (дуже спрощено). І в принципі зі збором даних на нашій стороні все відносно легко. Ми можемо просто підготувати контекст з важливою інформацією та передати її тому, хто буде приймати рішення.

Для простого прикладу, нехай у нас буде якийсь Express сервер, в якому вже є налаштовані middleware, які роблять аутентифікацію й засовує ваші дані в req.user. Тоді, ми могли б викликати функцію, яка скаже нам, а чи можна для цього користувача ввімкнути цей шлях, чи ні:

- if (thisIsMineRequestAndNoOneElse) {
+ if (featureEnabledFor(req.user)) {
  outputVerboseInfoFor(connection);
}

Перенесення цих рішень у динамічну площину та додавання контекстів, перед тим як приймати рішення, й робить можливим реалізацію прапорців на більш гранулярному рівні. Тепер ми вже можемо прапорці вмикати не лише для конкретної програми, а і для конкретних користувачів чи інших обʼєктів, які містяться в тій програмі на момент обробки.

Проблема тепер лише в тому, щоб правильно побудувати потрібний контекст для прийняття рішення. А там ви вже що вирішите, так і буде, обмежень майже немає, майже. Захотіли зробити, щоб прапорець був ввімкнений тільки коли context.date == Feb 30 2222? Та робіть, запихайте в контекст дату, ну і налаштуйте того, хто прийматиме рішення, що якщо дата Feb 30 2222 в контексті, то прапорець треба ввімкнути.

Але я оце говорю постійно про оцього “хтось”, та й так не сказав, про кого ж мова. Що ж, тепер поговоримо про тих, хто приймає рішення, й місце, де ви це все налаштовуєте.

Feature Management Platform

Ці інструменти називають по різному в різних компаніях, бо хтось будує свої власні платформи, як от Wix, й називає по своєму. Хтось бере вже готові COTS (Component-Of-The-Shelf). Тому і терміни вигадують різні. Мені ж ближче більш таке загальне використання терміну - Feature Management Platform.

Що ж це за комбайни? Це платформи, які надають вам, якщо дуже грубо:

• Базу даних для зберігання налаштованих правил. Для кого, коли, в який час, як довго й тому подібне, вся ця інформація зберігається в цих базах даних і потім використовується для прийняття рішення. (Маю на увазі, що це не їх власні бази даних, а просто що вони використовують БД для зберігання налаштованих прапорців з усіма їх правилами).

• Web інтерфейс для зручного налаштування правил. Через нього ви, як розробники, й кажете, що має бути ввімкнено, а що вимкнено, для кого, як надовго й т.і. Зазвичай це процес по типу “Створити новий прапорець → Вмикати лише для користувачів з email, який закінчується на company.com → Вмикати прапорець лише один раз із десяти випадків” ну і тому подібне.

• Рушій для прийняття рішень, який безпосередньо й бере участь в тому, що потім повертається у ваш код у вигляді true чи false. Ви даєте йому свій контекст, про який ми поговорили трішки раніше, а він на основі переданих йому даних, порівнює це з налаштованими правилами із бази даних й каже вам - так, прапорець ввімкнено для цього користувача, або ні, не ввімкнено.

Ось це все і є тим, що потрібно, щоб ви могли змінювати хід програми залежно від того, хто нею користується - ваш користувач чи ви.

1. Налаштували прапорець через Web-інтерфейс, дали йому назву, вказали правила по типу “для цих email” та “на ці дати” й т.д.

2. У своєму коді зібрали контекст для прапорця, в який запхали потрібні дані, як от пошта чи унікальний ідентифактор користувача чи ще щось.

3. Відправили контекст на Feature Management Platform й отримали відповідь чи для цього контексту прапорець ввімкнено чи ні.

Про які платформи я чув?

Щоб ви могли детальніше пошукати та почитати про всі ці платформи, накидаю сюди список, який я принаймні чув, бачив та читав щось про них.

Unleash

Наскільки я зрозумів, то вважається одним із найбільших платформ цього типу з відкритим вихідним кодом. Є і документація й приклади, можна їх і на on-prem розгортати, наскільки памʼятаю. Наявність клієнтів під більшість мов програмування. Ось їх сторінка - Unleash.

Їх інтерфейс, як на мене, доволі гарний, що теж плюс:

Є в них і всілякі залежності, сегменти, стратегії активацій - але то все вже більш для досвідчених і можна про то окремий пост зробити.

GitLab Feature Toggles

Наш проєкт хоститься на GitLab і ми там використовуємо й реєстри для контейнерів й всіляких пакетів для npm, Helm і так далі. Так ось у них також є і прапорці. Єдине що, інтерфейс у них набагато гірший й мені важко сказати, що в тій реалізації вони нам якось корисні. Все доволі просто й, наскільки я зрозумів, під капотом в них там unleash. Тому можна починати з GitLab, а потім переїхати на Unleash, коли масштаби виростуть.

OpenFeature

Не зовсім платформа, а скоріш спроби стандартизувати все що повʼязане з прапорцями. Можете використати як джерело додаткової інформації, щоб детальніше з ними познайомитись.

Простий прапорець в Unleash

Ну от вирішили ви таки спробувати це все і встановили собі Unleash, наприклад. Як буде виглядати ваш код з усіма цими модними прапорцями?

В першу чергу, вам потрібно буде налаштувати прапорець в інтерфейсі, де вказуєте стратегії активації, сегменти й тому інше, якщо воно вам, звісно, потрібно.

Через те, що я постійно розповідав про активацію прапорця для конкретного користувача в системі, то зробімо прапорець, якому ми скажемо, що ввімкни наш if для мене і мого колеги (ID випадкові):

Зберігши цю стратегію активації в нашому прапорці з іменем demoApp.step2, в нас тепер є місце, куди ми можемо піти спитати, чи можна нам в той закритий для користувачів if чи ні. Так, я використовую Demo App від Unleash, ну бо а чого ні, в мене зараз немає ніде серверів з ним.

Але як це виглядатиме в коді? Налаштувати прапорець зі своїми власними User ID в системі ми то налаштували, а як передати? Ну, грубо кажучи, от як я розповідав раніше в прикладі з Express, так і передавати. Це просто обʼєкт з контекстом, в якому можуть лежати й інші значення, наприклад:

+ const context = {
+   userId: req.user.id,
+   sessionId: req.session.id,
+   remoteAddress: req.ip,
+   properties: {
+     region: 'EMEA',
+   },
+ };

- if (featureEnabledFor(req.user)) {
+ if (unleash.isEnabled('demoApp.step2', context)) {
  outputVerboseInfoFor(connection);
}

Unleash SDK зробить запит до свого рушія, передасть туди, в тому числі, User ID із вашої бази даних. На сервері Unleash відбудеться порівняння, він побачить User ID в списку тих, кому прапорець можна ввімкнути й поверне вам в if true. Якщо ж User ID не співпаде, то буде false.

Ось таким чином ми і зробили можливість умовно не робочий код деплоїти в прод і при цьому не ламати наших користувачів. Бо ми буквально цей код викликаємо тільки для конкретних ситуацій, конкретних користувачів, тенантів й тому інше.

За допомогою цих прапорців великі компанії роблять в тому числі й A/B тестування, підписки по типу Premium, Ultra й так далі, з різним набором функціоналу.

Підсумовуючи

Концепція прапорців вже дуже давно як не нова. Про неї говорили ще чуть не з 2010-их, а то й раніше. Швидкий пошук показав, що і Fowler в 2017 щось там про нього писав, й на DOU вже проскакували статті про них в 2019. Звісно, що до нас воно прийшло здалеку, тому є деяка затримка, але так, якось так - концепція перевірена часом.

Основна ідея в тому, що ви, як розробник, змінюєте хід програми, не змінюючи код програми. Ви деплоїте в пʼятницю ввечері неробочий код в прод, але ховаєте його за прапорцем зі стратегією активації “тільки для мене”. Тому якщо хтось і зламається в пʼятницю ввечері - то це тільки ви.

Один сервіс — один репозиторій

Майже завжди, принаймні з тими командами й проєктами з якими я працював, все починається з одного репозиторію й монолітного сервісу. Тобто у вас буквально один проєкт на весь репозиторій і ви цей проєкт можете зібрати однією командою, щось типу docker build --tag my-awesome-app path/to/context.

Все настільки просто, що ви навіть можете робити це в себе локально і не робити ніяких CI/CD. Інколи, за певних умов, я б навіть і сказав, що вам не потрібен CI/CD. Але сьогодні ми не про це.

Якщо ви все ж таки зробили собі якийсь простий CD, то у вас могло б це бути якимось простим скриптом типу:

#!/bin/bash

set -euo pipefail

pnpm install
pnpm run build
docker build --tag my-awesome-app:latest --file path/to/Dockerfile path/to/context

Цей скрипт ви загорнули б в якийсь YAML для GitHub чи GitLab й справу закрито. Воно собі там щось робить, контейнер збирає й кудись завантажує. Але… ускладнимо задачу.

Багато сервісів — один репозиторій

З цим сценарієм вже стикаюсь рідше, але він все одно є. Зазвичай, такий сценарій починають втілювати організації, в яких достатньо велика кількість розробників та сервісів, які між собою повʼязані, але операційно є окремими сутностями. Детальніше про монорепозиторії я б розповів іншим разом, а зараз продовжимо з контейнерами.

І, до речі, а скільки це “багато” сервісів? Ну, звісно це число може плавати від одного до другого в різних компаніях, тому я просто скажу скільки сервісів зараз у нас, з якими я прямо працюю. І в нас їх небагато — близько 30 з чимось, щось таке. Доводилось працювати в монорепозиторіях і з сотнями сервісів, тому вважаю що 30 - це небагато.

Так ось, всі ці сервіси лежать в одному репозиторії, просто що в різних теках. Структура вашого репозиторію з цими сервісами виглядала б якось так (всі назви вигадані, хочу підкреслити що ось таких Dockerfile може бути багато):

monorepo/
├─ packages/
│  ├─ logger/
│  ├─ eventually/
├─ services/
│  ├─ orchestrator/
│  │  ├─ Dockerfile
│  ├─ lookout/
│  │  ├─ Dockerfile
│  ├─ purger/
│  │  ├─ Dockerfile

Тепер, якщо ви спробуєте зробити класичний docker build в корні репозиторію, то, звісно, що ви не отримаєте ніякого корисного результату. Але ми ж розумні люди, правда? Чом би просто не взяти цей docker build та й не почати його викликати для кожного Dockerfile в його окремих теках. Робимо якесь рішення в лоб зі скриптом, який буде нам збирати всі наші контейнери:

#!/bin/bash

set -euo pipefail

find . -type f -name 'Dockerfile' | while read -r dockerfile; do
  dir=$(dirname "$dockerfile")
  tag=$(basename "$dir" | tr '[:upper:]' '[:lower:]')
  docker build --tag "$tag" "$dir"
done

P.S. Писав цей скрипт по памʼяті, не перевіряв що він працює, але я хочу передати тут саму ідею, що ми ітеруємо по всім знайденим Dockerfile та збираємо їх.

І от, здавалось б, в нас вже є підтримка збірки контейнерів в нашому монорепозиторії. Зробили зміни, завантажили їх на GitHub, а воно вже вам всі контейнери зібрало — кошерно. Ні, не кошерно, давайте я трішки ускладню проблему.

Сервіси повʼязані з бібліотеками з інших тек

Сама суть монорепозиторіїв полягає в тому, що це дозволяє розробникам локально повʼязувати кодові бази з різних бібліотек чи сервісів. Для демонстрації візьмемо те ж вигадане дерево, що я зробив раніше.

monorepo/
├─ packages/
│  ├─ logger/
│  ├─ eventually/
├─ services/
│  ├─ orchestrator/
│  │  ├─ Dockerfile
│  ├─ lookout/
│  │  ├─ Dockerfile
│  ├─ purger/
│  │  ├─ Dockerfile

Пакети logger та eventually - це звичайні npm пакети. Але ці пакети через dependencies використовуються, наприклад, в сервісі lookout. Так, операційно, вони окремі сутності, які приходять через npm реєстр під час npm install. Але для того, щоб локально розробка була трішки легшою, вони повʼязуються локально за допомогою hardlink/softlink. Тож ми маємо сервіс lookout, який у своїх node_modules має посилання на теки в інших частинах монорепозиторію.

Якщо ми просто викличемо docker build для кожного Dockerfile в репозиторії, вказавши йому за контекст збірки теку з Dockerfile, то зібраний сервіс просто не матиме всіх залежностей, які знаходяться за рамками цього контексту. Тобто, він банально не запрацює. Ви отримаєте Cannot find module … чи як там той текст помилки йде.

Тут варто зазначити, що ми використовуємо підхід зі збіркою контейнерів із самого монорепозиторію. Якщо вибудувати робочий процес таким чином, що ви спочатку публікуєте все в реєстри із репозиторію, а потім із реєстрів вже тягнете через npm install під час збірки контейнерів, то цієї проблеми там не буде.

Тож нам, щоб успішно зібрати контейнер, потрібно не лише викликати docker build, вказавши теку з Dockerfile як контекст збірки, а і впевнитись, що в тому контексті збірки будуть всі необхідні залежності. А саме — сам сервіс і та частина монорепозиторію, яка необхідна цьому сервісу як залежність.

Готуємо контекст для збірки

Для менеджменту нашого монорепозиторію ми використовуємо Rush. Так от, нам пощастило, що в Rush є саме команда, яка цю проблему й вирішує. До речі, в pnpm теж є аналог цієї команди - pnpm deploy.

Коли ми викликаємо команду rush deploy, ми вказуємо проєкт, який ми хочемо проаналізувати й викинути в готовий до споживання артефакт. Що мається на увазі під “готовий до споживання”? Я маю на увазі, що ця тека буде містити в собі все необхідне для того, щоб сервіс запрацював.

Наведу невеликий приклад, на тому ж дереві, що ми бачили раніше:

monorepo/
├─ packages/
│  ├─ logger/
│  ├─ eventually/
├─ services/
│  ├─ orchestrator/
│  │  ├─ Dockerfile
│  ├─ lookout/
│  │  ├─ Dockerfile
│  ├─ purger/
│  │  ├─ Dockerfile

Я наводив приклад з lookout, який використовує залежності з packages/logger та packages/eventually. Так ось, якщо ми тепер викличемо команду rush deploy та вкажемо, що ми хочемо зібрати lookout:

rush deploy --project lookout --target-folder /tmp/somewhere/in/the/abyss

То ми отримаємо теку /tmp/somewhere/in/the/abyss, але, що цікаво, вже з такою структурою теки:

monorepo/
├─ packages/
│  ├─ logger/
│  ├─ eventually/
├─ services/
│  ├─ lookout/
│  │  ├─ Dockerfile

Зверніть увагу, що в цій теці присутня тільки та частина монорепозиторію, яка необхідна для нормальної працездатності сервісу. Відповідно всі hardlink/softlink, які були створені, будуть вказувати на реальні файли, а значить всі залежності будуть знайдені. А все що зайве — було викинуто.

На додаток, rush deploy не тільки викидає частину монорепозиторію, яка не стосується цільового сервісу. Він також ще й перебирає node_modules і залишає тільки ті, які справді потрібні цільовому сервісу. Тому в результаті ми отримаємо теку, в якій є необхідний мінімум для виклику Node.js.

node /tmp/somewhere/in/the/abyss/services/lookout/dist/index.js

Маючи ось такий subset основного монорепозиторію, ми вже не маємо проблему з локально повʼязаними бібліотеками й сервісами. А тому можемо й запакувати його в контейнер:

docker build \
    --tag lookout:latest
    --file /tmp/somewhere/in/the/abyss/services/lookout/Dockerfile
    /tmp/somewhere/in/the/abyss

Єдине що я б тут додав, що цей процес починає виглядати дуже непривабливо для розробників. Оце піди, скажи через rush deploy який проєкт треба підготувати до збірки, а потім піди ще сам якісь docker build пороби з якимись незрозумілими контекстами. А тому я всю цю рутину запакував в скрипт до Rush.

Розширюємо команди Rush

Ще одна річ, яка мені дуже подобається в Rush, це те що ви можете розширювати його команди. Ну тобто писати свої власні скрипти, які ви можете підʼєднати до основного набору команд. Це робиться через command-line.json файл у його теці з конфігураціями.

Тобто, якщо раніше команда розробників вже навчилась збирати монорепозиторій через rush build, або тестувати його через rush test, то точно так само можна було б зробити й інтерфейс для збірки контейнерів!

Так я і зробив і надав командам скрипт, який доступний через rush build-docker команду. Основна суть цього скрипту саме в автоматизації тієї рутини, про яку я розповідав розділами вище. Це звичайний TypeScript скрипт, який використовує Rush API (так, в нього є API), для того, щоб зібрати контейнер для вказаного проєкту. Але я його ще більше розширив інтеграціями саме з нашим пропрієтарним стеком, а тому в результаті ми отримали команду, яку можна використати ось так:

rush build-docker --project lookout --push

І в результаті отримати:

• Пошук по репозиторію саме цього проєкту й підготовка його метаданих (через Rush API)

• Виклик rush deploy, який в тимчасову теку скидає той самий контекст для збірки (через child process)

• Підготовка всіх тегів, версій, назв для контейнера — всього, що необхідно для GitLab, щоб він прийняв до себе в реєстр наш образ (через версії із package.json та маніпуляції із рядками)

• Безпосередньо сама збірка контейнера (через Docker API, з яким я по сокету комунікую із TypeScript через dockerode)

• Ну і саме завантаження зібраного контейнера на GitLab Container Registry (теж через dockerode із TypeScript коду)

Таким чином, все те, про що ми щойно говорили, я приховав від команд розробників. Якщо їм потрібно зібрати контейнер для якогось зі своїх сервісів, то вони просто викликають то й же інструмент, яким вони й інші операції з репозиторієм роблять - Rush. Вони не те що про контексти збірок не думають, а навіть про версії та про те як там те завантажувати на реєстр.

Проте, якщо з погляду розробника, цього достатньо (розробник часто працює в рамках одного сервісу за одиницю часу), то з погляду DevOps є один незручний нюанс — а що, як нам треба зібрати всі контейнери? Ми ж не будемо бігати для кожного з них викликати rush build-docker?

Збираємо пачку контейнерів

Як щойно я зрозумів, що нам не вистачає команди, яка може працювати з сукупністю контейнерів, я одразу ж реалізував ще одну - rush build-docker-all.

Початкова реалізація була доволі проста — ітерація по всім Rush проєктам, які зазначені як сервіси, та виклик rush build-docker для них через дочірні процеси. Але я і тут стикнувся зі складнощами.

Річ у тім, що дуже часто розробники не змінюють ж всі сервіси у PR. Ну, це очевидно вже, так, але тоді я про це не подумав. І коли у вас в монорепозиторії вже більш ніж 30 сервісів, а змінився один, то… всі просто чекають поки зберуться всі 30 сервісів.

Тому я розширив свою команду ще одним прапорцем - --changed-only. Коли цей прапорець вмикається, rush build-docker-all після того, як збере всі сервіси на збірку, відфільтрує з них й залишить тільки ті сервіси, які реально були змінені. А тому rush build-docker вже викликався тільки для тих сервісів із монорепозиторія, які були змінені.

Як це виглядає на CI

Через те, що вся логіка реалізована на TypeScript, як звичайний скрипт, який використовує Rush API та Docker API, то там це все виглядає дуже просто. Ба більше, цей скрипт, він же оформлений як ще одна команда Rush. А тому, якщо дуже коротко, то в моїх скриптах збірки, процес виглядає приблизно ось так (спрощено):

#!/bin/bash

set -euo pipefail

rush build # Calls TypeScript
rush test # Tests the changes
rush build-docker-all --push --changed-only # Build and push Docker images for changed services

Справді, це все, тут більше нічого додати. Це буквально, спрощено звісно, частина CI, яка відповідає за збірку контейнерів — просто викликати rush build-docker-all --push --changed-only десь там у YAML файлах.

Ось так ми розвʼязали проблеми з локально повʼязаними бібліотеками, автоматизували збірку контейнерів через власний скрипт й зробили YAML трішки легшим для розуміння. Пишіть про свої досвіди збірки контейнерів. Як у вас побудований цей процес? :)

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

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

• По друге, хочу сказати, що жодних тонкощів реалізації, вихідних кодів, посилань безпосередньо на реалізацію, й інше - не буде. Але це не заважатиме нам говорити про концепції самого процесу як такого.

• Ну і, вся ця тема з CI/CD доволі обʼємна. Тож, я не намагаюсь втиснути в один пост взагалі все, що відбувалось. Є дуже багато питань, які я свідомо пропускаю в цьому пості, але які, можливо, ми піднімемо в наступних постах, коли буде ясно, про що саме можна було б поговорити.

• Також, майте на увазі, все про що ми будемо говорити, реалізувалось виключно мною протягом року. Сюди входить як і початкова фаза дизайну й намагань продавити його в бюджет й інше, так і сама реалізація, включно з допомогою командам мігрувати в нове середовище, розвʼязуючи їх проблеми на шляху до нього. Тому хоч я і кажу про великий обсяг роботи, який я робив майже рік, але сюди входить не тільки CI/CD, а і купа іншого супроводу.

Але який все-таки результат ми отримали? Почнемо з розробника, який прокинувся і взяв задачу в роботу.

Доброго ранку, девчик!

Розробник з команди, який береться за задачу після ранкового созвону, першим ділом підтягує собі останні зміни основної гілки - нічого незвичного. Стягнув собі через git pull, чи що він там використовує, останній commit з гілки, зробив йому rush install та rush all, аби переконатись, що станом на сьогодні, основна його гілка збирається та з нею все добре.

Якщо з git pull все зрозуміло, то, думаю, з rush треба трішки розповісти. Ми його використовуємо для менеджменту нашого моно репозиторію.

І от, rush install встановлює на робочій станції розробника залежності тих версій, які зараз знаходяться в основній гілці, та лінкує між собою всі наші пакети та сервіси, щоб локально воно все відчувалось як одне спільне під час розробки. Він також робить й інші речі, але не будемо про це в цьому пості.

Після успішного rush install, розробник, опціонально, може викликати rush all. Це просто сахар поверх інших команд: rush build, rush lint, rush test. Він, відповідно, викликає всі білд скрипти в усіх сервісах та пакетах, потім лінтери й врешті решт тести. Але, він не робить це для всього репозиторію. Не потрібно чекати, поки вся велика монорепа збереться. Він аналізує ваш локальний стан, дивиться, що було змінено за час відсутності розробника, і викликає ці команди тільки в тих місцях, які були змінені відносно вашого попереднього білда репозиторію. Тож, якщо викликати rush all на чистому репозиторії, то це білд всього, а вже наступний виклик rush all пропускає всі скрипти і закінчує свою роботу за менш ніж секунду. Дуже зручно для локальної роботи - дозібрати тільки те, що змінилось.

І ось розробник працює собі з таскою в його IDE, воно йому там все підсвічує, автоматично чинить помилки, форматує й так далі. Зміни в сервісі чи пакеті одразу поширюються на суміжні сервіси, які з ними повʼязані, і розробник може одразу ж локально все це запускати й перевіряти що воно працює.

В певний момент, він такий дивиться й каже: “Ну, наче можна відкривати PR”.

Створюємо Pull Request

Ми використовуємо GitLab для нашого коду, але це не дуже відрізняється від того, що на GitHub. Розробник бере гілку, в якій він працював, пушить на GitLab та створює новий Pull Request. Знову ж, нічого незвичного.

На цьому етапі, він може зробити паузу, піти попити чаю чи кави, але недовго :)

Одразу після створення PR, білд ферма починає робити свою роботу. Встановлюються залежності для репозиторію через rush install (воно, звісно, закешоване) та починаються запуски rush build (в основному, це виклик TypeScript компілятора, щоб зібрати dist), rush lint (тут, зазвичай, просто ESLint запускається) та rush test (залежно від видів тестів, які розробники пишуть, можуть бути різні інструменти, але переважно це mocha або jest).

І, здавалось б, наче нічого такого, але є там одна цікава деталь, яка допомагає робити це дуже швидко.

Я вже писав трішки вище, що, коли розробник робить rush all, воно здатне зрозуміти, що було змінено в порівнянні з попереднім станом, та на основі цієї інформації вивести список сервісів й пакетів, які змінились.

Так ось, такий самий алгоритм застосовується і на білд фермах. Береться PR та порівнюється з основною гілкою. Все що було змінено в PR, мапиться на список сервісів, які нам потрібно зібрати. Але і тут є нюанс.

Окрім того, що ми користуємось цим алгоритмом для розуміння де нам потрібно прогнати скрипти, нам також потрібно не забувати і про топологію. Якщо, скажімо, змінився сервіс А, який не працюватиме без пакету В (який не змінився, наприклад), то щоб зібрати цей сервіс А, нам потрібно також зібрати і пакет В, навіть якщо він не був змінений.

І ось тут ми приходимо до класичної проблеми графів та вибору його під-дерев (не знаю, як subtrees правильніше написати). І ми зробили наступним чином:

• rush build - обирає частину репозиторію, де явно були змінені файли. Включно з їх залежностями, щоб воно могло взагалі зібратись, та всіма, хто залежить від цих змінених файлів, щоб перевірити, що ми не зламали downstream, когось другого, хто від нас залежить.

• rush lint - обирає частину репозиторію, де явно були змінені файли і більше нічого. Перевіряти на best practices код, який не змінився, немає сенсу. Так само як і перевіряти downstream. Це повністю атомарна й ізольована задача, яка просто перевірить, що ваші зміни не порушують наші практики.

• rush test - обирає частину репозиторію, де явно були змінені файли. Включно з усіма, хто залежить від цих файлів. Таким чином, ми перевіряємо, що безпосередньо зміни не зламали нічого в сервісі. Але, також, перевіряємо і всіх, хто залежить від цих змін, на випадок, якщо хтось щось зламав для іншої команди чи іншого сервісу.

Ось такі, здавалось б, прості задачі, а під ними багато всякого цікавого відбувається :)

У випадку, якщо всі ці процеси пройдуть успішно, CI почне перевіряти, а чи описали ви зміни, які ви зробили. Це потрібно для наступної фази нашого CI процесу.

Версіонуємо наші зміни

Питання версіонування це завжди складно. Потрібно враховувати канали дистрибуції, чи потрібно нам підтримувати старі версії, чи потрібно нам бекпорти підтримувати й багато іншого. Це прям окремий пост можна писати.

В нашому випадку, в нас версіонування відносно просте, а тому ми вирішили його зробити повністю асинхронним та автоматичним. Але ж виникає тоді питання, а хто взагалі приймає рішення про те, яка має бути наступна версія, якщо це повністю автоматичне та асинхронне?

Так ось, ми вирішили це наступним чином. Якщо розробник забуде описати свої зміни, то CI завалить йому білд і напише список сервісів, які він змінив, але не описав ці зміни. В такому випадку, це означатиме, що розробник просто забув викликати ще одну команду rush - rush change. Якщо ж він не забуде її викликати перед створенням PR, то звісно що і білд валитись не буде. Що ж це за команда така?

rush change аналізує сервіси та пакети, які були змінені, та які піддаються політикам версіонування (ми можемо вказувати різні політики версіонування та розділяти внутрішні пакети на зовнішні й так далі). На основі цієї інформації, в інтерактивному режимі, розробник має описати, що він змінив, та вказати яка має бути наступна версія: patch чи minor (важливо зрозуміти, що ми вказуємо не саму версію, а лиш стратегію, за якою оновлювати версію).

Результатом цього інтерактивного опитування, яке відбувається виключно на локальному компʼютері розробника і не потребує нічого складного, стають JSON файли, які коммітяться разом з іншими змінами.

Тож тепер, CI бачить не тільки зміни і що вони працюють, а ще й має інформацію про те, який сервіс на яку версію потрібно буде оновити - ця інформація є частиною PR.

Це дає нам змогу не синхронізувати взагалі жодним чином інших розробників та команди. Кожен розробник, створюючи новий Pull Request, просто вказує стратегію оновлення версії через rush change і коммітить це разом зі своїми змінами.

Тому цей процес я і називаю асинхронним - тут відсутня координація між розробниками. Хоч у вас буде 200+ PR-ів, але якщо в кожному із них буде вказано розробником, що, наприклад, наступна версія має бути patch, то хто б там що не робив, але після мержу в основну гілку, наступна версія буде - теперішня версія з основної гілки + patch.

Якщо весь цей процес відбувається в рамках Pull Request, то окрім того, що CI робить нові версії згідно опису автора цього PR, він ще додає до нього dev-$COMMIT суфікс. Тож, якщо процес запустився на PR, то ми отримали дев збірку, яку ми можемо задеплоїти на тестові кластери та потестувати. Ну і, відповідно, якщо воно відбувається в основній гілці, то нова версія буде вже без dev-$COMMIT суфіксу.

Реалізувавши асинхронне (автор PR не координується з іншими) та автоматичне (CI бере теперішню версію й просто інкрементує згідно опису автора) версіонування, ми вже можемо зібрати артефакти з новими версіями, та завантажити їх по всім нашим реєстрам.

Деліверимо артефакти

Про артефакти я довго розповідати не буду. В нас тут все доволі класично і, на мою думку, нічого цікавого не відбувається.

Маючи нові версії пакетів та сервісів, наш CI прописує їх в package.json всіх тих пакетів, які підпадають під нову версію. Оновлені package.json, з новими version полями, використовуються для того, щоб вивести всі версії для всіх артефактів в подальших кроках.

Якщо це npm пакет, то використовується звичайний pnpm publish (звісно, що з врахуванням всіх тих нюансів, але в кінці це просто publish). Пакети публікуються в закритий реєстр на GitLab Package Registry, який знаходиться в тому ж проєкті, що і сам репозиторій.

Якщо це Docker образ, то ми його збираємо з використанням наших кастомних скриптів, які через програмне API комунікує з Docker Engine. Це нам дозволяє побудувати місток між Rush API та Docker Engine, що, своєю чергою, дозволяє нам реалізувати збірку контейнерів частиною команд rush. Що, своєю чергою…, дозволяє нам використати всі ті корисні речі, про які я розповідав раніше, для збірки саме контейнерів.

Ми розуміємо, де контейнер треба збирати, де не треба і тому подібне. Тегом контейнера виступає той ж version із package.json проєкту, який раніше був оновлений на CI. Результатом цього всього є команда rush build-docker-all --push --changed-only, яку ми викликаємо на CI, а він вже розбирається, що змінилось, й зібрав контейнери з новими версіями та запушив їх на GitLab Container Registry.

Ну і з Helm аналогічна ситуація. Окрім самого Helm, поруч з ним зберігається такий ж package.json, але він використовується лише для того, щоб зберігати там версію й інтегрувати в спільний workflow монорепозиторію. Ми і тут розуміємо, коли змінився Helm, і коли він змінився, то розробник описує зміну й стратегію для нової версії, а все інше - те саме. А, ну і сховищем для Helm Charts у нас є GitLab Package Registry.

Тож, на цьому етапі, в нас вже всі нові версії є, всі артефакти зібрані й всі розкидані по всім реєстрам. Вони задеплоїлись на тестові кластера, прогнались e2e тести і розробник отримує зелену галочку на свої dev-$COMMIT версії.

Даємо добро на мерж

Всі ці процеси, описані вище, відбуваються в Pull Request, а тому вони повністю безпечні. Мало того, ми не просто запускаємо весь цей CI процес на окремій гілці розробника, а робимо ефемерні комміти, які є результатом автоматичного злиття гілки розробника з основною гілкою. Це дозволяє нам розуміти, чи буде мерж успішним, чи ні, ще до того, як ми його змержимо. Тобто в нас немає ситуацій, коли ми постфактум дізнаємось, що після мержа основна гілка вже не працює. Ми про це дізнаємось ще на етапі Pull Request-а.

А ще, ми використовуємо Merge Train, як додатковий спосіб перевірки, чи буде мерж успішним, чи ні. Ці Merge Train-и здатні автоматично мержити декілька гілок в один комміт та запускати наш CI процес на комбінаціях декількох ПР-ів з основною гілкою. Як на мене, про це варто і окремий пост зробити, а тут не буду вдаватись в деталі.

Що б там не було, які б комбінації мержів там не тасувались, але ось, нарешті, розробник отримав ту зелену галочку і отримав дозвіл на мерж. Після чого це все вливається в основну гілку. Причому, важливо, що вливається як squash commit. Тобто що б там розробник собі не робив у своєму PR, то його пісочниця і він може робити що завгодно. Але в основній гілці це буде один єдиний комміт, з посиланням на PR розробника, де можна прослідкувати всю історію.

Таким чином, ми страхуємо себе від ситуації, коли недобросовісний розробник наробив коммітів по типу asdf та bla-lba, та які попали в основну гілку - такі ситуації ми забороняємо, але надаємо можливість робити що завгодно у гілці розробника, поки це залишається там.

Після змерженого Pull Request в основну гілку, запускаємо знову CI. Але цього разу, викидаємо з його роботи деякі моменти, які вже й так були виконані ще на етапі Merge Train. Через те, що ось той ефемерний комміт, про який я казав раніше, вже і так містить в собі комбінацію кодових баз розробника з його гілки та основної гілки - ми можемо не запускати той ж лінтер чи e2e тести - бо ми вже і так їх прогнали на цьому комміті, перед тим як мержитись.

А тому, CI на основній гілці викликає тільки rush build для змінених сервісів, щоб отримати артефакти в dist. Ми їх одразу ж оновлюємо на нові версії згідно опису автора PR та пакуємо в реєстри - CI закінчив свою роботу - ми отримали нові production артефакти.

Деплоїмось в dev

Як тільки ми отримали нові production артефакти, тобто з версіями типу 1.5.12, а не дев збірки, ми їх одразу ж деплоїмо на dev кластера. Так, я знаю, що для деяких команд, автоматичний деплой це щось страшне і штибу в “пʼятницю нічого не чіпайте”. Але я проти такої культури і, більш того, вважаю її неефективною. Потрібно працювати над створенням процесів, які дозволяють деплоїтись, коли вам завгодно, а не лякати людей і стримувати їх мантрами “працює - не чіпай”. Бо коли настане час справді чіпати - може бути вже пізно.

Так ось, для деплоїв на наші кластера, ми використовуємо Helm. Це доволі великий чарт, в якому прописані всі наші мікросервіси разом з їх базами даних й іншими операційними залежностями. Для того, щоб цей деплой був автоматичний, я реалізував скрипти, які беруть інвентар зібраних Docker образів та оновлює ними потрібний Helm chart. Це банальний обхід дерева YAML файлу та оновлення всіх збігів по Docker-у на нові версії. Тобто відкрили YAML, розпарсили його, отримали дерево, по якому пробіглись рекурсивно, та оновили всі збіги образів на нові версії.

Змінене дерево я зберігаю назад у файл і роблю новий комміт в основну гілку. Всі ці файли ми зберігаємо в текі .gitops й використовуємо Flux, для того, щоб застосовувати нові зміни на наші кластера. Тобто, таким чином, скрипт оновив та закоммітив нові версії в .gitops, а Flux уже прийшов й зробив reconcilation loop.

В результаті, ми отримали процес, в якому розробник після мержу свого Pull Request, може одразу бачити свої зміни на дев кластерах. Це, по відгуках, особливо приємно для frontend розробників. Бо вони не чекають когось, хто задеплоїть їх зміни. Вони змержились й хвилин через 5 вже бачать свої зміни на живому дев кластері. Ну, а для backend розробників, це теж корисно, бо вони одразу бачать чи не зламали вони щось після мержу свого PR.

Деплоїмось в production

Ось розробники пописали коду, перемержили PR-и, і такі сидять, і думають - може в прод? І це, я вважаю, і є те, заради чого, всі ці речі потрібно робити. Я вважаю, що деплоїтись в прод має бути виключно політичне рішення. Чи то маркетингове, неважливо. Не має бути жодних труднощів для команд задеплоїтись в production. Це має бути відбуватись за бажанням в будь-яку годину (ну, майже в будь-яку, в рамках розумного).

Для цього, команда йде на пайплайни репозиторію, та просто запускає ще одну задачу - deploy to production. І цей скрипт робить все те саме, що робить і скрипт для деплою в dev. Бабільше, використовується той ж скрипт, просто з іншими аргументами. Він пішов у YAML файл, але який стосується вже проду, оновив там всі версії й закомітив назад в .gitops, щоб Flux застосував зміни на кластери.

Єдиний, правда, момент в тому, що ми вирішили себе трохи таки застрахувати. Коли ми деплоїмось в прод, то версії для проду ми беремо виключно із версій теперішнього дев кластеру. Таким чином, ми хочемо себе застрахувати від моментів, коли щось могло б трапитись лише після довгої роботи кластера.

А тому, спочатку команда деплоїться в dev автоматично після мержу PR і, якщо на dev-і все добре, то ми можемо вважати, що і на проді теж буде норм, а тому версії можна перекласти в прод з деву.

Результати

На новому CI/CD процесі, команда вже працює в режимі деплою щоранку. Раніше, це було чи то раз у два тижні, чи щось таке, не памʼятаю. Звісно, тут ще багато було роботи, в тому числі культурної та менторської: розповісти, показати, зруйнувати міфи і тому подібне, але вже зараз вони відчувають покращення в порівнянні з минулою системою.

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

Звісно, ми ще знаходимо баги, чинимо їх, але загалом - маємо монорепозиторій, в який можна набирати більше команд, та який надає весь необхідний інструментарій для повного SDLC.

На цьому ми й закінчимо це велике полотно. Дякую вам, якщо дочитали до цього місця, та допоможіть мені лайком й розповсюдженням, якщо вам сподобалось. Тема велика, а тому пишіть коментарі, ставте питання та пропонуйте, про що б хотілось почитати далі.

Disclaimer

Проте одразу залишу парочку дисклеймерів, хоча я знаю, що ніколи ці дисклеймери не захищали від занудних тіпків, які хочуть показати що вони все знають.

По перше, я пишу цей текст от як від себе до людини, яка сидить поруч і я їй розповідаю історію. В мене немає зараз часу й бажання займатись редагуванням текстів і оце все, тому читайте це з чайочком там, чи з кавою, не напинайтесь лишній раз 🙂

По друге, я не пропагую ніяких best practices в цій статті. Це просто цікава історія (або ні), що можна зробити, на що повпливати й так далі й тому подібне. Можливо у вас є певні обставини, за яких вам необхідно зменшувати розмір образів, можливо ні. В будь-якому разі, якщо ви із цієї статті дізнаєтесь щось нове, не забувайте, що у всього є контекст і потрібно аналізувати й дивитись, чи варто робити щось, чи не варто. Ви всі великі молодці й у вас є свої голови на плечах, для того, щоб подумати, чи варто робити речі із цієї статті, чи не варто.

Почнемо з рішення “в лоб”

Я трішки подумав як би то можна було організувати, але чесно, зараз щось такий стан трохи втомлений, що я вирішив зробити це просто як інкрементальний процес від роздутого образу до чогось такого, до чого прийдемо згодом.

Я ще навіть не знаю куди ми прийдемо. Я пишу зараз цей текст без жодного контент-плану, імпровізую 🙂

Почнемо з того, що зазвичай можна знайти в просторах інтернету, простий й примітивний Dockerfile:

FROM node:lts
WORKDIR /app

COPY dist dist
COPY package.json package.json

RUN npm install

CMD [ "node", "dist/index.js" ]

Зібравши цей образ через docker build й запустивши його через docker run ми вже маємо сервер, який готовий приймати наші запити:

Server is listening on http://69bfecfb40ae:36199

Сам сервер це звичайний Hapi сервер, ніякої екзотики.

Глянувши в docker images ми побачимо, що розмір цього образу 1.8GB 🤯

І тут буде цілком очікуваним позадавати питання штибу “ви шо тут, вообще всі такі чи шо?”.

Тож давайте потроху розбиратись.

Відділяємо run-time залежності від compile-time залежностей

Один із факторів який впливає на розмір вашого Docker образу - node_modules.

Я бачив різні команди й різні підходи до розв'язання цієї проблеми, дехто їх і взагалі не вирішував, як ось npm install просто та і все.

Але загалом, правилом гарного тону все ж є використання --production при встановленні тільки тих залежностей, які вам критично необхідні для працездатності сервісу.

Коли ви вказуєте у своїх package.json залежності, то дотримуйтесь правила, що в dependencies ви вказуєте тільки ті залежності, які вам потрібні в runtime. В моєму випадку це @hapi/hapi, бо на ньому в мене сервер написаний. Без нього, мій сервер просто не запуститься. Це робить цю залежність необхідною в runtime.

Все інше, що вам потрібно щоб прогнати ESLint, чи може тести прогнати, чи ще щось — якщо це робиться під час розробки й не потрібно в runtime - виносьте в devDependencies.

Таким чином, у вас локально npm install буде встановлювати все що треба для розробки. А коли ви будете готувати ваш сервіс, який вже зібраний, до роботи в runtime, то використовуйте там npm install --production:

FROM node:lts
WORKDIR /app

COPY dist dist
COPY package.json package.json

RUN npm install --production

CMD [ "node", "dist/index.js" ]

Зробили знову docker build і подивились скільки тепер займає образ - 1.69GB. Ще дуже далеко до 40 Мб 😆

Давайте тепер поговоримо про різницю між різними образами від яких ви можете наслідуватись!

lts, lts-slim

Коли ви обираєте який базовий образ використовувати, памʼятайте, що неправильно підібраний образ може мати різні наслідки починаючи від проблем з розміром і закінчуючи несумісністю архітектур й того що компілюється, коли ви встановлюєте якість нативні аддони під Node.js.

От почав я з того, що обрав node:lts як базовий образ, але що там, в цьому образі?

Якщо піти глянути на Docker Hub, то ми можемо побачити там, з яких інших образів був створений цей образ, які шари застосовані й т.п.

Ми бачимо що node:lts побудований з debian:12 до якого потім додали buildpack-deps і пішло поїхало по ланцюжку.

Тобто наш образ node:lts насправді має в собі не тільки Node.js, який ми запустили й поїхали. Також, в нашому образі знаходиться велика купа різних бінарників, бібліотек, які насправді не потрібні нам для того, щоб запустити наш сервіс. Це можуть бути всякі git, curl, ca-certificates і що там ще можна згадати, мені ліньки 🙂

Чи потрібні нам всі ці пакети при збірці наших сервісів, компіляції, тестування — звісно! Чи потрібні вони нам, коли ми вже запускаємо це в runtime - ні!

Тому правилом гарного тону вважається, що у вас є оточення, яке ви використовуєте для збірки ваших сервісів, а є оточення, яке ви використовуєте вже безпосередньо для запуску цього сервісу.

І в нашому випадку, ми можемо позбутись цього роздутого образу з buildpack-deps, використавши lts-slim.

Якщо ми поглянемо на інвентар того, що є в цьому образі, то ми побачимо наступне:

По перше, тепер у нас два базових образи, з яких будувався lts-slim. По друге, в шарах вже немає всіляких apt-get update та apt-get install.

Тобто ці образи хоч і містять меншу кількість різних бінарників та інструментів, що заважає розробці, але для production нам це і не потрібно. Тому тут мінус в тому, що ми втрачаємо всілякі зручності повноцінних ОС, але виграємо в потенційно захищенішому середовищі, бо менше потенційних векторів атаки, та виграємо в зменшеному розмірі нашого власного образу. Тому замінимо lts на lts-slim:

FROM node:lts-slim
WORKDIR /app

COPY dist dist
COPY package.json package.json

RUN npm install --production

CMD [ "node", "dist/index.js" ]

Зібрали знову образ і подивились, а скільки він тепер займає місця - 429MB.

Ну це вже прям непогано. Принаймні GB замінились на MB 😄

Але поговорім про ще один варіант, більш радикальний.

Alpine Linux

По всіляких Linux дистрибутивам можна дуже довго розмовляти. Починаючи від “BTW, I’m using Arch”, “вічно дивитись як тече вода, збираються портажі на Gentoo”, а потім сісти за макбук і на Notion поток сознанія видавать.

Так от Alpine Linux це один із дистрибутивів Linux, але в якого є кардинальні відмінності від більш house-hold дистрибутивів Linux, таких як Debian (пробачте мені молодого, я не хотів називати їх house-hold).

Цей дистрибутив спеціально заточений, по дизайну, бути малим за розміром. Але досягає він цього дещо “радикальними” методами (хоча рівень радикальності тут можна задавати відносно окремо взятих систем координат).

По перше, він використовує musl замість glibc. Якщо хтось із читачів писав програми на С, то він знає, що в C є стандартна бібліотека. А чи то musl, чи то glibc - це вже реалізації цих стандартних бібліотек.

Так от, вважається, чи то вважалось, тут мої знання можуть бути вже не актуальні, але вважалось, що Node.js більше дружить з glibc і вірогідність що якийсь нативний аддон чи C-шний код не відпрацює з glibc набагато нижча, аніж якби це був musl. Можливо зараз там стан речей зовсім інший, але хай там як, потрібно усвідомлювати, що такі речі можуть принести багато цікавих проблем на вашу голову, якщо вам не пощастить.

По друге, він використовує BusyBox. От якщо ви звикли до того, що у всіляких Debian-ах у вас купа бінарників, де кожен надає якийсь свій інструментарій, то BusyBox це все один бінарник, в якому купа цих інструментів. Ну добре добре, не купа, менше 🙂

Ну і ще там OpenRC замість systemd… короче… ви зрозуміли — змін багацько. Радикальних змін.

Тож чим більше у вас всілякої екзотики у вашому сервісі, можливо кастомних нативних аддонів, абощо, тим більше уваги вам треба приділяти перевірці, що воно точно під Alpine заведеться.

Але у нас це звичайний сервер на Hapi, так шо нам норм, поїхали 🙂

FROM node:lts-alpine
WORKDIR /app

COPY dist dist
COPY package.json package.json

RUN npm install --production

CMD [ "node", "dist/index.js" ]

Зібрали цей образ і отримали розмір - 308MB. Що ж можна придумати ще?

Викидаємо npm з процесу збірки

Якщо нам обставини дозволяють, або можливо це навіть архітектурно прописано у вашій компанії, то ми можемо зрізати ще в одному місці 😉

Суть дуже проста. Ми коли викликаємо npm install то при встановленні залежностей, npm тягне то всьо з інтернету, завантажує це у своєму кеші й так далі й тому подібне. Ми то, звісно, можемо зробити потім npm cache prune чи як воно там, але особисто мені воно якесь meh.

Окрім цього, він ще й компілює нативні аддони, якщо залежності цього потребують, і компілює він їх під ту архітектуру, на якій ви запустили процес збірки. Тобто якщо ви запустили npm install на макі (darwin-arm64v, якщо не помиляюсь) то node_modules будуть містити в собі код, який працюватиме тільки на таких же маках з архітектурою darwin-arm64v. Якщо ви node_modules скопіюєте в образ і запустите його на linux-amd64 то я сумніваюсь що воно у вас запрацює, але ви можете спробувати, звісно.

Але! 😉

Якщо ми впевнені в тому, що на CI пайплайнах використовується ферма із нод з такою ж архітектурою, яка використовується і в проді, то ми можемо зробити фінт вухами.

Замість того, щоб робити npm install під час збірки образу, ми можемо зробити його в контексті звичайного процесу збірки вашого репозиторію. Якщо архітектури збігаються, то тоді node_modules вашого репозиторію можна буде просто перенести в контейнер і не тягнути туди npm install.

А якщо ще й застосувати, як я їх називаю, екстрактори в пакетних менеджерах, то це взагалі можна зробити так, що node_modules будуть містити ну прям дуже гарний layout, ну прям 🤌

Наприклад у pnpm є команда pnpm deploy. Або ж якщо ви використовуєте підхід з моно репозиторієм і ви використовуєте Rush як інструмент для менеджменту вашого репозиторію, то в нього теж є rush deploy --project PROJECT --target-folder path/to/folder.

В чому їх особливість?

Ці команди аналізують ваші пакети, які ви хочете винести й аналізують залежності, які вашим пакетам потрібні. Маючи цю інформацію, ці команди здатні зробити вам окремо теку, де будуть лежати тільки ваші production файли разом з node_modules, де лежать тільки те, що справді потрібно в runtime - production залежності.

Воно настільки самодостатнє, що ви навіть можете зробити rush deploy --project my-package --target-folder /app і одразу викликати node /app/dist/index.js - воно спрацює. Бо всі node_modules вже там, всі files із вашого package.json вже теж там.

Хочете зробити просто архів з цим і десь передати щоб потім запустити через node - кидайте.

Хочете зробити якийсь свій дуже кастомний процес delivery цього на якісь ноди - робіть.

А ми ж зробимо наступним чином…

Новий build context для образу

Ми дізнались що в пакетних менеджерах є команда, яка дозволяє нам виокремити із нашого репозиторію з купою коду й залежностей теку, яка буде містити в собі мінімальний набір необхідного для запуску в проді.

Якщо ми застосуємо це як новий build context для докера, то нам, насправді, вже й не треба ніякі npm install чи то COPY dist dist чи ще щось - в нас готовий артефакт, самодостатній, який працює і без докера. Тобто докер в цьому контексті починає виступати просто як, буквально, контейнер 🙂

Тож що ми робимо…

Ми беремо, викликаємо, скажімо rush deploy --project hapi-server --target-folder common/deploy.

Якщо ми тепер викличемо node common/deploy/dist/index.js, то побачимо, що наш сервер все ще працює й слухає порт:

Server is listening on http://ghaiklor---MacBook-Pro.local:52215

А по структурі файлів там просто dist з моїми JS файлами та й node_modules. Все.

Як же це тепер запакувати в образ? Та насправді дуже просто 🙂

Якщо ми враховуємо, що цей common/deploy стає нашим новим build context для докера, то нам вже не потрібні вибіркові COPY, ми можемо тупо зробити COPY . .:

FROM node:lts-alpine
WORKDIR /app

COPY . .

CMD [ "node", "dist/index.js" ]

Можна навіть залишити коментар нашим наступникам, щоб вони не подумали, що цей COPY . . копіює взагалі весь репозиторій:

FROM node:lts-alpine
WORKDIR /app

# The COPY command here copies the entire prepared folder into the Docker image.
# This works because we're using the `rush deploy` command.
# Which prepares a minimized subset of the monorepository containing only the necessary files and dependencies.
# The prepared folder acts as the build context on CI.
# So it's already optimized to exclude unnecessary files, such as development tools.
# As a result, copying the entire folder is safe since everything included in the build context is essential for the service’s operation.
# And there's no risk of including extraneous files from the broader monorepo.
COPY . .

CMD [ "node", "dist/index.js" ]

І, як бачимо, ми вже не викликаємо тут npm install, бо node_modules вже теж там 🙂

Що ж, почнімо збірку з врахуванням цього трюку:

rush deploy --project hapi-server --target-folder common/deploy
docker build --file common/deploy/Dockerfile --tag hapi-server common/deploy

З таким Dockerfile та цією комбінацією команд, ми, по великому рахунку, всю збірку вже зробили ще на самому хості. Тут же, ми просто прокидуємо вже зібране в сам образ - от і все.

Гляньмо, що в нас там зараз з місцем виходить - 192MB! Ну це вже не майже 2Gb, правда ж? 😄

Щоб бути гарними хлопчиками, вкажімо ще конкретну версію Node.js рантайма, щоб не вистрілити собі в ногу випадково, коли lts-alpine неочікувано зміниться на іншу версію:

FROM node:20.17.0-alpine
WORKDIR /app

# The COPY command here copies the entire prepared folder into the Docker image.
# This works because we're using the `rush deploy` command.
# Which prepares a minimized subset of the monorepository containing only the necessary files and dependencies.
# The prepared folder acts as the build context on CI.
# So it's already optimized to exclude unnecessary files, such as development tools.
# As a result, copying the entire folder is safe since everything included in the build context is essential for the service’s operation.
# And there's no risk of including extraneous files from the broader monorepo.
COPY . .

CMD [ "node", "dist/index.js" ]

Не те, щоб я очікував, що тут щось зміниться з розміром, але як правило гарного тону…

Distroless

Ще один варіант, який можна застосувати, це distroless:

Конкретно в нашому випадку, в тому що я зробив до цього, то ми багато не виграємо, насправді. Я навіть не знаю, може ми нічого не виграємо, давайте перевіримо 😅

Специфіка цих образів в тому, що в них відсутнє все те, що зазвичай присутнє в дистрибутивах Linux. Ви в них не знайдете ніяких shell-ів, пакетних менеджерів - нічого.

В них є тільки необхідне для того, щоб запустити Node.js, в нашому випадку.

Спробуймо замінити наш FROM на distroless образ й подивитись, скільки ми отримаємо:

FROM gcr.io/distroless/nodejs20-debian12:nonroot
WORKDIR /app

# The COPY command here copies the entire prepared folder into the Docker image.
# This works because we're using the `rush deploy` command.
# Which prepares a minimized subset of the monorepository containing only the necessary files and dependencies.
# The prepared folder acts as the build context on CI.
# So it's already optimized to exclude unnecessary files, such as development tools.
# As a result, copying the entire folder is safe since everything included in the build context is essential for the service’s operation.
# And there's no risk of including extraneous files from the broader monorepo.
COPY . .

CMD [ "dist/index.js" ]

Зверніть, до речі, увагу, що ми прибрали node із CMD. Через те що в distroless образах відсутній shell, то ми не можемо це запускати вже як раніше. Але ми можемо вказати прямо шлях до нашого файлу. В distroless це спрацює.

Гляньмо, скільки тепер займає місця - 189MB. Не густо щось 😂

Із цих 189 Мб, сам тільки Node.js займає майже 100MB, але чому так багато?

Що ми можемо викинути з Node.js?

Зараз вже майже восьма година вечора. Я приїхав з офісу додому й хочу вже поскоріш закінчити цю, і так довгу, історію 🙃

Тому на цьому етапі ми закінчимо з практичною частиною, проте, пофантазуємо, що ми можемо зробити ще, якщо це справді буде необхідно.

Річ у тім, що заздалегідь зібрані бінарники Node.js під різні платформи містять в собі ну-у-у-у занадто багато всього. Наприклад?

Наприклад Internationalization - https://nodejs.org/api/intl.html

Всі ці API, яка надає вам Node.js, по типу Intl обʼєкту чи .localeCompare() й тому подібні несуть за собою доволі відчутний розмір.

І що ми могли б зробити, насправді, це зібрати власний бінарник Node.js, в якому повикидати те що нам не потрібно. Ну, принаймні, те що ми можемо викинути.

У випадку з інтернаціоналізацією, якщо ми розуміємо, що ми ці API не використовуємо, то давайте зберемо Node.js без ICU. Зклонували собі репозиторій з вихідними кодами Node.js й еге-ге-й:

Останній раз коли я контрібʼютив в Node.js, це робилось так, як зараз, я, чесно, не знаю, можливо вони щось змінили, тому take it with a grain of salt.

./configure --without-intl
make

Тобто ми налаштовуємо білд систему й кажемо їй, що ми хочемо скомпілювати Node.js, але без використання ICU. Отриманий node бінарник буде вже займати, по грубим прикидкам, на 20-40 МБ менше, в залежності від купи факторів.

Також можна почати думати щось цікаве з zlib чи openssl, можливо викинути їх теж, або скомпілювати як з shared libraries. Загалом, можна буде подумати. Детальніше про те, як зібрати Node.js у себе вдома, можна почитати ось тут:

До прикладу, ось залежності в збірці Node.js, яка в мене стоїть, встановлена через nvm, та яка займає 90MB:

{
  node: '20.17.0',
  acorn: '8.11.3',
  ada: '2.9.0',
  ares: '1.32.3',
  base64: '0.5.2',
  brotli: '1.1.0',
  cjs_module_lexer: '1.2.2',
  cldr: '45.0',
  icu: '75.1',
  llhttp: '8.1.2',
  modules: '115',
  napi: '9',
  nghttp2: '1.61.0',
  nghttp3: '0.7.0',
  ngtcp2: '1.1.0',
  openssl: '3.0.13+quic',
  simdutf: '5.3.0',
  tz: '2024a',
  undici: '6.19.2',
  unicode: '15.1',
  uv: '1.46.0',
  uvwasi: '0.0.21',
  v8: '11.3.244.8-node.23',
  zlib: '1.3.0.1-motley-209717d'
}

Якщо буде стояти питання порізати Node.js, щоб воно вмістилось на якусь embedded приблуду, то можна буде подумати в напрямку збірки свого власного бінарника.

Буде це питання того, щоб повністю викинути якісь шматки, чи буде це питання вивчення конкретного дистрибутива, які бібліотеки в тому дистрибутиві є і чи можемо ми скомпілювати Node.js, який буде динамічно лінкуватись до цих бібліотек - то вже, як кажуть, треба буде розбирати конкретний кейс.

Просто для прикладу, наскільки я знаю, то Arch Linux має системний ICU, тож можна було б скомпілювати Node.js з --with-intl=system-icu і не тягнути його з бінарником Node.js.

Короче, гратись можна було б довго з цим й пробувати різні комбінації.

Я знаю випадки, коли такими танцями витягували Node.js бінарник до 15-20MB. Але, знову ж таки, вони всі зачіпають збірку Node.js з його вихідних кодів з різними тюнінгами 🙂

Компресія образів

Весь цей час, всю цю історію, ми розглядали розмір образів як образів без компресії. Тобто це все розміри вже “розпакованих” образів.

Але ж ми, коли пушимо образ в реєстр, Docker нам додатково ще застосовує алгоритми компресії. Тому давайте глянемо, а скільки ж, такий образ, який ми створили на Alpine Linux, буде займати місця безпосередньо в реєстрі? Скільки трафіку буде бігати по мережі, коли буде завантажуватись образ?

Я запушив цей образ на GitLab Container Registry та глянув, скільки місця він займає в реєстрі - 45.40 MiB.

Тобто, після компресії, наш образ займає 45MB в реєстрах, а значить, по мережі буде йти 45MB, а не 192MB.

Закінчуємо

На годиннику вже девʼята вечора, тож буду йти відпочивати.

Сподіваюсь, в цьому потоці сознанія, ви віднайшли для себе щось нове, можливо абсурдне, можливо креативне, то вже як буде. Я поділився історією, яку я сьогодні в себе на ноуті провів, а вам вже вирушівати для себе, що воно дає і чи дає взагалі.

Всіх благ і гарного вечора ❤️