Блог

Интернет вещей стал горячей темой и модным словом в 2016 году, когда крупные поставщики облачных услуг представили свои передовые вычислительные решения. Но что, если эра IoT действительно начнется в этом году?

Первым подключенным к Интернету устройством был тостер, представленный Джоном Ромки в 1990 году для конференции Interop . Сам термин «IoT» был придуман в 1999 году Кевином Эштоном из Массачусетского технологического института. В течение следующих 15 лет были объявлены различные пилотные проекты, Tesla, Mercedez, General Motors, Ford и Volvo объявили о своих намерениях по созданию легковых и грузовых автомобилей с самостоятельным вождением, и даже Google объявил о своем проекте по производству легковых автомобилей. Amazon Echo и Google Nest вошли в нашу жизнь и начали превращать наши квартиры в умные дома будущего.

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

Edge computing – ответ на проблемы IoT

В 2016–2017 годах Microsoft представила свою службу Azure IoT Edge , Google Cloud выпустила свое облачное ядро ​​IoT, AWS улучшила свои предложения IoT и представила множество новых функций во время AWS re: Invent 2017 . Между тем, несколько менее крупных облачных провайдеров, таких как DigitalOcean и IBM, также используют свою возможность получить долю на будущем рынке IoT.

Edge computing- это новая концепция обработки данных, разработанная специально для узлов IoT. Основными требованиями являются:

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

• Горячая обработка данных внутри узла . Вышеупомянутые сценарии ответа должны обрабатываться моделями машинного обучения, развернутыми внутри узла IoT. Сами алгоритмы ML сначала обучаются в облаке с использованием огромных массивов исторических холодных данных, но обученные модели занимают всего 1 ГБ дискового пространства и могут эффективно работать внутри узла IoT. (3)
  Благодаря такой структуре горячие данные могут обрабатываться на месте, а ответы могут выдаваться в течение миллисекунд, а холодные данные отправляются в облако и используются в текущем процессе обучения модели ML (4). Например, когда небольшая партия датчиков регистрирует порыв ветра с гравием, который угрожает ветряной электростанции, вся ветровая электростанция регулирует положение роторов, чтобы избежать повреждения.
• Регулярные обновления модели ML . Чем больше исторических данных доступно для модели ML, тем лучше она может предсказать необходимые результаты. Поэтому локальные экземпляры модели, развернутой в узлах IoT, должны время от времени обновляться, поэтому для обеспечения эффективной работы системы необходимо установить безопасный канал соединения и защищенный от ошибок конвейер CI / CD.
• Стабильность и безопасность покрытия интернета . Что касается вопросов возможных краж со взломом умных домов или автокатастроф, стабильность интернет-связи и безопасность соединений является еще одной серьезной проблемой. Многие компании, такие как AT & T в США и Vodafone в Великобритании , планируют запустить сети 5G, чтобы обеспечить достаточный доступ в Интернет для смартфонов и других подключенных устройств.

Таким образом, сказать, что индустрия ИТ-услуг активно разрабатывает технологии, программное обеспечение и методы для поддержки потока данных, ожидаемых от миллиардов взаимосвязанных устройств, которые появятся в сети в 2019 году. Но действительно ли эра IoT начинается в этом году?

Готовы ли мы к эре IoT?

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

Выводы о готовности облака к IoT

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

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

Что, по вашему мнению, могло бы ускорить наступление эры Интернета вещей?

Вопросы безопасности Jenkins

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

Включить SSL для Дженкинса

Сертификаты Secure Sockets Layer / Transport Layer Security (SSL / TLS) могут использоваться для защиты сетевых соединений и установления идентичности веб-сайтов через Интернет. Это легко можно реализовать, установив в свой мастер Jenkins балансировщик нагрузки ELB. В этом случае вы можете использовать диспетчер сертификатов AWS, чтобы подключить сертификат, который предоставляет вам зашифрованные сетевые подключения и защищает ваши данные во время их передачи.

CSRF Защита

Подделка межсайтовых запросов (CSRF) – это класс атак, который позволяет выполнять нежелательные действия над Jenkins. По умолчанию в установках Jenkins 2.x включена опция защиты CSRF. Чтобы проверить состояние этого параметра, выберите « Управление Jenkins» , затем « Настроить глобальную безопасность» и убедитесь, что параметр «Предотвращать подделки межсайтовых запросов» включен.

Смысл безопасности сборки на мастере

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

Контроль доступа рабочего узла

В версиях Jenkins 1.5.80.x и более поздних версий установлена ​​подсистема, которая устанавливает барьер между рабочими узлами и мастером, чтобы безопасно подключать к мастеру менее доверенные рабочие узлы.

В вашей установке Jenkins 2.x этот барьер должен быть включен по умолчанию. В этом можно убедиться, посетив «Управление Jenkins», затем «Настроить глобальную безопасность» и убедившись, что «Включить ведомое устройство -> Управление основным доступом» включено.

Настроить аутентификацию пользователя

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

Аутентификация пользователя может быть обеспечена несколькими способами:

Защита доступа к сети

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

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

$ sudo iptables -A PREROUTING -t nat -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080 
$ sudo iptables -t nat -I OUTPUT -p tcp -o lo --dport 80 -j REDIRECT --to-ports 8080

Для каждого порта ограничьте доступ к вашему IP-адресу или диапазону IP-адресов с помощью поля «Источник», которое определяет трафик, который может достичь вашего экземпляра. Укажите один IP-адрес или диапазон IP-адресов в нотации бесклассовой междоменной маршрутизации (CIDR) (например, 203.0.113.5/32, как показано на следующем рисунке). При подключении из-за брандмауэра вам понадобится диапазон IP-адресов, используемый клиентскими компьютерами.

Хотите настроить безопасность Jenkins, обращайтесь ITFB обеспечит защиту Вашего наземного или облачного сервера.

Одна из наиболее распространенных услуг DevOps, которую мы предоставляем в ITFB, – это облачная миграция с AWS на GCP, Azure, DigitalOcean и наоборот, или с устаревшей инфраструктуры на облако.

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

Однако переход на облачные технологии может представлять другую опасность – привязку к поставщику, когда рабочие процессы компании и ИТ-операции связаны со специфическими функциями и услугами одного поставщика облачных услуг (CSP). Например, если компания строит свою деятельность на основе AWS RDS, замена ее на аналоги в Google Cloud или MS Azure является довольно сложным делом.

Лучшие практики облачной миграции

Таким образом, при выполнении миграции в облако следует соблюдать определенные рекомендации:

• Создайте свою инфраструктуру как код, используя манифесты Terraform и Kubernetes
• Относитесь к своим виртуальным машинам как к скоту, а не как к домашним животным (будьте готовы убить и перезапустить любую машину в любое время)
• Развивайте команду DevOps в соответствии с ростом облачной инфраструктуры, которую вам необходимо поддерживать
• По возможности используйте сторонние инструменты, чтобы избежать блокировки поставщика

Инструментарий для миграции инфраструктуры AWS

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

Оркестровка инфраструктуры: Terraform

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

Вот почему Terraform должен стать краеугольным камнем современной разработки программного обеспечения. Когда все параметры конфигурации инфраструктуры сохранены в декларативном коде в легко настраиваемых манифестах Terraform, каждое состояние ваших систем может быть легко воспроизведено. Более того, эти манифесты работают на нескольких облачных платформах, а минимальные изменения позволяют переходить с Amazon Web Services на платформу Google Cloud – одни и те же манифесты хорошо работают с обоими этими поставщиками.

Terraform обрабатывает все, от интеграции до балансировки нагрузки и создания сетевых ресурсов. Например, можно легко создать запись DNS, хранящуюся в GCP, которая будет управлять веб-сервисами в AWS. В то время как каждая облачная платформа имеет свой собственный менеджер конфигурации (AWS Cloud Formation, Google Cloud Deployment Manager или Heat ORchestration Templates for OpenStack), Terraform превосходит их всех по эффективности и удобству, как инструмент для управления облачной независимой конфигурацией, способный работать в нескольких облачных экосистемах. ,

Управление сервером и конфигурацией: Ansible

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

Например, база кода Ansible может использоваться без корректировок как в AWS, так и в GCP. Единственные вещи, которые должны быть обновлены – это скрипты динамической инвентаризации, написанные на Python. Остальная конфигурация, управляемая плейбуками Ansible, остается прежней, что позволяет легко использовать Ansible в нескольких облачных средах. Тем не менее, Ansible не идеален, так как это система, основанная на push(в отличие от Salt или Puppet или Chef). Таким образом, он не идеален для автоматического масштабирования, но это можно исправить с помощью дополнительных сценариев.

Создание образа: Docker / Packer

Образ виртуальной машины, является основным строительным блоком современной облачной инфраструктуры. Запуск с Docker или Packer позволяет быстро предоставить предварительно сконфигурированную инфраструктуру для запуска ваших приложений и сервисов. AWS Marketplace предоставляет огромную библиотеку готовых образов AMI буквально для любых целей. Однако варианты использования в бизнесе по-прежнему более разнообразны, чем этот ассортимент, поэтому создание библиотеки образов ваших сред тестирования, промежуточных и производственных сред имеет решающее значение для обеспечения производительности и стабильности ваших ИТ-операций. Таким образом, каждый бизнес должен иметь возможность создавать и запускать изображения для любой облачной платформы и региона.

Docker и Packer являются инструментами выбора для создания и работы с реестром образов. Основным преимуществом их использования в сочетании с Terraform и Ansible является возможность бесперебойной работы независимо от базовой облачной инфраструктуры. Изменение только пары строк кода позволяет раскрутить образ в AWS, GCP, Azure или DigitalOcean – таким образом миграция AWS становится намного проще и намного более управляемой.

Контейнер приложений: Docker

Следующим шагом управления вашими приложениями в облаке после создания образов является запуск созданных из них контейнеров. Лучше всего это сделать с помощью Docker, так как этот инструмент был первым и остается лучшим подходом к контейнеризации приложений. Приложения упакованы в аккуратные контейнеры с кодом, которые включают в себя операционную систему, все необходимое время выполнения и библиотеки, которые позволяют запускать код. Основным преимуществом этого подхода является 100% надежность – контейнеры Docker работают везде, где бы то ни было, будь то AWS, GCP, Azure, OpenStack или любая другая инфраструктура. Контейнеры Docker могут быть запущены в любой ОС с установленным Docker, что значительно увеличивает переносимость и снижает эксплуатационные расходы.

Конфигурация и управление контейнерами: Kubernetes

Kubernetes был впервые разработан Google Cloud Platform, но теперь выпущен как инструмент с открытым исходным кодом. Его невероятная гибкость и способность управлять контейнерами не имеют себе равных. Все крупные поставщики облачных услуг предлагают Kubernetes-как-услугу, поэтому использование вашей инфраструктуры с использованием Kubernetes является разумным выбором, поскольку оно определенно подойдет где угодно, независимо от назначения вашей облачной миграции. Kubernetes позволяет запускать, работать, отслеживать, завершать работу и перезапускать кластеры, узлы и модули контейнеров, обеспечивая стабильное время безотказной работы и простоту масштабирования для ваших облачных операций. Google Kubernetes Engine – это отличный способ начать знакомство с инструментами настройки контейнеров, а миграция с него или на него подробно описана в документации по сервису миграции AWS, а также для других поставщиков облачных сервисов.

Управление пользователями: JumpCloud

Одной из проблем масштабного управления облаком является сложность управления пользователями, поскольку каждой учетной записи пользователя должен быть предоставлен SSH-доступ к приложению, поэтому вы должны хранить и управлять множеством SSH-ключей. JumpCloud решает эту проблему, предоставляя размещенную службу LDAP / Active Directory, позволяющую легко порождать пользователей в любой базе данных и любом контейнере. Google Compute Engine предоставляет еще одну удобную функцию, поскольку пользователи могут использовать команду gcloud для загрузки своих ключей ssh keys/user из своего интерфейса командной строки Google, и эти пользователи будут созданы на предполагаемых компьютерах с самого начала. Это также можно сделать через конечную точку JumpCLoud, точно так же, как для AWS, Azure и любого другого облака.

Хранение образов: RexRay

Еще одна вещь, которую следует учитывать при переносе AWS, – это перенос вашей библиотеки образов на другую платформу. RexRay – это удобный интерфейс для хранения и монтажа образов в контейнеры. Он предоставляет аккуратный плагин Docker, который выполняет вызовы API для AWS, GCP, Azure и других платформ, поэтому изменение пары строк кода позволяет выполнить переход с томов AWS EBS на GCP Compute Engine без особых ручных усилий.

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

Благодаря использованию этих и других популярных инструментов DevOps ИТ-команда ITFB может выполнить быструю миграцию AWS от любого другого поставщика облачных услуг. Все эти инструменты предназначены для работы в ансамбле и обеспечивают согласованный уровень управления на любых облачных платформах. Эти инструменты обеспечивают плавную и практически без усилий миграцию между AWS и Google Compute Engine, и наша команда DevOps способна выполнить эту задачу хорошо.

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

Хотите, чтобы мы справились с миграцией AWS? Дайте нам знать, ITFB всегда рада помочь!

Что говорит твой инженер DevOps? Что такое кластер Kubernetes и почему серверы должны быть настроены с использованием манифестов Terraform? Почему вы должны заботиться об агентах Zabbix? Вы просто хотите, чтобы работа была выполнена, и проект был запущен вовремя!

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

DevOps Глоссарий

Это большой список, но далеко не исчерпывающий список терминов DevOps, объясненных простыми словами.

Агент – часть программы «сервер-агент», выполняемая в каком-либо экземпляре или контейнере для предоставления входных данных для приложения централизованного сервера (например, агента мониторинга Zabbix)

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

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

Amazon AWS – Amazon Web Services – самый популярный поставщик облачных услуг (CSP) согласно отчету о состоянии DevOps за 2017 год, предлагающий широкий спектр услуг облачных вычислений для предприятий любого масштаба.

Ansible – механизм автоматизации для различных ИТ-задач, таких как подготовка и настройка облачной инфраструктуры. Ansible – это инструмент с открытым исходным кодом, который взаимодействует с несколькими программными модулями через соединение SSH, скрипты PowerShell или различные API.

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

Apache – один из самых популярных веб-серверов с открытым исходным кодом (уступает только NGINX), кроссплатформенный инструмент для запуска веб-сайтов и приложений.

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

ASG – Auto Scaling Group – сервис AWS, используемый для объединения нескольких экземпляров EC2 в логические группы в целях проектирования инфраструктуры и простоты управления; группа состоит из идентичных экземпляров, которые добавляются или удаляются в соответствии с требованиями рабочей нагрузки.

AWS CLI – интерфейс командной строки AWS – инструмент AWS для управления различными сервисами и продуктами AWS из терминала командной строки.

Автоматизация выпуска приложений или ARA – общий подход к развертыванию нового кода в производстве с минимальными человеческими действиями с помощью автоматизированных конвейеров CI / CD

Amazon Aurora – сервис AWS, предоставляющий облачную реляционную базу данных, ставший самым быстрорастущим сервисом в истории AWS . Эта база данных в 5 раз быстрее, чем MySQL, и в 3 раза быстрее, чем PostgreSQL, не говоря уже о том, что она является базой данных по умолчанию для многих продуктов и сервисов AWS.

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

Bastion host – специальный сервер, используемый для доступа к частным сетям и противостояния хакерским атакам. Обычно размещает одно приложение (например, прокси-сервер) и ключи SSH для доступа и управления базовой облачной инфраструктурой.

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

Bucket – логическая единица в Amazon S3 (Simple Storage Service), используемая для хранения нескольких типов объектов (в основном, различных данных и метаданных, которые их описывают).

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

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

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

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

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

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

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

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

CI / CD – Непрерывная интеграция / Непрерывная доставка – основа современной культуры DevOps. CI гарантирует, что новый код передается в централизованное хранилище кода несколько раз в день, чтобы пройти автоматические модульные тесты и ускорить сборку нового программного обеспечения. Если тесты пройдены успешно, CD гарантирует, что новая версия приложения будет автоматически отправлена ​​в промежуточную и производственную среды без простоев службы. Рабочий процесс CI / CD гарантирует, что все ошибки будут найдены и исправлены на ранней стадии, а продукт будет доступен в любое время.

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

Commit  (Комит) – процесс отправки кода в репозиторий Git и полученный фрагмент кода.

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

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

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

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

Управление конфигурацией – процесс установки и поддержания требуемых параметров программной экосистемы с помощью инструментов автоматического управления конфигурацией, таких как Kubernetes, Ansible, Puppet, Chef, Saltstack и т. Д.

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

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

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

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

Docker Swarm – движок контейнерной оркестровки, разработанный Docker. Это встроенный в Docker инструмент для кластеризации и планирования контейнеров, способный запускать тысячи контейнеров одновременно. К сожалению, он не может похвастаться той же функциональностью, что и Kubernetes, и практически не используется с середины 2018 года.

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

Фреймворк Django – это высокоуровневый фреймворк Python, ориентированный на чистый дизайн, быструю разработку и высокую производительность приложений. Нашел широкое применение в веб-разработке и обработке больших данных.

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

Среда (Environment) – все ресурсы сервера (ОС, библиотеки, API, инструменты и платформы и т. Д.), Необходимые для запуска программного обеспечения на различных этапах его жизненного цикла (разработка, тестирование, подготовка, производство).

ElasticSearch – RESTful, распределенный движок для поиска и анализа данных, построенный на Apache Lucene. Как ядро ​​стека Elastic, Elasticsearch позволяет хранить и обрабатывать данные из нескольких облачных инструментов мониторинга и ведения журналов.

Envoy – мощный прокси C ++ для обработки трафика между микросервисами.

EC2 – Amazon Elastic Compute Cloud – центральное предложение Amazon Web Services, предоставляющее несколько типов виртуальных серверов для запуска приложений в облаке.

EKS – Amazon Elastic Computer Service для Kubernetes – управляемая служба Amazon, которая позволяет любому человеку развертывать и запускать Kubernetes в инфраструктуре AWS без необходимости разбираться и настраивать кластеры самостоятельно.

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

Fargate – Amazon Fargate – это сервис Amazon для запуска контейнеров Docker в управляемой инфраструктуре, такой как EKS, без необходимости что-либо настраивать. Он работает по схеме выставления счетов без сервера – вы указываете, что необходимо сделать, и оплачиваете потребляемые ресурсы без какой-либо ручной настройки кластера.

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

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

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

GitLab – веб-портал Git с открытым исходным кодом, настроенный на производительность DevOps, благодаря встроенной поддержке инструментов CI / CD, таких как Gitlab CI.

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

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

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

IaC – Инфраструктура как код – один из базовых принципов DevOps. Это означает, что конфигурация инфраструктуры выполняется с помощью машиночитаемых декларативных файлов, а не вручную или с использованием интерактивных инструментов. Эти файлы (например, манифесты Kubernetes или Terraform ) могут храниться в репозиториях GitHub, настраиваться и корректироваться так же, как и код, что обеспечивает эффективную автоматизацию обеспечения инфраструктуры.

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

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

InfluxDB – база данных с открытым исходным кодом для обработки событий временных рядов. Она написана на Go и используется для мониторинга инфраструктуры, хранения данных высокой доступности и аналитики в реальном времени. Лучше всего он работает с такими инструментами DevOps, как Prometheus и Grafana.

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

Пропускная способность ввода / вывода – количество операций ввода / вывода в секунду, характеристика пропускной способности сети или накопителя.

Ingress controller – программный модуль, используемый для обеспечения балансировки нагрузки в модулях Kubernetes.

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

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

Kubernetes – платформа управления контейнерами с открытым исходным кодом от Google. Kubernetes и Docker – это основы выполнения современных рабочих нагрузок в облаке.

Kibana – часть стека Elastic, отвечающая за визуализацию данных и навигацию по кластеру ELK.

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

Lead time (Время выполнения) – время, необходимое для перемещения нового пакета кода из коммита в релиз.

Микросервисы – пример сервис-ориентированного подхода в архитектуре программного обеспечения (SOA), практика разделения монолитного приложения на набор слабо связанных сервисов, отвечающих за определенный аспект операций. Эти детализированные сервисы взаимодействуют через легкие протоколы и API для обеспечения гибкости и масштабируемости продукта.

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

MTTR – среднее время до восстановления – среднее ожидаемое время, когда отказавший системный компонент снова заработает; основной параметр сценариев восстановления после сбоев, системного стресс-тестирования и проверки производительности.

Node (узел, нода)- физическая или виртуальная машина в кластере Kubernetes, используемая для размещения модулей, которые запускают контейнеры Docker.

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

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

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

Оркестровка – практика автоматизации ИТ-задач (в частности, управления контейнерами и конфигурацией инфраструктуры) в контексте SOA, виртуализации, предоставления среды. Короче говоря, это процесс выполнения предопределенных задач с использованием предопределенных сценариев, выполняемых с помощью интерактивных инструментов, таких как Terraform (который был создан специально для целей оркестровки конфигурации).

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

OpenStack – платформа с открытым исходным кодом для создания локальных облачных инфраструктур.

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

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

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

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

Python – интерпретируемый язык программирования высокого уровня. Благодаря своей эффективности и скорости Python в настоящее время широко применяется для решения задач от разработки веб-сайтов до аналитики больших данных .

Pod – базовое структурное подразделение Kubernetes, группа контейнеров Docker, развернутых на одном хосте.

Playbook – Ansible playbook – это инструкции по развертыванию инфраструктуры с подробными руководствами по выполнению серии команд для выполнения конкретных задач.

ProxMox – основанная на Debian платформа с открытым исходным кодом для развертывания и управления виртуальными машинами.

Production environment (PROD, Производственная среда)- среда, в которой программный продукт или услуга используется целевой аудиторией.

RDS – сервис реляционных баз данных AWS, облачная база данных, использующая распределенную природу сервисов AWS.

Rolling update (Скользящее обновление) – процесс плавных обновлений для приложения без простоев, выполняемый экземпляр за экземпляром. Он использует Kubernetes для обеспечения бесперебойной доступности приложений и положительного взаимодействия с пользователем.

Rollback  (Откат) – ручное или автоматическое восстановление ранее сохраненного состояния программы или базы данных.

Regression testing (Регрессионное тестирование) – комплексное тестирование обновленной версии продукта, чтобы убедиться, что последняя сборка не оказала негативного влияния на уже имеющуюся функциональность.

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

Source control – система хранения, управления и отслеживания изменений в исходном коде. Наиболее популярными являются GitHub, GitLab и BitBucket.

S3 – Amazon Simple Storage Service – сервис облачных вычислений для хранения любых объектов данных, необходимых для стабильной работы ваших приложений.

Snapshot . Amazon EBS snapshot EBS – это команда для создания статической копии содержимого вашего экземпляра EC2 в целях резервного копирования и восстановления.

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

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

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

Модульное тестирование (Unit testing)- основа CI / CD, модульное тестирование – это практика тестирования кода приложения небольшими блоками на основе кода автоматизированного тестирования перед сборкой приложения, чтобы минимизировать время, необходимое для обнаружения и исправления ошибок, сокращая время выхода на рынок.

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

VPC peering  – AWS VPC – это сервис, который логически изолирует определенное количество общедоступного облака AWS для создания виртуальных частных облаков.  AWS VPC peering позволяет объединить ресурсы нескольких таких облаков в случае необходимости.

Vault – продукт Hashicorp для безопасного хранения таких секретов, как ключи SSH, токены, пароли, ключи API и другие важные элементы инфраструктуры Kubernetes.

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

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

DefectDojo – это программа безопасности приложений, написанная на Python / Django. DefectDojo был создан в 2013 году и с открытым исходным кодом 13 марта 2015 года. Проект был начат, чтобы оптимизировать отслеживание уязвимостей. Главная цель DefectDojo – сократить время, которое специалисты по безопасности тратят на регистрацию уязвимостей. DefectDojo выполняет эту задачу, предлагая систему шаблонов для уязвимостей, импорт для распространенных сканеров уязвимостей, генерацию отчетов и метрики.

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

Использовать DefectDojo легко.

• DefectDojo доступен для скачивания и имеет установочный скрипт.
• Так же доступен docker контейнер с предварительно созданной версией DefectDojo.

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

Возможности DefectDojo

• Управление уязвимостями
  DefectDojo поддерживает более 22 форматов сканеров.
• Jira Integration
  DefectDojo имеет двунаправленную интеграцию Jira.
• Управление процессом
  Управляйте своим рабочим процессом безопасности приложений.
• CI / CD
  Отслеживайте тесты безопасности и точно узнавайте состояние безопасности вашего продукта.

CI / CD Автоматизация и слежение

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

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

Функции управления уязвимостями

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

Track Vital Информация о продукте

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

Часто задаваемые вопросы

• Откуда появилось DefectDojo?
  DefectDojo появилось в Rackspace, а затем было передано в качестве открытого исходного кода, чтобы стать ведущим менеджером дефектов приложений с открытым исходным кодом.
• Зачем создавать такие приложения?
  DefectDojo существует потому, что не так много приложений, таких как DefectDojo, которые помогают управлять программой безопасности приложений. DefectDojo – одно из единственных приложений для управления уязвимостями, которое все еще имеет открытый исходный код.
• Каковы отношения DefectDojo с OWASP?
  DefectDojo – это проект OWASP.
• Кто использует DefectDojo?
  DefectDojo используется во всем мире 100 крупными компаний для малого бизнеса.

Хотите использовать это продукт, обращайтесь, мы поможем office@itfb.com.ua

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

Экономия затрат — одна из основных причин переноса рабочей нагрузки в «облако». При правильном использовании «облачная» инфраструктура может снизить совокупную стоимость владения (ТСО) по сравнению с локальной инфраструктурой. Однако это не означает, что простой перенос приложений и данных в «облако» неизбежно ведет к экономии затрат.

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

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

Оптимальные размеры экземпляров виртуального сервера

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

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

• Не приобретайте ненужных ресурсов. Если ваша рабочая нагрузка требует 4 Гбайт памяти, то приобрете­ние 8 Гбайт будет непроизводительной тратой средств.
  Конечно, необходимо предусмотреть достаточный размер буфера для обработки резких скачков объема загрузки (по крайней мере, на время создания новых экземпляров, если требуется поддерживать обработку повышенной загрузки в течение длительного времени).
• Выбирайте экземпляр с учетом специфических потреб­ностей рабочей нагрузки. Обеспечение надежной работы некоторых приложений требует в равной мере вычис­лительных ресурсов и памяти. Для других приложений требуется больше памяти, но меньше процессорного времени, и наоборот. Есть приложения, которым нужен графический процессор. Независимо от особенностей приложения, почти наверняка существует тип экземпляра, полностью отвечающий его потребностям. Поэтому, прежде чем приобретать универсальный экземпляр с одинаковыми ресурсами виртуальных процессоров и памяти, проверьте, нет ли специализированного варианта, более целесообразного с точки зрения баланса между ресурсами и затратами. Возможно, это потребует нагрузочного тестирования самого приложения с целью определения оптимального сочетания различных типов ресурсов. Можно также воспользоваться средствами оптимизации затрат на «облачные» вычисления, созданными специально для правильного определения подходящих размеров экземпляра.

«Облачные» экземпляры по сниженной цене

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

Однако, если пойти на организационные меры по обеспечению прогнозирования потребностей «облачного» экземпляра, то можно за счет использования зарезерви­рованных экземпляров AWS сэкономить до 75% средств.

Многоуровневые «облачные» хранилища

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

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

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

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

Выбор подходящих «облачных» сервисов

Виртуальный сервер и хранилище данных — наиболее распространенный тип «облачной» службы. Однако современные общедоступные «облака» предлагают множество других вариантов, например решение AWS Fargate для запуска приложений внутри контейнеров, Microsoft Azure Blockchain Workbench или «облачные» функции Google Cloud.

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

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

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

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

«Многооблачная» архитектура

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

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

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

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

Однако для обособленных рабочих нагрузок (напри­мер, если предполагается выполнить развертывание веб-приложения на платформе AWS, а для резервного копирования данных использовать Azure) экономически выгодная «многооблачная» стратегия легко реализуется с технической точки зрения.

Источник: Журнал “Windows IT Pro/RE”

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

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

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

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

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

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

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

• Неполадки внутри ядра ОС Linux, связанные с особенностью структуры кэша-объектов;
• Проведение отладки внутри ядра с помощью команды perf.

Немного о команде perf. Как ни странно, мало кто использует данное решение, сталкиваясь с проблемой в Docker. Оно было создано с появлением версии 2.6.31, а представляет из себя достаточно универсальный инструмент для диагностики ядра системы.

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

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

Запустив perf, вы можете столкнуться с весьма неожиданной для себя картиной. На скриншоте вы можете увидеть, как команда отработала на протяжении 10 секунд и представила данные в виде таблицы: слева находится информация о работе на железе, а справа – непосредственно в контейнере.

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

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

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

Перед вами библиотека glog, которая использовалась пользователем для его собственных нужд. То есть, она является сторонней. Одна единственная строчка LogFileObject::Write тормозит Docker из-за постоянного вызова при запуске нового события. Очевидно, что запись в лог проводится регулярно в любой системе, поэтому неудивительно, что производительность снизилась. Решение проблемы простое: отключаем fadvise с помощью параметра –drop_log_memory=false:

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

Итог

Чтобы не допустить банальную ошибку, с которой мы столкнулись в данном примере, стоит помнить о простых правилах во время использования Docker. Во-первых, все контейнеры потребляют ресурсы всей аппаратной части, включая ресурсы ядра. А значит, нужно регулярно проводить диагностику именно этой части. И тут мы переходим к второму правилу: чтобы упростить себе жизнь используйте для отладки «perf»!

Стабильная работа