Комментарий автора: Основная цель доклада — рассказать о методах построения инфраструктуры (Configuration Synchronization/Immutable infra) и сравнить их.
Ansible используется в качестве примера одного из инструментов синхронизации конфигурации.
С точки зрения автора, мир движется к неизменной инфраструктуре и в докладе приводятся аргументы, объясняющие позицию автора.
И поскольку мир движется к неизменяемой инфраструктуре, инструменты обучения, использующие подход синхронизации конфигурации, возможно, не будут лучшим использованием времени.
Еще раз повторю - доклад не об инструментах, а о подходах и принятии решений "от проблемы", а не от "инструмента" Отказ от ответственности: Этот доклад сложен тем, что он готовится для российской аудитории, которая работает в несколько специфических условиях.
Всех этих вещей мы коснемся во время презентации.
В России специфическое использование инфраструктуры, потому что люди в основном не живут на Амазонке.
Есть компании, которые там живут, но их мало.
И это ограничение.
Это нужно учитывать во всех отчетах, связанных с развертыванием инфраструктуры, чтобы не говорить: «Ребята, давайте в облако, в AWS все будет хорошо», а тут сидит толпа людей, которые не могут иди туда.
Российская аудитория кажется очень специфичной.
А те отчеты, которые принимаются в Европе, не всегда принимаются в России.
Возможно, это связано с особым восприятием этой аудитории.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Всем привет! Спасибо, что пришли послушать! Сегодня мы обсудим, почему я не рекомендую людям изучать Ansible. Давайте разберемся.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Что не так с Ansible? Давайте разберемся.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Еще несколько оговорок.
Первое предупреждение заключается в том, что данная презентация не предназначена для сравнения каких-либо инструментов.
То есть это не Ansible vs Terraform, Ansible vs CloudFormation, Ansible vs Chef и т. д. 
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Тогда вы, возможно, сейчас думаете: «О чем тогда это могло бытьЭ» 
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Еще один отказ от ответственности:
- Эта презентация основана на нашем опыте консалтингового агентства FivexL.
- Это именно то, что мы рекомендуем клиентам сегодня.
- Все сказанное в данной презентации является моим субъективным мнением, а также мнением моих коллег.
И это вполне прагматично.
- Серебряной пули тоже не существует, т. е.
то, что я говорю здесь, не нужно воспринимать идеалистически.
К этому нужно, как говорят британцы, отнестись скептически.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
И я опять не про Ансибл? 
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Давайте поговорим об Ансибле.
Мы перейдем на страницу Ansible. Я сделал этот снимок ее 2 дня назад, так что это совсем недавно.
Можем попытаться разобраться, что это за инструмент Ansible и для чего он используется.
На этой странице мы видим, что его можно использовать для развертывания приложений, управления конфигурацией и оркестрации задач.
И все это работает либо через OpenSSH, либо через WinRM. Но это не отвечает на вопрос: «Зачем нам его использовать, какую проблему он решаетЭ» 
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Итак, мы можем перейти на страницу вариантов использования.
Вы увидите ссылки, которые я предоставляю, в левом нижнем углу экрана.
Мы видим, что его рекомендуется использовать для инициализации серверов, управления их конфигурацией, а также для распространения там приложений.
И что-то можно сделать для обеспечения безопасности и оркестрации.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Наши клиенты часто приходят к нам с разными желаниями.
Они говорят: «Давайте воспользуемся этим инструментом».
А мы им говорим, что давайте отойдем от проблемы и разберемся в контексте.
Далее мы разберемся с методами, которые будут уместны в данном контексте.
А дальше выберем инструмент, т. е.
не будем начинать с инструмента.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
И если переварить все, что мы только что видели на слайдах относительно Ansible, то можно понять, что проблема в автоматизации ИТ-изменений.
Соответственно, под контекстом они подразумевают либо аппаратные серверы, либо виртуальные машины.
Предполагается использовать метод инфраструктуры как синхронизацию кода и конфигурации.
И они предлагают использовать инструмент Ansible. 
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Многие из вас думают, что с помощью Ansible можно сделать гораздо больше вещей.
Вы также можете настроить AWS. Kubernetes также возможен.
Вы также можете настроить HashiCorp Vault. Если хотите, вы можете сделать все с помощью Ansible. 
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Но тогда стоит задуматься о том, станет ли Ansible решением проблемы и в том контексте, который вы решаете.
То есть нужно отстраниться от проблемы.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
В противном случае мы можем оказаться в ситуации, когда мы пользуемся таким инструментом, как молоток, которым мы стучим повсюду и нам все кажется гвоздем.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Мы не хотим оказаться в такой ситуации.
Плюс каждый раз, когда ты немного выходишь за рамки мейнстрима, нужно думать о последствиях.
Поставщик, предлагающий вам инструмент, расскажет вам, как вы можете его использовать.
Вы можете попробовать влево и вправо и сделать что-то по-другому.
Но нужно всегда думать: «Я сейчас сделаю так, а потом начну что-то терять.
Если я пойду в другом направлении по сравнению с сообществом, то я потеряю именно то, чему научится сообщество, то есть потеряю некоторые инсайты».
Потом подумайте: «То, что я делаю, немного на стороне, каковы перспективы долгосрочной поддержки? Могу ли я найти кого-то, кто захочет работать с этим в будущем? Кроме того, ваш начальник может быть счастливее, если вы сосредоточитесь на чем-то полезном для бизнеса, а не на необходимости делать что-то второстепенное, когда вы можете использовать другой инструмент, который лучше подходит для этого.
Это вещи, над которыми стоит задуматься.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Именно поэтому в рамках этой конфигурации мы будем рассматривать Ansible как инструмент управления конфигурацией, который используется для подготовки серверов с целью распределения приложений по этим серверам.
Плюс вы можете запускать задачи, он это умеет. 
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Мы часто будем возвращаться к этому слайду и говорить о проблеме, которая остается неизменной, ведь мы тоже хотим автоматизировать изменения в ИТ.
Но в этой презентации я заявляю, что наш контекст меняется, наши методы меняются.
И поэтому выбор инструмента может быть разным.
Давайте разберемся.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Меня зовут Андрей Девяткин.
Я называю себя специалистом по облачной инженерии.
В частности, я работаю с инструментами AWS и HashiCorp. Этим летом я выступал на HashiConf, потому что это было очень круто.
Я также являюсь основателем консалтингового бренда FivexL. Я часто выступаю на конференциях.
А еще у нас есть англоязычный подкаст
, где мы с двумя друзьями рассказываем о том, что происходит сейчас, и пытаемся во всем разобраться.
Мы пытаемся выяснить, что работает, а что нет. Это честный разговор, который мы записываем.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
В этой презентации у нас будет много материала, который нам понадобится.
Эту презентацию я разделил на 5 этапов, которые мы сейчас и пройдём.
На первом этапе будем говорить, что единственной константой является изменение.
На втором этапе мы поговорим о том, что синхронизация конфигурации является неизбежным злом.
На третьем этапе мы поговорим о неизменяемой инфраструктуре и о том, что это, скорее всего, самая подходящая практика, которая у нас есть сегодня.
Давайте поговорим о том, что появляются новые пути, новые контексты и новые методы.
Плюс давайте поговорим о том, что будущее уже здесь.
Просто оно распределено неравномерно.
Поехали, начнем с первого.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Мы посмотрим на картину в целом и попытаемся понять, почему в ИТ происходят такие изменения, которые нам необходимо автоматизировать.
Представьте себе ситуацию, когда у потребителя есть какое-то желание, которое ему необходимо удовлетворить.
И есть предприниматель.
Предприниматель видит, что у потребителя есть какая-то потребность, которую он может удовлетворить и получить за это деньги.
Он тестирует какую-то бизнес-модель и предлагает потребителю продукт или услугу.
Теоретически в идеальных условиях можно сказать, что он построил машину по зарабатыванию денег, если ничего не изменится.
Но это неправда.
Поэтому у нас есть конкуренция, то есть есть люди, которые приходят на рынок, видят, что сделал предприниматель, и делают примерно то же самое, а может быть, даже лучше.
И они пытаются захватить рынок.
Например, мы начали с AWS в облаках, потом пришел Google, потом пришел Amazon, Alibaba, Яндекс, Сбер и т. д. Если бы не пришли другие игроки, то у Amazon была бы полная монополия, он бы просто зарабатывал деньги.
Но этого не происходит. Комментарий автора: Пришёл Google, потом пришёл Amazon, Alibaba - под Amazon я имел в виду Azure Поэтому вам постоянно приходится меняться, вам постоянно приходится конкурировать с другими.
Плюс сам рынок меняется.
Рынок может быть насыщен.
Кардинальные изменения на рынке могут произойти, например, потому, что в этом году во время пандемии было сложно всем перевозчикам и тем, кто зарабатывал на туризме.
Для них рынок фундаментально изменился.
Поэтому бизнесу постоянно приходится меняться.
И изменения будут постоянно продолжаться.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
И каждое изменение приносит энтропию.
Вы не можете просто измениться, с переменами всегда будет элемент хаоса.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
А если мы посмотрим словарь, то энтропия – это мера хаоса, это процесс разрушения, процесс деградации, когда материя во Вселенной приходит в предельное состояние, т. е.
когда все полностью переходит в хаос.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
И здесь нужно задаться вопросом: «Как позволить бизнесу быстро меняться, но при этом минимизировать энтропиюЭ» 
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
И тут мы можем подумать: «DevOps!» «Инфраструктура как код!» «Анзибль!», наконец.
Но что мы делаем сейчас? Мы просто выкрикиваем термины, которые приходят нам в голову.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
И мы должны следовать этой схеме.
Мы должны отойти от проблемы.
Мы сформулировали задачу — мы хотим минимизировать энтропию, потому что она будет мешать нам в пути, но при этом нужно постараться максимально автоматизировать все, что можно.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
В нашей области энтропию называют дрейфом конфигурации.
И впервые я встретил это определение, когда читал книгу Кейфа Морриса»
Андрей Девяткин"> Инфраструктура как код
«Это не он придумал это определение.
PuppetLabs были первыми, кто использовал этот термин, поэтому атрибуты им подходят.
Идея в том, что дрейф конфигурации накапливается и понемногу серверы отклоняются, отклоняются, отклоняются от первоначальной конфигурации из-за того, что люди что-то там делают руками, делают обновления, тестируют новые приложения, приложения могут что-то оставить после себя.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Тогда из-за энтропии, из-за дрейфа конфигурации сервер в какой-то момент может прийти в состояние сервера-снежинки.
Это то, что придумал Мартин Фаулер в свое время.
Сервер-снежинка — это сервер, прошедший точку невозврата.
Он уже настолько уникален, что никто не знает, как он был так настроен, ведь там уже столько всего накопилось.
И каждый раз к нему страшно прикасаться.
Он уникален и очень хрупкий.
Думаю, у многих были моменты, когда они сталкивались с такими серверами-снежинками.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
мы не можем устанавливать приложения на эти сервера и иметь 100% гарантию, что все пройдет гладко, потому что всегда есть что-то неизвестное.
Кроме того, каждый раз, когда возникает некоторая неопределенность и что-то идет не так, мы отвлекаем наши ресурсы от продуктивной работы: от работы над новым функционалом, от работы над улучшениями инфраструктуры, которые будут служить клиенту и позволят бизнесу двигаться вперед.
И, как я уже сказал, это влияет на нашу способность выпускать новые версии приложения.
Посмотрите на это как на технический долг в инфраструктуре.
Это также влияет на наше MTTR (среднее время восстановления), то есть на то, насколько быстро мы можем восстановиться после инцидента.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Я приведу вам несколько примеров.
Например, вы могли получить письмо счастья от AWS, в котором говорилось, что оборудование, на котором установлен ваш экземпляр EC2, ухудшилось, и они собираются его уничтожить.
А если у вас там будет такой сервер-снежинка, то день может стать гораздо интереснее, чем был.
На Amazon все не так плохо.
Вы можете сделать снимок, попытаться воссоздать его, и с большой вероятностью это получится.
А если у вас вдруг выйдет из строя жесткий диск на железном сервере, то это уже менее смешно.
Например, у вас был второй
и нужно все кардинально патчить.
И тут могут возникнуть различные казусы, потому что патчи не проходят, т. е.
вам сложно это сделать.
У моего коллеги Артема была ситуация с серверами-снежинками, на которых были драйверы графического процессора.
Эти серверы каким-то образом настраивались вручную, но как они это сделали, никто не знает. Необходимо было обновить драйвера графического процессора.
И это было великолепное приключение.
Это заняло гораздо больше времени, чем следовало бы.
Например, в вашей сети появился злоумышленник.
И вам нужно разобраться и разобраться, что происходило на этом сервере.
Эти файлы должны быть здесь или Вася их положил? Должны ли они находиться в этом состоянии и в этом каталоге или их свойства были изменены? Должно ли быть так? 
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Мы говорим сейчас в контексте серверов и виртуальных машин.
А господа, о которых мы говорили ранее, говорили в терминологии серверов и виртуальных машин начала 2010-х годов.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Так что же нам с этим делать? 
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Обычный способ — инфраструктура как код. А в книге «Инфраструктура как код» сформулированы 4 принципа:
- Все элементы инфраструктуры должны быть воспроизводимыми, то есть мы должны иметь возможность их воспроизводить.
- Поскольку мы можем их воспроизводить, мы должны иметь возможность их выбросить.
Они должны быть одноразовыми.
- А благодаря тому, что мы настраиваем в виде кода, наша инфраструктура будет согласованной.
- Плюс у него нет конечного состояния.
Когда мы проектируем нашу инфраструктуру, мы понимаем, что то, что мы знаем сегодня, ограничено и может измениться завтра.
Бизнес-контекст может измениться, бизнес-потребности могут измениться, поэтому то, что мы строим сегодня, не является чем-то высеченным в камне.
Это то, что изменится, поэтому нам нужно подумать о том, как мы изменим это завтра.
И вы должны быть готовы это изменить.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
А если мы посмотрим на определение из Википедии, там сказано, что инфраструктура как код — это когда мы описываем всю нашу инфраструктуру в файлах.
Эти файлы машиночитаемы, то есть некоторые инструменты могут прочитать эти файлы и затем перевести все, что в этих файлах написано, а затем пойти и настроить системы так, как мы это описали.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Все те же приемы, т. е.
так же, как мы разрабатывали код, как мы разрабатывали продукт, мы делаем то же самое с инфраструктурой, используя те же приемы.
Мы можем проводить обзоры кода, запускать CI и так далее.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
И наш шаблон медленно заполняется, т. е.
мы говорим в контексте аппаратных серверов и виртуальных машин.
Мы используем infra в качестве кода.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
А про синхронизацию конфигурации я обещал рассказать и давайте об этом поговорим.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Было несколько поколений инструментов настройки.
Не буду называть численность этого поколения, но было конкретно выделенное поколение: Марионетка, Шеф.
Ansible и SaltStack появились чуть позже.
Это именно те инструменты, которые работали с синхронизацией конфигурации.
Сейчас мы увидим, что это значит. Специфика этих инструментов заключается в том, что они автоматизируют подготовку.
И чаще всего им требуется небольшая дополнительная настройка.
В случае с некоторыми инструментами вам необходимо установить агент на сервер, в других нужно открыть брандмауэр, чтобы он мог заходить туда, например, через SSH-порт и делать то, что хочет. 
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Эту картинку я взял из статей Мартина Фаулера.
Это отличные картинки, ссылки ниже, если вы хотите прочитать всю статью.
Именно так работает конфигурация синхронизации.
У нас есть образ сервера.
Загружаем его на сервер.
Наш сервер запущен.
А затем мы используем инструмент синхронизации конфигурации, чтобы применить изменения.
Вот почему это так называется.
У нас есть конфигурация в нашем репозитории, и мы запускаем ее для синхронизации на сервере.
И каждый раз, когда нам нужно сделать что-то новое, мы меняем это в репозитории и запускаем инструмент. И он синхронизирует его на сервере.
Если мы не уверены, как он туда попал, мы запускаем его еще раз и делаем еще одну синхронизацию.
Опасность здесь в том, что мы не отслеживаем все файлы на сервере.
Всегда есть вероятность, что кто-то пошел и исправил это своими руками, и это выходит за рамки ответственности инструмента.
Все это накапливается и накапливается.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
И это может привести к возникновению спирали страха перед автоматизацией.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Как это работает? Вы вносите изменения вне своего инструмента, с которым синхронизируете конфигурацию.
Ваши серверы становятся немного непоследовательными.
И тогда вы начинаете бояться запускать свой инструмент, потому что что-то может пойти не так: что-то может сломаться, если вы его запустите.
Поэтому в следующий раз, когда вам понадобится внести изменения, вы сделаете их снова вручную, серверы станут еще более противоречивыми, и вы еще больше боитесь запускать свой инструмент. Таким образом, ваш сервер спускается по спирали вниз к состоянию сервера-снежинки.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Давайте посмотрим, как человеческая мысль развивалась дальше.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Потом те же ребята из ThoughtWorks придумали сервер Phoenix, 
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Идея та же: делаем все то же самое, что и при настройке синхронизации, но в какой-то момент периодически убиваем этот сервер, полностью удаляем с него все, перерисовываем сервер и затем запускаем наш инструмент. Таким образом, мы сбрасываем накопившийся дрейф конфигурации.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Мы можем сделать еще один шаг вперед. 
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Мы можем поместить все изменения, все конфигурации, которые у нас есть в образ сервера и накатить прямо на сервер.
И после этого не вносим никаких изменений, а просто удаляем один раз в определенный промежуток времени.
Если нам нужно внести какие-то новые изменения, мы создаем новый образ сервера и перекатываем его на сервер.
То есть мы не синхронизируем конфигурацию, мы либо поднимаем новую виртуалку из нового образа, либо вайпируем (вайпируем) сервер и выкатываем новый образ.
Поэтому для переключения трафика требуется несколько серверов.
Но за счет этого вы минимизируете количество дрейфа конфигурации.
И еще одно преимущество, которое вы от этого получаете, заключается в том, что люди больше не хотят заходить на сервер через SSH, потому что они знают, что в какой-то момент сервер будет уничтожен и все внесенные ими изменения будут потеряны.
И вместо того, чтобы спросить, где находится SSH-ключ, вас уже спрашивают, где спек, из которого будет скомпилирован образ для этого сервера.
И это новый уровень диалога.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
- Если говорить о выгоде, то, как мы уже говорили, дрейф нашей конфигурации стремится к нулю.
- У нас есть возможность быстрого масштабирования.
Например, в AWS есть группа автоматического масштабирования.
Вам нужно поднять новые виртуальные машины.
И вы не будете их вручную запускать и запускать, а потом настраивать инструментом синхронизации конфигурации, а потом просто пускать в работу.
Если у вас почти все заключено в ami (шаблон виртуальной машины), то ваша группа автомасштабирования может автоматически поднимать и убивать за вас новые серверы.
Вы ничего не теряете, потому что они всегда одинаковы.
Я не говорю здесь ничего нового.
Это запеканка против жарки, крупный рогатый скот против домашних животных.
Все то, что говорилось много раз на конференциях.
- И ваш уровень безопасности возрастает. Представьте, что в вашу сеть проник злоумышленник.
И ты этого не заметил.
И вы обновляете все свои серверы каждую неделю.
И таким образом, все, что он установил, вы стираете.
И ему придется каждую неделю повторять все одни и те же мероприятия, чтобы хоть как-то закрепиться в вашей инфраструктуре.
Плюс, что делают те, кто нападает? Они нападают и сидят очень тихо.
И они нумеруют все, что у вас есть: «Ага, веб-сервер на том IP-адресе, это на том IP-адресе».
И для тебя все постоянно меняется.
Вы постоянно меняете эти серверы, меняете IP-адреса, если находитесь в облаке.
И им гораздо труднее делать то, ради чего они пришли.
Например, тонкие боковые движения в вашей сети становятся намного сложнее.
- Плюс, в связи с тем, что вам нужно минимальное время для подготовки сервера, поскольку все уже есть в образе, вы можете использовать такие варианты, как спотовый экземпляр EC2, если вы находитесь в облаке.
Даже если спотовый экземпляр вырвется из-под вас, ничего страшного.
Он поднимется в другой зоне, потому что там все остается по-прежнему, т. е.
вы ничего не теряете.
У вас будет 2 минуты на переключение трафика и удаление данного инстанса из ротации.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
И тут вы можете подумать: «Если я использую Ansible, но при этом довольно часто убиваю свои серверы, то, может быть, этого достаточноЭ» 
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Может быть.
Как я уже говорил, эта презентация очень практична.
И мы не идеалисты, мы практики.
Умные книги всегда рисуют вам красивую картину, но жизнь всегда сложнее.
Иногда приходишь к клиенту и думаешь: «Боже мой, что ты наделал! Ужасный!".
Конечно, в глаза людям этого не скажешь.
Нам нужно поговорить и понять, почему они это сделали.
Скорее всего у них были свои причины.
Если бы у всех нас были идеальные условия, мы бы построили идеальные системы.
Но условия не идеальны и часто приходится приспосабливаться.
И как сказал нам угрюмый кот, возможно, это даст вам 80% пользы за 20% усилий.
Каждый выбирает свой путь, основываясь на рамках, о которых мы только что говорили.
Андрей Девяткин" alt="Почему я советую людям не изучать Ansible. Переход от синхронизации конфигурации к неизменяемой инфраструктуре.
Андрей Девяткин">
Мы понимаем нашу проблему, наш контекст, наши ограничения.
И теперь мы уже видим, что есть новые методы, из которых мы можем выбирать.
И когда мы работаем в контексте Теги: #terraform #DevOps #ansible #immutableинфраструктура
-
Октановое Число
19 Dec, 24 -
Поддержка Доставки Электронной Почты
19 Dec, 24 -
Интервью О Прошлом И Будущем Библиотек C++
19 Dec, 24 -
Пакет Для Вас: История Подписного Бизнеса
19 Dec, 24 -
Qip Придумает Для Вас Имя?
19 Dec, 24 -
Как Прошел Девфест Сибирь 2017
19 Dec, 24
