Почему я советую людям не учить Ansible. Андрей Девяткин
Комментарий автора: Основная цель доклада — рассказать про методы построения инфраструктуры (Configuration Synchronization/Immutable infra) и сравнить их. Ansible используется как пример одного из инструментов синхронизации конфигурации. С точки зрения автора мир движется в сторону immutable infrastructure и в докладе приводятся аргументы разъясняющие позицию автора. И так как мир движется в сторону immutable infrastructure учить инструменты использующие подход синхронизации конфигураций может быть не самым лучшим использованием времени. Повторю еще раз — доклад не про инструменты, а про подходы и принятие решения «от-проблемы», а не «от-инструмента»
Disclaimer: Этот доклад сложен тем, что готовится под российскую аудиторию, которая работает в несколько специфических условиях. Мы потрогаем все эти вещи во время презентации. В России специфичное использование инфраструктуры, потому что народ в основном живет не на Amazon. Есть компании, которые и там живут, но их мало. И это является ограничением. Это стоит учитывать во всех докладах, связанных с раскаткой инфраструктуры, чтобы не говорить: «Ребята, поехали в облако, в AWS все будет отлично» и тут сидит толпа людей, которые туда поехать не могут. Российская аудитория кажется очень специфичной. И те доклады, которые заходят в Европе, в России не всегда заходят. Возможно, это связано с особым восприятием данной аудитории.
Всем привет! Спасибо, что пришли послушать! Сегодня мы обсудить, почему я не рекомендую людям изучать Ansible. Давайте разбираться.
Что же все-таки не так с Ansible? Давайте разбираться.
Еще несколько дисклеймеров.
Первый дисклеймер — это то, что в этой презентации нет цели сравнивать какие-то инструменты. Т. е. это не Ansible vs Terraform, Ansible против CloudFormation, Ansible против Chef и т. д.
Тогда вы сейчас, возможно, думаете: «А о чем тогда это может быть?»
Еще один дисклеймер:
- Это презентация построена на нашем опыте консалтингового агентства FivexL.
- Это именно то, что мы рекомендуем заказчикам на сегодняшний день.
- Все, что рассказывается в этой презентации, это мое субъективное мнение, а также мнение моих коллег. И оно достаточно прагматичное.
- Также нет серебряной пули, т. е. то, что я рассказываю здесь, не нужно воспринимать идеалистически. Нужно, как говорят англичане, воспринимать это с щепоткой соли.
И снова рассказываю не про Ansible?
Давайте поговорим про Ansible. Мы пойдем на страницу Ansible. Этот снапшот я сделал с нее 2 дня назад, так что он достаточно свежий. Мы можем попытаться разобраться, что же за инструмент такой Ansible и зачем его используют.
Мы видим из этой страницы, что его можно использовать для application deployment, менеджмента конфигурации, чтобы оркестровать таски. И это все работает либо через OpenSSH, либо WinRM.
Но это не отвечает на вопрос: «Зачем нам его использовать, какую проблему он решает?».
Поэтому мы можем пойти на страницу use-cases. Те ссылки, которые я привожу, вы увидите в левом нижнем углу экрана.
Мы видим, что его рекомендуют использовать для provisioning серверов, менеджмента их конфигурации, а также для того, чтобы раскидывать там приложения. И можно что-то делать для безопасности и оркестрации.
Наши заказчики часто к нам приходят с различными желаниями. Они говорят: «Давайте мы будем вот этот инструмент использовать».
А мы им говорим, что давайте пойдем от проблемы, поймем контекст.
Далее поймем методы, которые в этом контексте будут уместны.
И потом уже подберем инструмент, т. е. давайте не будем исходить из инструмента.
И если мы переварим все то, что сейчас увидели на слайдах касательно Ansible, то мы можем понять, что проблема — это автоматизация изменений IT.
Соответственно, контекст, который они подразумевают, это либо железные сервера, либо виртуальные машины.
Метод, который предполагается использовать, это инфраструктура как код и синхронизация конфигурации.
И предлагают использовать инструмент Ansible.
Многие из вас думают, что с Ansible можно делать многое другое.
Можно еще AWS настроить.
Можно и Kubernetes.
Можно и HashiCorp Vault настроить.
Можно все сделать с помощью Ansible при желании.
Но тогда стоит задуматься — будет ли Ansible решением той проблемы и в том контексте, которую вы решаете. Т. е. нужно идти от проблемы.
Иначе можно оказаться в ситуации, когда мы применяем инструмент как молоток, которым мы стучим везде и все нам кажется гвоздем.
Мы не хотим быть в этой ситуации. Плюс каждый раз, когда вы немножко выходите из mainstream, нужно подумать о последствиях. Vendor, который предлагает вам инструмент, говорит, как его можно использовать. Вы можете пойти попробовать вправо-влево и сделать что-то по-другому. Но вам нужно всегда думать: «Я это сделаю сейчас так, но тогда я начну что-то терять. Если я иду в другую сторону по сравнению с community, то я потеряю именно те вещи, которым community научится, т. е. какие-то инсайты я потеряю».
Дальше подумать: «То, что я делаю, это немного на стороне, какие здесь перспективы продолжительного саппорта? Могу ли я найти кого-то, кто захочет потом с этим работать в дальнейшем?».
Плюс, возможно, ваш начальник будет более рад, если вы будете фокусироваться на чем-то, что полезно бизнесу, вместо того, чтобы на стороне что-то такое делать, когда можно воспользоваться другим инструментом, который для этого больше подходит. Это такие вещи, которые стоит продумать.
Именно поэтому Ansible в рамках этой конфигурации мы будем рассматривать, как инструмент менеджмента конфигурации, который используется для provisioning серверов, чтобы раскидать applications, приложения по этим серверам. Плюс можно запускать таски, он это умеет делать.
Мы часто будем возвращаться к этому слайду и разговаривать про проблему, которая остается неизменной, т. к. также хотим автоматизировать изменения в IT.
Но в этой презентации я заявляю, что у нас меняется контекст, у нас меняются методы. И поэтому выбор инструмента может быть другим. Давайте разбираться.
Меня зовут Андрей Девяткин.
Называю себя cloud engineering-специалистом.
Я занимаюсь в частности AWS и инструментами компании HashiCorp. Выступал на HashiConf этим летом, потому что было очень классно.
Также являюсь основателем консалтинг-бренда FivexL.
Часто выступаю на конференциях. И еще у нас есть англоязычный podcast DevSecOps, где я и два моих друга рассуждаем о том, что сейчас происходит и пытаемся разобраться во всем. Мы пытаемся разобраться, что работает, что не работает. Это честный разговор, который мы записываем.
В этой презентации у нас будет очень много материала, который нам понадобится. Я эту презентацию разбил на 5 этапов, через которые мы сейчас пройдем.
На первом этапе мы будем говорить о том, что единственная константа — это изменения.
На втором этапе мы поговорим, что синхронизация конфигурации — это необходимое зло.
На третьем этапе мы поговорим про immutable-инфраструктуру и о том, что это, скорее всего, наиболее подходящая практика, которая у нас есть сегодня.
Поговорим о том, что появляются новые способы, новые контексты и новые методы.
Плюс поговорим о том, что будущее уже здесь. Оно просто неравномерно распределено.
Поехали, начнем с первого.
Мы посмотрим на большую картинку и попытаемся понять, почему происходят эти изменения в IT, которые нам надо автоматизировать.
Представьте ситуацию, что у потребителя, есть какое-то желание, которое ему нужно утолить.
И есть предприниматель. Предприниматель видит, что у потребителя есть какая-то потребность, которую он может утолить и получить за это деньги. Он тестирует какую-то бизнес-модель и предлагает продукт или услугу потребителю.
Теоретически в идеальных условиях мы можем сказать, что он построил машину по производству денег, если ничего не меняется.
Но это не так. Потому у нас есть competition, т. е. есть люди, которые приходят на рынок, видят, что сделал предприниматель и делают примерно то же самое, а, может быть, даже лучше. И они пытаются занять рынок. Например, мы начали с AWS в облаках, потом пришел Google, потом пришел Amazon, Alibaba, Яндекс, Сбер и т. д. Если бы другие игроки не пришли, то у Amazon была бы полная монополия, он бы просто делал денег. Но этого не происходит.
Коментарий автора: пришел Google, потом пришел Amazon, Alibaba — под Amazon имелся ввиду Azure
Поэтому постоянно приходится меняться, постоянно приходится соревноваться с другими. Плюс меняется сам рынок. Рынок может насыщаться. Могут происходить коренные изменения в рынке, например, как в этом году во время пандемии было тяжело всем перевозчикам и тем, кто зарабатывал на туризме. Для них рынок коренным образом изменился.
Поэтому бизнесу постоянно приходится меняться. И изменения постоянно будут продолжаться.
И каждое изменение приносит собой энтропию. Вы не можете просто изменить, у вас всегда будет элемент хаоса приходить вместе с изменением.
И если мы посмотрим словарь, то энтропия — это мера хаоса, это процесс разрушения, процесс деградации, когда материя во Вселенной станет в ultimate state, т. е. когда все совсем уйдет в хаос.
Вы можете сейчас сидеть и думать: «Как это все связано с Ansible?».
И тут нам надо задать вопрос: «Как же мы позволим бизнесу меняться быстро, но при этом минимизируем энтропию?».
И тут мы можем подумать: «DevOps!».
«Infrastructure as code!»
«Ansible!», наконец.
Но что мы сейчас делаем? Мы просто выкрикиваем термины, которые всплывают в нашей голове.
А должны мы идти по этому фреймворку. Мы должны идти от проблемы. Проблему мы сформулировали — мы хотим минимизировать энтропию, потому что она нам будет мешать по дороге, но при этом нам нужно стараться как можно больше автоматизировать все, что мы можем.
Поэтому мы немножко обсудим конфигурацию синхронизации и энтропию.
В нашей области энтропию называют — configuration drift. И первый раз я нашел это определение, когда читал книжку Keif Morris «Инфраструктура как код». Он не является тем человеком, который придумал это определение. Первыми этот термин использовали PuppetLabs поэтому атрибутика идет им.
Идея в том, что конфигурационный дрифт накапливается и потихоньку сервера отклоняются-отклоняются-отклоняются от изначальной конфигурации за счет того, что люди делают там что-то руками, делают апдейты, обкатывают новые приложения, приложения могут за собой что-то оставлять.
Потом за счет энтропии, за счет конфигурационного дрифта сервер может в какой-то момент прийти в состояние сервера-снежинки. Это что-то такое, что придумал Martin Fowler в свое время.
Сервер-снежинка — это сервер, который прошел точку невозврата. Он уже настолько свой, что уже никто не знает, как его так сконфигурировали, т. к. там уже столько всего накопилось. И трогать каждый раз его страшно. Он уникальный и очень хрупкий. Я думаю, что у многих были такие моменты, когда они сталкивались с такими серверами-снежинками.
Почему это проблема? Это проблема, потому что нарушается стабильность системы, т. е. мы не можем устанавливать приложения на эти сервера и иметь 100%-ную гарантию, что все пройдет гладко, потому что всегда есть доля неизвестности.
Плюс каждый раз, когда эта доля неизвестности срабатывает и что-то идет не так, мы свои ресурсы отвлекаем от продуктивной работы: от работы над новой функциональностью, от работы над улучшениями инфраструктуры, которая служила бы заказчику и позволяла бы бизнесу двигаться вперед. И, как я уже сказал, это влияет на нашу способность доставлять новые версии приложения. Смотрите на это, как на технический долг в инфраструктуре.
Также это влияет на наш MTTR (mean time to recovery), т. е. насколько быстро мы можем восстановиться после инцидента.
Приведу вам несколько примеров. Например, вам могло прийти письмо счастья от AWS о том, что железо, на котором лежит ваш EC2 instance, деградировало, и они собираются его прибить. И если у вас там такой сервер-снежинка, то день может стать намного интересней, чем он был.
В Amazon это все не так плохо. Вы можете взять снапшот, попробовать его пересоздать и с большой вероятностью это получится. А если у вас резко слетает жесткий диск на железном сервере, то это менее смешно.
Например, у вас случился второй shellshock и вам нужно все резко пропатчить. И тут могут навалиться различные инциденты, потому что патчи не проходят, т. е. вам сложно это сделать.
У моего коллеги Артема была ситуация со серверами-снежинками, у которых были GPU-драйвера. Эти сервера как-то руками наконфигурировали, но как это сделали никто не знает. Нужно было обновить GPU-драйвера. И это было большим приключением. На это ушло гораздо больше времени, чем должно уходить.
Например, в вашей сети находится нарушитель. И вам нужно произвести расследование и понять, что происходило на этом сервере. Эти файлы должны быть здесь или это Вася их поставил? Они должны быть в таком состоянии и в такой директории или им свойства поменяли? Должно ли быть все так?
Мы говорим сейчас в контексте именно серверов и виртуальных машин. И джентльмены, про которых мы говорили до этого, в начале 2010-ых говорили в терминологии серверов и виртуальных машин.
И что мы с этим делаем?
Обычный способ — это инфраструктура как код. И есть 4 принципа, сформулированные в книге «Инфраструктура как код»:
- Все элементы в инфраструктуре должны быть воспроизводимыми, т. е. у нас должна быть возможность их воспроизвести.
- За счет того, что мы можем их воспроизвести, у нас должна быть возможность их выкинуть. Они должны быть disposable.
- И за счет того, что мы конфигурируем как код, наша инфраструктура будет консистентной.
- Плюс у нее нет конечного состояния. Когда мы проектируем нашу инфраструктуру, мы понимаем, что то, что мы знаем сегодня ограниченно и завтра может измениться. Может измениться бизнес-контекст, могут измениться бизнес-нужды, поэтому то, что мы выстраиваем сегодня, это не что-то такое, что вырублено на камне. Это то, что будет меняться, поэтому нужно продумать, как мы это будем менять завтра. И нужно быть готовым это изменить.
Это 4 принципа, на которых держится инфраструктура как код.
И если мы посмотрим определение из Википедии, то там написано, что инфраструктура как код — это когда мы описываем всю нашу инфраструктуру в файликах. Эти файлики — machine-readable, т. е. какие-то инструменты могут эти файлики прочитать и потом перевести все, что в этих файликах написано, а потом пойти и сконфигурировать системы так, как мы это описали.
Технически мы применяем методы разработки software — одна конфигурация. Все те же методики, т. е. так же, как мы разрабатывали код, как мы разрабатывали продукт, тоже самое мы делаем с инфраструктурой, применяя те же методики. Можем делать code review, можем запускать CI и так далее
И наш шаблон потихоньку заполняется, т. е. мы говорим в контексте железных серверов и виртуальных машин. Применяем infra as code.
И я обещал поговорить про синхронизацию конфигурации и давайте про нее поговорим.
Было несколько поколений инструментов для работы с конфигурациями.
Я не буду называть номер этого поколения, но было конкретно выделенное поколение: Puppet, Chef. Ansible и SaltStack пришли чуть попозже. Это именно те инструменты, которые работали с синхронизацией конфигурации. Мы сейчас увидим, что это значит.
Специфика этих инструментов в том, что они автоматизируют provisioning. И чаще всего им нужна небольшая дополнительная конфигурация. В случае некоторых инструментов нужно установить агента на сервер, в случаях других нужно открыть firewall для того, чтобы он туда мог пойти, например, по SSH-порту и сделать то, что он хочет сделать.
Вот эту картинку я взял из статей Martin Fowler. Это отличные картинки, ссылки внизу, если вы захотите всю статью прочитать. Это именно то, как работает конфигурация синхронизации.
У нас есть образ сервера. Мы накатываем его на сервер. Сервер у нас поднялся. И потом мы используем инструмент синхронизации конфигурации, чтобы применять изменения. Он поэтому так и называется. У нас лежит конфигурация в нашем репозитории, и мы ее запускаем, чтобы синхронизировать на сервере. И каждый раз, когда нам нужно что-то новое сделать, мы меняем это в репозитории, запускаем инструмент. И он это синхронизирует на сервере. Если мы не уверены, как он там встал, мы запускаем еще раз и делаем еще одну синхронизацию.
Опасность здесь в том, что мы не следим за всеми файлами на сервере. У вас всегда есть вероятность, что кто-то пошел и руками поправил и это вне ответственности инструмента. Это все накапливается-накапливается.
И это может привести к спирали страха автоматизации.
Как это работает? Вы делаете изменения вне вашего инструмента, которым вы синхронизируете конфигурацию. Ваши сервера становятся немного не консистентными. И потом вам становится страшно запускать ваш инструмент, потому что что-то может пойти не так: что-то может сломаться, если вы его запустите. Поэтому в следующий раз, когда вам нужно сделать изменения, вы снова их делаете руками, сервера становятся еще более не консистентными, и вам еще более страшней запустить ваш инструмент. И таким образом ваш сервер по спирали уходит вниз к состоянию сервера-снежинки.
Давайте посмотрим, как эволюционировала человеческая мысль дальше.
Потом те же ребята из ThoughtWorks пришли с идеей о Phoenix server,
Идея такая же: мы делаем все то же, что конфигурация синхронизации, но в какой-то момент на периодической основе мы этот сервер прибивает, полностью все с него удаляем, заново накатываем образ сервера и потом запускаем наш инструмент. Таким образом мы обнуляем конфигурационный дрифт, который накопился.
Мы можем сделать еще один шаг.
Мы можем все изменения, все конфигурации, которые у нас есть, поместить в образ сервера и уже накатывать это сразу на сервер. И после этого не делаем никаких изменений, и просто раз в какой-то промежуток времени его удаляем. Если нам нужно сделать какие-то новые изменения, мы делаем новый образ сервера, накатываем его на сервер. Т. е. мы не делаем синхронизацию конфигурации, мы либо понимаем новую виртуалку из нового образа или вайпаем (wipe, стереть) сервер и накатываем новый образ. И поэтому требуется несколько серверов, чтобы вы могли переключать трафик. Но за счет этого вы минимизируете количество конфигурационного дрифта.
И другой бенефит, который вы получаете от этого, у людей пропадает желание ходить на сервер по SSH, потому что они знают, что сервер будет уничтожен в какой-то момент и все изменения, которые они делают, пропадут. И вместо про то чтобы спрашивать вас о том где лежит SSH ключ они уже спрашивают вас о том, где лежит спека из которого будет собран образ для этого сервера. И это уже новый уровень диалога.
Если говорить еще о бенефитах, то, как мы уже говорили, у нас стремится к нулю конфигурационный дрифт.
У нас есть возможность масштабироваться быстро. Например, в рамках AWS у нас есть auto scaling группа. Вам нужно поднимать новые виртуалки. И вы не будете руками их запускать-запускать, а потом инструментом синхронизации конфигурации их настраивать, а потом только вводить в строй. Если у вас почти все заключено в ami (шаблон виртуальной машины), то тогда у вас auto scaling group может автоматически вам новые сервера легко поднимать, а также убивать. Вы ничего не теряете, потому что они всегда все одинаковые. Ничего нового здесь я не рассказываю. Это backing vs. frying, cattle vs pets. Все то что много раз рассказывалось на конференциях.
И у вас повышается уровень безопасности. Представьте, что в вашу сеть пробрался нарушитель. И вы это не заметили. А вы каждую неделю перекатываете все свои сервера. И таким образом все, что он установил, вы стираете. И ему придется каждую неделю повторять все те же мероприятия, чтобы хоть как-то закрепиться в вашей инфраструктуре.
Плюс, что делают те, кто нападают? Они нападают и сидят очень тихо. И они делают нумерацию всего того, что у вас есть: «Ага, веб-сервер на том IP-адресе, это на том IP-адресе». А у вас все меняется постоянно. У вас постоянно происходит ротация этих серверов, ротация IP-адресов, если вы в облаке. И им намного сложнее заниматься теми делами, которыми они пришли заниматься. Например, незаметные латеральные движения в вашей сети становится намного сложнее.
Плюс, за счет того, что вам минимальное время нужно на provisioning сервера, потому что все уже в образе находится, вы можете воспользоваться, если вы в облаке такими опциями, как EC2 spot instance. Если даже из-под вас spot instance выдернут, то ничего страшного. В другой зоне поднимется, потому что там осталось все по-прежнему, т. е. вы ничего не теряете. У вас будет 2 минуты для того, чтобы переключить трафик, чтобы убрать этот instance из ротации.
И тут вы можете подумать: «Если я использую Ansible, но при этом достаточно часто убиваю свои сервера, то, может быть, этого достаточно?».
Может быть. Как я вам сказал, эта презентация очень практичная. И мы не идеалисты, мы практики. Умные книжки вам всегда рисуют красивую картинку, но жизнь всегда сложнее. Ты приходишь иногда к заказчику и думаешь: «Боже мой, что же вы наворотили! Какой ужас!».
Конечно, этого нельзя людям в лицо говорить. Нужно пообщаться и понять, почему они так сделали. Скорее всего, у них были причины. Если бы у нас у всех были идеальные условия, то мы бы строили идеальные системы. Но условия не идеальные и часто приходится подстраиваться. И как хмурый котик нам сказал о том, что, может быть, это даст вам 80% бенефитов за 20% усилий.
Каждый для себя выбирает свою дорогу, основываясь на том фреймворке, о котором мы сейчас говорили.
Мы понимаем, свою проблему, свой контекст, свои ограничения. И сейчас мы уже видим, что есть новые методы, из которых мы можем выбрать. И когда мы работаем в контексте серверов и виртуальных машин, мы можем выбрать синхронизацию конфигураций или можем выбрать immutable-инфраструктуру.
И мы рекомендуем нашим заказчикам, что immutable-инфраструктура — это более лучший подход.
Как ее имплементировать? Давайте поговорим про это.
В идеале перед тем, как вы начнете, вам надо посмотреть на ваши приложения. И будет очень хорошо, если ваши приложения будут соответствовать 12 факторам app.
Там очень полезные вещи написаны. И очень смешно, когда системные инженеры, которые занимаются инфраструктурой, выстраивают системы, приходят к девелоперам и говорят: «Вы про 12 factor app слышали? Давайте так делать». И очень часто на них люди удивленно смотрят.
И если вы следуете этим рекомендациям и если ваше приложение сегодня не запускается в контейнерах, то переезд контейнера будет намного проще. Плюс вам будет намного проще имплементировать immutable-инфраструктуру.
На этом слайде я привожу несколько примеров этих принципов, чтобы вы поняли, о чем это.
Давайте подумаем о тех вещах, которые стоит учесть.
У нас есть 3 большие области, про которые стоит подумать:
- У вас всегда будет какая-то динамическая конфигурация, которую вы не знаете наперед. И, может быть, эту часть вы решаете сегодня с Ansible.
- У вас могут быть какие-то секреты, которые вы не хотите запихивать в образ. И нужно подумать, как это решить.
- И нужно подумать, как сделать так, чтобы люди туда не ходили, чтобы этот конфигурационный дрифт не накапливался. И как им все-таки туда пойти, если очень нужно.
Давайте разбираться с секретами сначала.
Нам нужно решить проблему нулевого секрета. И в зависимости от той среды, которую мы используем, применяются разные вещи. Например, если это AWS, то мы можем использовать instance-профайлы, которые нам дадут credentials, которые мы потом можем в дальнейшем использовать.
Если это Bare Metal, то там много разных систем.
SPIFFE все больше набирает популярность, чтобы давать серверам identity. И потом, чтобы они могли через identity аутентифицироваться в других системах.
Другой вариант — вы можете запечь зашифрованные секреты в образ с учетом того, что ключ шифрования будет доступен, когда образ будет подниматься. Например, в AWS вы можете использовать KMS ключ, который доступен только в вашем аккаунте. Если ваш AMI утек, то его нельзя будет расшифровать, потому что нет доступа к ключу. В вашем дата-центре может быть HSM (hardware security module), в котором вы можете хранить ключи шифрования, которые будете использовать для того, чтобы расшифровывать секреты. Если у вас утечет образ, то ничего страшного, потому что ключи только там.
Также сейчас есть системы, которые позволяют затаскивать секреты вовнутрь, т. е. у вас приложение может подняться и прочитать все необходимые секреты, например, с HashiCorp Vault. Если вы бежите в AWS, то мы можете Secrets Manager использовать.
Также все больше и больше возможностей генерировать динамические credentials. Это не сильно относится к immutable-инфраструктуре, но это то, что мы всегда рекомендуем.
Плюс есть возможность пулить (pull) не только секреты, но и конфигурацию, например, используя Consul.
Что делать с людьми?
Нам нужно оставить возможность попасть на сервер, либо на виртуальную машину. Но сделать это так, чтобы люди наследили, когда они это делают. Грубо говоря, не надо гасить SSH-сервер, но SSH-порт стоит закрыть на firewall. И чтобы людям туда пойти, им сначала нужно открыть firewall. И у вас получится из этого какой-то event. Это зависит от того, как ваша инфраструктура выстроена. И на этот event вы потом можете настроить автоматическое убийство машин, потому что неизвестно, что человек там наделал.
И многие компании так делают. Если там кто-то что-то наделал ручками, то автоматически эта машина через 12 часов будет убрана из ротации и полностью очищена.
Как нам поступать с debug?
- В первую очередь нужно вытаскивать все, что мы можем вытащить. Стримить логи наружу, а также все метрики, т. е. все то, что можно вытащить, нужно вытаскивать.
- Дальше нам нужно подумать про безопасность немножко. Наши сервера умирают достаточно часто. И может быть так, что нам понадобиться пойти назад в историю. Может быть, у нас несколько месяцев сидит злоумышленник в нашей сети, и нам нужно провести исследование, что он делал и где он был. А если вы каждую неделю вращаете свои сервера и полностью их затираете, то вы можете потерять важные улики. Поэтому системные вызовы тоже стоит стримить с серверов. И, скорее всего, ваша служба безопасности этим занимается. Либо нужно делать какие-то снапшоты перед тем, как вы сервер убиваете. И потом эти снапшоты вы храните несколько месяцев. Это полезно.
- Если людям нужно что-то протестировать, то у вас есть образ, который такой же, как и тот. Поднимите на стороне еще одну виртуалку, например, либо еще один сервер. Пустите немножко трафика и протестируйте там. Не ходите на те машины, которые на данный момент обслуживают production.
- А если очень нужно, то ходите, а потом прибейте.
- Лучшие практики. Если вы делаете continuous integration, то ничего нового. Все зависимости сохраняйте под системой контроля версий.
- Автоматизируйте построение образов ваших виртуальных машин или серверов. Постарайтесь, чтобы люди вам их не собирали, чтобы это был повторяемый процесс, который у вас происходит на сервере.
- Автоматизируйте тестирование, т. е. пробуйте автоматически все раскатывать.
- Старайтесь промоутить вместо того, чтобы пересобирать. Эта важно. Старайтесь, чтобы это был тот же образ, просто, чтобы он был конфигурируемый между окружениями вместе того, чтобы пересобрать в каждом окружении свой. Иначе будет вероятность, что что-то пойдет не так или у вас будет тестирование отличное от условий production.
- Часто деплойте. Как можно меньшую дельту накапливайте перед тем, как раскатываете. В идеале раскатываете на каждый commit, если у вас есть такая возможность. Особенно, если у вас система построена так, что вы без потери трафика можете переключать виртуальные машины. Это требует определенной работы, но вполне достижимо. И сейчас есть много инструментов, которые могут с этим помочь. В идеале каждый commit. Потому что, если что-то пошло не так, у вас дельта — один commit, вы знаете, что пошло не так. Проблема в этом commit. Вы его откатили, вернули зеленое состояние. И человека, который сделал этот commit, есть время, чтобы разобраться и узнать, что пошло не так. На него нет давления, что он сломал что-то в CI.Т. е. просто откатили и человек спокойно разбирается.
- Плюс я рекомендую перекатывать по расписанию. У вас может быть так, что commit«ов нет. Т. е. у вас какая-то такая система, в которой не так часто происходят изменения. Поэтому я рекомендую по таймеру перекатывать, т. е. делать каждую неделю перекатку. Можно делать это в выходные, либо в понедельник с утра.
Предположим, есть задача посмотреть на практике, какие инструменты могут быть нам полезны.
HashiCorp Packer, я думаю, всем знаком. Это достаточно универсальный инструмент, который много где используется. Вы можете под облака собирать Packer«ом, можете под локальные виртуалки тоже. Есть много разных вариантов.
Если вы деплоите в cloud или вам предоставлен API, то Terraform — классный инструмент. Это дело вкуса, конечно. Может быть, вам vendor предоставляет какой-то более хороший инструмент, т. е. я не пытаюсь вам говорить, что Terraform — самый лучший инструмент в мире. PXE очень полезен для раскатки baremetal, если вам именно baremetal нужен.
У нас сейчас тоже был проект, где мы Packer«ом старались собирать образа и через PXE их раскатывать. Но не было возможности, к сожалению, довести его до конца, потому что началась пандемия и потерялась возможность попасть в то место, где сервера стоят, потому что нет возможности путешествовать.
Безопасность — Audibeat, WAZUH и другие инструменты. Vault — очень популярный инструмент. Если вы в облак
