Development

Предыдущие статьи:

• раз: ESPboy гаджет для ретро игр и экспериментов с IoT

• два: Часть 2: Mодули и AppStore. ESPboy гаджет для ретро игр и экспериментов с IoT

В основе лежит старенький уже на сегодня чип ESP8266 c WiFi с подключенными к нему цветным экраном 128х128, кнопками, динамиком, RGB светодиодом и еще парой удобных дополнений.

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

В ESPboy есть слот расширения, на который выведены интерфейсы I2C, SPI, UART, I2S куда втыкаются штатные модули, которые при загрузке соответствующего софта превращают устройство в ретро игровую консоль, GSM телефон, GPS навигатор, FM радио, перехватчик радиопакетов, читалку/писалку rfid/nfc, MP3 плеер, погодную станцию, универсальный ИК пульт, LORA мессенджер и много чего еще.

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

Список опробованных модулей можно увидеть на сайте проекта www.espboy.com, весь софт, как уже говорилось, на GitHub для изучения и экспериментов. Много чего в работе и еще больше в планах. К сожалению не удалось поспеть в прошлом году довести модули до промышленного изготовления, все они в виде прототипов, но энтузиасты с помощью сообщества в проектном форуме и Discord чате собирают при желании любой без сложностей. Думаю, что в этом году часть модулей все же получится выпустить в заводском исполнении.

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

• Работает сайт, а также форум и Discord чат, где идеями и достижениями делятся друг с другом международное комьюнити.

• Устройства продаются на tindie.com во все концы света, а любители самостоятельно паять по открытым схемам собирают полнофункциональные самоделки ESPboy и модулей к ним.

• По предварительной оценке, активных устройств на сегодня штук 400 и их число растет.

• Работает онлайн ESPboy AppStore и улучшенный AppStore2 в экспериментальном режиме, куда, судя по статистике, за последние полгода пришло более 5000 тысяч запросов на загрузку приложений.

• Разработана и протестирована вторая версия девайса -- ESPboy2 в более компактном исполнении, симпатичном корпусе, единым USB и прочими мелкими улучшениями. При этом сохранилась полная совместимость с классическим ESPboy. В новом исполнении устройство выглядит более законченным и приятным для использования людьми, далеким от DIY.

• Портировано около сотни игр c платформы Arduboy и написано около десятка новых игр на Little Game Engine, улучшен эмулятор ZX Spectrum 48k и CHIP8/SCHIP, добавлен звук в эмулятор GameBoy

• Портирован думообразный свободно распространяемый 3Д шутер - Anarch

• Написан разнообразный полезный софт

  • WiFi analyzer

  • WiFi sniffer

  • WiFi packet monitor

  • WiFi deauther

  • Пинговщик

  • I2C scanner

  • UART terminal

  • RSS reader

  • Рожицы COZMO в качестве прикола и демонстрации использования в робото-проектах

  • Игры из библиотеки ESPpert

  • Игры проекта tinyjoypad.com

  • Порт известного в ZX Spectrum кругах музыкального однобитного движка Phaser1

  • и кое-что по мелочи

• Собраны, протестированы и обеспечены софтом несколько новых модулей:

  • Дозиметр

  • Пульсометр

  • Каордиограф

  • Цифровой термометр диапазона -40-120С

  • Электронная рулетка

  • Сниффер и грабер радиосигналов Sub1Ghz Inspector

  • Универсальный ИК пульт

  • Bluetooth link (тестировался на мультиплеерной версии 3Д шутера Catacombs of the damned, портированного с Arduboy)

  • Генератор сигналов разной формы и частоты

• Переработан и улучшен софт прошлого года

  • GSM телефон

  • GPS навигатор

  • LORA пейджер

  • RFID/NFC читалка-писалка

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

Уже есть задумки по ESPboy3.

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

Заглядываясь на кикстартер успех FLIPPER ZERO, тоже посещают мысли о запуске компании на Kickstarter. Но такой разворот требует значительных усилий в сторону маркетинга, продаж, что далее неизбежно повлечет за собой масштабирование производства, логистики, поддержки, переход на новый уровень R&D и управление процессами в целом. Бросаться в такой омут очертя голову не охота. Хочется делать основательно, а в этом случае уже нужны заинтересованные люди, понимающие в бизнесе и инвестиции.

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

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

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

• Сайт проекта: www.espboy.com

• Лог проекта на hackaday.com https://hackaday.io/project/164830-espboy-the-ultimate-multi-gadget

• Предзаказ ESPboy2 https://forms.gle/nNGewLwkSyeA4K9L8

• Чат проекта в Discord: https://discord.gg/9HY4w2Y

• Фоум проекта: http://community.espboy.com

• YouTube: https://www.youtube.com/c/ESPboy/videos

• Софт: https://github.com/ESPboy-edu

• Схемы и плата ESPboy: https://easyeda.com/ESPboy/espboy_pcb_v3-82

• Tindie.com: https://www.tindie.com/products/18194/

Всем добра!

С уважением, РоманС

mailto: espboy.edu@gmail.com

Зачем они нужны и какие функции они выполняют.

Всем привет! Меня зовут Антон, я инженер команды, отвечающей за развитие централизованныхIT-сервисов, которыми пользуются продуктовые команды вX5RetailGroup.

В этой статье я расскажу осистемах класса API Management и в частности о APIM Gravitee (https://www.gravitee.io), том, что это за класс систем, как они используются для обеспечения потребностей команд разработки. Статья не погружает в технические аспекты, но может быть полезна архитекторам и менеджерам, которые думают о том, чтобы попробовать использоватьданный класс систем, но не знают, подойдут ли они для их задач, а также разработчикам, которые могут открыть для себя новые инструменты для удобной работы с API.

Что такое системы API Management

Определение

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

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

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

Зачем еще один огород городить?

Необходимость этого класса систем возникла в связи с увеличением количества сервисов, которые могут предоставлять свое API как конечный продукт для других сервисов. Ничего не напоминает? Правильно - микросервисная архитектура. Для организации это возможность ускорения "цифровизации". Владельцы продукта публикуют API, документацию к ней и прочие документы типа: планов развития, лимиты и т.д. Также всем хочется контролировать качество работы API, а это уже анализ производительности, статистика использования, проведение все возможных маркетинговых исследований и простой мониторинг. Для коллег из информационной безопасности будет интересно осуществлять наблюдение за использованием API в части контроля доступа: авторизация, аутентификация, аудит, проверка по черным/белым спискам IP. Для аналитиков и тестировщиков возможно будет интересна функциональность проверки корректности запросов, проверка корректности JSON или динамическое изменение запросов, для DevOps инженеров возможность установки rate limit, чтобы не было DoS конечного сервиса, настройка кэша и возможность оптимизации сервиса под микросервисную архитектуру: Service Discovery, Load Balancing, Blue/Green или Canary deploy.

Архитектура сервиса

В архитектуру сервиса API Management обычно входят (см. рис. 1):

1. Management Core: ядро системы, которое отвечает за формирование политик, планов, работу точками входа и выхода, настроек API Gateways и API, настройку CORS, Failover, Healthcheck, формирование запросов на отображение статистики использования API и логов.

2. Web/Development Portal: отвечает за UI, отображение настроек, статистики использования API, healthcheck и логов, а также позволяет общаться разработчикам, администраторам и владельцам API.

3. API Gateways: шлюзы или прокси, они отвечают за обработку запросов от клиентов сервиса согласно установленных настроек и политик, ведение логов запросов и ответов, а также запуск healthcheck по Backend API.

4. Backend API: отвечает за обработку запросов согласно бизнес-логике конечного сервиса.

5. Databases: в части сервиса API Management, хранят данные по настройке API, API Gateways, логи запросов клиентов и ответы backend, healthcheck, данные мониторинга практически всех компонентов API Management.

Плюсы и минусы систем API Management

У данных систем есть несколько преимуществ:

• Абстракция: система упрощает сложность сервисов под ним и предоставляет клиентам единый опыт.

• Аутентификация:система позволяет пройти аутентификацию, в том числе и через сторонние службы, например Keycloak.

• Управление трафиком: система регулирует входящий и исходящий трафик API.

• Мониторинг API: система может помочь в мониторинге запросов/ответов клиента.

• Преобразования: система позволяет преобразовать запросы/ответы API.

К минусам можно отнести:

• Увеличение Latency: шлюзу необходимо время для обработки запросов/ответов согласно настроенным политикам.

• TCO: Совокупная стоимость владения для всей цепочки поставки ценности, естественно будет больше, чем просто установить nginx и выставить его наружу.

APIGateways

API Gateways работают как единая точка входа в ЦОД (центр обработки данных), группу распределенных служб или сервисов (см. рис. 2). Также API Gateways могут использоваться для связи между двумя продуктами/сервисами, развернутыми в одном ЦОД. API Gateways принимают вызовы от клиентов, обрабатывают их согласно политикам/правилам и направляют их в соответствующие сервисы. Чтобы API Gateways могли максимально быстро обрабатывать запросы от клиентов их делают максимально легковесными, с использованием асинхронных фреймворков. API Gateways, как правило, работают только на седьмом уровне (L7) модели OSI.

ТипыAPI Gateways

С точки зрения расположения есть два места установки API Gateways:

• Local API Gatewaysработают как шлюз для сервисов внутри организации.

• DMZ API Gatewaysработают как шлюз для внешних потребителей и клиентов сервисов.

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

Наиболее распространенные системы

Централизованный сервис Gravitee

В X5 Retail Group в свое время выбрали для использования систему APIM Gravitee (https://www.gravitee.io). Основной сценарий использования нашими командами публикация API в локальной сети и в DMZ.

Немного цифр об этом сервисе на текущий момент:

• 23 продуктивных команд зарегистрировано

• 69 API Gateways для обслуживания запросов

• 400 Гб логов за сутки

• 350 RPS в среднем по больнице за сутки

• 30 000 000+ запросов обрабатывается за сутки

Функциональность

Рассмотрим базовую функциональность, предоставленную системой APIM Gravitee.

1. Identity provider: Аутентификация внешних пользователей можешь осуществляться на основе следующих систем и сервисов:

1. MongoDB (по умолчанию для новых пользователей, которые приглашаются);

2. In-memory (по умолчанию для пользователя admin);

3. LDAP / Active Directory;

4. OpenID Connect IdP (Azure AD, Google);

2. Fetchers: стянуть настройки для новой версии API и документацию можно через:

2. File (Swagger, OpenAPI);

3. HTTP;

4. GIT;

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

3. API Key - политика авторизации с использованием API-ключа;

4. Rate-limiting - политика ограничения скорости или квот для предотвращения флудинга backend;

5. Transform Headers/Transform Query Parameters - политика преобразований параметров заголовка или запроса;

6. etc.

Политик обработки запросов в Gravitee Gateway более 30 штук и с каждой версией их число увеличивается. Так же можно сделать свои политики. Но стоит учитывать, что чем больше политик "навешано", тем медленнее будет обрабатываться запрос и тем больше ресурсов будет использовано.

4. Reporters: сборщики логов используются экземпляром шлюза для сообщения о событиях. Типы сборщиков логов:

4. Reporter file;

5. Elasticsearch;

6. Accesslog;

Типы событий, которые можно собрать:

4. Метрики запроса/ответа например, время ответа, длина содержимого, api-ключ;

5. Мониторинг метрик например, процессора, использования кучи, кол-во открытых файлов и т.д.;

6. Показатели проверки работоспособности например, состояние, код ответа;

5. Repositories: репозиторий - это подключаемый компонент хранилища для настройки API, конфигураций политик, аналитики, аудита и так далее. Можно использовать следующие репозитории:

5. MongoDB (по умолчанию);

6. Redis;

7. Elasticsearch;

8. PostgreSQL (коннектор через JDBC и надо использовать другой дистрибутив);

6. Resources: ресурсы, которые можно использовать при работе:

6. OAuth2 (подключение к OAuth2 как источнику данных для аутентификации);

7. Cache (создание локального кэша на шлюзе);

8. LDAP (подключение к LDAP как источнику данных для аутентификации);

7. Services: сервисы, которые может предоставлять сам шлюз:

7. Sync (Синхронизация состояния шлюза с конфигурацией из репозитория управления);

8. local-registry (Локальный реестр используется для загрузки API в формате json из файловой системы. Таким образом, вам не нужно настраивать свой API с помощью веб-консоли или rest API (но вам нужно знать и понимать формат json API, чтобы он работал.));

9. health-check (Сервис для проверки состояния других сервисов);

10. monitor (Сервис извлекает метрики, такие как метрики os / process / jvm, и отправляет их в базовую службу отчетов);

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

8. Email;

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

9. Vertx;

А так как система с открытыми исходниками:https://github.com/gravitee-io, то при знании Java, можно написать свои собственные плагины и использовать как вздумается.

Настройки API

Настройка нового API проходит несколько этапов:

1. Создание API

2. Настройка планов

3. Привязываем API к шлюзам

Создание API

На странице создания API можно выбрать, как и из чего создать скелет нового API

Вариантов немного, но выбор есть:

1. Вручную накликал и можно работать!

2. Импортировать из swagger файла.

3. Импортировать из Gitа/URLа.

Рассмотрим ручной вариант настройки, выбираем "->"

Ручное создание API проходит 5 шагов

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

Второй шаг может быть в двух модификациях:

В Simple mode указываем только адрес нашего backend api, например:https://msk-dpro-sre000.x5.ru:8443/testbackend/

В Advanced mode необходимо указатьадрес нашего backend api, используемые tenant и sharding tags.

tenant- область выделенная в Elasticsearch для логов запросов и событий.

sharding tags- теги, согласно которым связываются API и Gateways

На третьем шаге можно указать Plan

Plan - это указание ограничений, которые будут влиять на обработку запросов, проходящих через данный Gateway.

Name -имяплана

Security type -типплана: Keyless(public), API Key, JWT, OAuth2

Description - просто описание плана и его особенностей

Rate limit - ограничение кол-ва запросов в секунду/минуту

Quota -ограничение кол-ва запросов в час/день/неделя/месяц

Path authorization - черный и белый список путей и методов к ним

Данный пункт можно пропустить и заполнить уже в созданном API.

На четвертом шаге можно загрузить файл документации по API

Поддерживается формат swagger.json

Данный пункт можно пропустить и заполнить уже в созданном API.

На пятом шаге мы проверяем все что заполнили

И выбираем либо "Создать API без установки на шлюз", либо "Создать и запустить API"

Нажимаем CREATE и получаем частично настроенный API для работы.

Настройки планов

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

Основные настройки:

1. Планы привязываются к конкретному шлюзу или группе шлюзов через Tags (см. рис. 3)

2. В плане указывается какой тип Аутентификации будет использован (см. рис. 4)

3. Можно сразу указать Rate и Quota лимиты и определить список разрешенных путей для запроса (см. рис. 5)

4. В последней вкладке можно указать политики, которые будут отрабатывать на начальном этапе обработки запросов (см. рис. 6)

Заключение

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

Цель статьи - показать один из возможных подходов для организации гибкого развёртывания 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и разворачивать новые стенды из пайплайнов команд разработчиков передавая версии сервисов.

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

В ноябре прошлого года более 500 российских технологов присоединились к нашему первому GitHub Meetup на русском языке и сейчас наше коммюнити насчитывает уже больше 1000 человек. Недавно мы открыли Telegram канал. Для нас это большая честь - привлекать такое внимание, и мы всегда будем рады слушать, учить и вдохновлять русскоязычное сообщество на вашем родном языке.

Вот краткое изложение того, о чем мы рассказали на данный момент:

GitHub:

• От Юрия Неваленного, разработчика npm: новые функции в GitHub Actions и способы их эффективного использования для реализации CI/CD.

• Алексей Мигуцкий (GitHub: разработчик issues/projects): как мы разрабатываем GitHub с помощью GitHub

• Наталия Дорфман (npm Engineering manager) Обзор платформы GitHub

Открытый исходный код правит миром:

• Олег Докука, разработчик открытого программного обеспечения для @rsocket @reactorr, поделился своей историей участия в open source проектах.

• Дмитрий Сошников, ведущий эксперт в области искусственного интеллекта и машинного обучения, developer advocate в Microsoft. Он показал коллективный портрет посетителя митапа: короткую интерактивную презентацию с Python, Codespaces и когнитивными сервисами.

• Антон Колесник (Microsoft Azure SDK) поделился опытом работы в качестве разработчика OSS в крупной компании.

• Олег Пименов (Positive Technologies) рассказал об управлении проектами с открытым кодом на GitHub

• Алексей Миловидов (Яндекс): Как организовать живое сообщество вокруг продукта с открытым исходным кодом

• Алекс Пулвер (архитектор AWS Solutions) рассказал про OSS-фреймворк AWS Cloud Development Kit (AWS CDK) - современный способ построения вашей инфраструктуры AWS.

Безопасность - наша ответственность:

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

• Алена Глобина (Продакт Менеджер в GitHub:Code scanning CodeQL) рассказала про анализ безопасности кода с помощью CodeQL.

• Артём Савельев (разработчик в GitHub: Secret Scanning) рассказал о превентивной безопасности в цикле разработки.

Программа GitHub Stars и ваша собственная Русская Звезда

• GitHub Star Никита Соболев (DryLabs) поделился подробностями о программе GitHub Stars.

Начало работы с InnerSource

• Дмитрий Сугробов (разработчик и евангелист в Leroy Merlin, член InnerSource Commons Foundation) дал нам Введение в InnerSource.

Бонус-трек: развитие soft skills

• Алена Беркач (тренер уровня ACC ICF) поделилась своим тренерским взглядом на синдром самозванца.

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

Если вы хотите выступить в качестве приглашенного докладчика, отправьте нам предложение на http://github.co/cfp - не важно если это ваше первое или уже тысячное выступление. Мы приглашаем Вас присоединиться к нам и воспользоваться имеющимися возможностями.

Мы надеемся, что вы присоединитесь к нам 15 июня 2021 года в 19:00 по Москве для дальнейшего общения и новых сессий.

Далее: наши эксперты на июньском мероприятии:

• Грачев Михаил: Взращивание культуры Open Source в компании

• Антон Таяновский: Инфраструктурные шаблоны Pulumi на примере AWS Lambda и Sagemaker

RSVP:http://github.co/habr

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

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

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

Создавайте сценарий логичного и очевидного общение друга с вашим приложением

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

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

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

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

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

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

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

Друг же может рассчитывать на честность?

Мотивируйте друга на действия

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

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

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

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

Необходимо ли другу знать о целях разработчика? Нужно ли другу знать о целях операционной системы? О целях сервера? О целях сервиса времени? О целях DNS серверов?

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

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

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

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

Слова, фразы, концепции друг может использовать свои. Ведь также?

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

Должен ли друг каждый раз заглядывать в словарь? Читать википедию или технические статьи о сервисе мирового времени? Погружаться в те многие нюансы и технические детали? Должен ли совершать многие лишние и излишние действия для достижения своих целей ваш друг?

Позвольте приложению напоминать объекты реального мира

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

Вы знаете этот язык, друг знает этот язык, даже друг в другой стране тоже знает этот язык.

Дайте другу право на ошибку

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

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

Может ли друг экспериментировать с приложением, чтобы понять как оно работает?

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

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

Постоянство и стандарты дают другу ощущение безопасности

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

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

У друга уже есть предположения о приложении до начала использования вашего приложения.

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

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

Предупредите ошибки друга

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

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

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

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

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

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

Информация в приложении постоянно меняется, И правда, другу следует заучивать наизусть некую информацию, потом переучивать, потом ещё много раз переучивать?

Позвольте другу эффективно использовать ваше приложение

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

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

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

Позвольте не перегружать друга

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

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

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

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

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

P.S. Как вы поняли это классические 10 эвристик Якоба Нильсена. Только под немного другим углом зрения. Спасибо тем, кто прочитал.

Здравствуйте уважаемые читатели. Все мы любим и используем DataBinding, который представила компания Google несколько лет назад, для связи модели данных с вьюшками через ViewModel. В этой статье, хочу поделиться с вами, как можно унифицировать этот процесс с помощью языка Kotlin, и уместить создание адаптеров для RecyclerView (далее RV), ViewPager и ViewPager2 в несколько строчек кода.

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

class CustomAdapter(private val dataSet: Array<String>) : RecyclerView.Adapter<CustomAdapter.ViewHolder>() {        class ViewHolder(view: View) : RecyclerView.ViewHolder(view) {    val textView: TextView            init {      textView = view.findViewById(R.id.textView)    }  }       override fun onCreateViewHolder(viewGroup: ViewGroup, viewType: Int): ViewHolder {    val view = LayoutInflater.from(viewGroup.context).inflate(R.layout.text_row_item, viewGroup, false)          return ViewHolder(view)  }         override fun onBindViewHolder(viewHolder: ViewHolder, position: Int) {    // Get element from your dataset at this position and replace the    viewHolder.textView.text = dataSet[position]  }        override fun getItemCount() = dataSet.size}

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

Затем появился DataBinding и большую часть по связыванию данных перекладывалась на него, но адаптеры все равно приходилось писать вручную, изменились только методы onCreateViewHolder, где вместо инфлэйтинга через LayoutInflater, использовался DataBindingUtil.inflate, а при создании вьюхолдеров данные связывались непосредственно с самой вьюшкой через ссылку на созданный объект байдинга.

class BindingViewHolder(val binding: ItemTextRowBinding) : RecyclerView.ViewHolder(binding.root)override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): BindingViewHolder {        val binding = DataBindingUtil.inflate<ItemTextRowBinding>(LayoutInflater.from(parent.context), viewType, parent, false)        val viewHolder = BindingViewHolder(binding)        return viewHolder}override fun onBindViewHolder(holder: BindingViewHolder, position: Int) {      holder.binding.setVariable(BR.item, dataSet[position])}

Выглядит уже лучше, но что если в RV, по прежнему должны отображаться элементы лайаута с разными типами данных, то такая реализация не сильно помогла решить проблему больших адаптеров. И здесь на помощь приходит аннотация BindingAdapter из библиотеки androidx.databinding. С ее помощью, можно создать универсальное решение, которое скрывает реализацию создания адаптера для RV, если использовать вспомогательный объект-конфигуратор DataBindingRecyclerViewConfig, в котором содержится ряд свойств для настройки адаптера.

В результате на свет появилась библиотека, которая называется EasyRecyclerBinding. В нее так же вошли BindingAdapters для ViewPager и ViewPager2. Теперь процесс связывания данных выглядит следующим образом:
1) В лайауте фрагмента, необходимо добавить специальные переменные, которые содержат список отображаемых моделей данных и конфигурацию, указав их атрибутами для RV, - app:items и app:rv_config.

<?xml version="1.0" encoding="utf-8"?><layout xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    xmlns:app="http://personeltest.ru/away/schemas.android.com/apk/res-auto"    xmlns:tools="http://personeltest.ru/away/schemas.android.com/tools">    <data>    <variable        name="vm"        type="com.rasalexman.erb.ui.base.ExampleViewModel" />        <variable            name="rvConfig"            type="com.rasalexman.easyrecyclerbinding.DataBindingRecyclerViewConfig" />    </data>    <androidx.constraintlayout.widget.ConstraintLayout        android:id="@+id/main"        android:layout_width="match_parent"        android:layout_height="match_parent">        <androidx.recyclerview.widget.RecyclerView            android:layout_width="0dp"            android:layout_height="0dp"            app:items="@{vm.items}"            app:rv_config="@{rvConfig}"            app:layout_constraintBottom_toBottomOf="parent"            app:layout_constraintEnd_toEndOf="parent"            app:layout_constraintStart_toStartOf="parent"            app:layout_constraintTop_toTopOf="parent"            tools:listitem="@layout/item_recycler"/>    </androidx.constraintlayout.widget.ConstraintLayout></layout>

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

// названия пакетов не указаны для простоты примераclass ExampleViewModel : ViewModel() {     val items: MutableLiveData<MutableList<RecyclerItemUI>> = MutableLiveData()}data class RecyclerItemUI(    val id: String,    val title: String)

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

<?xml version="1.0" encoding="utf-8"?><layout xmlns:android="http://personeltest.ru/away/schemas.android.com/apk/res/android"    xmlns:app="http://personeltest.ru/away/schemas.android.com/apk/res-auto"    xmlns:tools="http://personeltest.ru/away/schemas.android.com/tools">    <data>        <variable            name="item"            type="com.rasalexman.erb.models.RecyclerItemUI" />    </data>    <androidx.constraintlayout.widget.ConstraintLayout        android:layout_width="match_parent"        android:layout_height="wrap_content"        android:background="@android:drawable/list_selector_background">        <TextView            android:id="@+id/titleTV"            android:layout_width="match_parent"            android:layout_height="wrap_content"            android:paddingStart="16dp"            android:paddingTop="8dp"            android:paddingEnd="16dp"            android:textColor="@color/black"            android:textSize="18sp"            android:text="@{item.title}"            app:layout_constraintEnd_toEndOf="parent"            app:layout_constraintStart_toStartOf="parent"            app:layout_constraintTop_toTopOf="parent"            tools:text="Hello world" />        <TextView            android:layout_width="match_parent"            android:layout_height="wrap_content"            android:paddingStart="16dp"            android:paddingEnd="16dp"            android:paddingBottom="8dp"            android:textColor="@color/gray"            android:textSize="14sp"            android:text="@{item.id}"            app:layout_constraintEnd_toEndOf="parent"            app:layout_constraintStart_toStartOf="parent"            app:layout_constraintTop_toBottomOf="@+id/titleTV"            tools:text="Hello world" />    </androidx.constraintlayout.widget.ConstraintLayout></layout>

2) Во фрагменте нам нужно получить конфигурацию для адаптера и передать её в отображение через инстанс dataBinding, используя специальную функцию-конструктор createRecyclerConfig<I : Any, BT : ViewDataBinding>, которая создаст и вернет инстанс DataBindingRecyclerViewConfig, указав при этом id лайаута для выбранной модели, и название свойства, к которому будет прикреплена данная модель.

class RecyclerViewExampleFragment : BaseBindingFragment<RvExampleFragmentBinding, ExampleViewModel>() {      override val layoutId: Int get() = R.layout.rv_example_fragment  override val viewModel: ExampleViewModel by viewModels()        override fun initBinding(binding: RvExampleFragmentBinding) {        super.initBinding(binding)        binding.rvConfig = createRecyclerConfig<RecyclerItemUI, ItemRecyclerBinding> {            layoutId = R.layout.item_recycler        itemId = BR.item                    }    }}

Это все, что нужно сделать, чтобы связать данные из ViewModel с отображением списка в RV. Так же при создании адаптера можно назначить слушатели событий для байдинга вьюхолдера, такие как onItemClick,onItemCreate, onItemBind и другие.

А чтобы использовать вьюхолдеры с разными визуальными лайаутами, к которым привязаны свои модели отображения данных, необходимо имплементировать в них специальный интерфейс из библиотеки EasyRecyclerBinding - IBindingModelи переопределить поле layoutResId, - id лайаута, который будет отображаться для этой модели в списке.

data class RecyclerItemUI(    val id: String,    val title: String) : IBindingModel {        override val layoutResId: Int            get() = R.layout.item_recycler}data class RecyclerItemUI2(    val id: String,    val title: String) : IBindingModel {    override val layoutResId: Int        get() = R.layout.item_recycler2}

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

class RecyclerViewExampleFragment : BaseBindingFragment<RvExampleFragmentBinding, RecyclerViewExampleViewModel>() {      override val layoutId: Int get() = R.layout.rv_example_fragment    override val viewModel: RecyclerViewExampleViewModel by viewModels()        override fun initBinding(binding: RvExampleFragmentBinding) {        super.initBinding(binding)        binding.rvConfig = createRecyclerMultiConfig {            itemId = BR.item        }    }}class RecyclerViewExampleViewModel : BasePagesViewModel() {    open val items: MutableLiveData<MutableList<IBindingModel>> = MutableLiveData()}

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

Аналогичный процесс создания адаптеров для ViewPager и ViewPager2, представлен в примере на github вместе с открытым кодом, ссылку на который, я разместил в конце статьи. В настоящий момент библиотека еще дорабатывается, и хочется получить адекватный фидбек, и пожелания по дальнейшему ее развитию. Так же в неё вошли вспомогательные функции для удобного создания байдинга, в том числе в связке с ViewModel. (LayoutInflater.createBinding, Fragment.createBindingWithViewModel, etc)

Спасибо, что дочитали до конца. Приятного кодинга и хорошего настроения)

И снова привет, мир!

В прошлой статье про IoT-елочку в голосовании многие отметили, что интересна тема управления устройствами в зависимости от количества человек в помещении. Это довольно масштабная задача, и мы предлагаем разделить ее решение на несколько этапов. Сегодня поговорим о системе контроля управления доступом (СКУД), которая, будучи подключенной к платформе интернета вещей Rightech IoT Cloud (далее по тексту - платформа), является базовым элементом в системе подсчета количества человек в офисе. Мы уже поверхностно освещали этот кейс в одной из статей, но сегодня рассмотрим этот проект более подробно и погрузимся в особенности исполнения.

С чего все началось

Задача обеспечить контроль за входом-выходом в офисе возникла еще в те времена, когда у нас был выход на крышу с отличным видом на Москву, и поэтому часто приходили люди, не являющиеся нашими сотрудниками. Тогда мы решили принять какие-то меры по безопасности и установить СКУД.

Архитектура

Система открытия дверей по карте

В качестве модуля, отвечающего за обработку информации по считыванию бесконтактных карт, выбрали GATE-8000.

Основные достоинства контроллера:

• формирование и хранение необходимой информации о факте открытия двери по карте и времени прохода человека в офис;

• возможность автономной работы и защиты от зависания;

• хранение 16 тысяч ключей и 8 тысяч событий;

• простое подключение и управление;

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

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

Система взаимодействия с платформой

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

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

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

Аппаратная часть

Для начала нужно было выбрать устройство, которое будет всегда в активном состоянии с включенной программой-агентом в непосредственной близости от платы СКУД. Из многообразия микрокомпьютеров первое что попало под руку выбор пал на Raspberry Pi.

Дальше возник вопрос, как подсоединить GATE-8000 к Raspberry - то есть как подключить последовательный интерфейс RS485 от GATE к USB от микрокомпьютера. Начались поиски переходника USB-RS485. Первый вариант, который мы испробовали, - Espada за 200 рублей. Надежда на то, что маленький хлипкий китайский переходник заработает, была небольшой. Он и не заработал. Вместо нужных данных приходило что-то похожее по виду и размеру, но всё же не то. В чем было дело: в отсутствии гальванической развязки, невозможности поддерживать скорость 19200 bps или же просто в некачественной элементной базе, - загадка. Но после обращения к производителю GATE-8000, мы получили рекомендацию на более дорогой (в 10 раз) и громоздкий (но аккуратный и корпусированный) переходник Z-397, который заработал тут же как надо.

Программная часть

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

1. Что нужно - взаимодействие с GATE-8000 для отправки команд и получения данных.

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

2. Что нужно - взаимодействие с платформой для получения команд и отправки данных.

   Как решим - выберем для общения протокол MQTT, в коде воспользуемся готовой библиотекой Paho MQTT.

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

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

1) задавать всю логику работы в агенте;

2) использовать внешние запросы (от платформы).

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

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

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

1) найден ключ в банке ключей (банк ключей - еще один блок в распределенной памяти контроллера);

2) состоялся проход (если он, конечно, состоялся).

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

bool SerialPortInlet::readBufferCycle(unsigned short& bottom, unsigned short const& top, unsigned char& u_lowerBound,    unsigned char& l_lowerBound, std::vector<unsigned char>& readBuffer, std::string& result){// Подсчет байтов, которые необходимо считатьunsigned short byteCountTmp = top - bottom;BOOST_LOG_SEV(log_, logging::info) << "Need read " << byteCountTmp << " byte";unsigned char byteCount;// За один цикл нельзя прочитать более 12 событий (96 байт)byteCount = byteCountTmp > 0x60 ? 0x60 : (unsigned char)byteCountTmp;BOOST_LOG_SEV(log_, logging::info) << "Read " << +byteCount << " byte";// Описываем тело командыstd::vector<unsigned char> body = {0x02, 0xA0, byteCount, u_lowerBound, l_lowerBound};std::vector<unsigned char> command;// Получаем полный текст командыgenerateComplexCommand(command, Command::BYTE_CODE_READ, body);// Если не удалось по каким-то причинам отправить команду (например, конечное устройство не подключено), возвращается falseif (!sendCommand(command, result)){    return false;}// Иначе отправляем ответ с устройства на парсинг по событиямSerialPortType::Answer answerEvents;if(!Parsers::parserAnswer(log_, result, answerEvents, Command::BYTE_CODE_READ)){    BOOST_LOG_SEV(log_, logging::error) << "Failed parse buffer reading";    return false;}readBuffer.insert(readBuffer.end(), answerEvents.body.begin(), answerEvents.body.end());// Сдвигаем нижнюю границу буфера для чтения следующих событийbottom = bottom + byteCount;u_lowerBound = (unsigned char)(bottom >> 8) ;l_lowerBound = (unsigned char)bottom;return true;}

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

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

Пример байтстаффинга из документации

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

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

Работа на платформе Rightech IoT Cloud

Модель

Основные данные с контроллера - это события, на платформу они приходит в формате JSON и включают в себя поля

• eventTime - время наступления события;

• eventCode - код события;

• keyNumber - номер карты сотрудника (поле может быть пустым, если событие вызвано не картой).

Модель устройства выглядит следующим образом.

Посмотреть оригинал >>>

Возможные события:

• нажата кнопка звонка;

• неопознанный ключ на входе;

• неопознанный ключ на выходе;

• ключ найден в банке ключей при входе;

• ключ найден в банке ключей при выходе;

• открывание оператором по сети;

• дверь заблокирована оператором;

• дверь оставлена открытой после входа;

• дверь оставлена открытой после выхода;

• проход состоялся на вход;

• проход состоялся на выход;

• перезагрузка контроллера.

Объект

Интерфейс объекта полностью формируется согласно разработанной модели.

Посмотреть оригинал >>>

Ура, теперь, собравшись на кухне офиса в ожидании пиццы на праздник, можно никуда не идти, а просто открыть мобильное приложение и нажать кнопку открытия двери для курьера!

Автомат

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

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

Посмотреть оригинал >>>

Здесь виден цикл <чтение>-<запись новой границы буфера>-<ожидание таймера> (сейчас события считываются каждые 30 секунд).

1. В состоянии Read events читаем новые события.

2. В состоянии Clear buffer записываем новую границу.

3. В состоянии Await timer ожидаем начала нового цикла.

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

Дальнейшее использование собранных данных

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

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

Посмотреть оригинал >>>

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

Забор данных из платформы производится по REST API. API платформы предоставляет возможность работы, взаимодействия и использования сущностей платформы и их данных в таких внешних системах, как веб-порталы, мобильные и веб-приложения или, как в нашем случае, - CRM системах.

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

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

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

Распределённая трассировка (Distributed Tracing) - это метод, используемый для мониторинга приложений. Для микросервисов он просто незаменим.

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

Что нам потребуется?

• Начальные знанияGoLang

• Понимание принциповKubernetes

• Опыт работы с NGINX /Ingress-NGINX

• Установить Docker-Desktop

• Установить Helm v3

В этом руководстве предполагается, что вы понимаете код, написанный на Go, умеете использовать Ingress-nginx и знаете, как работают основные объекты Kubernetes, такие как Service и Deployment.

Если вы хотите освежить знания, воспользуйтесь этими материалами:

• Kubernetes Basics

• Ingress-Nginx Basics

Запуск Kubernetes в Docker Desktop

Начнём с установки Docker Desktop, который позволяет не только запускать контейнеры, но и создать локальный кластер Kubernetes.

После установки Docker Desktop выполните следующие действия, чтобы создать кластер Kubernetes:

1. Нажмите на иконкуPreferences

2. Выберете вкладкуKubernetes, установите флажокEnable Kubernetes и нажмите кнопкуApply & Restart

3. В появившемся окне нажмите кнопкуInstall и дождитесь пока установка завершится

4. Выберите пунктKubernetes в панели задач

5. В контекстном меню выбиритеdocker-desktop

6. Проверьте, что вы подключены к нужному кластеру

$ kubectl cluster-infoKubernetes master is running at https://kubernetes.docker.internal:6443KubeDNS is running at https://kubernetes.docker.internal:6443/api/v1/namespaces/kube-system/services/kube-dns:dns/proxy

Установка Ingress-NGINX Controller

1. Воспользуйтесь командой из официального руководства для установки Ingress-NGINX Controller.

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.45.0/deploy/static/provider/cloud/deploy.yamlnamespace/ingress-nginx createdserviceaccount/ingress-nginx createdconfigmap/ingress-nginx-controller createdclusterrole.rbac.authorization.k8s.io/ingress-nginx createdclusterrolebinding.rbac.authorization.k8s.io/ingress-nginx createdrole.rbac.authorization.k8s.io/ingress-nginx createdrolebinding.rbac.authorization.k8s.io/ingress-nginx createdservice/ingress-nginx-controller-admission createdservice/ingress-nginx-controller created\deployment.apps/ingress-nginx-controller createdvalidatingwebhookconfiguration.admissionregistration.k8s.io/ingress-nginx-admission createdserviceaccount/ingress-nginx-admission created]clusterrole.rbac.authorization.k8s.io/ingress-nginx-admission createdclusterrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission createdrole.rbac.authorization.k8s.io/ingress-nginx-admission createdrolebinding.rbac.authorization.k8s.io/ingress-nginx-admission createdjob.batch/ingress-nginx-admission-create created\job.batch/ingress-nginx-admission-patch created

2. Проверьте, что установка Ingress Сontroller прошла успешно. Pods должны быть запущены и находятся в статусе Ready.

$ kubectl get pods -n ingress-nginxNAME                                     READY   STATUS    RESTARTS ingress-nginx-admission-create-52jsl        0/1     Completed   0          ingress-nginx-admission-patch-78fkc         0/1     Completed   0          ingress-nginx-controller-6f5454cbfb-qsfnn   1/1     Running     0 

Важно:Если Pod находится в статусе Pending из-за нехватки ресурсов CPU/Memory, вы можете добвить ресурсы вашему кластеру в настройках Docker Desktop.

Установка Jaeger и настройка Ingress Controller

Jaeger - это платформа распределенная трассировки, которую мы будем использовать для мониторинга наших микросервисов. Установим Jaeger и включим трассировку на уровне Ingress Controller.

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

$ git clone https://github.com/diazjf/meow-micro.gitCloning into 'meow-micro'...remote: Enumerating objects: 105, done....$ cd meow-micro

2. В репозитории вы найдёте манифесты для jaeger-all-in-one. Установим Jaeger из этих манифестов.

$ kubectl apply -f jaeger/jaeger-all-in-one.yamldeployment.apps/jaeger createdservice/jaeger-query createdservice/jaeger-collector createdservice/jaeger-agent createdservice/zipkin created

3. Убедимся, что Jaeger запущен и готов к работе.

$ kubectl get podsNAME                      READY   STATUS    RESTARTS   AGEjaeger-6f6b5d8689-8gccp   1/1     Running   0          17s

4. Пришло время настроить совместную работу Ingress-NGINX and Jaeger, для этого необходимо добавить параметрыenable-opentracingиjaeger-collector-hostвingress-nginx-controllerConfigMap. В параметре jaeger-collector-host указываем имя сервиса Jaeger.

$ echo '  apiVersion: v1  kind: ConfigMap  data:    enable-opentracing: "true"    jaeger-collector-host: jaeger-agent.default.svc.cluster.local                metadata:    name: ingress-nginx-controller    namespace: ingress-nginx  ' | kubectl replace -f -configmap/ingress-nginx-controller replaced

5. Убедимся, что в настройках Ingress Controller включени настроен opentracing.

$ kubectl get pods -n ingress-nginx | grep controlleringress-nginx-controller-6f5454cbfb-qptxt   1/1     Running     0          8m56s$ kubectl exec -it ingress-nginx-controller-6f5454cbfb-qptxt -n ingress-nginx -- bash -c "cat nginx.conf | grep ngx_http_opentracing_module.so"load_module /etc/nginx/modules/ngx_http_opentracing_module.so;$ kubectl exec -it ingress-nginx-controller-6f5454cbfb-qptxt -n ingress-nginx -- bash -c "cat nginx.conf | grep jaeger"opentracing_load_tracer /usr/local/lib/libjaegertracing_plugin.so /etc/nginx/opentracing.json;$ kubectl exec -it ingress-nginx-controller-6f5454cbfb-qptxt -n ingress-nginx -- bash -c "cat /etc/nginx/opentracing.json"{  "service_name": "nginx",  "propagation_format": "jaeger",  "sampler": {    "type": "const",    "param": 1,    "samplingServerURL": "http://127.0.0.1:5778/sampling"  },  "reporter": {    "endpoint": "",    "localAgentHostPort": "jaeger-agent.default.svc.cluster.local:6831"  },  "headers": {    "TraceContextHeaderName": "",    "jaegerDebugHeader": "",    "jaegerBaggageHeader": "",    "traceBaggageHeaderPrefix": ""  }}

Jaeger и Ingress Controller успешно установлены и настроены. Самое время развернуть наши микросервисы!

Разворачиваем тестовое приложение

Тестовое приложение meow-micro состоит из двух микросервисов. Клиент meow-client - принимает REST запрос и отправляет информацию сервису meow-server через GRPC.

Подробная информация об использовании REST и GRPC с GoLang:

• GoLang HTTP Server

• GoLang GRPC Communication

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

tracing.go

Получает параметры для настройки Jaeger из окружения, в котором запускается Helm для установкиmeow-clientandmeow-server.

cfg, err := config.FromEnv()if err != nil {panic(fmt.Sprintf("Could not parse Jaeger env vars: %s", err.Error())) }  tracer, closer, err := cfg.NewTracer()if err != nil {   panic(fmt.Sprintf("Could not initialize jaeger tracer: %s", err.Error())) }

client.go

Выполняет конфигурирование клиента - задает service nameдля trace и определяет span.

• Span базовый элемент распределенной трассировки. Представляет собой описание некоего рабочего процесса (например, запроса к базе данных). Span'ы обычно содержат ссылки на другие span'ы, что позволяет объединять множество span'ов вTrace.

• Trace визуализация жизни запроса в процессе его перемещения по распределенной системе.

Подробную информацию о понятиях trace и span можно посмотреть в официальной документации.

// main function spanos.Setenv("JAEGER_SERVICE_NAME", "meow-client")tracer, closer := tracing.Init()defer closer.Close()http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {spanCtx, _ := tracer.Extract(opentracing.HTTPHeaders, opentracing.HTTPHeadersCarrier(r.Header))span := tracer.StartSpan("send-meow-communication", ext.RPCServerOption(spanCtx))defer span.Finish()...// sleep function spanos.Setenv("JAEGER_SERVICE_NAME", "meow-client")tracer, closer := tracing.Init()defer closer.Close()span := tracer.StartSpan("sleep")defer span.Finish()

Установка тестового приложения

Установить Helm v3 можно на любую операционную систему, например на macOS с помощью brew. Теперь мы готовы развернуть микросервисы в нашем кластере.

$ brew install helm...==> Downloading https://ghcr.io/v2/homebrew/core/helm/manifests/3.5.4######################################################################## 100.0%==> Downloading https://ghcr.io/v2/homebrew/core/helm/blobs/sha256:5dac5803c1ad2db3a91b0928fc472aaf80a4==> Downloading from https://pkg-containers-az.githubusercontent.com/ghcr1/blobs/sha256:5dac5803c1ad2db######################################################################## 100.0%==> Pouring helm--3.5.4.big_sur.bottle.tar.gz...$ helm versionversion.BuildInfo{Version:"v3.3.4", GitCommit:"a61ce5633af99708171414353ed49547cf05013d", GitTreeState:"clean", GoVersion:"go1.14.9"}

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

# Build client and server from Dockerfile$ make builddocker build -t meow-client:1.0 -f client/Dockerfile .[+] Building 17.1s (10/10) FINISHED...docker build -t meow-server:1.0 -f server/Dockerfile .[+] Building 0.5s (10/10) FINISHED...# Install Microservices into Kubernetes via Helm$ make installhelm install -f helm/Values.yaml meow-micro ./helmNAME: meow-microLAST DEPLOYED: Mon Apr 26 13:42:38 2021NAMESPACE: defaultSTATUS: deployedREVISION: 1TEST SUITE: None

Проверим, что Pods обоих сервисов запустились и работают.

$ kubectl get podsNAME                           READY   STATUS    RESTARTS   AGEjaeger-6f6b5d8689-s7cln        1/1     Running   0          26mmeow-client-8b974778c-85896    1/1     Running   0          15mmeow-server-56f559db44-5mvgp   1/1     Running   0          15m

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

А теперь самое интересное! Взглянем на трассировку.

Откройте консоль Jaeger, указав в браузере адресhttp://localhost:8081.

2. Отправим запрос нашему приложению.

$ curl http://localhost/meow -X POST -d '{"name": "Meow-Mixer"}'200 - Meow sent: Meow-Mixer

3. Обновите страницу браузера. В меню Service выберите - nginx.

4. Нажмите кнопкуFind Traces.

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

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

И выводить дополнительную информацию по каждому запросу.

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

Другие системы трассировки

Мы рассмотрели как использовать Jaeger для трассировки запросов Ingress-Nginx. Для этих целей можно также использовать Zipkin или DataDog.

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

Красота в наших глазах. Но руководитель часто далек от технических деталей. Часто очень сложно объяснить всю программистскую кухню на языке диаграмм Ганта. Когда штудирование документации и вычитывание кода библиотеки выливается в метрику +10 строк кода. (За половину месяца.) Ну ведь правда, как-то не солидно 0.125 строк кода в день. (Это сколько символов в день? А в час?) Правда?

Мы правда должны опускаться до уровня руководителей?

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

Но все же, что же с диалогом?

Если задаться вопросом: а нужно ли пасовать?

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

А если о диалоге?

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

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

Кейс разработки.
Разработчик завис над простой задачей. Занимался задачей две недели. По результатам двух недель работы внес в репозиторий изменений на 10-20 строк кода. В отчете по задаче множество технических деталей. В отчете выставил необходимость дополнительного времени на доработку задачи.

Если для вас кейс очевиден, то можно дальше и не читать.

Список проблем.

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

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

Возможность конфликта с разработчиком.

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

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

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

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

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

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

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

И так далее. (Прописываю только часть проблем.)

Решения.

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

Спасибо.

Для этого нам понадобится

1. Действующий account Google Play Developer

2. Сервер Linux с предустановленным Docker, в моём случае это Ubuntu 16.04

3. Установленный Android SDK

4. Jenkins - в данном случае развернём его при помощи Docker

5. Gitea - Удобная служба для собственного Git-репозитория (это не обязательно можно использовать и GItHub) её мы подымем также на базе Docker контейнера

Настройка Google Play Account

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

1. Авторизуйтесь в Google Cloud Platform, если еще не создан проект то создаём его

2. В разделе IAM и администрирование - Сервисные аккаунты жмём Создать сервисный аккаунт

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

4. Авторизуйтесь в Gooogle Play Developer Console

5. В разделе Пользователи и разрешения нажимаем пригласить пользователя сервисного аккаунта по сгенерированному email , выставляем ему роль Релиз менеджер (при необходимости можете настроить права этого пользователя более детально)

6. Я предполагаю что Сертификат для ключа подписи приложения, и Сертификат ключа загрузки у вас уже настроен и это не требует пояснений.

Установка Android SDK

# Install latest JDKsudo apt install default-jdksudo apt install android-sdk

Добавьте Android SDK в свой PATH, откройте~/.bashrcв редакторе и скопируйте следующие строки

# Export the Android SDK path export ANDROID_HOME=$HOME/android-sdkexport PATH=$PATH:$ANDROID_HOME/tools/binexport PATH=$PATH:$ANDROID_HOME/platform-tools# Fixes sdkmanager error with java versions higher than java 8export JAVA_OPTS='-XX:+IgnoreUnrecognizedVMOptions --add-modules java.se.ee'

Для проверки запустите

source ~/.bashrc

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

sdkmanager --list

По аналогии с выполните установку интересующих вас версий инструментов для нужных платформ

sdkmanager "platform-tools" "platforms;android-28"

На этом установка Android SDK может считаться завершённой, и в дальнейшем нам понадобится лишь путь к установленным инструментам, в моём случае это выглядит как то так

Установка Gitea

Этот шаг является опциональным и совсем не обязательным если вы предпочитаете использовать git репозитарии такие как GitHub и им подобные и его можно пропустить, это малой степени повлияет на конечный результат. (На базе gitea в дальнейшем будет обсуждаться тема создания Telegram Bot`a для оповещения о публикациях)

Подробно по установке и настройке написано на оф сайте https://docs.gitea.io/en-us/install-with-docker/

По факту установка сводится к выполнению 2х действий

1) Перейдите на официальный репозитарий Gitea , на Docker HUB и скопируйте то что там написано в предварительно созданный файл

version: '2'services:  web:    image: gitea/gitea:1.12.4    volumes:      - ./data:/data    ports:      - "3000:3000"      - "22:22"    depends_on:      - db    restart: always  db:    image: mariadb:10    restart: always    environment:      - MYSQL_ROOT_PASSWORD=changeme      - MYSQL_DATABASE=gitea      - MYSQL_USER=gitea      - MYSQL_PASSWORD=changeme    volumes:      - ./db/:/var/lib/mysql

2) Сохраните и запустите команду docker-compose you_filename

3) Gitea установлена и доступна по URL http://you_IP:3000/

4) Создайте пользователя, репозитарий, сделайте PUSH исходного кода вашего проекта, и в моём случае для упрощения процесса публикации приложения все необходимые ключи для его подписи и деплоя я храню в месте с исходным кодом в системе контроля версий (да знаю это не совсем верно и вы вольны делать так как считаете нужным, к примеру создать отдельный volume для ключей и пробрасывать их jenkins для дальнейшего их использования gradle при подписании приложения, описание этого лишь раздует статью и потому не будет рассматриваться)

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

Для подписания нашего apk файла в автоматическом режиме на стороне сервера, нам нужен файл нашего keystore и правильно настроенный скрипт gradle , для этого добавим в него несколько секций

// Load keystoredef keystorePropertiesFile = rootProject.file("keystore.properties")def keystoreProperties = new Properties()keystoreProperties.load(new FileInputStream(keystorePropertiesFile))// GenerateNameVersiondef getVersionNameTimestamp() {    return new Date().format('yy.MM.ddHHmm')}// GenerateVersionCodedef getVersionCodeTimestamp() {    def date = new Date()    def formattedDate = date.format('yyMMddHHmm')    def code = formattedDate.toInteger()    println sprintf("VersionCode: %d", code)    return code}......android {    signingConfigs {        config {            keyAlias keystoreProperties['keyAlias']            keyPassword keystoreProperties['keyPassword']            storeFile file(keystoreProperties['storeFile'])            storePassword keystoreProperties['storePassword']        }    }......    defaultConfig {        versionCode getVersionCodeTimestamp()        versionName "${getVersionNameTimestamp()}"

Содержимое файла keystore.properties

storePassword=you_password_keystorekeyPassword=you_password_keykeyAlias=you_key_namestoreFile=path_to_keystore_file

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

• Для публикации в Google Play требуется уникальная версия сборки, и я генерирую её скриптом Gradle на основании текущей даты и времени, и как вы понимаете это исключает использование каких либо вразумительных номеров версий и если вам это важно , то вам придётся придумать некий другой механизм автоматизации версионирования, я же остановился на этом варианте - потому как хотел что бы deploy происходил по нажатию одной лишь кнопки (PUSH)

Установка Jenkins

Его мы развернём используя Docker , я применяю уже настроенный образ с нужными мне инструментами из своего репозитария, вы же вольны использовать официальный, принципиально ни чего не измениться

docker run -it -d -v jenkins_home:/var/jenkins_home -v /usr/lib/android-sdk:/usr/lib/android-sdk -p 8080:8080 -p 50000:50000 --env JENKINS_OPTS="--prefix=/jenkins" --restart always leganas/ls_repository:jenkins

пробрасываем в качестве volumes в в наш контейнер папку с установленным Android SDK

Теперь он запущен и доступен по адресу http://you_IP:8080/jenkins/

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

1) Для начала нам нужно настроить окружение , заходим System Configuration - Глобальные настройки , и добавляем Environment variables (возможно ваши пути будут отличатся)

2) В разделе Настройки - Конфигурация глобальных инструментов проверяем настройки Git и Gradle (по факту обычно там всё уже настроено)

3) Заходим Настройки - Управление пользователями , выбираем пользователя и его настройки, ищем строку API Token , создаём новый и сохраняем его , он нам понадобится.

4) В разделе управления плагинами проверяем и если нужно устанавливаем плагины Git, Git client, Google OAuth Credentials plugin, Google Play Android Publisher

5) Заходим Настройки - Manage Credentials Configure credentials -Store - Jenkins - Global credentials (unrestricted)- и создаём там 2 ключа доступа |

• для доступа к Git репозитарию

  в моём случае т.к. я использую Gitea я создаю обычную пару login/password , для GitHub есть специальный плагин и инструмент для авторизации

• для публикации приложения в Google Play Market

  создаём ключ используя JSON файл который создали в первом разделе данной инструкции

6) Теперь создайте проект вашего приложения в Jenkins и настройте его

• Управление исходным кодом - установите Git , укажите Repository URL и Credentials (которые создали на прошлом этапе)

• Триггеры сборки - выставите Trigger builds remotely (e.g., from scripts), в поле ввода введите любой случайный текст (он нам понадобится для удалённой активизации процесса сборки) при помощи GIt huck

• Добавьте шаг сборки Invoke Gradle script , и После сборочные операции - публикацию

Обратите внимание на поле Release traack , оно указывает то как будет опубликовано ваше приложение , в моём случае это "Внутреннее тестирование"

7) Запустите проект в ручную использую Web интерфейс Jenkins и посмотрите на результат в истории сборок - Вывод консоли Если вы всё сделали верно то ваше приложение должно быть подтянуто из Git репозитария до актуальной версии ветки /master , собрано , подписано и опубликовано на Google Play.

Автоматизация запуска сборки

Если мы всё сделали правильно и проект удачно был опубликован на Google Play , можно перейти к настройке его автоматического deploy по Git событию PUSH в /master ветку

1) Если вы используете Gitea как я то зайдите в репозитарий вашего проекта - Настройки - Git хуки, и в post-receive нажмите редактировать, и добавьте нечто этого рода

#!/bin/bashwhile read oldrev newrev refnamedo    branch=$(git rev-parse --symbolic --abbrev-ref $refname)    if [ "master" = "$branch" ]; then       curl --user you_user_name:you_user_token http://you_url_jenkins/job/you_project/build?token=you_tocken_build    fidone

• you_user_name - Имя пользователя от лица которого jenkins будет производить сборку

• you_user_token - Токен который был сгенерирован в настройках пользователя

• you_url_jenkins и вообще весь путь до хука можно посмотреть на странице настройки проекта Jenkins и будет выглядеть он примерно так :

После проведения такого рода манипуляций сборка проекта Jenkins будет начинаться автоматически после PUSH события в master вашего репозитария.

PS. Если же вы используете для хранения вашего кода другую Git систему то этот же код вы можете поместить руками в .git\hooks\post-update

Заключение

В случае положительного фидбэка от статьи, в следующей части я расскажу как написать Telegram бота для оповещения ваших тестировщиков о наличии обновления приложения на Google Play.

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

Контекст

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

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

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

Например, можно получить следующие преимущества:
* выделение наиболее важной для данного проекта части API;

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

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

Прием

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

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

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

Важно, чтобы это был хоть и код заглушек, но вполне компилируемый и вполне выполняемый код. Код, который можно рассматривать на code review. Чтобы можно было просить разработчиков попробовать использовать ваше внутреннее API, ещё на стадиях проектирования API.

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

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

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

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

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

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

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

Ниже я распишу каждый шаг схемы и инструментарий, применяемый нами для каждого шага.

Шаг 1. Проверка нагрузки ядер процессоров на сервере БД (Load Average)

В большинстве случаев внешним проявлением проблемы в работе базы данных является возросшая нагрузка на ядра процессоров сервера БД. Лучшей метрикой для диагностирования этого факта я считаю LOAD AVERAGE. При этом мне больше нравится эта метрика в пересчете на ядро процессора сервера БД. LA (Load Average) на ядро более 1 плохо. Это значит, что запрос к БД ожидает какое-то время, прежде чем выполниться.

Для отслеживания этой метрики мы применяем систему мониторинга Zabbix с возможностью настройки оповещений в различные каналы. Пример такой метрики при возникновении аварии:

Шаг 2. Нагрузка на ядро процессора (LA) изменилась более чем на 30 % по отношению к тому же времени того же дня недели?

При возникновении серьёзной аварии LA обычно растёт лавинообразно. Тем не менее, даже повышение на 30 % признак какой-то аномалии. Если рост LA заметен и превышает заданный лимит, то самое время перейти к шагу 3 и проверить количество подключений к базе данных. Если же роста LA нет, то лучше переходить к шагу 27.

ШАГ 3. Проверка количества подключений приложений к БД и динамика его роста

Это ещё один маркер, который даёт чёткое понимание, что с БД что-то пошло не так. Тут в большей степени интересна динамика роста количества подключений к базе.

В качестве инструмента мониторинга используем всё тот же Zabbix. Максимально разрешенное количество подключений к БД можно узнать, выполнив команду SHOW_MAX_CONNECTIONS.

Шаг 4.Количество подключений к БД резко выросло за короткий промежуток времени?

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

Шаг 5. Увеличить количество подключений, поставив пулер подключений

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

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

Если же приложение работает всё-таки оптимально, то стоит задуматься над использованием пулера подключений (самый распространенный PGBouncer). Этот сервис берёт на себя управление подключениями и делает это достаточно эффективно. Приложение для взаимодействия с БД будет обращаться к PGBouncer, а тот в свою очередь будет перенаправлять запрос к БД через свои подключения. Подробнее об этой технологии можно почитать тут: http://personeltest.ru/aways/habr.com/ru/company/okmeter/blog/420429/.

Я также встречался с ситуацией, когда пулер подключений (PGBouncer) был установлен, но в его работе возникали проблемы. Стоит обратить внимание на лимит подключений к БД в самом пулере. Также у PGBouncer (не знаю, как в аналогах) есть одна особенность реализации: при установлении подключения к БД открывается файловый дескриптор. Поэтому на нагруженных крупных экосистемах с большим количеством сервисов и баз, использующих централизованный PGBouncer, может возникнуть проблема с ограничением числа одновременно открытых файловых дескрипторов на уровне операционной системы

Шаг 7. Проверка наличия блокировок и запросов в ожидании в базе данных

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

Способ проверки этой гипотезы динамика с количеством запросом к БД в статусе "IDLE IN TRANSACTION". Мы используем механизм периодического замера количества запросов в этом статусе, с выводом соответствующего графика в Grafana.

Шаг 8. В БД много блокировок и запросов в ожидании

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

ШАГ 9. Убить все блокировки в БД

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

Сделать это можно устранив процесс, вызвавший блокировку pg_terminate_backend(pid);.

Шаг 10. Ситуация исправилась?

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

Шаг 11. Получение списка выполняемых запросов, отсортированных по частоте и стоимости

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

Шаг 12. Изучить SlowLog (запросы, которые выполняются дольше критичного времени)

Эта операция, возможно, сразу даст ответ, какие запросы нужно оптимизировать, без более трудоемкого анализа результатов PG_STAT_STATEMENTS. Обычно мы оба шага (11 и 12) выполняем параллельно, чтобы сразу получить представление о нагрузке на БД. Еще один плюс SlowLog получив выборку из него за более длительный период времени, мы сможем вычленить запросы, которых раньше не было (т. е. они выполнялись быстро), но в какой-то момент стали выполняться медленно, скорее всего из-за аварии.

Шаг 13. Есть дорогие запросы, которые ранее выполнялись быстро?

На этом шаге главной проблемой является определение, с какой скоростью выполнялись запросы ранее (до аварии). Утилиты SlowLog и PG_STAT_STATEMENTS дадут понимание о скорости выполнения запросов сейчас. Но чтобы найти проблемный запрос, нужно понимать, с какой скоростью запросы выполнялись ранее. Для этой цели я рекомендую использовать дополнительные утилиты PGHero или NewRelic. Это достаточно удобные инструменты, которые позволяют понять динамику скорости выполнения запросов.

Если видна деградация в скорости выполнения каких-то определенных запросов, то переходим к шагу 14. Если зафиксировать снижение скорости выполнения какого-то запроса не удалось, то переходим к шагу 30.

Шаг 14. Проверка плана по дорогим запросам

Если вам удалось выделить конкретный запрос с ярко выраженной негативной динамикой скорости выполнения, то следующий шаг детальный анализ запроса посредством утилиты EXPLAIN ANALYZE. Подробно о том, как работает эта команда и как интерпретировать результаты её выполнения, можно ознакомиться тут: https://thoughtbot.com/blog/reading-an-explain-analyze-query-plan.

Шаг 15. Требуется новый индекс?

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

Шаг 16. Индекс есть, но не используется (а раньше использовался)

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

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

ШАГ 17. Обновление статистики таблиц базы данных

Простая операция, которая может спасти положение. Для сбора статистики большей точности достаточно выполнить команду ANALYZE илиset default_statistics_target = 500; ANALYZE . 500 это количественный коэффициент образца таблицы, который PostgreSQL выбирает для расчёта статистики. Подробнее о механизме работы статистики и карт видимости можно почитать тут: https://postgrespro.ru/docs/postgrespro/10/routine-vacuuming.

Шаг 18. Ситуация исправилась?

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

Шаг 19. Пересоздание индекса

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

Пересоздаем индекс. Сделать это можно командой REINDEX (подробнее читайте тут: https://postgrespro.ru/docs/postgrespro/9.5/sql-reindex).

Переходим к шагу 31.

Шаг 20. Профиль работы с кешем (Hit/Miss)

Запрос вдруг неожиданно начал тормозить, но при этом индекс используется. Следующий шаг проверить работу кеша базы данных. Для этого лучше всего подойдёт метрика Hit/Miss количества записей, полученных запросом из кеша или выбираемых из базы данных с нуля. Мы для этих целей используем Zabbix.

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

Шаг 21. Расширить размер буфера БД

Эта мера даст нам какое-то время, но только том в случае, если можно расшириться на значительный объём. По сути, мы какую-то часть данных БД перегоним в кеш, что ускорит доступ к этим данным. Расширение размера буфера кеша БД определяется параметром shared_buffers в конфиге базы.

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

Шаг 22. Изменились параметры запроса?

Иногда может быть так, что скорость выполнения запроса снижается изза дополнительных параметров, которые выступают в качестве условия выборки данных. Например, если в роли фильтра выступал какой-то атрибут, идентификаторы которого перечислялись в предикате запроса (where atribut_id in (id1, id2, id3)), и какой-то момент вместо 23 идентификаторов стали передаваться несколько сотен, то очевидно, что скорость выполнения запросов упадёт. Возможно, понадобится создание нового индекса, который учитывал бы такой вариант выборки данных. Такое может случиться после очередного релиза смежной системы, читающей данные из вашего сервиса.

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

Шаг 23. Изменилось ли количество и размер временных файлов?

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

Если вы увидели, что количество временных файлов, создаваемых базой данных, резко выросло, то переходим к шагу 25. Иначе к шагу 24.

Шаг 24. Пересоздать индекс

Пересоздаём индекс. Сделать это можно командой REINDEX (подробнее можно почитать тут: https://postgrespro.ru/docs/postgrespro/9.5/sql-reindex).

Переходим к шагу 31.

Шаг 25. Увеличить размер Work_mem, либо оптимизировать запрос на стороне приложения

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

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

Переходим к шагу 31.

Шаг 26. Создать новый индекс с учётом новых входных параметров

Быстрее всего в этой ситуации будет создание нового индекса (возможно, составного), который облегчил бы выборку данных с учётом новых входных параметров запроса. Если это возможно, то переходим к шагу 27. Иначе к шагу 28.

Шаг 27. Создать новый индекс с учётом новых входных параметров запроса

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

Шаг 28. Исправление самого запроса на стороне приложения, исключение новых параметров

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

Шаг 29. Создать новый индекс

В том случае, если по результатам EXPLAIN ANALYZE пришло понимание, что базе нужен новый индекс, то проще всего его досоздать. Это можно сделать командой CREATE INDEX с указанием параметра CONCURRENTLYдля неблокирующего построения (подробнее можно почитать тут: https://postgrespro.ru/docs/postgresql/11/sql-createindex). Далее переходим к шагу 31.

Шаг 30. Проверка влияния дополнительных факторов (взаимодействие с жёстким диском, сторонние процессы на сервере, работа других БД)

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

• работа жёстких дисков/систем хранения данных;

• нагруженные запросы на другие базы данных, находящиеся на том же сервере что и ваша;

• сторонние процессы, выполняемые на сервере БД (например, работа антивируса);

• создание репликационных баз данных, в процессе чего происходит создание слепка данных с вашего мастера;

• сетевые проблемы и потери при взаимодействии приложения и базы данных.

Если таковые факторы найдены, то постарайтесь их устранить и переходите к шагу 31.

Шаг 31. Ситуация исправилась?

Ситуация стабилизировалась и проблема решена? Мы молодцы! В противном случае пора собирать всю королевскую рать и обращаться к DB-администратору.

Шаг 32. В БД много блокировок и запросов в ожидании?

По аналогии с Шагом 8 - проверяем динамику количества запросов к БД в статусе "IDLE IN TRANSACTION". Мы используем механизм периодического замера количества запросов в этом статусе, с выводом соответствующего графика в Grafana. Подчеркну, что блокировки нормальное явление, они периодически будут возникать. Но вот если у вас произошло резкое увеличение количества блокировок, то переходите к шагу 37. Если же диагностировать увеличение количества блокировок и запросов в ожидании не удалось, то переходите к шагу 33.

Шаг 33. Проверка логов PG Bouncer и логов приложений при подключении к PG Bouncer

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

Шаг 34. Есть проблемы с PGBouncer?

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

Шаг 35. Исправление проблемы с работой PGBouncer/подключение приложения напрямую к БД, в обход PGBouncer

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

Это временная мера для быстрого восстановления доступности сервиса. Это не решение проблемы!

Переходим к шагу 31.

Шаг 36. Требуется консультация аналитика

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

Шаг 37. Было ли недавнее изменение схемы данных БД?

Ситуация, когда неожиданно, без объявления войны в базе данных растёт аномальное количество блокировок и запросов в ожидании, крайне редка. Чаще всего это следствие релиза или миграции с изменением схемы данных БД. Если такое было в последнее время, то переходим к шагу 45. Если изменений в схеме данных не было, то переходим к шагу 38.

Шаг 38. Проверка журналов БД (или PG_STAT_ACTIVITY) для выявления запроса, вызвавшего блокировку

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

Шаг 39. Выявление сервисаинициатора запроса, вызвавшего блокировку

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

Шаг 40. Сервис, инициировавший запрос, работает штатно?

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

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

Шаг 41. Были ли недавно релизы сервиса, инициировавшего блокирующий запрос?

Если релизы сервиса, который инициирует блокирующие запросы, совпадают по времени с началом проблемы в БД, то неплохой мыслью будет откатить последний релиз. Это может помочь (переходим к шагу 43).

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

Шаг 42. Диагностика и починка сервиса, инициировавшего блокирующие запросы

Мы определили, что запросы, вызывающие блокировки, генерирует сервис, в котором на данный момент также возникли проблемы в работе. Гипотеза состоит в том, что ошибки в работе сервиса приводят и к ошибкам в работе БД. Целесообразно будет откатить последний релиз (если он был) или сосредоточиться на починке этого сервиса. Если мы приведем сервис в нормальное состояние, то, вероятно, и база данных начнёт работать в соответствии с ожиданиями.

После починки сервиса переходим к шагу 31.

Шаг 43. Откат последнего релиза

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

Шаг 44. Требуется консультация аналитика

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

Шаг 45. Откатить миграцию возможно?

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

Шаг 46. Откатить миграцию

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

Шаг 47. Ожидать завершения миграции

Лучше всего дождаться завершения миграции. Меньше проблем будет в дальнейшем. Затем переходим к шагу 31.

Заключение

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

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