Русский
Русский
English
Статистика
Реклама

Redhat

Интеграция Open vSwitch с Р-виртуализацией

01.07.2020 10:24:00 | Автор: admin

Как-то понадобилось интегрировать Open vSwitch (OVS) c Р-виртуализацией плюс Р-хранилище(РП), может пригодится и не только с РП.


Текущая версия РП на момент статьи была 7.0.13-31, ядро в этой версии 3.10.0-1062.12.1.rv7.131.10.1, что соответствует версии RedHat 7.7, а версия OVS, который идет в составе репозитория РП была 2.0.0. Список функционала на OVS 2.0.0 можно посмотреть тут. Ключи для РП можно взять тут.



Цель была попробовать настроить VXLAN и виртуальный коммутатор в качестве альтернативы родным к технологии kvm-qemu и libvirt мостам. Если использовать голый OpenSource kvm-qemu, то там с OVS все в порядке, но захотелось это попробовать с РП, где не просто голый kvm-qemu+libvirt, а много патчей к этой связке и есть vstorage.


Железо


Для этого конечно нам понадобится железо. Минимальные требования РП это три сервера в каждом по три диска, можно конечно и два если все SSD, но в моем случае один SSD остальные HDD. Далее сеть не менее 10 гигабит два порта, в моем случае повезло было 20 гигабит два порта и дополнительный порт 5 гигабит для ввода в кластер тегированного трафика для OVS в обход классическим мостам или другими словами параллельное использование классических мостов Р-виртуализации с OVS. В общем в моем случае повезло в наличии был Synergy c 3 лезвиями, корзинами с JBOD дисками и встроенным коммутатором.


Развертывание РП


Краткая инструкция по установке:


  • 1. Устанавливаем первую ноду, в анаконде назначаем IP хосту и из этой же подсети виртуальный IP для управления Р-виртуализации, и IP для управления Р-хранилищем. Дисков как минимум должно быть 3, один для хоста (ОС/гипервизор) в моем случае HDD, второй и третий диск уже настроим через управление Р-хранилищем, где один SSD под кэш и другой под чанк сервер. На втором интерфейсе назначаем IP из другой подсети для сети хранения без шлюза.
  • 2. После установки заходим через браузер хром по IP адресу управления Р-хранилищем, далее выбираем раздел серверы и нажимаем на вопросик с прямоугольником, и выбираем раздел сеть, в нем назначаем роли для интерфейса с адресом подсети управления(роли ssh, управление, web cp) и для интерфейса с подсетью для хранения назначаем роли (ssh, хранилище).
  • 3. Далее нажимаем создать кластер вводим его имя автоматом должен подключится интерфейс с ролью хранения и выбрать подробные настройки, убедится что система правильно распределила роли на дисках, один должен быть системный, другой служба метаданных плюс кэш если это SSD и далее третий диск HDD в роли хранения (чанк сервер).
  • 4. Параллельно с установкой первой ноды можно устанавливать две последующие, назначить каждой по два IP адреса один для подсети управления Р-виртуализации, на втором интерфейсе из подсети хранения. Если оставить поля регистрации на сервере управления Р-виртуализации и управления Р-хранилище пустыми то, можно продолжить установку без указания IP адресов управления, а регистрацию выполнить потом.
  • 5. После того как последующие ноды установлены пройти по IP адресу этих хостов через ssh в cli и выполнить регистрацию, где IP это адрес управления Р-хранилищем и токен можно скопировать с веб управления р-хранилищем при нажатии добавить ноду.
  • 6. После того как обе ноды появятся в веб управлениии Р-хранилище выполнить те же действия что в пункте 2-3 только вместо создания кластера выбрать присоединить.
  • 7. Далее после создания кластера появится пункт сервисы в нем создать хранилище датастор в зависимости наличия дисков и узлов можно делать реплику 2 или 3 и т.д. если узла 3 то, реплика 2, остальное все по умолчанию.
  • 8. Далее проходим по IP адресу управления Р-виртуализации нажимаем добавить если физ. сервер если не добавлен и добавляем остальные, далее устанавливаем триал лицензию, далее в настройках хоста выполнить Изменение настроек хоста для виртуальных сред выбрать вместо локальной папки по умолчанию можно для всех пунктов(для первого раза лучше так) выбираем наш датастор который создавали в Р-хранилище и ставим галочку применить на все хосты.
  • 9. После это мигрируем vstorage-ui и va-nm на любой другой хост, время может занять некоторое потому что это миграция с локальных носителей на кластерные.
  • 10. После этого открываем ssh консоли всех трех узлов и вводим команду включения HA на каждом узле, где IP адрес сети хранения, после этого необходимо проверить командой #shaman stat
  • 11. После этого можно приступать к созданию ВМ, где я в качестве гостевой установил CentOS 7.

команда регистрации ноды к выше описанному пункту 5:


#/usr/libexec/vstorage-ui-agent/bin/register-storage-node.sh -m 10.43.10.14 -t ec234873

комнда включения HA к пункту 10:


#hastart -c имя кластера -n 192.168.10.0/24 

и проверка HA, где вывод должен быть примерно такой:


[root@n3 ~]# shaman statCluster 'rptest'Nodes: 3Resources: 7    NODE_IP           STATUS     ROLES                RESOURCES    192.168.10.10     Active     VM:QEMU,CT:VZ7       0 CT, 0 VM    192.168.10.11     Active   VM:QEMU,CT:VZ7       0 CT, 0 VM*M 192.168.10.12     Active     VM:QEMU,CT:VZ7       2 CT, 0 VM

Установка и настройка OVS


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


#yum install openvswitch 

После установки можно проверить командой


#ovs-vsctl show 

Вывод будет примерно следующий:


[root@node1 ~]# ovs-vsctl show180c5636-2d3d-4e08-9c95-fe5e47f1e5faovs_version: "2.0.0"[root@node1 ~]#

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


# ovs-vsctl add-br ovsbr0 

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


#ovs-vsctl add-br brlv140 ovsbr0 140 

Тег при этом может быть не привязан к какому-то реальному тегу с физического порта, это только в рамках виртуального коммутатора.
Далее назначаем его ВМ к виртуальной сети, где предварительно создаем xml файл:


<network> <name>ovsvl</name> <forward mode='bridge'/> <bridge name='brlv140'/> <vlan>  <tag id='140'/></vlan><virtualport type='openvswitch'/></network>

К сожалению веб ui Р-управления пока не поддерживает настройки с OVS, но их можно сделать через cli. Для создания и добавления виртуальных сетевых адаптеров к ВМ я воспользовался веб ui, но далее уже через cli подменил привязку этих адаптеров к ovsvl и ovsvl2 вместо Bridged. Главное потом не забыть, что изменения в сетевые настройки оборудования ВМ уже вносить через cli иначе веб ui не зная про OVS вернет Bridged.
Для просмотра существующих сетей используем команду:


#virsh net-list --all 

Для добавления нашей сети:


#virsh net-define ovsvl.xml 

Далее необходимо ее запустить/активировать


#virsh net-start ovsvl

И прописать в автостарт


#virsh net-autostart ovsvl

Далее необходимо добавить эту сеть к ВМ


#virsh edit имяВМ 

Находим необходимые строки с интерфейсами, редактируем их или добавляем свои по аналоги существующих меняя мак адрес и номер порта(слот):


<interface type='bridge'>      <mac address='00:1c:42:c6:80:06'/>

  <vlan>    <tag id='140'/>  </vlan>  <virtualport type='openvswitch'>    <parameters interfaceid='5a70be5b-5576-4734-9f61-61cdfc4a884a'/>  </virtualport>  <target dev='vme001c42c68006'/>  <model type='virtio'/>  <boot order='2'/>  <alias name='net0'/>  <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/></interface>


Редактирование осуществляется командами редактора vi
Далее после редактирования необходимо выключить и запустить ВМ для применения текущих настроек:


#prlctl stop имя ВМ

#prlctl start имя ВМ

Для проверки можно ввести команду:


#virsh dumpxml имяВМ | grep имясети 

После этого можно приступать к настройкам сети изнутри гостя ВМ или добавить сетевые порты в коммутатор для связи с другим кластером по VXLAN overlay:


#ovs-vsctl add-port ovsbr0 vxlan0 -- set Interface vxlan0 type=vxlan options:remote_ip=10.43.11.12 

где IP адрес это адрес той ноды на которой произведены такие же настройки как показано выше. Прямая связь между этими адресами может быть, как через роутеры, так и через VPN, и из разных подсетей, главное, чтобы между ними был настроен маршрут. Но еще главнее, чтобы интерфейс физического порта на котором назначен это адрес, был настроен MTU больше чем 1500 для пропускания пакетов с большим размером, так как vxlan добавляет свои данные, заголовок в несколько байт, но я не стал заморачиваться считать все байты и просто назначил 2000.
Например:


#ip link set mtu 2000 dev ens3f0

сам мост зависящий от этого интерфейса тоже должен быть с mtu2000, но он может не сразу его наследовать и возможно понадобиться его перезапустить.


На стороне второго кластера выполнить на ноде с адресом 10.43.11.12 как описано выше те же настройки только в vxlan назначить адрес ноды первой настройки в моем случае


#ovs-vsctl add-port ovsbr0 vxlan0 -- set Interface vxlan0 type=vxlan options:remote_ip=10.43.11.10

Далее также настроить mtu.
Если у вас все правильно настроено то, пойдут пинги и возможно делать подключения по ssh, если предварительно например, изнутри ВМ задать адреса из одной подсети. Если выполнить анализ сети:


#tcpdump i ens3f0 | grep 4789``` то можно увидеть пакеты с vxlan или c тегами vlan ```bash#tcpdump -ee -vvv -i ens3f0 | grep vlan

Далее можно настроить более удобный вариант настройки сети без мостов через функционал виртуального коммутатора portgroup.
Для этого необходимо создать xml сети со следующим:


 <network><name>ovsvl2</name><forward mode='bridge'/><bridge name='ovsbr0'/><virtualport type='openvswitch'/><portgroup name='vlan-120'>    <vlan>      <tag id='120'/>    </vlan>  </portgroup></network>

Можно создать новую сеть или отредактировать предыдущую с этими параметрами, но
В моем случае добавляю еще одну сеть
Как описано выше, а в ВМ уже следующим образом:


<interface type='bridge'>      <mac address='00:1c:42:c8:f1:cd'/>

  <vlan>    <tag id='120'/>  </vlan>  <virtualport type='openvswitch'>    <parameters interfaceid='ef717aa4-23b3-4fbe-82bb-193033f933b1'/>  </virtualport>  <target dev='vme001c42c8f1cd'/>  <model type='virtio'/>  <boot order='3'/>  <alias name='net1'/>  <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/></interface>


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


#ovs-vsctl set port ens3f4 trunks=120,130#ovs-vsctl add-port ovsbr0 ens3f4  

И можно добавить порт с тегом 120 для ВМ:


#ovs-vsctl add-port ovsbr0 vlan120 tag=120 -- set interface vlan120 type=internal

На стороне другого виртуального коммутатора на другой ноде другого кластера, где нет транка от физического коммутатора добавить точно также этот порт то есть:


#ovs-vsctl add-port ovsbr0 vlan120 tag=120 -- set interface vlan120 type=internal

Плюс добавить сеть как описано выше.


Пример вывода настроек OVS и ВМ



Вывод команды #ovs-vsctl show на первой ноде. Порты и интерфейсы с именем начинающимся с vme являются виртуальными интерфейсами ВМ, которые автоматически попадают в конфиг при запуске ВМ подключенному к OVS.



Вывод команды #ovs-vsctl show на третей ноде



Вывод команды virsh net-list содержит 4 вида сети, где Bridged и Host-Only это стандартные классические варианты от Р-виртуализации по дефолту, а ovsvl и ovsvl2 это то, что мы добавили по инструкции выше. Ovsvl получается для варианта с тегированным мостом tag 140 поверх моста OVS, а ovsvl2 это вариант с группой портов portgroup состоящей из одного порта с tag 120. Portgroup очень удобен и в него можно добавлять больше одного порта используя только одну сеть вместо большого количества сетей в классическом варианте Р-виртуализации с мостами под которыми разные VLAN интерфейсы. Далее вывод команды #virsh net-dumpxml ovsvl и ovsvl2 показывающие содержимое настроек этих сетей.



Здесь кусок конфига ВМ, где сетевые интерфейсы по команде:


 #virsh dumpxml имяВМ

Тесты


При тестировании OVS была проверена совместимость с запущенным networkmanager(NM), выше описанные сценарии работают нормально, но при автозапуске службы NM может выдавать сообщения по интерфейсам виртуального коммутатора, которыми не может управлять, NM можно выключить, но на функциональность сети это не влияет.


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


Также были успешно проверены живые миграции ВМ с сетями от OVS, если на каждой ноде имеется экземпляр сети вместе с OVS то, проблем с миграцией нет, так же как и в стандартной конфигурации кластера Р-виртуализации с дополнительными сетями для ВМ.



На рисунке выше был запущен ping изнутри ВМ в сторону ВМ из внешней сети и выполнена живая миграция ВМ с одной ноды с установленным OVS на другую ноду с установленным OVS, красным помечена задержка во время этой миграции ВМ. Параметры ВМ были следующие 4 vCPU, 8GB RAM, 64GB disk.


Точно такая же задержка происходит и в классике с мостами, то есть для ВМ ничего не поменялось, а сетевой стек теперь работает через OVS.


По мимо этого производились успешные подключения по ssh с разными ВМ расположенными на разных нодах между туннелем vxlan и с ВМ за физическим коммутатором. Для проверки работы выключали туннель или анализировали пакеты через tcpdump как описано выше. Если не назначить MTU как описано выше то, будут проходить только ping, а через ssh не получится подключится.


Описание сценариев


Ниже показан стандартный классический с мостами вариант настройки кластера из трех нод Р-виртуализация плюс Р-хранилища без OVS.



На схеме опущена и не показана сеть Р-хранилища, она обычно идет отдельным интерфейсом предназначенного только для блочного уровня и в этом тесте не участвует. Ее можно настраивать без мостов, и как вариант ее тоже можно задействовать через OVS. Например настроить на OVS агрегацию для Р-хранилища.
Далее схема с использованием вместе с мостами OVS.



Тут уже может быть одна сеть с OVS и одна с мостом. С OVS можно добавлять порты с разными тегами в portgroup и выводить уже на разные ВМ.


Если вернемся к тестируемому сценарию то, его можно увидеть на следующей картинке



В моем случае было в рамках одного кластера, но это может быть и между разными кластерами за счет туннелей vxlan. Попытаемся представить себе, что это ноды двух разных кластеров.
Туннель поднят на специально выделенном порту одного из серверов каждого кластера. Через туннель выполняется проброс определенного vlan120 в котором определенное количество ВМ со всего кластера рассчитанное на ширину пропускного канала, где средствами OVS можно определить QoS для трафика каждой ВМ. Локальные ВМ этого узла видны через локальный OVS, а ВМ с других узлов видны через физический коммутатор каждого кластера.


Отказоустойчивость OVS обеспечивается за счет добавления в скрипт службы HA(shaman) команд по перебросу туннеля vxlan на другую ноду с OVS, которая будет выбрана по дефолтному алгоритму drs,round-robin за счет службы shaman от Р-Хранилища. Отказоустойчивость и балансировку порта сервера можно обеспечить за счет агрегации bonding в режиме LACP(802.3ad) c хэшированием layer2+3 или layer3+4, которую также можно настроить средствами OVS.


Как работает классический br0 я описывать не буду, ovsbr0 работает со IP стеком ОС, который на этой картинке определен для br0, то есть экземпляр виртуального коммутатора в виде ovsbr0 работает в данном случае через br0. Другими словами статический IP адрес ноды назначен на классический br0 и весь трафик, который направлен в эту подсеть с виртуального коммутатора проходит через br0, так же как это работает для всех приложений этой ноды. С точки зрения настройки в этом случае никаких cli назначений на br0 со стороны виртуального коммутатора не производилось кроме настройки vxlan интерфейса с option, соответственно если у ноды есть второй классический br1 c другим IP адресом и подсетью висящий на другом физическом порту например eth2 или eth3 то, с виртуального коммутатора за счет стека ОС и его таблицы mac-ов можно направить пакеты в эти подсети назначив какой либо порт виртуального коммутатора в эту подсеть и подключить к ВМ, адрес подсети будет непосредственно назначаться внутри ВМ или в ее настройках.


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



У виртуального коммутатора есть своя таблица маков.


У каждого созданного мною виртуального коммутатора есть какой-то набор интерфейсов (разрешая влан на каком-то интерфейсе мы добавляем порт в определенный виртуальный коммутатор), а также таблица соответствия mac адресов и портов (ее мы смотрим командой ovs-appctl fdb/show ovsbr0). Ручное назначение мак адресов внутри коммутатора не производилось. Portgoup это группа портов в которой на данный момент есть порт vlan120 к которому подключена ВМ.


Теоретически мы можем представить, что когда в какой-то порт коммутатора прилетает фрейм с VLAN тегом, то решение о дальнейшей отправке фрейма принимается на основании таблицы mac адресов соответствующего виртуального коммутатора. Если получен фрейм с тегом 120, то соответственно приниматься решение о форвардинге данного фрейма будет на основании mac таблицы виртуального коммутатора с тегом 120.


Что касаемо VXLAN то, в этом случае static (Unicast). Самый простой вариант это статичное указание удаленных интерфейсов по типу vxlan. Все сводится к тому, что в конфигурации VNI(vlan vxlan) надо статически задать адреса всех удаленных интерфейсов vxlan, которые терминируют клиентов в указанном VNI. В таком сценарии vxlan будет указывать в IP заголовке как адреса назначения адреса указанных вручную vxlan. Естественно, если vxlan-ов будет больше двух, то точек назначения пакета при флуде будет уже как минимум две. Указать в IP заголовке нескольких получателей не получится, поэтому самым простым решением будет репликация VxLAN пакета на исходящем интерфейсе vxlan и отправка их юникастом на удаленные интерфейсы vxlan, указанные в конфигурации. Получив данный пакет, удаленный vxlan его декапсулирует, определяет какому VNI данный пакет относится и далее рассылает его во все порты в данном VNI. Помимо этого, так как мы все в курсе, что mac адреса изучаются коммутаторами на основании поля source mac, то после декапсуляции VxLAN пакета интерфейс vxlan ассоциирует mac адрес, указанный как исходящий в оригинальном ethernet заголовке с тоннелем до интерфейса vxlan, от которого данный пакет получен. Как и было сказано ранее VxLAN тоннель коммутатор воспринимает как простой транковый порт.


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


Для работы данного режима необходимо только наличие связности между лупбеками всех интерфейсов vxlan.
Static (Unicast) VxLAN проста как валенок и безотказна, как автомат Калашникова. Ломаться тут нечему.
здесь все более подробно описано по определению маков и flood&Learn в OVS.


Заключение


При выполнении настроек OVS понравилась простота, удобносто, сразу чувствуется что работаешь с коммутатором, а не просто с мостами))) В общем есть смысл его использовать хотя бы параллельно с классическими мостами в РП.


Перед выше описанной интеграцией по мимо использованных в ней ссылок изучал еще следующие статьи:
1)https://www.sidorenko.io/post/2018/11/openstack-networking-open-vswitch-and-vxlan-introduction/
2) https://blog.remibergsma.com/2015/03/26/connecting-two-open-vswitches-to-create-a-l2-connection/
3)http://mx54.ru/nastrojka-setevyx-interfejsov-v-kvm-dlya-virtualnyx-mashin/
4) https://kamaok.org.ua/?p=2677
5)https://kashyapc.fedorapeople.org/virt/add-network-card-in-guest.txt
6)https://costiser.ro/2016/07/07/overlay-tunneling-with-openvswitch-gre-vxlan-geneve-greoipsec/#.XuZ960UzaM_

Подробнее..

Перевод Разумные разработчики не пишут код

08.03.2021 16:15:18 | Автор: admin

Кое-что застряло у меня в голове очень давно, когда я был молодым младшим разработчиком. Я работал, пытаясь ускорить доступ к данным в веб-приложении. Первая итерация кода вызывала базу данных каждый раз, когда пользователь просматривал данные. В поисках оптимизации я решил кешировать исходные возвращённые данные, чтобы не возвращаться к базе. Это было разумно.

Итак, опустив голову, я целыми днями придумывал нечто, что было бы лучшим кеширующим кодом Java из всех, что я видел! Я придумал сложные алгоритмы вызова, хранения, пейджинга и удаления данных для одного юзкейса. После 5 дней и ночей тяжёлого труда я гордо встретил своего ведущего разработчика и познакомил его с моим кодом; я одурачил его великолепием алгоритмов.

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


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

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

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

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

Этот урок напомнил мне о недавнем разговоре с молодым разработчиком, представившим проблему с использованием кода в RedHat OpenShift (предупреждаю: я работаю в Red Hat). Во всех деталях он объяснил, что написал множество микросервисов, чтобы сидеть перед множеством API, которые читают данные из различных источников и манипулируют ими перед отправкой в различные конечные точки. Он был очень горд своим множеством микросервисов, которые разработал, чтобы решить проблему. Там были агрегаторы, трансляторы и другие паттерны.

Я выслушал и вздохнул

Я сказал ему, что решение выглядит действительно сложным и что он немного переусердствовал с инженерией. В вежливой форме я сказал ему, что люди решили все эти и другие проблемы много раз. Указал на Apache Camel и сказал, что не нужно разрабатывать микросервисы ради микросервисов.

Не стройте микросервисы ради микросервисов!

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

Apache Camel один из великолепных примеров того, что не нужно заново изобретать велосипед

Я большой поклонник Apache Camel как в смысле интегратора, так и в смысле большого успеха сообщества Open Source. История утверждает, что Camel появился из разговора Грегори Хофа и Джеймса Стрейкена. Грегор написал библию интеграции Enterprise Integration Patterns, книгу с проектами общих задач интеграции в виде набора шаблонов так что вам не нужно изобретать одни и те же архитектурные шаблоны.

Джеймс, разработчик Open Source и основатель языка Groovy, и Грегор беседовали на конференции, и Джеймс подумал, что было бы неплохо создать переиспользуемые реализации этих шаблонов на Java так что вам не нужно продолжать писать один и тот же код, когда необходимо что-то сделать! Apache Camel родился из этой беседы как набор реализующих шаблоны интеграции библиотек.

Вернёмся к недавнему разговору с младшим разработчиком

Итак, мы взглянули на Red Hat Integration, которая представляет собой Apache Camel и кучу других вещей для развёртывания и запуска сервисов интеграции. Я сказал младшему разработчику, что он не только может делать всё, что ему нужно, но и подогнать всё в его архитектуру микросервисов и, глядя на некоторые новые разработки, такие как Camel K, он также может сервировать свои микросервисы бессерверно [have his microservices servederr, serverless! заставить работать свои микросервисы с помощью технологии serverless, бессерверно].

Бессерверная интеграция микросервисов

Camel К самая захватывающая вещь в интеграции на данный момент. Некоторые из самых больших проблем, с которыми сталкиваются специалисты по интеграции, всегда были связаны с тем, как с помощью архитектур интеграционных решений добиться доступности в больших масштабах. Такие инструменты, как Camel K и OpenShift, учитывают все аспекты развёртывания, запуска и масштабирования в этой задаче.

Apache Camel предоставляет реализацию шаблонов и сотни адаптеров. Глубокие знания нужны, только чтобы выяснить, какие коннекторы и шаблоны использовать, и, что важно, нужно знать о том, как компоненты развёртываются в масштабируемой и доступной архитектуре таким образом, чтобы поддерживать требования.

Такие проекты, как Camel K, это новая порода нативных инструментов kubernetes, которые стремятся задействовать мощь Kubernetes, чтобы воспользоваться огромными масштабами и возможностями доступности этой платформы. Некоторые сложные вещи в определении и проектировании масштаба и доступности уже реализованы при помощи Kubernetes, так что мне не нужно заново изобретать масштабирование и доступность!

Что такое Apache Camel?

Ок, я расскажу быстро, если вы не сталкивались с Apache Camel, то это инструмент потрясающей красоты, который по-настоящему упрощает интеграцию и соединение сотен разных вещей:

Бросим быстрый взгляд на Apache Camel.

  1. Он предоставляет более 50 паттернов интеграции.

  2. Имеет более 350 коннекторов.

  3. Он прекрасен.

Вот что лежит в основе каждой интеграции. Данные или вызов приходит из источника (FROM), затем идут в обработчик (PROCESSOR), в котором как-то обрабатываются, и затем направляются к (TO) месту назначения.

Компоненты FROM и TO или адаптеры соединяют технологии от нативных сервисов AWS, файлов CSV и SAP до реактивных потоков и коннекторов Kafka их больше трёхсот пятидесяти.

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

Вот мощь Open Source

Вот что обычно происходит: разработчик использует Camel, и плагина, в котором он нуждается, в Camel ещё нет. Итак, разработчик пишет компонент, удовлетворяющий его требованиям. Будучи порядочным гражданином страны Open Source, разработчик радует сообщество Camel вносит свой компонент в исходный код Camel, и этот компонент включается в следующий выпуск Camel. Теперь, когда компонент нужен вам, не нужно создавать его заново это потрясающе!

Множество источников могут помочь вам с Camel. Один из лучших книга Клауса Ибсона и Джонатана Энсти, Camel in Action библия Camel. Джеймс Стрейкен часто говорил, что он изобрёл Camel, но Клаус заставил инструмент работать. Кроме того, взгляните на блестящие статьи Тома Донахью о Camel.

А как же Camel К?

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

Я собираюсь создать Telegram-бота, который будет отправлять комплименты в канал Telegram. У Telegram есть API загрузки, которым я могу воспользоваться, чтобы отправлять сообщения в каналы, которыми могу пользоваться.

А вот сервис комплиментов Grant Codes: complimentr.com, который возвращает приятные слова, чтобы поднять настроение.

Ух ты, потрясающие цветовые схемы Гранта!Ух ты, потрясающие цветовые схемы Гранта!

Сейчас я хочу интегрировать эти два сервиса, чтобы отправлять комплименты моим друзьям в Telegram. Итак, я собираюсь погрузиться в код? Нет, чёрт возьми!

Взгляните на коннекторы Apache Camel среди 350 компонентов, с помощью которых я могу соединить разные вещи, я нашёл Camel Telegram: кто-то, кто хотел пообщаться с Telegram, уже написал что-то для этого, так что я писать ничего не должен!

Стандартные компоненты Camel помогут с вызовом простого HTTP в моём сервисе комплиментов. Я легкомысленно говорю стандартные, потому что на самом деле есть HTTP-компонент, который работает со всем, что я мог бы написать, но мне он не нужен!

Итак, я собираюсь воспользоваться компонентом Camel Telegram, чтобы получить сообщение от бота, затем вызываю внешний сервис, чтобы получить комплимент, и отправляю его боту Telegram. Вещь не самая захватывающая, но немного забавная. Вот чего я хочу от бота: чтобы я отправил имя и в ответ получил комплимент.

У меня есть кластер kubernetes, поэтому я сделаю бота с помощью Camel K и воспользуюсь Red Hat OpenShift и Camel K Operator, чтобы всё настроить.

Вот, что нужно сделать:

1. Загрузить CLI Camel K.

2. Установить Camel K Operator.

3. Запустить мой код.

Загрузите Camel K CLI

Об этом есть много статей и документации, поэтому я не буду вдаваться в кучу подробностей, но Camel K CLI (или kamel) это, по сути, CLI взаимодействия с вашей платформой Kubernetes (или, точнее, с пользовательскими ресурсами Camel K на платформе) для развёртывания интеграций (есть также плагины для VSCode).

CLI позволяет установить операторы Camel K, запустить интеграции в режиме интерактивной разработки (с обновлениями запущенного кода интеграции на лету) и т. д.

Установка Camel K Operator

В Camel K есть ряд операторов Kubernetes, чтобы создавать, развёртывать и запускать интеграции. Весь смысл операторов Kubernetes заключается в том, чтобы абстрагировать сложности всего того, что работает на платформе, и Camel K справляется великолепно! Так что просто возьмите и установите оператор из CLI, используя командную строку:

Или, если вы работаете в Openshift, откройте вкладку Operators, чтобы установить операторы.

Запускам мой код

После установки я могу отправить код интеграции на свою работающую платформу OpenShift из IDE или из командной строки.

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

from("telegram:bots?authorizationToken=[YOUR TOKEN])

Если я добавлю простое логирование, чтобы увидеть, как работает маршрут:

from("telegram:bots?authorizationToken=[YOUR TOKEN]").to("log:bots")

То на выходе всего пара строк кода. Сохранив их в файле hello.groovy, я получу скрипт groovy, им можно воспользоваться в качестве интеграции CamelK, которая подключится к моему telegram-боту и будет логировать всё, что я напечатаю!

Запуск hello.groovy

Здесь начинается нечто удивительное. Я хочу, чтобы мой двухстрочный скрипт groovy развёртывался и запускался как масштабируемый интеграционный компонент. Вот что такое Camel К! Из командной строки я запускаю простую команду:

С помощью команды run я превратил свой двухстрочный скрипт groovy в контейнер, развёрнутый и работающий как маршрут Apache Camel на моём кластере OpenShift.

Зачем флаг --dev

Добавив флаг --dev, я оказался в странном мире, где я могу изменить свой файл hello.groovy, и изменения отразятся в кластере OpenShift! Опция --dev сильно упрощает разработку.

Бот целиком

Вы уже видели, как работает Camel K, и вот оставшаяся часть моего скрипта с уклонением от кодирования:

from("telegram:bots?authorizationToken=[YOUR TOKEN]").setHeader("USER", body()).to("https://complimentr.com/api?asGET=true").transform().jsonpath("\$.compliment").setBody(simple("\${body} \${in.header.USER}")).to("telegram:bots?authorizationToken=[YOUR TOKEN]")
  • Чтобы получить сообщения из канала Telegram, я использую компонент Camel Telegram.

  • Спрячьте имя в заголовок, передаваемый в теле сообщения Telegram.

  • Вызовите API комплиментов.

  • Обратитесь к пользователю по имени.

  • Верните комплимент в канал Telegram.

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

Есть несколько действительно блестящих шаблонов интеграции Camel, таких как агрегаторы, брокеры, динамическая маршрутизация, и даже более удивительные вещи в Camel K, например бессерверность или масштабирование до нуля [отключение, когда платформа не используется] по запросу, они помогут вам не писать код!

Разумные разработчики, которые не занимаются программированием, давно уже не новость. Причины, по которым мы создаём фреймворки и инструменты, заключаются в желании абстрагироваться от рутины и работать продуктивнее. Иногда нужно понять, какие фреймворки и инструменты помогут вам не писать код. Надеюсь, я показал вам один из таких фреймворков!

Узнайте подробности, как получить Level Up по навыкам и зарплате или востребованную профессию с нуля, пройдя онлайн-курсы SkillFactory со скидкой 40% и промокодомHABR, который даст еще +10% скидки на обучение.

Другие профессии и курсы
Подробнее..

БудниDevOpscобираемgcc9.3.1подCentOS8

21.04.2021 16:08:09 | Автор: admin

В Северстали внедрены большие корпоративные системы, такие какSAPилиQMET,но есть и много разных задач, которые закрывает собственная разработка,и задачи у этой разработки редко бывают простыми. А значит, и требования к инструментам разработки бывают достаточно специфическими.Что делать, если вашим разработчикам потребовалсяgcc-9подCentOS,а его нет в общедоступных репозиториях? Конечно, засучить рукава исоздать требуемые пакеты. Вот только задача эта выглядит просто только на первый взгляд.

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

Stage1.Собственно сборкаgcc

Здесь казалось бывсё просто: берёмgcc.specот пакетаgcc-8.3.1, меняем 8 на 9, запускаемrpmbuildbb,долго ждём? Да, но нет. Для начала придётся пересмотреть и поправить все патчи, а заодно ещё и поставитьbinutilsпосвежее,благо этонесложно. Потом, мы же не просто так компилятор меняем, нам же ещё какие-нибудьnvptx-toolsподавай, а это значит, что когда сборка закончитсяи начнется тестирование, тесты вlibgomp,завязанные на выгрузку кода, начнут виснуть и застревать в разных странных позах.

Решения тут может быть два:

  1. Консервативное: сказать разработчикам извините, нешмогла и отключитьnvptx-tools.

  1. Экспериментальное: предупредить разработчиков, чтоnvptxони используют на свой страх и риск, после чего запуститьrpmbuild, дождаться застревания в тестах и отстреливать их руками. Вы получите массовыеtestsfailedв результатах, но искомые пакеты будут собраны.

Stage 2. Packagelibgcc.i686 has inferiorarchitecture

Итак,мыскладываемвсеэтизамечательныеgcc-9.3.1-3.el8.x86_64.rpm, gcc-offload-nvptx-9.3.1-3.el8.x86_64.rpmит.д.ит.п.вотдельныйрепозиторий,индексируемего,подключаемв/etc/yum.repos.d,говоримdnfupdateиНет, ну вы правда думали, что он возьмёт и сразупоставится? Как бы не так. Как известно, 64-разрядные дистрибутивы семействDebianиRedHatдля семейств процессоровx86 в глубине души немножечко 32-разрядные (то есть, по умолчанию существуют в режимеmultilib), и поэтому вам потребуется илиобъявитьmultilibпережитком прошлогои снести 32-разрядные библиотеки системного компилятора, или создать соответствующие пакеты (libgcc.i686,libgfortran.i686,libgomp.i686,libquadmath.i686 иlibstdc++.i686) для новой версии. Как ни забавно, но решения тут тоже может быть два:

  1. Рекомендованное производителем: поставитьmockи выполнитьполнуюсборку дляi686, наступив на все сопутствующие грабли (nvptx,например, лучше сразу выключить).

  1. Ленивое на скорую руку: дело в том, что 32-битные версии библиотек на самом деле собираются вместе с 64-битными,ноникудав итогене попадают. В стандартной версииgcc.specони вообще тупо удаляются, но это как раз недолго изакомментировать. А потом скопироватьgcc.specвlibgcc-i686.spec, вымарать из него всю секцию %build, а в %installнаписать примерно следующее:

%install rm -rf %{buildroot} mkdir -p %{buildroot} tar cf - -C %{_buildrootdir}/%{name}-%{version}-%{release}.x86_64 usr | tar xf - -C %{buildroot}  FULLPATH=%{buildroot}%{_prefix}/lib/gcc/%{gcc_target_platform}/%{gcc_major} FULLEPATH=%{buildroot}%{_prefix}/libexec/gcc/%{gcc_target_platform}/%{gcc_major}  # fix some things mkdir -p %{buildroot}/%{_lib} mv -f %{buildroot}%{_prefix}/%{_lib}/libgcc_s.so.1 %{buildroot}/%{_lib}/libgcc_s-%{gcc_major}-%{DATE}.so.1 chmod 755 %{buildroot}/%{_lib}/libgcc_s-%{gcc_major}-%{DATE}.so.1 ln -sf libgcc_s-%{gcc_major}-%{DATE}.so.1 %{buildroot}/%{_lib}/libgcc_s.so.1  mkdir -p %{buildroot}%{_datadir}/gdb/auto-load/%{_prefix}/%{_lib} mv -f %{buildroot}%{_prefix}/%{_lib}/libstdc++*gdb.py* \       %{buildroot}%{_datadir}/gdb/auto-load/%{_prefix}/%{_lib}/ pushd %{name}-%{version}-%{DATE}/libstdc++-v3/python  for i in `find . -name \*.py`; do   touch -r $i %{buildroot}%{_prefix}/share/gcc-%{gcc_major}/python/$i done touch -r hook.in %{buildroot}%{_datadir}/gdb/auto-load/%{_prefix}/%{_lib}/libstdc++*gdb.py popd  for f in `find %{buildroot}%{_prefix}/share/gcc-%{gcc_major}/python/ \        %{buildroot}%{_datadir}/gdb/auto-load/%{_prefix}/%{_lib}/ -name \*.py`; do   r=${f/$RPM_BUILD_ROOT/}   %{__python3} -c 'import py_compile; py_compile.compile("'$f'", dfile="'$r'")'   %{__python3} -O -c 'import py_compile; py_compile.compile("'$f'", dfile="'$r'")' done  rm -rf %{buildroot}%{_prefix}/%{_lib}/%{name} 

Теперь достаточно сказатьrpmbuildbblibgcc-i686.specгде-то в соседнем терминале, покаgccразвлекается своимtorture,ивуаля, наши32-битные пакеты у нас в кармане (в смысле, в $RPM_BUILD_ROOT/RPMS/i686).Мы копируем их в наш репозиторий, индексируем его, запускаемdnfmakecacherepogcc-9 &&dnfupdateи Нет, обновить компилятор всё ещё нельзя.

Stage3.Annobinиlibtool

Те, кто внимательно смотрит на параметры сборкина линуксах линеекRHELиCentOS, могли заметить, что по умолчанию вgccподключен плагинannobin.У этого плагина есть неприятная привычка привязываться к версии компилятора, поэтому его придется пересобрать. Детали в принципе изложены в самомannobin.specв комментариях, поэтому отметим только, что пересобрать его придётся минимум дважды: сперва, используя ещё системныйgcc8.3.1,поправить требование к версииgcc,чтобыgcc< %{gcc_next}превратилось вgcc<=%{gcc_next}, потом, уже заменивgcc,пересобрать заново, вернув требованиеgcc< %{gcc_next}ираскомментировавстроку%undefine_annotated_build иначе вообще ничего собираться не будет. Ну и для чистоты можно пересобрать в третий раз, вернув_annotated_buildна место, а предыдущие две версии пакетов (переходную и без аннотациибинарей) из репозитория удалить.

Остаетсяlibtool.Этот джентльмен тоже жёстко привязывается к версииgcc,но к счастью, зависимость эта односторонняя, поэтомуlibtoolможно просто удалить перед заменойgcc,затем собрать его заново новымgccи добавить соответствующий пакет в наш репозиторийgcc-9.

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

Хабравчане-девопсы, а какие у вас бывали нестандартные запросы от разработчиков?

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru