JavaScript прочно закрепился на рынке корпоративных разработок. Одной из причин такого значительного роста является взрывное расширение языка, который из браузера превратился в основу серверных сред выполнения с Node.js. Одним из ключевых факторов внедрения языка программирования является легкий доступ к обширным библиотекам, разработанным сообществом программистов. Node.js хорошо известен своей системой управления зависимостями под названием NPM, которая позволяет разработчикам делиться своими активами кода с более широким сообществом. Благодаря упрощенному интерфейсу командной строки npm позволяет вам быстро устанавливать ваши любимые пакеты для включения основных библиотек, таких как экспресс для создания наших приложений RESTful и паспорт для создания защищенных приложений, поддерживаемых OAUTH.
Авторы
Тодд Каплингер — старший технический сотрудник и главный изобретатель IBM в IBM Cloud Group. Он является архитектором мобильной облачной платформы, специализирующимся на предоставлении мобильных облачных услуг, и последние 4 года является одним из ведущих идейных лидеров и архитекторов IBM в области мобильных технологий. Тодд является экспертом в области разработки мобильных приложений для Android и iOS, а также имеет большой опыт работы с веб-технологиями, такими как Node и Java. За последние 14 лет Тодд был ведущим архитектором многих инкубационных проектов IBM и участвовал в различных группах стандартов Java.
Алекс Вайднер — штатный инженер-программист, который работает в IBM Cloud с 2014 года. такие службы, как Presence Insights. Алекс связывает сообщества, методы и программное обеспечение с открытым исходным кодом с внутренними проблемами и требованиями, постоянно продвигая внутренние методы внедрения современных методов и автоматизируя задачи разработки и разработки.
Почему
Несмотря на эту замечательную модель совместного использования ресурсов общедоступного кода с более широким сообществом, всегда будут случаи, когда ваше приложение использует библиотеки, специфичные для вашего решения и не предназначенные для широкого использования. Примеры включают проприетарную интеллектуальную собственность, которую предприятия не хотят раскрывать за пределами своей компании, управляемые обновления, позволяющие контролировать изменения системы, ускорение конвейера разработки и доставки, а также общие версии, которые можно совместно использовать и разрабатывать внутри компании. В этих случаях существует несколько способов интеграции этих библиотек с вашим приложением, начиная от чего-то такого базового, как git checkout, и заканчивая частным NPM, который мы опишем в этой статье.
Для нас причина, по которой наша команда выбрала частный NPM, заключается в том, что это значительно упростило процесс развертывания. При развертывании наших производственных приложений в Bluemix ранее нам приходилось упаковывать все наши зависимости как часть процесса сборки, упаковывать их в один артефакт развертывания и развертывать все решение в Bluemix. Это значительно увеличило время сборки, поскольку нам нужно было загрузить все наши зависимости (общедоступные и частные) на нашу машину сборки, а затем упаковать все эти зависимости в один сжатый файл для развертывания. Это привело к тому, что приложения узлов значительно увеличились, что часто приводило к тайм-ауту во время отправки этих приложений в Bluemix. Поскольку у нас было около 30 приложений, которыми мы управляли в 3 регионах Bluemix, это сильно повлияло на время выполнения развертывания. Мы также не смогли использовать одну из ключевых функций пакетов сборки Bluemix и Cloud Foundry, когда push-уведомление Cloud Foundry автоматически «установит npm» все пакеты, определенные в вашем package.json. Мы знали, что должен быть лучший способ.
Почти сразу же было замечено много преимуществ при переходе на частный NPM. Во-первых, мы значительно сократили время развертывания, поскольку в процессе развертывания использовались только те ресурсы, которые были специфичны для проекта, а не их зависимости. Это действительно помогло нам продвигать лучшие отраслевые практики, которые мы разработали для микросервисов, и предоставлять небольшие наборы многократно используемых библиотек (модулей) для всех наших микросервисов, таких как ведение журналов, проверки работоспособности, безопасность, Cloudant и Elasticsearch. Частный NPM также изначально поддерживал управление версиями модулей, что позволяло нам одновременно разрабатывать, управлять и развертывать множество различных версий наших модулей и обеспечивало четкие пути миграции модулей за счет использования семантического управления версиями наших ресурсов. Наконец, что не менее важно, мы смогли использовать встроенную систему безопасности, предоставляемую NPM, для ограничения доступа к подмножеству наших разработчиков и создания систем с соответствующим токеном безопасности. Это позволило очень легко определить, кто может читать и писать в наш репозиторий, что важно для поддержания авторитетных зависимостей, а также для контроля управления во время развертывания.
Что такое Синопия?
Теперь, когда мы определили, что хотим использовать частный репозиторий NPM, следующий вопрос, который возник, на самом деле состоял из двух вопросов. Первый из них касался того, что мы используем, и есть ли уже готовый для использования в IBM с публичным доступом к нашим приложениям Bluemix. Ответом быстро стал Sinopia, так как внутри IBM не существовало решения, удовлетворяющего нашим требованиям к Bluemix.
Sinopia была выбрана изначально, поскольку это проект с открытым исходным кодом и довольно активным сообществом пользователей (29 коммиттеров, 65 релизов и 6 тысяч загрузок в месяц). Кроме того, IBM уже одобрила использование Sinopia, и этот выбор был подтвержден одним из наших недавних приобретений (StrongLoop), который использует Sinopia в своем конвейере devOps и во многих других внутренних целях.
Что нам больше всего понравилось в Sinopia, так это то, что она решила нашу насущную проблему, поскольку она предназначена для размещения частных модулей NPM, она интегрирована с нашим конвейером сборки, и мы смогли относительно безболезненно добавить ее в наш процесс развертывания. С небольшим изменением в нашем файле npmrc, чтобы указать на наш частный репозиторий NPM, процесс развертывания в Bluemix установил наши модули частных узлов как часть проталкивания в Bluemix.
Но подождите .. становится лучше. Поскольку Sinopia написана на Node.js, мы смогли легко разместить ее как приложение Bluemix, а также запустить ее локально для целей разработки без необходимости устанавливать множество зависимостей. С их упрощенной моделью безопасности (и различными модулями сообщества для работы с подключаемыми моделями безопасности, такими как ldap) мы смогли быстро определить роли и ACL. Это действительно помогло команде запустить это за очень короткое время.
Конечным результатом является то, что у нас есть хорошо масштабируемая тень общедоступного NPM, которая кэширует все наши общедоступные модули NPM в дополнение к модулям наших частных узлов, которые мы использовали для наших приложений.
Развертывание Sinopia в Bluemix
Учитывая упаковку Sinopia, проще всего создать небольшой проект Node, который включает Sinopia как зависимость в свой package.json и запустить его при запуске:
{
"name": sinopia-server,
"version": "1.0.0",
"description": sinopia-server wrapper",
"scripts": {
"start": "node node_modules/.bin/sinopia -l ${VCAP_APP_HOST:=localhost}:${VCAP_APP_PORT:=4873} -c ./config.yaml",
"test": "echo "Error: no test specified" && exit 1"
},
"author": "",
"license": "ISC",
"dependencies": {
"sinopia": ">= 1.x
}
}
Важной частью здесь является подстановка переменных в стиле bash, которая либо использует правильные переменные среды во время работы в Bluemix, либо использует набор резервных конфигураций для локальных экземпляров.
Перед развертыванием в Bluemix вам нужно обновить config.yaml, чтобы он имел для вас смысл. Простая настройка будет включать пользователя-разработчика и пользователя-администратора, один с возможностью получения всех модулей, а другой с возможностью публикации всех модулей.
# Look here for more config file examples:
# https://github.com/rlidwka/sinopia/tree/master/conf
#
# path to a directory with all packages
storage: ./storage
users:
dev:
password: <encrypted password>
admin:
password: <encrypted password>
auth:
htpasswd:
file: ./htpasswd
# Maximum amount of users allowed to register, defaults to "+inf".
# You can set this to -1 to disable registration.
max_users: -1
# a list of other known repositories we can talk to
uplinks:
npmjs:
url: https://registry.npmjs.org/
packages:
'@*/*':
# scoped packages
access:
- dev
- admin
publish: admin
storage: './private'
'*':
# allow all users (including non-authenticated users) to read and
# publish all packages
#
# you can specify usernames/groupnames (depending on your auth plugin)
# and three keywords: "$all", "$anonymous", "$authenticated"
access:
- dev
- admin
# allow all known users to publish packages
# (anyone can register by default, remember?)
publish: admin
# if package is not available locally, proxy requests to 'npmjs' registry
proxy: npmjs
storage: './public'
# log settings
logs:
- {type: stdout, format: pretty, level: http}
# Webhook settings
webhook:
url: <webhook>
Кроме того, вы можете добавить веб-хук, чтобы сообщать об изменениях в вашем реестре через такие платформы, как Slack.
Вы должны быть готовы к
cf push
из вашего проекта Sinopia-server!
бессовестная вилка
Sinopia использует файловую систему для хранения и управления пакетами в своем реестре. Поскольку Bluemix не обеспечивает сохранение данных на диске для приложений, нам было важно найти другое средство сохранения. Решение состояло в том, чтобы разветвить проект и реализовать серверную часть CouchDB, которая заменила бы хранилище, поддерживаемое файловой системой. Мы выбрали CouchDB, потому что тогда мы могли бы использовать Cloudant при развертывании в Bluemix.
После того, как работа над нашим форком была завершена, у нас остался внешний интерфейс без сохранения состояния, который можно было масштабировать независимо от того, какая база данных Couch/Cloudant поддерживала его. Связывание экземпляра службы Cloudant с нашим проектом сервера Bluemix Sinopia обеспечило нам постоянство, необходимое для противостояния сбоям, и позволило нам масштабировать внешний интерфейс независимо от пакетов, хранящихся в реестре.
В настоящее время мы находимся в процессе экстернализации нашего форка и возвращения функциональности в проект Sinopia. К сожалению, сопровождающий не активен, но сообщество предпринимает усилия по обновлению другого проекта Sinopia из-за его популярности и высокого спроса. Вы можете найти нашу вилку и посмотреть, как над ней ведется работа, здесь.
Первоначально опубликовано на сайте developer.ibm.com.
