Прежде чем мы окунёмся в само определение некой SOE, давайте изучим вызовы масштабирования среды Linux в отсутствии стандартов. Некое исследование этого будет способствовать нашему пониманию этого определения самого по себе, а также тому как устанавливать верные стандарты для заданного сценария.

Важно учитывать, что многие проблемы, с которыми сталкиваются предприятия из технологической отрасли (будь то Linux, или нечто иное) не начинаются сами по себе. На самых ранних этапах роста, в действительности, многие системы и процессы полностью устойчивы и в нашем следующем разделе мы рассмотрим такой ранний этап роста среды как некий предшественник для понимания проблем, связанных с крупномасштабным ростом.

Начальный рост нестандартной среды

В удивительно большом числе предприятий среды Linux начинают свою жизнь без какого бы то ни было вида стандартизации. Зачастую они органично растут со временем. Развёртывания начинаются с небольших, возможно только чтобы покрыть лишь пригоршню основных функций, но время идёт и требования растут, то же происходит и со средой. Умудрённые системные администраторы часто вносят изменения вручную на основе индивидуального подхода к каждому серверу, развёртывая новые службы и наращивая штат своих серверов по мере того как это диктуют дела.

Такой органический рост является является путём наименьшего сопротивления для большинства компаний - сроки выполнения проекта зачатую бывают жёсткими, а кроме того как бюджет так и ресурсы ограничены. Следовательно, при наличии некого квалифицированного ресурса Linux такой ресурс способен оказывать содействие практически во всех необходимых задачах, начиная с проблем сопровождения вплоть до сложных стеков приложений. Это экономит множество усилий и средств, затрачиваемых на построение и действенно применяет обученный персонал, так как тот может использоваться для решения насущных проблем и развёртывания, вместо того чтобы тратить время на проектирование построения. Следовательно, это достаточно просто и имеет смысл, причём автор этих строк испытал это в нескольких компаниях, причём даже в выдающихся многонациональных.

Воздействие нестандартных сред

Давайте рассмотрим это поглубже с некой технической точки зрения. Существует множество разновидностей Linux, огромное число приложений, выполняющих (на неком верхнем уровне) одну и ту же функцию и бесчисленное число способов решения заданной проблемы. Например, когда вы желаете создать сценарий для некой задачи, пишите ли вы его на языке сценариев оболочки, Perl, Python или Ruby? Для некоторых задач все они способны достичь желательного конечного результата. Различные люди имеют различные предпочитаемые ими пути подходов к задачам и различные предпочтительные технологические решения и зачастую обнаруживается, что некая среда Linux была собрана при помощи технологии, которая была предпочтением того месяца, когда она создавалась или была предпочтительной для того сотрудника, который отвечал за её решение. В этом подходе нет ничего дурного как в самом по себе и он не является причиной проблем.

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

Масштабирование нестандартных сред

Когда общее число серверов достигает сотен, никогда не говоря уж о тысячах (и даже больше!) весь этот органический процесс ломается. То, что некогда было интересным испытанием, становится трудоёмким и утомительным, причём даже вызывает стресс. Имеющаяся кривая для новых членов команды является крутой. Новый набор может оказаться в разрозненной среде со множеством подлежащих изучению различных технологий и возможно с длительным периодом обучения прежде чем они смогут стать реально действенными. Долго служившие члены команды могут в итоге превратиться в кладезь знаний и в случае их ухода от дел это может вызывать проблемы с преемственностью. Проблемы и простои превращаются в более многочисленные по мере роста предприятия без стандартов неким неконтролируемым образом, а устранение неисправностей превращается в продолжительные усилия - и вряд ли идеальным при попытке достижения согласованного обслуживания без простоев 99.99%, когда имеет значение каждая секунда простоя! Итак, в своём следующем разделе мы рассмотрим как решать эти задачи с применением SOE.

На данный момент мы осознали свои требования в стандартизации. Сборка некой подходящей SOE состоит в:

В конце концов, когда некая среда является краткой в своём определении, тогда всем вовлечённым в неё проще в ней разобраться и легче с ней работать. Это, в свою очередь, означает более быстрое выполнение задач, причём с большей простотой. Короче говоря, стандартизация способна привносить сбережение средств и улучшать надёжность.

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

Давайте продолжим изучать это более подробно. Всякое предприятие обладает определёнными запросами к своим средам ИТ, будь они основаны на Linux, Windows, FreeBSD или прочих технологиях. Порой они хорошо осознаны и документированы, а порой они просто подразумеваются - то есть все предполагают, что имеющаяся среда соответствует таким стандартам, однако они официально не определены. Зачастую эти требования содержат в себе:

Конечно же, всё это требования верхнего уровня и зачастую они пересекаются друг с другом. Давйте изучим их более подробно.

Безопасность

Безопасность в неком окружении устанавливается различными составляющими. Давайте рассмотрим некоторые вопросы, чтобы понять какие факторы вовлечены:

Теперь, в некой нестандартной среде, как мы можем и вправду сказать что все эти требования принудительно выполняются о всех ваших серверах Linux? Для этого требуется большая уверенность в том, что все они были собраны аналогично, что к ним применены одинаковы параметры безопасности и что никто и никогда не возвращался повторно в это окружение для того чтобы изменить что- то. Короче говоря, обеспечение соответствия требует достаточно частого аудита.

Однако, когда ваша среда была стандартизирована, а все серверы были собраны из общего источника или с применением общего инструментария автоматизации (мы продемонстрируем это позднее в нашей книге), намного проще ответственно заявить что ваш штат Linux безопасен.

Безопасность к тому же усиливается исправлениями, которые обеспечивают что вы не запускаете никакое программное обеспечение с уязвимостями, которые способны позволить атакующим скомпрометировать ваши серверы. Некоторые дистрибутивы Linux обладают более длительным временем жизни чем иные. К примеру, выпуски Red Hat Enterprise Linux (и такие производные как CentOS), а также Ubuntu LTS все обладают длительными, предсказуемыми циклами жизни и являют собой хороших претендентов для вашего штата Linux.

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

Даже когда такое обновление на более новую версию Fedora осуществлено, порой пакеты становятся осиротевшими - то есть, допустим, они не включены в более новый выпуск. Это может стать причиной того, что они были замещены другими пакетами. независимо от его причины, обновление одного дистрибутива на другой может вызывать ложное ощущение безопасности и его следует избегать до тех пор пока оно не будет целиком исследовано. Таким образом, стандартизация способствует обеспечению хороших практик безопасности.

Надёжность

Многие предприятия ожидают от своих ИТ операций обязаны быть поднятыми 99.99% от общего времени (или лучше). Часть необходимого маршрута достижения этого состоит в надёжном программном обеспечении, приложении или надлежащем исправлении ошибок и хорошо определённых процедур устранения неисправностей. Это обеспечивает что в случае самого худшего сценария некого бездействия является настолько минимальным, насколько это возможно.

И снова здесь помогает стандартизация - как мы уже обсуждали в своём предыдущем разделе по безопасности, хороший выбор лежащей в основании операционной системы обеспечивает что у вас имеется постоянный доступ в исправлению ошибок и обновлений и раз вы знаете что ваши дела требуют некой резервной копии производителя чтобы обеспечить непрерывность ведения дел, тогда становится существенным именно выбор операционной системы Linux с неким контрактом сопровождения (доступным, например, от Red Hat или Canonical).

Точно также, когда все серверы собираются в соответствии с хорошо определёнными и осознанным стандартом, исполнение в нём изменений должно давать предсказуемые результаты, поскольку все знают с чем они работают. Когда же все серверы собраны слега различно, тогда изменения или улучшения из лучших побуждений могли бы иметь непреднамеренные последствия и в результате затратное время простоя.

И вновь, при стандартизации, даже когда происходит наихудший сценарий, все вовлечённые в него должны знать как подходить к данной проблеме так как все они будут знать что все серверы должны быть собраны на определённом базовом образе и имеют определённую конфигурацию. Такое знание и доверие снижают время устранения неисправностей и в конечном счёте времени простоя.

Масштабирование

все предприятия желают роста своего бизнеса и в большинстве случаев это означает что среды ИТ требуют масштабирования чтобы иметь дело с растущими запросами. В некой среде, в которой серверы собираются нестандартно, масштабирование некого окружения становится более проблематичным.

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

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

Срок службы

Порой при развёртывании некой службы требуется определённая версия программного обеспечения. Давайте возьмём в качестве примера некое веб приложение, которое исполняет PHP. Теперь допустим что конкретно ваше предприятие обладает, по историческим причинам, стандартизацию на основании CentOS 6 (или RHEL 6). Эти операционные системы снабжаются лишь PHP 5.3, что означает, что если вы внезапно возьмёте некое приложение, которое поддерживается лишь PHP 7.0 или выше, вам потребуется решить как разместить его.

Одним несомненно очевидным решением было бы раскрутить образ виртуальной машины Fedora. После этого он бы разделял технологии, аналогичные CentOS и RHEL и обладал бы более современными включёнными в его состав библиотеками. Автор этих строк имеет непосредственный опыт такого рода решений в некоторых ролях! Однако давайте взглянем на картину шире.

RHEL (а также основанный на нём CentOS) обладают жизненным пространством около 10 лет, в зависимости от того момента, в котором вы приобрели их. В некотором предприятии это ценное утверждение - оно означает, что вы можете обеспечить то, что ваши сборки серверов будут обладать исправлениями и сопровождаться до 10 лет (а возможно и больше с расширенной поддержкой жизненного цикла) от того момента, когда вы их собрали. Это хорошо согласуется с нашими предыдущими моментами относительно безопасности, надёжности и поддержки (обсуждаемой в следующем разделе).

Однако все серверы, которые вы собираете на Fedora будут обладать продолжительностью жизни где- то в районе 12- 18 месяцев (в зависимости от цикла выпуска Fedora) - для некой установки предприятия необходимость повторного развёртывания серверов, скажем, через 12- 18 месяцев это совершенно не нужная головная боль.

Это вовсе не означает, что никогда не бывает потребности в развёртывании Fedora или любой иной быстро перемещающейся платформы Linux - просто нужно постулировать, что в неком предприятии, в котором жизненно важны безопасность и надёжность, маловероятно что вы пожелаете некую платформу Linux с каким- то коротким жизненным циклом, ибо получаемый короткий промежуток (поддержки более новых библиотек) будет изменён через 12- 18 месяцев с угрозой отсутствия обновлений и наличием потребности повторного построения/ обновления вашей платформы.

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

В конце концов, выбор за вами и вы должны устанавливать какой путь по вашему мнению снабжает вас наибольшими преимуществами ведения дел, не подвергая риску свои действия. Частью стандартизации является принятие обоснованных, рациональных решений в отношении технологий и их принятии там, где это возможно, а ваш стандарт может содержать частые перестроения, делающие возможным применение быстро движущихся систем, подобных Fedora. Точно так же вы можете принять решение что ваш стандарт состоит в том, чтобы серверы будут обладать длительным сроком службы и обновляться на месте, а в этом случае вам будет лучше выбрать такую операционную систему как LTS выпуск Ubuntu, либо RHEL/CentOS.

В своём следующем разделе мы рассмотрим более детально в чём состоят преимущества понятия поддержки SOE.

Наличие поддержки

Как мы уже обсуждали, обладание некой стандартной средой привносится с его двумя преимуществами. Первое состоит в в том, что правильно выбранная платформа означает длительную поддержку производителем жизненного цикла. Это, в свою очередь, означает более длительное сопровождение либо от самого производителя (в случае продуктв подобного RHEL), либо от его сообщества (как в случае CentOS). некоторые операционные системы, такие как сервер Ubuntu доступны как с поддержкой сообщества, так и по платному контракту от Canonical.

Сопровождаемость, однако, означает не только поддержку со стороны своего производителя или от имеющегося на просторах сообщества Linux. Помните, в неком предприятии что ваш персонал выступает фронтом поддержки прежде чем в неё вступит кто-либо ещё извне. Теперь представьте себе что у вас имеется команда спецов персонала Linux и предоставленный им штат серверов, представленный из Debian, SuSe, CentOS, Fedora, Ubuntu и Manjaro. Между ними существуют схожести, но также и гигантское число различий. Помимо всего прочего, имеется четыре различных диспетчера пакетов для установки и управления пакетами программного обеспечения и это лишь один пример.

Хотя всё это и целиком поддерживается, это представляет для вашего персонала ещё большую проблему и означает, что для любого кто присоединится к вашей компании вам потребуется как широкий, так и глубокий набор опыта Linux - либо такой, либо некий затратный процесс вводного обучения чтобы дать ему возможность встроиться.

при некой стандартизованной среде вы можете получить более одной операционной системы, однако если вы способны удовлетворить все свои потребности, скажем, CentOS 7 и сервером Ubuntu 18.04 LTS (и знаете что вы прикрыты на несколько последующих лет по причине своего выбора), тогда вы немедленно снижаете нагрузку на свою команду Linux и дадите им больше времени на более творческое решение задач (например, автоматизации решений при помощи Ansible!) и меньше времени на уточнение нюансов между операционными системами. Как мы уже обсуждали, в случае возникновения некой проблемы они окажутся более знакомыми с каждой из ОС, а следовательно потратят меньше времени на отладку, снижая время простоя.

Это подводит нас к предмету простоты применения в масштабе и мы представим такой обзор в своём следующем разделе.

Простота применения

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

Издожив те вызовы,которые помогает решать SOE мы в своём следующем разделе продолжим рассматривать саму анатомию такой среды чтобы разобраться с ней с технической точки зрения.

Теперь, когда мы изучили основные причины того почему SOE важна для определённого предприятия и осознаём на верхнем уровне имеющиеся решения этих задач, давайте подробнее рассмотрим SOE. Мы начнём с определения того что такое SOE сама по себе.

Давайте по- быстрому рассмотрим ей с более практичной точки зрения. Как мы уже сказали, некая SOE это понятие, причём оно не абсолютное. Это, в самом простом приближении, некий общий образ сервера или стандарт сборки, который разворачивается по большому числу серверов во всей компании. В таком случае все необходимые задачи выполняются неким известным, документированным образом.

Для начала существует основная базовая операционная система - и, как мы уже и обсуждали, имеются сотни дистрибутивов Linux для выбора. Некоторые очень похожи с точки зрения системного администрирования (например, Debian и Ubuntu), в то время как некоторые заметно отличаются (такие как Fedora и Manjaro). Посредством простого примера, допустим, вы желаете установить Apache Web Server на Ubuntu 18.04 LTS - вы вводите следующие команды:

# sudo apt-get update
# sudo apt-get install apache2
		

Теперь, когда вы хотите сделать те же самые вещи, но в CentOS 7, вы введёте:

# sudo yum install httpd
		

Как вы видите, нет ничего общего между этими командами - даже в самих названиях пакетов, хотя в конечном итоге в обоих случаях конечным результатом является некая установка Apache. В небольшом масштабе это не является какой бы то ни было проблемой, но когда сервера многочисленны и по мере роста числа серверов становится сложным управление такой средой.

Сама базовая операционная система это лишь начало. Наш приведённый выше пример устанавливал Apache, хотя мы могли бы также установить nginx или даже lighttpd. Все они, кстати говоря, также веб серверы.

Далее имеется настройка. Хотите ли вы чтобы пользователи имели возможность регистрации от имени root поверх SSH? Требуется ли вам определённый уровень регистрации для целей аудита или отладки? Требуется ли вам локальная или централизованная аутентификация? Этот список бесчисленный и, как вы можете видеть, если его не проверять, он может приводить к огромной головной боли.

Именно здесь приходит SOE. По сути, это некая спецификация и на самом верхнем уровне она может быть, допустим, такой:

Приведённое выше это просто некий пример и он не в коем случае не является всеобъемлющим; однако он должен начать давать вам некую идею того как выглядит SOE на верхнем уровне. По мере нашего продвижения по этой главе мы будем всё глубже погружаться в данный предмет и предоставлять дополнительные образцы чтобы выстроит более чёткое определение.

Прежде чем мы продолжим, давайте рассмотрим слегка более подробно то что нам следует включать в свою среду. В своём предыдущем разделе мы вывели очень упрощённое определение для некой SOE. Частью любого хорошего процесса работы SOE является обладание предварительно определённой сборки операционной системы которая может быть развёрнута в любой момент. Это может быть достигнуто множеством способом и мы обсудим их позднее в этой книге- тем не менее, пока давайте предположим был собран, как предложено ранее, некий базовый образ Ubuntu 18.04 LTS. Что мы интегрируем в эту стандартную сборку?

Например, мы знаем что наша политика регистрации намерена применяться для нашей организации - следовательно, когда такая сборка создана, следует индивидуализировать /etc/ssh/sshd_config чтобы она содержала PermitRootLogin no и PasswordAuthentication no. Не существует никакой возможности в выполнении этого этапа в конфигурации после развёртывания, поскольку это должно выполняться для абсолютно всех отдельных развёртываний. проще говоря, это было бы не эффективно.

Существует также важные подлежащие рассмотрению вопросы автоматизации для нашего образа операционной системы. Мы знаем, что Ansible сам по себе осуществляет взаимодействие поверх SSH и поэтому мы знаем что мы намерены запросить некий вид полномочий (скорее всего это будет основано на ключах SSH) под запуск Ansible для всех развёртываемых серверов. Нет смысла в том чтобы вручную развёртывать учётные данные для каждой отдельной машины прежде чем вы сможете на самом деле выполнять автоматизацию, а потому важно принимать во внимание тот вид аутентификации который вы бы желали применять в Ansible (например, основаны на пароле или на ключах SSH) и создать необходимую учётную запись и соответствующие полномочия когда вы собираете свой образ. Точный метод для выполнения этого будет зависеть от ваших стандартов корпоративной безопасности, но я бы выступил за некое следующее потенциальное решение:

Смещаясь с учётных записей пользователя и аутентификации, также рассмотрите NCPA (Nagios Cross-Platform Agent, межплатформенного агента Nagios). Из своего примера мы знаем, что должен быть установлен агент NCPA и определён соответствующий жетон (token) с тем, чтобы он имел возможность взаимодействия с сервером Nagios. {Прим. пер.: или аналогичных действий для Zabbix.} И снова , нет никакого смысла выполнять это для каждого сервера по отдельности после развёртывания своего стандартного образа.

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

В качестве здравого принципа, ваши стандартные сборки должны быть настолько простыми и легковесными, насколько это возможно. Нет смысла запускать в них дополнительные службы, отнимающие память и циклы ЦПУ в случае их избыточности. Точно так же, наличие не настроенных служб увеличивает имеющуюся поверхность атак для любого потенциального взломщика и потому по причинам безопасности рекомендуется оставлять их за бортом.

Короче говоря, наша стандартная сборка должна содержать лишь настройки и/ или службы, которые рассматриваются как общие для всех развёртываемых серверов. Такой подход порой носит название Just enough Operating System (Вполне достаточной операционной системы) или JeOS для кратности и это наилучшая отправная точка для вашей SOE.

Обладая пониманием необходимых базовых принципов SOE мы продолжим в своём следующем разделе более подробно рассматривать те преимущества,которые вносит SOEв вашем предприятии.

На данный момент вы должны обладать неким пониманием того что из себя представляет SOE и как она привносит экономию масштабирования и большую эффективность среды Linux. Теперь давайте соберём её и рассмотрим более подробно на неком примере демонстрации важности стандартизации.

Сказать что в среде Linux имеются общие черты то же самое что сказать, что все составляющие её серверы обладают общими атрибутами и свойствами. Например, все они могут быть собраны на Linux Ubuntu или все они могут иметь в качестве своего веб сервера Apache.

Мы можем изучить это понятие на неком примере. Допустим, что у вас имеются 10 веб серверов Linux позади некого балансировщика нагрузки и что все они обслуживают простое статическое содержимое. Всё работает отлично, однако затем наказано некое изменение конфигурации. Допустим, оно состоит в изменении значения корня документов в каждом из веб серверов для указания на некий новый выпуск кода, который был развёрнут в них другой командой.

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

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

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

Теперь давайте накинем на наши работы гаечный ключ. Что если по неизвестным нам причинам некто собрал пять наших веб серверов при помощи Apache под CentOS 7, а для остальных пяти применил nginx под Ubuntu 18.04 LTS? Конечный результат был бы, по завершению, тем же самым - на базовом уровне оба они являются веб серверами. Тем не менее, если вы желаете изменить корень документов в Apache под CentOS 7, вам понадобится проделать следующее:

Когда вам приходится выполнять те же самые моменты для nginx под Ubuntu 18.04 LTS, вы бы проделали следующее:

Как вы могли увидеть из этого достаточно упрощённого (хотя и натянутого) примера, отсутствие единообразия является злом для автоматизации. Чтобы справиться с этим случаем, вам придётся проделать следующее:

Таким образом, наш сценарий становится сложным, более трудным для его написания и сопровождения и, несомненно, более сложным в превращении в надёжный.

Хотя этот частный пример вряд ли встретится на вашем жизненном пути, он служит для выделения важного момента - автоматизацию намного проще реализовывать когда ваша среда собирается в соответствии с заданным стандартом. Когда предпринято решение что все веб серверы основываются на CentOS 7 для запуска Apache 2 и имеется надлежащая конфигурация сайта с названием после соответствующего имени службы, тогда наша автоматизация становится намного более простой. Действительно, вы даже имеете возможность запуска простой команды sed для выполнения необходимых изменений; например, предположим, что новое веб приложение было развёрнуто в /var/www/newapp:

# sed -i 's!DocumentRoot.*!DocumentRoot /var/www/newapp!g' /etc/httpd/conf.d/webservice.conf
# systemctl reload httpd.service
		

Никакое определение среды не требуется вовсе - всего лишь две простые команды оболочки. Это может стать основой реального простого сценария автоматизации для запуска либо в каждом из 10 серверов по очереди или удалённо через SSH. В любом случае, наша задача автоматизации теперь очень проста и демонстрирует нам насколько важно единообразие. Что ещё важнее, SOE сама по себе очень естественно предоставляет такую общность. Отсутствие общности не просто делает автоматизацию сложной по ходу дела - оно также препятствует проверкам, часто деформируя тесты, ибо они могут быть не представительны при различии сред.

В своей следующей части данной главы мы выполним сборку отталкиваясь от этих знаний чтобы показать насколько SOE благоприятствует самому процессу проверок.

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

Действительно, одной из решённых задач, выставляемых такими платформами контейнеризации как Docker, заключалась именно в этом, а следовательно переносимость составляет центральное свойство контейнерных сред. Развёрнутый в Docker код собирается поверх некого образа контейнера, который, проще говоря, является урезанным образом операционной системы (помните JeOS?). По сути, это на самом деле крошечная SOE, работающая лишь в контейнере вместо какого- то сервера голого железа или виртуальной машины. Тем не менее, стоит учитывать, что если переносимость посредством стандартизации среды является ключевой характеристикой контейнерных технологий, то мы не должны пытаться добиваться этого повсеместно, вне зависимости от своей инфраструктуры.

В конце концов, когда установленная конфигурация промышленных серверов отличается от той что имеется в пред производственной, тогда как подтверждать саму проверку? Когда предустановочная среда была собрана на CentOS 7.6, а ваша промышленная среда идёт на шаг позади с CentOS 7.4, тогда способны ли мы и в самом деле гарантировать что некий успешный результат проверки в одной среде обеспечит её для прочих? На бумаге это должно работать, однако при фундаментальных отличиях в версиях программного обеспечения и библиотек между вашими средами это может никогда не обеспечиваться. Именно по этой причине мы даже рассматриваем возможные отличия в файлах настроек и установленном программном обеспечении.

Следовательно здесь способна прийти на помощь SOE - когда все среды построены по одним и тем же стандартам, тогда в теории они должны быть идентичными. Те из вас, кто обладает зорким взглядом, заметят применение слова должны в нашем предыдущем предложении и для этого имеются веские основания. SOE это значительный шаг в сторону определения необходимого решения в отношении неудачных проверок, но это ещё не всё.

Некая среда является единым стандартом только пока никто не изменяет её, а когда все пользователи обладают полномочиями уровня администратора, тогда кто- то запросто (из лучших побуждений или ещё по какой- то причине) зарегистрирваться и внести изменения, которые означают отклонение данной среды от имеющегося стандарта.

Ответом на данную проблему является автоматизация - SOE выполняется не только для продвижения и внедрения автоматизации, но также полагается на неё для поддержки установленного уровня стандартизации, для которого она и требовалась в самую первую очередь. И действительно, именно в этом и состоит предпосылка данной книги - среда должна быть стандартизована настолько, насколько возможно, причём при этом столько, сколько только можно изменений должны быть автоматизированы.

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

То же самое справедливо и для операционных систем - некоторые организации могут полагаться на ту поддержку, которая предоставляется Red Hat Enterprise Linux, в то время как прочие не нуждаются в ней, а вместо этого им требуется быстро развивающиеся технологии переднего края, как, скажем, Fedora. Не существует верного или ошибочного способа для определения некого стандарта, до тех пор, пока он отвечает потребностям поддерживаемых им служб. До сих пор мы уделяли большое внимание общности и стандартам; тем не менее всегда существуют граничные случаи, когда требуется альтернативное решение. В своём следующем разделе мы установим как узнавать о том когда вам следует отклоняться от ваших стандартов.

Было бы легко переоценить имеющиеся преимущества стандартизации и они, несомненно, необходимы для действенности автоматизации. Тем не менее, как и всё прочее, они могут заходить слишком далеко. Нет смысла, например, собирать в 2019 году серверы на Red Hat Enterprise Linux 5.7 просто потому, что он когда- то был принят в качестве стандарта (теперь он End of Life и более не поддерживается и не сопровождается). Аналогично, время от времени производители программного обеспечения будут квалифицировать свой продукт под определённые дистрибутивы Linux или стеки приложений и не будут предоставлять поддержки когда их программное обеспечение не работает в подобной экосистеме.

Существуют варианты когда отклонения от SOE просто необходимы, но при этом они должны осуществляться неким управляемым образом. Например, когда все дела строятся поверх своего щатат серверов Linux Ubuntu 18.04, а затем приобретён некий новый стек программного обеспечения, который квалификирован лишь под RHEL 7, ясно что необходимо приступать к сборкам на RHEL 7. Они, тем не менее, должны быть частью некого нового набора стандартов по мозможности и превратиться во вторую SOE.

К примеру, когда эталонное тестирование по усилению безопасности CIS применяется к SOE Ubuntu, тогда его эквивалент должен применяться также и к RHEL. Аналогично, когда ваш бизнес стандартизован под nginx, то его и следует применять в вашем окружении пока нет веских оснований не делать этого (подсказка: веская причина состоит не в том что это будет новый и сексуально привлекательный продукт, а в том что он решает реальную проблему или как- то что- то улучшает ощутимым образом).

Это в результате приводит к тому что ваш бизнес переходит с одной SOE Linux к двум, что всё ещё в целом управляемо и несомненно лучше возврата к методологиям органичного роста, которые мешают действенной автоматизации.

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

Всегда будут существовать веские причины отклонения от некого стандарта; просто ищите те выгоды для ведения дел, которые это приносит, будь то поддержка поставщика, более низкие требования к ресурсам (а следовательно экономия электроэнергии и средств), более длительное время поддержки или нечто иное. Старайтесь избегать подобного лишь по той причине, что новая технология блестящая. Пока вы помните об этом факте, вы будете принимать верные решения относительно отклонения от своих стандартов. В своём следующем разделе этой главы мы изучим постоянное сопровождение SOE.

Хотя мы и рассмотрим позднее в этой книге исправления и сопровождение более подробно, они заслуживают упоминания о себе уже здесь, поскольку хорошо вписываются в обсуждение единообразия и отклонений.

Если не происходит ничего иного, вам придётся вносить исправления в свою среду Linux. По причинам безопасности это уже является достойной практикой даже в некой стерильной среде. Допустим, ваше окружение целиком выполнено виртуальными машинами и вы какое- то время назад решили принять в качестве стандарта CentOS 7.2. Вы создали некую виртуальную машину, выполнили все необходимые шаги по её превращению в свой образ SOE и затем преобразовали её в некий шаблон для вашей виртуальной среды. Она превращается в вашу золотую сборку. Всё идёт по плану.

Однако CentOS 7.2 была выпущена в декабре 2015, примерно 4 года назад к моменту написания этих строк и если вы развёртываете этот образ сегодня, первое что вам предстоит сделать, так это исправить его. Это бы содержало в зависимости от определения сборки (и общего числа включаемых в неё пакетов), выгрузку гигабайта или более пакетов для приведения к самому последнему стандарту и обеспечению того что вы запускаете её со всеми выявленными исправлениями уязвимостей и размещаете все требуемые исправления.

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

Следовательно, помимо выполнения постоянного сопровождения вашей среды самой по себе, важно выполнять непрерывную поддержку и ваших стандартов. В 2019 имеет смысл обновить свой CentOS до сборки 7.6. По крайней мере, в ваше расписание постоянного сопровождения вовлечено регулярное обновление имеющейся золотой сборки.

Позднее в этой книге мы углубимся в подробности этого процесса. Тем не менее, кому это интересно, это может быть настолько же просто, как загрузить образ виртуальной машины, выполнения обновления, его очистки (например, удаления ключей хоста SSH, которые дублировались бы при клонировании данного шаблона), а хатем создания из него некого нового шаблона. Очевидно, что если в эту SOE были внесены прочие изменения с момента последнего цикла сопровождения, их также следует включить сюда.

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

Короче говоря, SOE должна превратиться в часть вашего постоянного процесса ИТ; при верном применении они не препятствуют инновациям - вместо этого они активно поддерживают их, возвращая время обратно тем, кто работает с нею и обеспечивая то, что они тратят меньше времени на выполнение повседневных, повторяющихся задач, а следовательно, обладают большим временем для оценки новых технологий и поиска лучших способов ведения дел. Это, в конце концов, одно из ключевых преимуществ автоматизации, которую SOE поддерживают напрямую.

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

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

В своей следующей главе мы изучим как применять Ansible в качестве эффективной инфраструктуры автоматизации для вашей среды Linux.

Для изучения дополнительных сведений относительно SOE с точки зрения Red Hat, отсылаем вас к следующей статье.