Пять случаев использования частного прокси npm для вашего рабочего процесса

В этой статье рассказывается о том, почему установка частного прокси-сервера npm - хорошая идея. Здесь рассматриваются наиболее распространенные вопросы, которые мне задавали с тех пор, как я участвовал в форке verdaccio sinopia, и как разработчик решает многие вопросы, связанные с использованием случаи, которые заставили меня оценить, насколько полезно можно настроить локальный частный прокси

Давайте их рассмотрим.

Как автономная установка

Сегодня решение для автономного режима называется пряжа, а в последнее время - [email protected]. Это веский аргумент, оба клиента классные. Автономный режим работает нормально, но не решает всех проблем, связанных с автономным режимом.

Команды разработчиков: Yarn кэширует все ваши пакеты локально, чтобы вы не могли случайно поделиться ими в своей компании. Кроме того, нет ничего необычного в том, что кто-то в вашей команде перестает работать, потому что он / она не может загрузить какую-либо новую зависимость из-за отсутствия подключения к Интернету.
Путешествие: я путешественник 🛫 и мне приходится сталкиваться с этим довольно часто: в роуминге или 3G загрузка любого тарбола может занять целую вечность. Вы кодировали, путешествуя в самолете?
ИТ-конференции. Поднимите руку, если у вас возникли проблемы с подключением на ИТ-конференциях в качестве докладчика 😓 или участника 😩. Вы можете возразить, что yarn / npm может решить эту проблему. Я согласен с вами, но есть десятки вариантов использования, которые не охватываются их автономным режимом. Например, новую версию зависимостей, которую вы пока не можете опубликовать публично, или чистые демонстрации публикации, dist-tags и любые другие команды из yarn или npm. Я понимаю, что иметь местный реестр очень удобно.

Verdaccio может устанавливать и публиковать в автономном режиме.

Кажется, что в современных странах оффлайн в большинстве случаев не является проблемой. Но, читая темы в вердаччо, удивительно, как часто люди имеют ограничения в Интернете в его собственных компаниях, и их более простое решение - резервное копирование всего хранилища и восстановление его на работе.

Как хаб для извлечения из многих реестров

В наши дни работа с несколькими реестрами является довольно распространенным явлением, и постоянное переключение - действительно медленный и утомительный процесс.

npm install --registry http://localhost:4873

Что ж, недавно я нашла этот инструмент, чтобы сделать этот процесс безболезненным, но все же…

Кроме того, вполне обычным явлением является то, что многие разработчики используют платные реестры, такие как JFrog Artifactory или Nexus3 (Nexus имеет бесплатный npm OSS), и иногда онлайн-доступ для таких реестров ограничен.

Как вердаччо решает эту проблему?

Легко и просто, использует аплинки. Вы можете проксировать несколько реестров, используя вместо этого один, это круто, правда?

uplinks:
  npmjs:
   url: https://registry.npmjs.org/
  server2:
    url: http://mirror.local.net/
  server3:
    url: http://mirror2.local.net:9000/
  yarn:
    url: https://registry.yarnpkg.com/

Ссылки вверх позволяют вам установить несколько реестров, и вы можете позже определить, какие зависимости должны быть разрешены любым из ваших множественных реестров. Даже если для любого из них требуется какой-либо конкретный заголовок, вы можете добавить / переопределить их.

В качестве промежуточного сервера реестра

Все вы привыкли иметь дело с промежуточным сервером. Это последний шаг перед запуском в производство, на котором мы тестируем наши проекты, которые, в конце концов, могут также зависеть от частных модулей npm.

Разве с вами не случалось, что вы обнаружили ошибку в своем любимом проекте, и, несмотря на то, что ее легко исправить, потребовались годы, пока они не выпустили патч 😩😩? Да, Я из таких, но всегда стараюсь ответить как можно скорее 🙃.

Допустим, вы используете lodash, и оказалось, что это важная библиотека в вашем проекте, и вам нужно это исправить прямо сейчас. Здесь у вас есть несколько вариантов:

Зафиксировать node_modules/lodash? Это мерзко.
Исправить локально, упаковать tarball в свой пакет и сослаться на него из package.json? Ну .. Я проделал это один или два раза. Но честно говоря… как же тогда вы планируете получить будущий официальный патч? В любом случае вам нужно будет снова переключить зависимость на версию semver.

"dependencies": {
    "lodash": "./packages/lodash.patch.tar.gz"
}

Ссылка на Git - это обычная работа, но, честно говоря, мне это не нравится.

"dependencies" : {
  "name1" : "git://github.com/user/project.git#commit-ish",
  "name2" : "git://github.com/user/project.git#commit-ish"
}

Либо, если вам нужно иметь дело с ошибками или у вас есть реестр, работающий в вашей организации, промежуточный сервер очень удобен при размещении всех ваших частных модулей. У вас может быть несколько серверов или контейнеров Docker, что потребует централизации всех ваших модулей в одном месте.

Мне нужно легкое решение

Настройка всегда является критическим шагом, когда разработчик решает, использовать программное обеспечение или нет. Чтение длинного руководства Приступая к работе отговорит любого разработчика и в большинстве случаев полностью бесит вас, когда любой шаг терпит неудачу 😤.

Установка verdaccio выполняется довольно быстро и не требует какой-либо настройки, кроме установленного node.js.

npm install -g verdaccio

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

И это все. Ничего страшного, да? Действительно это. Вы можете начать играть с этим.

Составьте с Docker

Если у вас есть стек, основанный на Docker, вы можете объединить локальный реестр в рабочий процесс.

Как вы, возможно, знаете, файлы блокировки сохраняют ссылки на реестр (№2 и №3) для каждой зависимости, но похоже, что npm этого не делает. Это будет проблемой, если вы полагаетесь на файлы блокировки, а ваши контейнеры не могут разрешить реестр.

Verdaccio готов для Docker, и даже есть репозиторий примеров, который вы можете использовать для настройки своего композита. Наиболее распространенная конфигурация - прокси через nginx выглядит следующим образом:

version: '2'

services:
  verdaccio:
    image: verdaccio/verdaccio:latest
    container_name: verdaccio
    ports:
      - "4873:4873"
    volumes:
      - verdaccio:/verdaccio

  nginx:
    restart: always
    build: ./conf/nginx/
    ports:
      - "80:80"
    volumes:
      - /www/public
    volumes_from:
      - verdaccio
    links:
      - verdaccio:verdaccio

volumes:
  verdaccio:
    driver: local

и конфигурация nginx

server {
  listen 80 default_server;
	access_log /var/log/nginx/verdaccio.log;
	charset utf-8;
  location / {
    proxy_pass              http://verdaccio:4873/;
    proxy_set_header        Host $host;
  }
}

Скомпоновать ваши Docker-контейнеры с Verdaccio довольно просто, да и конфигурация минимальна. Если вам нужно более сложное решение, вы можете расширить конфигурацию по умолчанию и установить внешний том, как я описал в других примерах.

Сворачивать

Verdaccio - не единственное доступное решение, другие также имеют некоторую поддержку OSS. Но не все полностью бесплатно. Verdaccio унаследовал от Sinopia экосистему плагинов для аутентификации, которая полностью бесплатна и совместима с LDAP, Active Directory или Atlassian Crowd.

Local-npm кажется неплохим решением, если вам нужен только офлайн-прокси. Codebox-npm, если вы полагаетесь только на Github auth и AWS в качестве платформы, и Nexus3, когда вам нужно правильно масштабировать.

Возможно, вы имеете в виду больше вариантов использования. Я попытался выбрать наиболее распространенные, основываясь на моем опыте сопровождающего и на том, что спрашивали люди. Пожалуйста, поделитесь своими мыслями.

Частный реестр прокси Verdaccio npm
Verdaccio - это легкий частный реестр прокси npm, основанный на node.js www.verdaccio.org