Переводчик С. Черников

Технический редактор Н. Гринчик

Литературные редакторы Е. Ковалева, Н. Рощина

Художники С. Заматевская , Г. Синякина (Маклакова)

Корректоры Е. Павлович, Т. Радецкая

Верстка Г. Блинов

Джульен Вехен

Безопасный DevOps. Эффективная эксплуатация систем. — СПб.: Питер, 2019.

ISBN 978-5-4461-1336-1

© ООО Издательство "Питер", 2019

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

Посвящается моей жене Богдане и всем ребятам из Mozilla, которые берегут защищенность и открытость Интернета

Предисловие

Я расчищал полки со списанным оборудованием в подвале старого правительственного здания, и мне на глаза попалось несколько внушительных жестких дисков. 2002 год, мне 19 лет, это мое первое рабочее место в качестве специалиста службы поддержки во французском налоговом агентстве. Начальница едва не извиняется за то, что попросила убрать подвал, подозревая, что я выполню задание спустя рукава. Однако я чувствую себя как Али-Баба, впервые вошедший в волшебную пещеру. Я вижу множество старых серверов, стоящих без дела, но все еще способных запускать UNIX-системы, о которых я даже не слышал. Они оставлены в лучшем случае для баловства. Если бы в моей квартире было больше одной комнаты и крохотной кухни, я бы взял все это и запустил масштабную сеть прямо из дома!

Два жестких диска — это SCSI-диски с 15 000 об/мин, которые предназначались для устаревшего контроллера домена. Я отложил их в сторону, чтобы поискать SCSI-адаптер для подключения. Нашел его в соседней коробке пыльным, но невредимым. После нескольких часов расчистки и инвентаризации подвала я спросил разрешения забрать все домой. План был прост — подключить диски к запасной материнской плате и настроить самый быстрый сервер для шутера Counter Strike, которого Интернет еще не видел. Затем я бы развернул его в сети с помощью недавно установленного DSL-соединения на 512 Кбит/с и пригласил свою игровую команду потренироваться на нем.

Я провел все выходные, пытаясь заставить жесткие диски и адаптер правильно работать, стремился добиться их грамотного распознавания инсталлятором Debian. Часами искал руководства для работы со специфичным оборудованием, подсказки на десятках форумов и в письмах. Но большинство из них касались либо другого SCSI-адаптера, либо каких-то секретных ядер операционной системы (ОС), которые я не мог расшифровать. Прошли выходные, затем будни, и я наконец-то нашел верное сочетание параметров, которые запускают установку Linux на RAID 1. Может быть, я ошибаюсь, но думаю, что работа с железом — это и правда сложно!

Однако радость от успеха была недолгой. Вскоре я понял: эти два диска с их 15 000 об/мин создают слишком много шума, намного больше, чем я могу выдержать, когда сижу часами в нескольких метрах от них. Конечно, мой сервер работал, он был умеренно быстрым, но мне пришлось выключить его и оставить затею превращения квартиры в центр обработки данных.

Когда я изучал IT (в конце 1990-х и начале 2000-х годов), акцент делался на оборудовании и сетях. Вместе со своими сверстниками и преподавателями я проводил много времени, читая новости о последних серверах, новейших CPU и лучших жестких дисках. Все это надо было знать, чтобы создать идеальную систему для реализации на ней наших приложений. Закупка происходила медленно и была затратной, в частности, в моем правительственном агентстве. Неправильный выбор оборудования мог оставить нас в заложниках сервера, который не менялся бы в течение трех лет, а может, и дольше.

Представьте себе это в настоящем времени. Три года! Это длиннее, чем жизнь многих стартапов. Больше, чем продолжительность пика популярности почти всех веб-фреймворков на JavaScript. Множество людей работают в одной компании не дольше. Такой период просто вечность в мире IT.

В те времена (наверное, звучит так, будто я ваш дедушка) невозможно было развернуть веб-сервис на рынке менее чем за год или даже два. Не было облачных технологий, поставщиков услуг, которые могли бы размещать серверы или запускать службы онлайн вместо вас, предоставляя вам удаленный доступ к ним. Наши интернет-соединения были медленными (правительственное агентство обеспечивало вопиющими 128 Кбит/с, распределенными между 150 сотрудниками!) и не подходили для передачи больших объемов данных между локальным настольным компьютером и онлайн-сервисом. Настройка серверов представляла собой длительный и сложный процесс, который зачастую подразумевал часы сражения с драйверами оборудования и дни трудностей, связанные с прокладкой кабелей и работами по установке. Организации и целые отделы посвящали себя этому занятию. Программисты знали, что заказывать серверы нужно заранее, иначе есть риск того, что проект придется отложить на несколько месяцев.

Сосредоточенность IT на оборудовании и сетях также была характерна для отделов, обеспечивающих безопасность. Немногие тогда говорили о безопасности приложений. Зато все внимание сосредоточивалось на фильтрации сетевого трафика и доступе (физическом или виртуальном) к серверам. В школе мы узнали о межсетевых экранах (брандмауэрах), изолированных системах в пределах виртуальной локальной вычислительной сети (ЛВС) и обнаружении сетевых вторжений. Мы не вдавались в подробности безопасности веб-приложений — не знали тогда, что через несколько лет почти весь мир откажется от использования установленного программного обеспечения наподобие Outlook и сосредоточится на форме программы как сервиса, такой как Gmail. Эти перемены начались в середине 2000-х годов и позднее стали для нас более очевидными.

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

Сначала я был одним из тех, кто противился. Все мои потом и кровью полученные навыки внушали мысли о безопасности, неотделимой от управления оборудованием: если вы не управляете системами самостоятельно, то не можете считать свое положение безопасным. Но мало-помалу становилось все более заметно, что мои друзья-разработчики развертывают приложения с помощью небольшого перечня команд, в то время как я все еще трачу часы на то, чтобы осуществить это старым методом. Однозначно, они обнаружили что-то полезное, поэтому я начал работать инженером по эксплуатации и перенес монолитное Java-приложение на AWS (Amazon Web Services). Это было мучительно. Я не знал о существовании конфигурационных инструментов, Puppet или Chef, да и AWS в то время не был настолько развит, как сейчас. Я писал оригинальные скрипты для автоматизации настройки серверов и учился использовать API для создания виртуальных машин на ходу. Моему руководителю нравилось то, что возможно сломать приложение и развернуть его заново несколькими командами, однако все работало ненадежно и довольно нестабильно. Но это было лишь начало. Оно придало мне уверенности в том, что безопасность сильно зависит от гибкости инфраструктуры: чем быстрее системы способны изменяться, тем быстрее можно устранить проблемы и тем выше уровень безопасности.