...

суббота, 26 сентября 2020 г.

Беспроводной DIY датчик температуры и влажности с e-paper дисплеем

Всем привет! Сегодня хочу рассказать читателям о своем DIY проекте датчика температуры и влажности с e-ink дисплеем. Это будет некая обзорная статья об этапах создания устройства, будет много картинок. Идея этого проекта родилась около двух лет назад, примерно тогда я увлекся беспроводными автономными устройствами. Целью проекта было создание небольшого девайса для знакомства и изучения дисплеев на электронных чернилах. Было решено на плату добавить датчик температуры, что бы можно было выводить какие то полезные данные на экран, ну и передавать данные далее в систему умного дома.


Первая версия устройства была сделана на микроконтроллере atmega328 и радио-модуле nRF24L01. Очень быстро стало понятно что для работы с e-ink дисплеем не хватает памяти, а энергопотребление устройства довольно большое.

Тест первой версии устройства


Используется датчик температуры и влажности SHT20. Питание от трех батареек CR2430 (6V) через step down converter.

Следующая версия устройства, была разработана на nRF52832. Для этой версии был выбран радио-модуль от компании Holyiot YJ-16048. Характеристики радио-чипа: ARM Cortex-M4F с ОЗУ 512кб 64кб. Встроенный приемопередатчик 2,4 ГГц, поддержка BLE, ANT, ESB (совместимо с nRF24L01). Подробнее об этой версии рассказано тут.

В этом варианте, проблем с хранением в памяти микроконтроллера большого количества данных — не было. Наличие в nRF52 режима DC-DC, для работы радио в режиме с оптимизацией питания (экономия до 40%), позволило сократить максимальное пиковое потребление до 7-8мА. Вторая версия датчика, как и первая планировалась как модуль для разработки, поэтому вопрос выбора корпуса не ставился.

Тест работы прототипа второй версии.


Так же используется датчик температуры и влажности SHT20. Питание от двух батареек CR2450 через step down конвертер TPS62745DSSR с малым энергопотреблением.

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

Естественно проект захотелось довести до состояния законченного устройства. Поэтому первым этапом, стал корпус. Для возможности установки в корпус был переработан дизайн платы. Модель корпуса была разработана в программе SolidWorks. Первые корпуса я печатал на бытовом SLA принтере Anycubic Foton. Плюсами была высокая точность печати и простота пост-обработки корпуса (полировка). Из минусов (на тот момент) печати корпуса полимерной смолой — была хрупкость. Не то чтобы напечатанная модель разваливалась в руках, но если собранное устройство (с батарейками) уронить, то скорее всего корпус треснет (что и случилось однажды).

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

Тест работы прототипа третьей версии


В этой версии был расширен список сенсоров. Помимо SHT20, ПО может работать и с датчиками si7021, HTU21D, а так же с BME280 (отдельная версия платы).

Начиная с этой версии, устройство может работать от одной батарейки. Работа через step down конвертер или напрямую от батареек, устанавливается перемычками. Так же, с помощью перемычек, устанавливается последовательность подключения двух батареек: последовательное или параллельное. Плюс к этому, расширен список радио-модулей и разработаны версии плат под радио-модули EBYTE и MINEW.

Для работы в более экономичном режиме, была добавлена поддержка чипов nRF52810 и nRF52811, что позволило сократить потребление в спящем режиме до 1,7 — 2мкА.

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

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

В настоящий момент, разработаны 3 варианта корпуса, под разные батарейки. От самого тонкого, для батареек СК2430 до максимально прочного, под две батарейки CR2477. Все варианты моделей корпусов доступны на GitHub этого проекта.


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

В настоящий момент, можно настраивать:

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

Тест работы обновленной третьей версии.


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

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

Информацию по данному проекту можно найти на GitHub. Проект открытый, на гитхаб доступы файлы для изготовления плат, схемы, модели корпусов и программный код.


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

Если вам интересно все что связано с DIY, вы являетесть DIY разработчиком или хотите только начать, вам интересно использование DIY девайсов приглашаю всех заинтересованных в телеграм чат — DIYDEV

Всем, кто хочет делать устройства, начать строить автоматизацию своего дома, я предлагаю познакомиться с простым в освоении протоколом Mysensors — телеграм-чат MySensors

А тем кто ищет достаточно взрослые решения для домашней автоматизации приглашаю в телеграм-чат Open Thread. (что такое Thread?)

Всем, как всегда добра!

Let's block ads! (Why?)

[Перевод] Многие дедлайны придумывают специально с целью заставить инженеров работать бесплатно

Работа инженера — сплошное разочарование. Возможно, потому что у нас нет власти, а менеджеры сбрасывают на инженеров все проблемы и ожидают, что они будут решены к вчерашнему дню.

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

Вот общий сценарий, который разыгрывается между инженером и его боссом, инженером-менеджером. Менеджер спрашивает, сколько времени займёт выполнение новой задачи. Бывает, что инженер не делал эту задачу раньше, поэтому честно отвечает, что понятия не имеет. Менеджер не принимает такой ответ — и снова спрашивает. Тогда инженер даёт оценку практически наугад, а босс отвечает: «Это слишком долго». Даже если инженер знает, сколько времени займёт выполнение задачи и даёт реалистичную оценку, менеджер часто отвечает: «Это слишком долго. У тебя есть время до пятницы». Когда инженер спрашивает, как давно стало известно об этой задаче, босс отвечает, что месяц назад. Когда инженер спрашивает, почему он не сказал ему об этом месяц назад, тот просто смотрит на инженера, как будто не понимает вопроса.
Часто менеджер ставит невозможный дедлайн, например, три дня, чтобы решить проблему, которая, вероятно, займёт месяц. Это означает, что у инженера два варианта. Он может сделать некачественную (то есть паршивую) работу. Или может вернуться через три дня и сказать боссу, что работа не закончена. Очень часто, если он выбирает первый вариант, все счастливы, что есть какой-то результат, даже если это полный мусор, который абсолютно ни на что не годен. Если инженер возвращается через три дня и говорит менеджеру, что работа не завершена, его босс спрашивает, почему. Тот факт, что времени было недостаточно, не является приемлемым ответом. Но если работа всё же должна быть выполнена, инженеру дают больше времени. Подозреваю, что если работа изначально не была очень важной, босс просто говорит, что время истекло и нужно идти делать что-то другое.

Мне кажется, что такое взаимодействие между менеджером и инженером — ни что иное, как игра. Либо для менеджера, либо со стороны компании. В первом случае это может быть демонстрация власти, а во втором — реализация стратегии увеличения прибыли компании. Другими словами, если босс не совсем глуп (как иногда кажется), то он понимает, что инженер не может выполнить за три дня работу, которая занимает месяц. Но он играет по правилам компании: она хочет, чтобы инженер делал неоплачиваемую сверхурочную работу столько, сколько способен выдержать. Вот почему так много инженеров в некоторых компаниях работают по 70 часов в неделю.

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

Вы можете спросить, разве это законно? Да, это законно в Соединенных Штатах, поскольку инженеры получают фиксированную зарплату, а не почасовую оплату. Работнику выдают одинаковую сумму каждую неделю независимо от того, сколько часов он фактически работает. Почему это законно? Вероятно, это связано с тем, что крупные ИТ-компании могут позволить себе нанимать лоббистов, а инженеры — нет.

Для Соединенных Штатов это означает, что многие инженеры перегружены работой и производят мусор. Когда ваш новый ноутбук умирает через шесть месяцев или в новом американском автомобиле через год взрывается прокладка головки цилиндра, причина может быть в этом. Жадные и эгоистичные компании заставляют врать и своих менеджеров, и инженеров. Они вынуждены говорить, что работа выполнена, когда она не выполнена, чтобы компания получила больше прибыли. Похоже, топ-менеджеров проблема не волнует. Вероятно, отчасти это объясняется тем, что большинство из них — социопаты и психопаты. К сожалению, многие из наших компаний, по-видимому, стали оруэлловскими машинами, которые привели этих людей к власти, а оказавшись там, они порождают полный хаос для всех нас.

Let's block ads! (Why?)

Стоимость IT-компаний США превысила капитализацию всего фондового рынка Евросоюза

Аналитики Bank of America подсчитали капитализацию американского технологического сектора и сравнили ее с показателями фондового рынка Европы. В результате оказалось, что стоимость IT-компаний США на $0,2 трлн превышает весь фондовый рынок ЕС.

Что случилось

Эксперты подразделения  Bank of America Global Research опубликовали новое исследование фондовых рынков США и Европы. Согласно полученным данным,  на конец августа 2020 года капитализация американского сектора высоких технологий превышала $9 трлн. При этом капитализация всего фондового рынка Европы, включая Великобританию и Швейцарию составила $8,9 трлн.

В 2007 году же IT-сектор США в четыре раза уступал по объемам капитализации рынку акций Евросоюза.

Почему растут в цене IT-компании

В последние годы рынок высоких технологий США и так развивался достаточно бурно, но глобальная пандемия коронавируса в целом еще больше способствовала повышению показателей. Так в период с января 2020 года акции Apple выросли на 66%, Amazon — на 80%, Microsoft — на 42%, Alphabet (материнская компания Google) — на 20%, соцсети Facebook — на 40%. Из этих компаний только Facebook не преодолела капитализацию в $1 трлн.

В свою очередь, рост технологических акций «вытягивает» за собой и целые индексы, в которые они входят – например, NASDAQ Composite в 2020 году установил уже несколько исторических максимумов роста. С января он вырос с 9000 до 11 695 пунктов к концу августа. Технологический сектор индекса S&P 500 за тот же период вырос на 35%.

В Европе меньше успешных технологических компаний с огромной капитализацией, и в том числе поэтому европейские индексы показывают не столь впечатляющие результаты. Так индекс европейских голубых фишек  Euro Stoxx 50 по сравнению с началом года упал на 11%, а британский FTSE 100 обвалился на 20% по сравнению с январем.

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

Читайте обзоры, аналитику рынков и инвестидеи в Telegram-канале ITI Capital

Полезные ссылки по теме инвестиций и биржевой торговли:

Let's block ads! (Why?)

Microsoft: HoloLens 2 помогает строить космический корабль NASA Orion

Американская военно-промышленная корпорация Lockheed Martin использует гарнитуры смешанной реальности HoloLens 2 в ходе производства космического корабля Orion. Об этом Microsoft сообщает в своём блоге.

Космический корабль Orion станет частью программы Artemis II — пилотируемой миссии с экипажем из четырёх человек, целью которой станет облет Луны. HoloLens 2 помогает инженерам при сборке Orion.

Сотрудники впервые начали применять гарнитуры HoloLens на производстве в 2017 году. Гарнитура генерирует голографические инструкции и карты на поверхностях корабля. 

«Инженеры могут видеть голограммы, смоделированные в специальной программе Scope AR, которые накладываются на элементы, над которыми они работают. Каждая деталь модели снабжена комментарием о том, как ее следует устанавливать, а информация о том, как следует закручивать болты, выводится рядом с соответствующим отверстием. Также для каждого инженера определенным цветом подсвечиваются только те детали, которые соответствуют его специализации».

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

«Инженерам не приходится возвращаться к экрану компьютера или бумажным эскизам во время своей работы, — приводит Microsoft комментарий Шелли Петерсон, главный исследователь Lockheed Martin по дополненной и смешанной реальности. — Они могут надеть устройство, включить его, и на нём будет отображаться весь контент, необходимый для выполнения задачи».

В ходе некоторых работ, требующих большого количества точных измерений вручную — например, при маркировке мест для креплений — голографические инструкции позволяли выполнять эти повторяющиеся задачи на 90% быстрее. Применение HoloLens 2 также «почти полностью устранило ошибки в ходе сборки», и, по словам Петерсон, у компании «не было запросов на доработку или исправление задач», выполненных с помощью HoloLens.

«Тот факт, что у нас не было ошибок во всех этих действиях, феноменален, — заявила Петерсон. — Обычно, когда мы рассматриваем возможность внедрения новых технологий, мы задаёмся вопросом, что они дадут нам — качество, скорость или дешевизну производства. В большинстве случаев мы можем получить только два желаемых пункта из трёх, что вынуждает нас идти на компромиссы. HoloLens 2 позволяет выполнить все три, что довольно уникально».

Lockheed Martin планирует и дальше использовать гарнитуру. Петерсон сообщила The Register, что HoloLens 2 будет применяться «при производстве многих космических аппаратов», включая спутники GPS, а также кораблей для будущих миссий Artemis. Компания также предусматривает, что гарнитура, возможно, будет полезна в космосе. Она позволит уменьшить потребность в компьютерах и бумажных документах.

В сентябре Microsoft объявила о запуске продаж гарнитур смешанной реальности HoloLens 2 для рядовых потребителей. Ранее устройство было доступно только корпоративным клиентам. Цена HoloLens 2 в розницу осталась такой же, как для компаний — $3500.

Let's block ads! (Why?)

Per aspera ad astra, или как я строил ракету. Часть 2. Собираем альтиметр на STM32 и BMP280

Всем привет! 

В предыдущей части я остановился на том, что мои ракеты удачно взлетели и приземлились, а на одной даже был установлен альтиметр. В этой статье я и расскажу о том как сделать простой высотомер на основе STM32 Nucleo L031K6 и датчика давления BMP 280 , который к тому же хранит все данные во Flash памяти.


Основные требования к альтиметру:
  1. Высокая скорость считывания высоты, так как ракета в апогее находится не слишком долго, а я хотел узнать именно максимальную высоту;
  2. Низкое энергопотребление, чтобы не ставить большой аккумулятор;
  3. Небольшие размеры всей конструкции.

Исходя из них в качестве микроконтроллера взял STM32 Nucleo L031K6 (высокая скорость работы, низкое потребление тока, малый размер). Высоту решил измерять с помощью барометра BMP280 (те же резоны, что и у МК). Также добавил кнопку, при нажатии которой начиналась запись высоты. Ну и питала всю электронику батарейка CR2032, подключенная через адаптер. В итоге получилась такая схема:
Использованные модули

STM32 Nucleo L031K6


BMP280


Адаптер для CR2032


Код вы можете найти на моем гитхабе . Пины STM32 были сконфигурированы в CubeMX под IAR. Для работы с BMP280 использовал вот эту библиотеку, добавил в нее функцию расчета высоты над уровнем моря с помощью барометрической формулы и инициализацию датчика с нужными мне параметрами частоты считывания, фильтрации и тд. Так как я хотел измерить высоту полета относительно земли, мне нужно было сначала вычислить высоту над уровнем моря в моей местности, взять ее за «ноль» и относительно нее измерять высоту полета. Частота измерений равнялась 10 Гц.

Запись во Flash память происходила следующим образом так:

Организация памяти в STM32 L031K6


  • Для всех измерений выделил 8 Кбайт с 0x08006000 по 0x08007FFF адреса
  • На одно измерение выделил 2 байта
  • Во Flash записывал по 4 байта, то есть сразу два измерения
  • Максимальное количество измерений — 4096, этого хватало на запись примерно 7-ми минут полета
  • Высоту записывал в сантиметрах для большей точности

А происходила запись следующим образом:
  1. Если итератор записи четный, то в переменную с данными для записи во Flash сохраняем текущую высоту в младшую половину слова;
  2. Если итератор записи нечетный, то в переменную с данными для записи во Flash добавляем текущую высоту в старшую половину слова и сохраняем эту переменную в ячейку Flash

В итоге алгоритм работы программы следующий:
  1. После включения 5 секунд ждем нажатия кнопки для старта измерений высоты.
  2. Если кнопка не была нажата, то зажигаем встроенный светодиод и начинаем передачу по UART данных о высоте, записанных во Flash памяти
  3. Если кнопка была нажата, то два раза моргаем встроенным светодиодом и вычисляем высоту местности.
  4. После вычисления «нуля» два раза моргаем встроенным светодиодом и записываем во Flash-память высоту ракеты над землей.
  5. Когда выполнили передачу по UART или завершили измерения высоты, бесконечно моргаем встроенным светодиодом;
  6. Ждем пока нас найдут люди и выключат.

При питании STM’ки от CR2032 через пин 3.3V обнаружил, что код не работает. Проблема была в том, что при подаче питания через эту ногу необходимо было отпаять SB9 (расположен рядом с выводами RX и TX на обратной стороне МК)  иначе плата постоянно перезагружалась.

Теперь необходимо было проверить точность работы альтиметра. Взяв рулетку, я стал поднимать альтиметр на разные высоты и смотреть, что он измеряет. Результаты тестов лежат в соответствующей папке на гитхабе. В текстовых файлах — сырые данные с STM’ки, а в Excel’евских таблицах находятся красивые графики всех тестов. Точность соответствовала заявленной — ± 10см. Следует помнить, что высоту я измерял в сантиметрах, поэтому в таблице такие большие числа. 


Так как во время приземления ракета может сильно ударится о землю, необходимо было хорошо зафиксировать всю электронику, чтобы при тряске не отваливались проводки, или, того хуже, сами модули. Альтиметр разместил в головном обтекателе (места там было достаточно, и стабильности за счет смещения центра тяжести к головному обтекателю прибавилось) в 3D-печатном креплении. STM’ка стояла вертикально, BMP280 контактами вверх и под крепление приклеил адаптер для CR2032. Из-за того, что он не помещался в корпус ракеты, пришлось немного сточить контакты минуса. Рядом с контактами в боковой стенке 3D-печатного крепления проточил вертикальную канавку, чтобы протянуть через нее минус от CR2032, а под плюсом просверлил отверстие и пустил провод через него. Думал крепить альтиметр к головному обтекателю с помощью самореза, поэтому в корпусе есть отверстие, но потом от этой идеи отказался.


Модель крепления, напечатанного на 3D-принтере

Собранный блок альтиметра

Вид сверху


Вид снизу


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

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


Собранный альтиметр. Вид спереди  


Вид сзади. Видна резинка, соединяющая альтиметр с ракетой

Альтиметр был готов! Теперь предстояло его испытать, а это значит, что я снова отправился на полигон!


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

В итоге график получился таким:


По горизонтали — номер измерения. Каждые 10 измерений — 1 секунда. По вертикали — высота в сантиметрах

Ракета взлетела на 15м, затем устремилась в землю. После прохождения апогея через 1 секунду началась какая-то аномалия: после значения 12м почему-то показания упали до -8м. Это произошло в момент второго запуска двигателя (которого не должно было быть), так что не исключаю, что неисправный двигатель как-то повлиял на альтиметр. Во всех остальных тестах он работал отлично, так что это была проблема явно не в электронике. В общем, те испытания альтиметра были успешными лишь наполовину, так как во вторую половину полета произошла аномалия. Сам график вы можете найти на гитхабе, он называется rocket_flight_fall_test.

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


По горизонтали — номер измерения. Каждые 10 измерений — 1 секунда. По вертикали — высота в сантиметрах

Ракета поднялась на 150м и успешно приземлилась. Таким образом это испытание было полностью успешным. Я удостоверился в том, что альтиметр работает и приступил к разработке новой бортовой аппаратуры.


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

Спасибо за внимание!

Let's block ads! (Why?)

[Перевод] Кунг-фу стиля Linux: удобная работа с файлами по SSH

Если у вас имеется больше одного Linux-компьютера, то вы, вероятно, постоянно пользуетесь ssh. Это — отличный инструмент, но мне всегда казалась в нём странной одна деталь. Несмотря на то, что ssh-соединения позволяют передавать файлы с применением scp и sftp, у нас нет возможности перемещать файлы между локальной и удалённой системой, не запуская программу на локальном хосте, или не подключаясь к локальной машине с удалённой.

Последнее — это настоящая проблема, так как к серверам часто подключаются, находясь в это время за файрволом или за NAT-маршрутизатором, то есть, не имея постоянного IP-адреса. В результате сервер, в любом случае, не сможет подключиться к локальной системе, с которой раньше к нему обращались. Если бы в ssh-сессии можно было бы просто взять локальный или удалённый файл и передать его туда, куда нужно, это было бы очень удобно.

Я, на самом деле, не вполне достиг этой цели, но подобрался к её достижению очень близко. В этом материале я расскажу вам о скрипте, который позволяет монтировать удалённые директории на локальном компьютере. На локальной машине надо будет установить sshfs, но на удалённой, на которую вы, возможно, не можете устанавливать программы, ничего менять не придётся. Если же потратить на настройку систем некоторое время, и если на клиентском компьютере имеется работающий ssh-сервер, то можно будет ещё и монтировать локальные директории на удалённых системах. При этом не придётся беспокоиться о блокировке IP-адресов или портов. Фактически, если вы способны подключиться к удалённой машине, это означает, что вам удастся и то, о чём я хочу рассказать.

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

Нет ли тут подвоха?


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

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

Пара слов о sshfs


Утилита sshfs даёт возможность работать с файловой системой в пользовательском пространстве (filesystem in userspace, FUSE). То есть, речь идёт о том, что в пользовательском пространстве имеется слой, находящийся поверх базовой файловой системы. В данном случае такой файловой системой является ssh-сервер, поддерживающий sftp. Это позволяет работать с файлами, находящимися на удалённой системе, воспринимая их так, будто они находятся в реальной файловой системе на локальном компьютере. Если вы ещё не пробовали sshfs — попробуйте. Работает эта утилита очень хорошо.

Предположим, вы вошли на компьютер myserver и выполнили с локальной машины следующую команду: 

sshfs myserver:/home/admin ~/mounts/myserver

Это приведёт к тому, что директория удалённого компьютера /home/admin будет доступна в локальной системе по пути ~/mounts/myserver.

При использовании sshfs можно пользоваться различными опциями. Например, можно сделать так, чтобы после потери соединения осуществлялось бы повторное подключение. Подробности о sshfs ищите в справке.

Так как sshfs использует удалённо смонтированную версию файла, то все изменения, внесённые в файл, сохраняются на удалённой машине. А после того, как sshfs-соединение закрывают, на локальной компьютере ничего не остаётся. Сейчас мы это исправим.

Предварительная подготовка


Прежде чем я перейду к описанию скрипта, о котором было упомянуто выше, хочу рассказать о некоторых настройках клиента, которые вы, если хотите, можете доработать под себя. Так, тут я создаю директорию ~/remote, а в ней создаю поддиректории для каждого удалённого компьютера. Например — это могут быть директории ~/remote/fileserver и ~/remote/lab.

Скрипт называется sshmount. Он принимает те же аргументы, что и ssh. Для упрощения работы со скриптом сведения об удалённом хосте стоит хранить в файле ~/.ssh/config, что позволит пользоваться простыми и короткими именами хостов. Например, сведения о компьютере lab могут выглядеть так:

Host lab
Hostname lab.wd5gnr-dyn.net
Port 444
User alw
ForwardX11 yes
ForwardX11Trusted yes
TCPKeepAlive yes
Compression yes
ControlMaster auto
ControlPath ~/.ssh/master-%r@%h:%p

На самом деле, острой необходимости в этом нет, но при таком подходе в вашем распоряжении будет приятно выглядящая директория ~/remote/lab, а не сложная конструкция вида ~/remote/alw@lab.wd5gnr-dyn.net:444. Во всех этих параметрах нет ничего таинственного. Единственно, хочу обратить ваше внимание на то, что ControlMaster и ControlPath позволяют организовать более быструю работу с соединениями, что, в нашем случае, очень важно.

Кроме того, можно организовать автоматическое подключение к удалённой системе с использованием сертификата. Вот материал об этом.

Скрипт


Наш скрипт можно использовать двумя способами. Так, если его вызывают через ссылку к sshunmount, то он размонтирует файловую систему, связанную с указанным удалённым хостом. Если его вызывают иначе (обычно — как sshmount), то он выполняет следующие три действия:
  1. Он проверяет, есть ли в директории ~/remote поддиректория, имя которой совпадает с именем хоста (например — lab). Если такой директории нет — он выводит сообщение об ошибке и продолжает работу.
  2. Если такая директория существует — скрипт просматривает список смонтированных файловых систем на тот случай, если нужная файловая система уже смонтирована. Если это так — он продолжает работу.
  3. Если директория не смонтирована — он вызывает sshfs и продолжает работу.

Этот скрипт можно найти на GitHub. А вот его код, из которого убраны некоторые комментарии:
#!/bin/bash
 
if [ "$1" == "" ]
then
echo Usage: sshmount host [ssh_options] - Mount remote home folder on ~/remote/host and log in
echo or: sshunmount host - Remove mount from ~/remote/host
exit 1
fi
 
# Если вызван как sshunmount...
if [ $(basename "$0") == sshunmount ]
then
echo Unmounting... 1>&2
fusermount -u "$HOME/remote/$1"
exit $?
fi
 
# Обычный вызов...
if [ -d "$HOME/remote/$1" ] # Существует ли директория?
then
if mount | grep "$HOME/remote/$1 " # Файловая система уже смонтирована?
then
echo Already mounted 1>&2
else
sshfs -o reconnect $1: $HOME/remote/$1 # mount
fi
else
echo No remote directory ~/remote/$1 exists 1>&2
fi
ssh $@ # выполнить вход

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

Решаем обратную задачу


Если вы хотите поэкспериментировать с монтированием на сервере папок, находящихся на локальной машине, то нужно будет, чтобы на локальной машине работал бы ssh-сервер. Конечно, если ваш локальный компьютер видим и доступен серверу, то это просто: достаточно запустить на удалённом компьютере sshfs и смонтировать на нём папку с локального компьютера. Но во многих случаях у нас нет доступа к локальной системе, которая может быть расположена за файрволами или маршрутизаторами. Особенно это актуально в том случае, если роль локальной системы выполняет ноутбук, который может подключаться к сети из разных мест.

Но нашу задачу, несмотря на все эти сложности, всё же, можно решить. Её решение состоит из двух частей.

Во-первых — надо, при вызове sshmount, указать дополнительный аргумент (файл можно отредактировать в том случае, если вам нужно будет постоянно выполнять подобную команду):

sshmount MyServer -R 5555:localhost:22

Во-вторых — после подключения к хосту нужно выполнить такую команду:
sshfs -p 5555 localhost:/home/me ~/local

Благодаря опции -R на удалённой машине создаётся сокет на порте 5555 (который, естественно, должен быть свободным) и осуществляется его связь с портом 22 локальной машины. Если исходить из предположения о том, что ssh-сервер работает на порте 22, то это позволит серверу подключиться к локальной машине по тому же соединению. Ему не нужно знать наш IP-адрес или иметь открытый порт.

Команда sshfs, которую можно выполнять при запуске системы, связывает локальную директорию /home/me с директорией ~/local удалённого сервера. Если, вдобавок, войти в систему локально, то можно будет взглянуть на переменные окружения, имена которых начинаются с SSH_, и узнать подробности о SSH-соединении. Например, это переменные $SSH_CLIENT и $SSH_TTY.

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

Итоги


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

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

Чем вы пользуетесь для работы с файлами удалённых Linux-систем?

Let's block ads! (Why?)

Microsoft начала внутреннее расследование утечки исходных кодов Windows XP и Windows Server 2003

25 сентября 2020 года издание Verge сообщило, что Microsoft начала внутреннее расследование по поводу утечки исходных кодов Windows XP и Windows Server 2003.
Эксперты Verge и независимые исследователи проанализировали утекшие материалы по Windows XP, Windows Server 2003 и Windows 2000 и подтвердили их подлинность.

Один из специалистов по Windows обнаружил в утечке ключи подписи корневого сертификата пользователя NetMeeting.


По данным портала ZDNet, данная утечка исходных кодов произошла от одной из компаний или исследовательских организаций правительств некоторых стран, которые ранее получили доступ от Microsoft к этой информации с целью аудита безопасности. Программа по передаче кодов и технического контента Microsoft называется Government Security Program (GSP). К ней имеют доступ специалисты по безопасности из 45 стран, а также 90 различных агентств.

Ранее 24 сентября на портале 4chan был опубликован торрент-файл размером 42,9 Гб, в составе которого находились исходные коды Windows XP и Windows Server 2003.

6 августа 2020 года разработчик и IT-консультант из Швеции Тилли Коттманн (Tillie Kottmann) опубликовал в сети ссылки на файлообменный сервис MEGA и магнет ссылку на торрент с 20 ГБ исходных кодов прошивок процессоров и внутренней документации компании Intel, включая отладочные инструменты, схемы, драйверы, обучающие видео. В настоящее время Intel занимается расследованием этого инцидента. Intel рассказала, что утечка, скорее всего, произошла из Центра ресурсов и проектирования (Intel Resource and Design Center).

Let's block ads! (Why?)

[Перевод] Предком всех автомобилей с ДВС были гидроциклы, работавшие на мхе. Их создал тот же человек, что изобрел фотографию

image

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

Первый двигатель внутреннего сгорания в 1806 изобрели братья Ньепсы: Нисефор (именно он позднее стал изобретателем фотографии) и Клод. Свое изобретение они назвали пиреолофор (pyreolophore, от латинского pyr – огонь, eolo – ветер, phore – перевозка или производство).

В качестве топлива для двигателя использовалась смесь ликоподиевого порошка (споры мха, взрывающиеся при рассеивании), угольной пыли и смолы.
В своем патенте 1807 года братья описывали свое изобретение как «новую машину, принцип работы которой заключается в расширении воздуха под действием огня».

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

image

Карно описал двигатель в своей книге под названием «Размышления о движущей силе огня и о машинах, способных развивать эту силу». Судя по отрывкам вроде того, что приведен ниже, книга очень увлекательная:

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

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

image

Похоже, эта лодка была первым транспортным средством, приводимым в движение двигателем внутреннего сгорания. Впрочем, автомобиль De Rivaz с водородным двигателем появился в следующем, 1808 году (хотя некоторые источники указывают на 1807 – я придерживаюсь этой же позиции).

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

Впервые предложив эту идею в июне 1816 года, Нисефор написал брату об использовании керосина в качестве топлива, а в июле следующего года, после долгих испытаний, проведенных Клодом, была предложена идея впрыска топлива:

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

Этот «удовлетворяющий результат» используется в двигателях и по сей день. Некоторые из их испытаний были удивительно просты – они пропускали топливо через трубки, используя языки в качестве клапанов:

«Та часть, через которую он должен был продуть, имела длину около 66 см, а та, через которую протекало масло, — около 33 см». Выхлоп был скошен, как и в предыдущем эксперименте.

Эксперимент был исключительно успешен: «Пламя, по сравнению с небольшим количеством используемого масла, было огромным, интенсивным, появлялось мгновенно, а детонация была похожа на взрыв ликоподия», – сказал Нисефор, и добавил: «Результаты, которые я только что получил, возродили мой дух и полностью удовлетворили меня»

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

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

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

Затем он промывал пластинку раствором из масла лаванды и керосина (белой нефти), проявляя на ней постоянное изображение.

image

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

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


image

Вакансии
НПП ИТЭЛМА всегда рада молодым специалистам, выпускникам автомобильных, технических вузов, а также физико-математических факультетов любых других высших учебных заведений.

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

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

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



О компании ИТЭЛМА
Мы большая компания-разработчик automotive компонентов. В компании трудится около 2500 сотрудников, в том числе 650 инженеров.

Мы, пожалуй, самый сильный в России центр компетенций по разработке автомобильной электроники. Сейчас активно растем и открыли много вакансий (порядка 30, в том числе в регионах), таких как инженер-программист, инженер-конструктор, ведущий инженер-разработчик (DSP-программист) и др.

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


Список полезных публикаций на Хабре

Let's block ads! (Why?)

Ultimate Guide по карьере в AI: как выбрать специальность, прокачаться и найти классную работу

3 августа в наших соцсетях выступал Сергей Ширкин, специалист по ML и искусственному интеллекту.

Сергей занимался автоматизацией финансовых технологий и базами данных в «Сбербанке» и «Росбанке», построением финансовых моделей на основе машинного обучения и аналитической деятельностью в компании Equifax. Прогнозирует телесмотрение с применением методов искусственного интеллекта в Dentsu Aegis Network Russia. Приглашённый преподаватель ВШЭ (магистерская программа «Коммуникации, основанные на данных»).

Также Сергей исследует квантовые вычисления в приложении к ИИ и машинному обучению. Он стоит у истоков факультетов Искусственного интеллекта, Аналитики Big Data и Data Engineering онлайн-университета Geek University, на которых работает деканом и преподавателем.

Делимся с вами расшифровкой эфира и записью.

***

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

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

Порекомендуйте материалы по самостоятельному погружению в ИИ?


Если вы совсем новичок, то лучше начать с изучения Python. Быстрый способ для этого, как я видел на примере других новичков – это сайт PythonTutor.ru. Там надо изучить теорию и порешать задачи – хотя бы процентов 70. Задачи могут показаться сложными, если вы совсем не программировали до этого.

Следующий шаг – язык запросов SQL, и здесь поможет сайт SQL-EX.ru: там есть упражнения по SQL. Они организованы по этапам: обучающий этап, этап для получения рейтинга – можно занять определенное место в рейтинге. Здесь вы научитесь работать с базами данных. Параллельно там есть обучающие материалы от автора Моисеенко, и их довольно легко изучить.

Потом потребуется изучить само машинное обучение. Различные алгоритмы, начиная с линейной регрессии, логистической регрессии, вплоть до градиентного бустинга. Здесь очень много материалов. Потом можно перейти к нейронным сетям – для компьютерного зрения, для NLP; вы изучите сверточные, рекуррентные нейронные сети, и самые современные – трансформеры, Берт и т.д.

Расскажу про развитие ИИ. Если посмотреть на историю этого развития до 2010, то она достаточно скудна: были, конечно, некоторые великие свершения в ИИ и в смежных областях – в больших данных, например, и были готовы многие математические алгоритмы. Но для ИИ было недостаточно вычислительной мощности и данных. Начиная с 2010 года – скорее, с 2012 – пошел бурный рост ИИ. В 2012 году на одном из соревнований нейросеть победила классические алгоритмы машинного зрения и научилась распознавать около 1000 классов изображений.

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

Сейчас компьютерное зрение достигло больших успехов. Параллельно развивается обработка естественного языка – NLP. С появлением модели GPT-3, которые создала компания OpenAI пару месяцев назад, нейросеть научилась генерировать текст (а также музыку и другие последовательности). Это один из важных шагов в NLP – скорее всего, в этом десятилетии она достигнет расцвета. Появятся чат-боты, которые смогут полноценно поддерживать диалог с человеком.

SQL и Python немного. После курсов по data science, без опыта, можно сразу устроиться data scientist, или сначала надо поработать аналитиком БД?


Сейчас попасть в data science сложнее, чем 5 лет назад. Тогда можно было принять участие в каком-нибудь конкурсе на Kaggle и занять место – не обязательно самое первое, например, в первых 10% — в каком-нибудь интересном соревновании, не обучающего уровня. После этого можно было уже ходить по компаниям, отвечать на несложные вопросы по машинному обучению, и такого человека могли взять. Специалистов было мало.

Сейчас все гораздо сложнее, поэтому иногда не получается сразу после того, как вы изучили машинное обучение и математику, попасть на вакансию своей мечты – специалиста по ИИ или data scientist.

Хороший путь – сначала поработать с данными, аналитиком баз данных или аналитиком данных. Факт в том, что вы должны научиться предварительно обрабатывать, чистить данные, применять статистику. Это могут быть технологии БД, Python в том числе. Когда вы наберетесь опыта, появится у вас бэкграунд, то вы сможете, используя свои знания по библиотекам data science в Python – Pandas, NumPy, SKLearn, устроиться на вакансию, связанную с ИИ или data science.

В чем отличия специалистов от ИИ от data scientists?


Нужен ли C++ специалисту по ИИ? Что посоветуете изучить для того, чтобы стать спецом по компьютерному зрению?

Сейчас в вакансиях западных компаний появилось разделение: помимо data scientist есть отдельные вакансии для специалистов по ИИ. Раньше подразумевалось, что data scientist – это человек, который занимается и анализом табличных данных, и задачами компьютерного зрения, и задачами NLP. Также существовала вакансия аналитика данных – она оплачивалась меньше, хотя и была также довольно престижной; такой человек должен был анализировать данные, но не слишком углубляться в ИИ, связанный с речью, текстом и изображениями, работая в основном с табличными данными. Затем произошло смешение вакансий: в Долине всех аналитиков данных стали называть data scientist, включая и тех, кто работает только с табличными данными, и тех, кто работает с NLP и компьютерным зрением. И одновременно, чуть позже, начали выделять отдельно специалиста по ИИ. В российских компаниях обычно такого разделениям нет, хотя иногда бывают специализированные вакансии – например, «инженер NLP/компьютерного зрения». Data scientist’у желательно понемногу уметь все.

Насчет С++: самый основной – это Python. То есть, если вы работаете специалистом по ИИ, вы должны использовать TensorFLow, Keras или PyTorch – он сейчас на первом месте. Но если вы пишете более низкоуровневые программы – например, если вакансия связана с робомобилями, то часто будет требоваться код на C++. Python не всегда быстро работает. Библиотеки для машинного обучения обычно написаны на C++, но иногда нужно всю программу написать на C++: помимо самих моделей может работать логика (if-else и т.д.), и на С++ это работает быстрее. Конечно, сразу приходить на такую вакансию сложно, и лучше сперва поработать на такой, где будет достаточно Python – например, там, где идет аналитика соцсетей с анализом изображений, без потребности в быстрой обработке.

Для того, чтобы стать спецом, надо научиться работать с библиотеками для нейронных сетей, изучить библиотеку OpenCV для Python – она также есть для C++. Так вы получите инструментарий. Еще желательно уметь работать с библиотекой NumPy, понимать саму математику анализа изображений – то есть, разбираться в линейной алгебре и матанализе, также – знать архитектуру нейронных сетей. И так далее.

Почему на собеседованиях в ML задают вопросы о том, как разруливать конфликты в hash-таблице?


Почему это – маркер при приеме на работу, если это можно загуглить по ходу?

Не в каждой вакансии это спрашивают. Если вы идете на аналитику табличных данных, то вряд ли у вас это спросят. Точно спросят, если вы претендуете на место ML-инженера: то есть, вы не просто создаете модели ML, вы их еще и внедряете, и вам надо знать алгоритмы и структуры данных. А если вы разрабатываете что-то наподобие робомобиля, то – тем более: там придется писать код высокого и низкого уровня, и это знание обязательно. А иногда такое знание требуется и в анализе табличных данных – допустим, вы пишете модуль для этого на C++.
Если вы пока не готовы на такие вакансии претендовать, можно пройти побольше собеседований. Допустим, если вы пойдете устраиваться data scientist’ом в банк, то там подобных вопросов будет меньше.

Пишу на Python 10 лет, но без высшего образования. Насколько сложно входить в сферу ИИ без вышмата?


Высшая математика нужна. Придется пройти курсы или изучить литературу, и это будет долгий процесс. Вам будет нужна подготовка по линейной алгебре, математическому анализу, теории вероятности и математической статистике. Обычной школьной программы явно не хватит для того, чтобы заниматься ИИ; конечно, программы бывают разные – в некоторых школах и в 10-м классе проходятся темы из ВУЗов, но такое редко бывает.

Pandas, SKLearn, Catboost, Seaborn, результаты в тренировочных соревнованиях Kaggle – 3% и 13%. Нужно ли погружаться в DL, или уже можно искать работу?


По библиотекам уже все хорошо; у вас уже есть Pandas – библиотека для работы с табличными данными, и SKLearn – модели машинного обучения, и Catboost – градиентный бустинг, и Seaborn – для визуализации. Результаты 3% и 13% — значит, если это не учебные соревнования, то с такими результатами у вас уже должна быть какая-то медаль.

Deep Learning не всегда нужен. Вы можете уже пробовать искать работу, я думаю. Но, если вам нужна именно работа с DL, то нужно еще поучить нейронные сети.

Какой базовый набор книг нужно прочесть?


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

Насколько сейчас востребованы эти профессии? Будет ли много вакансий через 2 года?


Если вспомнить 2015-16 годы – тогда, например, на Headhunter было не больше 5-10 вакансий data scientist. То есть, был практически пустой рынок. Конечно, потом было переименование аналитиков в data scientist, но этого тоже было немного.

Сейчас одномоментно требуется несколько сотен, если смотреть по тому же сайту. Говорят, есть вакансии, которых там нет. Например, на ODS – OpenDataScience – если посмотреть, есть отдельный раздел вакансий. В целом, пока вакансии не кончаются – я думаю, через 2 года их будет только больше. Не только крупные компании этим занимаются: есть стартапы, мелкие компании; data scientist’ы сейчас требуются и в госучреждениях – например, в разных муниципальных департаментах, в налоговой службе и так далее.

В какой отрасли ИИ наиболее востребован?


Самое простое применение ИИ, где его явное применение может автоматизировать большое количество умственной работы специалистов – это финансовая сфера. Есть огромное количество банков. Каждому из них нужно, например, оценивать кредитоспособность заемщиков – то есть, определять по различных признакам, стоит ли выдавать кредит, не переоценивает ли человек свои силы и сможет ли вернуть кредит. Это самое очевидное использование ИИ.

Потом маркетинг, построение рекламных кампаний: то есть, когда нужно предсказывать, посмотрит ли человек рекламу (в Интернете, на ТВ и т.д.). Это тоже развитое направление, его невозможно не автоматизировать с помощью ИИ. Плюс, сейчас развивается роботизация: есть не только промышленные, но и бытовые роботы – робопылесосы и другие принадлежности для дома, которые тоже кто-то разрабатывает. Или различные приложения для смартфона – в общем, отраслей много, начиная от промышленности, медицины, ритейла, финансов, маркетинга и заканчивая развлечениями. Например, в играх тоже можно применить ИИ.

Сто ценится больше при приеме на работу в data science: знание математики, понимание работы конкретных алгоритмов, опыт работы?


За плечами техническая магистратура и год работы аналитиком данных в консалтинге.

У вас хороший бэкграунд – технический вуз, год работы аналитиком данных. Если вы уже изучили технологии и умеете программировать, то попасть в data science легко. Если вы работали а анализе БД и знаете SQL – это большой плюс, а если прибавить программирование и машинное обучение – это очень хороший набор.

Расскажу о том, как я строю модели машинного обучения на работе. Компания, в которой я работаю – это Dentsu Aegis, очень известная компания, особенно среди тех, кто работает в маркетинге. Это коммуникационная группа, входящая в топ-5 в мире; ее штаб находится в Токио, есть офисы в 145 странах. Российский филиал – Dentsu Aegis Network Russia. В России работает 25 лет и выступает пионером медиа-инноваций.

Я расскажу про тот участок, за который отвечаю как data scientist. Это как раз то применение, о котором я рассказывал как о наиболее очевидном в практическом применении. ИИ в маркетинге помогает автоматизировать многие задачи специалистов, и одна из них – прогнозирование просмотра различных видов контента различными целевыми аудиториями. Я расскажу подробнее про одну из своих непосредственных задач – прогнозирование телесмотрения.

Аудиторий может быть несколько сотен, и для того, чтобы их прогнозировать вручную, требовалась бы работа десятков специалистов. Это непомерно. Очень большое количество данных – до миллиардов строк в таблицах. Надо заботиться не только о том, чтобы построить модель машинного обучения, но и о том, чтобы она быстро работала. Для такой работа надо хорошо знать реляционные и нереляционные БД, работать с Linux, иметь навыки devops и вообще разбираться в архитектуре приложения, в IT-инфраструктуре компании, хорошо знать Python, возможно – C++.
Когда мы строим прогноз телепросмотров, мы применяем современные методы машинного обучения. Для табличных данных это градиентный бустинг и случайный лес. Если анализируется текст, мы применяем нейронные сети; помимо них – тематическое моделирование, TF-IDF и другие распространенные методы NLP.

Мы применяем градиентный бустинг, потому что, если мы прогнозируем с использованием табличных данных, то по работе с такими данными градиентный бустинг опережает все известные алгоритмы. В Kaggle, начиная с 2018 года, все основные достижения в соревнованиях с использованием табличных данных достигались именно с помощью градиентного бустинга. Большинство кегглеров тогда перешло на XGBoost – это была первая известная библиотека для градиентного бустинга, а позже многие освоили LightGBM от Microsoft или CatBoost от Yandex. Для задачи прогноза просмотров телепередач также хорошо подходит применение временных рядов, но такие методы не всегда хорошо работают – периодически появляются неожиданные события, на которые нужно вовремя реагировать или предвосхищать. Иногда встречаются большие аномальные периоды – от нескольких дней до месяцев: например, ЧМ по футболу в 2018 году сильно повлиял на просмотры. Карантин тоже стал аномальным периодом: люди начали проводить больше времени дома и больше смотреть ТВ. Это тоже надо как-то учитывать, предвосхищать. Вообще, этот период – это своеобразный вызов для машинного обучения и ИИ, потому что нужно постоянно осуществлять мониторинг моделей и контролировать их, чтобы они работали корректно. Помимо аномальных периодов на прогноз оказывают влияние праздники, погодные условия, изменения трендов в просмотрах конкретных передач и каналов. В итоге модели получаются достаточно сложными, потому что надо учесть все возможные варианты, учесть или предвосхитить аномалии и отклонения.

Естественно, модели не предоставлены сами себе – постоянно идет тестирование, тонкая настройка, мониторинг. Но не только модели важны: еще один важный этап – это создание признаков. Во-первых, это признаки, связанные со временем показа: время суток, день недели, сезон и т.д. Во-вторых, это признаки, связанные с контентом. При этом надо понимать, что, если передача идет ночью, то, какой бы ни был интересный контент, просмотров не будет больше, чем в праймтайм. Важность признаков может меняться, но разные аудитории выбирают разный контент. Это может зависеть от пола, возраста, социального положения.

Один из самых объемных по времени этапов работы с данными – это feature engineering: обработка или создание признаков. Для этой части data science нужен большой опыт: заранее известных рецептов либо нет, либо они слишком просты, и способы подготовки признаков приходится придумывать на ходу.

Иногда в данных встречаются курьезы: допустим, зритель включает ТВ вечером и засыпает. Получается так, как будто он всю ночь смотрел передачи. Это один из примеров шума в данных – вроде бы данные точные, а вроде бы и нет, и это нужно учиться угадывать, хотя это и сложно. Кроме того, ночью обычно показывается очень мало рекламы.

Когда мы строим модель, надо не просто сделать так, чтобы она работала, но и обеспечить тестирование и мониторинг. Для этого нам нужны метрики. Так как у нас задача регрессии, наш набор метрик будет отличаться от набора для классификации, например. Это среднеквадратичная ошибка и коэффициент детерминации – они все очень важны. Также есть метрики, которое приходится создавать самостоятельно для решения определенной бизнес-задачи – например, задачи оптимизации расходов на рекламную кампанию. В таком случае нам надо предсказывать не только телевизионный рейтинг, но и охват рекламной кампании; у нас работает не только машинное обучение, но и сложные статистические и эконометрические методы. Это тот случай, когда знаний машинного обучения оказывается недостаточно: здесь нужен матанализ, линейная алгебра, методы математической оптимизации. В отличие от обычных задач машинного обучения – регрессии, классификации, кластеризации – здесь приходится придумывать собственные методы, и одного программирования не хватит.

Хочу упомянуть программу Высшей школы экономики – «Коммуникации, основанные на данных». Приходилось по ходу работы помогать студентам на этой программе, они занимаются маркетингом и предметами, связанными с машинным обучением. Собственно, для чего машинное обучение и data science маркетологу? Раньше не предполагалось, что специалист такой области будет программировать и делать сложные модели, но сейчас это – навык, который дает преимущества на рынке труда. Если специалист, дополнительно к своей профессии, овладел data science, то он получает возможность либо поменять работу и стать data scientist’ом, либо продолжить развиваться в своей предметной сфере, но с большими конкурентными преимуществами. Знаток машинного обучения сможет делать более точные прогнозы, но для этого потребуется многое изучить.

Стоит ли обратить внимание на курс Data Science МФТИ/Yandex, или, возможно, посмотреть в сторону Udacity?


Я так понимаю, вы имеете ввиду курс от МФТИ/Yandex на Coursera. Udacity – это отдельная площадка для обучения; там не только data science, хотя для ИИ и data science и предназначена довольно большая часть курсов. Я рекомендую не зацикливаться на одном ресурсе, а попробовать пройти несколько курсов. Курсы не совпадают на 100%, вы всегда можете найти что-то новое, чего раньше не знали. Также новый курс можно использовать для повторения. Например, курсы на GeekBrains на наших факультетах ИИ, data engineering и аналитики big data. Так как я являюсь их деканом и преподавателем, я могу более подробно рассказать о них.

Курсы объединяются в факультеты – например, на факультете искусственного интеллекта есть 17 курсов, плюс 8 дополнительных. Почти в каждом курсе есть практическая работа как финальный проект. Таким образом, у обучающегося на нем специалиста появляется практика. Я рекомендую не просто изучать теорию, а делать проекты: хорошие практические умения приблизят вас к прохождению собеседований и началу карьеры.

Я сам обучался некоторое время назад на Udacity – проходил курс по робомобилям, очень длинный, запланировано было 9 месяцев, но курс длился около года. Действительно узнал много нового, впечатления от платформы положительные. Но, конечно, все курсы там преподаются на английском.

Как учесть аномалии по временным рядам и можно ли их вырезать?


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

Для таких случаев есть различные наработки, но их приходится создавать самостоятельно. Самое важное – определить, что будет в будущем: например, увеличение телесмотрения по определенным каналам и передачам. Когда проходит время, эти данные попадают в прошлое — к тренировочным данным, и их нужно обработать правильным образом.

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

Каким образом устроиться на работу без подтвержденного опыта?


Хороший опыт – это ваши проекты. То есть, если вы не просто учите теорию, а сразу делаете проект — желательно, под руководством ментора (человека с опытом в data science и ИИ) – то вы знаете, что вы делаете. Вы не просто умеете применять теорию, или применять модель к данным, найденным в интернете, а решать практические задачи. При работе над такими проектами вы получаете знания, которые нельзя получить из книг и курсов, и помощь ментора здесь неоценима.

Поговорим о книгах – я приготовил небольшую стопку.

Если вы работаете в data science, то, скорее всего, вам придется работать в среде Linux. При этом вы не будете администратором – то есть, слишком глубокие знания вам не понадобятся – но уверенное знание этой платформы для простых административных задач (планирование запуска скриптов или распоряжение ресурсами ОС) будет обязательно. Здесь поможет книга «LINUX – карманный справочник» Скотта Граннемана. Его можно изучить за пару дней.

По теории вероятностей я бы порекомендовал книгу Г. Г. Битнера «Теория вероятностей» — в ней есть и теория, и задачи. Теория вероятностей пригодится вам и на собеседовании, и в работе.
Любому, кто работает в IT, требуется минимальный набор знаний и навыков. Соответственно, книга «Теоретический минимум по Computer Science – все, что нужно знать программисту и разработчику» (Фило Владстон Феррейра) — это ликбез по computer science.

Если вы будете погружаться в программирование и низкоуровневые разработки, то вам будут нужны алгоритмы. В книге «Алгоритмы для начинающих – теория и практика для разработчика» Паноса Луридаса даются алгоритмы без привязки к конкретному языку. Есть более объемная книга для C++ — «Алгоритмы на C++» Роберта Седжвика; она полезна, если вы хотите исключить какие-то высокоуровневые операции, которые есть в Python, и создавать алгоритмы с нуля.

Если вы хотите получить общее представление о верхнеуровневой работе специалиста по data science, то вам подойдет книга «Работа с данными в любой сфере – как выйти на новый уровень, используя аналитику» Кирилла Еременко. Здесь нет программирования. Но, если вы уже специалист, она пригодится вам только в том случае, если вы еще не работали с данными.
Далее: «Data Science. Наука о данных с нуля» Джоэля Граса – тоже полезная книга. От того же издания – «Практическая статистика для специалистов Data Science. 50 важнейших понятий» Питера Брюса и Эндрю Брюса. Здесь тоже можно изучить статистику.

Если вы будете работать с данными в Python и использовать библиотеку Pandas, то вам обязательно нужна «Python и анализ данных» Уэса Маккини – автора самой библиотеки Pandas.
По машинному обучению я рекомендую две книги: «Машинное обучение» Петера Флаха и «Python и машинное обучение» Себастьяна Рашки.

Для глубокого обучения есть книга «Глубокое обучение на Python» Франсуа Шолле, там можно изучить нейронные сети для задач NLP и компьютерного зрения. Конкретно по NLP есть «Прикладной анализ текстовых данных на Python» — Бенджамин Бенгфорд, Ребекка Белбро и Тони Охеда.

Если хотите изучить TensorFlow для глубокого обучения – есть одноименная книга Бхарата Рамсундара и Реза Босаг Заде.

Также есть книга, в которой просто и понятно объясняются принципы работы нейронных сетей – книга Эндрю Траска «Грокаем глубокое обучение». Есть также «Грокаем алгоритмы» — там хорошо объясняются алгоритмы, которые могут пригодиться на собеседовании и на практике.

Что вы спрашиваете на собеседованиях?


Есть небольшой сборник вопросов. Есть вопросы по классическому машинному обучению – специалист, который устраивается в сферу data science и ИИ, должен знать, как работают классические модели машинного обучения: линейная, логистическая регрессия, градиентный спуск, регуляризация L1-L2. Нужно, чтобы человек рассказал про принцип работы деревьев решений, про критерий информативности для задач классификации и регрессии; чтобы человек знал, как работает случайный лес, градиентный бустинг. Очень хорошо, если он знает отличия моделей градиентного бустинга – Catboost, LightGBM, XGBoost – то есть, чем отличаются эти библиотеки, как в них реализован градиентный бустинг. Также нужно, чтобы человек владел библиотеками для машинного обучения – Pandas, NumPy, SKLearn. Если специалисту нужно будет работать с нейронными сетями, с компьютерным зрением, с NLP, то будут вопросы по этим темам.
Вопросов может быть очень много. Если человек хорошо отвечает, то интересно бывает расспросить его о каких-то его проектах – если человек что-то сделал, у собеседующего сразу появляется много вопросов, связанных именно с проектами. Если у вас на GitHub есть личные проекты, или учебные проекты с курсов – будет очень хорошо, если вы сумеете подробно рассказать про технологии и алгоритмы, которые вы применяли.

Помимо этого, на собеседовании можно спрашивать разные базовые вопросы. Обычно, если человек хорошо отвечает на них – скорее всего, хороший специалист. Конечно, важно, чтобы он сумел выполнить тестовое задание. Теория – это одно, а вот то, как человек сможет решить практическую задачу, запрограммировать ее, какой он напишет код – это тоже важно. Если человек знает всю теорию, но присылает код, в котором не используется OP, когда это нужно – значит, он не знает, как правильно применять теорию. Кроме того, конечно, сам код должен быть читабельным и комментированным.

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

Что должно быть написано в резюме, чтобы получить приглашение на собеседование?


Резюме – это ответственный момент. Во-первых, оно не должно быть раздутым по объему: в нем должен быть только релевантный опыт. Если вы работали по специальности, не связанной с IT – это не нужно. Перечислите свои достижения вкратце, проекты, пройденные курсы, релевантные для вакансии. Вписывайте то, что показывает вас как специалиста, который способен выполнять эту работу. И, конечно, резюме должно быть читабельно.


Что было ранее


  1. Илона Папава, Senior Software Engineer в Facebook — как попасть на стажировку, получить оффер и все о работе в компании
  2. Борис Янгель, ML-инженер Яндекса — как не пополнить ряды стремных специалистов, если ты Data Scientist
  3. Александр Калошин, СEO LastBackend — как запустить стартап, выйти на рынок Китая и получить 15 млн инвестиций.
  4. Наталья Теплухина, Vue.js core team member, GoogleDevExpret — как пройти собеседование в GitLab, попасть в команду разработчиков Vue и стать Staff-engineer.
  5. Ашот Оганесян, основатель и технический директор компании DeviceLock — кто ворует и зарабатывает на ваших персональных данных.
  6. Сания Галимова, маркетолог RUVDS — как жить и работать с психиатрическим диагнозом. Часть 1. Часть 2.
  7. Илья Кашлаков, руководитель фронтенд-отдела Яндекс.Денег — как стать тимлидом фронтендеров и как жить после этого.
  8. Влада Рау, Senior Digital Analyst в McKinsey Digital Labs — как попасть на стажировку в Google, уйти в консалтинг и переехать в Лондон.
  9. Ричард «Левелорд» Грей, создатель игр Duke Nukem 3D, SiN, Blood — про личную жизнь, любимые игры и о Москве.
  10. Вячеслав Дреер, гейм-дизайнер и продюсер игр с 12-летним стажем — про игры, их жизненный цикл и монетизацию
  11. Андрей, технический директор GameAcademy — как видеоигры помогают прокачивать реальные навыки и найти работу мечты.
  12. Александр Высоцкий, ведущий PHP-разработчик Badoo — как создаются Highload проекты на PHP в Badoo.
  13. Андрей Евсюков, заместитель CTO в Delivery Club — про найм 50 синьоров за 43 дня и о том, как оптимизировать фреймворк найма
  14. Джон Ромеро, создатель игр Doom, Quake и Wolfenstein 3D — байки о том, как создавался DOOM
  15. Паша Жовнер, создатель тамагочи для хакеров Flipper Zero — о своем проекте и другой деятельности
  16. Татьяна Ландо, лингвист-аналитик в Google — как научить Google-ассистента человеческому поведению
  17. Путь от джуна до исполнительного директора в Сбербанке. Интервью с Алексеем Левановым
  18. Как Data Science продает вам рекламу? Интервью с инженером Unity

Let's block ads! (Why?)

[Перевод] Как масштабируется бизнес Docker для обслуживания миллионов разработчиков, часть 2: Исходящие данные

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

В первой части мы подробно рассмотрели образы, хранимые в Docker Hub, крупнейшем registry образов контейнеров. Мы пишем об этом для того, чтобы вы лучше понимали, как наши обновленные Условия обслуживания повлияют на команды разработчиков, использующих Docker Hub для управления образами контейнеров и конвейерами CI\CD.

Об ограничениях по частоте скачивания было объявлено ранее в наших Условиях обслуживания. Мы подробнее рассмотрим ограничения по частоте, которые вступят в силу с 1 ноября 2020 года:

Бесплатный тарифный план, анонимные пользователи: 100 скачиваний за 6 часов
Бесплатный тарифный план, авторизованные пользователи: 200 скачиваний за 6 часов
Тарифный план Pro: без ограничений
Тарифный план Team: без ограничений

Частота скачиваний со стороны Docker определяется как число запросов манифестов к Docker Hub. Ограничения по частоте скачивания образов зависят от типа учетной записи, запрашивающей образ, а не от типа учетной записи владельца образа. Для анонимных (неавторизованных) пользователей частота скачивания привязана к ip-адресу.

N.B. Больше тонкостей и best practice кейcов вы получите на курсе Docker от практиков. Причём вы можете проходить его, когда вам удобно — и по времени, и по настрою.

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


Подробный анализ частот скачивания образов Docker Hub

Мы потратили много времени анализируя скачивание образов из Docker Hub, чтобы определить причину ограничения скорости, а также как именно нужно ограничивать. То, что мы увидели, подтвердило, что фактически все пользователи скачивают образы с предсказуемой скоростью для типовых рабочих процессов. Однако есть заметное влияние небольшого числа анонимных пользователей, например порядка 30% всех скачиваний исходят только от 1% анонимных пользователей.

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


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

Сейчас, когда нам стало понятно влияние, а также где должны быть границы, нам надо было определить технические условия работы этих ограничений. Ограничивать скачивание образов из Docker registry достаточно сложно. Вы не найдете API для закачек в описании registry — его просто не существует.По факту скачивание образа представляет собой комбинацию запросов манифеста и blobs в API, а они выполняются по-разному, в зависимости от состояния клиента и запрашиваемого образа.

К примеру, если у вас уже есть образ, Docker Engine выдаст запрос на манифест, поймет, что у него уже есть все необходимые слои на основе принятого манифеста, после чего остановится. С другой стороны — если вы скачиваете образ, поддерживающий несколько архитектур, запрос на манифест вернет список манифестов образов для каждой поддерживаемой архитектуры. Затем Docker Engine выдаст еще один запрос на манифест касательно конкретной архитектуры, на которой он работает, в ответ получит список всех слоев образа. Затем он будет запрашивать каждый отсутствующий слой (blob).

N.B. Более широко эта тема раскрыта на курсе Docker, в котором мы разберем все его инструменты: от основных абстракций до параметров сети, нюансов работы с различными ОС и языками программирования. Вы познакомитесь с технологией и поймете, где и как лучше использовать Docker.

Получается, что скачивание образа это на самом деле один или два запроса манифеста, а также от нуля и до бесконечности — запросы слоев (blob). Исторически Docker отслеживал частоту скачивания на основе слоев, поскольку это наиболее связано с использованием полосы пропускания. Но тем не менее, мы прислушались к сообществу, что так сложнее, ведь нужно отслеживать запрашиваемое число слоев, что приведет к игнорированию best practices касательно работы с Dockerfile, а также интуитивно непонятнее для пользователей, желающих просто работать с registry, не сильно разбираясь в деталях.

Так что мы ограничиваем число запросов на основе запросов на манифесты. Это напрямую связано с скачиванием образов, что легко понять пользователям. Есть правда небольшой нюанс — если вы пробуете скачать образ, который уже есть, запрос все равно будет учтен, даже если вы и не будете качать слои. В любом случае мы надеемся, что такой метод ограничения частоты скачивания будет и справедливым, и удобным для пользователей.


Ждем ваши отзывы

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

Следите за сообщениями в ближайшие недели, будет еще одна статья о настройке CI и боевых систем в свете этих изменений.

Наконец, в рамках поддержки сообщества разработчиков ПО с открытым исходным кодом, до 1 ноября мы предоставим новые тарифные планы для открытого исходного кода. Чтобы подать заявку — надо заполнить форму тут.

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

Тем, кому надо поднять ограничения на частоту скачивания образов, Docker предлагает неограниченное скачивание образов в качестве особенности планов Pro или Team. Как всегда, мы ждем обратную связь и вопросы здесь.

Let's block ads! (Why?)

Автоматизация системных тестов на базе QEMU (Часть 2/2)

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

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


Дисклеймер

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

Итак, в прошлой части мы запаслись внушительным арсеналом из навыков работы с виртуальными машинами из командной строки: научились устанавливать виртуалки, раскатывать на них ОС (на примере Ubuntu Server 18.04), соединять виртуалку с хостом по сети и даже организовывать канал управления через SSH. Всё это нам пригодится в этой статье, но прежде чем перейти к практике, нужно обсудить несколько вопросов.


Что же мы хотим получить?

Самый главный вопрос, на который нужно дать ответ — это "Какой результат мы хотим получить?". Да, в прошлый раз мы много говорили об автоматизации установки, развертывания и настройки виртуалок, но в отрыве от конечной цели это всё не имеет большого смысла.

Лично для меня системные тесты "всё в одном" выглядят так: я скачиваю из VCS несколько небольших файликов (сам скрипт с запуском, плюс, возможно, несколько вспомогательных артефактов), подкладываю куда нужно тестируемую программу (в виде инсталлятора или пакета, например), нажимаю одну кнопку и иду пить кофе. Когда я возвращаюсь, я хочу либо увидеть что все тесты прошли, либо что такие-то тесты сломались. Я не хочу заниматься какой-либо настройкой стенда, не хочу разворачивать виртуалки или что-то там настраивать. Хочу скачать скрипт и воспользоваться им.

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

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


Что будем тестировать

Для статьи в качестве подопытной программы я выбрал интересную кандидатуру. Мы будем тестировать мини-фаервол, написанный с ипользованием библиотеки Data Plane Development Kit (DPDK). Если вы не знакомы с DPDK — не пугайтесь, мы не собираемся его изучать, мы возьмём готовое приложение из тех примеров, которые поставляются вместе с DPDK. Приложение на DPDK идеально подходит к этой статье, потому что совершенно непонятно, как именно можно автоматизировать end-to-end тесты для таких приложений.


Несколько слов про DPDK и что в нем такого особенного

DPDK (Data Plane Development Kit) — под этим громким названием скрывается просто набор библиотек, написанных на языке C. Эти библиотеки упрощают создание приложений, которые занимаются обработкой сетевого трафика. Примечательной особенностью этой библиотеки является тот факт, что она взаимодействует с сетевыми адаптерами напрямую. Обычно оборудованием управляет операционная система, она же выполняет приём и обработку сетевых пакетов. Платформа DPDK позволяет отодвинуть операционную систему в сторону и взять всё управление в свои руки. Зачем это нужно? Такой подход позволяет добиться впечатляющих показателей производительности. Дело в том, что ядро операционной системы, например Linux, выполняет с сетевыми пакетами очень много манипуляций, которые нам, возможно, и не нужны. Оно и понятно, ведь Linux — он как швейцарский нож, подходит для решения практически любой задачи. Если же нужно решить всего одну относительно простую задачу и сделать это максимально эффективно, то DPDK будет хорошим выбором.

Само приложение имеет очень простой принцип работы:


  1. оно принимает сетевые пакеты с одного из сетевых интерфейсов;
  2. сопоставляет полученный пакет со списком правил фильтрации;
  3. если пакет попал под правило DROP — то пакет отбрасывается;
  4. если пакет попал под правило ACCEPT — то пакет выплёвывается из другого сетевого адаптера;

Соответственно, нам нужно проверить, что:


  • приложение устанавливается на ОС и успешно запускается;
  • правила фильтрации отрабатывают так, как и было задумано;

План работ

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


  1. Создать три виртуальных машины (client, middlebox, server), установить везде Ubuntu Server 18.04 (например);
  2. Создать две виртуальные сети: сеть между client и middlebox (назовём эту сеть для краткости net_1) и сеть между middlebox и server (назовём её net_2);
  3. Подключить машины к этим сетям;
  4. Настроить виртуальные машины, привести их в боевое состояние;
  5. Установить наше приложение-фаервол в машину middlebox;
  6. Прогнать сами тесты.

Вот все эти вещи мы и хотим автоматизировать в нашем скрипте. При этом добавим пару оговорок:


  1. Как мы помним из первой части статьи, для выполнения команд на виртуалках нам потребуется организовать SSH-канал управления между виртуалками и хостом, это будет один из пунктов, который нам нужно будет дополнительно сделать, хотя для ручного тестирования этот пункт явно необязателен;
  2. Хоть теоретически хост может связаться с виртуалкой по SSH используя виртуальные сети net_1 и net_2, но лучше использовать для этого отдельную сеть (назовём её net_for_ssh). Глобальных причин для этого две:

  • Т.к. мы тестируем фаерволл, то не хотелось бы, чтобы управляющий трафик оказывал какое-либо влияние на ход проведения тестов;
  • В случае, если что-то пойдет не так (например, фаерволл свалится), мы бы не хотели чтобы управление у виртуалки отваливалось.

За работу!

Для тестирования мини-фаерволла мы развернём такой стенд:


С учётом знаний, которые мы получили в предыдущей части статьи, автоматизировать развёртывание стенда совсем несложно:


run_tests.sh
#!/bin/bash
set -euo pipefail

# =======================================
# Подготовка сети net_for_ssh
# =======================================
virsh net-define net_for_ssh.xml
virsh net-start net_for_ssh

# =======================================
# Подготовка сети net_1
# =======================================
virsh net-define net_1.xml
virsh net-start net_1

# =======================================
# Подготовка сети net_2
# =======================================
virsh net-define net_2.xml
virsh net-start net_2

# =======================================
# Подготовка машины client
# =======================================
virt-builder ubuntu-18.04 \
    --format qcow2 \
    --output client.qcow2 \
    --install wget \
    --root-password password:1111 \
    --run-command "ssh-keygen -A" \
    --run-command "sed -i \"s/.*PermitRootLogin.*/PermitRootLogin yes/g\" /etc/ssh/sshd_config" \
    --copy-in netcfg_client.yaml:/etc/netplan/

virt-install \
    --import \
    --name client \
    --ram 1024 \
    --disk client.qcow2 \
    --network network=net_for_ssh \
    --network network=net_1,mac=52:54:56:11:00:00 \
    --noautoconsole

# =======================================
# Подготовка машины middlebox
# =======================================
virt-builder ubuntu-18.04 \
    --format qcow2 \
    --output middlebox.qcow2 \
    --install python,daemon,libnuma1 \
    --root-password password:1111 \
    --run-command "ssh-keygen -A" \
    --run-command "sed -i \"s/.*PermitRootLogin.*/PermitRootLogin yes/g\" /etc/ssh/sshd_config" \
    --copy-in netcfg_middlebox.yaml:/etc/netplan/

virt-install \
    --import \
    --name middlebox \
    --vcpus=2,sockets=1,cores=2,threads=1 \
    --cpu host \
    --ram 2048 \
    --disk middlebox.qcow2 \
    --network network=net_for_ssh \
    --network network=net_1,model=e1000 \
    --network network=net_2,model=e1000 \
    --noautoconsole

# =======================================
# Подготовка машины server
# =======================================
virt-builder ubuntu-18.04 \
    --format qcow2 \
    --output server.qcow2 \
    --install nginx \
    --root-password password:1111 \
    --run-command "ssh-keygen -A" \
    --run-command "sed -i \"s/.*PermitRootLogin.*/PermitRootLogin yes/g\" /etc/ssh/sshd_config" \
    --copy-in netcfg_server.yaml:/etc/netplan/

virt-install \
    --import \
    --name server \
    --ram 1024 \
    --disk server.qcow2 \
    --network network=net_for_ssh \
    --network network=net_2,mac=52:54:56:00:00:00 \
    --noautoconsole

# =======================================
# Убедимся, что наши машины запустились
# и доступны для команд управления
# =======================================

SSH_CMD="sshpass -p 1111 ssh -o StrictHostKeyChecking=no"

while ! SSH_CMD root@192.168.100.2 "echo Hello world from client!" echo
do
    echo "Waiting for client VM ..."
    sleep 1
done

while ! SSH_CMD root@192.168.100.3 "echo Hello world from middlebox!" echo
do
    echo "Waiting for middlebox VM ..."
    sleep 1
done

while ! SSH_CMD root@192.168.100.4 "echo Hello world from server!" echo
do
    echo "Waiting for server VM ..."
    sleep 1
done

Для запуска этого скрипта потребуются следующие артефакты:


net_for_ssh.xml
<network>
    <name>net_for_ssh</name>
    <bridge name='net_for_ssh'/>
    <ip address='192.168.100.1' netmask='255.255.255.0'/>
</network>

net_1.xml
<network>
    <name>net_1</name>
    <bridge name='net_1'/>
    <ip address='192.168.101.1' netmask='255.255.255.0'/>
</network>

net_2.xml
<network>
    <name>net_2</name>
    <bridge name='net_2'/>
    <ip address='192.168.102.1' netmask='255.255.255.0'/>
</network>

netcfg_client.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      addresses:
        - 192.168.100.2/24
    ens4:
      addresses:
        - 192.168.101.2/24
      gateway4: 192.168.101.3

netcfg_middlebox.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      addresses:
        - 192.168.100.3/24

netcfg_server.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    ens3:
      addresses:
        - 192.168.100.4/24
    ens4:
      addresses:
        - 192.168.102.2/24
      gateway4: 192.168.102.3

Большая часть команд и приёмов Вам должна быть уже известна из первой части статьи, а мы лишь остановимся на некоторых интересных моментах:


  1. Мы используем параметр --install команды virt-builder, чтобы установить на виртуалки дополнительные пакеты. Это просто удобное сокращение для --run-command "apt install ...". Собственно, Вам даже не обязательно знать, какой пакетный менеджер работает на гостевой системе — virt-builder сам разберётся. Для машины client мы устанавливаем пакеты wget, для servernginx (чтобы тестировать фаерволл с помощью http-запросов на сервер). Для middlebox мы устанавливаем зависимости, необходимые для настройки и запуска DPDK-приложений;
  2. Для машин client и server мы указываем, какие МАС-адреса нужно присвоить сетевым адаптерам, смотрящих в сторону фаерволла. Это пригодится нам при прогоне тестов;
  3. Для машины middlebox мы указываем топологию виртуального процессора (параметр --vcpus): нам требуется один CPU c двумя ядрами без поддержки технологии hyperthreading. Два ядра — это минимальное количество ядер, необходимое для запуска DPDK приложения. Кроме того мы указываем параметр --cpu host, что означает, что процессор на вируалке должен иметь те же возможности, что и процессор на хостовой системе. Дело в том, что по-умолчанию QEMU создаёт виртуальный процессор, который не поддерживает даже SSE3 инструкции. А без этого, опять же, DPDK приложение не запустится.
  4. Также для машины middlebox мы указываем модель сетевых адаптеров, участвующих в машрутизации и фильтрации трафика: e1000. Та модель адаптера, которая создаётся по-умолчанию на данный момент не поддерживается библиотекой DPDK.

На текущий момент наш скрипт run_tests.sh сможет корректно отработать только один раз (или даже вообще ни разу, если Вы проделывали у себя шаги из первой части статьи). При повторном запуске у Вас будут возникать ошибки, связанные с двумя моментами:


  1. Нельзя повторно создать уже созданную сеть;
  2. Нельзя повторно создать уже созданную виртуальную машину.

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


run_clean.sh
#!/bin/bash
set -euo pipefail

# =======================================
# Удаление машины client
# =======================================
if virsh list --all | grep -q " client "; then
    if virsh domstate client | grep -q "running"; then
        virsh destroy client
    fi
    virsh undefine client --snapshots-metadata --remove-all-storage
fi

# =======================================
# Удаление машины middlebox
# =======================================
if virsh list --all | grep -q " middlebox "; then
    if virsh domstate middlebox | grep -q "running"; then
        virsh destroy middlebox
    fi
    virsh undefine middlebox --snapshots-metadata --remove-all-storage
fi

# =======================================
# Удаление машины server
# =======================================
if virsh list --all | grep -q " server "; then
    if virsh domstate server | grep -q "running"; then
        virsh destroy server
    fi
    virsh undefine server --snapshots-metadata --remove-all-storage
fi

# =======================================
# Удаление сети net_for_ssh
# =======================================
if virsh net-list --all | grep -q " net_for_ssh "; then
    if virsh net-list --all | grep " net_for_ssh " | grep -q " active "; then
        virsh net-destroy net_for_ssh
    fi
    virsh net-undefine net_for_ssh
fi

# =======================================
# Удаление сети net_1
# =======================================
if virsh net-list --all | grep -q " net_1 "; then
    if virsh net-list --all | grep " net_1 " | grep -q " active "; then
        virsh net-destroy net_1
    fi
    virsh net-undefine net_1
fi

# =======================================
# Удаление сети net_2
# =======================================
if virsh net-list --all | grep -q " net_2 "; then
    if virsh net-list --all | grep " net_2 " | grep -q " active "; then
        virsh net-destroy net_2
    fi
    virsh net-undefine net_2
fi

Вот этот скрипт, в отличие от run_tests.sh, будет отрабатывать всегда. Основные моменты в этом скрипте:


  1. Удаляет машины или сети только если они созданы (существование виртуалок проверяется с помощью команды virsh list --all, а существование сетей — с помощью команды virsh net-list -all);
  2. Чтобы удалить машину/сеть, сначала нужно убедиться, что эта машина/сеть выключена, иначе удалить её не получится;
  3. Виртуалки удаляются вместе со снепшотами (параметр --snapshots-metadata) и подключенными дисками (параметр --remove-all-storage).

Пока что для повторного запуска run_tests.sh нужно запускать run_clean.sh. В дальнейшем мы доработаем run_tests.sh так, чтобы он отрабатывал и без помощи run_clean.sh.


По поводу копипасты

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

Здесь стоит упомянуть один неприятный момент. Когда мы запускаем SSH-команды — SSH добавляет публичный ключ виртуалки в файл ~/.ssh/known_hosts. Если мы удалим виртуалки, создадим её заново и попробуем поключится к ней по SSH — он откажется подключаться, думая, что Вас кто-то хочет обмануть. Мы можем избежать этой ситуации подкорректировав нашу переменную SSH_CMD:

SSH_CMD="sshpass -p 1111 ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o LogLevel=ERROR"

Я добавил параметр -o UserKnownHostsFile=/dev/null, чтобы запуск скрипта тестового сценария никак не влиял на хостовую машину.


Немного об организации тестов

В прошлой части я упомянул, что идеальный вариант автоматизации системных тестов — это автоматизация действий человека при работе за компьютером. Но работу пользователя с Ubuntu Server (без GUI) можно представить как последовательность выполнения bash-команд, чем мы и воспользовались.

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

Во-первых, сделаем очень простую, но в тоже время очень полезную вещь:

EXEC_CLIENT="$SSH_CMD root@192.168.100.2"
EXEC_MIDDLEBOX="$SSH_CMD root@192.168.100.3"
EXEC_SERVER="$SSH_CMD root@192.168.100.4"

Мы всего лишь объявили три переменные. Но это уже позволяет писать более читабельный скрипт. Например:

$EXEC_CLIENT echo hello from client
$EXEC_SERVER echo hello from server

Во-вторых, что насчёт многострочных команд? Здесь нам поможет такая возможность bash-интерпретатора как Heredoc. Heredoc позволяет нам записывать тестовые сценарии в следующим виде:

$EXEC_CLIENT << EOF
    echo hello from client
    ls
    pwd
EOF

$EXEC_MIDDLEBOX << EOF
    echo hello from middlebox
    some_another_command
EOF

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

Когда вы используете мультистрочные команды, скорее всего вы захотите добавить в начало строчку set -xeuo pipefail. Например:

$EXEC_MIDDLEBOX << EOF
    set -xeuo pipefail

    command1
    command2 | command3
EOF

Напомню на всяких случай, что означает эта команда:


  • параметр -x заставляет bash-интерпретатор печатать каждую команду перед тем как её выполнить;
  • параметр -e останавливает выполнение всего скрипта, если хотя бы одна из команд завершилась с ошибкой;
  • параметр -u останавливает выполнение всего скрипта, если Вы обратились в нём к несуществующей переменной;
  • парамерт -o pipeline останавливает конвейер, если какая-то команда в его составе завершилась с ошибкой.

Таким образом, если что-то пойдёт не так в Вашем тестовом сценарии — Вы сразу об этом узнаете.

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

$EXEC_MIDDLEBOX << EOF
    set -xeuo pipefail

    command1
    ! command2
EOF

Вышеприведенный скрипт выполнится успешно только в одном единственном случае: если command1 вернёт 0, а command2 вернёт значение, отличное от нуля.


Переходим к самим тестам

В рамках статьи мы напишем три системных теста:


  1. Проверим, что приложение успешно устанавливается и запускается;
  2. Проверим, что приложение в принципе машрутизирует трафик;
  3. Проверим, что приложение может блокировать определенный вид трафика.

Давайте взглянем на первый тест:

$SCP_CMD l3fwd-acl-1.0.0.deb root@192.168.100.3:~

$EXEC_MIDDLEBOX << EOF
    set -xeuo pipefail

    dpkg -i l3fwd-acl-1.0.0.deb

    echo 256 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
    mkdir -p /mnt/huge
    mount -t hugetlbfs nodev /mnt/huge

    modprobe uio_pci_generic
    dpdk-devbind --bind=uio_pci_generic ens4 ens5

    echo "R0.0.0.0/0 192.168.102.0/24 0 : 65535 0 : 65535 0x0/0x0 1" > /etc/rule_ipv4.db
    echo "R0.0.0.0/0 192.168.101.0/24 0 : 65535 0 : 65535 0x0/0x0 0" >> /etc/rule_ipv4.db

    echo "R0:0:0:0:0:0:0:0/0 0:0:0:0:0:0:0:0/0 0 : 65535 0 : 65535 0x0/0x0 0" > /etc/rule_ipv6.db

    daemon --name l3fwd --unsafe --output /var/log/l3fwd -- l3fwd-acl \
        -l 1 \
        -n 4 \
        -- \
        -p 0x3 \
        -P \
        --config="(0,0,1),(1,0,1)" \
        --rule_ipv4="/etc/rule_ipv4.db" \
        --rule_ipv6="/etc/rule_ipv6.db"
EOF

О содержимом скрипта

Вот развёрнутый список того, что делает этот скрипт (для интересующихся):


  1. Устанавливает скопированный на виртуалку deb-пакет;
  2. Резервирует и монтирует 256 гигантских страниц по 2 мегабайта (DPDK-приложения по-умолчанию используют гигантские страницы для размещения своих данных);
  3. Подгружает poll-mode драйвер uio_pci_generic (он поставляется в составе Ubuntu Server). Этот драйвер необходим для того, чтобы DPDK приложение смогло через него получить прямой доступ к сетевым адаптерам;
  4. Отвязывает интерфейсы ens4 (в сторону клиента) и ens5 (в сторону сервера) от стандартного сетевого драйвера и привязывает их к драйверу uio_pci_generic;
  5. Создаёт файл rule_ipv4.db с правилами маршрутизации для пакетов IPv4 и кладёт туда два правила: все пакеты с адресом назначения 192.168.102.0/24 отправлять на порт 1 (то есть все пакеты от клиента к серверу надо отправлять на порт, который смотрит в сторону сервера), а все пакеты с адресом назначения 192.168.101.0/24 отправлять на порт 0 (то есть в сторону клиента);
  6. Также создаёт аналогичный файл для rule_ipv6.db, но туда кладёт одно правило по умолчанию "Все пакеты отправляй на порт 0". Реальных IPv6 пакетов генерироваться в рамках тестов не будет, но без этого файла DPDK приложение запускаться не будет;
  7. Запускает тестируемое l3fwd приложение и отправляет его работать в фон с помощью daemon. Подробно останавливаться на формате запуска не будем, но для интересующихся этот формат можно посмотреть на странице с документацией l3fwd: https://doc.dpdk.org/guides/sample_app_ug/l3_forward.html

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


  1. Установить пакет .deb в систему;
  2. Подправить параметры ядра;
  3. Смонтировать раздел к файловой системе;
  4. Загрузить модуль ядра;
  5. Привязать сетевые интерфейсы, участвующие в маршрутизации, к драйверу uio_pci_generic;
  6. Запустить приложение в фоне.

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

И этот лейтмотив только усиливается во втором тесте: вместо того, чтобы проверять работу DPDK-приложения с помощью фиксированного набора пакетов (как это можно было бы сделать в unit-тестах, например), мы будем проверять приложение так, как это бы сделал реальный человек: попробуем передать что-нибудь по сети с помощью реальных утилит и посмотрим на результат:

$EXEC_CLIENT arp -s 192.168.101.3 52:54:56:00:00:00
$EXEC_SERVER arp -s 192.168.102.3 52:54:56:11:00:00

$EXEC_CLIENT << EOF
    set -xeuo pipefail

    ping -c 5 192.168.102.2
    wget --timeout=5 --tries=1 http://192.168.102.2
EOF

о ситуации с ARP-записями

Перед тем, как пускать трафик, мы добавили две статические ARP-записи.
Зачем это нужно? Дело в том, что тестовое приложение l3fwd, взятое из примеров
библиотеки DPDK, настолько простое, что оно даже не обратывает протокол ARP.
Приложение l3fwd просто фильтрует трафик в соответствии с правилами, заданными
в файлах rule_ipv4.db и rule_ipv6.db, и кроме этого не делает больше ровным
счётом ничего: ни проверки чексуммы, ни фрагментации/дефрагментации пакетов, ни-че-го.
Это как раз один из способов достижения максимальной производительности: просто
не делать того, что конкретно Вам не нужно конкретно в Вашей ситуации.
Это приводит к тому, что сетевые пакеты пролетают сквозь машину middlebox
вообще без никаких изменений, хотя у него должны поменяться MAC-адреса
в Ethernet-заголовке (иначе client и server будут просто отпрасывать такие пакеты).
Мы можем закостылить эту пролему следующим образом: будем отправлять пакеты
с уже заранее изменённым destination MAC-адресом. Для этого здесь и используются
статические ARP-записи.

Третий же тест довольно очевиден и вытекает из первых двух:

# =======================================
# Добавим правило, заврещающее tcp трафик
# =======================================

$EXEC_MIDDLEBOX << EOF
    set -xeuo pipefail

    daemon --name l3fwd --stop

    # Это и есть запрещающее правило
    echo "@0.0.0.0/0 0.0.0.0/0 0 : 65535 0 : 65535 0x06/0xff" > /etc/rule_ipv4.db

    echo "R0.0.0.0/0 192.168.102.0/24 0 : 65535 0 : 65535 0x0/0x0 1" >> /etc/rule_ipv4.db
    echo "R0.0.0.0/0 192.168.101.0/24 0 : 65535 0 : 65535 0x0/0x0 0" >> /etc/rule_ipv4.db

    daemon --name l3fwd --unsafe --output /var/log/l3fwd -- l3fwd-acl \
        -l 1 \
        -n 4 \
        -- \
        -p 0x3 \
        -P \
        --config="(0,0,1),(1,0,1)" \
        --rule_ipv4="/etc/rule_ipv4.db" \
        --rule_ipv6="/etc/rule_ipv6.db"
EOF

# =======================================
# Проверяем, что ping продолжает ходить,
# а http трафик - перестал
# =======================================

$EXEC_CLIENT << EOF
    set -xeuo pipefail

    ping -c 5 192.168.102.2
    ! wget --timeout=5 --tries=1 http://192.168.102.2
EOF

Обратите внимание, что перед wget стоит восклицательный знак: это означает, что тест будет успешен, только если команда wget завершиться с ошибкой.


Дорабатываем скрипт run_tests.sh

С самими тестами мы разобрались, осталось немного подумать над нашим скриптом по запуску тестов, который сейчас может успешно отрабатывать только при предварительном прогоне скрипта run_clean.sh.

Давайте поразмышляем вот над чем: весь скрипт можно условно разделить на две больших секции: до копирования сборки DPDK-приложения на middlebox и после. В чём разница? Дело в том, что по отношению к стенду (системе из виртуальных машин) сборка DPDK-приложения является внешней переменной Х. Мы заранее знаем, как поведёт себя скрипт до появления этой внешней переменной, но мы не знаем насколько успешно пройдут тесты после внедрения внешнего неизвестного элемента. Вдруг сборка окажется неработоспособной и тесты свалятся?

Поэтому мы можем внести элемент кеширования в наш скрипт. Как насчёт фиксации результатов работы скрипта на момент ровно перед появлением внешней переменной, и отката к этому состоянию при повторном запуске скрипта? Ведь мы знаем, что участок скрипта до появления неопределённого элемента должен всегда выполняться одинаково. А фиксацию можно сделать очень просто: мы можем создать снепшот, например с названием init, для каждой виртуальной машины после её первоначальной настройки.

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

# =======================================
# Подготовка машины client
# =======================================
if ! virsh list --all | grep -q " client "
then
    virt-builder ubuntu-18.04 \
        --format qcow2 \
        --output client.qcow2 \
        --hostname client \
        --install wget,net-tools \
        --root-password password:1111 \
        --run-command "ssh-keygen -A" \
        --run-command "sed -i \"s/.*PermitRootLogin.*/PermitRootLogin yes/g\" /etc/ssh/sshd_config" \
        --copy-in netcfg_client.yaml:/etc/netplan/

    virt-install \
        --import \
        --name client \
        --ram 1024 \
        --disk client.qcow2 \
        --network network=net_for_ssh \
        --network network=net_1,mac=52:54:56:11:00:00 \
        --noautoconsole

    virsh snapshot-create-as client --name init
else
    virsh snapshot-revert client --snapshotname init
fi

Теперь если машина уже существует, то скрипт вместо её создания будет откатывать её к снепшоту init.


Другие снепшоты

Конечно, никто не запрещает создавать и другие снепшоты уже во время самих тестов, чтобы при необходимости откатываться к ним: например, мы могли бы создать снепшот после установки .deb-пакета и базовых настроек DPDK, после чего откатываться к нему перед началом второго теста. Здесь лучше всего действовать по ситуации.

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

# =======================================
# Подготовка сети net_1
# =======================================
if ! virsh net-list --all | grep -q " net_1 "
then
    virsh net-define net_1.xml
    virsh net-start net_1
fi

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

→ Репо с итоговым скриптом можно найти здесь


Итоги

Что ж, мы проделали довольно много работы, в том числе и муторной, и самое время оглянуться назад и посмотреть, чего же мы достигли. А достигли мы немалого: мы написали скрипт, который в автоматическом режиме полностью с нуля разворачивает у нас на компьютере стенд из трёх виртуальных машин, раскатывает на этом стенде сборку тестируемого приложения, а также прогоняет настоящие системные (end-to-end) тесты для этого приложения.

Заметьте, что эти тесты проверяют работу нашего приложения от начала и до конца именно в том виде, в котором это приложение будет в реальности работать: мы поместили DPDK-приложение в конкретную среду (стенд из трех машин Ubuntu Server 18.04) и с конкретным набором реальных пользовательских проверок (вызов утилиты ping и wget). В нашем стенде нет ни единой заглушки, мы можем взять наш .deb пакет и прямо сейчас выложить его на сайте для скачивания всеми желающими. И именно поэтому такие тесты дают такую четкую уверенность, что если программа работает внутри тестов, то она точно отработает в реальных условиях (по крайней мере, в ТАКИХ ЖЕ реальных условиях). И эта уверенность дорогого стоит.

Но это ещё не всё: все наши артефакты это два скрипта (run_tests.sh и run_clean.sh), три xml-файла и три yaml-файла. Всё это текстовые файлы и идеально хранятся в любой VCS. Эти скрипты можно легко переносить между компьютерами и всё равно прогонять тесты одной кнопкой.

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

Ну а если у Вас осталось некоторое ощущение "недоделанности", "костыльности" и "кривизны" подхода, который мы продемонстрировали в этой статье, то Вы, на самом деле, будете правы. Все эти наработки очень даже хороши как Proof Of Concept для идеи автоматизации системных тестов с использованием виртуальных машин. Но строить полноценную большую и промышленную систему тестов на основе баш-скриптов было бы… довольно оптимистично. Впрочем, есть и более элегентное, законченное и отработаное решение, которое может помочь Вам клепать системные тесты как горячие пирожки на любых операционных системах и даже не задумываться всерьез обо всей сложной внутренней кухне, которая при всём при этом происходит. Но это уже тема для нашей следующей статьи...

Let's block ads! (Why?)