Як ми швидше розгортаємо гарячі контейнери Docker

Безсерверна розробка та цикли зворотного зв’язку

За допомогою безсерверної хмари Dagster ви можете розробляти та розгортати код Dagster без налаштування локального середовища розробки чи хмарної інфраструктури. Коли ви вносите зміни в GitHub, дія GitHub створює та розгортає ваш код безпосередньо в Dagster Cloud, де ви можете переглядати свої об’єкти Dagster і взаємодіяти з ними в інтерфейсі користувача.

Спочатку ми використовували наш стандартний процес збірки на основі Docker для Dagster Cloud Serverless, але швидко виявили, що через це цикл збірка-розгортання-запуск надзвичайно повільний. Щоб пришвидшити це, ми впровадили систему доставки коду поза образами Docker. У цій статті описано проблеми, які ми проаналізували, рішення, яке ми обрали, і різноманітні компроміси, які ми зробили в процесі.

<цифра> Шалаб Чатурведі ділиться оглядом високого рівня нової можливості швидкого розгортання Dagster Cloud.Проблема із зображеннями Docker

Коли ми створюємо образи Docker на GitHub і розгортаємо їх у Dagster Cloud, для кожного коміту в інтерфейсі користувача Dagster потрібно 3–5 хвилин. Безсерверні розробники часто вносять невеликі зміни в код з кожною ітерацією, і чекати більше 3 хвилин, щоб побачити ефект цієї зміни, дуже швидко стає втомливим. Ми проаналізували, «що відбувається, коли ви редагуєте рядок коду та фіксуєте» та виявили наступне:

Як ви бачите вище, дві речі, які займають найбільше часу:

створіть образ Docker (60-90+ секунд) розгортання контейнера Docker (90 секунд)

Давайте розглянемо кожен із них.

Створюйте образи Docker

Декілька речей, на які слід звернути увагу щодо створення образу Docker:

Зображення Docker складаються з кількох шарів у стеку, де кожен шар створюється підмножиною команд у файлі Docker. Кожен шар ідентифікується хешем. Під час завантаження зображень до реєстру завантажуються лише шари, яких немає в реєстрі (ідентифікуються хешем). Перебудова зображень на машині збирання GitHub за допомогою кешу дій GitHub перетягує всі непризначені шари з кешу на машину збирання. Зауважте, що якщо у вашому проекті є велика кількість залежностей, які не змінюються, вони все одно будуть скопійовані з кешу на машину збирання під час процесу збирання. Збірки Docker не є детермінованими. Якщо ви двічі створюєте зображення з абсолютно однаковим вмістом, кожен раз він може створювати інший хеш. (Хоча це не має прямого відношення, ми хотіли звернути увагу на це несподіване спостереження. В особливому випадку вважайте, що щойно створений великий шар, ідентичний шару, який уже є в реєстрі, усе ще можна завантажити як новий шар. ) Запустіть контейнери Docker

Головне, про що слід пам’ятати про запуск контейнерів Docker, це те, що ми використовуємо AWS Fargate, а підготовка та завантаження образу займає 45–90 секунд. Він не забезпечує кешування зображень. Запуск нового контейнера завантажує всі шари реєстру в наданий контейнер.

Інші обмеження

Після створення та запуску образу Docker ми запускаємо код користувача, щоб отримати метадані, які відображаються в інтерфейсі користувача. Це неминуче і може зайняти від кількох секунд до 30 секунд або більше, залежно від способу обчислення метаданих (наприклад, він може підключитися до бази даних для читання схеми). Цей сервер коду залишається активним і обробляє запити метаданих, доки не буде подано нову версію коду, яка потім запускає новий контейнер.

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

Огляд альтернатив

Ось кілька альтернатив, які ми досліджували та обговорювали:

Перейдіть із Fargate на EC2 для швидшого запуску контейнерів. Це збільшить наше операційне навантаження, вимагаючи від нас попередньої підготовки, моніторингу та масштабування нашого кластера. У нас все ще буде проблема повільних збірок Docker. Перейдіть на іншу систему збірки Docker, наприклад AWS CodeBuild. Для реалізації цього потрібно ще багато роботи...