По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В этой заключительной статье о перераспределении маршрутов мы проверим работу Route redistribution с помощью IPv6 и увидим небольшое отличие в настройке routes redistributed IPv6 от routes redistributed IPv4.
Предыдущие статьи из цикла:
Часть 1. Перераспределение маршрутов (Route redistribution)
Часть 2. Фильтрация маршрутов с помощью карт маршрутов
Часть 3. Перераспределение маршрутов между автономными системами (AS)
Перераспределение подключенных сетей
Во-первых, рассмотрим маршрутизатор, выполняющий маршрутизацию, предположим, что используется протокол OSPF. Кроме того, предположим, что маршрутизатор имеет несколько интерфейсов, которые участвуют в маршрутизации OSPF. Представьте, что на этом же маршрутизаторе мы запускаем другой протокол маршрутизации (скажем, EIGRP), и мы делаем взаимное перераспределение маршрутов.
Вот что удивительно. Если мы делаем перераспределение маршрута на этом маршрутизаторе, сети IPv4, связанные с интерфейсами этого маршрутизатора, участвующими в OSPF в нашем примере, будут перераспределены в EIGRP. Однако сети IPv6, будут вести себя по-другому. В частности, в сетях IPv6 мы должны ввести дополнительный параметр в нашу конфигурацию перераспределения маршрутов, явно указывая, что мы хотим перераспределить подключенные сети. В противном случае эти маршруты IPv6, связанные с непосредственно с подключенными интерфейсами, не перераспределяются.
Логика такого поведения вытекает из понимания того, что для перераспределения маршрута данный маршрут должен появиться в таблице IP-маршрутизации маршрутизатора. Конечно, когда посмотрим таблицу IP-маршрутизации маршрутизатора и увидим непосредственно подключенные сети, эти сети отображаются как подключенные сети, а не сети, которые были изучены с помощью определенного протокола маршрутизации.
В то время как route redistribution для IPv4 понимает, что сеть напрямую подключена, но участвует в процессе маршрутизации и поэтому будет перераспределена, route redistribution для IPv6 не делает такого предположения. В частности, если мы перераспределяем сети IPv6 из одного протокола маршрутизации в другой, эти сети должны отображаться в таблице маршрутизации IPv6 маршрутизатора вместе с указанием, что они были изучены с помощью перераспределяемого протокола маршрутизации. Конечно, мы можем добавить дополнительный параметр к нашей команде redistribute, чтобы заставить эти непосредственно подключенные сети IPv6 (участвующие в распространяемом протоколе) также быть перераспределенными. Эта настройка будет продемонстрирована немного позже.
Перераспределение в OSPF
В прошлой статье мы обсуждали потенциальную проблему, с которой вы можете столкнуться при распространении в OSPF (в зависимости от вашей версии Cisco IOS). Проблема была связана с подсетями. В частности, по умолчанию в более старых версиях Cisco IOS OSPF только перераспределяет классовые сети в OSPF, если мы не добавим параметр subnets к команде redistribute. Добавление этого параметра позволило перераспределить сети в OSPF, даже если у них не было классовой маски. Пожалуйста, имейте в виду, что последние версии Cisco IOS автоматически добавляют параметр подсети, не требуя от вас ручного ввода.
Однако параметр подсети в IPv6 route redistribution отсутствует. Причина в том, что IPv6 не имеет понятия о подсетях.
Пример route redistribution IPv6
Чтобы продемонстрировать перераспределение маршрутов IPv6, рассмотрим следующую топологию:
Протоколы маршрутизации OSPFv3 и EIGRP для IPv6 уже были настроены на всех маршрутизаторах. Теперь давайте перейдем к маршрутизатору CENTR и настроим взаимное route redistribution между этими двумя автономными системами. Убедимся в этом, проверив таблицу маршрутизации IPv6 маршрутизатора CENTR.
Приведенные выше выходные данные показывают, что мы изучили две сети IPv6 через OSPF, две сети IPv6 через EIGRP, а CENTR напрямую подключен к двум сетям IPv6. Далее, давайте настроим взаимное перераспределение маршрутов между OSPFv3 и EIGRP для IPv6.
CENTR # conf term
Enter configuration commands, one per line. End with CNTL/Z.
CENTR (config)# ipv6 router eigrp 1
CENTR (config-rtr) # redistribute ospf 1 metric 1000000 2 255 1 1500?
include-connected Include connected
match Redistribution of OSPF routes
route-map Route map reference
cr
CENTR (config-rtr) #redistribute ospf 1 metric 1000000 2 255 1 1500 include-connected
CENTR (config-rtr) #exit
CENTR (config) # ipv6 router ospf 1
CENTR (config-rtr) #redistribute eigrp 1?
include-connected Include connected
metric Metric f or redistributed routes
metric-type OSPF/IS-IS exterior metric type for redistributed routes
nssa-only Limit redistributed routes to NSSA areas
route-map Route map reference
tag Set tag for routes redistributed into OSPF
cr
CENTR (config-rtr) #redistribute eigrp 1 include-connected
CENTR (config-rtr) #end
CENTR#
Обратите внимание, что конфигурация взаимного перераспределения маршрутов, используемая для маршрутов IPv6, почти идентична нашей предыдущей конфигурации для перераспределения маршрутов IPv4. Однако для обеих команд перераспределения был указан параметр include-connected. Это позволило маршрутизатору CENTR перераспределить сеть 2003::/64 (непосредственно подключенную к интерфейсу Gig0/1 маршрутизатора CENTR и участвующую в OSPF) в EIGRP. Это также позволило маршрутизатору CENTR перераспределить сеть 2004::/64 (непосредственно подключенную к интерфейсу Gig0/2 маршрутизатора CENTR и участвующую в EIGRP) в OSPF.
Чтобы убедиться, что наша конфигурация рабочая, давайте перейдем на оба маршрутизатора OFF1 и OFF2, убедившись, что каждый из них знает, как достичь всех шести сетей IPv6 в нашей топологии.
Вышеприведенные выходные данные подтверждают, что маршрутизаторы OFF1 и OFF2 знают о своих трех непосредственно связанных маршрутах и трех маршрутах, перераспределенных в процессе маршрутизации. Итак, как мы видим, что когда речь заходит о routes redistributed IPv6, то не так уж много нового нужно узнать по сравнению с routes redistributed IPv4.
Проксирование HTTP и FTP запросов от клиента осуществляется proxy-сервером по средствам сохранения копии (кэширования) запрашиваемых клиентом данных из Интернета на системе, которая расположена ближе к получателю и последующей передачи кэшированных данных получателю с более низкой задержкой. Это может быть страничка сайта, которая расположена на определённом URL'e, например - http://shareit.merionet.ru или же какой-нибудь файл, который лежит на FTP сервере.
Введение
Роутеры MikroTik способны выполнять следующие функции в качестве web-proxy сервера:
Стандартное проксирование HTTP. Когда пользователь сам указывает кто является для него proxy-сервером и настраивает браузер соответствующим образом;
Прозрачное проксирование. Когда пользователь не знает, что его запросы перенаправляются через proxy-сервер;
Настройка списка доступа по адресу источника, назначения, URL и методу передачи запросов (GET, POST др.);
Список кэшируемых объектов. Определяет какие копии каких ресурсов сохранять, а какие нет;
Прямой список доступа. Определяет какие ресурсы доступны без проксирования и для каких нужен proxy-сервер;
Логирование событий и операций proxy-сервера
Поддержка родительских proxy-серверов. В этом случае указывается дополнительный сервер и запрос направляется к нему, если первый сервер не имеет доступа к запрашиваемому объекту.
Proxy-сервер располагается между клиентом и конечным сервером с ресурсом, к которому клиент хочет получить доступ.
Web-proxy сервер случает запросы от клиентов и сохраняет ответы у себя в памяти. Если он получит запрос, содержащий тот же URL, то он может просто отправить имеющуюся копию. Если же копии нет, то он запрашивает её у конечного сервера. То же самое с файлами, если есть сохранённая копия файла, он отправит её клиенту, если нет - скачает с FTP сервера.
Есть несколько целей применения proxy-сервера:
Ускорение получения доступа к ресурсам, которые физически находятся дальше от получателя (большая задержка при передаче пакетов);
Использование в качестве HTTP Firewall'а. Блокирование доступа к нежелательным ресурсам;
Фильтрование web-контента по заданным параметрам, например IP-адрес источника, IP-адрес назначения и порт, URL ресурса, метод HTTP запросов;
Сканирование передаваемого из внутренней сети контента, например, для предотвращения утечек. При этом совсем не обязательно использовать функции кэширования на web-proxy.
Настройка стандартного web-proxy
В роутерах MikroTik, настрока web-proxy через терминал происходит через команду:
/ip proxy set
Ниже приведен список параметров доступных для настройки:
enabled - активирует функционал web-proxy. (yes - включен, no - выключен);
src-address - устанавливает IP-адрес proxy-сервера;
port - задаёт порт, на котором будет работать proxy-сервер;
parent-proxy - задаёт адрес родительского proxy-сервера;
cache-drive - указывает куда складывать кэшируеемых данные.
cache-administrator - email администратора, который будет показан на странице с ошибкой;
max-cache-size - указывает максимальный объём для хранения кэшируемых данных на диске в килобайтах (в случае использования внешнего диска);
max-ram-cache-size - указывает максимальный объём для хранения кэшируемых данных в RAM роутера в килобайтах;
cache-only-on-disk - указывает создавать ли внутреннюю базу данных, описывающую кэшируемый на диске контент. Может сократить потребление памяти, но повлиять на скорость;
maximal-client-connections - максимальное число подключений к proxy-серверу от клиентов. Подключения сверх указанного здесь количества будут отклоняться;
maximal-server-connections - максимальное число подключений к серверам. Подключения от клиентов к другим серверам сверх указанного здесь количества будут находиться в режиме ожидания, пока некоторые текущие подключения не завершатся ;
max-fresh-time - максимальный срок хранения кэшируемого контента;
Настроим стандартный proxy-сервер на адресе 192.168.11.1, для этого через терминал вводим команду:
ip proxy> set enabled=yes port=8080 src-address=192.168.11.1
Для настройки через Winbox открываем IP → Web Proxy ставим галочку напротив Enabled, указываем IP адрес и порт, на котором будет работать наш proxy-сервер, кстати, тут же настраивается родительский прокси в разделе Parent proxy.
При настройке обычного функционала web-proxy, должна быть также выполнена настройка на стороне клиента (браузера) и указан сервер, который выступает в качестве proxy. Для настройки в Google Chrome нужно открыть Settings → Advanced → Confidentiality and Security, крутим в самый низ до пункта System и выбираем Proxy settings. В появившемся окне выбираем LAN settings → ставим галку напротив Use a proxy server for your LAN и заходим в Advanced. В появившемся окне вбиваем параметры нашего proxy-сервера в строку HTTP (в нашем случае 192.168.11.1 и порт 8080) и применяем настройки:
Настройка прозрачного проксирования
Прозрачное проксирование не требует дополнительных настроек на стороне клиентов. Более того, пользователи даже не будут подозревать, что их запросы направляются через proxy-сервер.
Чтобы настроить прозрачное проксирование, необходимо добавить NAT’ирующее правило в Firewall, которое будет определять какие HTTP запросы будут проходить через локальный proxy. Ниже показан пример того, как можно проксировать все запросы пользователей из сети 192.168.11.0/24
ip firewall nat> add chain=dstnat protocol=tcp src-address=192.168.11.0/24
dst-port=80 action=redirect to-ports=8080
Списки доступа или использование Firewall’а на основе proxy
Пожалуй, этот функционал понравится вам больше всего :)
Список доступа работает здесь также, как и в правилах Firewall – сначала читаются самые приоритетные правила, затем, вниз по списку - менее приоритетные. Критерием для применения правил может быть совпадение таких параметров как: адрес источника, порт источника, адрес назначения, порт назначения, запрашиваемый URL или HTTP метод (POST, GET и др.)
В случае совпадения критериев, заданных в правиле и параметров подключения, такое подключение может быть разрешено (allow) или запрещено (deny). Если параметры подключения не подпадают ни под один из критериев правил, то оно по умолчанию разрешается.
Понятно, что использование правил должно применяться вместе с настройками прозрачного проксирования, которые мы рассматривали выше. Итак, допустим мы настроили прозрачное проксирование для сети 192.168.11.0/24 и пустили все HTTP запросы из этой подсети через наш прокси сервер.
ip firewall nat> add chain=dstnat protocol=tcp src-address=192.168.11.0/24
dst-port=80 action=redirect to-ports=8080
Что если мы теперь хотим запретить пользователям в данной подсети сидеть во всеми любимом вконтактике? Очень просто – настроим список доступа. Для этого:
/ip proxy access add src-address=192.168.1.0/24 dst-host=www.vk.com action=deny
Мы также можем заблокировать web-сайты, которые содержат какое-либо ключевое слово или часть слова в названии, например:
/ip proxy access add src-address=192.168.1.0/24 dst-host=:er action=deny
И гуд-бай - Tinder.com, Twitter.com, Viber.com, ну вы поняли :)
Мы даже можем запретить скачивание определённых файлов:
/ip proxy access add src-address=192.168.1.0/24
add path=*.pdf action=deny
add path=*.png action=deny
add path=*.docx action=deny
add path=*.mp3 action=deny
add path=*.zip action=deny
add path=*.rar action=deny
Стоит отдельно рассказать про маски (wildcard), которые позволяют настроить более тонкое соответствие проверяемых URL’лов и других названий.
В dst-host и dst-path можно указывать следующие маски - * - любое количество символов. Например - *ings.docx будет искать .docx файлы, названия которых оканчиваются на ins или же просто файл ings.docx, то есть сюда подходят такие названия файлов – paintings.docx, wings.docx – перед ings может стоять любое количество символов.
Если поставить маску ?, то поиск будет осуществляться по количеству символов. Например маска ??ings.docx найдёт файл wnings.docx, но не найдёт paintings.docx, потому что маска задана на 2 символа.
Также поддерживаются регулярные выражения, но если вы собираетесь их использовать, то перед этим обязательно нужно поставить двоеточие :.
Канареечное (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 смогла улучшить качество и стабильность своих служб.
Заключение
Как и любой другой процесс, подход или стратегия, канареечное развертывание не является решением всех мировых проблем. Встречаются случаи, когда его практически невозможно реализовать из-за ограничений среды, недостатка знаний или полного отсутствия понятия концепции данной технологии.
Такое развертывание больше всего подходит для проектов нового времени, то есть проектов, где гибкое мышление является незыблемым качеством, автоматизация всех процессов – неоспоримым приоритетом, а максимальный уровень надежности – вполне обоснованным ожиданием заинтересованных лиц.
В таком случае канареечное развертывание в некотором смысле является следующим уровнем гибкой разработки. Оно может поднять команды на тот уровень проектов, где они еще никогда не были.