Спонсорство JupyterCon 2020: обмен ценностями и поддержка инфраструктуры

Повторяя вчерашнее объявление в блоге Jupyter, OVHcloud гордится тем, что поддерживает JupyterCon в качестве платинового спонсора и донора инфраструктуры.



Как вы, наверное, знаете, Jupyter стал огромным фактором развития сообщества программистов, поддерживая более 140 ядер, таких как Python, R, Julia, Spark, Sas, Haskell, Ruby, C ++, Go и т. Д.

Проект Jupyter воплощает в себе открытые и совместные сообщества разработчиков, которые являются ключевыми ценностями в структуре нашей собственной экосистемы.

В последние годы Jupyter и OVHcloud работали рука об руку над такими проектами, как Mybinder.org и NbViewer. Я хотел бы поблагодарить совет директоров Jupyter и NumFocus за их открытость и доверие, которые сделали возможным такое успешное партнерство.

В 2020 году мы пошли дальше, предложив поддержку JupiterCon в течение всего года и помогая внести свой вклад в успех мероприятия.

С переходом на полностью цифровой опыт ограничения на поездки COVID-19 представляют собой возможность не только сократить расходы на поездки и упростить доступ, но и ограничить углеродный след, связанный с обменом знаниями в экосистеме.

Празднование присоединения Harbour к ограниченному списку проектов CNCF Graduated



Пару месяцев назад, через год после того, как наша служба Managed Kubernetes стала общедоступной, мы запустили службу Managed Private Registry. В предыдущем сообщении в блоге мы рассказали, почему решили основать его на проекте CNCF Harbour. Два сотрудника OVHcloud стали сопровождающими проекта. Теперь у нас есть новое событие, которое нужно отпраздновать: Фонд облачных вычислений только что объявил, что Харбор присоединился к очень ограниченному списку «завершенных» проектов.

Выпуск CNCF: высший уровень зрелости

CNCF размещает несколько десятков проектов с открытым исходным кодом и отлично справляется со своей работой, предлагая этим проектам поддержку роста как с точки зрения инфраструктуры и инструментов, так и с точки зрения сообщества и осведомленности. Однако большинство этих проектов находятся в «песочнице CNCF» или на стадии «инкубации». В настоящее время «завершили» только 11 проектов, включая Kubernetes, Prometheus и Helm. Харбор стал последним, кто получил этот большой знак признания.



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

OVHcloud с гордостью демократизирует гавань

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

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



Больше для наших нынешних и будущих пользователей управляемого реестра!

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

  • план «M», идеальный для средних компаний-разработчиков программного обеспечения или бизнес-единиц в крупных организациях; теперь включает сканирование уязвимостей
  • план «L» теперь может содержать до 5 ТБ ваших артефактов (слои контейнера, диаграммы Helm и т. д.)

Цены и другие характеристики не изменились, что делает эту услугу одной из самых интересных услуг реестра корпоративного уровня на рынке. Все существующие и будущие клиенты автоматически получают выгоду от этих улучшений. Публичная страница цен скоро будет обновлена. Конечно, как и в большинстве продуктов OVHcloud, входящий и исходящий трафик остается неограниченным и бесплатным.

В настоящее время демонстрируя очень стабильную версию Harbour 1.10, наша контейнерная команда уже планирует перейти на Harbour 2.0.

До встречи на саммите Kubecon Europe и OVHcloud в конце этого года!

Переход к хранилищу Ceph нового поколения в OVHcloud с LXD

Вступление

Меня зовут Филип Дорош. Я работаю в OVHcloud с 2017 года инженером DevOps. Сегодня я хочу рассказать вам историю о том, как мы развернули Ceph следующего поколения в OVHcloud. Но сначала несколько слов о Ceph: Ceph — это программно определяемое решение для хранения данных, которое поддерживает дополнительные тома публичного облака OVHcloud, а также наш продукт Cloud Disk Array. Но я не буду утомлять вас маркетинговыми вещами — давайте начнем!



Похоже, это интересная задача ...

Полтора года назад мы начали очень знакомый спринт. Помимо обычных вещей, с которыми нам приходится иметь дело, была одна задача, которая выглядела немного интереснее. Заголовок гласил: « Оцените, можем ли мы запускать новые версии Ceph на нашем текущем программном обеспечении ». Нам нужны были более новые версии Ceph и Bluestore для создания решения Ceph следующего поколения со всеми флеш-хранилищами.

Наше программное решение (которое мы называем устаревшим решением) основано на Docker. Звучит действительно круто, но мы запускаем Docker немного иначе, чем по назначению. Наши контейнеры очень сохраняют состояние. Мы запускаем полноценную систему инициализации внутри контейнера в качестве точки входа в докер. Затем эта система инициализации запускает все необходимое программное обеспечение внутри контейнера, включая Puppet, который мы используем для управления «вещами». Похоже, мы используем контейнеры Docker так же, как контейнеры LXC, не так ли?…

Наша унаследованная инфраструктура Ceph (аллегория)

Вскоре выяснилось, что невозможно запускать более новые выпуски Ceph в нашем внутреннем решении, потому что новые версии Ceph используют systemd, а в нашем текущем решении мы вообще не запускаем systemd — ни внутри контейнеров, ни на хозяева, которые их принимают.

Началась охота за решениями. Одна из возможностей заключалась в том, чтобы упаковать Ceph самостоятельно и избавиться от systemd, но это большой объем работы с небольшой добавленной стоимостью. Сообщество Ceph предоставляет проверенные пакеты, которые необходимо использовать, так что этот вариант не рассматривался.

Второй вариант — запустить Ceph с супервизором внутри контейнера Docker. Хотя это звучит как план, даже в документации supervisord четко указано, что supervisord «не предназначен для запуска вместо init как« process id 1 ».». Так что это тоже явно не вариант.

Нам нужен был systemd!

На этом этапе стало ясно, что нам нужно решение, позволяющее запускать systemd как внутри контейнера, так и на хосте. Похоже, настало идеальное время для перехода на совершенно новое решение — решение, которое было разработано для запуска полной ОС внутри контейнера. Поскольку наш Docker использовал бэкэнд LXC, это было естественным выбором для оценки LXC. В нем были все необходимые функции, но с LXC нам пришлось бы самостоятельно кодировать всю автоматизацию, связанную с контейнерами. Но можно ли избежать всей этой дополнительной работы? Оказывается, может…

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

Поэтому я переустановил свои серверы разработчиков с выпуском Ubuntu Server LTS и установил на них LXD.



LXD имеет все необходимое для создания полнофункциональных кластеров Ceph:

  • он поддерживает «толстые» контейнеры с отслеживанием состояния,
  • он поддерживает systemd внутри контейнера,
  • он поддерживает образы контейнеров, поэтому мы можем подготовить индивидуальные изображения и без проблем использовать их,
  • передача целых блочных устройств в контейнеры,
  • передача обычных каталогов в контейнеры,
  • поддержка простого запуска, остановки, перезапуска контейнера,
  • REST API, который будет рассмотрен в следующих частях статьи,
  • поддержка нескольких сетевых интерфейсов в контейнерах с использованием macvlan.

После нескольких часов ручной работы у меня был кластер Ceph, на котором запущен выпуск Mimic внутри контейнеров LXD. Я набрал ceph health и получил «HEALTH_OK». Приятно! Это сработало отлично.

Как нам это индустриализировать?

Чтобы индустриализировать его и подключить к нашей плоскости управления, нам нужен был модуль Puppet для LXD, чтобы Puppet мог управлять всеми элементами, связанными с контейнером, на хосте. Такого модуля, который предоставлял бы необходимую нам функциональность, не существовало, поэтому нам пришлось его кодировать самостоятельно.

Демон LXD предоставляет удобный REST API, который мы использовали для создания нашего модуля Puppet. Вы можете общаться с API локально через сокет unix и через сеть, если вы настроили его раскрытие. Для использования в модуле было действительно удобно использовать команду запроса lxc, которая работает, отправляя необработанные запросы в LXD через сокет unix. Модуль теперь имеет открытый исходный код на GitHub, поэтому вы можете скачать его и поиграть с ним. Он позволяет настраивать основные параметры LXD, а также создавать контейнеры, профили, пулы хранения и т. Д.

Модуль позволяет создавать, а также управлять состоянием ресурсов. Просто измените свои манифесты, запустите марионеточный агент, и он сделает все остальное.



Модуль LXD Puppet на момент написания этого документа предоставляет следующие определения:

  • lxd :: profile
  • lxd :: изображение
  • lxd :: хранилище
  • lxd :: container

Для получения полной справки посетите его страницу GitHub — github.com/ovh/lxd-puppet-module.

Ручная установка VS Автоматическая установка с Puppet

Я покажу вам простой пример того, как создать точно такую ​​же настройку вручную, а затем снова автоматически с помощью Puppet. Для целей этой статьи я создал новый экземпляр Public Cloud с Ubuntu 18.04, один дополнительный диск и уже настроенное мостовое устройство br0. Предположим, есть также DHCP-сервер, прослушивающий интерфейс br0.

Стоит отметить, что обычно вам не нужно создавать собственное изображение, вы можете просто использовать вышестоящие со встроенными командами. Но для целей этой статьи давайте создадим собственный образ, который будет в точности похож на исходный. Чтобы создать такой образ, вам просто нужно ввести несколько команд, чтобы перепаковать исходный образ в Unified Tarball.

root @ ubuntu: ~ # wget https://cloud-images.ubuntu.com/bionic/current/bionic-server-cloudimg-amd64-root.tar.xz 
root @ ubuntu: ~ # wget https: // cloud-images .ubuntu.com / bionic / current / bionic-server-cloudimg-amd64-lxd.tar.xz 
root @ ubuntu: ~ # mkdir -p ubuntu1804 / rootfs 
root @ ubuntu: ~ # tar -xf bionic-server-cloudimg-amd64 -lxd.tar.xz -C ubuntu1804 / 
root @ ubuntu: ~ # tar -xf bionic-server-cloudimg-amd64-root.tar.xz -C ubuntu1804 / rootfs / 
root @ ubuntu: ~ # cd ubuntu1804 / 
root @ ubuntu : ~ / ubuntu1804 # tar -czf ../ubuntu1804.tar.gz *


В конце вы получите образ ubuntu1804.tar.gz, который можно использовать с LXD. Для целей этой статьи я поместил это изображение в каталог, доступный через HTTP, например: example.net/lxd-image/

Ручная настройка

Первым делом давайте установим LXD.

root @ ubuntu: ~ # apt install lxd

Во время установки пакета вы увидите сообщение: «Чтобы пройти начальную конфигурацию LXD, запустите: lxd init», но мы просто сделаем все шаги вручную.

Следующим шагом будет добавление нового пула хранения.

root @ ubuntu: ~ # lxc storage create default dir source = / var / lib / lxd / storage-pools / 
default Создание пула хранения по умолчанию


Затем создайте собственный профиль, который будет иметь: переменную окружения http_proxy, установленную на ”, ограничение памяти 2 ГБ, крыши в пуле хранения по умолчанию и eth0, который будет частью моста br0.

root@ubuntu:~# lxc profile create customprofile
Profile customprofile created
root@ubuntu:~# lxc profile device add customprofile root disk path=/ pool=default
Device root added to customprofile
root@ubuntu:~# lxc profile device add customprofile eth0 nic nictype=bridged parent=br0
Device eth0 added to customprofile
root@ubuntu:~# lxc profile set customprofile limits.memory 2GB


Распечатываем весь профиль, чтобы проверить, все ли в порядке:

root@ubuntu:~# lxc profile show customprofile
config:
  environment.http_proxy: ""
  limits.memory: 2GB
description: ""
devices:
  eth0:
    nictype: bridged
    parent: br0
    type: nic
  root:
    path: /
    pool: default
    type: disk
name: customprofile
used_by: []


Затем давайте загрузим изображение LXD в формате Unified Tarball:

root@ubuntu:~# wget -O /tmp/ubuntu1804.tar.gz http://example.net/lxd-images/ubuntu1804.tar.gz


И импортируйте его:

root@ubuntu:~# lxc image import /tmp/ubuntu1804.tar.gz --alias ubuntu1804
Image imported with fingerprint: dc6f4c678e68cfd4d166afbaddf5287b65d2327659a6d51264ee05774c819e70


Когда все будет готово, давайте создадим наш первый контейнер:

root@ubuntu:~# lxc init ubuntu1804 container01 --profile customprofile
Creating container01


Теперь давайте добавим несколько каталогов хоста в контейнер:
обратите внимание, что вы должны установить правильного владельца каталога на хосте!

root@ubuntu:~# mkdir /srv/log01
root@ubuntu:~# lxc config device add container01 log disk source=/srv/log01 path=/var/log/


И в качестве последнего штриха добавьте в контейнер раздел хоста:

root@ubuntu:~# lxc config device add container01 bluestore unix-block source=/dev/sdb1 path=/dev/bluestore


/ dev / sdb1 будет доступен внутри контейнера. Мы используем его для передачи устройств для Ceph's Bluestore в контейнер.

Контейнер готов к запуску.

root@ubuntu:~# lxc start container01


Вуаля! Контейнер запущен и работает. Мы настраиваем наши контейнеры так же, как указано выше.

Хотя это было довольно просто настроить вручную. Для массового развертывания вам необходимо автоматизировать вещи. Итак, теперь давайте сделаем это, используя наш модуль LXD Puppet.

Автоматическая установка с Puppet

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

Затем создайте новый класс или добавьте его к одному из существующих классов; все, что вам подходит.



Я подключил его к своему марионеточному серверу. Обратите внимание, что я использую мостовое устройство br0, которое было подготовлено ранее другими модулями, и что изображения LXD размещаются на веб-сервере example.net/lxd-images/ в виде унифицированных тарболов.

Полный пример модуля, использующего модуль LXD Puppet:

class mymodule { 
 
    class {':: lxd':} 
 
    lxd :: storage {'default': 
        driver => 'dir', 
        config => { 
            'source' => '/ var / lib / lxd / storage-pools / default ' 
        } 
    } 
 
    lxd :: profile {' exampleprofile ': sure 
        =>' present ', 
        config => { 
            ' environment.http_proxy '=>' ', 
            ' limits.memory '=>' 2GB ', 
        }, 
        devices => { 
            'root' => { 
                'path' => '/', 
                'pool' => 'default',
                'type' => 'disk', 
            }, 
            'eth0' => {
                'nictype' => 'bridged', 
                'parent' => 'br0', 
                'type' => 'nic', 
            } 
        } 
    } 
 
    lxd :: image {'ubuntu1804': sure 
        => 'present', 
        repo_url => ' http://example.net/lxd-images/ ', 
        image_file =>' ubuntu1804.tar.gz ', 
        image_alias =>' ubuntu1804 ', 
    } 
 
    lxd :: container {' container01 ': 
        state =>' start ', 
        config => { 
            'user.somecustomconfig' => 'Моя потрясающая пользовательская переменная env',
        }, 
        profiles => ['exampleprofile'], 
        image => 'ubuntu1804',
        устройства => { 
            'log' => { 
                'path' => '/ var / log /', 
                'source' => '/ srv / log01', 
                'type' => 'disk', 
            }, 
            'bluestore' = > { 
                'путь' => '/ dev / bluestore', 
                'source' => '/ dev / sdb1', 
                'type' => 'unix-block', 
            } 
        } 
    } 
}


Теперь осталось только запустить марионеточный агент на машине. Он применит желаемое состояние:

root@ubuntu:~# puppet agent -t
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Caching catalog for ubuntu.openstacklocal
Info: Applying configuration version '1588767214'
Notice: /Stage[main]/Lxd::Install/Package[lxd]/ensure: created
Notice: /Stage[main]/Lxd::Config/Lxd_config[global_images.auto_update_interval]/ensure: created
Notice: /Stage[main]/Mymodule/Lxd::Storage[default]/Lxd_storage[default]/ensure: created
Notice: /Stage[main]/Mymodule/Lxd::Profile[exampleprofile]/Lxd_profile[exampleprofile]/ensure: created
Notice: /Stage[main]/Mymodule/Lxd::Image[ubuntu1804]/Exec[lxd image present http://example.net/lxd-images//ubuntu1804.tar.gz]/returns: executed successfully
Notice: /Stage[main]/Mymodule/Lxd::Container[container01]/Lxd_container[container01]/ensure: created
Notice: Applied catalog in 37.56 seconds


В конце концов, у вас будет запущен новый контейнер:

root@ubuntu:~# lxc ls
+-------------+---------+--------------------+------+------------+-----------+
|    NAME     |  STATE  |        IPV4        | IPV6 |    TYPE    | SNAPSHOTS |
+-------------+---------+--------------------+------+------------+-----------+
| container01 | RUNNING | 192.168.0.5 (eth0) |      | PERSISTENT | 0         |
+-------------+---------+--------------------+------+------------+-----------+


Поскольку вы можете выставлять пользовательские переменные среды в контейнере, это открывает множество возможностей для настройки новых контейнеров.



Как это хорошо !?

Я призываю всех внести свой вклад в модуль или поставить ему звезду на GitHub, если вы сочтете его полезным.

Планы на будущее

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

В будущем мы планируем перенести всю нашу устаревшую инфраструктуру на новое решение на основе LXD. Это будет гигантский проект для миграции: более 50 ПБ размещается на более чем 2000 выделенных серверах, но это уже история для другого раза.

Механизм интерпретации: инструмент с открытым исходным кодом для интерпретации ваших моделей в ML Serving

Контекст

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



Скорее всего, вы читали статьи о методах машинного обучения (ML) или даже использовали модели машинного обучения — возможно, это заставило вас усомниться в их использовании в производственных системах. В самом деле, даже если модель дает интересные результаты, результаты могут показаться практикам неясными. Не всегда очевидно, почему модель приняла решение, особенно когда есть много функций с различными значениями и метками. Для неопытных пользователей предсказание будет казаться волшебным. В ответ на это новая область исследований, известная как интерпретируемость, направлена ​​на демистификацию моделей черного ящика. Исследование интерпретирует объяснения прогнозов, что, в свою очередь, дает пользователям уверенность в результатах. Таким же образом подтверждается использование моделей в производстве.

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



Классификация метода изображена на рисунке выше. Во-первых, мы отделяем локальные методы от глобальных. Локальные методы объясняют один прогноз, сделанный моделью, в то время как глобальные методы исследуют поведение всех функций для набора образцов. Во-вторых, мы различаем способ представления результатов методами (например, ранжирование важности признаков, график прогнозирования воздействия для значений признаков, дерево правил и т. Д.…).

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

Механизм интерпретации

Использовать механизм интерпретируемости довольно просто. Чтобы установить инструмент, вы можете ввести его pip install interpretability-engine, а затем использовать его через интерфейс командной строки.

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

interpretability-engine --token XXX --deployment-url https://localhost:8080 --samples-path my_dataset.csv --features 0 1 2 --method 'pdp'


Примечание: 0 1 2 — это указатели характеристик

Вы также можете получить образцы, хранящиеся в хранилище объектов, с помощью swift, см .: interpretability-engine --help.

Пример в наборе данных iris

Теперь давайте попробуем конкретный пример на наборе данных радужной оболочки глаза. Мы обучили модель с помощью scikit, экспортируем ее в формат ONNX и развертываем на ML Serving, см. Документацию.

Затем мы использовали весь набор данных радужной оболочки в качестве образца, что позволило нам получить максимум информации о модели.

Примеры выглядят так (формат csv):

4.7,3.2,1.3,.2
4.6,3.1,1.5,.2
5,3.6,1.4,.2
5.4,3.9,1.7,.4
...


Примечания :

  • Каждая строка — это экземпляр, а каждый столбец — это функция.
  • Первый столбец соответствует 
    sepal.length
    , второй - 
    sepal.width
    , третий - 
    petal.length
    и последний - 
    petal.width
    .
  • Порядок функции должен соответствовать порядку функции в экспортированном формате, см. Ограничения, подробно описанные ниже.

Затем запускаем следующую команду:

interpretability-engine --token xxx --deployment-url https://xxxx.c1.gra.serving.ai.ovh.net/iris/ --samples-path iris.csv --features 0 1 2 3 --feature-names "sepal.length" "sepal.width" "petal.length" "petal.width" --label-names "setosa" "vergicolor" "virginica"


И получаем следующий рисунок:



Ось PDP соответствует среднему значению воздействия на модель. В этом примере это их вероятность для каждой метки. Например, чем больше длина чашелистика, тем выше вероятность, что это будет вид «вергиника».

Примечание: если вы хотите сохранить результат, используйте опцию--output-file you-result-filename.pdf

Ограничения и будущая работа

Interpretability Engine — это первый шаг к объяснению модели, но текущая реализация включает ограничения.

Среди них — отсутствие методов. На данный момент доступен только один глобальный метод (PDP). Мы планируем добавить дополнительные методы, более эффективные с точки зрения вычислений, такие как ALE. Мы также планируем добавить локальные методы с целью объяснения одного прогноза. Самый эффективный с точки зрения вычислений — LIME. Другие методы, такие как [Anchors] () или [SHAP] (), звучат многообещающе, но пока остаются дорогими.

Другое ограничение связано с именами функций, которые зависят от того, как вы экспортировали свою модель. Модель, обученная в scikit и экспортированная в формат ONNX, будет иметь только один вход с формой, соответствующей количеству функций. Следовательно, функции не имеют имен и основаны на их индексах. Чтобы решить эту проблему, мы позволяем пользователю сопоставлять указатель функций с именами с помощью этой опции --feature-names. Таким образом, когда объяснение экспортируется, его легче читать. Аналогичная проблема существует с этикетками, в этом случае вы можете использовать эту опцию --label-names.

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

На данный момент экспортированные результаты доступны для чтения, когда есть некоторые функции, но остается вопрос, как представить сотни функций с помощью методов PDP?

Открытый источник

Открытый исходный код является частью культуры OVHCloud, поэтому мы сделали инструмент доступным на Github. Если у вас есть какие-либо мысли по поводу улучшений, не стесняйтесь сообщить нам об этом через PR.

Ссылки

BigBlueButton

Во время кризиса Covid-19 OVHcloud старался поддерживать тесный контакт со школами и университетами и продолжать их поддерживать. Мы всегда делимся своими идеями и возможностями со студентами на ярмарках вакансий, карьерных встречах, демонстрациях технологий и практических семинарах.

В рамках этой инициативы OVHcloud предлагает школам и университетам ваучеры, которые дают студентам возможность учиться на практике. Эти ваучеры позволяют учителям создавать экземпляры Public Cloud и изучать новое программное обеспечение для виртуализации. Ваучеры также используются для заказа выделенных серверов с целью поддержки решений электронного обучения, таких как BigBlueButton. Университет ISEN Ouest занимается этим с начала кризиса Covid-19.



Коротко о BigBlueButton

BigBlueButton (BBB) ​​- это система веб-конференций, предназначенная для электронного обучения. BBB — это проект с открытым исходным кодом, начатый в 2007 году в рамках GNU LGPL. Он предоставляет широкий спектр функций видеоконференций (аудио, видео, совместное использование экрана, белая доска, запись сеанса и т. Д.) С простым и интуитивно понятным пользовательским интерфейсом. Для электронного обучения BBB расширяет свои функциональные возможности и совместимость с различными системами управления обучением (LMS); такие как Moodle, Canvas, Jenzabar, Sakai или Schoology.



BBB @ ISEN

16 марта — го, Франция вошла в строгую изоляцию, и все школы и учебные центры были закрыты. На следующий день ISEN Ouest решила, что им необходимо эффективное решение для электронного обучения своих студентов, поэтому установила BigBlueButton на выделенных серверах, размещенных в OVHcloud.

Цель — обеспечить педагогическую преемственность для студентов из кампусов в Бресте, Нанте и Ренне — означала, что решение платформы должно было поддерживать связь нескольких сотен студентов каждый день — с помощью видеоконференций, обмена документами и чата. Задача заключалась в том, чтобы решение было достаточно мощным, чтобы выдерживать такие большие нагрузки.

Чтобы ответить на этот вызов, ISEN Ouest разработал архитектуру следующим образом:

  • Один выделенный сервер Rise-1 на передней панели, настроенный как масштабируемый балансировщик нагрузки Scalelite , подключенный к среде ISEN Ouest Moodle .
  • Два выделенных сервера Infra-1 с 64 ГБ ОЗУ и гарантированной пропускной способностью 2 Гбит / с для видеоконференций BBB, а также для размещения виртуальных классов и встреч. Один сервер расположен в одном из наших центров обработки данных в Страсбурге, а другой — в Рубе — это распределяет нагрузку и обеспечивает непрерывность обслуживания в случае сбоя. 

Наконец, архитектура была построена ISEN в соответствии с архитектурой, предложенной Scalelite.



Чтобы участвовать в уроках, студенты подключаются к цифровой рабочей области, предоставляемой ISEN, и присоединяются к предварительно настроенному классу в Moodle. Они автоматически идентифицируются и добавляются в «список учащихся». Учителя берут на себя роль модераторов в классе и могут управлять своим классом со всей необходимой им автономией.

После нескольких учебных занятий, посвященных электронному обучению с помощью BBB, преподаватели ISEN могли проводить подавляющее большинство запланированных уроков (кроме тех, которые требуют практических инструментов, таких как лабораторное оборудование).

Ежедневно платформа принимает около 600 студентов и преподавателей, которые разделены между 20-40 виртуальными классами. Балансировщик нагрузки поглощает пики соединения между двумя серверами BBB и сглаживает нагрузку, которая может превышать 1 Гбит / с.

BBB @ OVHcloud

Мы используем BigBlueButton в OVHcloud, первыми пользователями стали сотрудники нашего Учебного центра. Действительно, что касается школ, предприятия должны продолжать обучать своих сотрудников во время блокировки.

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

Благодаря некоторым обсуждениям с Эммануэлем, главой ISEN Nantes и бывшим менеджером учебного центра в OVHcloud, мы открыли для себя BBB и захотели попробовать.

Наш первый тест был проведен на одном выделенном сервере Infra-1:

  • Процессор: Intel Xeon-E 2274G — 4 c / 8 t — 4 ГГц / 4,9 ГГц 
  • Оперативная память: 32 ГБ
  • Накопитель: 2 × 960 Go SSD, NVMe Soft RAID 
  • Публичная сеть: 1 Гбит / с 
  • Частная сеть: 2 Гбит / с 

После этого первоначального эксперимента и благодаря упрощенным сценариям установки BBB мы установили его на инстанс публичного облака C2-60 (16 ядер; 60 Go RAM; 400 Go SSD; гарантированная пропускная способность 1 Гбит в общедоступной сети и до 4 Гбит / с. в частной сети). Это повысило устойчивость и упростило обслуживание.

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

  • Нет необходимости устанавливать программное обеспечение локально (через веб-браузер).
  • Идеальное качество звука и видео без задержки, 
  • Очень просто и удобно.
  • Доступны различные интерактивные режимы: доска, управление группами, совместное использование слайд-шоу и т. Д.
  • Легкая интеграция с Moodle. 



BBB @ #Open_Solidarity

Благодаря Worteks BigBlueButton стал одним из бесплатных инструментов, предлагаемых во время кризиса COVID19. Это возможно благодаря нашей инициативе #OpenSolidarity.

Так что, если вы учитель или инструктор, ищущий решение для электронного обучения, простое в использовании, с большим количеством функций и надежным дизайном, обратите внимание на экземпляры BBB от W'Sweet.

Прокачай мой Makefile

Чтобы не повторяться, рекомендуется поместить все задачи, которые вы можете выполнить дважды, где-нибудь в своем проекте. Makefile — идеальное место, а также исполняемая документация: вместо документирования процесса сборки вы должны записать его в цель сборки



Make почти везде — либо установлен, либо на расстоянии одной команды во всех дистрибутивах Linux. Но он далек от совершенства: например, нет встроенной справки или какой-либо опции для перечисления доступных целей для выполнения завершения Bash.

Помощь по целям

Рассмотрим следующий Makefile:

BUILD_DIR=build

clean: # Clean generated files and test cache
	@rm -rf $(BUILD_DIR)
	@go clean -testcache

fmt: # Format Go source code
	@go fmt ./...

test: clean # Run unit tests
	@go test -cover ./...

.PHONY: build
build: clean # Build binary
	@mkdir -p $(BUILD_DIR)
	@go build -ldflags "-s -f" -o $(BUILD_DIR)/hello .


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

BUILD_DIR=build

help: # Print help on Makefile
	@grep '^[^.#]\+:\s\+.*#' Makefile | \
	sed "s/\(.\+\):\s*\(.*\) #\s*\(.*\)/`printf "\033[93m"`\1`printf "\033[0m"`	\3 [\2]/" | \
	expand -t20

clean: # Clean generated files and test cache
	@rm -rf $(BUILD_DIR)
	@go clean -testcache

fmt: # Format Go source code
	@go fmt ./...

test: clean # Run unit tests
	@go test -cover ./...

.PHONY: build
build: clean # Build binary
	@mkdir -p $(BUILD_DIR)
	@go build -ldflags "-s -f" -o $(BUILD_DIR)/hello .


Теперь вы можете создавать справку по целям, набрав:

$ make help
help       Print help on Makefile []
clean      Clean generated files and test cache []
fmt        Format Go source code []
test       Run unit tests [clean]
build      Build binary [clean]


Target help анализирует Makefile с помощью регулярного выражения, чтобы извлечь целевые имена, описания и зависимости, чтобы распечатать их на терминале. Поскольку эта цель является первой в Makefile, она используется по умолчанию, и вы можете получить помощь, набрав make .

Завершение удара по целям

Некоторые дистрибутивы предоставляют пакет для добавления завершения Bash в цели Make, другие — нет. Если у вас нет завершения при вводе make [TAB] , вы можете добавить его, используя следующий файл (например, в вашем файле ~ / .bashrc ):

# /etc/profile.d/make

complete -W "\`grep -oEs '^[a-zA-Z0-9_-]+:([^=]|$)' ?akefile | sed 's/[^a-zA-Z0-9_.-]*$//'\`" make


В примере файла сборки завершение будет напечатано:

$ make [TAB]
build  clean  fmt    help   test
$ make t[TAB]est


Это удобно для больших Make-файлов с несколькими целями.

Включение Makefile

Можно включить дополнительные файлы Makefile, которые включают директивы. Одним из примеров этого может быть включение Makefile help.mk в тот же каталог:

help: # Print help on Makefile
	@grep '^[^.#]\+:\s\+.*#' Makefile | \
	sed "s/\(.\+\):\s*\(.*\) #\s*\(.*\)/`printf "\033[93m"`\1`printf "\033[0m"`	\3 [\2]/" | \
	expand -t20


Его можно импортировать в основной Makefile следующим образом:

include help.mk

BUILD_DIR=build

clean: # Clean generated files and test cache
	@rm -rf $(BUILD_DIR)
	@go clean -testcache

fmt: # Format Go source code
	@go fmt ./...

test: clean # Run unit tests
	@go test -cover ./...

.PHONY: build
build: # Build binary
	@mkdir -p $(BUILD_DIR)
	@go build -ldflags "-s -f" -o $(BUILD_DIR)/hello .


Это будет включать в себя help.mk с целевой помощью. Но поскольку целевой справки больше нет в основном файле Makefile, она больше не будет отображаться при печати справки:

$ make help

$ make help
clean      Clean generated files and test cache []
fmt        Format Go source code []
test       Run unit tests [clean]
build      Build binary [clean]


По той же причине завершение Bash не будет включать целевую справку. Включение справки и завершения во включенных Make-файлах требует дополнительной работы для их анализа и учета включенных целей.

Сделать инструменты

Make Tools используются для решения этих проблем с включением. Таких инструментов два:

Сделайте помощь
Инструмент Make Help сканирует текущий каталог в поисках make-файла, а затем анализирует его, чтобы извлечь информацию о целях. Включенные make-файлы анализируются рекурсивно. Таким образом, чтобы распечатать справку в предыдущем примере, вы должны ввести:

$ make-help
build Build binary [clean]
clean Clean generated files and test cache
fmt   Format Go source code
help  Print help on Makefile
test  Run unit tests [clean]


Мы знаем, что цели отсортированы и что цель справки включена в печатную справку.

Вы можете включить эту цель справки в make-файл со следующим определением:

.PHONY: help
help: # Print help on Makefile
	@make-help


Сделать цели
Этот инструмент рекурсивно перечисляет цели make-файла в текущем каталоге и все включенные. В предыдущем примере:

$ make-targets
build clean fmt help test


Таким образом, чтобы выполнить завершение bash, вы должны указать:

# /etc/profile.d/make

complete -W "\`make-targets\`" make


Известные ошибки
Эти инструменты работают так же, как и make:

  • Включенные файлы относятся к текущему каталогу, а не к соответствующему make-файлу.
  • Для включений нет бесконечного цикла обнаружения.

Этот инструмент с открытым исходным кодом, не стесняйтесь вносить свой вклад и улучшать его.

Наслаждайтесь!

Гибкая телеметрия в OVHCloud - Часть III

Эта статья является третьей в серии статей, мы рекомендуем сначала прочитать часть 1 и часть 2:

  • Рождение гибкой телеметрии в OVHcloud — Часть I
  • Гибкая телеметрия в OVHCloud — Часть II

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

Макро и Микровидение

Для команд разработчиков микровидение имеет решающее значение. В то время как макроэкономическая перспектива важна для достижения таких целей, как сроки поставки, наблюдение за микродетализацией разработки обеспечивает хорошее качество продукта. Вот как нам удалось достичь этой важной цели:



Микровидение



Три блока данных

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



BurdownChart

(1) Это прогресс текущего спринта и его процент завершения. Процент выполнения просто вычисляется:



(2) Это показывает, сколько раз команда разработчиков выходила из спринта, чтобы что-то исправить, и время завершения. На прилагаемом графике показаны пиковые дни, когда команда была мобилизована.



Чтобы сообщить об этом типе информации:

  • Команды добавляют в поле «Ярлык» JIRA заголовок: препятствие.
  • Они регистрируют время, проведенное в поле «Журнал работы» в JIRA.



Накопленная информация затем отображается на нашей панели инструментов. Это помогает нам понять, почему спринт не продвигается. Когда команды проводят недели на устранение неполадок, мы можем объяснить почему.

NB: Важно отделить спринт от препятствий. Эти две части информации позволяют сравнить «ожидаемое» и «неожиданное». Это позволяет предложить 2 типа графиков.

(3) В последней части рассказывается, почему команды вмешались, когда они вышли из спринта. Эти ценные данные дают нам четкое представление о ситуации. Если команда тратит 90% своего времени на устранение ошибок или устранение неполадок в поддержке, это дает информацию о процессах принятия решений для будущих проектов.



Природа препятствия

Пример: мы предоставляем 30 часов на исправление ошибок во время спринтов; должны ли мы сосредоточиться на создании чего-то нового или сокращении технического долга?

Вывод: Сегодня Agile-телеметрию используют 19 команд в OVHCloud. Это облегчает и позволяет нам измерять производительность и прогресс команд удаленно и в режиме реального времени. Он также предоставляет нам актуальную информацию, необходимую для реализации наших проектов. Именно эта методология получила награду Innovations Awards для сотрудников OVHCloud.

Если вы хотите погрузиться в Agile Telemetry, вы можете сделать это прямо сейчас!!! Просто возьмите нашу панель инструментов с открытым исходным кодом и нашего бота Jerem — github.com/ovh/jerem.

Анонс Kafka-on-Pulsar: добавление поддержки протокола Kafka в Apache Pulsar

Этот пост был опубликован в блогах StreamNative и OVHcloud, его соавторами являются Сиджи Го, Цзя Чжай и Пьер Земб. Спасибо Горацио Гонсалесу за иллюстрации!



Мы рады сообщить, что StreamNative и OVHcloud открывают исходный код «Kafka on Pulsar» (KoP). KoP обеспечивает поддержку протокола Apache Kafka в Apache Pulsar, вводя обработчик протокола Kafka на брокерах Pulsar. Добавив обработчик протокола KoP в существующий кластер Pulsar, вы теперь можете перенести существующие приложения и службы Kafka в Pulsar без изменения кода. Это позволяет приложениям Kafka использовать мощные функции Pulsar, такие как:

  • Оптимизация операций благодаря многопользовательской среде корпоративного уровня 
  • Упрощенные операции с архитектурой без ребалансировки 
  • Бесконечное хранение потока событий с помощью Apache BookKeeper и многоуровневого хранилища
  • Бессерверная обработка событий с помощью функций Pulsar

Что такое Apache Pulsar?

Apache Pulsar — это платформа потоковой передачи событий, изначально разработанная для облачных вычислений и обеспечивающая развертывание многоуровневой и сегментно-ориентированной архитектуры. Архитектура разделяет обслуживание и хранение на разные уровни, что делает систему удобной для контейнеров. Облачная архитектура обеспечивает масштабируемость, доступность и отказоустойчивость и позволяет компаниям расширять свои предложения с помощью решений с поддержкой данных в реальном времени. Pulsar получил широкое распространение с тех пор, как в 2016 году был открыт исходный код, а в 2018 году он был признан проектом Apache верхнего уровня.

Необходимость КОП

Pulsar предоставляет унифицированную модель обмена сообщениями как для очередей, так и для потоковых рабочих нагрузок. Pulsar реализовал собственный двоичный протокол на основе protobuf, чтобы обеспечить высокую производительность и низкую задержку. Такой выбор protobuf делает удобным реализацию клиентов Pulsar, и проект уже поддерживает языки Java, Go, Python и C ++ наряду с сторонними клиентами, предоставляемыми сообществом. Однако существующие приложения, написанные с использованием других протоколов обмена сообщениями, пришлось переписать, чтобы принять новый унифицированный протокол обмена сообщениями Pulsar.

Для решения этой проблемы сообщество Pulsar разработало приложения, упрощающие переход на Pulsar с других систем обмена сообщениями. Например, Pulsar предоставляет оболочку Kafka для API Kafka Java, которая позволяет существующим приложениям, которые уже используют клиент Kafka Java, переключаться с Kafka на Pulsar без изменения кода. Pulsar также имеет богатую экосистему соединителей, соединяющую Pulsar с другими системами данных. Тем не менее, все еще существовал высокий спрос со стороны тех, кто хотел перейти с других приложений Kafka на Pulsar.

Сотрудничество StreamNative и OVHcloud

StreamNative получал много входящих запросов о помощи по переходу с других систем обмена сообщениями на Pulsar и осознавал необходимость поддержки других протоколов обмена сообщениями (таких как AMQP и Kafka) изначально на Pulsar. StreamNative начал работу над внедрением общей структуры обработчиков протоколов в Pulsar, которая позволила бы разработчикам, использующим другие протоколы обмена сообщениями, использовать Pulsar.

Внутри OVHcloud уже много лет работает Apache Kafka, но, несмотря на их опыт работы с несколькими кластерами с миллионами сообщений в секунду на Kafka, возникают болезненные проблемы при эксплуатации. Например, объединить тысячи тем от тысяч пользователей в один кластер без мультитенантности было сложно.

В результате OVHcloud решила сместить и построить основу своего продукта «тема как услуга» под названием ioStream на Pulsar вместо Kafka. Мультиарендность Pulsar и общая архитектура с Apache Bookkeeper упростили операции по сравнению с Kafka.

Создав первый регион, OVHcloud решила реализовать его в качестве прокси-сервера для проверки концепции, способного на лету преобразовывать протокол Kafka в Pulsar. В ходе этого процесса OVHcloud обнаружил, что StreamNative работает над внедрением протокола Kafka в Pulsar, и они объединили усилия для разработки KoP.



KoP был разработан, чтобы предоставить оптимизированное и комплексное решение, использующее инфраструктуру хранения потоков событий Pulsar и BookKeeper и структуру подключаемого обработчика протоколов Pulsar. KoP реализован как плагин обработчика протокола с именем протокола «kafka». Его можно установить и настроить для работы в составе брокеров Pulsar.

Распределенный журнал

И Pulsar, и Kafka используют очень похожую модель данных для журналов как для обмена сообщениями pub / sub, так и для потоковой передачи событий. Например, оба они построены поверх распределенного журнала. Ключевое различие между этими двумя системами заключается в том, как они реализуют распределенный журнал. Kafka реализует распределенный журнал в архитектуре на основе разделов, где распределенный журнал (раздел в Kafka) предназначен для хранения в наборе брокеров, в то время как Pulsar развертывает архитектуру на основе сегментов для реализации своего распределенного журнала, используя Apache BookKeeper как его масштабируемый уровень хранения сегментов. Архитектура Pulsar на основе * сегментов * обеспечивает такие преимущества, как отсутствие перебалансировки, мгновенная масштабируемость и неограниченное хранение потоков событий. Вы можете узнать больше о ключевых различиях между Pulsar и Kafka вэтот блог Splunk и в этом блоге проекта Bookkeeper.

Поскольку обе системы построены на схожей модели данных, распределенном журнале, очень просто реализовать обработчик протокола, совместимый с Kafka, используя распределенное хранилище журналов Pulsar и его подключаемую структуру обработчика протоколов (введенную в выпуске 2.5.0).

Реализации

Реализация осуществляется путем сравнения протоколов между Pulsar и Kafka. Мы обнаружили, что между этими двумя протоколами есть много общего. Оба протокола состоят из следующих операций:

  • Поиск темы : все клиенты подключаются к любому брокеру для поиска метаданных (то есть брокера-владельца) тем. После получения метаданных клиенты устанавливают постоянные TCP-соединения с брокерами-владельцами.
  • Производство : клиенты обращаются к брокеру- владельцу тематического раздела, чтобы добавить сообщения в распределенный журнал.
  • Потребление : клиенты обращаются к брокеру- владельцу раздела темы, чтобы прочитать сообщения из распределенного журнала.
  • Смещение : сообщения, создаваемые для тематического раздела, назначаются со смещением. Смещение в Pulsar называется MessageId. Потребители могут использовать смещения для поиска заданной позиции в журнале для чтения сообщений.
  • Состояние потребления : Обе системы поддерживают состояние потребления для потребителей в рамках подписки (или группы потребителей в Kafka). Состояние потребления хранится в теме __offsets в Kafka, а состояние потребления хранится в виде курсоров в Pulsar.

Как видите, это все примитивные операции, обеспечиваемые масштабируемым распределенным хранилищем журналов, таким как Apache BookKeeper. Основные возможности Pulsar реализованы поверх Apache BookKeeper. Таким образом, довольно легко и просто реализовать концепции Kafka, используя существующие компоненты, которые Pulsar разработал для BookKeeper.

На следующем рисунке показано, как мы добавляем поддержку протокола Kafka в Pulsar. Мы представляем новый обработчик протоколов, который реализует проводной протокол Kafka, используя существующие компоненты (такие как обнаружение тем, распределенная библиотека журналов — ManagedLedger, курсоры и т. Д.), Которые уже есть в Pulsar.



Темы

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

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

Идентификатор сообщения и смещение

В Kafka каждому сообщению присваивается смещение после его успешного создания в разделе темы. В Pulsar каждому сообщению присваивается «MessageID». Идентификатор сообщения состоит из 3 -х компонентов, главная книга-ID , начальные идентификаторы и пакетный индекс . Мы используем тот же подход в оболочке Pulsar-Kafka для преобразования Pulsar MessageID в смещение и наоборот.

Сообщения

И сообщение Kafka, и сообщение Pulsar имеют ключ, значение, временную метку и заголовки (примечание: в Pulsar это называется «свойствами»). Мы автоматически конвертируем эти поля между сообщениями Kafka и сообщениями Pulsar.

Поиск по теме

Мы используем тот же подход поиска тем для обработчика запросов Kafka, что и обработчик запросов Pulsar. Обработчик запросов выполняет обнаружение темы для поиска всех владений для запрошенных тематических разделов и отвечает информацией о владении как часть Kafka TopicMetadata обратно клиентам Kafka.

Создавать сообщения

Когда обработчик запросов Kafka получает созданные сообщения от клиента Kafka, он преобразует сообщения Kafka в сообщения Pulsar, сопоставляя поля (т.е. ключ, значение, временную метку и заголовки) одно за другим, и использует API добавления ManagedLedger для добавления этих преобразованных сообщений Pulsar. в BookKeeper. Преобразование сообщений Kafka в сообщения Pulsar позволяет существующим приложениям Pulsar использовать сообщения, созданные клиентами Kafka.

Потреблять сообщения

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

Координатор группы и управление взаимозачетами

Самая сложная часть — внедрить управление групповым координатором и зачетами. Потому что Pulsar не имеет централизованного координатора группы для назначения разделов потребителям группы потребителей и управления смещениями для каждой группы потребителей. В Pulsar назначением разделов управляет брокер для каждого раздела, а управление смещением осуществляется путем сохранения подтверждений в курсорах брокером-владельцем этого раздела.

Модель Пульсара сложно согласовать с моделью Кафки. Следовательно, для обеспечения полной совместимости с клиентами Kafka мы реализовали координатор группы Kafka, сохраняя изменения и смещения группы координаторов в системной теме под названием public / kafka / __ offsets в Pulsar.

Это позволяет нам преодолеть разрыв между Pulsar и Kafka и позволяет людям использовать существующие инструменты и политики Pulsar для управления подписками и мониторинга потребителей Kafka. Мы добавляем фоновый поток в реализованный координатор группы для периодической синхронизации обновлений смещения из системной темы с курсорами Pulsar. Следовательно, группа потребителей Kafka фактически рассматривается как подписка Pulsar. Все существующие инструменты Pulsar также могут использоваться для управления группами потребителей Kafka.

Соедините две популярные экосистемы обмена сообщениями

В обеих компаниях мы ценим успех клиентов. Мы считаем, что предоставление собственного протокола Kafka на Apache Pulsar снизит барьеры для людей, использующих Pulsar для достижения успеха в бизнесе. Интегрируя две популярные экосистемы потоковой передачи событий, KoP открывает новые варианты использования. Клиенты могут использовать преимущества каждой экосистемы и создать действительно унифицированную платформу потоковой передачи событий с Apache Pulsar, чтобы ускорить разработку приложений и сервисов в реальном времени.

С помощью KoP сборщик журналов может продолжать собирать данные журналов из своих источников и отправлять сообщения в Apache Pulsar, используя существующие интеграции с Kafka. Последующие приложения могут использовать функции Pulsar для обработки событий, поступающих в систему, для выполнения бессерверной потоковой передачи событий.

Попробуй это

Исходный код KoP открыт под лицензией Apache License V2 по адресу https://github.com/streamnative/kop .

Мы с нетерпением ждем ваших вопросов и PR. Вы также можете присоединиться к каналу #kop в Pulsar Slack, чтобы обсудить все о Kafka-on-Pulsar.

StreamNative и OVHcloud также проводят веб-семинар по KoP 31 марта. Если вы хотите узнать больше о KoP, зарегистрируйтесь . С нетерпением жду встречи с вами онлайн.



Спасибо

Первоначально проект KoP был инициирован StreamNative. Команда OVHcloud присоединилась к проекту для совместной работы над проектом KoP. Большое спасибо Пьеру Зембу и Стивену Ле Ру из OVHcloud за их вклад в этот проект!

Управление 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/

Представляющий директор - инструмент для построения рабочих процессов Celery

Нам как разработчикам часто приходится выполнять задачи в фоновом режиме. К счастью, для этого уже существуют некоторые инструменты. Например, в экосистеме Python самая известная библиотека — это Celery. Если вы уже использовали это, вы знаете, насколько это здорово! Но вы также, вероятно, обнаружите, насколько сложно может быть отслеживание состояния сложного рабочего процесса.



Celery Director — это инструмент, который мы создали в OVHcloud для решения этой проблемы. Код теперь имеет открытый исходный код и доступен на Github.



После нашего выступления во время FOSDEM 2020, этот пост направлен на представление инструмента. Мы подробно рассмотрим, что такое Celery, почему мы создали Director и как его использовать.

Что такое «сельдерей»?

Вот официальное описание сельдерея:

Celery — это асинхронная очередь задач / очередь заданий, основанная на распределенной передаче сообщений. Он ориентирован на работу в реальном времени, но также поддерживает планирование.

Важные слова здесь — «очередь задач». Это механизм, используемый для распределения работы по пулу машин или потоков.



Очередь в середине приведенной выше диаграммы хранит сообщения, отправленные производителями (например, API). С другой стороны, потребители постоянно читают очередь, чтобы отображать новые сообщения и выполнять задачи.

В Celery сообщение, отправленное производителем, является подписью функции Python: send_email(«john.doe»)например.

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

Но зачем выполнять функцию Python где-то еще? Основная причина — быстрое возвращение ответа в случаях, когда функции долго выполняются. В самом деле, это не вариант заставлять пользователей ждать ответа несколько секунд или минут.

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

Как использовать «сельдерей»

Итак, Celery — это библиотека, используемая для выполнения кода Python где-то еще, но как она это делает? На самом деле это действительно просто! Чтобы проиллюстрировать это, мы будем использовать некоторые из доступных методов для отправки задач брокеру, а затем запустим воркер для их использования.

Вот код для создания задачи Celery:

# tasks.py
from celery import Celery

app = Celery("tasks", broker="redis://127.0.0.1:6379/0")

@app.task
def add(x, y):
    return x + y


Как видите, задача Celery — это просто функция Python, преобразованная для отправки в брокер. Обратите внимание, что мы передали соединение redis приложению Celery (названному app), чтобы сообщить брокеру, где хранить сообщения.

Это означает, что теперь можно отправить задачу в брокере:

>>> from tasks import add
>>> add.delay(2, 3)


Вот и все! Мы использовали этот .delay()метод, поэтому наш производитель не выполнял код Python, а вместо этого отправлял подпись задачи брокеру.

Теперь пора употребить его вместе с сельдереем:

$ celery worker -A tasks --loglevel=INFO
[...]
[2020-02-14 17:13:38,947: INFO/MainProcess] Received task: tasks.add[0e9b6ff2-7aec-46c3-b810-b62a32188000]
[2020-02-14 17:13:38,954: INFO/ForkPoolWorker-2] Task tasks.add[0e9b6ff2-7aec-46c3-b810-b62a32188000] succeeded in 0.0024250600254163146s: 5


Можно даже комбинировать задачи Celery с некоторыми примитивами (полный список здесь ):

  • Цепочка: будет выполнять задачи одну за другой.
  • Группа: будет выполнять задачи параллельно, направляя их нескольким рабочим.

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

from celery import chain, group

# Create the canvas
canvas = chain(
    group(
        add.si(1, 2),
        add.si(3, 4)
    ),
    sum_numbers.s()
)

# Execute it
canvas.delay()


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

.si()
Метод используется для создания неизменяемой подписи (т. Е. Такой , которая не получает данные от предыдущей задачи), в то время как 
.s()
полагается на данные, возвращенные двумя предыдущими задачами.

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

Как разработчик я хочу…

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

  • Отслеживание развития задач и их зависимостей в WebUI.
  • Выполнение рабочих процессов с помощью вызовов API или просто с помощью интерфейса командной строки.
  • Объединение задач для создания рабочих процессов в формате YAML.
  • Периодическое выполнение всего рабочего процесса.

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

И поскольку нам действительно были нужны эти функции, мы решили создать Celery Director.



Как использовать Директор

Установку можно произвести с помощью pip-команды:

$ pip install celery-director


Директор предоставляет простую команду для создания новой папки рабочего пространства:

$ director init workflows
[*] Project created in /home/ncrocfer/workflows
[*] Do not forget to initialize the database
You can now export the DIRECTOR_HOME environment variable


Ниже для вас создана новая папка задач и пример рабочего процесса:

$ tree -a workflows/
├── .env
├── tasks
│   └── etl.py
└── workflows.yml


В tasks/*.pyфайлы будут содержать ваши задачи Сельдерей, в то время как workflows.ymlфайл будет объединить их:

$ cat workflows.yml
---
ovh.SIMPLE_ETL:
  tasks:
    - EXTRACT
    - TRANSFORM
    - LOAD


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

После экспорта DIRECTOR_HOMEпеременной и инициализации базы данных с помощью director db upgradeвы можете выполнить следующий рабочий процесс:

$ director workflow list
+----------------+----------+-----------+
| Workflows (1)  | Periodic | Tasks     |
+----------------+----------+-----------+
| ovh.SIMPLE_ETL |    --    | EXTRACT   |
|                |          | TRANSFORM |
|                |          | LOAD      |
+----------------+----------+-----------+
$ director workflow run ovh.SIMPLE_ETL


Брокер получил задачи, поэтому теперь вы можете запустить Celery worker для их выполнения:

$ director celery worker --loglevel=INFO


А затем отобразите результаты с помощью команды веб-сервера ( director webserver):



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

Вывод

Наши команды регулярно используют Director для запуска наших рабочих процессов. Больше нет шаблонов и нет необходимости в продвинутых знаниях Celery… Новый коллега может легко создавать свои задачи на Python и комбинировать их в YAML, не используя примитивы Celery, описанные ранее.

Иногда нам нужно периодически выполнять рабочий процесс (например, для заполнения кеша), а иногда нам нужно вручную вызывать его из другой веб-службы (обратите внимание, что рабочий процесс также может быть выполнен через вызов API ). Теперь это возможно с помощью нашего единственного экземпляра Director.

Мы приглашаем вас попробовать Director на себе и оставить свой отзыв через Github, чтобы мы могли продолжать его улучшать. Исходный код можно найти на Github, а презентация FOSDEM 2020 доступна здесь.