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

Облачные сервисы

Новый портал для автоматизации от Check Point

23.12.2020 04:14:35 | Автор: admin

Приветствую читателей блога TS Solution, в последний месяц уходящего года продолжаем рассказывать вам о новостях в мире Check Point. Сегодня речь пойдет о новом едином портале - СheckMates Toolbox, он содержит в себе многочисленные инструменты по автоматизации для ежедневной работы администраторов. Контент верифицируется самим вендором, это говорит о долгосрочной поддержке данного проекта.

Коротко о главном

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

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

Вернемся же к проекту СheckMates Toolbox, его цель предоставить конечному пользователю единое пространство для того чтобы делиться инструментами и решениями при работе с оборудование Check Point, на момент выхода статьи существуют разделы:

  • SmartEvent;

  • Compliance;

  • Scripts;

  • SmartConsole Extensions;

  • Cloud Deployment.

Кроме представленной выше разбивки, существует опция для фильтрации решений - Verified by Check Point, которая соответственно подтверждает проверку со стороны вендора. От общих слов перейдем к самим категориям и на практических примерах разберем предлагаемые инструменты.

SmartEvent

Раздел содержит шаблоны для просмотра событий. Напомню, что блейд SmartEvent установленный на ваш Management Server или отдельный cервер, требует отдельной лицензии и коррелирует логи, далее создает отчеты по аналогии с SIEM-подобными системами.

Архитектура SmartEvent для любознательных

Correlation Unit (CU) В реальном времени считывает записи из текущего лог-файла сервера и анализирует их с помощью Correlation Policy, генерируя события безопасности, которые отправляет на Event Server.

Analyzer Server Загружает на Correlation Unit политики Event Policy, сохраняет полученные от Correlation Unit события безопасности в своей базе данных, взаимодействует с Security Management Server для организации блокировки источника угрозы на шлюзах безопасности Check Point. Подгружает с Security Management Server необходимые объекты. Предоставляет данные для генерации отчётов Reporting Server.

Analyzer Client Организует интерфейс взаимодействия и управления c Event Server, выводит информацию собранную на Event Server в различных представлениях.

Мы же используя СheckMates Toolbox, находясь в разделе SmartEvent, скачаем репорт - Unknown-Applications-Detection

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

Compliance

Раздел содержит лучшие мировые практики в области ИБ, которые вы можете использовать на Check Point, благодаря блейду Compliance ( требуется соответствующая активная лицензия ).

На портале представлено большое количество стандартов, загрузить их на ваш Management Server возможно из: Manage & Settings Blades Compliance Settings

Scripts

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

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

CPme

CCЛКА!

1) Соответственно, для загрузки требуется:

curl_cli https://raw.githubusercontent.com/0x7c2/cpme/main/cpme-install.sh -k | bash

2) запуск самой утилиты:

[Expert@CPGWSMS:0]# cpme

3) В меню возможен выбор:

4) пройдемся по разделам - Gaia Operating System (1)

Легко можно проверить доступность сервисов Check Point (3) и прочее:

5) Большое количество проверок самой системы - Health Analysis (2):

6) Полезны также будут Troubleshooting Options (7):

7) Отдельно отметим возможность собрать HTML-отчет (10), который вы можете просмотреть:

Remote Access VPN Statistics - OneLiner

ССЛКА!

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

Его также можно выполнять как Task ( отправляя из SmartConsole ).

Show AntiSpoofing Networks via CLI

ССЛКА!

Bash-скрипт, который собирает статистику работы Anti-Spoofing с ваших активных интерфейсов шлюза (Security Gateway). Для тех кто забыл или не знаком с технологией, она позволяет предотвратить подмену адресации со стороны источника или назначения, за счет того, что шлюз Check Point имеет информацию о типе трафика (внутренний, внешний и т.д.).

Вывод скрипта отобразит сети, которые попадают под Anti-Spoofing, что значительно сэкономит ваше время при траблшутинге машрутизации трафика ( необъяснимые дропы ).

SmartConsole Extensions

В данном разделе содержатся шаблоны для Extensions. Это позволяет оперативно получать различную системную информацию от вашего Security Gateway или Management Server в самой SmartConsole.

Чтобы активировать опцию необходимо перейти: Manage & Settings Preferences SmartConsole Extensions

Где загрузим соответствующий URL: https://dannyjung.de/ds.json

Он взят из примера:

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

Cloud Deployment

Раздел для автоматизации развертывания продуктов Check Point в облачных провайдерах. На момент выхода статьи он только появился и содержал лишь 1 решение.

Предложенный bash-скрипт позволит развернуть Cloud Guard в облаке Google в полуавтоматическом режиме.

Вместо заключения

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

Следите за обновлениями в наших каналах (Telegram,Facebook,VK,TS Solution Blog)!

Подробнее..

Как АНБ и ЦРУ используют дата-центры и облака

23.12.2020 14:04:12 | Автор: admin

Дата-центр АНБ в Юте на картах Google Maps

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

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

Дата-центры




Главный дата-центр АНБ в штате Юта под кодовым названием Bumblehive (Шмель) введён в строй в сентябре 2013 г. Ориентировочная стоимость строительства на площади почти 10 га оценивается в $1,5 млрд.

Объём дискового хранилища Шмеля в 2013 году оценивали в 5 зеттабайт (510). Для сравнения, в 2020 году мировой объём IP-трафика оценивается примерно в 250 эксабайт в месяц (Statista), то есть примерно 3 зеттабайта в год. С подводных межконтинентальных кабелей АНБ уже в 2013 году снимало 2 петабайта в час, а сейчас гораздо больше.

Поэтому АНБ наверняка пришлось сделать апгрейд дисковых накопителей в последние годы, если они по-прежнему хотят сохранять копию всего мирового интернет-трафика.





На схеме показаны:

  • четыре помещения для серверов общей площадью 9290 м;
  • офис для технического и административного персонала;


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


    Запасы воды и топлива
  • резервуары с водой и насосы, пропускная способность 6,4 млн л в сутки;


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

Площадь всех административных и технических зданий 83 613 м.

Другую техническую информацию по дата-центру Шмель см. здесь.

Место в Юте выбрано не случайно. Оказывается, крупнейшие американские ЦОД располагаются у 41-й параллели северной широты.



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

Другие дата-центры АНБ не такие впечатляющие. Есть суперкомпьютер в Форт-Миде, где находится штаб-квартира. Он нужен для оперативной деятельности. Также в строю ЦОД в Сан-Антонио (Техас), криптологические центры в Джорджии стоимостью $286 млн и Сант-Антонио (Техас) стоимостью $300 млн, которые используются для взлома шифров.


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

Из документов Сноудена выяснилось, что у АНБ есть небольшой ЦОД даже в Великобритании. Дата-центр на станции Menwith Hill (Field Station 8613) была секретно построен в период с 2009 по 2012 годы с бюджетом $40 млн.



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

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



Дата-майнинг


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





Вот список некоторых целей по сбору данных АНБ. Каждый тип данных нуждается в классификации, индексировании и отдельном анализе:

  • поисковые запросы;

    пример базы данных с поисковыми запросами государственных служащих с указанием места работы и IP-адреса сотрудника:


  • посещённые сайты;
  • полученная и отправленная почта;
  • активность в соцсетях (Facebook, Twitter и др.)
  • активность в блогах: опубликованные и прочитанные посты, оставленные комментарии (патент АНБ на технологию определения темы текста путём анализа существительных);
  • звукозаписи телефонных переговоров с биометрической идентификацией личности по голосу (патент АНБ);
  • видеозвонки через Zoom, Google Meet и др.;
  • ДНК;
  • и многое другое.

Объём растёт в экспоненциальной прогрессии. Например, в последние годы добавились видеозаписи с камер наблюдения.

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

В дата-центре Шмель установлен суперкомпьютер Cray XC30. В каждую стойку Cray XC30 входит до 384 процессоров Intel Xeon E5-2600 либо Intel Xeon E5-2600 V2.


Cray XC30


Распаковка суперкомпьютера Cray XC30 (источник)

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





На узел устанавливается 32-128 ГБ памяти с пропускной способностью до 117 ГБ/с. Для связи между узлами применяется фирменная шина интерконнекта Aries.

Суперкомпьютеры XC30 работают под управлением операционной среды Cray Linux Environment, в состав которой входит SUSE Linux Enterprise Server.

Облачные сервисы


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

Сейчас ЦРУ и АНБ постепенно отказываются от собственных ЦОД и переходят в облако, причём частично используют инфраструктуру обычных провайдеров, начиная с AWS.

Агентства вроде ЦРУ и АНБ самые жирные заказчики для облачных провайдеров. Бюджеты не ограничены, объёмы данных колоссальные.

Commercial Cloud Enterprise


В ноябре 2020 года стало известно, что ЦРУ заключило мультиоблачный контракт Commercial Cloud Enterprise (C2E) сразу с пятью облачными провайдерами: Amazon Web Services, Microsoft, Google, Oracle и IBM, в то время как с 2013 года она эксклюзивно пользовалась только AWS по десятилетнему контракту на $600 млн на 2013-2023 годы. Теперь ЦРУ переходит в гибридное облако и будет выбирать наиболее подходящего поставщика облачных услуг для конкретных рабочих нагрузок.

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

ЦРУ специализируется на деятельности исключительно иностранных организаций и граждан. Другое дело АНБ. Вот уже эта структура осуществляет прослушку электронных коммуникаций и за границей, и внутри страны, охватывая всё местное население. Объёмы данных у них на порядок больше, чем у ЦРУ.

Intelligence Community GovCloud


По примеру других разведывательных агентств, к 2018 году АНБ тоже перенесло бльшую часть своих данных в облако. Но совсем другое облако это Intelligence Community GovCloud, которое работает на инфраструктуре АНБ (on-premise), на стандартном железе, но с использованием множества уникальных наработок АНБ по аппаратной и программной части.

Commercial Cloud Enterprise и Intelligence Community GovCloud от ЦРУ и АНБ в каком-то смысле два конкурента. Каждое из 16-ти агентств, которые входят в Разведывательное сообщество, может выбрать C2E или GovCloud.

Кроме того, есть ещё инфраструктура Джедай (Joint Enterprise Defense Infrastructure, JEDI) Минобороны США, которое заключило эксклюзивный контракт с Azure в октябре 2019 года, но до сих пор правомерность сделки оспаривается в суде компанией Amazon.

С точки зрения логической архитектуры Intelligence Community GovCloud это общий центр, единая среда для удобной работы с множеством разрозненных источников данных. Оно описывается как озеро данных (data lake), которое запрашивает данные из внешних хранилищ АНБ и других ведомств.

Информационный директор АНБ Грег Смитбергер рассказывал, что благодаря GovCloud стало проще применять алгоритмы машинного обучения. Вся информация, поступающие в озеро, помечается тегами с указанием источника и уровня доступа у кого есть право работать с этими данными. Это должно защитить в том числе от таких масштабных утечек, как в случае с Эдвардом Сноуденом. Ведь он работал в консалтинговой компании Booz Allen Hamilton (подрядчик АНБ) и формально не должен был получить доступ к секретным файлам, которые вынес из здания операционного центра АНБ на Гавайях.


Кадр из фильма Сноуден

АНБ сейчас тоже смотрит в сторону гибридного облака на публичной инфраструктуре. О проекте Hybrid Compute Initiative (HCI) рассказал информационный директор Разведывательного сообщества США Джон Шерман на конференции AFCEA NOVA. Он говорит, что это будет своего рода эволюционное развитие GovCloud.

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

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



На правах рекламы


Виртуальные серверы с новейшим железом, защитой от DDoS-атак и огромным выбором операционных систем. Максимальная конфигурация 128 ядер CPU, 512 ГБ RAM, 4000 ГБ NVMe.

Подробнее..

Стражи публичных облаков как мы внедряли анклавы Intel SGX для защиты чувствительных данных

14.01.2021 16:09:15 | Автор: admin
Как развеять предубеждения потенциальных пользователей относительно безопасности публичных облаков? На помощь приходит технология Intel Software Guard Extensions (Intel SGX). Рассказываем, как мы внедрили её в своём облаке и какие преимущества от нашего решения получила компания Aggregion.





Кратко об Intel SGX и его роли в облаке


Intel Software Guard Extensions (Intel SGX) набор инструкций ЦП, с помощью которых в адресном пространстве приложения создаются частные защищённые области (анклавы), где размещается код уровня пользователя. Технология обеспечивает конфиденциальность и целостность чувствительных данных. Путём изоляции в анклаве они получают дополнительную защиту как от несанкционированного внешнего доступа, в том числе со стороны провайдера облачных услуг, так и от внутренних угроз, включая атаки со стороны программного обеспечения привилегированного уровня.

Принципы работы. Для хранения кода и данных анклавов технология Intel SGX выделяет область памяти Processor Reserved Memory (PRM). ЦП защищает её от всех внешних обращений, в том числе от доступа со стороны ядра и гипервизора. В PRM содержится Enclave Page Cache (EPC), состоящий из блоков страниц объёмом 4 КиБ, при этом каждая страница должна принадлежать только одному анклаву, а их состояние фиксируется в Enclave Page Cache Metadata (EPCM) и контролируется ЦП.

Безопасность EPC обеспечивается за счёт Memory Encryption Engine (MEE), который генерирует ключи шифрования, хранящиеся в ЦП. Предполагается, что страницы могут быть расшифрованы только внутри физического ядра процессора.

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

Наш подход к внедрению Intel SGX


Чтобы в публичном облаке G-Core Labs появилась возможность выделять виртуальные машины с анклавами Intel SGX, нам пришлось пройти путь от компиляции патченного ядра KVM и QEMU до написания Python-скриптов в сервисах OpenStack Nova. Вычислительные узлы, которые планировалось использовать для выделения виртуальных машин повышенной безопасности, мы решили определить в отдельный агрегатор тип вычислительных ресурсов, требующий дополнительной настройки. На таких узлах было необходимо:

  • Включить поддержку Intel SGX на уровне BIOS.
  • Поставить патченные QEMU/KVM.

Изначально у нас не было понимания, как это должно работать и что в итоге мы должны прикрутить, чтобы получить ВМ нужной конфигурации. Разобраться с этим вопросом нам частично помогло руководство Intel для разработчиков. С его помощью мы узнали, как подготовить вычислительный узел для работы с SGX и какими дополнительными параметрами должен обладать конфигурационный XML-файл виртуальной машины. Здесь же мы нашли исчерпывающую информацию, как с помощью виртуализации KVM сделать гостевую машину с использованием Intel SGX. Чтобы убедиться, что мы смогли обеспечить поддержку данной технологии, мы использовали два способа:

  • Проверили секцию /dev/sgx/virt_epc в файле /proc/$PID/smaps:

    [root@compute-sgx ~]# grep -A22 epc /proc/$PID/smaps7f797affe000-7f797b7fe000 rw-s 00000000 00:97 57466526/dev/sgx/virt_epcSize:               8192 kBKernelPageSize:        4 kBMMUPageSize:           4 kBRss:                   0 kBPss:                   0 kBShared_Clean:          0 kBShared_Dirty:          0 kBPrivate_Clean:         0 kBPrivate_Dirty:         0 kBReferenced:            0 kBAnonymous:             0 kBLazyFree:              0 kBAnonHugePages:         0 kBShmemPmdMapped:        0 kBFilePmdMapped:         0 kBShared_Hugetlb:        0 kBPrivate_Hugetlb:       0 kBSwap:                  0 kBSwapPss:               0 kBLocked:                0 kBTHPeligible:0VmFlags: rd wr sh mr mw me ms pf io dc dd hg
    
  • И воспользовались данным shell-скриптом, предварительно поставив SGX-драйвер (все действия осуществлялись внутри ВМ):

    [root@sgx-vm ~]# cat check_sgx.sh#!/bin/bashMETRICS="sgx_nr_total_epc_pages \    sgx_nr_free_pages \    sgx_nr_low_pages \    sgx_nr_high_pages \    sgx_nr_marked_old \    sgx_nr_evicted \    sgx_nr_alloc_pages \    "MODPATH="/sys/module/isgx/parameters/"for metric in $METRICS ; do    echo "$metric= `cat $MODPATH/$metric`"done[root@sgx-vm ~]# curl -fsSL https://raw.githubusercontent.com/scontain/SH/master/install_sgx_driver.sh | bash -s - install -p metrics -p page0[root@sgx-vm ~]# ./check_sgx.shsgx_nr_total_epc_pages= 2048sgx_nr_free_pages= 2048sgx_nr_low_pages= 32sgx_nr_high_pages= 64sgx_nr_marked_old= 0sgx_nr_evicted= 0sgx_nr_alloc_pages= 0
    

    Стоит учитывать, что, если одна страница занимает 4 КиБ, то для 2048 страниц требуется 8 МиБ (2048 x 4 = 8192).

Трудности разработки и их преодоление


Отсутствие какой-либо технической документации по интеграции Intel SGX в OpenStack было нашей основной трудностью на момент внедрения. Поиск привел нас к статье проекта SecureCloud, где был представлен способ управления виртуальными машинами с анклавами SGX.

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

  1. Добиться от сервиса OpenStack Nova генерации XML-файла с дополнительными параметрами для виртуальных машин с поддержкой Intel SGX.
  2. Написать фильтр планировщика OpenStack Nova с целью определения доступной памяти для анклавов на вычислительных узлах и осуществления некоторых других проверок.

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

Кроме того, мы дописали сбор статистики с учетом EPC:

# openstack usage showUsage from 2020-11-04 to 2020-12-03 on project a968da75bcab4943a7beb4009b8ccb4a:+---------------+--------------+| Field         | Value        |+---------------+--------------+| CPU Hours     | 47157.6      || Disk GB-Hours | 251328.19    || EPC MB-Hours  | 26880.02     || RAM MB-Hours  | 117222622.62 || Servers       | 23           |+---------------+--------------+


Безопасная среда для запуска контейнеризированных приложений



Научившись выделять виртуальные машины с поддержкой Intel SGX, мы использовали платформу SCONE компании Scontain, чтобы обеспечить возможность безопасного запуска контейнеризированных приложений в случае угроз со стороны привилегированного программного обеспечения. При использовании данного решения для прозрачной защиты файловых систем в средах Docker, Kubernetes и Rancher достаточно наличия процессора Intel с поддержкой SGX и драйвера Linux SGX.

Запуск каждого из контейнеров возможен лишь при наличии файла конфигурации, создаваемого клиентским расширением платформы SCONE. В нём содержатся ключи шифрования, аргументы приложения и переменные среды. Файлы, сетевой трафик и стандартные потоки ввода/вывода (stdin/stdout) прозрачно зашифрованы и недоступны даже для пользователей с правами root.
Платформа SCONE оснащена встроенной службой аттестации и конфигурации, проверяющей приложения на соответствие принятой политике безопасности. Она генерирует приватные ключи и сертификаты, которые должны быть доступны только в пределах анклава. Конфиденциальность и целостность данных в процессе их передачи обеспечиваются криптографическим протоколом TLS.

С помощью драйвера SGX для каждого анклава в виртуальном адресном пространстве резервируется до 64 ГБ памяти. Платформа SCONE поддерживает языки программирования C/C++/C#/Rust/Go/Python/Java. За счёт специального компилятора исходный код автоматически (без необходимости дополнительных модификаций) подготавливается к использованию совместно с Intel SGX.

Кейс Aggregion


Завершив все необходимые работы по интеграции Intel SGX, мы подключили к нашему публичному облаку платформу управления распределёнными данными компании Aggregion.

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

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

Принципы безопасной работы на платформе Aggregion. В контуре каждого поставщика чувствительные данные изолируются в анклавы Intel SGX, которые фактически представляют собой чёрные ящики: что происходит внутри, недоступно никому, в том числе и провайдеру облачной инфраструктуры. Проверка первоначального состояния анклава и возможности его использования для хранения конфиденциальной информации осуществляется за счёт удалённой аттестации, когда MrEnclave определяет хеш-значение.

Потенциальная польза для клиентов. Комбинирование баз данных нескольких поставщиков позволяет повысить эффективность совместных рекламных кампаний. При выделении целевой аудитории по заданным параметрам мэтчинг (сопоставление) сегментов выполняется непосредственно внутри контейнеров с поддержкой анклавов Intel SGX. За пределы выводится только конечный результат: например, численность пользователей, соответствующих выбранным атрибутам. Аналогичным образом оценивается эффективность проведенных кампаний: в анклавы выгружаются данные о рекламных показах и совершённых продажах для вычисления прироста покупок целевой группы относительно контрольной, который и выдаётся наружу для дальнейшего использования.



Выводы


Мы понимаем, что Intel SGX не является панацеей по защите данных и можно найти ряд статей, порицающих эту технологию, в том числе и на Хабре. Периодически появляются сообщения об атаках, способных извлечь конфиденциальные данные из анклавов: так, в 2018 году бреши в SGX пробили Meltdown и Spectre, в 2020 году SGAxe и CrossTalk. В свою очередь компания Intel устраняет выявленные уязвимости с помощью обновлений микрокода процессоров.

Почему же мы всё-таки решили внедрить данную технологию? Мы видим в применении Intel SGX возможность сократить потенциальную область кибератак за счёт создания дополнительного контура защиты облачной инфраструктуры G-Core Labs наряду с уже задействованными технологиями информационной безопасности и тем самым повысить доверие наших пользователей к хранению и обработке конфиденциальных данных. Надеемся, что в будущем нам ещё предстоит поделиться с вами успешными клиентскими кейсами, хотя и не берёмся утверждать, что наши статьи не будут основаны на историях обнаружения и устранения новых уязвимостей. А пока предлагаем вам поделиться своими методами по защите чувствительных данных в комментариях.
Подробнее..

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

18.01.2021 16:06:50 | Автор: admin
image

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

Вступление


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

Есть хорошие и плохие способы осуществить эту миграцию в облако. Многие подводные камни не новы. Например, на одной встрече Gartner 2019 два ИТ-менеджера заявили, что их развертывание Office 365 было приостановлено из-за необходимости обновления устаревшего оборудования. Теперь то, как мы используем и совместно используем наши домашние компьютеры, изменилось. Наши компьютеры больше не личные. Этот же компьютер может поддерживать виртуальную школу вашего ребенка и приложения вашего супруга.

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

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

1. Использование VPN для удаленного доступа


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

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

2. Создание неправильного облачного портфеля


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

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

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

3. Ваша политика безопасности не подходит для облака


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

Johnson & Johnson сделали это несколько лет назад, когда перенесли большую часть своих рабочих нагрузок в облако и централизовали свою модель безопасности. Есть помощь: Netflix только что выпустил инструмент с открытым исходным кодом, который они называют ConsoleMe. Он может управлять несколькими учетными записями Amazon Web Services (AWS) в одном сеансе браузера.

4. Не тестировать планы аварийного восстановления


Когда вы в последний раз тестировали свой план аварийного восстановления (DR)? Возможно, это было слишком давно, особенно если вы были заняты повседневными проблемами, связанными с поддержкой домашних работников.

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

Еще одна важная часть любого плана аварийного восстановления это непрерывное тестирование на предмет частичных сбоев облака. Скорее всего, у вас будут перебои в работе. Даже Amazon, Google и облака Microsoft испытывают это время от времени. Netflix был одним из первых мест, где несколько лет назад стала популярной общая инженерия хаоса с помощью инструмента под названием Chaos Monkey. Он был разработан для тестирования инфраструктуры AWS компании путем постоянного и случайного отключения различных рабочих серверов.

Используйте эти уроки и инструменты, чтобы разработать собственное тестирование отказов, особенно тесты, связанные с безопасностью, которые выявляют слабые места в вашей облачной конфигурации. Ключевой элемент делать это автоматически и постоянно, чтобы выявлять узкие места и недостатки инфраструктуры. Помимо использования инструментов с открытым исходным кодом от Netflix, есть коммерческие продукты, такие как Verodin / Mandiant's Security Validation, SafeBreachs Breach and Attack Simulation, инструменты моделирования Cymulate и AttackIQ's Security Optimization Platform.

5. Не оптимизирована аутентификация для портфеля с преобладающим облачным сервисом


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

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

6. Устаревший Active Directory


Идентичность это теперь новый периметр, и данные распространяются повсюду, заявили Дэвид Махди и Стив Райли из Gartner в своей презентации.

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

Разумеется, здесь стоит многое исправить. Это означает, что ваша Active Directory (AD) может не отражать реальность как из списка текущих и авторизованных пользователей, так и из текущих и авторизованных приложений и серверов.

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

7. Отказ обратиться за помощью


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

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

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

14.01.2021 00:13:39 | Автор: admin

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

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

Фотография: Chris Panas. Источник: Unsplash.comФотография: Chris Panas. Источник: Unsplash.com

Без разбора

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

Последнее время с ними сталкиваются исполнители классической музыки. В прошлом году американский ансамбль Camerata Pacifica на страничке в соцсети транслировал Кегельштатт-Трио Моцарта. Для музыкантов это был один из немногих способов заработка в условиях весеннего и летнего карантина. Но через несколько минут после старта стрима, трансляцию заблокировали. Алгоритмы обнаружили в записи фрагмент, права на который принадлежат студии Naxos of America хотя творчество Моцарта уже давно считается общественным достоянием. Скорее всего речь идет о сравнении с другим исполнением коллективом, который как раз и сотрудничает с этим лейблом. Таких ситуаций много аналогичным образом заблокировали композитора из Балтимора, играющего в Колумбийском оркестре. В мае прошлого года он стримил сонату Бетховена в прямом эфире, но его выступление остановили.

Фотография: Ben Hershey. Источник: Unsplash.comФотография: Ben Hershey. Источник: Unsplash.com

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

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

Новые правила

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

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

Фотография: Oleksandr Kurchev. Источник: Unsplash.comФотография: Oleksandr Kurchev. Источник: Unsplash.com

Сейчас Twitch пытается найти решение проблемы. В конце прошлого года компаниязапустиласобственную музыкальную библиотеку Soundtrack с одобренными инди-треками. Среди лейблов-партнеров уже числятся MonsterCat, Chillhop Music, SoundCloud. Но пока сервис критикуют за небольшую библиотеку, невозможность формировать плейлисты и плохой поиск.

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

Еще вариант обратиться к другим акустическим библиотекам с треками и семплами под лицензией Creative Commons. Работа с такими аудиозаписями позволит избежать проблем с алгоритмами на всех площадках, в том числе на YouTube. О некоторых таких ресурсах мы рассказывали в наших подборках они доступны в нашем Мире Hi-Fi:

Что дальше

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

Под конец 2020 года в США начали обсуждать поправку к Закону об авторском праве в цифровую эпоху (DMCA). Если её одобрят в текущем виде, то даже нелицензионное использование музыкального трека в видео может стать уголовным преступлением. Следуя этой логике, площадки смогут ввести еще более жесткие ограничения по контенту своих правилах.


Дополнительные материалы для изучения:


Подробнее..

В интернете опять кто-то неправ

11.01.2021 14:11:20 | Автор: admin
АйТи отрасль глубоко больна уже не первый год. Точнее, весь мир глубоко болен, а айти отрасль, идущая в авангарде, стала самым опасным носителем и распространителем этой болезни. Что же за болезнь такая, спросите, вероятно, вы?

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

Теперь все это более и более отчетливо наблюдается и в АйТи. Заметьте, начиналось все это как обычно с довольно-таки правильных начинаний а давайте будем модерировать контент/приложения чтобы не было всякой порнографии и прочего непотребства. Однако, систему стоит лишь один раз запустить и остановить ее уже сложно. Любой индус в Гугле или Эпл без объяснения причины мог забанить приложения по одному ему ведомому принципу, ведь безопасный интернет это всеобщее благо. Ну и что очевидно, закончилось все блокировкой аккаунтов Трампа и сети Parler. (Стоит также отметить и Apple и Epic Games, история схожая, лишь мотивация немного разная)
image
Holston for The New York Times

Хочется сразу отметить, что я не сторонник Трампа или теорий заговора/плоской земли. Но то, что происходит это обыкновенная диктатура, хоть и в интернете. Какая-то группа людей решает за другую группу, что она должна думать и писать, а что нет, перед кем должна вставать на колени, а кого забанить. Да, все это происходит под прикрытием нарушений прав пользователей, однако правила и законы действуют избирательно. С одной стороны, они банят и советуют идти в суд, а с другой стороны, банят они по причине общественной опасности, которая судом как-раз-таки никак и не установлена. С какой стати руководство Фейсбук вправе решать забанить или нет человека, за которого проголосовали десятки миллионов сограждан? Да, у них есть пользовательские соглашения, но не стоит забывать, что они также монополисты на рынке.

Главная цель любого СМИ, а социальные сети по сути им и являются, это обеспечение нормальной обратной связи между членами общества и государством. Любые попытки цензуры нарушают эту обратную связь. Если в стране много поклонников теории плоской земли, значит в стране есть проблемы с образованием и значит деньги нужно вкладывать не в цензуру, а в образовательные проекты. Если у вас в стране голосуют за Трампа 70 млн человек, значит в обществе назрел глубокий раскол и нужно что-то делать, чтобы наладить диалог между лагерями, а не банить лидеров мнения. Потому что, если забанить, вы уберете обратную связь, но не решите существующие проблемы, а застоявшиеся проблемы гораздо чаще приводят к кровопролитию, чем лозунги в Твиттере.

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

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

Отличие сервисов аналитики маркетплейсов, подробный анализ

27.12.2020 02:13:31 | Автор: admin

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

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

Я зарегистрировался в 4 таких сервисах и решил провести обзор с описанием своих ощущений.

1. Moneyplace.io - сервис одновременной аналитики Wildberries, Ozon и AliExpress

Анализ продаж маркетплейсов Wildberries, Ozon и AliExpressMoneyplace.io

Первый сервис для аналитики продаж на маркетплейсах - Moneyplace.io. По числу маркетплейсов - он лидирует, кроме популярных Wildberries и Ozon, они анализируют еще и AliExpress, что является большим преимуществом, ведь этот маркетплейс активно выходит на рынок России и уже в 2021 году обещают поставить100 000 постаматовв крупных городах. По всей видимости в России вскоре появится новый лидер в этой сфере.

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

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

Анализ продаж маркетплейсов Wildberries, Ozon и AliExpressMoneyplace.io

Информация структурирована в табличном и графическом виде. Определять самые продающиеся товары интуитивно понятно. Есть вывод данных за 7, 14 или 30 дней по трем маркетплейсам.

В примере ниже, например, сразу видно, чтоКрем-спрейпродался за 7 дней на3,6 млн. руб.аПодгузникина2,7 млн. руб.Понравилось, что эти данные видны еще до захода в карточку анализа товара.

Анализ продаж товарах на маркетплейсахMoneyplace.io

В таком же виде можно оценить объем продаж каждой категории и подкатегории на всех маркетплейсах.

Анализ продаж категорий маркетплейсовMoneyplace.io

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

Анализ продавцов на маркетплейсахMoneyplace.io

Выведены для анализа все товары, которые есть у продавца - это полезно с точки зрения конкурентной разведки.

Анализ товаров у продавцов на маркетплейсахMoneyplace.io

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

Тарифы на сервисы аналитики маркетплейсовMoneyplace.io

Сайт:Moneyplace.io

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

2. mpstats.io - сервис аналитики wildberries и ozon

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

Анализ продаж на маркетплейсахmpstats.io

В сервис вам необходимо загрузить API своего магазина Ozon или WildBerries и он выведет статистику по продажам и состоянию склада в графическом и табличном виде.

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

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

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

Аналитика категорий на маркетплейсахmpstats.io

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

Анализ товаров на маркетплейсахmpstats.io

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

Глубокий анализ товаров на маркетплейсахmpstats.io

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

Тарифы на сервисы аналитики маркетплейсовmpstats.io

Сайт:mpstats.io

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

3. EggHeads Solutions - сервис аналитики валдберрис

Увеличение продаж на WildberriesEggHeads Solutions

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

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

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

Сайт:eggheads.solutions

4. Pi-Data - сервисы для оптимизации продаж на Wildberries и Ozon

Оптимизация продаж наWildberries и OzonPi-Data

Очень крутой сервис для профессионалов. Такое количество аналитической информации я не встретил ни у кого на рынке. Тут и PnL анализ и АВС и география продаж, и десятки или даже сотни графиков в разных разрезах информации.

Графический анализ продаж на маркетплейсахWildberries и OzonPi-Data

ABC анализ продаж на маркетплейсах Wildberries и OzonPi-Data

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

Контроль поставок на маркетплейсахWildberries и OzonPi-Data

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

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

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

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

Тарифы на сервисы аналитики маркетплейсовPi-Data

Тарифы начинаются от2 999 рубна начальном тарифе до18 999 руб в месяцна профессиональном.

Сайт:Pi-Data.ru

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

В заключение:

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

Чтобы спрогнозировать и увеличить свои продажи, на мой взгляд очень перспективно пользоваться аналитическими сервисами, описанными выше. Благодаря им бизнес становится прозрачным, еще до вложения денег, вы можете на 99% знать, какими будут ваши продажи. Вы можете увидеть тренд (новинки товаров) и быть в самом его зарождении.

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

Подробнее..

Вебинар Создание эффективной инфраструктуры при помощи облачных решений

12.01.2021 04:18:24 | Автор: admin


19 января в 19:00 приглашаем на бесплатный вебинар Создание эффективной инфраструктуры при помощи облачных решений. На вебинаре расскажем об отличиях облачной инфраструктуры от традиционного подхода. Обсудим вопросы:


Как работают облака и какие проблемы они решают?
В чем разница между IaaS, PaaS и SaaS?
Как Netflix обслуживает десятки миллионов подписчиков по всему миру?
Global Presence: ваш ЦОД в любом уголке планеты.
Flexibiltity: от ста серверов до тысячи и обратно за несколько минут, адаптивно к нагрузке.
Модели оплаты Upfront/Pay as you go.


Спикер


Александр Волочнев, Developer Advocate в DataStax Inc.


Certified Professional Cloud Architect
Автор международных курсов для IT-специалистов
Более 8 лет опыта разработки и внедрения облачных решений
Спикер на многочисленных международных конференциях


Записаться на вебинар

Подробнее..

От появления ЭВМ до периферийных вычислений в телекоме

18.01.2021 22:06:54 | Автор: admin

Edge Computing введение в тему

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

Одним из результатов исторического развития стало появление Edge Computing. Что важно знать об Edge Computing? Это не четкое определение или конкретные механизмы, а концепция, при которой часть обработки данных, критичная к скорости, выполняется на узлах, вынесенных за пределы крупных ЦОДов и размещенных перед последней милей или в минимальном количестве прыжков от конечного устройства-потребителя или поставщика данных. В русскоязычной среде для обозначения Edge Computing распространены два обозначения граничные вычисления и периферийные вычисления.

Рассмотрим, как произошёл переход от огромных машинных залов до периферийных вычислений на смартфонах.

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

Задачей самых первых операционных систем (ОС), появившихся в 50-х годах (например, GM-HAA), была координация запуска пакетов программ и вывод полученных результатов. Более развитые ОС (такие как Unix, RSX, VMS) появились в 70-х и получили много дополнительных функций, в том числе связанных с межкомпьютерным взаимодействием. Если первым пользователям приходилось для работы использовать системы ввода/вывода расположенные непосредственно в центрах обработки данных (ЦОД), то с развитием коммуникационных систем в 60-х годах появилась возможность подключать пользовательские терминалы по выделенным и коммутируемым медным телефонным линиям, а в конце 70-х по волоконно-оптическим. В середине 60-х для организации линий связи стали доступны первые коммерческие спутниковые каналы.

Параллельно с развитием линий связи совершенствовались и протоколы передачи данных. После появления пакетных систем передачи данных канального уровня (в 70-х годах протокола Ethernet и подобных, в 80-х годах протоколов SLIP, Token ring, HDSL и т.д.), а затем в 80-х протоколов для пакетной связи на региональном и на глобальном уровне (сеть Internet на основе стека протоколов TCP/IP), пользователям для обработки и хранения данных стали с рабочего места доступны удаленные компьютерные центры.

С выпуском в 70-х годах первых микропроцессоров начали активно развиваться специализированные вычислительные устройства и персональные компьютеры. Они подключались к мощным ЦОД через глобальную сеть в качестве клиентских периферических устройств для доступа к вычислительным мощностям и хранилищам данных. Как правило рабочее место использовалось в качестве тонкого клиента (например, как терминал подсоединенный по протоколам Telnet, rlogin и т.д.) для запуска вычислительных задач на удаленном сервере или для получения данных по таким протоколам как FTP.

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

Первоначально наиболее распространенный в операционных системах способ организации хранения данных в виде файловых систем оказался не оптимальным для работы со сложными структурами характерными для бизнес-приложений, что привело к созданию в 50-х и 60-х годах специализированных языков программирования для работы с большим количеством разнотипных записей сравнительно небольшого объема (таких как язык Cobol, на котором написаны многие приложения используемые до сих пор), и к возникновению в 70-х годах концепции реляционных баз данных и языка SQL.

Другим способом доступа к серверным ресурсам стал появившийся в 80-х годах протокол RPC позволивший осуществлять удаленный запуск программ на сервере. На базе этого протокола в конце 80-х годов было разработано программное обеспечение первой массовой сетевой файловой системы NFS позволившей реализовать доступ к файлам и каталогам сервера как к локальным файлам и каталогам клиентского компьютера.

Развитие сетевых технологий

В 90-х годах произошел кардинальный скачок в количестве пользователей сети Интернет, объеме трафика, производительности рабочих станций и серверов, в развитии сетевых технологий и вычислительных систем обработки данных обусловленный целым набором факторов:

  1. Широкое внедрение высокоскоростных соединений на основе семейства протоколов xDSL.

  2. Развитие волоконно-оптических линий связи (ВОЛС).

  3. Стали более доступны спутниковые системы связи VSAT и дешевый комбинированный доступ.

  4. Появление протоколов распределенного поиска и передачи документов (gopher, http и т.д.).

  5. Появление первых поисковых систем - Archie (90), Wandex (93), Yahoo! (94), Google (96).

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

  7. Степень интеграции, параметры микропроцессоров и технология SMP позволили использовать микропроцессоры при проектировании серверного оборудования, а центральные процессоры (ЦП) рабочих станции приблизились по производительности к ЦП серверов.

  8. Появление пользовательских операционных систем для персональных компьютеров с интегрированным программным обеспечением для подключения к интернет-провайдерам, простой настройкой сервисов Интернет и предустановленными Web-браузерами (Windows 95).

  9. Появление свободнораспространяемого и юридически чистого программного обеспечения на основе юниксоподобных систем (386BSD, FreeBSD, NetBSD, OpenBSD, ОС на основе ядра Linux и т.д.) портированных для широкой номенклатуры серверного и другого оборудования.

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

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

Облачные технологии

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

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

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

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

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

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

  1. IaaS аренда соединенных в сеть виртуальных серверов.

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

  3. SaaS доступ к данным через специализированный интерфейс.

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

Edge Computing периферийные вычисления

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

Напомним, Edge Computing концепция обработки критичных к скорости данных ближе к месту их возникновения без передачи в центральные ЦОДы.

Предпосылки для развития периферийных вычислений:

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

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

  3. Стремление разделить данные и сегменты сети для повышения безопасности.

  4. Желание повысить надежность и автономность отдельных частей IT-системы.

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

  1. Снижения нагрузки на сети передачи данных.

  2. Уменьшения времени задержки при обработке.

  3. Выполнения нормативных требований и законодательства.

Применимость концепции следует именно из этих трех основополагающих элементов. Фактически, любые системы, работающие в реальном времени, могут требовать использования периферийных вычислений. Развитию рынка периферийных вычислений способствуют IoT (концепция интернет вещей - Internet of Things) и массовый переход на сети 5G первые обеспечивают кратный рост устройств, подключенных к сети, а вторые дают возможность передачи довольно больших объемов данных при росте количества подключенных устройств.

Оборудование для периферических вычислений

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

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

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

  2. Локальные ЦОДы или микроЦОДы 1-10 стоек, дают значительные возможности по обработке и хранению данных по сравнению с локальными устройствами.

  3. Региональные ЦОДы более 10 стоек.

2 и 3 пункт фактически может быть приравнен к CDN (Content Delivery Network) - Сеть доставки содержимого. Либо наоборот на базе чьего-то CDN можно строить инфраструктуру для периферийных вычислений.

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

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

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

Если говорить про микроЦОДы (MDC), то существуют готовые решения под ключ на несколько стоек, которые могут быть быстро развернуты в месте потребления и обработки данных. Есть варианты и мобильных контейнерных микроЦОДов которые могут быть развернуты в любом самом удаленном месте. Обычно микроЦОДы содержат серверное оборудование, ИБП (Источники Бесперебойного Питания) и системы вентиляции, кондиционирования, пожаротушения, мониторинга. Микро ЦОДы могут быть использованы для размещения активного оборудования провайдера. Бывают и обратные ситуации базовые станции сотовых операторов являются хорошим местом размещения периферийного оборудования и можно арендовать место в стойке на базовой станции под свой сервер. Тем более, что сотовый оператор уже решил проблемы энергоснабжения, охлаждения и сохранности оборудования. А получить связь лучше, чем на базовой станции оператора довольно сложно.

Архитектура

Наиболее распространены двух- и трёхзвенные варианты построения Edge-систем.

Двухзвенная граничное устройство и ЦОД/облако.Двухзвенная граничное устройство и ЦОД/облако.Трёхзвенная граничное устройство, туман (микроЦОДы, микрооблака, отдельные сервера), ЦОД/облако.Трёхзвенная граничное устройство, туман (микроЦОДы, микрооблака, отдельные сервера), ЦОД/облако.

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

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

Достоинства

С точки зрения бизнеса следование концепции даёт:

  1. Повышение эксплуатационной эффективности работы.

  2. Создание новых технологически ёмких услуг и продуктов.

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

  4. Улучшение обслуживания клиентов.

Примеров использования множество и окружают они нас повсеместно.

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

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

Как всё это работает? Возьмем несколько упрощенных примеров.

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

Аналогично с камерами для фиксации потока автомобильного трафика - фиксируются количество и скорость автомобилей на трассе. На локальном оборудовании транспортные средства распознаются и классифицируются на мототранспорт, легковые авто, грузовые разного тоннажа и длины. Агрегированные данные отправляются в ЦОД. При нарушении скоростного режима, производится дополнительно фото/видеофиксация нарушителя номер ТС (Транспортного средства), фото авто и водителя (если возможно). Эти дополнительные данные также отправляются в ЦОД для формирования штрафа. Так же как с камерами в метро можно дополнительно отслеживать авто по госномерам по базе загруженной на локальное устройство.

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

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

Что еще можно назвать из наиболее востребованных периферийных вычислений?

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

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

  • Умные дома.

  • Безопасный город.

  • Онлайн-игры.

  • Любые сети доставки контента, инфраструктурные проекты интернет-гигантов.

  • Виртуальная и дополненная реальность.

Еще в 2018 году аналитики McKinsey говорили в своём отчете New demand, new markets: What edge computing means for hardware companies о 100 вариантах использования в 11 наиболее перспективных отраслях. А сейчас 2020 год и рынок динамично развивается несмотря на пандемию и экономический кризис.

Законы

Про это надо сказать отдельно. Законы и локальные нормативные акты диктуют свои правила игры. Из-за этого надо хранить данные граждан России на территории России, данные граждан Евросоюза на территории Евросоюза. Таких ограничений достаточно и это вынуждает технологические компании дробить базы и выносить их в CDN в конкретном регионе Земли.

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

Практика

Рассмотрим работу концепции переферических вычислений на примере компании Форвард-Телеком, одним из главных направлений работы которой является автоматизация деятельности операторов связи и интернет-провайдеров. Программное обеспечение Forward во многом является потребителем информации, полученной с edge- и endpoint-устройств. Система Forward BSS/OSS, как комплексная платформа, предназначена для поддержки бизнеса клиента практически при любой существующей модели сети оператора. Платформа Forward имеет логичную модульную структуру, легко масштабируется, поддерживает облачную и гибридную модель развертывания, при этом система позволяет настроить разнообразные внешние интерфейсы для взаимодействия с элементами сети оператора и клиентами.

Система OSS отвечает за правильную работу сетевой инфраструктуры и оборудования, а система BSS за учет оказанных услуг, взаиморасчеты с абонентами, управление ресурсами и проектами (элементы подсистемы ERP), за отношения с абонентами и хранение дополнительных данных (элементы системы CRM).

Для небольших операторов доступ к возможностям Forward BSS/OSS может предоставляться как стандартизованная услуга облачного сервиса по модели SaaS, при этом сеть оператора и его клиенты взаимодействуют с системой в рамках концепции Edge Computing.

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

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

Характерной особенностью многих крупных операторов является наличие исторически сложившегося зоопарка информационных систем. Плохо совместимое программное обеспечение различных вендоров, внедрённое на разных этапах развития компании в каких-то региональных подразделениях или полученное при покупке местных операторов. Быстрая замена такого зоопарка часто не возможна или слишком накладна. Интеграция исторических информационных систем может быть быстрее и дешевле произведена через Forward BSS/OSS через API или специально написанные шлюзы.

Поток обращений по интеграции OSS/BSS систем с мобильными приложениями становится больше. Все операторы связи, банки, ритейлеры, сервисные компании, госорганы постепенно обзаводятся приложениями B2B, B2C или B2B2C класса для коммуникации со своими заказчиками. Самостоятельное управление абонентскими услугами через мобильное приложение подразумевает глубокую интеграцию в бизнес-процессы компании и всё больше приближает нашу работу по автоматизации к endpoint-устройствам конечных пользователей.

Сложности при использования концепции

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

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

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

  3. Информационная безопасность edge- и endpoint-устройств заслуживает отдельного упоминания. Удаленность от основных объектов инфраструктуры, отсутствие охраны может дать злоумышленнику возможность физического доступа к устройству и его компрометации.

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

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

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

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

Для разработчиков систем автоматизации, 7 пункт является наиболее важным. Именно он входит в сферу ответственности Форвард-Телеком перед заказчиком и разработчики стараются выполнять свою работу хорошо. О том, как идёт у Форвард-Телеком разработка биллинговых систем уже писалось на Хабре в статье Как там биллинг делается: когда заказчик и разработчик говорят на разных языках.

Уменьшение техпроцесса и широкое распространение энергоэффективных многоядерных вычислительных устройств будет способствовать дальнейшему перекладыванию обработки данных на локальные устройства и увеличению собираемой номенклатуры данных. Как минимум, можно ожидать, что будет необходимо готовить платформу Forward OSS/BSS к существенному расширению типов поступающей информации, обработке этих данных в реал-тайме с использованием Edge Computing инфраструктуры. Например, вполне вероятно, что в будущем данные какого-нибудь фитнес-браслета о кардио-ритме носителя могут быть использованы в банковской системе для скоринга рисков, оценки вероятности возврата задолженности и расчета процентной ставки по кредиту.

Так что Prepare yourselves because cyberpunk is coming

Подробнее..

Если у вас не работает Spring BootJar

28.12.2020 00:15:11 | Автор: admin

Проблема с загрузкой Spring Boot Jar


image


Сталкивались ли вы с проблемой запуска нового загрузочного архива Spring Boot?


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


Итак, проблем с BootJar на самом деле хватает. Особенно учитывая, что уже минимум три версии формата поменялось.


Здесь я расскажу о часто встречающемся случае с потерей ресурсов. Конкретнее в моём случае с потерей JSP шаблонов. Почему JSP? Мне так привычнее, проект я по-быстрому начал с них, и не думал, что будут такие проблемы.


Итак структура проекта (стандартный веб):


/src/main/    java/    resources/        static/            some.html        public/    webapp/        WEB-INF/jsp            index.jsp

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


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


Итак, дубль раз. Чуть ли не в первый раз запускаю задачу BootJar. Ярхив готов, деплоим Готово! Сигнала нет, сыпет ошибки 302 + 404 (это авторизация не находит вью). Но это пока не понятно.
Отключаем Секурити всё равно ничего не находит, кроме голимой статики, и то не всей, а только из webjars. ???


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


Хм, странно. Запускаем BootJar локально всё работает. Чудеса.


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


Что и делам. Выясняется ресурсы BootJar запакованные не из библиотек (webjars), а из проекта, не включаются в перечисление, и это, оказывается, по дизайну! Подробности здесь.


Вернее не так есть спец-ресурсы в каталогах типа static/, public/. И они вроде находятся, если объявить. Но jsp не видит в упор хоть тресни. И дело не в том, что не там лежат. Оказалось, что Томкат (в нашем плохом случае), грузит jsp особым механизмом после редиректа. И сами jsp можно загрузить без рендеринга, если правильно задать их положение в настройках
spring.resources.static-locations


Но это нас не устраивает.
Оказалось, что при использования встроенного томката, ресурсы вью он грузит отдельно и в первую очередь своей старой встроенной логикой, которую Спрингисты настраивать не научились. А этой логике нужен либо архив Вар, либо он же распакованный (почему кстати при разработке нормально отрабатывает расположение webapp/), либо ресурсы из библиотек, которые прекрасно видны, если правильно упакованы в изначальных либах нужно чтоб лежали в META-INF/resources, как в стандарте сервлетов. Последнее работает даже внутри BootJar. Удивительно.


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


Почему не работает способ с Вар-архивом? Ё-маё, Амазон решил, что лучше меня знает, что я буду грузить именно в яр-формате, хотя интерфейс заявлет о готовности съесть варник. Он этот варник переименовывает в ярник, умник такой. А Томкат не умничает, он смотрит расширение: не Вар ну тогда, извините, это не мой случай.


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


Ладно, проблема понятна. Решение?


Было три варианта.


  1. Сделать свой spring-загрузчик ресурсов. Вариант отпал, поскольку, как я уже сказал, Томкат отрабатывает jsp до их запуска.
  2. Прокинуть загрузку в Томкат. Стал прикидывать: надо расширить контекст spring-а, прокинуть пути в контекст Томката, там ещё раза два переложить непонятно, насколько сложно, и можно ли без изменения самого томката. Спрингисты не осилили, и я не хочу.
  3. Вариант попроще пакуем ресурсы в ресурсную либу в BootJar.

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


sourceSets {    jsp {        resources.source(sourceSets.main.resources);        resources.srcDirs += ['src/main/webapp'];    }    jmh {        .. ..    }}

Сама задача


task jsp(type: Jar, description: 'JSP Packaging') {    archiveBaseName = 'jsp'    group = "build"    def art = sourceSets.jsp.output    from(art) {        exclude('META-INF')        into('META-INF/resources/')    }    from(art) {        include('META-INF/*')        into('/')    }    dependsOn(processJspResources)}

Задача processJspResources уже создана, её не надо делать. Ставим всё в зависимость и пакуем:


bootJar {    dependsOn(jsp)    bootInf.with {        from(jsp.archiveFile) {            include('**/*.jar')        }        into('lib/')    }}

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


artifacts {    jspImplementation jsp}

Всё, теперь имеем ресурсную либу, которую по всем стандартам томкат должен грузить, и он грузит. Запускаем, как BootJar.

Подробнее..

Пишем мессенджер на Vue в облаке Amazon

16.01.2021 20:09:22 | Автор: admin

Разберем, как использовать облачный сервис Amazon для созданиямессенджера Chattyмногопользовательского чат-приложения в реальном времени с одной комнатой с помощью фреймворка Vue иAWS Amplify. Настроим регистрацию пользователей и хранение данных.

Темы, которые мы рассмотрим:

  • Аутентификация

  • GraphQL API с AWS AppSync

  • Настроить Amplify DataStore

  • Развертывание через консоль Amplify

  • Удаление сервисов

  • Приложение и устранение неисправностей

Результат можно увидеть тут: https://master.d58xs5f4j0v44.amplifyapp.com/

Предварительные условия:

  • Регистрация за $1 в сервисах Amazon AWS уже произведена

  • Бесплатный редактор Visual Studio Code установлен, локализован и установлен npm:

    • Node:14.7.0. VisitNode

    • npm:6.14.7.

npm install -g npm

Начало работы - Создание приложения

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

npm install -g @vue/clivue create amplify-datastore
  • ?Выберитепредустановку: поумолчанию [Vue 2] (babel, eslint)

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

cd amplify-datastore npm run serve

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

Откроем папку проекта C:\Users\Admin\amplify-datastore> в редакторе Visual Studio Code:

Обратите внимание на окончание строк LFОбратите внимание на окончание строк LF

Мы видим шаблон приложения Vue, и оно работает локально.

Остановим его CTRL+C что бы продолжить.

Давайте теперь установим API AWS Amplify и библиотеку AWS Amplify Vue:

npm install --save aws-amplify @aws-amplify/ui-vue moment

Установка интерфейса командной строки AWS Amplify

Далее мы установим интерфейс командной строки AWS Amplify:

npm install -g @aws-amplify/cli

Теперь нам нужно настроить CLI с нашими учетными данными:

amplify configure

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

Здесь мы рассмотримamplify configureнастройку.После входа в консоль AWS продолжайте:

  • Укажите регион AWS:eu-central-1 (Франкфурт)

  • Укажите имя пользователя нового пользователя IAM:ampify-datastore

В консоли AWS нажмитеДалее: Разрешения,Далее: Теги,Далее: ОбзориСоздать пользователя,чтобы создать нового пользователя IAM.Затем вернитесь в командную строку и нажмите Enter.

  • Введите ключ доступа вновь созданного пользователя:

    accessKeyId:(<YOURACCESSKEYID>)secretAccessKey:(<YOURSECRETACCESSKEY>)

  • Имя профиля: поумолчанию

Чтобы просмотреть нового созданного пользователя IAM, перейдите на панель управления по адресуhttps://console.aws.amazon.com/iam/home?region=eu-central-1#/users.Также убедитесь, что ваш регион соответствует вашему выбору.

Инициализация нового проекта

amplify init
  • Введите название проекта:ampifydatastore

  • Введите имя для среды:dev

  • Выберите редактор по умолчанию:Visual Studio Code

  • Выберите тип приложения, которое вы создаетеjavascript

  • Какую среду JavaScript вы используетеvue

  • Путь к исходному каталогу:src

  • Путь ккаталогураспространения:dist

  • Команда сборки:npm run-script build

  • Команда запуска:npm run-script serve

  • Вы хотите использовать профиль AWS? да

  • Пожалуйста, выберите профиль, который вы хотите использовать по умолчанию

Теперь интерфейс командной строки AWS Amplify инициировал новый проект, и вы увидите новую папку:ampify.Файлы в этой папке содержат конфигурацию вашего проекта.

<amplify-app>    |_ amplify      |_ .config      |_ #current-cloud-backend      |_ backend      team-provider-info.json

Добавление аутентификации

Чтобы добавить аутентификацию в наш проект Amplify, используем следующую команду:

amplify add auth

При появлении запроса выберите

  • Вы хотите использовать конфигурацию аутентификации и безопасности поумолчанию?:Конфигурация по умолчанию

  • Как вы хотите, чтобы пользователи могли входить в систему при использовании вашего пула пользователей Cognito ?:Имя пользователя

  • Вы хотите настроить дополнительные параметры?Да, я хочу внести дополнительные изменения.

  • Какие атрибуты необходимы для регистрации?(Нажмите <пробел>, чтобы выбрать, <a>, чтобы переключить все, <i>, чтобы инвертировать выделение):Электронная почта

  • Вы хотите включить какие-либо из следующих возможностей?(Нажмите <пробел>, чтобы выбрать, <a>, чтобы переключить все, <i>, чтобы инвертировать выделение):Нет

Чтобы ничего не выбрать, просто нажмитеEnterпоследнюю опцию.

Теперь мы запустим команду push, и облачные ресурсы будут созданы в нашей учетной записи AWS.

amplify push Current Environment: dev| Category | Resource name      | Operation | Provider plugin   || -------- | ------------------ | --------- | ----------------- || Auth     | amplifyappuuid     | Create    | awscloudformation |? Are you sure you want to continue? Yes

Чтобы быстро проверить созданныйпул пользователей Cognito,запустим:

amplify status

Чтобы получить доступ кконсоли AWS Cognitoв любое время, перейдите на панель управления по адресуhttps://console.aws.amazon.com/cognito/.

Настраиваем приложение Vue

Теперь наши ресурсы созданы, и мы можем начать их использовать!

Первое, что нам нужно сделать, это настроить наше приложение Vue, чтобы оно было осведомлено о нашем новом проекте AWS Amplify.Мы можем сделать это, обратившись к автоматически сгенерированномуaws-exports.jsфайлу, который теперь находится в srcпапке.

Чтобы настроить приложение, откройтеmain.jsи добавьте следующий код:

import Vue from 'vue'import App from './App.vue'import Amplify from 'aws-amplify';import '@aws-amplify/ui-vue';import aws_exports from './aws-exports';Amplify.configure(aws_exports);Vue.config.productionTip = falsenew Vue({  render: h => h(App),}).$mount('#app')

Теперь наше приложение готово к использованию сервисов AWS.

Использование компонента аутентификации

AWS Amplify предоставляет компоненты пользовательского интерфейса, которые можно использовать в своем приложении.Добавим эти компоненты в проект

Чтобы использовать компонент Authenticator, добавьте его вsrc / App.vue:

<template>  <div id="app">    <amplify-authenticator>      <div>        <h1>Hey, {{user.username}}!</h1>        <amplify-sign-out></amplify-sign-out>      </div>    </amplify-authenticator>  </div></template>

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

Чтобы просмотреть всех созданных пользователей, вернитесь напанель управленияCognito поадресуhttps://console.aws.amazon.com/cognito/.

В качестве альтернативы мы также можем использовать

amplify console auth

Доступ к данным пользователя

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

<script>import { AuthState, onAuthUIStateChange } from '@aws-amplify/ui-components'export default {  name: 'app',  data() {    return {      user: { },    }  },  created() {    // authentication state managament    onAuthUIStateChange((state, user) => {      // set current user and load data after login      if (state === AuthState.SignedIn) {        this.user = user;      }    })  }}</script>

Добавление GraphQL API

Чтобы добавить GraphQL API, мы можем использовать следующую команду:

amplify add api

Ответьте на следующие вопросы

  • Пожалуйста, выберите одну из нижеуказанных службGraphQL

  • Укажите имя API:ChattyAPI

  • Выберите тип авторизации по умолчанию дляключаAPIAPI

  • Введите описание ключа API:(пусто)

  • Через сколько дней истечет срок действия ключа API (1-365):7

  • Вы хотите настроить дополнительные параметры для GraphQL API?Да, я хочу внести дополнительные изменения.

  • Настроить дополнительные типы авторизации?N

  • Настроить обнаружение конфликтов?Y

  • Выберите стратегию разрешения по умолчаниюAuto Merge

  • Вы хотите изменить настройки по умолчанию для каждой модели? N

  • У вас есть аннотированная схема GraphQL? N

  • Вам нужно управляемое создание схемы? Y

  • Что лучше всего описывает ваш проект: один объект с полями (например, Todo с идентификатором, именем, описанием)

  • Вы хотите отредактировать схему сейчас? Y

Чтобы ничего не выбрать, просто нажмитеEnter.

При появлении запроса обновите схему до следующего:

type Chatty @model {  id: ID!  user: String!  message: String!  createdAt: AWSDateTime}

Это позволит нам отображать сообщения каждого пользователя вместе с датой и временем создания.

Примечание: не забудьте сохранить изменения в файле схемы!

Затем давайте перенесем конфигурацию в нашу учетную запись:

amplify push
  • Вы уверены что хотите продолжить?да

  • Вы хотите сгенерировать код для недавно созданного GraphQL API?Да

  • Выберите целевой язык генерации кодаjavascript

  • Введите шаблон имени файла для запросов, мутаций и подписокgraphql src / graphql / ** / *. Js

  • Вы хотите сгенерировать / обновить все возможные операции GraphQL - запросы, изменения и подписки?Да

  • Введите максимальную глубину инструкции [увеличьте значение по умолчанию, если ваша схема глубоко вложена]2

Обратите внимание наконечную точку GraphQLиКЛЮЧ API.

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

amplify console api
  • Пожалуйста, выберите одну из нижеуказанных службGraphQL

Настроить Amplify DataStore

Установка Amplify DataStore

Далее мы установим необходимые зависимости:

npm install --save @aws-amplify/core @aws-amplify/datastore

Генерация модели данных

Затем мы сгенерируем модели для доступа к нашим сообщениям из нашегоChattyAPI.

amplify codegen models

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

Теперь интерфейс командной строки AWS Amplify сгенерировал необходимые модели данных, и вы увидите новую папку в своем источнике:models.Файлы в этой папке содержат классы и схему вашей модели данных.

<amplify-app>    |_ src      |_ models

Самые нетерпеливые могут заглянуть в репозиторий проекта https://github.com/lazy-fox-code/amplify-datastore и уточнить куда какой код добавлять. Основная логика приложения описывается в App.vue и следующие разделы будут разбирать именно этот файл.

Структура App.vue содержит шаблон <template> в котором присутствуют блоки <divid="app"> с формами, кнопками, авторизацией и прочими деталями приложения. Затем идет раздел <script> в котором импортируются и применяются модели и методы приложения. Затем следуют стили оформления приложения.

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

Теперь, когда GraphQL API и модели данных созданы, мы можем начать с ними взаимодействовать!

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

import { DataStore } from "@aws-amplify/datastore";import { Chatty } from "./models";await DataStore.save(new Chatty({  user: "amplify-user",  message: "Hi everyone!",  createdAt: new Date().toISOString()}))

Это создаст запись локально в вашем браузере и синхронизирует ее в фоновом режиме с помощью базового API GraphQL.

Запрос данных

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

import { DataStore, Predicates } from "@aws-amplify/datastore";import { Chatty } from "./models";const messages = await DataStore.query(Chatty, Predicates.ALL);

Это вернет массив сообщений, которые мы можем отобразить в нашем пользовательском интерфейсе.

Предикаты также поддерживают фильтры для распространенных типов, таких как строки, числа и списки.

Найдите все поддерживаемые фильтры вразделе "Запрос с предикатами"

Создание UI

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

<template>  <div v-for="message of sorted" :key="message.id">    <div>{{ message.user }} - {{ moment(message.createdAt).format('YYYY-MM-DD HH:mm:ss')}})</div>    <div>{{ message.message }}</div>  </div></template><script>import { Auth } from "aws-amplify";import { DataStore, Predicates } from "@aws-amplify/datastore";import { Chatty } from "./models";import moment from "moment";export default {  name: 'app',  data() {    return {      user: {},      messages: [],    }  },  computed: {    sorted() {      return [...this.messages].sort((a, b) => -a.createdAt.localeCompare(b.createdAt));    }  },  created() {    this.currentUser();  },  methods: {    moment: () => moment(),    currentUser() {      Auth.currentAuthenticatedUser().then(user => {        this.user = user;        this.loadMessages();      });    },    loadMessages() {      DataStore.query(Chatty, Predicates.ALL).then(messages => {        this.messages = messages;      });    },  }}</script>

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

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

<template>  <form v-on:submit.prevent>    <input v-model="form.message" placeholder="Enter your message..." />    <button @click="sendMessage">Send</button>  </form></template><script>export default {  data() {    return {      form: {},    };  },   methods: {    sendMessage() {      const { message } = this.form      if (!message) return;      DataStore.save(new Chatty({        user: this.user.username,        message: message,        createdAt: new Date().toISOString()      })).then(() => {        this.form = { message: '' };        this.loadMessages();      }).catch(e => {        console.log('error creating message...', e);      });    },  }}</script>

Удаление всех сообщений

Одним из основных преимуществ работы с Amplify DataStore является возможность запускать пакетные мутации без использования серии отдельных операций.

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

DataStore.delete(Chatty, Predicates.ALL).then(() => {  console.log('messages deleted!');});

Подписки GraphQL

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

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

Когда компонент будет уничтожен, мы откажемся от подписки, чтобы избежать утечки памяти.

<script>export default {  data() {    return {      subscription: undefined;    };  },  created() {    //Subscribe to changes    this.subscription = DataStore.observe(Chatty).subscribe(msg => {      console.log(msg.model, msg.opType, msg.element);      this.loadMessages();    });  },   destroyed() {    if (!this.subscription) return;    this.subscription.unsubscribe();  },}</script>

Развертывание через консоль Amplify

Мы рассмотрели развертывание через категорию хостинга Amplify CLI, но что, если нам нужно непрерывное развертывание CI/CD?Для этого мы можем использоватьконсоль Amplifyдля развертывания приложения.

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

git initgit remote add origin git@github.com:username/project-name.gitgit add .git commit -m 'initial commit'git push origin master

Затем мы посетим консоль Amplify в нашей учетной записи AWS по адресуhttps://eu-central-1.console.aws.amazon.com/amplify/home.

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

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

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

Наконец, мы можем нажать Сохранить иразвернуть, чтобы развернуть наше приложение!

Теперь мы можем отправлять обновления в Master, чтобы обновить наше приложение.

Удаление сервисов

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

amplify remove authamplify push

Если вы не знаете, какие службы вы в любой момент включили, вы можете запуститьamplify statusкоманду:

amplify status

amplify statusпредоставит вам список ресурсов, которые в настоящее время включены в вашем приложении.

Приложение

Настройка учетной записи AWS

Чтобы пройти этот урок, необходимо создать и активировать учетную запись Amazon Web Services.

Следуйте инструкциямздесь

Устранение неполадок

Сообщение: для идентификатора ключа доступа AWS требуется подписка на сервис

Решение: убедитесь, что вы подписаны на бесплатный план.Подписывайся

Сообщение: TypeError: fsevents не является конструктором

Решение:npm audit fix --force

Поведение: данные не синхронизируются с облаком и / или наоборот

Решение:

amplify update apiamplify push

Убедитесь, что вы ответили на следующие вопросы как

  • Настроить обнаружение конфликтов?Y

  • Выберите стратегию разрешения по умолчаниюAuto Merge

  • Вы хотите изменить настройки по умолчанию для каждой модели?N

Послесловие

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

Результат работы двух пользователейРезультат работы двух пользователей

Что дальше?

Конечно у разработчика возникнет ряд вопросов по эффективности использования приложения в среде Amplify. Вот некоторые из них:

5 шагов администрирования приложения5 шагов администрирования приложения

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

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

Подробнее..

Одно неловкое движение, и сразу целый вал ненужных рекомендаций за что критикуют видеохостинги

10.01.2021 14:07:00 | Автор: admin

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

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

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

Фотография: Kevin Grieve. Источник: Unsplash.comФотография: Kevin Grieve. Источник: Unsplash.com

Метрики вместо развития

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

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

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

Фотография: Christopher Ott. Источник: Unsplash.comФотография: Christopher Ott. Источник: Unsplash.com

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

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

Слабые рекомендации

Сегодня все чаще можно встретить критику алгоритмов YouTube. Вот так на эту тему высказываются на Hacker News: Болею, целую неделю сижу дома. Фактически обновляю главную каждые пятнадцать минут, но видео, которые я пропускаю уже сотый раз, остаются на месте. Снова и снова нужно скроллить, чтобы найти что-то другое. Базовая рекомендация в таких ситуациях самостоятельно редактировать, чистить или замораживать историю просмотров. Если избавиться от пары записей с роликами об условных теориях заговора, алгоритм пессимизирует это тематическое направление и не будет рекомендовать подобный контент. Более радикальный подход режим приватного просмотра [инкогнито или private browsing], если возникает спонтанное желание провалиться в черную дыру с кучей сомнительных сюжетов. Так можно будет и не тратить время на чистку watch history.

Резиденты HN отмечают и другие особенности рекомендательного движка этой площадки: Помню, как в далеком 2009-м искал электронную музыку и в related к трекам с условной тысячью просмотров были аналогичные по популярности композиции. Их мало кто слушал, поэтому и я всего за несколько часов открыл для себя кучу новых исполнителей. Сегодня все иначе алгоритм выдает похожие видео, но это почти всегда стотысячники.

Фотография: Glenn Carstens-Peters. Источник: Unsplash.comФотография: Glenn Carstens-Peters. Источник: Unsplash.com

Стоит признать, что встречаются и мнения в защиту YouTube, хотя по большей части ключевую роль в примерах играют не алгоритмы, а пользовательский опыт: На моем ноуте слушал музыку чуть ли не весь дом, но ситуацию спас хороший вкус окружающих теперь сервис радует меня шикарными рекомендациями. Они круче, чем у Spotify. На HN говорят и о других видеохостингах вроде Netflix, но даже в случае этой стриминговой площадки пользователи сожалеют о низком качестве действующих алгоритмов фильтрации контента по сравнению с временами, когда компания работала с DVD-дисками и предлагала качественные рекомендации.

Отсутствие точечных настроек

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

Еще один лайфхак пригодится тем, кто не успевает изучать ролики, отложенные для последующего просмотра. Часть из них рано или поздно пропадают с площадки либо за нарушения правил, либо по желанию авторов, решивших обновить канал. В таком случае стоит заранее воспользоваться youtube-dl одним из наиболее популярных менеджеров загрузок [более 87 тыс. звезд на GitHub на момент публикации]. Либо выбрать более доступный вариант закинуть ссылку на видео в Wayback Machine. Однако в этом случае гарантированной архивации ждать не стоит снэпшот могут и не сделать по единственному запросу [хотя общее число захватываемых сервисом роликов еще в 2018-м оно доходило до 800 тыс. в неделю].

Фотография: Dodi Achmad. Источник: Unsplash.comФотография: Dodi Achmad. Источник: Unsplash.com

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

Что будет происходить дальше

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

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


Подробнее..

Почему JVM это ОС и больше чем Кубер

05.01.2021 08:15:09 | Автор: admin

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

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

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

Итак, какие признаки ОС мы имеем у JVM? Управление памятью - несомненно. Управление потоками - да, но как правило на базе существующих местных потоков базовой ОС. Тем не менее, потоки являются важной неотъемлемой и очень развитой подсистемой машины, предоставляя гораздо больше сервисных средств, чем базовые потоки ОС.

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

У Ява есть философия. Если в Юникс - всё файл, то в Ява всё (почти) есть объект.

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

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

Во-первых, JVM управляемая (managed) среда. Это не только означает безопасность исполнения кода. Это также модель разграничения, аналогичная выделению ядра в большинстве ОС в отдельный контекст привилегированного исполнения. Т.н. нативный контекст исполнения, в котором работает сама машина - прямой аналог реального (или подобного) режима исполнения процессором ядра ОС. Сама машина имеет полный контроль над всеми процессами внутри неё. Байткоду достается уже сильно ограниченная, защищённая среда. Степень свободы загружаемого байткода определяется Ява-машиной и её рантайм-библиотекой. Более того, сам механизм загрузки байткода (классов в первую очередь) иерархичен и подразумевает разделение прав и ответственности ветвление прав. Это ветвление достигается за счёт применения отдельных загрузчиков классов. При этом создаётся иерархия областей видимости, код, загруженный в одном контексте не имеет доступа к другому независимому контексту. При этом нельзя получить указатель на произвольную область памяти, нет доступа к произвольным полям объектов, даже через механизм рефлексии, даже к целым отдельным объектам. Этот механизм встроен в язык (ключевые слова private, protected и т.п.) и в платформу уже названные загрузчики и конечно менеджеры безопасности, о которых тоже не забудем. Такие механизмы обеспечивают разделение контекстов выполнения аналогично процессам классических ОС. Я бы даже сказал более строгое и надёжное разделение.

Загрузчики классов совместно с менеджерами безопасности (SecurityManager) обеспечивают полный контроль над тем, что может попасть внутрь среды исполнения Ява, а что не может. Механизм этот необычайно гибкий. При этом, в отличие от нативного кода, загружаемый байткод проходит полную проверку на валидность (он не может затем вызвать непредсказуемый сбой) и безопасность - так как возможные варианты поведения ограничены теми же загрузчиком+менеджером безопасности. Вы слышали когда-нибудь о вирусах на Яве?

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

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

Круче чем докер

Почему Ява-машина круче чем докер? Потому что, как я уже сказал, она позволяет создавать множество независимых изолированных контекстов читай пространств имён на базе общего ядра Ява-машины и рантайм-библиотеки. И эти пространства могут настраиваться более гибко, обеспечивая различные уровни изоляции (доступа). Они могут дополнительно компоноваться. Отличным примером этого являются мощные сервера приложений. Они предлагают всё то, что обещает нам докер и его оркестраторы отказоустойчивость, балансировка нагрузки, отличная модульность (суть микросервисности), сервисы и вебсервисы и даже самые микро и нано-модули лямбды в виде супер легковесных ejb, решение проблем совместимости версий библиотек, удалённый вызов процедур в качестве альтернативы protoBuf & gRPC RMI и его развития Corba + rmi-iiop. И это всё в виде стандартов и множества реализаций

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

И для иллюстрации посмотрим на стандартную модульность сервера приложений. Есть иерархия загрузки: система -> сервер -> приложение -> модуль приложения.

Что ж, на этом пока всё. Порадуемся выходу очередной версии Jakarta EE 9 и пожелаем им успехов.

Подробнее..

Перевод Как сократить время сборки образов Docker в GitLab CI

18.01.2021 02:05:59 | Автор: admin

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

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

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

Локальная упаковка приложения

В качестве примера мы возьмем достаточно простое приложение Python Flask:

from flask import Flaskapp = Flask(__name__)@app.route('/')def hello_world():    return 'Hello, World!'

Написание Dockerfile

Давайте напишем соответствующий Dockerfile:

FROM python:3.7-alpine as builder# установка зависимостей, необходимых для сборки пакетов pythonRUN apk update && apk add --no-cache make gcc && pip install --upgrade pip# настройка venv и загрузка или сборка зависимостейENV VENV="/venv"ENV PATH="${VENV}/bin:${PATH}"COPY requirements.txt .RUN python -m venv ${VENV} \    && pip install --no-cache-dir -r requirements.txtFROM python:3.7-alpine# настройки venv с зависимостями с этапа компоновкиENV VENV="/venv"ENV PATH="${VENV}/bin:$PATH"COPY --from=builder ${VENV} ${VENV}# копирование файлов приложенияWORKDIR /appCOPY app .# запуск приложенияEXPOSE 5000ENV FLASK_APP="hello.py"CMD [ "flask", "run", "--host=0.0.0.0" ]

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

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

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

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

Запуск и тестирование образа.

Убедитесь, что все работает должным образом:

docker build -t hello .docker run -d --rm -p 5000:5000 hellocurl localhost:5000Hello, World!

Если вы запустите команду docker build во второй раз:

docker build -t hello ....Step 2/15 : RUN apk update && apk add --no-cache make gcc && pip install --upgrade pip ---> Using cache ---> 24d044c28dce...

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

Отправка образа

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

docker tag hello my-registry/hello:1.0docker push my-registry/hello:1.0The push refers to repository [my-registry/hello]8388d558f57d: Pushed 77a59788172c: Pushed 673c6888b7ef: Pushed fdb8581dab88: Pushed6360407af3e7: Pushed68aa0de28940: Pushedf04cc38c0ac2: Pushedace0eda3e3be: Pushedlatest: digest: sha256:d815c1694083ffa8cc379f5a52ea69e435290c9d1ae629969e82d705b7f5ea95 size: 1994

Обратите внимание, как каждый из промежуточных слоев идентифицируется хэшем. Мы можем насчитать 8 слоев, потому что у нас есть ровно 8 docker команд в Dockerfile поверх нашей последней инструкции FROM.

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

С локальной сборкой все достаточно просто, давайте теперь посмотрим, как это будет работать в CI среде.

Сборка образа Docker в контексте CI конвейера

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

Тестовая CI среда

Мы реализуем CI среду, используя:

Последний пункт важен, потому что наши CI задачи будут выполняться в контейнерной среде. Учитывая это, каждая задача создается в виде пода Kubernetes. Каждое современное CI решение использует контейнерные задачи, и при создании Docker контейнеров все они сталкиваются с одной и той же проблемой: вам нужно заставить Docker команды работать внутри Docker контейнера.

Чтобы все прошло гладко, у вас есть два пути:

  • Забиндить /var/run/docker.sock, который слушает демон Docker, сделав демон хоста доступным для нашего контейнера задач.

  • Использовать дополнительный контейнер, запускающий Docker in Docker (также известный как dind) вместе с вашей задачей. Dind - это особый вариант Docker, работающий с привилегиями и настроенный для работы внутри самого Docker ?

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

Реализация GitLab конвейера

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

В приведенном ниже фрагменте конвейера и задача docker-build, и служебный dind контейнер будут выполняться в одном и том же поде Kubernetes. Когда в сценарии задачи используется docker, он отправляет команды вспомогательному dind контейнеру благодаря переменной среды DOCKER_HOST.

stages:  - build  - test  - deployvariables:  # отключаем проверку Docker TLS  DOCKER_TLS_CERTDIR: ""  # адрес localhost используется как контейнером задачи, так и dind контейнером (поскольку они используют один и тот же под)  # Таким образом, при выполнении команд Docker эта конфигурация делает службу dind нашим демоном Docker   DOCKER_HOST: "tcp://localhost:2375"services:  - docker:stable-dinddocker-build:  image: docker:stable  stage: build  script:      - docker build -t hello .      - docker tag my-registry/hello:${CI_COMMIT_SHORT_SHA}      - docker push my-registry/hello:${CI_COMMIT_SHORT_SHA}

Запуск конвейера

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

docker build -t hello .Step 1/15 : FROM python:3.7-alpine as builder...Step 2/15 : RUN apk update && apk add --no-cache make gcc && pip install --upgrade pip---> Running in ca50f59a21f8fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz...

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

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

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

Как же нам получить выгоду от кэширования и по-прежнему использовать Dind-контейнер?

Использование кэша Docker вместе с Docker in Docker

Первое решение: Pull/Push танцы

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

Если быть точнее:

  • Мы начинаем с извлечения (pull) самого актуального образа (т. е. последнего) из удаленного реестра, который будет использоваться в качестве кэша для последующей docker команды сборки.

  • Затем мы создаем образ, используя извлеченный образ в качестве кэша (аргумент --cache-from), если он доступен. Мы помечаем эту новую сборку в качестве последней и коммитим SHA.

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

stages:  - build  - test  - deploy    variables:   # отключаем проверку Docker TLS  DOCKER_TLS_CERTDIR: ""  DOCKER_HOST: "tcp://localhost:2375"services:  - docker:stable-dinddocker-build:  image: docker:stable  stage: build  script:    - docker pull my-registry/hello:latest || true    - docker build --cache-from my-registry/hello:latest -t hello:latest .    - docker tag hello:latest my-registry/hello:${CI_COMMIT_SHORT_SHA}    - docker tag hello:latest my-registry/hello:latest    - docker push my-registry/hello:${CI_COMMIT_SHORT_SHA}    - docker push my-registry/hello:latest

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

Все слои из базового образа компоновщика пересобираются. Только первые 2 слоя (8 и 9) заключительного этапа используют кэш, но последующие слои перестраиваются.

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

Затем, когда наш финальный образ собран (шаги с 8 по 15), первые два слоя присутствуют в образе, который мы извлекли и использовали в качестве кэша. Но на шаге 10 мы получаем зависимости образа компоновщика, которые изменились, поэтому все последующие шаги также строятся заново.

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

stages:  - build  - test  - deploy    variables:    # отключаем проверку Docker TLS  DOCKER_TLS_CERTDIR: ""  DOCKER_HOST: "tcp://localhost:2375"services:  - docker:stable-dinddocker-build:  image: docker:stable  stage: build  script:    - docker pull my-registry/hello-builder:latest || true    - docker pull my-registry/hello:latest || true    - docker build --cache-from my-registry/hello-builder:latest --target builder -t hello-builder:latest .    - docker build --cache-from my-registry/hello:latest --cache-from my-registry/hello-builder:latest -t hello:latest .    - docker tag hello-builder:latest my-registry/hello-builder:latest        - docker tag hello:latest my-registry/hello:${CI_COMMIT_SHORT_SHA}    - docker tag hello:latest my-registry/hello:latest    - docker push my-registry/hello-builder:latest    - docker push my-registry/hello:${CI_COMMIT_SHORT_SHA}    - docker push my-registry/hello:latest

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

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

Второе решение: внешняя служба dind

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

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

Создать такую службу в Kubernetes достаточно просто:

apiVersion: v1kind: PersistentVolumeClaimmetadata:  labels:    app: docker-dind  name: dindspec:  accessModes:    - ReadWriteOnce  resources:    requests:      storage: 500Gi---apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: docker-dind  name: dindspec:  replicas: 1  selector:    matchLabels:      app: docker-dind  template:    metadata:      labels:        app: docker-dind    spec:      containers:        - image: docker:19.03-dind          name: docker-dind          env:            - name: DOCKER_HOST              value: tcp://0.0.0.0:2375            - name: DOCKER_TLS_CERTDIR              value: ""          volumeMounts:            - name: dind-data              mountPath: /var/lib/docker/          ports:            - name: daemon-port              containerPort: 2375              protocol: TCP          securityContext:            privileged: true # Требуется для работы dind контейнера.      volumes:        - name: dind-data          persistentVolumeClaim:            claimName: dind            ---apiVersion: v1kind: Servicemetadata:  labels:    app: docker-dind  name: dindspec:  ports:    - port: 2375      protocol: TCP      targetPort: 2375  selector:    app: docker-dind

Затем мы немного изменим наш исходный GitLab конвейер, чтобы он указывал на эту новую внешнюю службу, и удалим встроенные dind службы:

stages:  - build  - test  - deploy    variables:   # отключаем проверку Docker TLS  DOCKER_TLS_CERTDIR: ""   # здесь имя хоста dind разрешается как dind служба Kubernetes с помощью kube dns  DOCKER_HOST: "tcp://dind:2375"docker-build:  image: docker:stable  stage: build  script:    - docker build -t hello .    - docker tag hello:latest my-registry/hello:{CI_COMMIT_SHORT_SHA}    - docker push my-registry/hello:{CI_COMMIT_SHORT_SHA}

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

И последний вариант: использование Kaniko

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

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

Заключение

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


А прямо сейчас приглашаем ва ознакомиться с программой супер-интенсива"CI/CD или Непрерывная поставка с Docker и Kubernetes", а таже записаться надень открытых дверей.


Подробнее..

Выбираем self-hosted замену IFTTT

08.01.2021 14:08:13 | Автор: admin


If This Then That сервис для автоматизации задач и создания пайплайнов из действий в разных сервисах. Это самый известный и функциональный продукт на рынке, но популярность ему навредила: полноценное создание апплетов теперь возможно только с платной подпиской, а на реддите периодически появляются жалобы на нестабильную работу сервиса. Как и в случае с любым полезным но платным продуктом, ищущий альтернативы обрящет их в опен-сорсном комьюнити. Мы сравним три self-hosted инструмента: Huginn, Beehive и Node-RED, попробуем их в действии и выберем лучший по функционалу и удобству использования.

Huginn




Huginn один из старейших сервисов автоматизации рутинных задач, первая версия была выпущена весной 2013 года. В скандинавской мифологии Хугин и Мунин вороны Одина, приносящие ему новости обо всё происходящем в мире, здесь же это менеджер агентов, выполняющих небольшие задания по заданным триггерам. Агентов можно объединять в цепочки и вообще организовывать в структуры произвольной сложности. Hugginn даже иногда используют целые компании для автоматизации процессов (пример>). Агенты могут:

  • Мониторить любой сайт и реагировать когда появляется определенная информация. Базовый пример агент утром проверяет прогноз погоды и присылает уведомление, если днём будет дождь
  • Следить за темами в твиттере и обращать внимание на пик упоминаний, например во время горячего обсуждения
  • Следить за понижением цен на товары/билеты/подписки/etc
  • Отслеживать упоминания как Google Alerts
  • Отслеживать изменения целых сайтов или их частей. Подойдёт для тех кейсов веб-скрапинга, которые не покрывается вариантами выше. Например повесить алёрт на изменение страницы с пользовательским соглашением или продукт, переходящий из беты в релиз
  • Распознавать цепочки заданий, сформулированных простым текстом, через Amazon Mechanical Turk
  • Отправлять и получать вебхуки
  • Отслеживать текущую геолокацию и сохранять историю перемещений
  • Использовать интеграции с открытыми API любых сервисов (довольно много уже готово, но для экзотики придётся написать своего агента, это несложно)
  • При срабатывании триггера запускать кастомный JS/CoffeeScript код без непосредственного редактирования агентов
  • Аггрегировать все действия в один процесс и выдавать в итоге дайджест сразу по нескольким темам
  • Отправлять алёрты и вообще любые выходные данные через RSS, вебхуки, EMail и SMS

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



За семь лет разработки Huginn собрал сообщество, дописывающее новых агентов по мере необходимости. Также у него открыта программа на Bountysource.

Установка


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

Huginn распространяется в виде докер-образа, поэтому устанавливаем докер, затем просто запускаем:

  docker run -it -p 3000:3000 huginn/huginn

Ждём установки и запуска, затем идём на 3000 порт, логинимся под дефолтной учёткой admin:password и видим полностью готовый к работе сервис. По умолчанию в Huginn уже есть несколько агентов (они были на графе выше), но мы создадим свою цепочку с нуля.

Сначала создадим агента, читающего RSS-версию хабра:



Все доступные опции и общая информация для каждого агента указывается справа от полей, удобно. Пока нам не нужны никакие поля кроме url. Вставляем адрес, сохраняем, снова идём на /agents/new и делаем агента, реагирующего на данные от агента-читателя:



Затем создаём сценарий из этих двух агентов и ставим на запуск.

Beehive




В Beehive агенты называются ульями (hives) сейчас список на вики насчитывает 43 готовых улья. Они могут:

  • Читать и постить в социальных сетях и мессенджерах, пересылать посты из одного сервиса в другой. Поддерживаются Twitter, Telegram, Facebook (ограниченно), Slack, Discord, Tumblr, Mastodon, Jabber, Rocket.Chat, Gitter, IRC, Mumble
  • Мониторить сайты, RSS и OpenWeatherMap. Для веба также можно представляться не только клиентом, но и сервером, реагируя на входящие запросы.
  • Слать по триггеру HTTP-запросы, пуши, EMail, SMS, сообщения в любом из вышеперечисленных сервисов, постить на Pastebin, загружать файлы в S3.
  • Аггрегировать данные мониторинга из GitHub, Prometheus, Nagios
  • Использовать в качестве триггера не только стандартные ивенты и таймер, но и полноценный cron.
  • Выполнять произвольные команды из хост-системы
  • Мониторить отдельные каталоги в хост-системе
  • Управлять умным освещением, совместимым с Philips Hue

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

Установка


Нам снова потребуется докер и одна команда:

docker run -it -p 8181:8181 fribbledom/beehive

Вот только админка уверенно откажется загружаться из-за запросов на localhost, поэтому придётся пробросить адрес:

docker run -it CANONICAL_URL="http://personeltest.ru/away/your.ip.address.here:8181" -p 8181:8181 fribbledom/beehive


Авторизация не предусмотрена видимо, подразумевается что без аутентификации в админку просто не попасть.

Процесс создания заданий и цепочек целиком показан на гифках из репозитория:

Создаем наблюдателя и действие


Создаем цепочку


Node-RED


Здесь мы уже имеем дело не просто с агент-менеджером, а с полноценной платформой для организации задач, ориентированной не только на программистов, но и на обычных пользователей. Как и аналоги, Node-RED помимо использования готовых сценариев и модулей (нод) позволяет определять кастомные задачи, их логику и триггеры. Но если в других менеджерах любая кастомизация означает написание интерфейса (или целого модуля) с нуля или переписывание существующего, то здесь создавать все задачи и сценарии можно не выходя из браузера с помощью визуального программирования потоков данных. Создание модулей всё ещё требует навыков программирования, как и работа с API или ядром системы, но в целом из всех трёх вариантов только этот действительно близок к IFTTT по простоте использования, и помимо самого широкого функционала, у него еще и самое обширное сообщество, выкладывающее тысячи самописных модулей и сценариев.


Пример организации сценария

Установка


Node-RED предлагает несколько вариантов установки, включая npm, деплой в облака и даже установку на Raspberry Pi. Подробные инструкции по всем вариантам здесь, а вот простейшая установка докер-образа:

docker run -it -p 1880:1880 -v node_red_data:/data --name mynodered nodered/node-red

-v node_red_data:/data примонтирует каталог node_red_data в /data контейнера чтобы любые изменения, внесенные в сценарии, сохранялись.

Инстанс Node-RED будет доступен (без авторизации) на 1880 порту. Так как hello-world пример вообще не поможет понять довольно сложное устройство сценария, лучше прочитать полный туториал здесь.

Заключение


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

  • Hugginn покрывается много базовых сценариев из коробки, быстрое создание задач и сценариев. Продвинутые варианты требуют много кода и отладки, мало реально работающих интеграций со сторонними сервисами. Позволяет реализовывать базовую логику в сценариях.
  • Beehive много готовых интеграций, которые явно пишутся разработчиками в первую очередь для себя. Если ваш сценарий не основывается на сложной логике, а просто тащит данные из API и отдает их на обработку или отправку, то это самый быстрый вариант для запуска.
  • Node-RED возможность детально прорабатывать сценарии, огромное количество доступных модулей, сложно разобраться и запустить первый сценарий. Но зато потом можно сворачивать этой штукой горы.



На правах рекламы


VDSina предлагает мощные и недорогие VDS с посуточной оплатой для установки практически любого программного обеспечения. Интернет-канал для каждого сервера 500 Мегабит, защита от DDoS-атак включена в тариф, возможность установить Windows, Linux или вообще ОС со своего образа, а ещё очень удобная панель управления серверами собственной разработки. Обязательно попробуйте!

Подробнее..

3 крутых вебинара по Azure в январе

15.01.2021 10:11:34 | Автор: admin

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

ПосетивAzure Virtual Training Daysвы узнаете как решения на основе облачных сервисов Microsoft Azure могут помочь вашему бизнесу успешно преодолевать сложности.

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

Под катом 3 обучающих мероприятия по Azure в январе.

1. Microsoft Azure: основы

18 января 2021г, 11.00-14.30 (GMT+3) Moscow
19 января 2021r, 11.00-14.30 (GMT+3) Moscow

Чтобы представить будущее, вам необходимо понять, какие возможности перед вами и вашей организацией открывает облако сегодня. В рамках этого вводного курса День виртуального обучения Microsoft Azure: основы рассказывается о концепциях, моделях и сервисах облачных вычислений. Рассматриваются такие темы, как публичное, частное и гибридное облако, а также инфраструктура как услуга (IaaS), платформа как услуга (PaaS) и программное обеспечение как услуга (SaaS).

Во время обучения вы узнаете, как:

  • начать работать с Azure;

  • интегрировать Azure с существующими сетями;

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

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

Вот, что будет:

Введение

Введение

Модуль 0. Введение в курс Модуль 1. Концепции облачных технологий

Модуль 3. Безопасность, конфиденциальность, соответствие требованиям и доверие

Перерыв 10минут

Перерыв 10минут

Модуль 2. Базовые сервисы Azure

Модуль 4. Ценообразование и поддержка Azure

Заключение

Заключение

Регистрация

2. Миграция серверной инфраструктуры

20 января, 2021, 12:00-15:10, (GMT+03:00), с русскими субтитрами

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

Регистрация

3. Модернизация веб-приложений и данных

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

Регистрация

Подробнее..

Sci-Hub теперь находится в нецензурируемой сети

15.01.2021 16:07:39 | Автор: admin

После того, как популярный, но крайне нелюбимый правообладателями сайт Sci-Hub столкнулся с неоднократными отзывами доменных имен, а Твиттер и вовсе забанил аккаунт Sci-Hub, Александра Элбакян зарегистрировала его в сети распределенных доменных имен Handshake.

База данных научных работ теперь доступна напрямую черезпорталы службы,а такжечерез NextDNS, облачный преобразователь доменных имен, ориентированный на конфиденциальность, который преобразует IP-адреса в доменные имена. Разработчики NextDNSназываютсебя истинными сторонниками сетевого нейтралитета и конфиденциальности в интернете. Они считают, что незашифрованные DNS-резолверы, управляемые интернет-провайдерами, наносят ущерб этим двум принципам. Устойчивый к цензуре DNS поможет сохранить доступность Sci-Hub, даже если его снова попытаются закрыть, надеется основательница портала.

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

DNS подобен телефонной книге в Интернете.Адреса в телефонной книге это IP-адреса серверов.DNS был создан для того, чтобы давать IP-адресам понятные для человека имена, поэтому с нашей платформой вы можете найти IP-адрес через Handshake, а не через центр сертификации, рассказываетТишун Рокерре, генеральный директор платформы Namebase, предоставляющей доступ к Handshake.

Как работает Handshake

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

Для обеспечения максимальной открытости, децентрализации, безопасности и, самое главное, устойчивости к цензуре, Handshake использует алгоритм proof-of-work. Такое решение позволяет разрешать имена со скоростью, превосходящей отправку запроса на DNS-резолверы Google. Это быстрее в том случае, если ваш узел имеет локальный кэш данных.

В отличие от предшествующих протоколов, Handshake с введением компактных SPV-подтверждений открывает совершенно новые перспективы. Это по определению позволяет исключить (что очень важно) из процесса верификации доверие к третьей стороне, так как ваш SPV-клиент позволяет локально запускатьсобственныйрекурсивный DNS-резолвер. Архитектура же существующей DNS просто не допускает такого прямого разрешения без посредничества центрального органа.

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

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

Что дальше

Децентрализованная система доменных имен (необязательно Handshake, успеха могут добиться и его последователи), может стать важным инструментом в борьбе за децентрализованный интернет. Этот проект является частью так называемых приложений Web 3.0, стремящихся создать менее централизованный, устойчивый к цензуре Интернет.В Handshake, например, естьдополнительный браузер,позволяющий вести поиск в интернете без цензуры. Также можно упомянуть Urbit, который находится в разработке более десяти лет и полагается на Ethereum для создания платформы для децентрализованных персональных серверов. Все эти решения очень пригодились бы Parler, столкнувшемуся с цензурой и давлением со стороны поставщиков облачных серверов, магазинов приложений и центров сертификации DNS.

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


Что ещё интересного есть в блогеCloud4Y

В тюрьму за приложение

2020 год всемирной мобильности (как бы иронично это ни звучало)

Виртуальные машины и тест Гилева

Китайские регуляторы хотят получать от ИТ-гигантов данные о потребительских кредитах

Как настроить SSH-Jump Server

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

Подробнее..

CloudMaster это про самообслуживание разработчиков в корпоративном ЦОДе и облачных сервисах

25.12.2020 18:10:30 | Автор: admin
Здравствуйте! Я Игорь Гальцев, с 2010 технический руководитель различных направления разработок Softline в области автоматизации управления и продаж облачных (подписочных) сервисов.

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



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


В чем проблема


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

Разрабатывая параллельно несколько сотен проектов, суммарно ресурсов AWS, Azure и GCP клиент потребляет ежемесячно на полмиллиона долларов. А за год создает и удаляет порядка 350 тыс. виртуальных машин.

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

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

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

Самообслуживание через платформы управления облаками (CMP)


Навести порядок в нескольких используемых облаках, частных или публичных, помогают решения класса Cloud Management Platform. Я хочу рассказать о российской альтернативе от наших партнеров платформе CloudMaster, ориентированной на подключение к Azure, AWS и Google Cloud, а также приватным регионам под vCloud Director, vSphere и OpenStack.

С точки зрения разработчика, CloudMaster это портал самообслуживания, где через единый интерфейс и без бюрократии (через UI в браузере, мобильном приложении и консольных командах (Python-скрипты)) можно получать ресурсы в корпоративном облаке или ЦОД. А для инфраструктуры это дополнительный уровень абстракции между облачными платформами и конечными пользователями, на котором сохраняется избирательный общий доступ к ресурсам, политики безопасности, стандартные конфигурации и прочие необходимые инструменты вроде образов машин и Terraform-шаблонов.

Основная часть CloudMaster сделана на Java и базируется на основе фреймворков Spring на сервер-сайде и Dagger в Android-приложении.

Архитектурно CloudMaster заточен на работу с большими командами и значительными объемами отправляемых сообщений: для обработки очередей использован RabbitMQ, для хранения данных MonogoDB, для балансировки Nginx.



Разрабатывался инструмент с 2012 года, а с 2014-го применяется у крупного разработчика софта.

Логика CloudMaster


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

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


Окно запуска виртуальной машины

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


Типовые шаблоны для разных облаков

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


Шаблоны

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

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


Список ресурсов


Список виртуальных машин

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


Пришедшие уведомления


И текст одного из уведомлений

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

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


Биллинг от облачных провайдеров


Окно управления квотами

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

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

При необходимости для администраторов и разработчиков есть Java SDK.
Самое главное, что CloudMaster, как и другие CMP, позволяет перейти от ручного рутинного выделения ресурсов к более интересным задачам: проработке автоматизаций на базе инфраструктура как код и т.п.

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

Архитектура любительского стримингового сервиса DOS игр

29.12.2020 22:09:15 | Автор: admin
Недавно я написал небольшую статью о стриминге DOS игр в браузере. Настало время сделать небольшой технический обзор. Проект ведется исключительно мной, поэтому я его позиционирую как любительский. Среди общедоступных технологий позволяющих сделать стриминг игр можно выделить только WebRTC на нём и построен мой сервис. Как вы уже наверное догадались он состоит из браузерной и серверной части.


Браузерная часть


Основной компонент сервиса WebRTC сервер Janus. Из коробки он предоставляет простое API для подключения к серверу, и поддержки WebRTC протокола. Поэтому, браузерная часть получилось максимально простой, в виде обертки поверх Janus API.

Серверная часть


На стороне сервера используются dosbox, ffmpeg и Janus. Все они собраны вместе в docker контейнер.

Текущая версия сервиса использует:

  • Последнюю версию dosbox
  • Последнюю версию ffmpeg, скомпилированную с поддержкой кодеков vp9 и opus
  • Последнюю версию janus с небольшими дополнениями (о них ниже)


Стриминг звука и видео


Когда docker стартует, супервизор запускает все три программы. Dosbox запускает игру и начинает непрерывно генерировать кадры и звуки. Эти данные перенаправляются в ffmpeg, который создает два RTP стрима (звук, видео). Плагин для стриминга Janus (стандартный компонент), слушает эти стримы и генерирует WebRTC данные для браузера.

{dosbox} --> {ffmpeg} --> {janus streaming plugin} --> {browser}


Поддержка клавиатуры


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

  • pipe kdown когда кнопка нажата
  • pipe kup когда кнопка отпущена


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

{browser} --> {janus data text channel} --> {pipe} --> {dosbox}


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

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


Сервис запущен на платформе Amazon. Для каждого клиента создается новая задача Fargate. После старта задача получает публичный IP, который отправляется в браузер. При получении IP браузер инициирует WebRTC соединение с Janus сервером. Когда dosbox заканчивает работу, задача Fargate автоматически останавливается. Технически нет никаких ограничений на количество одновременных игроков.

{browser} --> {+fargate} --> {ip} --> {browser}
...
{browser} --> {stop} --> {-fargate}


Вместо заключения


Получилось достаточно поверхностно,

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

Обзорная статья: DOS Cloud Gaming
Подробнее..

Обзор набора программ Zoho One

14.01.2021 20:16:39 | Автор: admin

Два года назад на рынке появился такой программный продукт, как Zoho One. Ко мне уже множество раз обращались по поводу интереса к этому набору, внедрял его и консультировал по работе с ним. Сегодня я бы хотел подытожить свой опыт и рассказать об этом продукте поподробнее, ибо он определенно заслуживает внимания. Я специально сделал этот пост коротким, и сконцентрировался только на самом важном, все остальное при желании вы можете выяснить из описания на сайте ссылка на регистрацию аккаунта ZOHO ONE.


Что такое Zoho One?


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


Цена вопроса


Здесь предлагаются две, которые отличаются только ценой, но не набором:


  1. All Employee. Оценка идет по всем сотрудникам. Если вы покупаете этот программный продукт, то лицензию вы должны приобрести на всех сотрудников. Ее месячная стоимость при единовременной оплате за весь год составляет $30. Если платить ежемесячно, то $35. Как рассчитывается цена? В вашей компании 20 человек, значит нужно покупать 20 лицензий. 20*35$=700$
  2. Flexible User. Вы покупаете стандартный набор просто на одного пользователя и платите за это $75 в месяц.

Необходимо учитывать, что как бы не платили, для вас будет работать налог на гугл НДС 20%.


Кроме всего прочего, если учитывайте тот факт, что если вы хотите чтобы тарифы считались в долларах, то заходите на сайт под VPN c IP адресом США. Иначе тарифы вам будут предлагаться в евро, что ощутимо дороже.



Как в Zoho могут посчитать количество пользователей?


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


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


Что вы получаете?


На самом деле выглядит круто, но давайте разберемся что


  • Разные продукты по единой цене. Давайте, к примеру, возьмем продукт Zoho CRM. В этот набор входит Zoho CRM Enterprise Edition. Сам по себе Enterprise стоит $45. Но, помимо него, вы еще получаете Zoho Mail, Zoho Campaigns и другие подобные программы. И все это по единой цене.


  • Управление из единого центра. Теперь давайте разберемся, каким образом с этим работать. Zoho One это не просто набор, это, можно сказать, еще и отдельный продукт в принципе. Из единого центра вы управляете всеми вашими пользователями, сотрудниками, не заходя в каждый из программных продуктов и не настраивая их по отдельности.




Это значит, что у Zoho One есть отдельный дашборд и панель управления. Здесь вы можете настроить количество пользователей, их доступ к каждой из систем и права в них. К примеру, в Zoho CRM один пользователь может быть администратором, а в Zoho Books он может быть менеджером по продажам. Вы, даже не заходя в эти программные продукты, находите нужного пользователя в системе, назначаете ему приложение и определяете права.


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

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


Интеграция сервисов


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


Для примера:


  • Вы можете интегрировать Zoho CRM с Zoho Inventory. То есть вы будете выгружать из Zoho CRM или обратно товары и клиентов.
  • Вы можете интегрировать Zoho Books с Zoho Inventory, выгружая товары и транзакции.
  • Вы можете интегрировать Zoho Project с Zoho Desk. Для этого достаточно только поставить несколько галочек. Соответственно, никаких проблем с этим у вас быть не должно.


Ограничения о которых надо знать.


По пользователям:


Если вы купили Zoho Mail, вы получаете доступ к нему по тарифу Zoho One. Здесь очень важный момент: при привязке вашего домена к аккаунту ZOHO вы можете создавать почтовые ящики на исходящую почту только по количеству ваших пользователей.


К примеру, у меня есть электронный адрес ramil@trinion.org. На входящую почту я могу создать псевдоним info@trinion.org и привязать его к основной учетной записи. Но если я захочу с info@trinion.org рассылать письма, я этого сделать уже не смогу. То есть Zoho такая почта будет работать только на прием.


По расширениям:


Доступны только ограниченное количество расширения именно в рамках ZOHO ONE: нельзя купить дополнительное количество лицензий для ZOHO PROJECTS, если хотите еще пользователей купите еще лицензий ZOHO ONE.



Как это обойти?


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


Всем ли вы будете пользоваться?


Важно понимать что вы не будете пользоваться всем что входит в данный набор, просто потому что там много всего что не нужно большинству пользователей ( к примеру ZOHO Backstage). Но для чего же берут этот набор? Вот список систем которые обыкновенно используются из данного набора
CRM, Desk, Projects, Books, Inventory, SalesIQ, Mail.


Подытожим


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


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


С уважением Кинзябулатов Рамиль.

Подробнее..

Категории

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

© 2006-2021, personeltest.ru