Одна из наиболее распространенных услуг 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 всегда рада помочь!