Когда можно считать, что вышла новая версия Node.js?
#docker #devops

У #Nodejs есть официальный график выхода и поддержки мажорных версий. Так 20 апреля ожидается первый релиз 16 версии Node.js.
Выход минорных и патч версий не имеет графика, а определяется Node.js Release Working Group.
Например, 6 апреля была опубликована версии 14.16.1. Спустя 24 часа Node.js Docker Working Group опубликовали эту версию на Docker Hub.
Еще раз, за выпуск binary и Docker image отвечают разные люди, поэтому задержка составляет сутки и более.
В современных проектах Node.js запускается как Docker контейнер, поэтому именно появление новой версии Docker Image стоит считать выходом новой версии.

Как конфигурировать Node.js приложение?
#best_practice #package #devops

TL;DR Конфигурация хранится в переменных окружения без значений по умолчанию. Если какой-либо переменной нет или формат не верный, то приложение не должно запускаться. Требуемые переменные описываются в env.example. Реализация dotenv-safe

Теория
Каждому #nodejs разработчику следует знать 12 факторный манифест . Следование его принципам позволит создавать масштабируемые веб-приложения и комфортно сотрудничать с DevOps инженерами. Третий фактор говорит, что конфигурация должна храниться в настройках окружения (env vars). Рекомендую с этим фактором ознакомиться, там подробно описано почему стоит использовать именной такой подход.

Применение
Значения всех переменных окружения доступны:
- в терминале с помощью команды env
- на уровне Node.js кода с помощью объекта process.env.

Значения конкретной переменной <NAME> доступно:
- в терминале с помощью $<NAME>
- на уровне Node.js кода с помощью process.env.<NAME>

Установить переменные окружения можно:
– посредством команды export. Например: export NODE_ENV=production . Результат команды не сохраняется между сессиями консоли. Для внесения долгосрочный изменений в окружение команду необходимо прописать в .bashrc или его аналог.
– посредством команды source
– В момент запуска процесса как ИМЯ=ЗНАЧЕНИЕ перед самой командой. Пример: NODE_ENV=production DEBUG=0 node src/index.js Работает как в терминале, так и в npm scripts.
– Изменением значений в process.env уже во время работы приложения.
 
.env
.env файл с переменными окружения используется для упрощения локальной разработки. На всех других окружениях его использование является плохой практиков. .env никогда не должен храниться в git репозитории. Поддержка есть во всех IDEA. Для консоли есть расширения, например autoenv. На уровне кода общепринятым пакетом является dotenv. Он вычитывает в process.env значения из .env, но не заменяет уже существующие значения.

.env.example
.env.example описывает все требуемые переменные окружения для работы приложения. Там можно и нужно делать комментарии. Это single source of truth для вашего DevOps инженера. Его необходимо хранить в git. Если приложение, не имеет какого-либо из ожидаемых переменных, то оно не должно стартовать. Fail fast! Этот функционал обеспечивает пакет dotenv-safe, который является оберткой над dotenv.

Советы по уменьшению количества переменных
– Используйте connection string. Пример: DB_URL=postgresql://postgres:password@localhost:5432/database
– Используйте JSON в значениях переменных. Пример: const stripeConfig = JSON.parse(process.env.STRIPE_CONFIG)
– Используйте значения через запятую. Пример: const adminList = process.env.ADMINS.split(',')

Распространенные ошибки
– Отсутствие приведение типа. Все ключи объекта process.env имеют значения типа string. Пример, вопреки ожиданиям при запуск с SOME_FEATURE=false код if process.env.SOME_FEATURE ... будет исполнен.
– Использование значений по умолчанию. Пример, const logLevel = process.env.LOG_LEVEL || 'info'. Это приводит к неявной конфигурации и дорогостоящим ошибкам.
– Ошибка в путях к .env из-за использования относительных, а не абсолютных путей.
– Ошибка характерная для FE разработчиков: не понимание разницы между переменными окружения в build-а и run time.
– Ошибка характерная для microservice разработчиков в проектах с Service discovery: различие локального и прод окружений. Необходимо запускать Consul или его аналоги через Docker.

Как запускать Node.js с доп. аргументами?
#nodejs_api #devops

При запуске #nodejs бывает необходимо передать дополнительные аргументы. Примеры:
➡️ node --no-warnings app.js
➡️ node --title='MyApp' app.js
➡️ node --require dotenv/config app.js
Полный перечень аргументов и их использование в документации CLI.

Стоит знать об переменной окружения NODE_OPTIONS. Любые значения из нее Node.js добавляет в перечень аргументов. На одном из проектов мы включаем DataDog вот таким образом: NODE_OPTIONS='--require dd-trace/init'

15 Factor App
#devops

Я часто рассказываю об 12 факторах. Это манифест как делать веб приложения правильно (масштабируемо, переносимо и т.д.). Прелесть этих факторов, что они универсальны:
– работают для любой архитектуры – монолит или микросервисы
– любого языка
– любого облака

Ребята из IBM расширили манифест до 15 факторов. Новые факторы:
– API First, т.е. сначала делаем контракт нового API, а только потом его реализовываем.
– Telemetry. Логи из 12 факторов это поток событий, а телеметрия это time series метрики.
– Authentication and authorization. Снова напоминаем себе и команде об важности безопасности.

Що перевірити при розгортанні API?
#list #devops #cloud

1️⃣ Чи є Load Balancer?
Без нього масштабування не можливо.
2️⃣ Чи включений редирект з http на https?
Ваше API має працювати тільки по https.
3️⃣ Чи включений HTTP/3?
74% користувачів мають браузер з підтримкою HTTP/3.
4️⃣ Чи налаштовано стискання (compression)? Які методи підтримуються?
Load Balancer має цю відповідальність, а не Node.js
5️⃣ Чи має публічне API кешування?
Поділ публічного та приватного API (яке вимагає авторизації) відповідальність розробників, а ось налаштувати Load Balancer-а – DevOps інженер.

Як правильно реалізується 12-й фактор у NestJS?
#nestjs #devops
Нагадаю, що XII фактор це "Задачі адміністрування". Він визначає:
1️⃣ Запуск міграції бази даних
2️⃣ Запуск консолі (REPL) для виконання довільного коду або перевірки моделі застосунку на діючій базі даних
3️⃣ Запуск разових скриптів, збережених в репозиторії застосунку

⚠️ Стратегія розгортання повинна визначати процес застосування міграцій.

NestJS екосистема пропонує нам:
1️⃣ Migrations, щоб синхронізувати схему бази даних та код.
2️⃣ NestJS REPL, для одноразових адміністративних завдань.
3️⃣ Nest Commander/nestjs-command, для регулярних адміністративних завдань.

Конкретні приклади за мій минулий тиждень:
1️⃣ Додав нове поле у модель та згенерував міграцію за допомогою migration:generate.
2️⃣ За допомогою REPL та Stripe Dashboard зробив refund, бо бізнес поки що не готовий це автоматизувати.
3️⃣ Використов CLI, щоб оновити SendGrid шаблони відповідно до змін коду, як про це писав тут

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