Найкращі 4 тактики, щоб тримати Rockin ’у Docker - Docker Blog

У нас є всі свої улюблені мови та фреймворки, і Node.js є для мене першим. Я запускав Node.js у Docker з перших днів для критично важливих програм. Я маю на меті навчати всіх, як отримати максимальну віддачу від цієї основи та його інструменти, такі як npm, Yarn та nodemon з Docker.

Існує маса інформації про використання Node.js з Docker, але стільки з цього застаріло на роки, і я тут, щоб допомогти вам оптимізувати налаштування для Node.js 10+ та Docker 18.09+. Якщо ви віддаєте перевагу перегляду мого виступу на DockerCon 2019, який охоплює ці теми та багато іншого, перегляньте його на YouTube.

Давайте пройдемо 4 кроки для того, щоб ваші контейнери Node.js співали! Я включу декілька коротких записів "Задовго; Не читав »для тих, хто цього потребує.

Дотримуйтесь поточного базового дистрибутива

TL; DR: Якщо ви переносите програми Node.js у контейнери, використовуйте базове зображення хост-ОС, яка ви маєте сьогодні на виробництві. Після цього моїм улюбленим базовим зображенням є офіційний node: slim editions, а не node: alpine, що все ще добре, але, як правило, більше роботи для реалізації та має обмеження.

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

тонкий та альпійський набагато менші за зображення за замовчуванням. Існує безліч факторів, які впливають на це, але не робіть "розмір зображення" головним пріоритетом, якщо ви не маєте справу з IoT або вбудованими пристроями, де кожен МБ має значення. За останні роки тонкий образ зменшився до 150 МБ і працює найкраще в найширшому наборі сценаріїв. Alpine - це дуже мінімальний розподіл контейнерів, із найменшим зображенням вузла лише 75 МБ. Однак рівень спроб поміняти менеджери пакетів (apt на apk), розібратися з крайовими випадками та обійти обмеження сканування безпеки змушує мене зупинятися на рекомендації node: alpine для більшості випадків використання.

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

Робота з вузловими модулями

TL; DR: Вам не потрібно переміщувати node_modules у ваші контейнери, якщо ви дотримуєтеся кількох правил для належного місцевого розвитку. Другий варіант - перемістити mode_modules вгору по каталогу у вашому Dockerfile, правильно налаштувати контейнер, і він надасть найбільш гнучкий варіант, але може не працювати з кожною структурою npm.

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

Ядро цієї проблеми для Node.js полягає в тому, що node_modules можуть містити двійкові файли, скомпільовані для вашої хост-ОС, і якщо вона відрізняється від ОС контейнера, ви отримаєте помилки при спробі запустити програму, коли ви прив'язуєте її до господар для розвитку. Зверніть увагу: якщо ви розробник чистого Linux і розробляєте на Linux x64 для Linux x64, ця проблема з монтуванням, як правило, не турбує.

Для Node.js я пропоную вам два підходи, які мають свої переваги та обмеження:

Рішення A: Будьте простими

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

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

Розробити тільки через контейнер. Чому? По суті, ви не хочете змішувати node_modules на вашому хості з node_modules у контейнері. У macOS і Windows Docker Desktop прив'язує ваш код через бар'єр ОС, і це може спричинити проблеми з двійковими файлами, які ви встановили з npm для хост-ОС, які неможливо запустити в контейнерній ОС.
Запустіть усі свої команди npm через docker-compose. Це означає, що початковою установкою npm для вашого проекту тепер слід виконати docker-compose run npm install .

Рішення B: Перемістіть контейнерні модулі та сховайте хост-модулі

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