Управление Harbour в облачном масштабе: история Harbour Kubernetes Operator

Недавно наша команда контейнерных платформ сделала нашу услугу «Частный управляемый реестр» общедоступной. В этом сообщении блога мы объясним, почему OVHcloud выбрал основу для этой службы на проекте Harbour, построил для него оператор Kubernetes и открыл его исходный код в рамках проекта CNCF goharbor.



Необходимость частного реестра S.MART

После выпуска нашей управляемой службы Kubernetes мы получили много запросов на полностью управляемый частный реестр контейнеров.

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

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

Пользователи регулярно хвалили пользовательский интерфейс таких сервисов, как Docker Hub, но в то же время запрашивали сервис с высокой доступностью и поддерживаемый SLA.

Идеальное сочетание набора функций с открытым исходным кодом и корпоративного уровня

Изучив перспективы точной настройки нашего набора функций и модели ценообразования, мы искали лучшие существующие технологии, чтобы поддержать его, и остановились на инкубационном проекте CNCF Harbor (подаренном CNCF компанией VMWare). Помимо того, что Harbour является одним из немногих проектов, достигших инкубационного состояния CNCF, что подтверждает твердую приверженность сообщества, он также стал ключевой частью нескольких коммерческих решений для контейнеризации предприятий. Мы также высоко оценили подход, принятый Харбором: не изобретать колесо заново, а использовать лучшие в своем классе технологии для таких компонентов, как сканирование уязвимостей, доверие к контенту и многие другие. Он использует мощную сеть проектов с открытым исходным кодом CNCF и обеспечивает высокий уровень качества UX.



Пришло время использовать эту технологию 10k-GitHub-stars и адаптировать ее к нашему конкретному случаю: управление десятками тысяч реестров для наших пользователей, каждый из которых имеет определенный объем образов контейнеров и шаблонов использования.

Конечно, высокая доступность (интеграция и развертывание программного обеспечения клиентов зависит от этой услуги), но и надежность данных не обсуждались для нас.

Кроме того, Kubernetes для обеспечения высокой доступности сервисов без сохранения состояния и хранилища объектов (на основе Openstack Swift и совместимость с S3 API ) был очевидным выбором для проверки этих требований.

Решение операционных проблем в масштабе облачного провайдера

В течение нескольких недель мы открыли сервис в публичной бета-версии, быстро привлекая сотни активных пользователей. Но с этим всплеском трафика мы, естественно, столкнулись с первыми узкими местами и проблемами производительности.

Мы обратились к группе пользователей и команде Harbour, которые любезно указали нам на возможные решения, и после некоторых небольших, но важных изменений в том, как Harbor обрабатывает соединения с базой данных, наши проблемы были решены. Это укрепило нашу веру в то, что сообщество Harbour твердо и привержено здоровью проекта и требованиям его пользователей.

Поскольку наш сервис процветал, не было реальных инструментов, позволяющих легко приспособить жизненный цикл экземпляров Harbour. Наша приверженность экосистеме Kubernetes сделала концепцию оператора Harbour для Kubernetes интересным подходом.

Мы обсудили с сопровождающими Harbour, и они тепло приветствовали нашу идею разработать его и открыть исходный код в качестве официального оператора Harbour Kubernetes. OVHcloud очень гордится тем, что проект теперь доступен в проекте goharbor GitHub под лицензией Apache 2. Этот проект — еще один пример нашей твердой приверженности открытому исходному коду и нашей готовности внести свой вклад в проекты, которые нам нравятся.

Универсальный оператор, разработанный для любого развертывания в гавани

Читатели, знакомые с проектом Harbour, могут задаться вопросом, какое значение этот оператор привносит в текущий каталог развертываний, включая версию Helm Chart, поддерживаемую проектом.

Шаблон проектирования оператора быстро становится популярным и имитирует ориентированный на приложения контроллер, который расширяет Kubernetes для управления более сложными приложениями с отслеживанием состояния. Проще говоря, он предназначен для разных сценариев использования, чем Helm. В то время как диаграмма Helm предлагает универсальный установщик, который также будет развертывать различные зависимости Harbor (база данных, кеш и т. Д.) Из образов Docker с открытым исходным кодом, другие предприятия, операторы услуг и облачные провайдеры, такие как мы, захотят выбрать и -выбрать услугу или технологию, лежащую в основе этих компонентов.

Мы также стремимся расширить возможности текущего оператора v0.5 для управления полным жизненным циклом Harbour, от развертывания до удаления, включая масштабирование, обновления, обновления и управление резервным копированием.

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

Мы разработали оператор (используя платформу OperatorSDK), чтобы как дополнительные модули Harbor (хранилище Helm Chart, сканер уязвимостей и т. Д.), Ни зависимости (серверная часть хранилища реестра, относительные и нереляционные базы данных и т. Д.) Могли легко соответствовать вашему конкретному варианту использования.

Упрощенная архитектура службы управляемого частного реестра OVHcloud'd

Вклад в проект Harbor и оператора

У нас уже есть план действий с сопровождающими Harbour для дальнейшего обогащения оператора, чтобы он мог включать не только фазы развертывания и уничтожения (например, сделать обновления версии Harbour более элегантными). Мы надеемся стать неотъемлемой частью проекта и продолжим инвестировать в Harbour.

С этой целью Жереми Монсинжон и Пьер Перонне также были приглашены в качестве сопровождающих в проекте Harbour с упором на goharbor / оператора.

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

Скачать Harbour or the Harbour Operator: официальное репозиторий Harbour Github — www.github.com/goharbor

Узнайте больше о гавани: Официальный сайт гавани — goharbor.io/

Партнерство MyBinder и OVH

В прошлом месяце команда OVH и Binder объединилась, чтобы поддержать рост экосистемы BinderHub по всему миру.



Приблизительно 100 000 еженедельных пользователей общедоступного развертывания mybinder.org и 3 000 уникальных репозиториев git, в которых размещены значки Binder, ощущали потребность в дополнительных ресурсах и вычислительном времени.

Сегодня мы рады объявить, что OVH теперь является частью всемирной федерации BinderHubs, поддерживающих mybinder.org. Весь трафик на mybinder.org теперь распределяется между двумя BinderHub: один находится в ведении группы Binder, а другой — в инфраструктуре OVH.

Итак, для тех, кто еще не знает mybinder.org, вот краткое изложение.

Что такое Юпитер?

Jupyter — потрясающий проект с открытым исходным кодом, который позволяет пользователям создавать, визуализировать и редактировать интерактивные записные книжки. Он поддерживает множество популярных языков программирования, таких как Python, R и Scala, а также некоторые стандарты представления, такие как разметка, фрагменты кода, визуализация диаграмм…



Пример локальной записной книжки Jupyter, читающей записную книжку внутри клиента предвидения репозитория OVH GitHub.

Основной вариант использования — это возможность поделиться своей работой с множеством людей, которые могут пробовать, использовать и редактировать ее прямо из своего веб-браузера.

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

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



Что такое JupyterHub?

JupyterHub — еще более потрясающий проект с открытым исходным кодом, предлагающий многопользовательскую функцию для ноутбуков Jupyter. Благодаря нескольким подключаемым механизмам аутентификации (например, PAM, OAuth), он позволяет создавать записные книжки Jupyter на лету из централизованной инфраструктуры. Затем пользователи могут легко делиться своими записными книжками и правами доступа друг с другом. Это делает JupyterHub идеальным для компаний, учебных аудиторий и исследовательских лабораторий.

Что такое BinderHub?

Наконец, BinderHub — это вишенка на торте: он позволяет пользователям превращать любой репозиторий Git (например, GitHub) в коллекцию интерактивных записных книжек Jupyter одним щелчком мыши.



Binder экземпляр развернутого OVH можно ознакомиться здесь .

  • Просто выберите общедоступный репозиторий git (лучше, если он уже содержит записные книжки Jupyter ).
  • Скопируйте URL-адрес выбранного репозитория в правильное поле привязки.
  • Щелкните кнопку запуска.
  • Если связыватель впервые видит предоставленный вами репозиторий, вы увидите журналы компиляции. Ваш репозиторий анализируется и готовится к запуску связанной записной книжки Jupyter .
  • После завершения компиляции вы будете автоматически перенаправлены на выделенный экземпляр.
  • Затем вы можете начать взаимодействовать и взламывать ноутбук.
  • На начальной странице подшивки вы увидите ссылку, по которой можно поделиться своим репозиторием с другими.

Как это работает?
Инструменты, используемые BinderHub

BinderHub соединяет несколько сервисов вместе, чтобы обеспечить создание и реестр образов Docker на лету. Он использует следующие инструменты:

  • Облачный провайдер, такой как OVH.
  • Kubernetes для управления ресурсами в облаке
  • Helm для настройки и управления Kubernetes.
  • Docker для использования контейнеров, которые стандартизируют вычислительные среды.
  • Пользовательский интерфейс BinderHub, к которому пользователи могут получить доступ, чтобы указать репозитории Git, которые они хотят создать.
  • BinderHub для создания образов Docker с использованием URL-адреса репозитория Git.
  • Реестр Docker, в котором размещаются образы контейнеров.
  • JupyterHub для развертывания временных контейнеров для пользователей.

Что происходит, когда пользователь щелкает ссылку Binder?

После того, как пользователь щелкает ссылку Binder, происходит следующая цепочка событий:

  1. BinderHub разрешает ссылку на репозиторий.
  2. BinderHub определяет, существует ли уже образ Docker для репозитория по последней ссылке (хэш, ветка или тег git commit).
  3. Если изображение не существует, BinderHub создает модуль сборки, который использует repo2docker для:
    • Получите репозиторий, связанный со ссылкой.
    • Создайте образ контейнера Docker, содержащий среду, указанную в файлах конфигурации в репозитории.

    • Отправьте этот образ в реестр Docker и отправьте информацию реестра в BinderHub для дальнейшего использования.
  4. BinderHub отправляет реестр образов Docker в JupyterHub.
  5. JupyterHub создает для пользователя модуль Kubernetes, который обслуживает созданный образ Docker для репозитория.
  6. JupyterHub отслеживает активность модуля пользователя и уничтожает его после короткого периода бездействия.

Схема архитектуры BinderHub



Как мы это развернули?

На платформе OVH Kubernetes


Одна замечательная особенность проекта Binder заключается в том, что он полностью не зависит от облака, вам просто нужен кластер Kubernetes для развертывания.

Kubernetes — один из лучших вариантов, когда речь идет о масштабируемости в стеке архитектуры микросервисов. Управляемое решение Kubernetes работает на инстансах публичного облака OVH. С помощью балансировщиков нагрузки OVH и встроенных дополнительных дисков вы можете размещать все типы рабочих нагрузок с полной обратимостью.

Для этого мы использовали 2 сервиса в OVH Public Cloud:


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

Установка HELM на наш новый кластер

После завершения автоматической установки нашего кластера Kubernetes мы загрузили административный YAML-файл, позволяющий управлять нашим кластером и запускать 
kubectl
на нем команды.
kubectl
это официальный и самый популярный инструмент, используемый для администрирования кластера Kubernetes. Более подробную информацию о том, как его установить, можно найти здесь .
Автоматическое развертывание полного стека Binder уже подготовлено в виде пакета Helm. Helm — это менеджер пакетов для кубернетов, и для работы ему нужны клиентская часть ( 
helm
) и серверная часть ( 
tiller
).
Всю информацию об установке 
helm
и 
tille
можно найти здесь .

Конфигурация нашего развертывания Helm

После 
tiller
установки в нашем кластере все было готово для автоматизации развертывания связующего в нашей инфраструктуре OVH.
Конфигурация 
helm
развертывания довольно проста, и все шаги были описаны командой Binder здесь .

Интеграция в процесс CD / CI binderhub

У них binder team уже был рабочий процесс travis для автоматизации процессов тестирования и развертывания. Все прозрачно, и они раскрывают все свои конфигурации (кроме секретов) в своем проекте GitHub. Нам просто нужно было интегрироваться с их текущим рабочим процессом и разместить нашу конкретную конфигурацию в их репозитории.

Затем мы подождали их следующего запуска рабочего процесса Travis, и он сработал.

С этого момента стек ovh для binder был запущен и доступен всем отовсюду по этому адресу: ovh.mybinder.org/

Что будет дальше?

OVH продолжит взаимодействовать с сообществом разработчиков данных с открытым исходным кодом и будет поддерживать прочные отношения с фондом Jupyter и, в более общем плане, сообществом Python.

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

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

Специальная благодарность

Мы благодарны командам Binder, Jupyter и QuantStack за их помощь, команде OVH K8s для OVH Managed Kubernetes и OVH Managed Private Registry, а также команде OVH MLS за поддержку. Вы молодцы!

Понимание CI / CD для больших данных и машинного обучения

На этой неделе команда OVH Integration and Continuous Deployment была приглашена на подкаст DataBuzzWord .



Вместе мы исследовали тему непрерывного развертывания в контексте машинного обучения и больших данных. Мы также обсудили непрерывное развертывание для таких сред , как Kubernetes , Docker, OpenStack и VMware VSphere .

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

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

Найдите CDS на GitHub:


…. и подписывайтесь на нас в Twitter:


Обсудите эти темы с нами на нашем канале Gitter: https://gitter.im/ovh-cds/