Приветствую, данная статья является прямым продолжением статьи Salt Deconstructed vol.1. Что бы не захламлять статью бесконечными картинками и вырезками, решил конвертировать их в GIF формат. Старался располагать каждую GIF'ку в начале каждого текста к которому она относится, надеюсь так мне получится передать суть излагаемого в видео презентации.
Скрытый текст
https://habr.com/ru/articles/934594/
первая статья, в которой рассматривались основные главы - minion, master, транспортный уровень и скриптыhttps://habr.com/ru/articles/934608/
данная статья, в которой подробно освещена глава модули
Модули
Итак, каждый раз, когда я говорю про модули, я буду показывать три вещи
тип
имя
функцию
Тип - это что-то вроде модуля выполнения, я буду его изображать в зеленом квадрате сокращенными буквами. Имя — это что-то вроде команды, буду изображать внутри типа до точки. Функция — это что-то вроде метода, буду изображать внутри типо после точки. К примеру у нас есть модуль выполнения(Ex - execution), с именем cmd и функцией run. И я это буду показывать каждый раз, так как оно все соответствует этому шаблону. И так, в Salt есть очень много типов модулей, их всерьёз очень много. При этом вы можете их расширять и они могут использовать друг друга и это очень круто. И я постараюсь описать как можно больше из них, на сколько мне позволяет время. Что бы упростить задачу я их разобью на группы, и опять же это моё группирование, только для того что бы вам было проще понять. Далее будет представлено разбиение на группы:
ядро(core)
данные(data)
события(event)
возвращаемые данные(result)
администрирование(admin)
интеграции(integration)
утилиты(utility)
Cкоро вернемся к этому списку, повторюсь я группирую только для лучшего усвоения. Так же, каждый раз когда я буду показывать вам модуль, я буду демонстрировать три вида данных:
repo - место в репозитории, где вы можете найти тот модуль. Это что очень полезно иметь ссылку на него
custom - место где обычно хранится на мастере, это так же можно кастомизировать
и команду, которую вы запускаете применяя к миньонам, потому что как вы помните большинство модулей предназначены для миньонов. Поэтому вы должны запустить их с мастера к миньону
Поскольку это деконструкция, давайте возьмем слой модулей и разберём его дальше на те группы, которые я представил, и рассмотрим их по одному.
Ядро(core)
Начнем с группы модулей ядро. Группа модулей ядро — это модули, которые вы используете каждый день если используете Salt. Я уверяю вас, вы просто можете не знать что это так.
execution
Начнем с модуля execution. Я хочу отметить, что модуль execution интересен тем, что он не следует статичному шаблону(который был ранее показан - прим.автора). Это оригинальный модуль Salt, поэтому указана директория salt/_modules. После этого вы увидите шаблон и довольно быстро его освоите. Модули execution — это то, что следует после команды salt или salt-call, вы все это уже видели.
Обратите внимание на формулировку, сделай это сейчас - cmd.run(выполни команду), test.ping(выполни тестовый пинг), git.clone(склонируй гит репозиторий), . Сделай это без подтекста. Вы всегда будете это выполнять. Ещё раз, вы постоянно используете их, они уже изношены донельзя мне нет необходимости это освещать. Просто, это то что следует за salt и salt-call.
Я хочу отметить еще один момент. Вы можете взять любой вызов salt или salt-call, подсветить его части и посмотреть где они сопоставляются в коде модуля, который сопоставляется с аргументами функции и именованными аргументами. И это настолько очевидно, что вы даже можете увидеть — это просто объявление функций кода, это очень легко понять, сослаться на них и посмотреть в код модуля.
state
Модуль state — это последний раз когда я указываю на исключение из шаблона, а именно salt/_states. Модуль state — это еще одна вещь которую вы используете все время. Вы увидите их в state-файлe, когда будете писать код.
Так что обратите внимание, что формулировка здесь изменилась - pkg.installed(пакет установлен), service.running(сервис работает), git.cloned(гит склонирован). Они изменились на подразумеваемые вопросы, потому что состояние должно быть таким, если же это не так то сделай так. Я не буду слишком долго на этом останавливаться. Но вы можете создать файл с состоянием pkg.installed, пакет установлен - нет, сделайте так - чтобы это произошло. Или, вы можете проверить сервис работает - нет, запусти и так далее. Опять же, вы можете подсветить части состояния, найти файл(в нашем примере ./states/service.py - прим.автора), в нем найти аргументы функции и именованные аргументы. И есть даже несколько разных способов сделать это. Я думаю это очень полезно для изучения и точного понимания того, что делают ваши модули, если вы настолько любопытны.
И, наконец, я хочу поговорить о том, как они работают вместе, потому что между ними есть интересная взаимосвязь на которую, я думаю стоит обратить внимание.
state + execution
Итак, у нас есть обычный модуль state git.clonned, который позволяет убедиться что git-репозиторий склонирован в определенном состоянии в по определенному пути. Как вы можете догадаться, первое что нужно сделать, это выяснить склонирован ли он и для этого есть модуль execution с помощью которого можно проверить статус git-репозитория в определенном месте. Вместо того, чтобы переписывать этот код git.clonned использует модуль execution git.status, таким образом вы можете использовать модуль execution напрямую как и другие модули могут это делать. Если вы копнете глубже, то увидите, что они на самом деле используют массу других модулей, это очень правильная схема - модули state используют модули execution, пиши код единожды и переиспользуй его везде. Если вы копнете ещё глубже, то в git.status увидите что он использует кучу других модулей execution, которые даже не являются модулями git. Снова модули вызывают модули, которые вызывают модули, вы можете строить эти деревья весь день. Написав код один раз для чего угодно, а затем просто повторно переиспользовать его.
Данные(data)
Как я и говоил, что вернусь к этим модулям. Модули данные предназначены для получения секретных данных и данных конфигурации во время выполнения. Давайте рассмотрим их по одному, начиная с grains.
grains
Помните, что миньон является носителем grains, то есть данных которые миньон может предоставить о себе. Есть много способов сделать это, вы можете получить информацию об основном оборудовании и операционной системе. Вы можете посмотреть дисковые массивы или вызвать метаданные.
Здесь я буду всегда приводить три примера, но они могут зависеть от типа модуля. У некоторых групп уже существует сотни различных модулей, которые вы можете использовать. Конечно, вы можете захардкодить данные и есть некоторые встроенные grains которые вы можете получить, но иногда более полезно использовать какую-то внешнюю систему/ПО/софт. Например, вызвать mdadm и узнать какие у сервера дисковые массивы и получить результаты. Миньон вызовет каждый модуль grains который вы настроили, скомпрессирует все результаты в один большой объект данных grains который он отправит мастеру, просто результат всех этих отдельных выполнений модулей.
pillar
Данные pillar в первую очередь предназначены для использования мастером, потому что он является носителем pillar.
Такие вещи как взаимодействие с MySQL, libvirt или даже любой командой, всё где вы хотите, чтобы мастер был единственным кто имеет доступ к любой системе, которую вы запрашиваете и вы хотите, чтобы только мастер был носителем этих данных. Конечно, вы можете использовать pillar, о которых мы говорили ранее, с конфигурационными файлами, но статические конфигурационные файлы не всегда являются лучшим решением. Поэтому вы можете запустить любое количество внешних модулей pillar которые вам нужны, когда миньон спросит, каковы метаданные о нём — мастер ответит: «Позвольте мне проконсультироваться со всеми моими источниками, объединить всё это в одно и сказать вам». Мы используем это для связи с Amazon Cloud, чтобы получить информацию о тегах, потому что я не хочу чтобы каждый миньон имел токены к Amazon Cloud для описания своего собственного инстанса. И так, это grains и pillar, где minion и master соответственно являются носителями. Sdb-модули нужны тогда когда вы не хотите, чтобы ни minion, ни master были носителями данных.
sdb
Sdb — это сокращение от simple database module(простой модуль базы данных), а не secret(секрет), хотя он используется для секретов, но на самом деле это сокращение от простые модули базы данных.
Как я уже сказал, всё это касается работы с внешними системами, которые являются носителями в отношении некоторой информации, к примеру - vault. Например, у меня есть миньон, он настроен на использование модуля sdb для vault, что означает, что он связывается с vault, чтобы получить, установить или удалить данные. Обратите внимание на то, чего здесь нет — мастера. Мастер здесь отсутствует, что означает, что вся настроенная нами система доверия и шифрования исчезла, и теперь сторонней системе предстоит самостоятельно решить, как она будет обеспечивать доверие, шифрование и определять, кто получает какие данные, но это очень полезно для внешних систем. Это также очень полезно потому что, как и любой другой модуль, вы можете вызывать их напрямую, не импортируя код vault в свой пользовательский модуль, а используя модуль vault sdb самостоятельно. Кстати, причина, по которой это было написано, и один из основных случаев использования — это salt-cloud. Помните, что salt-cloud вызывает машины через SSH, а это означает, что ему нужны учётные данные, и я не хочу их хардкодить, это страшно, поэтому я могу заменить их таким синтаксисом URI и salt, говоря: «Перейди к модулю sdb, по указаному урлу есть REST API и получи значения пользователя и пароля и замени их здесь». Это простая встроенная замена строки, и вот поэтому это простой модуль базы данных. Вот и всё.
Прежде чем пойдем дальше, я хочу дать вам секунду, чтобы посмотреть на этот слайд. Я хочу, чтобы это было своего рода общими рекомендациями сообщества, по моему мнению о том, когда что следует использовать. Единственное, что я хочу действительно подчеркнуть и отметить здесь, это то, что grains не находятся в строке secret. Не используйте grains для хранения секретов. Не используйте grains для предоставления секретов. Миньоны могут лгать о своих grains, они являются носителями их. Предположим вы создали роль на пользовательском уровне. Но в случае взлома и получения root-доступа к этой машине, очень легко сказать: «Давайте попробуем роль на уровне администратора и посмотрим, какие секретные данные я получу».
Поэтому никогда не используйте grains для хранения секретов или для предоставления секретов, для этого существуют pillar и sdb.
События(event)
Модули событий перенесут вашу работу с Salt на новый уровень. Здесь вы перейдете от простого использования Salt к тому, что Salt действительно будет управлять вашей инфраструктурой за вас.
beacon
Начнем с модулей beacon, это модули событий, которые генерируют события в Salt.
Это такие вещи как inotify, discusage, service события, существует множество систем которые наблюдают за миньоном и отправляют события когда что-то происходит. Например, у нас есть миньон, на котором настроены все три выше перечисленных beacon.
у него есть файл, за которым вы хотите наблюдать. И когда он создается, он отправляет событие с сообщением «Тебе надо знать, файл был создан»
диск начинает заполняться, он отправляет событие с сообщением «Тебе надо знать, что диск заполняется»
сервис умирает, миньон говорит «Тебе надо знать, что сервис умер» маяки погасли, маяки зажглись, и мы знаем, что этот миньон просит о помощи.
Но, конечно просить о помощи бесполезно, если никто не отвечает и поэтому я добавлю на слайлд reactor. Обратите внимание, что он имеет другую форму логотипа, потому что он не является типом модуля. Но он, возможно, является первым что вы сделаете с событиями, не единственным, но первым.
reactor(не является типом модуля)
Reactor очень просты, они хорошо работают с событиями(events/beacons). В данном примере реакция заключается в очистке некоторых временных файлов. Затем есть список, когда запускать каждый reactor на основе полученных событий. Так что в данном случае мы говорим: «Если ты получаешь событие tmp_disk_full_event, запускай clean_tmp.sls». Эти два файла - всё, что вам нужно для создания reactor. И это может быть как мастер, так и миньон, кстати. Итак, у нас есть мастер, у нас есть миньон, и у нас есть эти два файла на мастере. И так
на миньоне происходит событие диск переполнен
отправляется beacon с миньона на мастер
мастер получает сигнал с "призывом о помощи"
далее он сверяется с тем что он должен сделать согласно реактору(reactor)
далее мастер отправляет файл который должен будет выполнить миньон
Это тривиальный пример, но это похоже на то, как платить кому-то за то, чтобы он следил за вашей инфраструктурой на предмет определенных событий и запускал команды Salt или принимал другие реакции для их решения. Это самоуправляемая самовосстанавливающаяся инфраструктура. Кстати, мое любимое запланированное использование этого примера — когда диск миньона начинает заполняться, мастер обращается к облаку и увеличивает диск в режиме онлайн. После он обращается к миньону, чтобы тот увеличил диск в режиме онлайн. И уже после отписывается в чат или рассылку просто сказать что это только что произошло, всё предотвращено на данный момент, но вам следует проверить это, потому что я не всегда могу знать, где удалить файлы, но довольно легко заплатить несколько долларов, чтобы увеличить диск в режиме онлайн и спастись от катастрофы.
И так, перейдем к следующему типу - queue. Он также очень полезен, когда вы начинаете иметь дело с большим количеством событий.
queue
Модули очереди(queue) предназначены для работы с базами данных, в которых хранятся события.
Так, например, у нас есть база данных Postgres, в которой хранятся события нашей инфраструктуры. Вы можете запустить метод insert модуля очереди(queue) и вставить туда события, миньоны могут это делать и другие системы тоже могут это делать. Самое классное, что облако или агент работающий в облаке, может использовать это и добавлять события, даже если это не миньон, он может вставлять события в вашу инфраструктуру, сообщая о том, что что-то запустилось, что-то закрылось. Затем мастер или другая система может использовать функцию pop и извлекать события в удобное время, что делает ее полезной для обмена событиями или для кластера мастеров или для того чтобы не терять события если мастер не работает когда происходит событие. Мы вернемся к этому через секунду
engine
Engine во многом чем интересен, что именно в нём находится чат-оператор в Salt.
Так что вы видите, у нас есть Slack, у нас есть Logstash, у нас даже есть webhook, движок его очень прост, но он не ограничен чат движком. Если у вас есть мастер и миньон и вам нужно запустить какой-то дополнительный Python скрипт, чтобы сделать что-то в инфраструктуре, не запускайте его отдельно и не управляйте им самостоятельно. Engine — это Python процесс, который может запускаться как на мастере, так и на миньоне. Фактически, вы можете запускать несколько процессов, и это здорово, так как что на мастере, что на миньоне, они управляются за вас. Если они выходят из строя, мастер или миньон может перезапустить их, а так же могут ввести некоторые дополнительные переменные, чтобы упростить взаимодействие с Salt. Как я уже сказал, engine всегда запущен, что делает их очень полезными для таких задач, как считывание событий, потому что они могут прослушивать очередь событий и сказать: «Тут событие произошло, позвольте мне отписаться в чат и сообщить вам, что диск только что заполнился на этом миньоне». Или наоборот, вы можете сказать: «Я хочу прочитать из чата, когда получу эту команду из чата, вызови ее», и engine прочитает ее, запустит команду в вашей инфраструктуре, и это будет как запуск и выполнение команды локально. Есть много разных вещей, которые вы можете делать с событиями. Еще один вещь которую вы можете сделать с событиями — у нас есть очередь(queue) событий в базе данных из примера ранее, engine конечно же имеет доступ ко всем модулям очередей, поэтому он может извлекать события, а так же помещать события в очередь, при этом они будут работать раздельно. Если вы хотите сделать что-то другое, кроме обычных реакций мастера, engine — хорошее место для этого.
thorium
Я не буду слишком много говорить о thorium. Thorium интересен, он связан с событиями, но не очень хорошо поддерживается. Я даже не изучал примеры. В основном, каноническое использование thorium — это то, что делать когда миньон выходит из строя. Для несобытийных событий нет событий, поэтому стандартная конфигурация thorium выглядит так: «Если миньон не отвечает вовремя, удали его». И синтаксис не сложен для понимания. В основном я бы сказал, что если вы пытаетесь сделать что-то с событиями и не можете сделать это с помощью reactor или engine, возможно, thorium — это то, что вам нужно, но я не хочу тратить больше времени на его обсуждение сейчас.
Результаты(result)
Модули результаты занимаются обработкой результатов команд salt, salt-call и даже salt-run и они относятся либо к командной строке, либо к другим системам.
output
Начнем с модулей output(вывод). Модули вывода — это просто вывод по умолчанию(highstate.output), в формате JSON(json_out.output) или даже Pony-say(pony.output), который сообщает о результатах того, что только что произошло.
Это просто разные способы форматирования данных для отображения в командной строке. И так мы запускаeм salt или salt-call и он генерирует этот большой блок того что произошло, и вы хотите отобразить это множеством разных способов, вы отправляете его в модуль вывода, будь то по умолчанию или вы указываете, что он форматируется определенным образом. Так что, например, у нас есть стандартный модуль если вы не указываете что то другое, highstate.output который представляет собой тот красивый табулированный вывод с цветовой гамме который вы видите все время в Salt. Мы можем сделать --out=json чтобы вы могли проанализировать его или вы можете сделать --out=pony озвучить результаты. И мне было любопытно как это будет выглядеть, как пони озвучит результаты. Это форк проекта Debian cow-say, но от лица пони, кстати это апстрим salt, вам даже не нужно устанавливать его.
returner
Модули returner(возврат) также занимаются выполнением команд, но они занимаются отправкой их во внешние системы такие как MySQL, Kafka, Couchbase.
Все эти места, куда вы хотите отправить все свои результаты, агрегируют и отчитываются о них, не теряя результаты когда вы закрываете командную строку. Например, у нас есть команда salt с большим блоком данных, который также отправляется как результат в модулях returner, которые могут переходить во внешнюю систему. Так что вы можете сказать миньону по умолчанию отправлять всё в определенный модуль или по умолчанию отправлять всё в два или в три модуля, чтобы вы могли выполнять различные виды обработки результатов. Или вы можете переопределить это в ad-hoc команде, сказав, что только этот результат отправь сюда для хранения или анализа.
Так что это все, что я хочу сказать о модулях результаты. Я ещё раз повторюсь, конечно, вы можете использовать их вместе(output и returner). Так что если вы используете salt или salt-call, вы можете отправить его как в output, так и в return или в несколько модулей return они не взаимоисключаемы.
Администрирование(admin)
wheel
Модули wheel предназначены для работы с внутренними компонентами Salt.
Главное, на что я хочу обратить внимание это то как он повторно используется в Salt. У нас есть key.accept, модуль key с функцией accept который используется salt-key он также может использоваться напрямую salt-api, и его можно использовать в вашем собственном скрипте как подключаемую библиотеку, это практически не представляет сложности. Вы можете импортировать эту библиотеку и использовать её. Как итог, легко взять эту библиотеку и просто использовать ее для своих нужд. Это всё что я хочу сказать о модулях wheel.
runner
Я хочу поговорить о модулях runner потому что как и модули execution они являются тем на чем работает salt-run. Так что они все занимаются тем же чем занимается salt-run. Ещё раз, это вещи, которые требуют доступа на уровне мастера.
Поэтому, когда вы запускаете модули runner, они по умолчанию запускаются на уровне мастера с полным доступом, вы так же можете сделать это с помощью salt-run, конечно вы так же можете вызывать модули runner напрямую через salt-api с помощью специального синтаксиса. Вы даже не будете предоставлять информацию о целевом объекте, потому что он согласно архитектуре выполняется на мастере, поэтому вы можете выполнять все эти административные задачи. Это отличный способ предоставить доступ к вашей системе через API.
Интеграции(integration)
Здесь мы наконец возвращаемся к salt-api, как я и обещал. Начнем с модулей аутентификации.
auth
Модули auth требуются для salt-api. Если вы собираетесь использовать salt-api, вам необходимо сначала отсортировать(пройти) аутентификацию в системе.
Существуют такие системы, как стандартная аутентификация Linux(pam), MySQL или LDAP, а также всевозможные прочие системы аутентификации, которые только можно себе представить. Вам нужно перейти в раздел конфигурации external_auth, где находятся все модули аутентификации, которые я хочу использовать, и все ACL для каждого модуля. Например, я говорю: «Есть пользователь Carson который может аутентифицироваться через pam, он может делать все, что захочет, даже какие-то страшные команды от root. Он умный парень, мы доверяем ему доступ ко всей нашей инфраструктуре». Но иногда хочется немного ограничить права. Так, например, здесь у нас есть LDAP, который говорит, что любой из группы DBA может делать именно то, что указано, например, они могут просто взаимодействовать с машинами БД, выполнять именно эту функцию, именно с этими аргументах, с очень узким охватом, только то, что им нужно. Последний пример: у нас есть пользователь api для mysql, который может только вызывать листинг установленных пакетов и версию, он не может предпринимать какие-либо действия, он может только проверять инфраструктуру и получать то, что ему нужно. Кстати, вы можете использовать их всех одновременно, они не являются взаимоисключающими. Я показал один пример пользователя в группе в каждом из них, но вы можете иметь столько пользователей и групп на модуль, сколько хотите.
netapi
Модули netapi — это другая половина salt-api. Вы должны запустить хотя бы один модуль netapi, чтобы запустить salt-api.
Примерами таких модулей являются tornado, cherrypy и WSGI. Кстати, это единственный случай, когда их ровно три. Cherrypy — это REST API, а два других — это разновидности web socket API. Итак, у нас есть salt-api, который общается с мастером, нам нужен доступ к нему, и вы должны запустить хотя бы один API модуль, возможно, это будет cherrypy, чтобы получить доступ к REST. Но что круто, так это то, что вы можете запустить их все одновременно, если хотите, потому что некоторые пользователи могут хотеть REST, а некоторые — WebSockets, и вы можете предоставить и то, и другое, они не являются взаимоисключающими. Так что между модулем API мы можем использовать модуль аутентификации что бы контролировать, что вы можете запустить именно это или именно то, и этот итог — мой любимый пример этого модуля. Давайте возьмем и создадим врапер, я всегда так делаю, я пишу модуль выполнения, беру страшную команду полностью под мою ответственность. Так что здесь мы делаем rm -rf /tmp на машине базы данных, и это страшно, и я не хочу давать кому-либо доступ к этому кому-либо, я хочу дать доступ к запуску именно модулю оболочки БД и функции очистки, я точно знаю, что он делает, что он может сделать и что он может изменить. И я даже абстрагирую это, если я позже изменю что может чистить, мне не нужно менять то, что они вызывают, они просто вызывают. Так что вы сочетаете это с аутентификацией, говоря: «Пользователь API может выполнять dbwrapper на машинах DB», это дает мне действительно жестко контролируемый абстрактный способ, но все же очень большой доступ к инфраструктуре.
proxy
Модули proxy предназначены для работы "глупыми" устройствами, они поддерживаются salt-proxy, как я уже сказал. Вам нужно запустить хотя бы один прокси-модуль для salt-proxy что бы получить доступ к вашей инфраструктуре.
Так что это такие устройства как коммутаторы, маршрутизаторы, умные лампы. Возьмем в качестве примера то, что мы уже использовали ранее касательно прокси, и мы знаем что мастер видит его так, как он думает, что просто общается напрямую с этим "глупым" устройством. В этом случае мы запустим модуль philips_hue, который может управлять умными лампами для нас, и поскольку salt-proxy действительно умный, он может иметь ID устройства как миньон, он может даже иметь grains как миньон, что означает, что вы можете делать такие вещи, как вызов salt или salt-api или производить оркестрацию или что-либо еще, потому что он похож на миньона из вашей инфраструктуры, говоря: «Этот миньон, запусти это, установи цвет красный, так как сборка зафейлилась», вы можете подключить это в API. Все другие системы так же имеют много возможностей чтобы контролировать все с помощью Salt.
cloud
Cloud модули являются основой salt-cloud, это в основном уже готовые облачные модули для всех публичных и частных облаков, которые только можно представить. И все они предназначены для запуска машин.
Если в двух словах, то для облачного модуля Salt вы, по сути, создаете конфигурационный файл, в котором указываете типы машин, которые нужно создать, количество копий, которое вам нужно, используя cloud модуль для чтения конфигурации и передачи сигналов облаку, говоря: «Конфиг такой, если это не так, сделай так чтобы это было правдой». Вы можете изменить это, и он снова убедится, что ваша инфраструктура является состоятельной.
Я пропущу остальное, чтобы мы могли рассмотреть некоторые модули утилит, пока не истекло время. Опять же, всё, что я пропускаю или что вы пропустили, можно найти по ссылке на полное видео в конце, где я говорю медленнее и рассказываю обо всем. Итак, перейдем к модулю утилит. Я хочу рассказать о нескольких из них.
fileserver
--- Пропущено(прим. автора)
totp
--- Пропущено(прим. автора)
Утилиты(utility)
serializer
Мы все более менее знаем что такое serializer, если мы когда-либо занимались программированием, но я хочу обратить внимание на эти модули, потому что их использование довольно интересно.
Итак, модули serializer занимается прямым и обратным преобразованием данных в формат строки или обратно в объект, что вполне логично, и тут много разных видов сериализаторов, о которых вы можете подумать. Самое интересное в этом то, что вы берете преобразованные данные, преобразуете их с помощью функции serialize для хранения или передачи, а затем обратно преобразуете в объект, возвращая их в память, здесь ничего нового. Интересно то, как вы можете его использовать с другими модулями. Помните, что модули могут вызывать модули, так что мы берем модуль state file.serialize и вы можете написать конфигурацию, которая говорит: «Помести эти данные в JSON», и все, что вы помещаете в formatter — это любой модуль сериализатора, который вы установили. Так что вам не нужно снова беспокоиться об импорте библиотек, он просто имеет полный доступ ко всем этим модулям. Его также очень легко использовать с вашими собственными пользовательскими модулями. Поэтому, если вы пишете пользовательский модуль и вам нужно преобразовать некоторые данные, не импортируйте библиотеки самостоятельно, вам это не нужно. В качестве примера вот модуль state, который обеспечивает конфигурацию и обратно преобразует упакованные данные, и мне не нужно беспокоиться о библиотеке, которую я использую в операционной системе, я просто использую функцию, которая уже была введена для меня через этот специальный введенный словарь здесь.
executors
Я пропущу executors, потому что они немного эзотеричны и мы перейдем к rosters.
rosters
И так, я хочу обратить внимание на модули rosters, потому что они являются тем, что поддерживает salt-ssh, если вы собираетесь использовать salt-ssh, вам нужно их понимать, думаю вы согласитесь со мной.
Я также хочу обратить на них внимание, потому что salt-ssh умеет читать конфигурационные файлы напрямую, чтобы получить списки узлов, с которыми вы можете общаться. Так что еще одна причина, если вы пытаетесь переключиться, вам не нужно использовать другую конфигурацию, по крайней мере, для перечисления доступных вам миньонов. Помните что salt-ssh не имеет агента, а это значит что нет списка всех подключенных миньонов, так кто же скажет вам с кем вы можете общаться - это задача модуля roster. Модули roster вытягивают данные из какой-то внешней системы, даже если это просто плоский конфигурационный файл, возвращает результаты и говорит: «Вот все подчиненные, с которыми вы можете общаться, и вот все данные о них, потому что у вас нет агента».
cache
Cache мы тоже пропустим, но у нас осталось пару минут. Давайте вернёмся и рассмотрим renders мне нравится они.
renders
И так, модули renders, если вы не знаете, это то основное что используются при написании файлов состояния(state) или конфигурационных файлов, и их установлено огромное количество. Например есть jinja, mako или даже обычный python, и вы можете использовать их как для создания файлов конфигурации, так и для рендеринга данных состояния. Например, у вас есть очень простое состояние salt, которое вы можете написать, и вы знаете, что это шаблон, и если мы все использовали когда-либо Salt знаем, что это jinja. Но мы не знаем, что вы можете сделать she-bang вверху и переопределить render модуль для любого файла состояния или конфигурации. Так что вместо запуска обычного jinja я могу сделать так чтобы мы фактически отправили его через Python, который будет иметь объявление функции, чтобы я мог делать действительно сложные логические операции, потому что, если вы когда-нибудь делали много действительно сложных jinja шаблонов, логика становится очень запутанной очень быстро, если вы делаете слишком много итераций, а не просто несколько циклов for. Так что вы можете фактически использовать Python или любой рендер. Вы также можете вводить результат render одних render модулей в другие render модули, фактически это является стандартным, если вы не указываете наш рендерер, то по умолчанию это не просто Jinja, а фактически Jinja перенаправляется через pipe в yaml, и вы можете указать столько, сколько хотите. Это похоже на то как делать bash shell pipe от одной команды к другой и к другой. Вы также можете делать, если вы создаете специальный конфигурационный файл file.managed. Вы можете указать любой из модулей render, который вы хотите, и они будут работать практически одинаково.
Лирика
Благодарю всех тех кто прочитал эту часть и тем более кого хватило и на первую! Спасибо!
Еще раз приветствую, пожалуй самое время представиться, меня зовут Мушинский Станислав. За спиной у меня около 17 лет в IT, за это время поработал техподом, админом, руководителем группы администрирования, Linux экспертом(как выяснилось позже это Linux solution архитектор), DevOps инженером, даже помнится в начале работал монтажником СКС, но к счастью не долго. Работал в больших и не очень фирмах таких как Mail/ВК(да, это разное), CберТех, GeekBrains, Mango Telecom, СФН. Сейчас нахожусь в SmartMerch на должности системный инженер Linux.
Но если вернуться к лирике, то... Помнится, давно, где то в 2019/2020 в ходе поиска доп.информации по Salt посмотрел видео которое я здесь переводил и для того, что бы вся информация хранилась под рукой пытался выписать текст данного видео в оригинале. Почему не писал сразу в переводе вообще не ясно, но имеем что имеем. Спасала та ситуация что полное видео со стандартной скоростью повествования было доступно. Но недавно, до того как я уселся за создание статьи, я хотел посмотреть то видео, что бы освежить воспоминания и оказалось что видео удалено с vimeo(старая ссылка - https://vimeo.com/289106306), попытки связаться с Карсоном не увенчались успехом ни через LinkedIn, ни через Twitter, даже не через коммит в github под репозиторием с его выступлением(да, не красиво, знаю). Позже я отписался в большой русскоязычный чат по Salt, кстати пользуясь моментом прорекламирую его - , но там тоже ни у кого не нашлось сохраненного старого видео.
Поэтому решил написать большую статью для привлечения внимания, и пользуясь данным случаем хотел бы обратиться к сообществу, может быть у кого то осталось сохранённое видео по SaltStack Decunstruction Full-length and Unabridged? В случае если у кого-то оно есть просьба поделиться. От себя могу сказать что тогда обе статьи дополню ещё и той информацией из полного ролика.
Критика, пожелания, исправления, обсуждение - welcome в коменты.
