Как переехать в Amazon

Предпосылки

До переезда мы арендовали несколько bare metall серверов в SoftLayer.

На всех из них крутились KVM виртуалки, была своя выделенная подсеть (даже не так, несколько подсетей). Поддерживать все это было то еще удовольствие.

Немного спасал OpsCode Chef, но не сильно. Т.к. три ветки в git, которые сливать в кучку не всегда нормально удавалось из-за шифрования критичных вещей.

Не спрашивайте почему так. Это историческое наследие и выкорчевать его было не так просто.

Последней каплей стало то, что у нас как-то пошла небольшая нагрузка и на двух физических серверах тупо не хватило памяти, чтоб добавить ее в виртуалки. Пришлось ждать два дня, пока поддержка SoftLayer'a добавит нам планки.

В этот момент было принято волевое решение - хватит это терпеть. Пора отказываться от такой схемы работы.

Подготовка инфраструктуры

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

Выбор не велик - DigitalOcean и Amazon AWS. Поскольку DO не предоставляет HIPAA и HiTrust, то выбор стал очевиден сразу.

К тому моменту мы уже игрались с Docker и посматривали на Kubernetes и Swarm. И решили, что если уж переезжать, то сразу менять и метод доставки релизов на сервера. Самописные развесистые скрипты, запускаемые из Jenkins, это конечно не плохо, но плюшки доккера как-то радовали.

Ну и если уезжать в Amazon, то использовать их API надо по полной. Отсюда вырастала парадигма Infrastructure As Code.

Согласитесь, что иметь историю изменения инфраструктуры в git - это отличная идея.

Выбор пал на Terraform от компании Hashicorp. Да, там не все гладко. Но оно работает и даже не падает. ;)

Я засел за выписывание всей инфраструктуры, создание VPC, RDS, ElasticSearch и т.п.

Раз уж мы готовим инфраструктуру автоматизированно, то надо как-то и образы для виртуальных машин готовить.

У нас есть Terraform, и у этой компании есть отличный инструмент для подготовки AMI в Amazon - Packer.

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

Docker Swarm

Для автоматического развертывания мастера и воркеров был написан скрипт, который запускается при создании виртуалки, ищет мастер ноду Swarm'a и цепляется к ней автоматически.

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

Понятное дело, что мы не формировали сразу все на проде. Swarm мы сначала создали руками на деве и стейдже. И только потом приступили к проду.

Подготовка к переезду

Перед тем, как переносить все сервисы в новый прод, пришлось перешерстить все наши сервисы. Очень много из них просто выкинули, т.к. исследовав статистику запросов, оказалось, что туда в принципе никто не ходит.

Кое-какие сервисы мы допилили немного и перекрыли необходимость переносить какие-то сервисы (т.е. внесли некоторый старый функционал в текущие и поддерживаемые вещи). Таким образом мы сократили количество того, что нужно перенести.

Дальше была большая работа по обертыванию всех наших сервисов в Docker. Написали кучку Dockerfile'ов, собрали образы, запушили их и развернули на деве и стейдже.

Отдельная история была с системой OTRS. Редкая хрень с точки зрения админа.

Посоздавали таски в Jenkins на сборку образов и деплой сервисов. В этом месте была большая эпопея по допиливанию связей, т.к. наткнулись на какие-то странности в Swarm'e. Решали методами выбрасывания портов, изменения логики, роутингом через в внутренний LoadBalancer. Было много всего, но этот этап успешно завершили и начали переезд.

Переезд

В выходной вышли на работу и начали перенос.

Первое, что мы сделали, это перенесли базу в RDS и задеплоили сервисы. Потом руками перенастроили Nginx в SoftLayer для проксирования почти всего трафика в Amazon и переключили DNS.

Все сервисы были проверены нашим отделом QA (за что им большое спасибо). И мы со спокойной душой смогли выключить часть серверов и отказаться от их.

Но один большой сервис все еще продолжал крутиться в SoftLayer.

Спустя какое-то время мы перенесли примерно так же и оставшийся сервис. Все прошло гладко, т.к. опыт уже был не маленький.

И, наконец, мы выключили все сервера в SoftLayer и забыли о них.

Жизнь после переезда

После переезда прошло 6 месяцев. Сейчас я с уверенностью могу сказать, что все прошло достаточно гладко.

С Docker Swarm в продакшн окружении жить можно и оно работает. С Kubernetes у нас как-то не сложились отношения.

После того, как мы переехали было еще много всякой работы. Настройка и деплой мониторинга сервисов и машин, допиливание Jenkins, прикручивание AWS Lambda, выуживание разных узких мест в инфраструктуре.

Естественно, у нас не обходится и без Ansible. Куда ж без него. Всяко лучше, чем стра[ш|н]ный OpsCode Chef. ;)

В общем и целом - все получилось, хотя задача была, конечно, не тривиальная. Это был очень интересный опыт.

Если у вас есть большая задача - не бойтесь ее делать. Главное - чтоб было интересно.