Всем привет! В сегодняшние нестабильные времена бизнес сталкивается с целым рядом рисков, от политических санкций до стихийных бедствий, что в свою очередь влияет и на работу IT-отрасли (например, об импортозамещении в сфере информационных технологий сейчас задумываются все, кто хоть сколько-нибудь озабочен будущим своих продуктов). А поскольку IT-команды всё больше полагаются на облачную инфраструктуру для закрытия своих потребностей, её безопасность и доступность становятся приоритетными задачами. Даже с учетом событий последнего года, остается достаточно много компаний, которые продолжают держать свою инфраструктуру в зарубежных облаках. Однако такая зависимость сопряжена с потенциальными проблемами и неопределенностью. Что произойдет, если доступ к вашему текущему облачному провайдеру внезапно прервется? Что если вам потребуется быстро перейти к другому облачному провайдеру из-за правительственных санкций или других геополитических факторов? С другой стороны, каждый кризис – это время возможностей. Как не прозевать момент, когда можно захватить свою долю зарубежного рынка (имея, конечно, все необходимое в рукаве – зарубежные счета, продукт, который востребован на этом рынке и т.д.)? В этой статье мы постараемся дать ответы на вышеуказанные вопросы, объяснить важность подхода «мер на упреждение» – создания базы для дублирования своей облачной инфраструктуры, рассказать про основные составляющие этого подхода и выгоды, которые он может принести. Прежде чем начать, приглашаю вас подписаться на наш блог Хабр, TG-канал DevOps FM и познакомиться с YouTube — мы всегда рады новым друзьям :) Поскольку диапазон возможностей IT-команды напрямую зависит от бюджета, который выделяется бизнесом, давайте сначала разберем данный вопрос с точки зрения руководителей компаний. Далее будут озвучены пункты актуальные для бизнесов, которые пользуются услугами зарубежных облаков для размещения инфраструктуры. Что? Дублирование? Зачем нам тратить на это деньги? Одним из наиболее значительных рисков, связанных с отсутствием возможности быстрого дублирования своей инфраструктуры (в случае возникновения проблем с основной), является длительный простой, т.е. ваш продукт не продается и не используется на неопределенно долгой дистанции. Причины такого простоя могут быть разные: уменьшение и без того скудных вариантов оплаты облачных услуг и дальнейшее их отключение, прекращение доступа как следствие принципиальной позиции руководства облака по отношению к пользователям определенных стран и др. Простой неизбежно приводит к потере прибыли и влечет за собой значительные расходы, которые могут нанести удар по финансовому состоянию компании. Репутационные потери также являются серьезной проблемой. Текущие клиенты могут потерять доверие к продукту или услуге, что приведет к оттоку лояльной части пользователей, а новые потенциальные клиенты могут пройти мимо, восприняв компанию как ненадежную. В итоге, когда и если вы восстановите свою инфраструктуру, клиентскую базу придется нарабатывать заново, а то и вовсе проводить ребрендинг. Хорошо, возможно, такие риски действительно есть, но проблемы решаемы, зачем нам избыточные траты сейчас? Время — это деньги, верно? Так вот, случись подобная ситуация, времени будет потрачено много, например: Так что советуем трезво оценить «избыточные траты сейчас» и «необходимые траты потом». Мы держим нашу инфраструктуру в местном облаке. Получается, для нас данный подход неактуален? Если ваш продукт находится на этапе роста или на этапе зрелости и чувствует себя более чем уверенно, вы можете использовать данный подход чтобы быстро занять место на новом рынке, расширить свою зону влияния, опередив конкурентов. И этот пункт относится уже ко всем, независимо от того, в зарубежном облаке ваша инфраструктура или нет. А также не стоит забывать, что в кризис случается всякое, и ваш местный облачный провайдер может просто его не пережить / отказаться от части предоставляемых услуг, критически необходимых вашему продукту / повысить цену так, что она перестанет вас устраивать, и необходимо будет куда-то мигрировать. Тут-то и пригодятся ваши предусмотрительно заготовленные наработки. Теперь предлагаем рассмотреть эти ситуации с точки зрения IT-команды. Я разработчик / админ / devops, что и как поменяется для меня? Проблемы озвучены, последствия тоже. Теперь надо обсудить, как всего этого избежать и чувствовать себя уверенно. Если вы с чем-то не согласны или хотите дополнить – пишите свои мысли в комментариях. 1. Выберите подходящее облако в качестве альтернативы.  На что необходимо обратить внимание: Если у вас есть необходимость быстро и безопасно переехать в российское облако, компания Nixys может с этим помочь. А если хотите при этом еще и максимально сократить расходы, есть вариант переезда под ключ в облако TimeWeb с приятной скидкой! 2. Опишите свою инфраструктуру как код (Infrastructure as Code). Такой подход имеет ряд существенных преимуществ: Какие инструменты можно использовать? Традиционно существует два подхода к IaC, декларативный и императивный. В качестве примеров рассмотрим Terraform и Ansible — это два инструмента для управления инфраструктурой в виде кода, у которых есть свои отличительные особенности. Особенности Terraform: Особенности Ansible: Для каких целей использовать Terraform, а для каких Ansible? Terraform обычно используется для управления ресурсами облачных провайдеров, т.е. создание и изменение ВМ, сети, экземпляров managed-сервисов и т.п. Ansible же может использоваться для настройки и управления уже созданными серверами и приложениями на них.  Универсально ли это? Terraform работает с API облака через провайдер, и описание ресурсов у различных провайдеров отличается. Но! Описав компоненты инфраструктуры для текущего облака и выбрав альтернативное (с нужными сервисами и для которого есть провайдер Terraform) – корректировка конфигурационных файлов не составит труда!  Давайте рассмотрим пару примеров, как будут отличаться модули на примере Google Cloud и Yandex Cloud. High Availability Redis: Google Cloud Yandex Cloud Далее в примерах блоки backend, required_providers и описание провайдера опустим, т.к. они меняться не будут (будьте внимательны с указанием версии провайдера – от этого зависит описание сущностей). Правило firewall: Google Cloud Yandex Cloud Группа нод кластера Kubernetes: Google Cloud Yandex Cloud Как видим, параметры интуитивно понятны и большинство из них легко сопоставимы у разных провайдеров, поэтому переход с одного облако на другое хоть и займет какое-то время, все же оно не будет продолжительным. Также следует учитывать, что различаться будут только специфические для облака ресурсы, а, например, модули для развертывания приложения в кластер k8s будут полностью одинаковы. Что касается Ansible – здесь можно говорить о полной универсальности, если ОС и дистрибутив полностью совпадают. Я не могу пользоваться Terraform в РФ:( Да, к сожалению, HashiCorp присоединилась к санкциям и запретила доступ к своим продуктам пользователям из РФ. Однако выход есть – у некоторых облаков (Yandex, VK, Croc) есть свои зеркала, откуда вы можете скачать дистрибутив инструмента и установить необходимые провайдеры. 3. Настройте сбор и хранение бэкапов в альтернативном хранилище (помимо текущего облачного). Как можно заметить, к инфраструктуре это отношения не имеет, однако в контексте утраты доступа к текущему облаку не сказать об этом нельзя. В подобной ситуации бэкапы, хранящиеся где-то вовне, станут ключевым ресурсом для восстановления утраченных данных. Если текущие бэкапы снимаются средствами своего облака и хранятся там же, то для задействования дополнительного хранилища встает вопрос выбора инструмента сбора, доставки и управления резервными копиями, к которому нужно подойти со всей ответственностью. В нашей компании мы пользуемся собственной разработкой – nxs-backup. Недавно релизнулась новая версия, про нее мы рассказали здесь. 4. Если вы используете контейнеризацию и пользуетесь образами из публичных хранилищ, перенесите их в личный хаб и старайтесь поддерживать актуальные версии. Хранение публичных docker-образов в личном хабе может быть критически важным в случае блокировки, удаления или утраты доступа к публичным хранилищам, таким как Docker Hub или Quay.io. Это может произойти, например, из-за изменения правил использования сервиса. Одним из инструментов, позволяющих хранить образы в личном хабе, является Harbor. Это инструмент с открытым исходным кодом для управления контейнерными образами и helm-чартами. Harbor предоставляет возможность создавать и управлять личными репозиториями на основе ролевой модели доступа, сканировать образы на уязвимости и др. 5. Опишите ваши приложения как код. Если ваши приложения запущены в Kubernetes – создайте для них helm-чарты. Они облегчат и ускорят деплой в новый кластер, позволят быстро обновлять и откатывать приложения, что особенно полезно в условиях тестирования работы приложений в новой инфраструктуре.
Для этих целей мы также разработали собственный универсальный helm-чарт. Подробнее про его использование на проектах писали здесь. Если вы уже используете helm-чарты для деплоя каких-либо сторонних сервисов, позаботьтесь об их локальных дубликатах в собственных репозиториях, т.к. мейнтейнеры могут удалить исходники, либо доступ будет закрыт (например, старые чарты bitnami более недоступны, т.к. были удалены). В случае, когда вы просто запускаете приложения в Docker – опишите их в docker-compose файлах. 6. Создайте отдельную ветку в вашем git-репозитории с написанным CI/CD-пайплайном для альтернативного облака и не забывайте поддерживать её в актуальном состоянии. Переход с одного облачного провайдера на другой влияет на конфигурацию инфраструктуры, поэтому необходимо проанализировать настройки текущего CI/CD- пайплайна и внести необходимые корректировки. Ниже приведены некоторые из возможных изменений, которые могут потребоваться при смене облака: Задокументируйте необходимые изменения в ReadMe. Таким образом, на работу разработчиков смена облака не повлияет, а значит и временные затраты на доставку и тестирование изменений продукта будут меньше. Давайте подытожим, какие преимущества получает от такого подхода бизнес и, в частности, его IT-команда в случае утраты доступа к своей текущей инфраструктуре. Бизнес: Бонусом открываются дополнительные возможности для расширения своей зоны влияния на зарубежных рынках. IT-команда: В этой статье мы говорили о плюсах подхода заблаговременного дублирования инфраструктуры, но стоит упомянуть и цену, которую придется заплатить: Для принятия решения компания должна поставить на одну чашу весов издержки мер на упреждение, на другую – риски от утраты контроля над текущими облачными ресурсами, и определиться, готовиться ли к худшему или плыть по течению, надеясь на лучшее… Будет ли актуален этот вопрос в обозримом будущем? Кто знает, но есть подозрение, что да. К сожалению, предпосылок к улучшению ситуации пока нет. Однако считаем необходимым отметить, что перечисленные меры разумно принимать не только в кризис, но и в обычной повседневной работе, это здорово облегчает жизнь всем сотрудникам и сохраняет нервы (и деньги) бизнесу. Спасибо за прочтение, берегите свою инфраструктуру! DevOps-инженер