пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ пїЅпїЅпїЅ пїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅпїЅ
По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Канареечное (canary) развёртывание – это метод разработки и развертывания программного обеспечения, который позволяет выпускать новые функции и обновления постепенно – сначала для небольшой группы пользователей, а затем для всей базы пользователей.
Такой подход предполагает, что вы создаете новую версию программного обеспечения и развертываете ее для небольшой группы пользователей, но при этом остальные пользователи продолжают пользоваться старой версией. После чего команда разработчиков внимательно наблюдает за новой версией с целью убедиться, что она стабильна и работает как надо.
Если все будет идти хорошо, новую версию развернут уже для большего числа пользователей, и так далее, пока в конечном итоге она не достигнет всех пользователей. Таким образом, команда проекта минимизирует риск появления ошибок или каких-то других проблем, которые могут затронуть сразу всех пользователей.
Цель канареечного развертывания – снижение риска для большой базы пользователей при внедрении новых функций. Распространяя изменения среди пользователей постепенно, разработчики могут отслеживать производительность и стабильность новой версии и вносить все необходимые корректировки перед тем, как развернуть ее для всей базы пользователей. Тем самым переход на новую версию происходит более плавно.
1. Основные концепции и преимущества
Вот так выглядят основные концепции канареечного развертывания:
Сначала новая версия развертывается для небольшой группы пользователей, а затем постепенно распространяется для большего числа.
Новую версию необходимо внимательно отслеживать, чтобы убедиться, что она стабильна и работает правильно.
При возникновении каких-либо проблем, можно быстро и легко откатить развертывание к предыдущей версии.
Процесс развертывания стоит максимально автоматизировать, чтобы минимизировать человеческий фактор.
Канареечное развертывание имеет некоторые преимущества для DevOps, а именно:
Внедряя изменения постепенно, вы, таким образом, минимизируете риск появления ошибок и прочих проблем, которые могут затронуть сразу всех пользователей.
Разработчики могут быстрее получать обратную связь, что позволяет им вносить любые необходимые изменения до того, как новая версия будет развернута для всей базы пользователей.
Отслеживая производительность и стабильность новой версии, разработчики могут убедиться в том, что она соответствует всем необходимым стандартам качества, до того, как развернут ее для всей базы пользователей.
Канареечное развертывание помогает разработчикам и всем заинтересованным сторонам быть более уверенными в том, как пройдет процесс развертывания, поскольку снижает риск возникновения проблем, которые могут повлиять на взаимодействие с пользователями.
2. Терминология канареечного развертывания
Давайте пройдемся по стандартному жизненному циклу процесса.
Все начинается с группы
Canary
, то есть группы «ранних пользователей» новой версии системы. Параллельно с ней существует еще одна группа –
Baseline
. К этой группе относятся все пользователи, оставшиеся за пределами группы Canary.
Пока пользователи Canary продолжают использовать новую версию, канареечное развертывание распространяет ее на все большее количество пользователей. Это называется
переключением трафика
. Группа Canary растет, а группа Baseline – уменьшается, таким образом, система выполняет
постепенное развертывание
.
По ходу дела система мониторинга регистрирует все действия и показатели использования и генерирует
метрики
, которые нужны разработчикам в качестве обратной связи. После чего разработчики изучают это все и исправляют все, что необходимо, или в случае, если они не могут в данный момент устранить проблемы, просто
откатывают
программу к исходной версии.
Лучше всего
автоматизировать
все действия, касающиеся мониторинга и развертывания. Это даст разработчикам возможность сосредоточиться исключительно на устранении проблем.
Может оказаться так, что группа Canary обнаружит, что какие-то функции новой версии не оправдали ожиданий, а некоторые получились очень даже неплохими. Таким образом, разработчики могут
помечать флагами функции
, в которых есть проблемы, и исключать их из процесса развертывания.
Разработчики внимательно следят за обеими группами одновременно. Пользователи генерируют результаты
А/В-тестирования
, которые дают понять, как ведут себя старая и новая версии, и какая из них лучше. В новой версии также постоянно выполняются автоматические тестирования, обеспечивающие основательность
проверки работоспособности
группой Canary.
3. В чем отличие от обычного развертывания?
Если разобрать процессы жизненного цикла более высокого уровня, то различия между канареечными процессами развертывания и обычными становятся вполне очевидными.
Вы выполняете развертывание постепенно, при этом контролируя его, вместо того, чтобы развертывать продукт сразу для всех пользователей, ожидая проблем, которые затронут всех сразу.
Вы ограничиваете риск появления ошибок в новых версиях группой Canary, а не подвергаете опасности весь мир.
Вы отслеживаете новую версию до того, как она дойдет до всех пользователей, а не после, вкладывая при этом огромное количество времени и ресурсов в «гиперопеку» в процессе релиза.
Вы можете откатить новую версию до того, как она полностью развернется в рабочей среде. Впрочем, планируется дополнительное окно релиза, которое позволит отменять релиз после завершения рабочей версии.
Канареечное развертывание естественным путем заставляет вас вкладываться в автоматизацию инструментов и процессов, если это возможно. Что же касается стандартных стратегий развертывания, здесь все мероприятия по автоматизации сами собой перемещаются в конец списка дел.
4. CI/CD-конвейер и канареечное развертывание
В обычном CI/CD-конвейере изменения автоматически создаются, тестируются и развертываются в промежуточной среде для последующего тестирования перед развертыванием в рабочей среде. Это также хорошо подходи для канареечного развертывания.
После того, как изменения буду развернуты в промежуточной среде и пройдут все необходимые тестирования, конвейер CI/CD автоматически развернет канареечную версию для небольшой группы пользователей в производственной среде.
Если вдруг что-то пойдет не так, вы просто запустите другой конвейер для отката этой версии. Или пометьте проблемные функции, и они никогда больше не попадут в конвейер развертывания. Все происходит автоматически, и вам больше не нужно об этом волноваться.
Так как канареечная версия полна автоматизированных тестов на работоспособность, все они, естественно, добавляются к основным функциям CI/CD-конвейеров. Так или иначе, это неотъемлемая часть любого хорошего CI/CD-конвейера.
5. Процесс и этапы канареечного развёртывания
Обобщив всю информацию, можно сказать, что это самый обычный процесс стандартного канареечного развертывания, который вы можете использовать для своего проекта. Вот он:
#1. Планирование и подготовка
На этом этапе команда разработчиков планирует и готовиться к канареечному развертыванию. Здесь происходит определение изменений и обновлений, которые нужно внести, создание новой версии ПО, а также определение метрик и показателей работоспособности, которые будут использоваться для отслеживания производительности новой версии. Кроме того, команда определяет группу пользователей, которые получат новую версию первыми, и план развертывания.
#2. Переключение трафика и мониторинг
Здесь новая версия ПО развертывается для пользователей, которых команда определила на этапе планирования. Для того, чтобы пользователи могли пользоваться новой версией, часть пользовательского трафика перенаправляется, но при этом старая версия по-прежнему функционирует для остальных пользователей. Новая версия тщательно отслеживается с помощью метрик и проверок работоспособности, проверяется ее производительность и стабильность. Это необходимо, чтобы гарантировать, что она работает так, как надо.
#3. Анализ и оценка производительности
Исходя из метрик и проверок работоспособности, определенных на этапе планирования, анализируется и оценивается производительность версии. Если новая версия работает без нареканий, со временем она дойдет и до всех пользователей. А если есть какие-то проблемы, то развертывание можно быстро откатить к предыдущей версии.
#4. Продвижение или откат развертывания
На этом этапе команда разработчиков принимает решение, продвигать новую версию дальше или откатить ее к предыдущей. Если новая версия работает хорошо и соответствует всем необходимым стандартам качества, она распространяется среди всех пользователей. Если же с новой версией возникли какие-либо проблемы, ее развертывание можно легко и быстро откатить к предыдущей версии.
6. Практические рекомендации и стратегии
Внедряя в свою платформу канареечное развертывание, начните с определения четких целей и того, как должен выглядеть конечный результат. Здесь вы можете конкретизировать такие вещи, как показатели производительности, критерии оценки пользователей и влияние на коммерческую деятельность.
Создайте небольшую группу пользователей, которые будут тестировать новую (канареечную) версию ПО. Большой размер группы на момент начала не дает никакого преимущества. Вам нужно быть как можно более подвижными, особенно в самом начале.
Как мы уже не раз говорили, отслеживайте производительность и стабильность новой версии с помощью метрик и проверок работоспособности. Старайтесь решать проблемы сразу по мере их возникновения. Когда речь идет о постепенном развертывании, то лучше отреагировать на проблему слишком остро, чем недооценить ее.
Распространяйте новую версию среди пользователей постепенно. Так вы обеспечите более плавный переход к новой версии.
По возможности используйте инструменты и процессы автоматизации, чтобы автоматизировать процессы развертывания и мониторинга. Добавьте их в конвейеры CI/CD, и запланированные процессы развертывания будут запускаться автоматически. Таким образом, вы сможете минимизировать человеческий фактор и гарантировать, что процесс развертывания будет согласованным и воспроизводимым.
Внедрите такую вещь, как флаги функций, чтобы иметь возможность включать и исключать определенные функции ПО. Вы сможете контролировать будущие процессы развертывания, и при этом вам не придется постоянно вручную вносить изменения или обновлять. Вы сможете сконцентрироваться на вещах, важных для разработчика, - на исправлении ошибок.
Используйте А/В-тестирование, чтобы сравнивать производительность двух разных версий ПО. Назначьте пользователей этих версий случайным образом, и определите, какая версия работает лучше. Учитывайте это, когда будете принимать решения.
Убедитесь, что вы можете быстро и в любое время выполнить откат развертывания, если вдруг с новой версией возникнут какие-то проблемы. Таким образом, вы сможете смягчить последствия любых проблем и быстро восстановить предыдущую версию ПО.
7. Проблемы и конкретные примеры
У канареечного развертывания есть явные преимущества, но все же существуют некоторые проблемы.
Одна из проблем канареечного развёртывания – это задержка в сети, которая может повлиять на производительность новой версии ПО. Разработчики могут решить эту проблему, прибегнув к помощи таких инструментов, как балансировщик нагрузки и сеть доставки содержимого, чтобы повысить производительность сети. Эта задержка будет влиять не только на внешних пользователей, но и на внутренние процессы, такие как развертывание и выполнение конвейеров CI/CD. Они должны выполняться максимально быстро, а иначе у вас выстроится очередь разработчиков в состоянии простоя, ожидающих завершения работы конвейеров.
Еще одна проблема – обеспечение согласованности данных между старой и новой версиями ПО. Чтобы решить эту проблему и гарантировать согласованность данных во всех версиях, разработчики могут воспользоваться такими методами, как репликация или синхронизация баз данных. Тот факт, что пользователи работают как в старой, так и в новой версиях одновременно, только увеличивают сомнения в том, что обе версии будут всегда полностью синхронизированы, и что пользователи не теряют никаких данных только потому, что находятся в одной из двух групп - Canary или Baseline. Это может оказаться крайне сложным, так что помогите себе, запустив надежные фоновые процессы.
Довольно известный пример – это Netflix. Эта компания использует канареечное развертывание для того, чтобы вносить изменения в свой стриминговый сервис. Чтобы внедрять изменения постепенно, компания использует комбинацию из автоматизированного тестирования, флагов функций и А/В-тестирования.
Еще один пример – Google. Компания использует канареечное тестирования, чтобы внедрять изменения в свои облачные службы. Аналогично, компания пользуется преимуществами автоматизированного тестирования, разделения трафика и приобщения мониторинга, чтобы развертывать изменения шаг за шагом – сначала для небольшой группы пользователей, а затем и для всей базы. С помощью такого подхода компания Google смогла улучшить качество и стабильность своих служб.
Заключение
Как и любой другой процесс, подход или стратегия, канареечное развертывание не является решением всех мировых проблем. Встречаются случаи, когда его практически невозможно реализовать из-за ограничений среды, недостатка знаний или полного отсутствия понятия концепции данной технологии.
Такое развертывание больше всего подходит для проектов нового времени, то есть проектов, где гибкое мышление является незыблемым качеством, автоматизация всех процессов – неоспоримым приоритетом, а максимальный уровень надежности – вполне обоснованным ожиданием заинтересованных лиц.
В таком случае канареечное развертывание в некотором смысле является следующим уровнем гибкой разработки. Оно может поднять команды на тот уровень проектов, где они еще никогда не были.
Каждое приложение проходит разные этапы разработки перед тем как попасть к пользователю. Один из них — деплой (от англ. deploy — развертывание), то есть размещение и запуск приложения на сервере. Это важный этап, который позволяет начать работать с приложением. Давайте разберемся подробнее, как проходит деплой, зачем он нужен и какие этапы включает.
Что такое деплой
Деплой — это не просто «запуск» приложения, как может показаться на первый взгляд. Это целая цепочка действий, которая состоит из подготовки, настройки и проверки работы приложения в реальной среде.
После того как разработчик написал код и протестировал его на своем компьютере, необходимо отправить код на сервер, где он будет доступен пользователям.
Типы деплоя
1. Ручной деплой. На ранних этапах разработки приложение может быть развернуто вручную. Это можно сделать через командную строку или с помощью FTP (File Transfer Protocol). Такой метод подойдет для небольших проектов, но имеет множество рисков, связанных с ошибками, так как все действия выполняются вручную.
2. Автоматический деплой. Гораздо чаще используется автоматический деплой с помощью инструментов непрерывной интеграции и непрерывной доставки (CI/CD) Этот процесс автоматизирует все этапы — от тестирования и сборки кода до его развертывания на сервере. Такой подход помогает избежать ошибки и ускоряет выпуск новых версий.
Зачем нужен деплой
Деплой необходим, чтобы код, написанный разработчиками, стал доступен пользователям. Сайты и приложения не пишутся прямо на сервере — вся работа ведется на локальных компьютерах. Поэтому, когда приложение готово, его нужно перенести на сервер, настроить и запустить.
Без деплоя код так и останется на рабочем компьютере разработчика, и никто, кроме него, не сможет им воспользоваться. Конечно, можно писать код прямо на сервере, но это неудобно, небезопасно и может привести к сбоям.
Кроме того, современные приложения состоят из множества частей, работающих на разных серверах или в облаке. Процесс развертывания должен учитывать все эти нюансы, чтобы приложение корректно работало в продакшене
Что можно деплоить?
Запустить можно не только целое приложение, но и его отдельные компоненты. К примеру, в App Store или Google Play появилась новая версия мобильного приложения. Это деплой. В приложении изменились только иконки — и это тоже считается деплоем! Рассмотрим основные варианты:
1. Веб-приложения и сайты
Самое распространенное — это развертывание веб-приложений и сайтов. Пример: разработчики создали интернет-магазин, и теперь его выкатывают на сервер, чтобы покупатели могли делать заказы.
2. Сервисы, работающие внутри компании
Не все программы и приложения предназначены для широкой аудитории. Многие компании используют внутренние инструменты. Они работают только внутри корпоративной сети и их тоже нужно развернуть, чтобы сотрудники могли ими пользоваться.
3. Отдельные части приложения
В разработке редко выкатывают всю систему сразу. Чаще новые функции разрабатываются по отдельности и деплоятся по мере готовности. Это может быть обновленная система уведомлений, авторизация или оплата. Деплой проходит только для отдельной части, а всё остальное приложение остаётся без изменений.
Кто занимается деплоем?
В больших компаниях за деплой обычно отвечает DevOps-инженер. Его работа не ограничивается только развертыванием приложений — он занимается множеством других задач. Девопсы автоматизируют процесс развертывания, чтобы программистам не приходилось делать всё вручную, настраивают инструменты, ускоряющие выпуск новых версий, работают с серверами и занимаются мониторингом работы системы.
Если проект небольшой, эта задача может лечь на бэкенд-разработчика. Чаще всего это самый опытный специалист, который хорошо знает сервис и умеет управлять его развертыванием. Однако, если деплоем занимаются бэкенд-разработчики, на время развертывания другие их задачи приостанавливаются.
Как выглядит развертывание пошагово
На практике весь процесс проходит в несколько этапов, каждый из которых важен для успешного запуска.
Шаг 1. Подготовка кода
Перед деплоем разработчики пишут код, тестируют его, чтобы понять, что он работает корректно. Если проект большой, код объединяют с работой других программистов в общей системе контроля версий (обычно это Git). На этом этапе также могут использоваться автоматизированные тесты, которые проверяют, нет ли ошибок в коде.
Шаг 2. Сборка приложения
Когда код готов, его нужно собрать в удобный формат для развертывания. Это может быть скомпилированный исполняемый файл, контейнер Docker или просто набор файлов, готовых к запуску. Важно, чтобы во время сборки код был оптимизирован, а все зависимости подключены.
Шаг 3. Настройка окружения
Перед тем как запустить приложение, надо подготовить сервер. Устанавливаются необходимые библиотеки, базы данных, веб-серверы, а также настраивается система управления конфигурацией. Если деплой происходит в облаке, разворачиваются виртуальные машины или контейнеры.
Шаг 4. Перенос кода на сервер
На этом этапе приложение загружается на сервер. Это можно сделать вручную или автоматически, если используется система CI/CD. Часто компании стремятся автоматизировать этот процесс, чтобы снизить количество ошибок.
Шаг 5. Запуск и тестирование на сервере
Код размещен на сервере, приложение запускают и проверяют его работу. Здесь важно убедиться, что все работает корректно, соединяется с базой данных и выполняет функции без сбоев. Если есть ошибки, их исправляют до того, как пользователи увидят обновление.
Шаг 6. Переключение пользователей на новую версию
Если приложение работало раньше, его обновляют так, чтобы пользователи могли им пользоваться и не заметили проблем. В этом случае применяются техники плавного обновления, например, blue-green deployment (одна версия работает, пока тестируется новая) или canary release (обновление получает сначала небольшая группа пользователей, а затем все остальные).
Шаг 7. Мониторинг и устранение возможных ошибок
Даже если всё протестировано и отлично работает, после деплоя важно следить за приложением. Системы мониторинга отслеживают ошибки, нагрузку на сервер и время отклика. Если что-то идет не так, разработчики могут быстро откатить изменения или исправить проблемы.
Какие инструменты понадобятся
Docker. С его помощью можно упаковать приложение и все его зависимости в контейнер. Это упрощает развертывание на разных серверах, так как контейнер работает одинаково в любой среде.
Kubernetes. Это система оркестрации, которая управляет контейнерами (например, Docker) и помогает автоматизировать их развертывание и масштабирование.
Jenkins и GitLab CI пригодятся для автоматической сборки, тестирования и деплоя. Они подключаются к репозиторию с кодом и могут автоматически запускать деплой каждый раз, когда разработчик вносит изменения.
Начиная с 2013 года по планете Земля начали свое победное шествие программы шифровальщики, требующие выкуп. Начал этот злостный хайп шифровальщик Cryptolocker, а затем были слышны такие громкие имена как Petya, NotPetya, WannaCry и иже с ними.
Мы хотели бы показать и объяснить механизмы работы подобного вида зловредного ПО, так как первичный источник заражения в организации обычно одинаковый и являет собой спам письмо – ниже, в последовательных шагах объясним, как, почему и зачем ОНО это делает.
Само заражение, подробно и без приукрас.
Конечный пользователь получает письмо как-будто бы от его начальника, в котором находится ссылка на популярный облачный сервис - Битрикс24, Salesforce, ZenDesk и так далее.
По ссылке открывается окно браузера и направляет пользователя на сайт, который выглядит вполне нормально и являет собой лэндинг для эксплойт кита.
До загрузки страницы, веб-сервер, на котором находится эксплойт-кит, начинает коммуникацию с компьютером жертвы и пытается понять какая версия Java используется для использования эксплойта в уязвимой версии.
Когда кто получает подтверждение уязвимости конкретной версии, эксплойт начинает свою работу и, в случае успеха, он загружает на рабочую станцию некий .EXE файл, и он начинает выполняться.
Экзешник создаёт дочерний процессы, который включает в себя процесс vssadmin.exe (теневую копию). Данный процесс удаляет имеющиеся теневые копии на компьютере жертвы и создаёт новые. Теневые копии, создаваемые самой ОС Windows, позволяют восстановить информацию - и поэтому WannaCry всеми силами пытается снизить вероятность восстановления файлов.
Далее WannaCry использует исполняемый PowerShell файл для распространения своих копий по системе и запускает шифрование файлов с определенными расширениями.
Дочерний процесс powershell.exe создает ещё три копии оригинального зловредного кода - сначала в директории AppData, затем в Start и в корневом каталоге диска C: . Данные копии используются совместно с модификациями регистра для автоматического перезапуска WannaCry после перезагрузки системы и различных событий.
После шифрования файлов на компьютере, малварь отправляет ключ шифрования и другую информацию в командный центр (C2).
Далее жертва получает сообщение, причем это может быть как банальное информирование пользователя о шифровке файлов и инструкций о передаче выкупа, так и установке другого зловредного ПО, например для кражи учётных данных.
Как правило, для усиления эффекта, на экране компьютера появляется таймер обратного отсчёта с указанием дедлайна, когда нужно отправить выкуп. Если не отправить вовремя, ключ для расшифровки будет уничтожен - то есть больше не останется шансов на восстановление вашей информации.
Обычно, оплата выкупа означает то, что вам пришлют ключ для расшифровки - но это совершенно точно не означает, что сам зловредный файл тоже удалится с машины жертвы. Обычно, в таких случаях нужно привлечь вашу службу ИБ или ИТ.
И, как уже было сказано выше, очень часто шифровальщики используются как некая маскировка более глубокой атаки на организацию - то есть кража учётных записей, персональных данных и прочие.
Наш посыл прост – не открывайте подозрительных ссылок! Особенно, если они пришли по электронной почте от людей, от которых не должно подобное приходить – руководитель компании и так далее. Старайтесь более ответственно относится к времяпрепровождению в Интернете, и тогда ИТ-службе (а это скорее всего вы и есть) будет гораздо спокойнее жить.