Приветствую, лирику оставлю в конце второй статьи, а эту, пожалуй, начну непосредственно с её сути, а именно с перевода выступления Carson Anderson на SaltConf 2018. Когда-то это видео на меня произвело огромное впечатление, а также закрепило уже имеющиеся знания по SaltStack.
Должен предупредить о двух моментах. Первое: я не профессиональный переводчик. И второе: в тексте есть некоторые элементы, которые были переведены с небольшими грамматическими и лексическими изменениями по моему собственному усмотрению, без потери или искажения смысловой нагрузки. Ввиду того, что Карсон вел лекцию на крайне высокой скорости повествования, практически уверен на 100%, что слова путались и иногда не догоняли мысли, а также он частенько повторяется. Посмотрев оригинал видео, вы всё поймете.
З.Ы.: да, знаю, опоздал я с этим переводом лет эдак на пять, плюс и готовил его более полугода из-за плотной занятости.
Список глав
https://habr.com/ru/articles/934594/
данная статья, основные главы — minion, master, транспортный уровень, скриптыhttps://habr.com/ru/articles/934608/
вторая статья, в которой освещена обширная глава — модули
Вступление
Перед тем как я начну, должен предупредить у меня для вас сегодня тонна информации. Её настолько много, что я точно знаю, что не уложусь в 45 минут. Прошу прощения. Но у меня есть полная, более медленная версия презентации без сокращений, ссылку на которую я вам дам в конце выступления. Поэтому если я вдруг что-то пропустил или слишком быстро проговорил — у вас будет эта запись, пожалуйста, используйте её, делитесь ею и изучайте в удобном для вас темпе. Итак, начнем...
Введение в Salt
Зачем необходимо проводить деконструкцию Salt? Почему я решил сделать данную презентацию? И почему я посчитал, что это может оказаться полезным для вас?
Начну с того, что я обожаю Salt. Вы можете сделать массу вещей при помощи Salt, и я имею в виду тонну вещей. Проблема в том, что из‑за того, что при помощи Salt вы можете сделать столь много вещей, она может стать весьма сложной. Как только вы подумаете: «Я знаю все о Salt» — вы тут же найдете несколько новых для вас терминов и концепций. И все эти термины и концепции вываливаются на вас единовременно, и это может привести к тому, что вы просто не сможете понять, что это и куда это вписывается. Поэтому я хочу взять Salt и разложить его на составляющие части, чтобы вам было проще приспособиться и понять. Я разделю Salt на пять частей и мы рассмотрим каждую из них по очереди, чтобы вам было проще понять каждый компонент, а также увидеть картину в целом.
Для начала мы поговорим о Salt Minion (далее «миньон»). О нем я расскажу совсем немного. Так как у вас будет огромное количество миньонов, которое вы будете использовать в вашей инфраструктуре, я думаю, что сначала нам нужно поговорить о нем.
Затем мы поговорим про Salt Master (далее «мастер»). Потому что когда у вас появится большое количество миньонов, вам понадобится кто‑то, кто будет управлять ими, и именно для этого мастер существует.
После мы поговорим о том как мастер обменивается данными с миньоном, а миньон обменивается данными с ним в ответ — другими словами про Transport Layer (далее «транспортный уровень»). Я хочу донести это до вас, потому что понимание транспортного уровня Salt поможет вам понять некоторые нюансы работы Salt, и даже покажет некоторые проблемы с безопасностью, которые могут возникнуть в случае, если вы сделаете некоторые вещи неправильно.
После мы поговорим о том, как вы взаимодействуете с вашей инфраструктурой при помощи Salt или с элементами самого Salt при помощи Scripts Layer (далее «уровень скриптов»).
И наконец, основная часть презентации, то, почему я буду пропускать некоторые моменты. Здесь я расскажу, как и посредством чего вы будете взаимодействовать с Salt — Modules (далее «модули»). В Salt есть огромное количество модулей, они практически руки мастера. Вы используете их повседневно, я клянусь, вы можете даже этого не знать.
Так что, как я уже говорил, — мы будем рассматривать их все по очереди, и я постараюсь рассказать о них как можно больше за то время, которое у нас есть.
Salt Minion
Давайте начнем с миньона; как я и сказал, я думаю, что мы должны поговорить про него в самом начале, потому что это сердце Salt. Миньон — это то, что вы будете запускать намного чаще, нежели что‑либо другое, и он делает больше, чем вы думаете. Итак, миньон — долгоживущий процесс (прим. переводчика — демон) Python, который работает поверх операционной системы, что означает, что он имеет доступ ко всей информации об аппаратном и программном обеспечении вашей системы. Он может работать автономно, что является еще одной причиной, почему я считаю его ядром Salt: ему даже не нужен мастер, миньон может работать сам по себе. Миньон также управляет большинством модулей, позже мы поговорим о них. Большинство из модулей предназначены для использования только миньоном, некоторые только для мастера, некоторые для них обоих, но все же большинство их них управляются миньоном.
Поскольку миньон находится в операционной системе, он наделен полномочиями в предоставлении метаданных системы, которые называются grains. Позже я подробнее остановлюсь на grains, и мы также поговорим о grains-модулях, но сейчас надо запомнить, что миньон авторитативен в предоставлении метаданных узла.
Миньон также выполняет рендеринг всех шаблонов, даже если вы видели много, вы можете не знать, что миньон собирает все файлы шаблонов и данные и выполняет рендеринг (прим.переводчика в основном Jinja, но не только). Повторюсь, мастер сгружает с себя все, что может, на миньоны.
Когда у вас куча миньонов, само собой, будет и мастер, и это работа миньона — установить соединение с мастером. У мастера есть обратный канал, который мы рассмотрим подробнее на транспортном уровне. Мастер может послать запрос, сказав: «Я хочу, чтобы ты сделал одну вещь». Миньон запустит модуль в запросе, который запустит другие модули, которые, в свою очередь, могут вызвать следующие модули и мы это рассмотрим в разделе про модули. Миньон генерирует ответ и отправляет его обратно мастеру, чтобы тот мог просто отобразить его для вас.
Поймите, я рассказываю это очень кратко, чтобы мы поняли, где миньон расположен в архитектуре, я не хочу говорить о нем слишком много. Итак, перейдем к мастеру.
Salt Master
Как только вы начинаете использовать множество миньонов, мастер становится практически незаменимым элементом. Вы можете управлять мастером только при помощи одного миньона, у этого есть свои преимущества, но на самом деле преимущество — это справляться с управлением всем парком вашей инфраструктуры из одного места. Но прежде чем мастер сможет справиться с нашим парком, вам нужно установить связь и доверительные отношения между мастером и миньоном. И я хочу рассказать об этом в секции «Доверие и шифрование».
Доверительные отношения и шифрование
Я сделаю оговорку: я буду говорить о шифровании, но не собираюсь на 100% идеально подробно с технической стороны рассказывать про него, потому что это просто сведет вас с ума. Но формат, который я предоставлю, даст вам представление о том, что мы здесь делаем и как это работает.
Итак, у нас есть мастер и миньон, который хочет подключиться к нему.
первое, что делает миньон, — создает пару публичного и приватного ключей;
далее он посылает мастеру открытый ключ, говоря: «Я хочу установить соединение с тобой»;
как только мастер принимает ключ, и я расскажу, как это происходит, позже, мастер отвечает: «Хорошо, давай я возьму свой публичный и приватный ключи ассиметричного шифрования, зашифрую их оба при помощи твоего (миньона) публичного ключа и отправлю это все обратно»;
теперь у миньона есть способ удостовериться в том, что он общается именно с тем мастером, и делает это внутри безопасного соединения к этому мастеру;
после миньон берёт всю метадату, для которой он является носителем, и отправляет мастеру со словами: «Хорошо, вот всё, что я могу сказать о себе»;
далее для всех подтвержденных миньонов вся информация о ключах записывается в хранилище, а также и все метаданные о каждом миньоне. И это происходит каждый раз, когда миньон подключается — этот процесс повторяется снова и снова. В результате мастер создает большую базу данных с принятыми ключами миньонов и всеми метаданными о них. И после этого у вас появляется возможность делать мощные операции;
Главное, о чем мы поговорим (в этой части), — это таргетирование.
Таргетирование(targeting)
Итак, таргетинг — это то, что вы делаете постоянно в Salt, знаете ли вы об этом или нет, просто довожу до вашего сведения. Поэтому каждый раз, когда я говорю о таргетинге, я говорю о типе и термине. Так что мы возьмем дефолтный salt '*' test.ping, это первое, что вы, вероятно запустите в Salt. Здесь мы выполняем таргетирование, даже если мы не передаем никакой флаг, мы делаем по умолчанию «глоббинг» по ID: возьми эти переданные ключи, найди любой из них, совпадающий с указанным шаблоном(*) и сделай test.ping
Вы также можете делать более полезные вещи — использовать метаданные, потому что вы знаете всю информацию об операционной системе каждого миньона. Вы можете сказать: найди каждого миньона, который работает под CentOS, и скажи им выполнить эту команду (selinux.setenforce 0), которая выполняет функционал специфичный для CentOS.
Есть тонна различных систем таргетирования, которые вы можете использовать в Salt. У меня нет времени, чтобы рассказать обо всех, если вам интересно, у Salt есть очень хорошая документация по таргетингу и тому, как разбить вашу инфраструктуру и послать определенные задания на определенные узлы и сказать: вы делаете это, вы делаете то. И еще раз, это все, что я хочу рассказать в этой главе.
Pillar
Следующее, за что будет отвечать мастер — это pillar'ы. Теперь вспомним, что у миньона есть grains, для которых он является владельцем этих данных. Мастер может определять данные о миньоне, также он может это делать, основываясь на том, что он знает об этом миньоне, и это и есть pillar. И это хорошее место для расположения данных конфигурации и секретных данных во время применения state (аналог таски в ansible). Итак, у нас есть связка мастер-миньон; когда миньон хочет получить pillar, он посылает свою обновленную версию метаданных мастеру: «Вот всё обо мне ещё раз, если ты забыл, а также я хочу получить все данные, которые ты знаешь обо мне». Мастер говорит: «Хорошо, тогда я ограничусь твоим ключом (имя машины) в метаданных, и я тогда определю, какие данные тебе вернуть». Основной способ, которым вы это (сопоставите значения grains и то, какие параметры к ним применимы) сделаете, есть и другие, но они будут рассмотрены в главе про pillar, — это файлы конфигурации (top файл). Итак, вы пишете этот топ-файл; предположим, что каждая строка в этом файле — это строка, таргетирующая (сопоставляющая) строку с типом и описанием. Мастер находит все позиции, где существуют совпадения и выдаст ассоциированные файлы/указания. Так что в данном примере у хоста есть совпадения с файлом конфигурации базы данных и файлом конфигурации SELinux. Так что мастер возьмет все те файлы, которые были указаны в шаблонах топ-файла, все pillar'ы и отдаст миньону большой объект данных, все, что мастер может рассказать миньону о нём самом же. Так что миньон спрашивает: «Что ты можешь рассказать мне». Мастер добавляет это всё и возвращает объект данных. Теперь миньон получил данные конфигурации, это не авторизационные данные, он просто получает конфигурацию от мастера.
И это все, что я хотел рассказать о мастере. Опять же, я хочу рассказать о них в той мере, чтобы вы знали, как они взаимодействуют и где находятся, но и чтобы мы не тратили на это все много времени.
Давайте перейдем к крутым вещам — к транспортному уровню.
Транспортный уровень
Теперь о транспортном уровне, о том, как мастер и миньон взаимодействуют друг с другом. Прежде чем мы перейдем к этому, я должен сказать, что есть несколько вариантов взаимодействия на транспортном уровне:
вы можете использовать сырые TCP‑сокеты;
вы можете использовать ZeroMQ;
вы даже можете использовать специфический для Salt способ коммуникации под названием RAET(rapid asynchronous event transport — быстрая асинхронная передача событий).
Я буду говорить о ZeroMQ, потому что он используется по умолчанию и именно его вы, вероятно, используете. И именно на него опираются все остальные системы. Так что вся речь будет применима к ZeroMQ и, возможно, к некоторым другим.
Итак, у нас есть наша связка мастер/миньон — а я просто хочу сосредоточиться на процессах. И когда мы говорим об этой связи, мы представляем её двусторонней, кажется, это нативно, и мы рисуем двустороннюю стрелку, и появляется связка «мастер/миньон», «миньон/мастер» — они разговаривают в обе стороны, точка. Но я не думаю, что вы должны думать об этом или даже рисовать это таким образом. Я думаю, что вам нужно думать немного другим способом, который действительно работает. А именно — это два разных канала, у вас есть шина для коммуникаций «мастер‑миньон» и шина для коммуникаций «миньон‑мастер». Они обе базируются на концепте ZeroMQ, и я собираюсь рассмотреть их по отдельности. Первая шина — от мастера к миньону — это publisher/subscriber(pub/sub) или широковещательная шина. Вторая шина — от миньона к мастеру — это request/reply(req/rep) или прямая шина. Итак, широковещательная шина — я приравниваю её к зашифрованной радиочастоте. Да, у вас должен быть код расшифровки, но все, кто настроен на эту частоту с кодом, будут знать всё, что вы скажете на этой частоте, и это стоит запомнить.
Итак, в случае с pub/sub у нас есть мастер и миньон — помните, что миньон инициирует все соединения — поэтому когда я рисую эту стрелку, это просто первичный поток данных, а не инициализация соединения, так что мастер инициализирует, а миньон слышит любую передачу по радио.
Если вы возьмете сценарий с несколькими миньонами, стрелка как бы разделится, и помните: это широковещательное сообщение. Я хочу донести до вас то, что больше не буду использовать стрелку, а переключусь на эту странную звезду, которую придумал, потому что она имеет направленность. Но я хочу, чтобы вы поняли, что это широковещательная трансляция, и вы больше никогда не увидите ничего, кроме этой стрелки. Итак, у нас есть наш мастер, и все, что он говорит через это широковещательное сообщение, может прочитать любой, у кого есть ключ.
Так что всё, что идет по широковещательной шине, отправляется всем миньонам постоянно. Поймите, даже если вы подумаете и заглянете в документацию и скажете: «Здесь нет фильтрации сообщений ZeroMQ, и я могу нацелиться на конкретного миньона точно по его ID». Нет! Это всё ещё широковещательное вещание. Так что, что‑то вроде этого — небезопасно. Вы говорите всем пароль, который должны знать только некоторые люди. Это также небезопасно! Вы думаете, что вы просто скажете db1 этот пароль, и он единственный, кто услышит это. Нет! Вы отправляете широковещательное сообщение. Или если вы сделаете еще правильнее. Вы скажете: «Я знаю, что pillars — хорошее место для секретов (да, это так и есть). Я помещу их в inline команде salt». Нет! Это небезопасно. Все они одинаково небезопасны! Так что если вы гадаете, что безопасно, а что нет, то на самом деле ответ очень прост. Всё, что вы вводите после команды salt, всегда отправляется всем. Поэтому никогда не указывайте ничего секретного после команды salt. Если же вы задаетесь вопросом: куда мне девать секреты и как их передать — то для этого предназначена следующая шина.
Шина request/reply, я её приравниваю к частному телефонному разговору тет‑а-тет между мастером и миньоном. Так что они могут говорить все, что хотят, они общаются безопасно, и только они двое слышат это. В этом примере мастер обращается к миньону, когда последнему нужно ответить, он создает соединение с мастером. И это действительно имеет больше смысла в сценарии с несколькими миньонами. Так что если мастер посылает широковещательный запрос, и каждый миньон должен ответить, то каждый из них создает канал связи тет‑а-тет (req/rep) и может отправлять все, что хочет, и это безопасно. Здесь видна некоторая производительность, потому что мастеру требуется столько же усилий для одного сообщения, сколько и для миллиона. Но в зависимости от количества ответов, которые вы получаете одновременно, вы можете перегрузить мастер, вот почему есть флаг batch для команд Salt. Ну вот и все.
Давайте пройдемся по всему процессу от начала до конца, я хочу показать вам транспортный уровень в действии. Итак, в моей очень простой команде «salt min3 grains.set role db» определенный миньон должен установить grains в переменную. Никаких команд Salt, вся передача секретна, все безопасно. Итак, у нас есть мастер/миньон инфраструктура, и помните, что мастер знает кучу вещей о каждом подключенном миньоне, записанных в grains. Я показываю только grains с названием ID, потому что это все, что меня сейчас интересует. Команда «salt min3 grains.set role db». Мастер смотрит на данные и он, основываясь на всем, что он знает о каждом подключенном миньоне, ожидает ровно один ответ. Поэтому он оставляет место и начинает ждать этого ответа. Как только ответ будет готов и получен, команда выполнится. Вот почему иногда, если мастер не может точно сказать, сколько ответов ожидать, он будет выдавать ошибку, ожидая большего количества ответов, и вы увидите ошибку «миньон не ответил вовремя». Итак, он говорит: хорошо, я делаю обращение и ожидается, что я создам сообщение. Мастер собирается поместить все после команды salt в эту шину. Отправляем его через шину, что означает одновременную отправку сообщения всем. Далее каждый миньон проверяет, совпадает ли таргетированное имя с его хостнеймом (min3). Все, кроме min3, отбрасывают сообщение. Тем самым таргетинг происходит дважды: первый раз на стороне мастера, второй раз на каждом миньоне. Тот миньон, кто совпадает, говорит: «Да, это я, я min3. Позвольте мне сделать то, что вы хотите. Я установлю переменную role=db. И я собираюсь сгенерировать ответ и переслать его вам (на мастер) приватно». На что мастер отвечает: «Я получил все ответы, которые ожидал, вот результаты. Я зaкончил выполнение команды». И это дает вам хорошее представление о том, как работает транспортный уровень в Salt.
Давайте двигаться дальше, к скриптам.
Скрипты
Это одна из двух самых объёмных частей доклада, и это то, почему я повествую столь быстро. Здесь мы поговорим о том, как вы будете взаимодействовать с Salt и с инфраструктурой посредством Salt. И поскольку я хочу рассказать о каждом элементе, я их разбил на группы для удобства понимания. Это группирование на мой личный взгляд, не Salt, просто чтобы вам было легче.
Взаимодействие(action)
Первая группа — это то, что я называю группой взаимодействия, это команды, которые вы запускаете, чтобы выполнить взаимодействие в вашей инфраструктуре с помощью Salt. Начнем, конечно, с самой команды salt.
salt
Я не хочу слишком много об этом говорить, потому что вы будете часто его использовать, вы уже использовали его раньше. Есть много документации, но, по сути, команда salt запускается на мастере, говорит мастеру сделать бродкаст-сообщение, миньон возвращает ответ мастеру. Это все, как я и говорил, вы уже много раз делали.
salt-call
Команда salt-call интересна тем, что если вы новичок в Salt или даже если вы уже некоторое время используете Salt, то ошибочно думаете, что salt — это вызов к мастеру, salt-call — это вызов к миньону. Все думают, что это так, но на самом деле это не так, на самом деле все проще.
Salt‑call — это легковесный миньон, он может работать даже без запущенного процесса миньона, поэтому я хочу подчеркнуть, что для запуска salt‑call не нужна служба миньона в фоновом режиме. Единственное отличие заключается в том, что он запускается и не слушает брокдаст-сообщение, просто делает то, что нужно, и затем завершается, вот и все. Кстати, когда я сказал, что миньон является автономным, я имел в виду, что salt‑call, действующий как миньон, является автономным. Даже если мы можем запускать миньон.
Итак, перейдем к salt-run.
salt-run
Salt-run похож на salt-call, но он запускается и не таргетирует никаких целевых данных. Вы запускаете salt-run на мастере, и он по определению запускается на мастере, что делает salt-run идеальной командой для выполнения всех административных задач, которые требуют доступа ко всей вашей инфраструктуре или к самому мастеру, таких как управление инфраструктурой, оркестрация; скажем, запустить это на одних машинах, затем запустить то на других машинах, а затем сделать это и сделать все взаимозависимым, как в statefull-инфраструктуре. Или даже выполнять такие задачи, как обработка salt-задач и кэширование всего, где требуется доступ на уровне мастера. Мы еще вернемся к этому в главе про модули.
Далее — salt-ssh.
salt-ssh
Итак, salt-ssh — действительно крутая команда. У нас есть вся эта мощная инфраструктура, о которой я говорил, и она действительно производительная и действительно мощная, но иногда она слишком сложна для вас или пока не совсем подходит. Вы говорите: «Я не хочу, чтобы агент постоянно работал», вот тут-то и приходит на помощь salt-ssh. Единственное требование для salt-ssh при запуске на мастере — это наличие на удаленном компьютере доступа по SSH и Python, те же самые зависимости, что и у ansible. Таким образом, salt-ssh подключается к демону SSH, копирует необходимый код, запускает его локально и возвращает результаты. Обратите внимание, что здесь больше накладных расходов, потому что вам нужно копировать код, поскольку он не предустановлен, но вам не нужен постоянно запущенный агент.
Salt-ssh также очень полезен с salt-cloud.
salt-cloud
Как вы могли догадаться, salt-cloud предназначен для работы с публичными и частными облаками. Вы запускаете его на мастере и можете создать множество вещей в облаках, но одна вещь, которая очень часто встречается, — это работа с виртуальными машинами. Я сказал облачному провайдеру развернуть машину, и у вас есть новая машина. Если у вас есть сомнения и вы боитесь использовать salt-cloud, потому что хотите золотой образ, который предварительно настроен для автоматического вхождения в вашу инфраструктуру (при помощи преднастроенного миньона на нём), не волнуйтесь — миньон вам не нужен. Единственное, что требуется на новой машине, — это доступ по SSH и Python, потому что salt-cloud по умолчанию использует salt-ssh. Salt-cloud попадает на машину, настраивает агент, чтобы вам не нужно было беспокоиться. Все, что вам нужно, это машина, на которую вы можете установить агент, вам не нужно поддерживать специальный образ.
Вот и все про группы взаимодействий.
Службы (daemon)
Эта группа называется службы (daemon). Это процессы, которые вы запускаете, чтобы каким-то образом расширить возможности Salt.
salt-api
Начнем с salt-api. Итак, у нас есть действительно мощная инфраструктура, о которой я постоянно говорю, и мы хотим, чтобы какая-то третья сторона могла использовать некоторые части Salt. Очень соблазнительно предоставить этой третьей стороне SSH-доступ к мастеру, и это сработало бы, но не делайте этого. Это слишком широкий доступ к вашей системе, и это неэффективно. Вам нужно использовать что-то более подходящее — вам нужен salt-api.
Salt‑api работает на мастере, подключается к нему, а затем использует HTTP или WebSocket клиент для подключения к API, и причину, по которой это лучше, мы рассмотрим в главе «Модули» в группе «Аутентификация». Но, как факт, API предоставляет очень мощные методы аутентификации и авторизации, поэтому вы можете предоставить минимальный объем доступа в вашей инфраструктуре через salt‑api, и не раздавать всем «ключи от дома».
Давайте перейдем к salt-proxy.
salt-proxy
Salt-proxy предназначен для работы с устройствами, которые не могут использовать SSH. Например, с простыми устройствами, такими как коммутаторы, маршрутизаторы, любые иные устройства, даже с низкоуровневым последовательным доступом через серийный порт. Если вы можете написать код на Python для доступа к ним, вы можете обеспечить связь с мастером с помощью salt-proxy.
Итак, у нас есть простое устройство и salt-proxy, у которого есть весь код и знания, необходимые для построения общения с этим устройством. Мы подробнее это разберём в главе «Модули» в группе «Прокси». Salt-proxy работает на миньоне, миньон подключается к мастеру, и он даже не знает о salt-proxy посередине (в связке мастер-миньон-устройство — прим.переводчика), он думает, что общается с этим простым устройством, как с полноценным миньоном. И вы можете подключить его к оркестрации и всей остальной инфраструктуре.
Вот что такое salt-proxy, далее перейдем к salt-syndic.
salt-syndic
Syndic — это сокращение от syndication (объединение в синдикат), и он предназначен для работы с многоуровневой инфраструктурой мастер/миньон. Итак, у нас есть миньоны, и на них у нас есть подключенный мастер. Но часто бывает так, что вам приходится запускать многоуровневую инфраструктуру из-за географического разрыва между всеми этими уровнями, а вы все равно хотите управлять мастерами в единой точке, вы хотите запускать одну команду и получать все результаты в одном месте. Вот тут-то и приходит на помощь salt-syndic.
Salt-syndic работает на хосте с мастером нижнего уровня, подключается к мастеру на том же хосте и подключается к мастеру, расположенному выше и проксирует трафик между ними. На самом деле, если вникнуть, это просто обычный прокси между этими мастерами, принимающий сигналы сверху, отправляющий его вниз, отправляющий ответ снизу вверх обычный прокси-трафик, это очень просто. Вы запускаете его на всех мастерах нижнего уровня, и это позволяет вам запускать одну команду salt на головном мастере, и, как в случае с salt-proxy, верхний мастер даже не знает, что есть ещё мастеры. Он думает, что общается напрямую с миньонами.
Кстати, здесь я хочу сделать небольшое отступление и поговорить о SaltStack Enterprise, потому что он работает практически так же, как salt-syndic. Это агент, который вы запускаете поверх существующей инфраструктуры и который дает вам мощную единую точку входа. Но он становится более мощным при помощи графического интерфейса и прочих других инструментов, которые вы можете получить и в открытом исходном коде, но эта инсталяция требует наличие более широкого опыта.
Это всё, что я хочу сказать о SaltStack Enterprise. Итак, давайте двигаться дальше к следующей группе.
Утилиты (utility)
Данная группа — это то, что я называю «группа утилит». Это инструменты, используемые для выполнения действий в самом мастере. Начнем с salt-key.
salt-key
Salt-key предназначен для работы с аутентификацией по ключам, о которой мы говорили ранее. Помните, что миньон отправляет открытый ключ, говоря: «Я хочу подключиться». У мастера есть кэш ключей, в котором указано, кто пытается подключиться, кто имеет доступ, а кто нет. Кто-то должен решать эту задачу, и это в первую очередь задача salt-key, хотя есть и другие способы. Вы запускаете salt-key на мастере, можете перечислить ключи в кэше, принять ключи или удалить их и т.д. Это и есть всё, для чего нужен salt-key — чтобы помочь вам управлять этим кэшем ключей.
salt-cp
Salt-cp (salt-copy) также очень прост. У вас есть мастер, миньон и файлы на мастере, которые нужно передать на миньон или миньоны, и вы можете сделать это, написав state и какие-то еще действия. Но иногда вы хотите сделать это просто ad-hoc командой, для этого и нужна salt-cp. После того как добавили файлы на мастере, после копируете файлы на миньоны. На самом деле это просто оболочка вокруг команды salt. Нет ничего, что вы можете сделать с помощью команды salt-cp, чего нельзя сделать с помощью обычной команды salt, просто синтаксис у salt‑cp намного чище и проще.
spm
SPM интересен тем, что это сокращение от salt package manager (менеджер пакетов salt), а также тем, что это единственная команда, которая не начинается со слова salt. И тут всё связано с формулами.
Если вы новичок в Salt, формулы — это очень просто — это tarball с данными состояния (state) и опционально с какими-то данными конфигурации по умолчанию, и всё. Проблема заключается в том, что формулы никогда не были доступны, в GitHub Salt их сотни.
Проблема заключалась в их использовании, особенно если у вас несколько мастеров, потому что каждый раз, когда вы хотите использовать формулу, вам нужно найти все ваши мастеры и указать ссылку на набор или клонировать её локально и указать на локальной машине, и этим довольно сложно управлять.
Поэтому мы сказали: «Мы знаем, как помещать tar-архивы в систему, это называется пакетным менеджером». Вы помещаете SPM на мастер, можете настроить его один раз, указав его репозиторий. Он может перечислить пакеты-формулы в репозитории, установить, обновить или удалить их с помощью одной команды, и вам никогда не придется перенастраивать ваши мастеры. Я думаю, что как только это действительно начнет развиваться с разными глубокими зависимостями и некоторыми другими вещами, это будет невероятно полезно для распространения формул в будущем.
Так, далее salt-extend.
salt-extend
Вы поймете, почему хотите использовать salt‑extend, когда я закончу с главой «Модули», потому что каждый модуль в Salt может быть кастомизирован. И salt‑extend существует для того, чтобы помочь вам написать идеальный шаблонный код для кастомных модулей. Я скажу, что это немного сложнее в использовании. Сначала нужно настроить несколько вещей:
у вас должен быть установлен salt-minion или salt-master;
у вас должен быть репозиторий в git (к примеру), потому что он использует как библиотеки, так и локальные файлы.
Как только вы это сделаете, вы можете запустить salt-extend, и если вы не укажете никаких флагов, он задаст вам несколько вопросов:
какой тип модуля вы хотите расширить;
как он называется;
каково его описание.
Вы отвечаете на вопросы, и он выдает идеальный шаблонный код. Вам не нужно идти на GitHub, копировать существующий код и изменять его, просто позвольте ему создать для вас шаблон. Я думаю, что это очень полезно.
salt-unity
Наконец, самой простой является salt‑unity. Она очень и очень проста, это обертка вокруг других команд salt. Это действительно всё, что она делает. Она берет отдельные команды, такие как salt‑master, salt‑key, и заменяет их на salt‑unity master/key. Я думаю, что она существует только для того, чтобы упростить создание sudoers-файлов, чтобы вы могли добавить одну команду и более никогда не беспокоиться о всех различных вариантах скриптов, которые могли бы выполнять.
На этом всё по главе «Скрипты», давайте перейдем к модулям. Это основная часть презентации, и нам придется пропустить некоторые вещи из-за нехватки времени.
Примечание от автора
Во-первых, благодарю каждого, кто дочитал до сих пор!
Во-вторых, в моменте написания понял, что проще для усвоения будет разбить данный текст на две части, по-честному я бы даже лучше разбил на три, но это уже слишком. Текст второй части у меня полностью готов, осталось только накидать скрины и гифки, поэтому, думаю, на выходных создам вторую статью, в которой рассматривается глава про модули и добавлю ссылку в начале страницы в «Список глав».
