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

Infrastructure

Перевод DataHub универсальный инструмент поиска и обнаружения метаданных

28.09.2020 12:18:44 | Автор: admin

DataHub: универсальный инструмент поиска и обнаружения метаданных.


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


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


Масштабирование метаданных


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


С момента нашего первого выпуска WhereHows в 2016 году, в отрасли наблюдается растущий интерес к повышению продуктивности специалистов по обработке данных с помощью метаданных. Например, инструменты, разработанные в этой области, включают Dataportal AirBnb, Databook Uber, Metacat Netflix, Amundsen Lyft и совсем недавно Data Catalog от Google. В LinkedIn мы также были заняты расширением объема сбора метаданных для новых вариантов использования при сохранении конфиденциальности. Однако мы пришли к выводу, что у WhereHows были фундаментальные ограничения, которые не позволяли удовлетворить наши растущие потребности в метаданных. Вот то, что мы смогли узнать во время работы с масштабированием WhereHows:


  1. Push лучше, чем pull: хотя получение метаданных непосредственно из источника кажется наиболее простым способом сбора метаданных. Более масштабируемым является использование отдельных поставщиков метаданных для передачи информации в центральный репозиторий через API или сообщения. Такой подход на основе push также обеспечивает более своевременное отображение новых и обновленных метаданных.
  2. Общее лучше, чем конкретное: WhereHows категорически придерживается мнения о том, как должны выглядеть метаданные для набора данных или задания. Это приводит к упрямому API, модели данных и формату хранения. Небольшое изменение модели метаданных приведет к каскаду необходимых изменений вверх и вниз по стеку. Он был бы более масштабируемым, если бы мы разработали общую архитектуру, не зависящую от модели метаданных, которую она хранит и обслуживает. Это, в свою очередь, позволило бы нам сосредоточиться на адаптации и развитии строго самоуверенных моделей метаданных, не беспокоясь о нижних уровнях стека.
  3. Онлайн так же важен, как и офлайн. После того, как метаданные собраны, естественно необходимо проанализировать эти метаданные, чтобы извлечь из них пользу. Одно из простых решений сбросить все метаданные в автономную систему, такую как Hadoop, где можно выполнять произвольный анализ. Однако вскоре мы обнаружили, что одной только поддержки автономного анализа недостаточно. Есть много вариантов использования, таких как управление доступом и обработка конфиденциальности данных, для которых необходимо запрашивать последние метаданные в Интернете.
  4. Взаимоотношения действительно важны. Метаданные часто передают важные взаимосвязи (например, происхождение, владение и зависимости), которые обеспечивают мощные возможности, такие как анализ воздействия, объединение данных, повышение релевантности поиска и т. д.
  5. Многоцентровая вселенная: мы поняли, что недостаточно просто моделировать метаданные, сосредоточенные вокруг одного объекта (набора данных). Существует целая экосистема данных, кода и человеческих сущностей (наборы данных, специалисты по обработке данных, команды, код, API микросервисов, показатели, функции ИИ, модели ИИ, информационные панели, записные книжки и т. Д.), Которые необходимо интегрировать и связать через единый граф метаданных.

Встречайте DataHub


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


Мы разделили монолитный стек WhereHows на два отдельных стека: интерфейс модульного пользовательского интерфейса и бэкэнд общей архитектуры метаданных. Новая архитектура позволила нам быстро расширить сферу сбора метаданных, не ограничиваясь только наборами данных и заданиями. На момент написания DataHub уже хранит и индексирует десятки миллионов записей метаданных, которые охватывают 19 различных сущностей, включая наборы данных, показатели, задания, диаграммы, функции ИИ, людей и группы. Мы также планируем в ближайшем будущем внедрить метаданные для моделей и меток машинного обучения, экспериментов, информационных панелей, API микросервисов и кода.


Модульный интерфейс


Веб-приложение DataHub это то, как большинство пользователей взаимодействуют с метаданными. Приложение написано с использованием Ember Framework и работает на среднем уровне Play. Чтобы сделать разработку масштабируемой, мы используем различные современные веб-технологии, включая ES9, ES.Next, TypeScript, Yarn with Yarn Workspaces, а также инструменты качества кода, такие как Prettier и ESLint. Уровни представления, управления и данных разделены на пакеты, так что определенные представления в приложении построены на основе композиции соответствующих пакетов.


Структура обслуживания компонентов


Применяя модульную инфраструктуру пользовательского интерфейса, мы создали веб-приложение DataHub как серию связанных компонентов, согласованных по функциям, которые сгруппированы в устанавливаемые пакеты. Эта архитектура пакета использует в основе Yarn Workspaces и надстройки Ember и разбита на компоненты с использованием компонентов и сервисов Ember. Вы можете думать об этом как о пользовательском интерфейсе, который построен с использованием небольших строительных блоков (например, компонентов и сервисов) для создания более крупных строительных блоков (например, надстроек Ember и пакетов npm / Yarn), которые при объединении в конечном итоге составляют веб-приложение DataHub .


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


Взаимодействие с DataHub


На самом высоком уровне интерфейс обеспечивает три типа взаимодействия: (1) поиск, (2) просмотр и (3) просмотр / редактирование метаданных. Вот несколько примеров скриншотов из реального приложения:








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


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


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


Обобщенная архитектура метаданных


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


  1. Моделирование: моделируйте все типы метаданных и отношений в удобной для разработчиков манере.
  2. Прием: прием большого количества изменений метаданных в любом масштабе как через API, так и через потоки.
  3. Обслуживание: обслуживайте собранные необработанные и производные метаданные, а также множество сложных запросов к метаданным в любом масштабе.
  4. Индексирование: индексируйте метаданные в масштабе, а также автоматически обновляйте индексы при изменении метаданных.

Моделирование метаданных


Проще говоря, метаданные это данные, которые предоставляют информацию о других данных. Когда дело доходит до моделирования метаданных, это предъявляет два различных требования:


  1. Метаданные это также данные: для моделирования метаданных нам нужен язык, который по крайней мере так же многофункциональн, как те, которые используются для моделирования данных общего назначения.
  2. Метаданные распределены: нереально ожидать, что все метаданные поступают из одного источника. Например, система, которая управляет списком управления доступом (ACL) набора данных, скорее всего, будет отличаться от той, которая хранит метаданные схемы. Хорошая среда моделирования должна позволять нескольким командам независимо развивать свои модели метаданных, одновременно представляя единое представление всех метаданных, связанных с объектом данных.

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


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



Пример содержит три типа сущностей Пользователь, Группа и Набор данных представленных синими кружками на диаграмме. Мы используем стрелки для обозначения трех типов отношений между этими объектами, а именно OwnedBy, HasMember и HasAdmin. Другими словами, группа состоит из одного администратора и нескольких членов пользователя, которые, в свою очередь, могут владеть одним или несколькими наборами данных.


В отличие от традиционного ERD, мы помещаем атрибуты сущности и отношения непосредственно внутри круга и под именем отношения, соответственно. Это позволяет нам присоединять к объектам новый тип компонента, известный как аспекты метаданных. Разные команды могут владеть и развивать различные аспекты метаданных для одного и того же объекта, не мешая друг другу, таким образом выполняя требование моделирования распределенных метаданных. Три типа аспектов метаданных: владение, профиль и членство включены в приведенный выше пример в виде зеленых прямоугольников. Связь аспекта метаданных с сущностью обозначается пунктирной линией. Например, профиль может быть связан с пользователем, а владение может быть связано с набором данных и т. д.


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


Чтобы смоделировать пример в Pegasus, мы переведем каждую из сущностей, отношений и аспектов метаданных в отдельный файл схемы Pegasus (PDSC). Для краткости мы включим сюда только по одной модели из каждой категории. Во-первых, давайте взглянем на PDSC для объекта User:


{  "type": "record",  "name": "User",  "fields": [    {      "name": "urn",      "type": "com.linkedin.common.UserUrn",    },    {      "name": "firstName",      "type": "string",      "optional": true    },    {      "name": "lastName",      "type": "string",      "optional": true    },    {      "name": "ldap",      "type": "com.linkedin.common.LDAP",      "optional": true    }  ]}

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


Далее следует модель PDSC для отношения OwnedBy:


{  "type": "record",  "name": "OwnedBy",  "fields": [    {      "name": "source",      "type": "com.linkedin.common.Urn",    },    {      "name": "destination",      "type": "com.linkedin.common.Urn",    },    {      "name": "type",      "type": "com.linkedin.common.OwnershipType",    }  ],  "pairings": [    {      "source": "com.linkedin.common.urn.DatasetUrn",      "destination": "com.linkedin.common.urn.UserUrn"    }  ]}

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


Наконец, ниже вы найдете модель аспекта метаданных владения. Здесь мы решили смоделировать владение как массив записей, содержащих поля type и ldap. Однако при моделировании аспекта метаданных практически нет ограничений, если это действительная запись PDSC. Это позволяет удовлетворить требование метаданные это также данные, сформулированное ранее.


{  "type": "record",  "name": "Ownership",  "fields": [    {      "name": "owners",      "type": {        "type": "array",        "items": {          "name": "owner",          "type": "record",          "fields": [            {              "name": "type",              "type": "com.linkedin.common.OwnershipType"            },            {              "name": "ldap",              "type": "string"            }          ]        }      }    }  ]}

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


Получение метаданных


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


API DataHub основан на Rest.li, масштабируемой строго типизированной сервисной архитектуре RESTful, широко используемой в LinkedIn. Поскольку Rest.li использует Pegasus в качестве определения интерфейса, все модели метаданных, определенные в предыдущем разделе, могут использоваться дословно. Прошли те времена, когда требовалось преобразование нескольких уровней моделей от API до хранилища API и модели всегда будут синхронизироваться.


Ожидается, что для приема на основе Kafka производители метаданных будут генерировать стандартизированное событие изменения метаданных (MCE), которое содержит список предлагаемых изменений конкретных аспектов метаданных, введенных с помощью соответствующего URN объекта. Схема для MCE находится в Apache Avro, но автоматически создается из моделей метаданных Pegasus.


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


В LinkedIn мы склонны больше полагаться на поток Kafka из-за слабой связи, которую он обеспечивает между производителями и потребителями. Ежедневно мы получаем миллионы MCE от различных производителей, и ожидается, что их объем будет расти экспоненциально только по мере того, как мы расширяем объем нашей коллекции метаданных. Чтобы построить конвейер приема потоковых метаданных, мы использовали Apache Samza в качестве нашей платформы обработки потоковой информации. Задание Samza приема специально разработано, чтобы быть быстрым и простым для достижения высокой пропускной способности. Он просто преобразует данные Avro обратно в Pegasus и вызывает соответствующий API Rest.li для завершения приема.



Обслуживание метаданных


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


  1. Документно-ориентированные запросы
  2. Графические запросы
  3. Сложные запросы, включающие соединения
  4. Полнотекстовый поиск

Для этого DataHub необходимо использовать несколько типов систем данных, каждая из которых специализируется на масштабировании и обслуживании ограниченных типов запросов. Например, Espresso это база данных NoSQL LinkedIn, которая особенно хорошо подходит для масштабируемого документально-ориентированного CRUD. Точно так же Galene может легко индексировать и обслуживать полнотекстовый поиск в Интернете. Когда дело доходит до нетривиальных запросов к графам, неудивительно, что специализированная графовая БД может выполнять на порядки лучше, чем реализации на основе СУБД. Однако оказывается, что структура графа также является естественным способом представления отношений внешнего ключа, позволяя эффективно отвечать на сложные запросы соединения.


DataHub дополнительно абстрагирует базовые системы данных с помощью набора общих объектов доступа к данным (DAO), таких как DAO ключ-значение, запрос DAO и поиск DAO. После этого реализация DAO для конкретной системы данных может быть легко заменена, без изменения какой-либо бизнес-логики в DataHub. В конечном итоге это позволит нам открыть DataHub с открытым исходным кодом с эталонными реализациями для популярных систем с открытым исходным кодом, в то же время используя все преимущества проприетарных технологий хранения LinkedIn.



Еще одно ключевое преимущество абстракции DAO стандартизированный сбор данных об изменениях (CDC). Независимо от типа базовой системы хранения данных, любая операция обновления через DAO ключ-значение автоматически генерирует событие аудита метаданных (MAE). Каждый MAE содержит URN соответствующего объекта, а также изображения до и после определенного аспекта метаданных. Это позволяет использовать лямбда-архитектуру, в которой MAE могут обрабатываться как пакетами, так и потоками. Подобно MCE, схема MAE также автоматически генерируется из моделей метаданных.


Индексирование метаданных


Последний недостающий элемент головоломки конвейер индексации метаданных. Это система, которая объединяет модели метаданных и создает соответствующие индексы в графической БД и поисковой системе для облегчения эффективных запросов. Эти бизнес-логики фиксируются в форме построителя индексов и построителей графиков и выполняются как часть задания Samza, обрабатывающего MAE. Каждый разработчик зарегистрировал свой интерес к конкретным аспектам метаданных в задании и будет вызван с соответствующим MAE. Затем построитель возвращает список идемпотентных обновлений, которые будут применяться к БД индекса поиска или графа.


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



Заключение и с нетерпением жду


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


DataHub работает в LinkedIn в течение последних шести месяцев. Каждую неделю его посещают более 1500 сотрудников, которые поддерживают поиск, обнаружение и различные рабочие процессы для конкретных действий. График метаданных LinkedIn содержит более миллиона наборов данных, 23 системы хранения данных, 25 тысяч показателей, более 500 функций искусственного интеллекта и, что наиболее важно, всех сотрудников LinkedIn, которые являются создателями, потребителями и операторами этого графика.


Мы продолжаем улучшать DataHub, добавляя в продукт больше интересных пользовательских историй и алгоритмов релевантности. Мы также планируем добавить встроенную поддержку GraphQL и использовать язык Pegasus Domain Specific Language (PDL) для автоматизации генерации кода в ближайшем будущем. В то же время мы активно работаем над тем, чтобы поделиться этой эволюцией WhereHows с сообществом разработчиков ПО с открытым исходным кодом, а после публичного выпуска DataHub мы сделаем объявление.

Подробнее..

Да кто такой этот ваш Mobile DevOps?

20.12.2020 18:08:28 | Автор: admin

Сегодня почти у каждого проекта мобильного приложения есть базовая инфраструктура: ваш код хранится на git хостинге и весь новый код регулярно проверяется на CI, чтобы не сломать старый. Если ваша команда в несколько человек производит не очень много кода, то скорее всего вы настроили весь пайплайн один раз и радуетесь его работе. Но что если ваша мобильная команда это пара десятков или даже сотен разработчиков? Много разработчиков производят много кода, что создает нагрузку на инфраструктуру, увеличивает вероятность сломать важные флоу приложения и просто навсего унести время сборки проекта в небеса. Единожды кем-то настроенный пайплайн обречен на изменения, если он не справляется с нагрузкой.

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

Mobile DevOps существует, даже если вы о нем не знаете

Говорить на тему DevOps особенно в направлении Mobile можно сколько угодно. Это тема богата на детали, обсуждения, вопросы, альтернативы и многое другое. Можно прочитать море определений понятия DevOps, попытаться интегрировать сюда мобильную разработку, но так до конца и не понять что же это такое. Поэтому я приготовил для вас небольшой рассказ, который поможет понять что это за зверь - Mobile DevOps. А после самого рассказа, в ходе которого вы сами найдете ответы на вопросы, я дам немного пояснений, который прольют еще больше света на эту интересную тему. Устраивайтесь поудобнее и наслаждайтесь рассказом.

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

Представьте как выглядит обычный рабочий день Android разработчика Миши в компании Galera Development: Миша пришел в офис (или просто встал с кровати, ееее удаленка), приготовил себе чашечку кофе и сел за работу. Сегодня у него отличное настроение и работа обещает быть бодрой. Для разминки Миша берет задачу на простой фикс бага, быстро с ней справляется и создает пул реквест в develop. Остается дождаться успешной сборки на CI и пул реквест можно заливать. Миша на 200% уверен, что сборка пройдет успешно, ведь баг был прост, и он локально все проверил.

Но как оно иногда бывает - не все идет по плану. Сборка на пул реквест Миши почему-то не собралась. Наш герой подумал, что это какая-то разовая акция и перезапустил свою сборку. Проходит пара минут и Миша получает опять упавшую сборку. Что поделать, придется идти разбираться. Миша идет на CI в логи своей сборки и видит ошибку, которая совсем не похожа на те, что пишет Android Studio. Что-то на эльфийском - подумал он, но пул реквест заливать надо и надо как-то получить успешную сборку на CI. Миша слышал раньше, что настраивал CI его коллега Паша, и он наверняка должен знать как совладать с этим зверем.

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

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

Проходит час, и на почту Паше пишут уже 5 разработчиков, которые тоже знают, что Паша маг и знает что происходит на CI. У них такая же история как и у Миши час назад - падают сборки. Что делать? Паша сейчас занят важной фичей, которая принесет компании несколько сотен миллионов в первую же неделю релиза. Еще один человек знает как устроен этот ваш зверь CI, но теперь он руководит небольшой командой IOS разработчиков в другой компании. Да и если Паше бросать свою работу над фичей и погружаться в проблему на CI, то на обнаружение проблемы и ее решение уйдет много времени, ведь Паша сам уже не помнит когда в последний раз заглядывал на CI и смутно помнит как там все устроено.

Паша решает сообщить о возникшей ситуации своему руководителю Антону. Так как надо много чего обсудить, они договариваются на созвон.

Антон: Привет! Ну как там с билдами?

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

Антон: А еще не вариант тормозить всю разработку проблемой на CI! Предлагаю следующее: ты сейчас разбираешься с проблемой на CI, а я подключаю к тебе на разработку фичи еще 2 разработчиков, годится?

Паша: Другого варианта не вижу, так и поступим.

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

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

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

Когда он полгода назад поднимал эти ресурсы для команды мобильной разработки все летало, и команда на руках его носила за проделанную работу. Паша пытается понять причину упора в потолок по ресурсам, что такого произошло, что именно сегодня начали всплывать такие проблемы. Все оказалось просто: за последние 2 месяца в команду мобильной разработки пришло пара десятков новых разработчиков. Разумеется, команда стала писать больше кода, который надо собирать на CI, что и дало нагрузку, пик которой пришелся на сегодня. Вот это денек! Паша прикинул сколько ресурсов дополнительно потребуется и создал заявку на ресурсы администраторам серверов.

А еще Паша заметил, что время сборки проекта стало в 4 раза больше! Он когда-то для проекта занимался оптимизацией времени, но сделал лишь часть от того что знал и планировал, очередные горячие фичи были приоритетнее. Паша тогда сделал лишь те оптимизации, которые существенно ускоряют сборку, а те, что ускоряют не сильно, или будут ускорять, только если проект будет намного больше - не сделал. Об этом он сейчас вспомнил и отметил себе, чтобы рассказать Антону. Так и подошел конец рабочего дня. Паша звонит Антону и рассказывает об успехах.

А вы тоже уже на этом моменте подумали как будет затратно компании если Паша уйдет?

Антон: Как успехи?

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

Антон: Круто! Спасибо тебе, выручил. Теперь можешь спокойно возвращаться к работе над своей фичей.

Паша: На самом деле есть еще кое-что. Я посмотрел как изменилось время сборки в последнее время - оно сильно выросло. Теперь вместо прежних 10 минут это 45 минут. Я думаю с этим надо что-то делать.

Антон: Ну и кода у нас стало больше. Скорее всего это закономерно.

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

Антон: Даже если ты сейчас вернешься к работе над нашей фичей, то после нее тебя ждет другая, у нас очень много работы. Боюсь, оптимизацию придется отложить. Есть возражения?

Паша: Да. Сейчас расскажу почему. У нас работает 50 Android разработчиков, которые собирают свои пул реквесты на CI да и локально тоже, но сейчас не об этом. Сейчас сборка занимает примерно 45 минут. Я не говорю, что смогу ее ускорить до 10 прежних минут. Но проходить минут за 30 она точно будет, а в некоторых случаях и быстрее. То есть я предлагаю сэкономить на каждой сборке по 15 минут. В среднем разработчик собирает на CI по 2 пул реквеста в день. Это 0.5 часа в день экономии времени разработчика на ожидание сборки на CI и 0.5 часа занимаемых ресурсов. Ладно, отложим в сторону ресурсы и сосредоточимся на времени разработчиков: у нас 50 разработчиков, которые могут в день экономить по полчаса своего времени, то есть за месяц вся команда Android разработки сэкономит 50 разработчиков * 20 рабочих дней * 0.5 часа экономии = 500 часов разработки. Планирую я на это дело потратить примерно месяц, то есть 160 часов. Как видишь, заняться оптимизацией сейчас это просто отличная возможность сэкономить 500 часов Android разработки каждый месяц. Неплохо, не правда ли? Плюс, я могу покопаться со сборкой IOS проекта, думаю, там тоже есть большой задел для оптимизаций.

Антон: Ты заставил меня задуматься над этим. Давай я все обдумаю и созвонимся завтра. Решим что делать.

Паша: Договорились. До завтра.

Антон: Пока.

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

Наступает следующий день. Паша садится с кружкой кофе (но уже покрепче в 2 раза чем вчера) и начинает смотреть почту. В целом ничего интересного: поставили на ревью, накинули замечаний в его пул реквест с небольшим баг фиксом, уведомление об обновлении версии CI завтра, корпоративные новости, день рождение коллеги Погоди, что? Обновление версии CI завтра?! Паша понял, что без внимания этот момент оставить нельзя. Совсем неизвестно как это повлияет на его текущую конфигурацию, которая теперь более менее стабильно собирает проект, а еще не известно как повлияет на интеграцию CI с другими сервисами инфраструктуры. Похоже придется провести ряд проверок, которые займут неизвестно сколько времени, а обновление уже завтра. Вот и еще одна тема для обсуждения с Антоном.

Антон: Доброе утро! Я тут все обдумал, и, кажется, ты прав, нам стоит провести ряд оптимизаций.

Паша: Привет! Это отличная новость. Когда приступать?

Антон: Можешь приступать прямо сейчас. И еще один момент, в связи с тем, что мы в последнее время довольно часто подходим к релизу со сломанными основными сценариями, которые находят, слава Богу, тестировщики, а не пользователи, то мы решили завозить в проект UI тесты, чтобы мы были уверены, что новые фичи не ломают наши основные сценарии. Прогнали UI тесты - сразу убедились, что основные сценарии целы, круто, правда? И поэтому надо научить наш CI прогонять эти UI тесты. Я пока без малейшего понятия как это реализовать, поэтому в первую очередь говорю об этом тебе. Было бы здорово, если бы ты занялся этой инфраструктурной задачей.

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

Антон: Да, конечно. Более того, я подумал над всеми этими задачами, заглянул в наш бэклог и нашел еще несколько задач на оптимизацию наших процессов, которые могут тоже неплохо сэкономить нам ресурсы разработчиков. Я прикинул, затраты на выполнение этих инфраструктурных задач окупятся даже в ближайший квартал! Плюс, я планирую обсудить задачи такого типа еще и с IOS командой, у них наверняка тоже что-то есть. Поэтому я сделал запрос на найм к нам в команду еще одного инженера, который бы помог организовать работу нашей инфраструктуры. В общем решили искать Mobile DevOps инженера, если можно так выразиться конечно. Будем надеяться что получится найти такого, хоть и на рынке Mobile DevOps инженеров единицы. Ну а пока ты ответственный за работу нашей инфраструктуры, можешь довести до конца свои текущие Android задачи и заняться инфраструктурой. Если все-таки не получится нанять Mobile DevOps a, то тебе нужно будет взять кого-то к себе в команду, кто хотел бы заниматься инфраструктурой и ввести в курс дела. Что скажешь насчет всего этого?

Паша: Звучит здорово. Я в деле. При таком раскладе у меня есть срочная инфраструктурная задача: от админов пришло письмо, в котором сообщается об обновлении нашего CI, надо срочно проверить что в новой версии все будет работать по прежнему и всякие интеграции тоже. Планирую ей сейчас заняться.

Антон: Спасибо, что заметил это письмо и понял чем оно может для нас обернуться. Тогда не буду тебя отвлекать. О деталях твоих новых рабочих процессов поговорим позже. Поздравляю, теперь ты Mobile DevOps, ахахаха!

Паша: Договорились. Спасибо! Хорошего дня!

Антон: Спасибо, и тебе!

И Паша отправился непростой и интересной дорогой Mobile DevOps инженера!

Что я только что прочитал?

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

  1. Что такое Mobile DevOps?

  2. Какие проблемы Mobile DevOps решает?

  3. Как Mobile DevOps решает проблемы?

  4. Как получить Mobile DevOps инженера в команду?

  5. Как стать Mobile DevOps инженером?

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

Что такое Mobile DevOps?

Здесь я не скажу ничего особо отличающегося от понятия классического DevOps. Это все так же Development и Operations, но в области мобильной разработки. Инженер, занимающийся Mobile DevOps, занимается не только разработкой и поддержкой инфраструктуры (как мы увидели в рассказе мага Пашу, который умел колдовать на CI, оптимизировать сборку с помощью магического Gradle и многое другое), но и совершенствованием процессов мобильных команд (когда Паша начал продумывать как проверять UI тесты для нового кода коллег, чтобы не сломать существующий код).

Про первую часть Development вам всегда будет напоминать огромный список задач в бэклоге, про нее вы никогда не забудете. А вот про вторую часть действительно стоит помнить. Главная цель нашего Mobile DevOps - обеспечивать команде эффективную и комфортную работу. Мы должны прислушиваться к команде, слушать когда они говорят о своих болях и пытаться их решить инструментами, которые мы можем даже пока и не знать.

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

Какие проблемы Mobile DevOps решает?

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

  1. CI. Создание CI сервера, его конфигурирование, общение с админами по поводу обеспечения сервера ресурсами. Настройка сборок для всех проектов команды.

  2. Оптимизация сборок. Конфигурирование системы сборки (например, Gradle для Android) проекта для обеспечения наилучшего времени сборки как локально, так и на CI. Обеспечение эффективного использования кэша сборки.

  3. Автоматические проверки кода. Это могут быть простые тулзы-анализаторы код стайла типа Sonar или Detekt, а может что-то посложнее и самописное в виде Gradle тасок, например, таска для проверки соответствия правилам зависимостей проекта.

  4. Прогон UI тестов на CI. Обеспечение работы набора устройств или эмуляторов и обеспечение возможности прогона на них UI тестов.

  5. Impact analysis. Анализ измененного кода для получения списка затронутых UI тестов, которые надо прогнать, чтобы убедиться, что в новом коде разработчик не сломал старый.

  6. Интеграция сервисов инфраструктуры. Обеспечение стабильной интеграции сервисов инфраструктуры типа CI, git-хостинга кода и других сервисов.

  7. Release Train. Автоматизация процесса релиза вплоть до автоматического деплоя бандла в Play Console и раскатки его в продакшн.

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

Как Mobile DevOps решает проблемы?

Тут все по классике: чтобы решить проблему ее нужно понять. Как я уже говорил ранее - понимание процессов команды невероятно важно в работе Mobile DevOps инженера. Это поможет выявить слабые места в процессах и усилить их.

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

Вот примеры инструментов, с помощью которых можно решить инфраструктурные и процессные проблемы:

  1. Gradle таски, которые будут выполняться в нужный момент (для Android)

  2. Gradle плагины (для Android)

  3. Скрипты, которые могут выполняться как вручную, так и автоматически, например, на CI

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

  5. Создание клиент-серверных приложений на различном стеке технологий

  6. Контейнеризация для изоляции ваших сервисов, автоматизации их развертки и конфигурирования

  7. Виртуализация для работы с эмуляторами

  8. Создание плагинов для любого из сервисов вашей инфраструктуры, если есть открытое API

И это только примеры. Разумеется, инструменты могут быть невероятно различными.

Как получить Mobile DevOps инженера в команду?

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

Но хочу отметить, что ваш новоиспеченный Mobile Devops только вчера занимался парсингом jsonа и передвигал кнопки, поэтому не стоит требовать решения проблем в совсем ближайшее время. Специфика работы и инструменты решения проблем Mobile DevOps сильно отличается от Android или IOS разработки, и развитие вашего инженера будет постепенным. Через какое-то время (это может быть полгода, год, все очень ситуативно) ваш инженер будет действительно способен решать ваши проблемы быстро и качественно. И вы будете счастливы и горды, что в вашей команде есть такой специалист.

Но также есть альтернатива, которая довольно привлекательна. Мы живем в такое время, когда все технологии и процессы развиваются стремительно и есть компании, которые уже активно практикуют Mobile DevOps. Их инженеры уже решили много проблем и имеют большой опыт в практике DevOps в направлении мобильной разработки. Это все те же люди, которые постоянно развиваются и ищут новые возможности, поэтому можно попытать удачу и поискать такого инженера в сервисах для поиска работы. Разумеется найти инженера с таким уникальным опытом намного сложнее, чем Android разработчика или IOS разработчика, но они тоже люди и бывают открыты предложениям.

Сколько нужно Mobile DevOps инженеров?

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

А почему бы просто не привлечь настоящего DevOps?

Как я уже говорил ранее, DevOps это не только про инфраструктуру, но и про процессы. Человек, который варился много времени в процессах Android или IOS команд, хорошо понимает специфику работы и отлично понимает боли команд, потому что сам их скорее всего испытывал. Да, он пока не так хорош в инфраструктуре, как обычный DevOps, но все это можно изучить и наверстать. Сам опыт процессов невероятно важен и если вы получите к себе в команду Mobile DevOps (обучите своего или, если повезет, найдете на рынке), то станете действительно богаты в плане ресурсов инженеров.

Что делать, если вы хотите стать Mobile DevOps инженером?

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

Заключение

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

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

Подробнее..

Стенды разработки без очередей и простоев

23.03.2021 08:12:20 | Автор: admin

Цель статьи - показать один из возможных подходов для организации гибкого развёртывания dev/test стендов. Показать какие преимущества предоставляет нам IaC подход в сочетании с современными инструментами.


Предыстория

Имеется несколько стендов для разработчиков - devs, tests, production. Новые версии компонентов продукта появляются несколько раз в день.

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

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

Задача

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

Стек

Gitlab CI, Terraform, Bash, любое приватное/публичное облако.

Технические сложности:

  1. Terraform state file - из коробки у нас нет возможности использовать переменную в значенииимени state файла. Нужно что-то придумывать или использовать другой продукт.

  2. Subnets - каждое новое окружение должно быть создано в изолированной подсети. Нужно контролировать свободные/занятые подсети, некий аналог DHCP, но для подсетей.

Алгоритм

  1. Gitlab CI выполняет pipeline. Связывает все остальные компоненты воедино.

  2. Terraform создаёт и удаляет экземпляры виртуальных машин.

  3. Configuration manager(CM) - разворачивает сервисы.

  4. Bash сценарии подготавливают конфигурационные файлы специфичные для каждого стенда.

Структура репозитория

development-infrastructure/  deploy/    env1/      main.tf      backend.tf     ansible-vars.json       subnets.txt     env2/    ...  cm/    ...  modules/    azure/      main.tf      variables.tf  scripts/    env.sh    subnets.txt   .gitlab-ci.yml
  • deploy - содержит специфичные для каждого окружения файлы - файл с переменными для terraform и CM, файл содержащий адрес подсети стенда.

  • cm - в моём случае, тут хранятся Ansible плейбуки для настройки ОС и разворачивания сервисов.

  • modules - модули terraform которые будут получать в качестве параметров имя окружения и адрес подсети

  • scripts - bash сценарии для создания и удаления стендов и их конфигураций

.gitlab-ci.yml:

stages:  - create environment  - terraform apply  - cm  - destroy environment .template: variables: ENV: $NAME_ENV  when: manual tags: [cloudRunner01]  only:   refs:    - triggers Create environment:  stage:create environment  extends: .template script:   - ./scripts/create_env.sh -e $ENV -a create  artifacts:   paths:    - deploy/${ENV}/backend.tf    - deploy/${ENV}/main.tf    - deploy/${ENV}/vars.json Create instances:  stage: terraform apply extends: .template  script:   - cd ./deploy/$ENV   - terraform init -input=false   - terraform validate   - terraform plan -input=false -out=tf_plan_$ENV   - terraform apply -input=false tf_plan_$ENV Deploy applications:  stage: cm  extends: .template  script:   - # мы можем передать имя окружения в качестве параметра нашей CM   - # в моём случае, на основе переменной $ENV генерируются сертификаты,   - # конфигурируется обратный прокси сервер и т.п.   - # также мы можем использовать данные из terraform Destroy instances and environment:  stage:destroy environment  extends: .template  script:   - cd ./deploy/$ENV   - terraform init -input=false   - terraform destroy -auto-approve   - ./scripts/delete_env.sh -e $ENV -a delete 

Остановимся подробнее на каждом шаге нашего пайплайна:

  • Create environment - на основе имени окружения, полученного из переменно NAME_ENV, создаём уникальные для окружения файлы, после чего помещаем их в наш git репозиторий.

  • Create instances - создаём инстансы(виртуальные машины) и подсети, которые будут использоваться окружением.

  • Deploy applications - разворачиваем наши сервисы с помощью любимого Configuration Manager.

  • Destroy instances and environment - с помощью bash сценария данный шаг удалит наши инстансы, после чего удалит из репозитория каталог с файлами окружения. Освободившаяся подсеть будет возвращена в файл scripts/subnets.txt.

Запуск пайплайна происходит с объявлением переменной NAME_ENV, содержащей имя нового стенда:

Разработчики не имеют доступа к Git репозиторию и могут вносить в него изменения только через запуск pipeline.

modules/base/main.tf:

# лучшие практики и личный опыт настоятельно рекомендуют фиксировать версию провайдера provider "azurerm" { version = "=1.39.0" }  # создаём новую группу ресурсов, это особенность Azure. Имя группы уникально, в этом случае будет удобно использовать имя окружения resource "azurerm_resource_group" "product_group" { name= "${var.env_name}" location = "East Europe" } # создаем сеть resource "azurerm_virtual_network" "vnet" { name= "product-vnet" resource_group_name = azurerm_resource_group.product_group.name location= azurerm_resource_group.product_group.location address_space= [var.vnet_address] } #используем подсеть полученную с помощью bash сценария resource "azurerm_subnet" "subnet" { name= "product-subnet" resource_group_name= azurerm_resource_group.product_group.name virtual_network_name = azurerm_virtual_network.vnet.name address_prefix= var.subnet_address } # теперь можем создать виртуальную машинуresource "azurerm_virtual_machine" "product_vm" { name= "main-instance" location= azurerm_resource_group.product_group.location resource_group_name= azurerm_resource_group.product_group.name network_interface_ids = [azurerm_network_interface.main_nic.id]   } # прочие ресурсы и виртуальные машины... 

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

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

scripts/env.sh:

#!/bin/bash set -eu CIDR="24" DEPLOY_DIR="./deploy" SCRIPT_DIR=$(dirname "$0") usage() { echo "Usage: $0 -e [ENV_NAME] -a [create/delete]" echo "-e: Environment name" echo "-a: Create or delete" echo "-h: Help message" echo "Examples:" echo "$0 -e dev-stand-1 -a create" echo "$0 -e issue-1533 -a delete" } while getopts 'he:a:' opt; do case "${opt}" in e) ENV_NAME=$OPTARG ;; a) ACTION=$OPTARG ;; h) usage; exit 0 ;; *) echo "Unknown parameter"; usage; exit 1;; esac done if [ -z "${ENV_NAME:-}" ] && [ -z "${ACTION:-}" ]; then usage exit 1 fi # приводим имя окружения к нижнему регистру ENV_NAME="${ENV_NAME,,}" git_push() { git add ../"${ENV_NAME}" case ${1:-} in create) git commit -am "${ENV_NAME} environment was created" git push origin HEAD:"$CI_COMMIT_REF_NAME" -o ci.skip echo "Environment ${ENV_NAME} was created.";; delete) git commit -am "${ENV_NAME} environment was deleted" git push origin HEAD:"$CI_COMMIT_REF_NAME" -o ci.skip echo "Environment ${ENV_NAME} was deleted.";; esac } create_env() { # создаём каталог для нового окружения if [ -d "${DEPLOY_DIR}/${ENV_NAME}" ]; then echo "Environment ${ENV_NAME} exists..." exit 0 else mkdir -p ${DEPLOY_DIR}/"${ENV_NAME}" fi # получаем адрес подсети NET=$(sed -e 'a$!d' "${SCRIPT_DIR}"/subnets.txt) sed -i /"$NET"/d "${SCRIPT_DIR}"/subnets.txt echo "$NET" > ${DEPLOY_DIR}/"${ENV_NAME}"/subnets.txt if [ -n "$NET" ] && [ "$NET" != "" ]; then echo "Subnet: $NET" SUBNET="${NET}/${CIDR}" else echo "There are no free subnets..." rm -r "./${DEPLOY_DIR}/${ENV_NAME}" exit 1 fi   pushd "${DEPLOY_DIR}/${ENV_NAME}" || exit 1 # Создаем main.tf terraform файл с нужными нам переменными нового окружения cat > main.tf << END module "base" { source = "../../modules/azure" env_name = "${ENV_NAME}" vnet_address = "${SUBNET}" subnet_address = "${SUBNET}" } END # Cоздаём backend.tf terraform файл , в котором указываем имя нового state файла cat > backend.tf << END terraform { backend "azurerm" { storage_account_name = "terraform-user" container_name = "environments" key = "${ENV_NAME}.tfstate" } } END } delete_env() { # удаляем каталог окружения и высвобождаем подсеть if [ -d "${DEPLOY_DIR}/${ENV_NAME}" ]; then NET=$(sed -e '$!d' ./${DEPLOY_DIR}/"${ENV_NAME}"/subnets.txt) echo "Release subnet: ${NET}" echo "$NET" >> ./"${SCRIPT_DIR}"/subnets.txt pushd ./${DEPLOY_DIR}/"${ENV_NAME}" || exit 1 popd || exit 1 rm -r ./${DEPLOY_DIR}/"${ENV_NAME}" else echo "Environment ${ENV_NAME} does not exist..." exit 1 fi } case "${ACTION}" in create) create_env git_push "${ACTION}" ;; delete) delete_env git_push "${ACTION}" ;; *) usage; exit 1;; esac 
  1. Сценарий env.shпринимает два параметра - имя окружения и действие(создание\удаление).

  2. При создании нового окружения:

  3. В каталоге DEPLOY_DIRсоздаётся директория с именем окружения.

  4. Из файла scripts/subnets.txt мы извлекаем одну свободную подсеть.

  5. На основе полученных данных генерируем конфигурационные файлы для Terraform.

  6. Для фиксации результата отправляем каталог с файлами окружения в git репозиторий.

  7. При удалении -сценарий удаляет каталог с файлами окружения и возвращает освободившуюся подсеть в файл scripts/subnets.txt

scripts/subnets.txt:

172.28.50.0172.28.51.0172.28.52.0...

В данном файле мы храним адреса наши подсетей. Размер подсети определяется переменной CIDR в файлеscripts/create_env.sh

Результат

  1. Мы получили фундамент который позволяет нам развернуть новый стенд путём запуска piplinea в Gitlab CI.

  2. Снизили затраты нашей компании на инфраструктуру.

  3. Разработчики не простаивают и могут создавать и удалять стенды когда им это потребуется.

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

  5. Можем поиграться с триггерами Gitlabи разворачивать новые стенды из пайплайнов команд разработчиков передавая версии сервисов.

Подробнее..

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

24.06.2020 14:16:49 | Автор: admin


В конце мая мы провели онлайн-митап на тему Современная инфраструктура и контейнеры: проблемы и перспективы. Поговорили о контейнерах, Kubernetes и оркестрации в принципе, о критериях выбора инфраструктуры и многом другом. Участники поделились кейсами из собственной практики.

Участники:

  • Евгений Потапов, CEO ITSumma. Больше половины его клиентов либо уже переходят, либо хотят перейти на Kubernetes.
  • Дмитрий Столяров, CTO Флант. Обладает 10+ годами опыта работы с контейнерными системами.
  • Денис Ремчуков (aka Eric Oldmann), COO argotech.io, ex-РАО ЕЭС. Пообещал рассказать о кейсах в кровавом энтерпрайзе.
  • Андрей Федоровский, CTO News360.comПосле покупки компании другим игроком отвечает за ряд ML и AI проектов и за инфраструктуру.
  • Иван Круглов, системный инженер, exBooking.com.Тот самый человек, который своими руками сделал с Kubernetes очень многое.


Темы:

  • Инсайты участников про контейнеры и оркестрацию (Docker, Kubernetes и прочее); что пробовали на практике или анализировали.
  • Кейс: В компании строят план развития инфраструктуры на годы. Как принимается решение, строить (или переводить текущую) инфраструктуру на контейнерах и Кубер или нет?
  • Проблемы в мире cloud-native, чего не хватает, давайте пофантазируем, что будет завтра.


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



Kubernetes это уже стандарт или отличный маркетинг?


Мы к нему (Kubernetes. Ред.) пришли тогда, когда о нем еще никто не знал. Мы к нему пришли еще тогда, когда его не было. Мы его хотели до этого Дмитрий Столяров


Фото с Reddit.com

Лет 5-10 назад существовало огромное количество инструментов, и не было единого стандарта. Каждые полгода появлялся новый продукт, а то и не один. Сначала Vagrant, затем Salt, Chef, Puppet, и ты каждые полгода перестраиваешь свою инфраструктуру. У тебя пять админов, которые постоянно заняты тем, что переписывают конфиги вспоминает Андрей Федоровский. Он считает, что Docker и Kubernetes задавили остальных. Docker стал стандартом в течение последних пяти лет, Kubernetes в последние два года. И это хорошо для индустрии.

Дмитрий Столяров и его команда любят Кубер. Они хотели такой инструмент до того как он появился, и пришли к нему когда о нем еще никто не знал. На текущий момент, из соображений удобства, они не берут клиента, если понимают, что не внедрят у него Kubernetes. При этом, по словам Дмитрия, у компании множество гигантских success story по переделке жуткого legacy.

Kubernetes это не только контейнерная оркестрация, это система управления конфигурацией с развитым API, компонентом работы с сетью, L3 балансировкой и Ingress контроллерами, которая позволяет относительно легко управлять ресурсами, масштабироваться и абстрагироваться от нижних слоев инфраструктуры.

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

Евгений провел аналогию с ситуацией в 1990-х годах, когда появилось объектно-ориентированное программирование, как способ программирования сложных приложений. На тот момент не прекращались дебаты и появлялись новые инструменты, поддерживающие ООП. Затем появились микросервисы как способ уйти от монолитной концепции. Это, в свою очередь, привело к появлению контейнеров и инструментов их управления. Я думаю, что скоро мы придем к тому времени, когда не будет стоять вопрос о том, стоит ли писать микросервисно маленькое приложение, его будут писать по дефолту микросервисом, считает он. Аналогично, Docker и Kubernetes со временем станут стандартным решением без необходимости выбора.

Проблема баз в stateless



Photo by Twitter: @jankolario on Unsplash

В наше время найдется много рецептов запуска баз данных в Kubernetes. Даже как отделять часть, работающую с диском I/O от, условно, application части базы. Возможно ли, что в будущем базы данных видоизменятся настолько, что будут поставляться в коробке, где одна часть будет оркестрироваться через Docker и Kubernetes, а в другой части инфраструктуры, через отдельный софт, будет предоставляться storage часть? Базы видоизменятся как продукт?

Это описание похоже на менеджмент очередей, но требования к надежности и синхронности информации в традиционных базах данных предъявляются гораздо выше, считает Андрей. Cache hit ratio в нормальных базах держится на уровне 99 %. Если worker ложится, запускается новый, и кэш разогревается с нуля. Пока кэш не разогрет, worker работает медленно, значит на него нельзя пускать пользовательскую нагрузку. Пока нет пользовательской нагрузки, кэш не разогревается. Это замкнутый круг.

Дмитрий в корне не согласен, кворумы и шардирование решают проблему. Но Андрей настаивает, что решение подходит не всем. В некоторых ситуациях подойдет кворум, но он дает дополнительную нагрузку на сеть. База NoSQL подходит не во всех случаях.

Участники митапа разделились на два лагеря.

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

Даже современные cloud native базы, такие как MongoDB и Cassandra, или очереди сообщений, как Kafka или RabbitMQ, требуют постоянные хранилища данных вне Kubernetes.

Евгений возражает: Базы в Кубере травма околороссийская, или околоэнтерпрайзная, которая связана с тем, что в России Cloud Adoption нет. Малые или средние компании на Западе это Cloud. Базы Amazon RDS использовать проще, чем самим возиться с Kubernetes. В России используют Кубер on-premise и переносят в него базы, когда пытаются избавиться от зоопарка.

Дмитрий тоже не согласился с утверждением, что никакие базы нельзя держать в Kubernetes: База базе рознь. И если пихать гигантскую реляционную базу то ни в коем случае. Если пихать что-то небольшое и cloud native, что морально готово к полуэфемерной жизни, все будет хорошо. Дмитрий упомянул также, что инструменты управления базами не готовы ни к Docker, ни к Kuber, поэтому возникают большие сложности.

Иван, в свою очередь, уверен, что даже если абстрагироваться от понятий stateful и stateless, экосистема энтерпрайзных решений в Kubernetes еще не готова. С Кубером сложно поддерживать требования законодательных и регулирующих органов. Например, невозможно сделать решение предоставления identity, где требуются строгие гарантии идентификации сервера, вплоть до железа, которое вставляется в серверы. Эта сфера развивается, но пока решения нет.
Участникам не удалось договориться, поэтому в этой части выводов не последует. Лучше приведем пару практических примеров.

Кейс 1. Кибербезопасность мегарегулятора с базами вне Кубера


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

Кейс 2. Частичный переезд баз данных Booking.com в Kubernetes


В Booking.com основная база данных это MySQL с асинхронной репликацией есть master и целая иерархия слейвов. К моменту ухода Ивана из компании был запущен проект по переносу cлейвов, которые можно отстрелить с определенным ущербом.

Помимо основной базы есть инсталляция Cassandra с самописной оркестрацией, которую писали еще до того как Кубер вышел в мейнстрим. Проблем в этом плане нет, но у нее persistent на локальные SSD. Удаленный хранилища, даже в рамках одного дата-центра, не используются из-за проблемы с высокой задержкой.

Третий класс баз данных это поисковый сервис Booking.com, где каждая нода сервиса является базой данных. Попытки перенести поисковый сервис в Кубер не удались, потому что каждая нода это 6080 Гб локального storage, которые сложно поднять и разогреть.

В итоге поисковый движок в Kubernetes не перенесли, и Иван не думает, что будут новые попытки в ближайшее время. База MySQL была перенесена наполовину: только Слейвы, которые не страшно отстрелить. Cassandra прижилась отлично.

Выбор инфраструктуры как задача без общего решения



Photo by Manuel Geissinger from Pexels

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

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

Иван: Я бы сейчас, безусловно, стартовал компанию в сloud, просто потому, что это быстрее, хотя не обязательно дешевле. С развитием венчурного капитализма у стартапов с деньгами больших проблем нет, и основная задача завоевать рынок.

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

Налог заплатить придется в любом случае, и Иван платил бы тот, который позволил ему в будущем платить меньше. Потому что просто за счет того, что я еду в поезде, который двигают другие, я проеду намного дальше, чем если я сяду в другой поезд, в который мне придется топливо закидывать самому. говорит Иван. Когда компания новая, и требования к latency десятки миллисекунд, то Иван смотрел бы в сторону операторов, в которые сегодня заворачивают классические базы данных. Они поднимают replication chain, который сам переключается в случае failover и т.п

Для маленькой компании с парой серверов в Кубере смысла нет, утверждает Андрей. Но если она планирует вырасти до сотни серверов и больше, то нужна автоматизация и система управления ресурсами. 90 % случаев оправдывают затраты. Причем вне зависимости от уровня нагрузки и ресурсов. Всем, начиная от стартапов, заканчивая крупными компаниями с миллионной аудиторией, имеет смысл постепенно смотреть в сторону продуктов для оркестрации контейнеров. Да, это действительно будущее, уверен Андрей.

Денис обозначил два главных критерия масштабируемость и устойчивость работы. Он выберет те инструменты, которые лучше всего подходят для этой задачи. Это может быть на коленке собранный ноунейм, и на нем Nutanix Community Edition. Это может быть вторая линия в виде application на Kuber с базой данных на бэкенде, которая реплицируется и имеет заданные параметры RTO и RPO (recovery time/point objectives прим).

Евгений обозначил возможную проблему с кадрами. На текущий момент на рынке не так много высококлассных специалистов, разбирающихся в кишках. Действительно, если выбранная технология стара, то сложно нанять кого-то, кроме немолодых скучающих и уставших от жизни людей. Хотя другие участники считают, что это вопрос подготовки кадров.
Если поставить вопрос выбора: запускать небольшую компанию в Public Cloud с базами в Amazon RDS или on premise с базами в Kubernetes, то несмотря на некоторые недостатки, выбором участников стал Amazon RDS.

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

Оценка использования Kubernetes


Слушатель Антон Жбанков задал вопрос-западню апологетам Kubernetes: как выбирали и проводили технико-экономическое обоснование? Почему Kubernetes, почему не виртуальные машины, например?


Photo by Tatyana Eremina on Unsplash

На него ответили Дмитрий и Иван. В обоих случаях методом проб и ошибок, была сделана последовательность решений, в результате которой оба участника пришли к Kubernetes. Сейчас бизнес начинает самостоятельно разрабатывать софт, который имеет смысл переносить в Кубер. Речь не идет о классических сторонних системах, типа 1С. Kubernetes помогает, когда разработчикам нужно оперативно делать релизы, при безостановочном Continuous Improvement.

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

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

Что нас ждёт



Photo by Drew Beamer on Unsplash

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

Не кажется ли вам, что наступит момент, когда появится инструмент, каким стала Ubuntu для мира Linux? Возможно, единый инструмент контейнеризации и оркестрации включит в себя и Кубер. С ним станет просто строить on-premise облака.

Ответ дал Иван: Google сейчас строит Anthos это их пакетное предложение, которое разворачивает облако и включает в себя Kuber, Service Mesh, мониторинг, всю обвязку, которая нужна для микросервисов в on-premise. Мы почти в будущем.

Денис также упомянул Nutanix и VMWare с продуктом vRealize Suite, которые могут справляются с подобной задачей без контейнеризации.

Дмитрий поделился мнением, что уменьшение боли и снижение налога это два направления, где стоит ожидать улучшений.

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


    Остальные выводы делать вам. Пока остается ощущение, что связке Docker+Kubernetes непросто стать центральной частью системы. Например, операционные системы ставятся на железку первыми, чего нельзя сказать о контейнерах и оркестрации. Возможно, в будущем срастутся операционки и контейнеры с cloud management софтом.


    Photo by Gabriel Santos Fotografia from Pexels

    Пользуясь случаем напомню, что у нас есть фейсбук-группа Управление и разработка крупных IT-проектов, канал @feedmeto с интересными публикациями из разных техно-блогов. И мой канал @rybakalexey, где я рассказываю об управлении разработкой в продуктовых компаниях.
Подробнее..

SaaS и ALEPIZ мониторинг и управление инфраструктурой

20.05.2021 12:07:50 | Автор: admin

Я системный администратор, более 20 лет занимаюсь управлением и мониторингом критичной в масштабах страны инфраструктуры. Услуги, которые я администрирую, предоставляются по модели SaaS (Software as a Service аренда ПО). Это моя первая публикация, я решил поделиться своими наработками в этой области, возможно кому-то это будет полезно.

ALEPIZ распространяется бесплатно по лицензии GPL v3ALEPIZ распространяется бесплатно по лицензии GPL v3

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

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

История

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

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

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

Я решил учесть ошибки и разработать новую систему. Большинство продуктов создаются разработчиками ПО, а я системный администратор. Я хуже знаю процесс разработки, но проектирование и реализация системы для системных администраторов в данном случае сделана системным администратором, с учетом нюансов нашей работы. Считаю, что это положительно сказалось на конечном результате

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

ALEPIZ

Новая система получила название ALEPIZ. Я не планировал ее распространять, но создание системы затянулось. Чтобы не платить за средства разработки я выполнил условия для их бесплатного использования: выложил ПО на GitHub под лицензией GPL v3 и создал сайт alepiz.com.

Data Browser служит для отображения собранных исторических данныхData Browser служит для отображения собранных исторических данных

Архитектура системы

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

Тестирование и эксплуатация ведется под ОС Microsoft Windows. Выбор ОС продиктован архитектурой программного обеспечения, которое используется в моей организации.

Для возможности портирования в будущем на другие архитектуры, в качестве платформы были выбраны JavaScript и NodeJS. Это так же позволило унифицировать разработку backend и frontend и использовать асинхронность JavaScript для достижения требуемой производительности. Применение потоков (threads) в NodeJS невозможно из-за отсутствия поддержки во многих модулях, поэтому используется схема с запуском нескольких процессов.

В ALEPIZ встроен Web сервер и сервер БД на основе быстрой и простой SQLITE. При развертывании системы нет необходимости в установке дополнительного ПО: ALEPIZ включает все требуемые компоненты. Для ускорения работы с БД реализована система кэширования, разработанная специально для ALEPIZ.

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

Сейчас ALEPIZ обслуживает одновременно более 250 000 метрик. Их количество постоянно увеличивается. Сбор данных по метрике происходит примерно раз в 3060 секунд. Исторические данные хранятся три месяца и база данных занимает около 1Тб. Для работы используется сервер с двумя процессорами Intel, по двенадцать ядер в каждом. Суммарная загрузка процессоров около 40% и зависит от количества расчетов, выполняемых ALEPIZ. Потребление памяти 64Gb. В качестве дисковой подсистемы используется RAID10 из 8 HDD 10 000 Rpms. Репликация и резервное копирование БД производится по сети на другой сервер.

Системные требования

Для работы ALEPIZ требуется компьютер архитектуры Intel x64 с установленной ОС Microsoft Windows версии не ниже Windows Server 2012 или Windows 10. После установки ALEPIZ использует 200Mb дискового пространства. Потребление оперативной памяти на сервере с 12 ядрами CPU составляет 1Gb. При меньшем количестве ядер потребление памяти будет уменьшено.

Описание возможностей

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

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

Dashboard позволяет обрабатывать произошедшие событияDashboard позволяет обрабатывать произошедшие события

ALEPIZ является не только системой мониторинга, но и системой для управления инфраструктурой. Для этого существуют специальные модули - действия. Например, действием может быть запуск или остановка внешнего сервиса, редактирование файла настроек, выполнения запросов к БД или копирование файлов для обновления ПО. Можно разрабатывать собственные действия.

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

Описание возможностей системы есть на сайте ALEPIZ и доступно на русском языке.

Сущности системы

Чтобы получить больше информации о принципах работы системы и ее возможностях, немного погрузимся в ALEPIZ.

Коллекторы

Для сбора данных используются модули, которые называются коллекторами (collectors). Например, коллектор PING используется для проверки доступности хостов по протоколу ICMP. Коллектор SNMP необходим для сбора данных по одноименному протоколу. MSSQL служит для выполнения запросов к БД MSSQL и т.п. На момент написания статьи в ALEPIZ реализован 21 коллектор. Можно разработать собственный. Информация о разработке коллектора и средства для разработки встроены в ALEPIZ.

Counter settings служит для настройки каунтераCounter settings служит для настройки каунтера

Каунтеры

Каунтеры (counters) это коллекторы с параметрами, которые определяют, какие данные необходимо собирать. Например, для того чтобы коллектор PING начал собирать информацию, ему в качестве параметра необходимо передать имя хоста, доступность которого требуется проверять. Параметры для коллекторов настраиваются в каунтерах.

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

Активные и пассивные коллекторы. Зависимости в каунтерах

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

Например, каунтер с активным коллектором Timer генерирует данные через определенные интервалы времени. Если от него сделать зависимым каунтер с пассивным коллектором SNMP, то данные по протоколу SNMP будут собираться через определенные каунтером интервалы времени. Если от каунтера с SNMP сделать зависимым каунтер с коллектором Events generator, то в случае превышения установленного порогового значения, в Dashboard появится предупреждение о возможной проблеме.

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

Объекты

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

Object editor необходим для редактирования объектов и их привязки к каунтерамObject editor необходим для редактирования объектов и их привязки к каунтерам

Связь объектов и каунтеров

Каунтеры не могут существовать сами по себе. Каждый каунтер должен быть привязан к одному или нескольким объектам. У объектов можно настроить свойства, которые будут использовать каунтеры для сбора или генерации информации. Например, объект хост может содержать свойство IP адрес, который будет использован каунтером с коллектором PING для проверки доступности этого хоста. Каунтер с коллектором PING можно привязать к нескольким объектам- хостам и он будет собирать данные в зависимости от настроенных свойств (IP адреса) для каждого из объектов.

Действия

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

Можно разработать собственные действия. Информация и средства для разработки встроены в ALEPIZ.

Задачи

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

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

Tasks maker используется для управления задачамиTasks maker используется для управления задачами

Остальные возможности

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

Заключение

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

Не обязательно использовать сразу все возможности ALEPIZ. Если у Вас небольшая инфраструктура, или в настоящее время нет потребности в автоматическом управлении, можно использовать только часть функций, например, только мониторинг. В дальнейшем у Вас будет возможность расширения и внедрения автоматизации в систему управления инфраструктурой.

Хотел бы еще раз повторить: ALEPIZ распространяется бесплатно по лицензии GPL v3. Вы можете использовать его на свое усмотрение. Я не знаю способов монетизации системы, поэтому принял решение сделать его доступным для всех.

Если Вы решили поставить систему у себя, проще всего скачать и запустить установочный пакет для ОС Microsoft Windows со страницы https://alepiz.com/help/download.pug. В этом случае установка и первичная настройка системы произойдет автоматически. ALEPIZ можно поставить даже на персональный компьютер или ноутбук под управлением Windows 10.

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

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

Спасибо за прочтение, надеюсь, ALEPIZ поможет Вам и Вашему бизнесу в достижении новых целей.

Подробнее..

Автотесты на Android. Картина целиком

20.08.2020 10:19:07 | Автор: admin

Всем привет!


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


Она также выступит в роли схематичной дорожной карты работы Avokado Project. Мы верим в то, что в скором времени разворачивание автотестирования будет занимать куда меньше времени, чем сейчас. И активно работаем в этом направлении.



Зачем нужны автотесты?


Есть мнение, что UI-тесты не нужны, если у вас достаточное количество юнит- и интеграционных тестов. Но от следующей метафоры никуда не деться. Представьте, что вы собираете велосипед. У вас есть два хорошо протестированных колеса, протестированная рама вместе с седлом, протестированная система педалей с цепью и рулем. То есть мы с вами имеем хороший набор интеграционных и юнит-тестов. А велосипед-то в итоге поедет? Чтобы это проверить, вы нанимаете ручных тестировщиков, которые перед каждым релизом должны убедиться, что безупречные детали корректно взаимодействуют друг с другом, и велосипед будет ездить и доставлять пользователю удовольствие.


Так же и с любым программным обеспечением для мобилок. К сожалению, в мобильном мире мы не можем откатить неудачные изменения быстро, ведь все обновления идут через Google Play Store и App Store, что сразу накладывает ограничения в виде долгой раскатки в сравнении с веб- и backend-аналогами, обязательной совместимости версий и зависимости от решения пользователя обновляться или нет. Поэтому нам критически важно всегда убеждаться перед релизом, что основные пользовательские сценарии приложения работают именно так, как ожидается.


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


Все это естественным образом подводит к необходимости автоматизации проверки пользовательских сценариев, то есть написания end-to-end- или автотестов. У Авито есть рассказ о том, как автотесты помогают и сколько они стоят (2019 год). Однако большинство команд такой метод отпугивает своей сложностью и необходимостью вкладывать существенные ресурсы, чтобы выстроить процесс. Это возвращает нас к цели данной статьи и вообще к одной из целей Avokado Project стандартизировать процесс автотестирования в Android и существенно уменьшить его стоимость.


Картина целиком


Итак, обещанная картина целиком.


Android Autotests Cheat Sheet


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


Процесс написания тестов


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


Выбор инструментов для написания автотестов


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


Первая развилка это выбор между кроссплатформенным решением (Appium и т. д.) и нативным решением (Espresso, UI Automator). Много копий сломано в этих спорах. Рекомендуем посмотреть выступление наших коллег, полное драматизма и накала страстей.


Спойлер мы за нативные решения. По нашему опыту, они:


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

Кроме того, Google поддерживает Espresso и UI Automator.


Больше почитать про сравнение вы можете в статьях:



На чистом Espresso и UIAutomator нынче редко кто пишет. Разработчики сделали различные удобные обертки, которые решают их проблемы. Сейчас у нас готовится статья об этих инструментах с классификацией и сравнением. Если кратко, то фреймворк, на который мы делаем ставку, это Kaspresso.


Kaspresso


Kaspresso это фреймворк, который:


  • предоставляет DSL, значительно облегчающий написание автотестов;
  • дает встроенную многоуровневую защиту от флекающих тестов;
  • ускоряет работу UI Automator;
  • предоставляет полные логи о том, что происходит в тесте;
  • дает возможность запуска любых ADB-команд внутри тестов;
  • предоставляет механизм интерцепторов для перехвата всех действий и проверок. На данном механизме построено логирование и защита от нестабильных тестов;
  • описывает лучшие практики (исходя из нашего опыта) по написанию автотестов.

Вы можете прочитать о Kaspresso на GitHub и Habr.


Test runner


Вы написали несколько тестов. Теперь их нужно запустить. За этот этап отвечает Test Runner, или просто раннер.


Что нам предлагает Google? Утилиту AndroidJUnitRunner и ее специальный режим Orchestrator. AndroidJUnitRunner делает то, что от него и требуется просто запускает тесты, позволяя еще и параллелить их выполнение. Orchestrator позволяет продолжить выполнение тестов, даже если некоторые из них упали, и дает возможность минимизировать общее состояние между тестами. Так достигается изоляция исполнения каждого теста.


Но со временем требований к раннеру становится все больше. Вот некоторые из них:


  • запускать отдельные группы тестов;
  • запускать тесты только на определенных девайсах;
  • перезапускать упавшие тесты (вторая волна защиты от последствий нестабильных тестов после Kaspresso);
  • эффективно распределять тесты по девайсам с учетом истории прогонов и успешности предыдущих запусков;
  • подготавливать отчеты о прогоне в разных форматах;
  • отображать результаты прогона (желательно Allure based);
  • поддержать истории прогонов для дальнейшего анализа;
  • просто интегрироваться с вашей инфраструктурой.

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


Однако, Marаthon, к сожалению, не обладает некоторыми важными, по нашему мнению, свойствами. В частности, в нем нет:


  • Простой и нативной интеграции раннера с инфраструктурой, которая выдает эмуляторы. А еще лучше возможности сразу же запустить ваши тесты в облаке. Впрочем, это проблема не только Marathon к сожалению, ни один известный нам раннер не берет на себя ответственность за получение эмуляторов, это всегда ложится на плечи разработчиков.
  • Плотной интеграции с фреймворками типа Kaspresso для получения максимальной, точной и корректной информации о тесте.

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


Поэтому прямо сейчас мы работаем над Avito Runner, в котором хотим собрать все лучшие и зарекомендовавшие себя наработки и идеи. Ждите будущих анонсов!


На чем запускать тесты


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


  1. Настоящий девайс.
    Плюсы. Покажет проблемы, специфичные для конкретных устройств и прошивок. Многие производители меняют Android под себя как UI, так и логику работы ОС. И бывает полезно проверить, что ваше приложение корректно работает в таком окружении.
    Минусы. Необходимо где-то добыть ферму устройств, организовать специальное помещение под них необходима низкая температура, нежелательно попадание прямых солнечных лучей и т. д. Кроме того, аккумуляторы имеют свойство вздуваться и выходить из строя. А еще сами тесты могут менять состояние устройства, и вы не можете просто взять и откатиться на какой-то стабильный снепшот.
  2. Чистый эмулятор.
    Под чистым мы подразумеваем, что вы запускаете эмулятор у себя или где-то на машине, используя установленный на эту машину AVD Manager.
    Плюсы. Быстрее, удобнее и стабильнее настоящего устройства. Создание нового эмулятора занимает считаные минуты. Никаких проблем с отдельным помещением, аккумуляторами и прочим.
    Минусы. Отсутствие упомянутых выше device specifics. Однако зачастую количество тестовых сценариев, завязанных на специфику устройства, ничтожно мало, и они не высокоприоритетные. Но самый главный минус это плохая масштабируемость. Простая задача залить новую версию эмулятора на все хосты превращается в мучение.
  3. Docker-образ Android-эмулятора.
    Docker решает недостатки чистых эмуляторов.
    Плюсы. Docker и соответствующая обвязка в виде подготовки и раскатки образа эмулятора это полноценное масштабируемое решение, позволяющее быстро и качественно готовить эмуляторы и раскатывать их на все хосты, обеспечивая их достаточную изолированность.
    Минусы. Более высокий входной порог.

Мы делаем ставку на Docker.
В сети есть разные Docker-образы Android-эмуляторов, мы рекомендуем обратить внимание на следующие:



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


Инфраструктура


Вы написали сотни UI-тестов. Часть из них вы хотите запускать в рамках PR, а значит, весь тестовый набор должен проходить в максимально короткие сроки, например, до 20 минут. Вот тут наступает настоящее масштабирование.


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


Итак, что вам примерно предстоит:


  • Выбор между облачным решением, локальным решением с нуля и локальным решением на базе чего-то, если в компании есть своя инфраструктура по запуску тестов других платформ.
  • Самое трудоемкое это развертывание внутренней инфраструктуры с нуля. В этом случае необходимо подобрать железо, которое будет максимально использоваться автотестами. Придется измерять нагрузку на CPU/GPU/Memory/Disk, а еще пробовать разное количество одновременно запущенных эмуляторов и смотреть за стабильностью тестов. Это большая тема, по которой мы хотим провести современные замеры и поделиться с вами своими рекомендациями.
    Дальнейшая накатка необходимого ПО, встраивание в сети и прочее это все за DevOps-инженерами.
  • На выходе должен быть какой-то сервис, единая точка, которая отдает вам эмуляторы. Это может быть Kubernetes, может быть облачный сервис типа Google Cloud Engine или какое-то кастомное решение.
    В его настройке опять-таки помогают DevOps-инженеры.
  • Связка полученного сервиса с Test Runner.
    Одна из задач AvitoRunner сделать такую связку максимально простой и прозрачной, а также предоставить точки расширения, которые помогут вам легко внедрить свой кастомный сервис.

В ближайшее время мы планируем выпустить AvitoRunner и статьи, которые помогут настроить инфраструктуру.


Остальное


Не забывайте про такие немаловажные моменты, как:


  • вывод отчета по прогону тестов (Allure);
  • внедрение/синхронизация с TMS;
  • интеграция в CI/CD;
  • обучение разработчиков и тестировщиков;
  • процессы кто, когда, сколько и какие автотесты пишет.

Про все это мы еще обязательно поговорим.


Заключение


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


Следите за анонсами на нашем сайте и в телеграм-канале.

Подробнее..

Категории

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

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