Журнал об IT-бизнесе, технологиях и цифровой трансформации

Отказоустойчивый приватный npm-репозиторий для JavaScript-приложений с SSO почти из коробки Mail.ru Cloud Solutions
Mail.ru Cloud Solutions
  • 27 января
  • Разработка

Отказоустойчивый приватный npm-репозиторий для JavaScript-приложений с SSO почти из коробки

Автор: Сергей Буйлов
Популярное
Ликбез
Что такое озера данных и почему в них дешевле хранить big data
Тренды
Эволюция квантовых вычислений: от гипотез до реальных компьютеров
Разработка
Три уровня автомасштабирования в Kubernetes: как их эффективно использовать

Расскажем, как поднять для команды разработки отказоустойчивый приватный npm-репозиторий с SSO (single sign-on). Смотрим, какие для этого существуют решения, и разворачиваем одно из них в облаке Mail.ru Cloud Solutions (MCS).

Постановка задачи

Нужно поднять private npm registry, отвечающий следующим требованиям:

  • Интеграция с SSO (Active Directory или LDAP).
  • Хранение данных на отказоустойчивом хранилище.
  • Минимальное обслуживание.
  • Разумная стоимость.

Выбор решения

Есть ряд подходящих решений, как SaaS, так и self-hosted, в том числе open source. Проанализируем некоторые из них.

SaaS (например, packagecloud.io). Позволяет быстро и удобно развернуть приватные репозитории для самых разных технологий (в том числе nodejs). Высокая цена (от 70 USD за очень скромный объем диска) делает этот класс решений непригодным для многих компаний.

Nexus. Есть как open source-, так и enterprise-версия. Поддерживает репозитории для многих языков/операционных систем. К сожалению, решение использует разные хранилища для метаданных и данных. Это, вероятно, увеличивает производительность, но усложняет построение высокодоступной (HA) системы, а также версионирования/бэкапов. Решение подходит для достаточно больших команд разработки при наличии ресурсов на поддержку данного ПО.

Verdaccio. Молодой open source проект, функционал которого легко расширяется плагинами. Доступна интеграция с S3-совместимыми хранилищами, а также авторизация с использованием LDAP, Active Directory. К сожалению, качество документации и самого кода некоторых сторонних плагинов оставляет желать лучшего и необходимо осмотрительно подходить к их выбору.

Примерами расширений, не рекомендуемых к использованию, являются:

  • verdaccio-oidc — не работает;
  • verdaccio-gitlab-ci — скудная документация, а также невозможно ограничить доступ для конкретного токена, что делает нежелательным интеграцию c gitlab.com.

Исходные требования (prerequisites)

Вам понадобится:

  • Kubernetes-кластер c установленным tiller (серверная часть helm 2).
  • Бакет в S3-совместимом хранилище. Мы будем использовать бакет от MCS, подробную инструкцию по настройке можно найти тут. Нам понадобится имя бакета, endpoint (обычно hb.bizmrg.com), access_key_id и secret key.
  • LDAP либо Active Directory в качестве authentication backend.

В статье будет приведен пример конфигурации verdaccio для openldap. Установка и проверка работоспособности Verdaccio проведена на k8s-кластере и объектном хранилище от MCS. Также мы исходим из предположения, что читатели знакомы со сборкой докер-контейнеров утилитами helm и kubectl.

В этой статье, в целях сокращения объема, не будем заострять внимание на управлении секретами, сборке charts для helm, а также некоторых других деталях, которые можно опустить безболезненно для демонстрации решения.

Собираем docker image

Создадим Dockerfile вида:

FROM verdaccio/verdaccio

USER root

ENV NODE_ENV=production

RUN npm i && npm i verdaccio-s3-storage verdaccio-ldap

USER verdaccio

В этом image на текущий момент нет ничего секретного. Выложим его в любой docker registry. В статье мы будем использовать имя образа mcsuser/verdaccio.

Редактируем helm chart

Получаем community chart:

helm fetch --untar stable/verdaccio
cd verdaccio

Приводим values.yaml к следующему виду:

image:
  repository: mcsuser/verdaccio
  tag: 0.0.1
  pullPolicy: IfNotPresent
service:
  annotations: {}
  clusterIP: ""
  externalIPs: []
  loadBalancerIP: ""
  loadBalancerSourceRanges: []
  port: 4873
  type: ClusterIP
nodeSelector: {}
tolerations: []
podAnnotations: {}
replicaCount: 1
resources: {}
# set reasonable limits for your installation here:
ingress:
  enabled: true
  hosts:
    - npm.example.com
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /

configMap: |
  storage: /verdaccio/storage/data
  store:
    s3-storage:
      bucket: verdaccio-mcs-test
      endpoint: hb.bizmrg.com
      keyPrefix: npm # optional, has the effect of nesting all files in a subdirectory
      accessKeyId: MCS_ACCESS_KEY_ID
      secretAccessKey: MCS_SECRET_KEY
  web:
    title: Verdaccio
  auth:
    ldap:
      type: ldap
      client_options:
        url: "ldap(s)://ldap.exapmple.com"
      searchBase: "ou=People,dc=example,dc=com"
      searchFilter: "(uid={{username}})"

  uplinks:
    npmjs:
      url: https://registry.npmjs.org/

  packages:
    '@*/*':
      # scoped packages
      access: $authenticated
      publish: $authenticated
      unpublish: admin.user
      proxy: npmjs
    '**':
      access: $authenticated
      publish: $authenticated
      unpublish: admin.user
      proxy: npmjs
  middlewares:
    audit:
      enabled: true

  # log settings
  logs:
    - {type: stdout, format: pretty, level: http}

persistence:
  enabled: false

securityContext:
  enabled: true
  runAsUser: 100
  fsGroup: 101

Находясь в директории с chart, устанавливаем командой:

helm install .

В демонстрационном values.yaml выключено SSL-шифрование на уровне ingress, а секреты для доступа в s3-совместимое хранилище указаны непосредственно в values.yaml. Для реального использования SSL-шифрование следует задействовать, а секреты не должны храниться в доступном хранилище открытым текстом, вместо них values.yaml должен содержать плейсхолдеры.

Таким образом, в нашем values.yaml мы задали следующие настройки:

  • Указали образ с необходимыми плагинами.
  • Указали использовать в качестве storage s3-совместимое хранилище и предоставили необходимые доступы.
  • Поскольку наш registry приватный, сделали просмотр и публикацию пакетов доступным только для авторизованных пользователей.
  • Возможность удаления оставили только для пользователя с особыми правами.
  • Также включен LDAP backend, отключена возможность самостоятельной регистрации и auth-basic бэкенд.

Аналогичные настройки можно произвести для Active Directory, ссылки на все упомянутые плагины будут ниже.

Проверяем работоспособность

  • Авторизуемся в нашем новом registry: npm login. Указываем при этом registry=npm.example.com в .npmrc.
  • Создаем package.json и index.js.
  • Публикуем: npm publish.
  • Проверяем, что пакет появился в registry и объектном хранилище.
  • Удаляем под, убеждаемся, что при пересоздании пода никакие данные не пропали.
  • Удаляем chart, вновь деплоим его же. Убеждаемся в том же.
  • Если необходимо — включаем версионирование в объектном хранилище.

Список полезных ссылок по теме

Ссылка скопирована!

Что еще почитать про ИТ-бизнес