- Главная
- →
- DevOps и эксплуатация
Разработка портируемой инфраструктуры New Relic - контейнеры, CoreOS и прочие приключения DevOps и эксплуатация
Недавно, после успешного запуска продукта New Relic Infrastructure, возглавил новую группу, ответственную за настройку второго "региона" для обслуживания европейских клиентов. Группа Михаила занимается стратегией перехода на более портируемые процессы и технологии с целью упрощения настройки всех сервисов, составляющих продукты New Relic. До этого Михаил основал компанию Opsmatic, которую New Relic купил в конце 2015-го года.
Тезисы
Нашей группе было поручено создать новый самостоятельный “регион” для всех продуктов New Relic, предназначенный для обслуживания европейских клиентов, подпадающих под ограничения GDPR. Здесь следует отметить, что так как наша компания предоставляла свои услуги исключительно через “облако” (SaaS), то хорошо выработанных процессов для настройки всей инфраструктуры “с нуля” у нас не было.
Рассмотрев полученную задачу, мы установили, что настройка региона при имеющихся процессах займет Н месяцев. Принимая в расчет, что в будущем может возникнуть необходимость создания подобного региона для другой группы - или других групп - клиентов, было решено вместо этого потратить Н-1 месяцев на улучшение процессов и автоматизацию, что по нашим расчетам должно значительно сократить максимальный срок непосредственной настройки до одного месяца. Таким образом, мы надеемся значительно снизить общую стоимость настройки третьего, четвертого и последующих регионов, а также упростить и ускорить работы по устранению неполадок, возможных во время их установки. В идеальном случае можно надеяться, что полученный опыт поможет уменьшить количество ручных операций также и в первом регионе, что в свою очередь положительно скажется на контроле качества и общем настрое коллектива.
В качестве опорных технологий наша группа выбрала достаточно известный коктейль, уже используемый в разных подразделениях компании - Docker, Mesos/Marathon, и CoreOS. Но дьявол, как всегда, скрывается в деталях. В этом докладе мы рассмотрим следующие вопросы:
* Как помочь командам, ответственным за приложения, написанные 10 лет назад по раннему образцу Rails и рассчитанные на установку под Capistrano?
* Как установить полный граф зависимостей, когда многие ссылки на зависимости спрятаны внутри контейнеров или в динамических элементах кода, не поддающихся статическому анализу?
* Как минимизировать ручные операции во время создания кластера Vault, избегая создания новых “дыр”?
* Как организовать работу команд, ответственных за устарелые, нестандартизированные приложения так, чтобы дополнительные нагрузки не привели к задержкам и простоям их основных проектов?
* Что делать с распределением нагрузки, когда привычные приборы F5 недоступны в новом регионе, а заменять их нет времени?