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

Всем привет!

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

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

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

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

Прежде чем начать, приглашаю вас подписаться на наш блог Хабр, TG-канал DevOps FM и познакомиться с YouTube — мы всегда рады новым друзьям :)

Часть 1: зачем вообще всё это надо?

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

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

Что? Дублирование? Зачем нам тратить на это деньги?

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

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

Хорошо, возможно, такие риски действительно есть, но проблемы решаемы, зачем нам избыточные траты сейчас?

Время — это деньги, верно? Так вот, случись подобная ситуация, времени будет потрачено много, например:

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

Так что советуем трезво оценить «избыточные траты сейчас» и «необходимые траты потом».

Мы держим нашу инфраструктуру в местном облаке. Получается, для нас данный подход неактуален?

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

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

Теперь предлагаем рассмотреть эти ситуации с точки зрения IT-команды.

Я разработчик / админ / devops, что и как поменяется для меня?

• Изменение всех процессов. Скорее всего, ваша зона ответственности существенно расширится. При отсутствии четко отлаженного disaster recovery плана, всем придется быстро адаптироваться и делать что-то «сверх» компетенций и/или рабочего времени.
• Отсутствие необходимых знаний при работе с новым облаком — еще одна потенциальная (в случае, если руководство откажется от привлечения экспертов со стороны) проблема. Придется в сжатые сроки изучать функционал и особенности нового облачного провайдера, что может привести к ошибкам, в том числе долгоиграющим (надо будет в дальнейшем переделывать что-то на базовом уровне).
• Ручное поднятие и настройка инфраструктуры и сопутствующие проблемы:
  — процесс настройки инфраструктуры может быть сложным и требовать знаний нюансов работы того или иного облака. Если специалиста с нужными знаниями нет в штате компании, на изучение документации на должном уровне потребуется много времени. Правда может оказаться, что документация облака просто не раскрывает необходимые вопросы;
  — если ваша инфраструктура плохо документирована, а изначально настраивали ее Петя и Вася, которые уволились 3 года назад, потребуется некоторое количество времени, чтобы разобраться и воспроизвести ее корректно в новом облаке;
  — человеческий фактор. В условиях стресса, переработок, давления со стороны руководства шанс допустить ошибку возрастает.
• Адаптация приложений. Некоторые сервисы, доступные в зарубежном облаке, могут не иметь аналогов в местном облаке, поэтому потребуется изменить свои приложения или найти подходящие альтернативы, а это время и «костыли», которые могут аукнуться в дальнейшем.
• Проблемы интеграции с существующими системами и приложениями. Они могут быть несовместимы или недоступны для ваших приложений в новой облачной инфраструктуре, для решения потребуется время. К тому же решение может оказаться «костыльным» со всеми вытекающими из этого последствиями.
• Потеря данных. Неполное резервное копирование или полное его отсутствие (?!) и хранение бэкапов только в текущем облаке – такая комбинация «непростительных» ошибок может привести к потере критически важных данных, которая может дорого стоить или даже оказаться разрушительной для бизнеса. Это также может повлиять на репутацию компании и подорвать доверие клиентов.
• Изменение CI/CD процессов. Ничего нового, всё те же временные затраты и пресловутые «костыли».

Часть 2: что можно сделать?

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

1. Выберите подходящее облако в качестве альтернативы.

На что необходимо обратить внимание:

• наличие нескольких зон доступности;
• наличие необходимых managed-сервисов, их версии, особенности. Чтобы было понятно, о каких особенностях речь, приведем пример: в Google Cloud у Memorystore for Redis отказоустойчивость реализована в виде реплик (с опцией чтения или без нее) + автоматический failover. Если говорить про Yandex Cloud, то high availability там в виде системы Redis Sentinel или Redis Cluster;
• наличие сервисов безопасности – Anti-DDoS и т.п.;
• наличие необходимых дистрибутивов ОС;
• наличие Terraform-провайдеров (об этом поговорим позже);
• наличие развернутой документации со ссылками на официальную документацию используемых сервисов;
• варианты тарифов поддержки;
• надежность (учитываем мнение коллег («сарафанка», профильные сайты/форумы), обращаем внимание на страничку с клиентами и партнерами облака);
• соответствие местным нормам защиты данных (если речь про РФ, то соответствие 152-ФЗ, ГОСТ Р);
• стоимость услуг, варианты оплаты, наличие дисконтов и скидок.

Если у вас есть необходимость быстро и безопасно переехать в российское облако, компания Nixys может с этим помочь. А если хотите при этом еще и максимально сократить расходы, есть вариант переезда под ключ в облако TimeWeb с приятной скидкой!

2. Опишите свою инфраструктуру как код (Infrastructure as Code).

Такой подход имеет ряд существенных преимуществ:

• вы сможете быстро и автоматически создать инфраструктуру в новом облаке, протестировать и при необходимости все так же быстро и автоматизированно внести изменения или временно удалить ресуры в целях избежания переплат;
• процесс развертывания одинаков и повторяем для любого компонента инфраструктуры: создаете ли вы сеть или виртуальную машину – порядок действий и команды не меняются;
• конфигурация инфраструктуры версионируется, что упрощает управление: всегда можно отследить, в какой момент что-то пошло не так и быстро откатиться (конечно, необходимо при этом не забывать фиксировать ваши изменения, это важно);
• стандартизация позволяет членам команды работать с инфраструктурой быстрее и эффективнее, и в совокупности с версионированием поможет избежать последствий от увольнения гениев инженерной мысли Пети и Васи из примера выше;
• процессы изменения инфраструктуры можно удобно встраивать в CI/CD-пайплайны: никаких адовых скриптов на bash’е, только элегантное применение новых конфигов одной командой.

Какие инструменты можно использовать?

Традиционно существует два подхода к IaC, декларативный и императивный.

В качестве примеров рассмотрим Terraform и Ansible — это два инструмента для управления инфраструктурой в виде кода, у которых есть свои отличительные особенности.

Особенности Terraform:

• предоставляет декларативный язык для определения инфраструктуры, который позволяет описать желаемое состояние инфраструктуры без необходимости задавать конкретные шаги для ее настройки;
• поддерживает широкий диапазон провайдеров, включая AWS, Google Cloud, Microsoft Azure, Yandex Cloud, Selectel и другие, что позволяет использовать один и тот же язык для управления инфраструктурой в различных облачных окружениях;
• поддерживает планирование изменений инфраструктуры, что позволяет убедиться в том, что изменения будут безопасными и не приведут к нежелательным результатам;
• предоставляет возможность оперировать модулями (логическими абстракциями поверх некоторого набора ресурсов), что упрощает и стандартизирует процесс определения инфраструктуры.

Особенности Ansible:

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

Для каких целей использовать Terraform, а для каких Ansible?

Terraform обычно используется для управления ресурсами облачных провайдеров, т.е. создание и изменение ВМ, сети, экземпляров managed-сервисов и т.п.

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

Универсально ли это?

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

Давайте рассмотрим пару примеров, как будут отличаться модули на примере Google Cloud и Yandex Cloud.

High Availability Redis:

Google Cloud

terraform {
  backend "gcs" {
    bucket      = "my-project-tf-state"
    prefix      = "terraform/gcp/services/redis-ha/state"
    credentials = "my-project-cred.json"
  }

  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "= 4.58.0"
    }
  }
}

provider "google" {
  credentials = file(var.cred_path)
  project     = var.project
  region      = var.region
}

resource "google_redis_instance" "redis" {
  name               = var.redis_instance_name
  tier               = "STANDARD_HA"
  authorized_network = data.google_compute_network.redis-network.id

  auth_enabled   = "true"
  redis_version  = var.redis_version

  memory_size_gb = var.redis_memory_size

  replica_count           = 2
  location_id             = var.gke_cluster_zone_1
  alternative_location_id = var.gke_cluster_zone_2
}

Yandex Cloud

terraform {
  backend "s3" {
    endpoint                    = "storage.yandexcloud.net"
    bucket                      = "my-project-tf-state"
    region                      = "ru-central1"
    key                         = "redis.tfstate"
    shared_credentials_file     = "storage-cred"

    skip_region_validation      = true
    skip_credentials_validation = true
  }

  required_providers {
    yandex = {
      source  = "yandex-cloud/yandex"
      version = "= 0.88.0"
    }
  }
}

provider "yandex" {
  service_account_key_file = "key.json"
  cloud_id                 = var.cloud_id
  folder_id                = var.folder_id
  zone                     = var.default_zone
}

resource "yandex_mdb_redis_cluster" "redis" {
  name               = var.redis_instance_name
  environment        = "PRODUCTION"
  network_id         = data.yandex_vpc_network.redis.network_id

  config {
    password = random_password.redis_exporter.result
    version  = "6.2"
  }

  resources {
    resource_preset_id = var.instance_type
    disk_size          = var.disk_size
  }

  host {
    zone      = data.yandex_vpc_subnet.redis.zone1
    subnet_id = data.yandex_vpc_subnet.redis.subnet_id
  }

  host {
    zone      = data.yandex_vpc_subnet.redis.zone2
    subnet_id = data.yandex_vpc_subnet.redis.subnet_id
  }

  host {
    zone      = data.yandex_vpc_subnet.redis.zone3
    subnet_id = data.yandex_vpc_subnet.redis.subnet_id
  }
}

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

Правило firewall:

Google Cloud

resource "google_compute_firewall" "openvpn-firewall" {
  name    = "openvpn-firewall-external"
  network = module.vpc_myvpc.network_self_link

  allow {
    protocol = "udp"
    ports    = ["1194"]
  }

  target_tags   = ["openvpn"]

  source_ranges = ["0.0.0.0/0"]
}

Yandex Cloud

resource "yandex_vpc_security_group" " openvpn-firewall " {
  name       = "openvpn-firewall-external"
  network_id = yandex_vpc_network.myvpc.id

  ingress {
    protocol       = "UDP"
    port           = 1194
    description    = "openvpn"
    v4_cidr_blocks = ["0.0.0.0/0"]
  }
}

Группа нод кластера Kubernetes:

Google Cloud

resource "google_container_node_pool" "pool" {
  name     = var.node_pool_name
  cluster  = module.private_gke.cluster_name

  initial_node_count = var.count_node_per_zone
  node_locations     = var.pool_node_zones

  autoscaling {
    min_node_count = var.min_node_count
    max_node_count = var.max_node_count
  }
  node_config {
    disk_size_gb = var.disk_size_gb
    disk_type    = var.disk_type
    machine_type = var.machine_type
  }

  upgrade_settings {
    max_surge       = 1
    max_unavailable = 0
  }

  management {
    auto_repair  = true
    auto_upgrade = false
  }
}

Yandex Cloud

resource "yandex_kubernetes_node_group" "group" {
  name        = var.node_pool_name
  cluster_id  = yandex_kubernetes_cluster.my_cluster.cluster_id

  allocation_policy {
    location {
      zone = "ru-central1-a"
    }
    location {
      zone = "ru-central1-b"
    }
    location {
      zone = "ru-central1-c"
    }
  }

  scale_policy {
    auto_scale {
      min     = var.min_node_count
      max     = var.max_node_count
      initial = var.initial_node_count

    }
  }

  instance_template {
    platform_id = "standard-v2"

    network_interface {
      nat                = true
      subnet_ids         = [id_1, id_2, id_3]
    }

    resources {
      memory = 8
      cores  = 2
    }

    boot_disk {
      size = var.disk_size_gb
      type = var.disk_type
    }

    scheduling_policy {
      preemptible = false
    }
  }

  deploy_policy {
    max_expansion   = 1
    max_unavailable = 0
  }

  maintenance_policy {
    auto_repair  = true
    auto_upgrade = false
  }
}

Как видим, параметры интуитивно понятны и большинство из них легко сопоставимы у разных провайдеров, поэтому переход с одного облако на другое хоть и займет какое-то время, все же оно не будет продолжительным. Также следует учитывать, что различаться будут только специфические для облака ресурсы, а, например, модули для развертывания приложения в кластер 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- пайплайна и внести необходимые корректировки. Ниже приведены некоторые из возможных изменений, которые могут потребоваться при смене облака:

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

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

Часть 3: что получим в сухом остатке?

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

Бизнес:

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

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

IT-команда:

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

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

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

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

Будет ли актуален этот вопрос в обозримом будущем? Кто знает, но есть подозрение, что да. К сожалению, предпосылок к улучшению ситуации пока нет.

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

Спасибо за прочтение, берегите свою инфраструктуру!