Расширяемость
Все в Salt является расширяемым, вплоть до модулей, отображающих результаты выполнения в CLI. Это большой плюс Salt, так как можно легко внедрять собственные изменения без необходимости поддерживать параллельный fork в главном проекте. Каждая функция в Salt также является подключаемой.
Наиболее распространенными сценариями для расширения могут быть разработка модуля состояния (для описания того, как должна быть сконфигурирована часть программного обеспечения или службы) или модуля исполнения (код для взаимодействия с API или системой). Оба типа модулей могут быть написаны по относительно небольшому шаблону, оба хорошо задокументированы и могут быть проверены с помощью неплохой встроенной тестовой среды. Выполнить узловую проверку модулей можно c помощью PyTest, даже не находясь на мастере или совсем без работающего мастера. Для тестирования интеграций требуется система Linux, хотя с небольшими навыками хакера модули можно запустить и на OSX (о Windows не может идти и речи, как и в случае StackStorm с Ansible).
Возможно либо поддерживать свой автономный пакет, либо вносить непосредственный вклад в проект Salt на GitHub. Самым большим недостатком при внесении кода в основной проект является то, что пользователям для легкой установки ваших модулей может потребоваться подождать целый цикл обновлений. Это занимает примерно 3-5 месяцев при их текущем темпе работы, поэтому, хотя система Salt и «поставляется с батарейками», она имеет недостатки.
Salt развивается очень быстро в течение последних нескольких лет и претерпела некоторые большие изменения. Из-за этого может наблюдаться несовместимость между разработанными сообществом модулями. Я также считаю (хотя это и не уникально для Salt), что модули, представленные сообществом, плохо тестируются.
Роли Salt
Структура управления Salt довольно проста. В типичной установке есть только два разных класса машин.
Salt Master
Salt Master – это машина, которая управляет инфраструктурой и определяет политики для подчиненных серверов. Мастер работает как репозиторий данных конфигурации и центр управления, который инициирует удаленные команды и приводит другие машины в требуемое состояние. Для обеспечения этой функциональности на мастер-сервер устанавливается демон salt-master.
Управлять инфраструктурой можно и без мастера, но большинство настроек используют расширенные функции Salt Master. Для управления большими инфраструктурами Salt может делегировать определенные компоненты и задачи, обычно связанные с мастером, на выделенные серверы. Он также может работать в многоуровневой конфигурации, где команды могут быть переданы через мастер-машины боле низкого уровня.
Salt Minion
Ведомые серверы называются Minion-ами. На каждый ведомый сервер для связи с мастером устанавливается демон salt-minion. Миньон отвечает за выполнение инструкций, отправленных мастером, сообщает о результате заданий и предоставляет данные о базовом хосте.
Masters и Minions
Salt Master (Мастер) — это сервер, который выступает в качестве центра управления для своих миньонов, именно от Master отправляются запросы на удаленное выполнение команд. Например, эта команда сообщает текущее использование диска каждым из миньонов, которыми управляет мастер:
Таких команд большое множество. Например, вы можете установить NGINX на миньона с именем webserver1:
Salt Minions (Ноды, Миньоны) — это ваши серверы под управлением мастера, именно на них запускаются приложения и сервисы. Каждому миньону присваивается идентификатор, а мастер может ссылаться на этот идентификатор для назначения команд конкретным миньонам.
Связь между мастером и миньонами осуществляется по транспортному протоколу ZeroMQ, канал зашифрован парой открытого и закрытого ключей. Пара ключей генерируется миньоном, после чего он отправляет свой открытый ключ мастеру.
2: Установка Nginx и перемещение исходных файлов на мастер Salt
Теперь у вас есть основной файл состояния Nginx. Однако некоторые состояния ссылаются на файлы мастера Salt, которые еще не существуют.
Поскольку это в основном файлы по умолчанию, установленные с пакетом Nginx в Ubuntu, можно начать с файлов этого пакета. Веб-серверы одной сред – идеальное место для установки Nginx, с помощью которой вы сможете получить необходимые файлы.
Если вы еще не развернули ни одной среды, выберите map-файл одной из сред и разверните его. Здесь мы используем промежуточную среду, поскольку она требует мало ресурсов.
Когда серверы будут запущены, выберите один из веб-серверов и установите на него Nginx. Для этого можно использовать модуль выполнения pkg, так как пока что состояния еще не полностью рабочие.
Получив конфигурацию для мастера Salt, включите опцию file_recv. Она позволяет запрашивать у миньонов отправку определенных файлов на мастер-сервер. С ее помощью можно получить стандартные конфигурационные файлы.
Теперь эти файлы доступны на мастере. Путь к файлам создан в каталоге /var/cache/salt/master/minions/minion_id/files (в данном случае ID миньона – stage-www1). Скопируйте каталоги в каталог state:
Если вы посмотрите на содержимое своего каталога state, вы увидите новый каталог под названием files. В этом каталоге доступны соответствующие каталоги в файловой системе minion и три скопированных файла:
Здесь будут поддерживаться все управляемые файлы. Это соответствует пути в параметре source, который вы установили в файле состояния Nginx.
Поскольку теперь есть все нужные файлы, можно уничтожить миньон, на котором был установлен Nginx, и пересобрать его. Благодаря этому в дальнейшем вы сможете протестировать файлы состояния на чистом сервере. Уничтожьте миньон Nginx:
Затем можно пересобрать его.
Для этого обычно используется map-файл. Но для сборки одного сервера лучше использовать непосредственно профиль stage-web. Затем вместо salt-cloud можно использовать расширение Salt cloud.profile, что позволяет добавить флаг –async. Он может пересобрать сервер stage-www1 в фоновом режиме, пока вы продолжите работать. Также нужно настроить таргетинг на мастер Salt, так как этот сервер обладает всеми необходимыми профилями:
Пока нода stage-www1 собирается в фоновом режиме, вы можете продолжать работу.
Дизайн
Salt родилась как распределенная система для удаленного исполнения команд и данных запросов на удаленных узлах или «миньонах». Удаленное исполнение возможно либо на отдельных узлах, либо на группах по произвольным критериям выбора — «таргетинг».
Мастер — сервер, который запускает основные службы для общения с миньонами Salt. Он также содержит хранилище ключей для шифрования между ним и миньонами.
Миньоны — агенты, которые используют микро-версию Salt для локального исполнения и связи с мастером.
Движки — они же Salt Engines (солевые двигатели) — это внешние процессы, исполняемые в течение продолжительного времени, которые работают с Salt.
Состояния или формулы — файлы, содержащие YAML и шаблонные данные для настройки миньонов. Механизм шаблонов также очень гибок
Он не ограничивается поддержкой Jinja, но также поддерживает и chetah, genshi, mako (очень важно для тех, кто имеет опыт с Puppet), wempy или даже чистый Python.
-
Grains — Salt содержит интерфейс для получения информации о нижерасположенной системе. Он называется интерфейс «крупинок», потому что представляет собой «соль», состоящую из «крупинок» информации. Grains собираются для операционной системы, имени домена, IP-адреса, ядра, типа ОС, памяти и многих других свойств системы. Интерфейс grains доступен для модулей и компонентов Salt, так что нужные команды миньонов автоматически становятся доступными в соответствующих системах.
Peer System
Salt minions can pass commands using the peer interface. The peer interface is configured through the master configuration file either to allow minions to send commands from the master using the peer configuration section or to allow minions to execute runners from the master using the peer_run configuration.
Let us understand both these configurations in detail.
Peer configuration
The simple configuration to be defined in master file is as below −
peer:
.*:
- .*
Here, It enables communication for all minions, but it is only recommended for very secure environments.
To assign minions to specific ID’s, the configuration needs to be defined as shown below: peer −
.*domain.com: - test.*
peer_run Configuration
This configuration is to allow minions to execute runners from the master using the peer_run option on the master file. The following example is to allow access to all minions and to all the runners.
peer_run:
.*:
- .*
To assign minions to a specific ID, the configuration needs to be defined as given below −
peer_run:
.*domain.com:
- test.*
How to Execute Commands
To execute test.ping on all the minions, use the salt-call command along with the publish.publish module.
salt-call publish.publish \* test.ping
To execute runner, use the salt-call command along with the publish.runner module.
salt-call publish.runner manage.up
Previous Page
Print Page
Next Page
Команды Salt
Соль предоставляет ряд команд для работы с описанными выше компонентами. Основные функции вы найдете ниже.
- salt-master: это процесс мастер-демона. Вы можете запустить мастера с помощью этой команды напрямую или (что более типично) через сценарий инициализации или service-файл.
- salt-minion: аналогично, это процесс демона миньона, используемый для связи с мастером и выполнения команд. Эта команда также обычно запускается через сценарий инициализации или service-файл.
- salt-key: этот инструмент используется для управления открытыми ключами миньона, для просмотра и отбора текущих ключей, отправленных потенциальными миньонами. Он также может генерировать ключи для размещения на миньонах вне диапазона.
- salt: эта команда используется для таргетинга миньонов для запуска специальных модулей выполнения. Это основной инструмент удаленного выполнения.
- salt-ssh: эта команда позволяет использовать SSH в качестве альтернативы ZeroMQ.
- salt-run: эта команда используется для запуска модулей runner на главном сервере.
- salt-call: эта команда используется для запуска модулей выполнения на текущем миньоне. Она часто используется для отладки проблемных команд путем обхода мастера.
- salt-cloud: эта команда используется для управления облачными ресурсами разных провайдеров. Она позволяет легко запускать новые миньоны.
Конечно, это только основные команды.
Orchestrate Runner
he Orchestrate Runner offers all the functionality of the OverState (previous system). It is originally called as the state.sls runner. This orchestrate runner is used to generalize the Salt state system to a Salt master context.
The state.sls and the state.highstate functions are executed on each Salt minion, but the state.orchestrate runner is executed on the master. The state.orchestrate runner allows you to manage your entire infrastructure as state fully. Let us understand how to go through a simple execution process.
Simple Execution
The Orchestrate Runner command is same as the state.sls function, but you can execute it with the “salt-run” instead of salt.
Assume that you have a sample.sls file located at /srv/salt/orch/samples.sls. Add the following code in that file.
sample.sls
install_nginx:
salt.state:
- tgt: 'web*'
- sls:
- nginx
The following command is used to run on the master and it will apply the states defined in that file.
salt-run state.orchestrate orch.sample
It will produce the following output −
saltmaster.local_master: ---------- ID: install_nginx Function: salt.state Result: True Comment: States ran successfully. Started: 11:54:56.308078 Duration: 63.401 ms Changes: Summary for saltmaster.local_master ------------ Succeeded: 1 Failed: 0 ------------ Total states run: 1 Total run time: 63.401 ms root@saltmaster:/home/vagrant#
Here, according to the Current Version, the runner function was renamed to state.orchestrate. This will be helpful to avoid confusion with the state.sls execution function, but the previous versions of state.sls must be used.
Execute Function
To execute a function, you should use the salt.function. Consider a file data.sls located at /srv/salt/orch/data.sls. Now, add the following changes in that file.
data.sls
cmd.run:
salt.function:
- tgt: '*'
- arg:
- rm -rf /tmp/data
The following command is used to execute the Salt function.
root@saltmaster:/home/vagrant# salt-run state.orchestrate orch.data
It will produce the following output −
saltmaster.local_master:
----------
ID: cmd.run
Function: salt.function
Result: True
Comment: Function ran successfully. Function cmd.run ran on minion1, minion2.
Started: 12:14:54.791635
Duration: 234.615 ms
Changes:
minion1:
minion2:
Summary for saltmaster.local_master
------------
Succeeded: 1 (changed = 1)
Failed: 0
------------
Total states run: 1
Total run time: 234.615 ms
Previous Page
Print Page
Next Page
What is SaltStack?
Salt is a very powerful automation framework. Salt architecture is based on the idea of executing commands remotely. All networking is designed around some aspect of remote execution. This could be as simple as asking a Remote Web Server to display a static Web page, or as complex as using a shell session to interactively issue commands against a remote server. Salt is an example of one of the more complex types of remote execution.
Salt is designed to allow users to explicitly target and issue commands to multiple machines directly. Salt is based around the idea of a Master, which controls one or more Minions. Commands are normally issued from the Master to a target group of Minions, which then execute the tasks specified in the commands and then return the resulting data back to the Master. Communications between a master and minions occur over the ZeroMQ message bus.
SaltStack modules communicate with the supported minion operating systems. The Salt Master runs on Linux by default, but any operating system can be a minion, and currently Windows, VMware vSphere and BSD Unix variants are well supported. The Salt Master and the minions use keys to communicate. When a minion connects to a master for the first time, it automatically stores keys on the master. SaltStack also offers Salt SSH, which provides an “agent less” systems management.
Salt Commands
Salt provides a number of commands to take advantage of the components outlined above. There is some significant crossover in terms of functionality between these tools, but we’ve attempted to highlight their primary functions below.
- : This is the master daemon process. You can start the master service with this command directly, or more typically, through an init script or service file.
- : Likewise, this is minion daemon process, used to communicate with the master and execute commands. Most users will also start this from init scripts or service files.
- : This tool is used to manage minion public keys. This tool is used to view current keys and to make decisions about public keys sent by prospective minions. It can also generate keys to place on minions out-of-band.
- : This command is used to target minions in order to run ad-hoc execution modules. This is the main tool used for remote execution.
- : This command allows you to use SSH as an alternative to ZeroMQ for the transport mechanism.
- : This command is used to run runner modules on the master server.
- : This command is used to run execution modules directly on a minion you are logged into. This is often used to debug problematic commands by bypassing the master.
- : This command is used to control and provision cloud resources from many different providers. New minions can easily be spun up and bootstrapped.
There are some other commands as well, like , , and , which aren’t used quite so often.
CP Module
The CP module is the main module to manipulate the Salt file server. The salt-cp command can also be used to distribute files presented by the Salt file server.
GET_FILE
The cp.get_file function can be used on the minion to download a file from the master. It is defined as shown in the following code block.
salt '*' cp.get_file salt://vimrc /etc/vimrc
The above command instructs all Salt minions to download the vimrc file and copy it to /etc/vimrc.
Enable Template
You can enable template option in get_file as follows −
salt '*' cp.get_file "salt://vimrc" /etc/vimrc template = jinja
Apply Compression
To use compression, use the gzip named argument. The valid values are integers from 1 to 9, where 1 is the minimum compression and 9 is maximum value.
The command is defined as follows −
salt '*' cp.get_file salt://vimrc /etc/vimrc gzip = 5
GET_DIR
The cp.get_dir function can be used on the minion to download an entire directory from the master. It is defined in the following code block.
salt '*' cp.get_dir salt://etc/mysql /etc
The cp.get_dir supports template rendering and gzip compression arguments. If you want, you can assign as well.
Время начинать
Сила Ansible — это минимальное количество настроек (их, в принципе, нет). Популярность в сетевых задачах может быть обусловлена простотой и знакомством сетевых администраторов с CLI для управления удаленными устройствами без необходимости развертывания каких-либо дополнительных серверов для запуска программного обеспечения. Если у вас много небольших изолированных сайтов (например, коммерческих филиалов), следует подумать, не разделить ли архитектуру. Мой работодатель управляет сетями передачи данных в некоторых крупных сетевых супермаркетах, и я бы не решился иметь мастера в центре, в то время как магазины в сельских районах могут иметь ненадежную связь.
Configuration Settings
Let us understand the different configuration settings for logging, in detail.
LOG_FILE
Salt log records are passed through the file, which contains the local path name or the network location for identification. This file is considered as the log file.
log_file: /var/log/salt/master
Here, the file dependent of the binary being executed in master. Similarly, you can execute in the minion as well, which is shown below.
log_file: /var/log/salt/minion
You can also use remote address. The syntax for using the remote address is − <file|udp|tcp>://<host|socketpath>:<port-if-required>/<log-facility>.
log_file: udp://loghost:port
Here, the Log-facility defaults to LOG_USER.
LOG_LEVEL
The log levels are ordered in a numerically assigned value. Python library has defined most of the logging levels by default. In addition to that, Salt uses some more levels. Some of the levels are explained below.
-
log_level: error; level value is 40 − It indicates log statement record at error.
-
log_level: quiet; level value is 1000 − It indicates that nothing should be logged at this level.
-
log_level: info; level value is 20 − It indicates the normal log information.
-
log_level: warn; level value is 30 − It indicates log statement record at warning.
-
log_level: debug; level value is 10 − Information useful for debugging both salt implementations and salt code.
-
log_level: trace; level value is 5 − More detailed code-debugging information.
It defines the level of messages to send to the log file.
log_level_logfile: info
LOG_DATEFMT
It defines the log date format. By default, it is represented as %Y-%m-%d %H:%M:%S.
log_datefmt_logfile: '%Y-%m-%d %H:%M:%S'
LOG_FMT_CONSOLE
It defines the format of the console logging the messages. Salt uses a custom LogRecord attributes to colorize the console log output. It follows the following syntax −
'%(colorlevel)s' # log level name colorized by level '%(colorname)s' # colorized module name '%(colorprocess)s' # colorized process number '%(colormsg)s' # colorized messages name
LOG_FMT_LOGFILE
It defines the format of the log file logging the messages. The basic syntax is as follows −
%(asctime)s,%(msecs)03d %(message)s
LOG_GRANULAR_LEVELS
This level is used to control logging levels more specifically.
log_granular_levels: 'salt': 'info' 'salt.modules': ‘trace'
Here, the Main salt library at the ‘info’ level sets the salt.modules to log at the trace level.
External Auth System
The external auth system is used to provide access to execute salt commands on specific minions through external authorization system like PAM, LDAP, etc. This configuration file is defined in the master file as described below.
external_auth:
pam:
user1:
- 'web*':
- test.*
- network.*
user2:
- .*
Here,
-
user1 is allowed to execute functions in the test and network modules on the minions that match the web* target.
-
user2 is allowed to execute all the functions.
Enable the External Auth System in Command
Salt server provides an option ‘–a’ to enable external authentication.
salt -a pam web\* test.ping
Here, the -a pam option is used to enable PAM external authentication. Salt Server will ask for authentication details whenever we execute the command. To restrict Salt Server from asking the authentication details for the first time only, we can use the T option. This -T option caches the authentication details for the next 12 hours (default setting) and use it to authenticate the users.
salt -T -a pam web\* test.ping
6: Тестирование настройки
Настройка Nginx завершена. Теперь нужно протестировать состояния.
Используйте модуль выполнения state.show_sls, чтобы увидеть, как Salt интерпретирует файл Nginx. Используйте сервер stage-www1 в качестве цели.
Вы увидите такой результат:
Он в основном отображает информацию из файла /srv/salt/nginx/init.sls с некоторыми интересными дополнениями. Убедитесь, что Salt не допускает ошибок интерпретации и знает, как читать команды. Строка order – еще один важный аспект проверки. Она определяет, когда будет выполняться каждое из отдельных состояний в файле. Первое состояние будет иметь значение order 10000. Оттуда подсчитывается каждое дополнительное состояние
Обратите внимание, что __env__ отличается от env
Затем запустите пробный прогон файла состояния. Это можно сделать с помощью функции state.apply с параметром test=True. Команда выглядит так:
Эта команда покажет изменения, если удалить опцию test=True. Просмотрите все изменения и убедитесь, что Salt может правильно интерпретировать все файлы
Поле Comment особенно важно, так как оно может выявлять проблемы даже в тех случаях, когда Salt отмечает состояние как успешное
Если пробный прогон не выявил ошибок, вы можете попробовать применить состояние ко всем доступным в инфраструктуре веб-серверам.
Используя состояние Nginx в промежуточной или производственной среде, вам понадобится внутренний IP-адрес веб-серверов. Эти страницы не доступны по открытому интерфейсу.
Если вы применили состояние Nginx в среде разработки, вам понадобится внешний адрес серверов:
- sudo salt-call mine.get ‘role:webserver’ external_ip expr_form=grain
- Протестируйте серверы с помощью curl:
- curl ip_address
Вы получите страницу index.html:
Как видите, при отображении Jinja на страницу было добавлено имя хоста миньона.
Состояние Nginx работает правильно.
Salt State
Salt state is a reusable configuration for a specific part of a system. States are easier to understand and described using a simple YAML.
Create a Salt State
Salt states are easy to create. Let us create a simple state in this chapter. Move to the directory “salt-vagrant-demo/saltstack/salt/” and create a file named samples.sls and add the following lines in it.
samples.sls
install_network_packages:
pkg.installed:
- pkgs:
- rsync
- lftp
- curl
Now, save the file and run the following command in the Salt master.
root@saltmaster:/home/vagrant# salt 'minion1’ state.apply samples
Here, we installed rsync, lftp and curl through the pkg.installed module using the Salt state in a salt minion, minion1. If it works properly, you could see the response as shown below.
It will produce the following output −
minion1: ---------- ID: install_network_packages Function: pkg.installed Result: True Comment: All specified packages are already installed Started: 08:08:48.612336 Duration: 545.385 ms Changes: Summary for minion1 ------------ Succeeded: 1 Failed: 0 ------------ Total states run: 1 Total run time: 545.385 ms
Apply Salt State
Now that we have created a state using the ‘.sls’ file and applied it by specifically calling it. Salt has a default state file called as the top.sls file. The top file is used to apply multiple state files to Salt minions. The top file describes where states should be applied. Well, States and the Top file work together to create the core of SaltStack’s configuration management capability.
Let us now create a simple top.sls file in the directory saltstack/salt and add the following.
top.sls
base:
'*':
- common
'minion1':
- samples
Here, the state, commonly applies to all system state, samples applies to minion1.
Next, run the Salt master and apply the state as shown below.
root@saltmaster:/home/vagrant# salt '*' state.apply
It will produce the following output −
minion1: ---------- ID: common_packages Function: pkg.installed Result: True Comment: All specified packages are already installed Started: 09:33:35.642355 Duration: 588.21 ms Changes: Summary for minion1 ------------ Succeeded: 1 Failed: 0 ------------ Total states run: 1 Total run time: 588.210 ms minion2: ---------- ID: common_packages Function: pkg.installed Result: True Comment: All specified packages are already installed Started: 09:33:35.890331 Duration: 602.79 ms Changes: Summary for minion2 ------------ Succeeded: 1 Failed: 0 ------------ Total states run: 1 Total run time: 602.790 ms
Apply Batch Size
If you have a large number of connected minions, then you can limit how many systems are updated at once. It is performed by using the –batch-size option, which is defined below.
root@saltmaster:/home/vagrant# salt --batch-size 5 '*' state.apply
It will produce the following output −
Executing run on jid: 20170314094638482664 minion1: ---------- ID: common_packages Function: pkg.installed Result: True Comment: All specified packages are already installed Started: 09:46:41.228519 Duration: 582.24 ms Changes: Summary for minion1 ------------ Succeeded: 1 Failed: 0 ------------ Total states run: 1 Total run time: 582.240 ms retcode: 0 jid: 20170314094638482664 minion2: ---------- ID: common_packages Function: pkg.installed Result: True Comment: All specified packages are already installed Started: 09:46:41.153609 Duration: 605.235 ms Changes: Summary for minion2 ------------ Succeeded: 1 Failed: 0 ------------ Total states run: 1 Total run time: 605.235 ms retcode: 0
File Server Backend
The file server backend allows the Salt file server to act as a transparent interface to other file server like a local file system, Git version control system, etc.
A Git file server backend can be enabled by using the following configuration in the master file.
fileserver_backend: - git
To enable multiple backend file system, we can use the following configuration.
fileserver_backend: - roots - git
We can also specify the additional option for a different backend server using the specific section of the corresponding backend server.
For using this system, we have to use the following code.
file_roots:
base:
- /srv/salt/prod
For using this system, we have to use the following code.
gitfs_remotes: - https://github.com/sample/sample1.git
Requesting Files
Salt has the option to request files for specific environments.
salt://path/to/file?saltenv = base
Here, the environment is defined using the roots option.
1: Создание главного файла состояния Nginx
Salt обрабатывает управление конфигурацией через систему состояний. В простейшем случае конфигурации контролируются файлами, расположенными в корневом каталоге сервера Salt (в данном случае это /srv/salt). Чтобы начать настройку Nginx, создайте каталог в этом месте.
Файлы состояний имеют суффикс .sls. Файл init.sls в каталоге работает как главный конфигурационный файл определенного состояния или формулы Salt. Для выполнения функций, содержащихся в соответствующем файле init.sls, нужно сослаться на имя родительского каталога.
Создайте и откройте файл init.sls в этом каталоге, чтобы начать:
Состояния пакетов и сервиса Nginx
Для начала нужно создать состояние с помощью идентификатора nginx. Это будет уникальным названием для данного состояния в системе состояний Salt. Поскольку модули состояния включать атрибут name, идентификатор также будет использоваться в качестве цели для установки (в функции pkg.installed) и сервиса, который нужно запустить (в функции service.running).
Nginx должен автоматически перезагружаться при определенных условиях: после обновления пакета, изменения основного конфигурационного файла или виртуального хоста по умолчанию. Salt может перезапускать Nginx при возникновении этих условий с помощью параметра watch:
Ключи pkg: и file: после watch: представляют модули состояний, связанные с отслеживаемыми ресурсами. Ресурс pkg определяется в первой части файла. Затем нужно создать состояния для ресурсов file.
Состояние конфигурационного файла Nginx
Начать можно с файла /etc/nginx/nginx.conf. Этот файл нужно добавить в систему управления конфигурацией. В терминологии Salt это значит, что вы определите содержимое файла на мастер-сервере и выгрузите его на каждый миньон, который в нем нуждается. Установите обычные права доступа и собственности на файл. Строка source ссылается на файл на сервере Salt (текущий файл также находится в этой структуре). Этот путь будет создан позже.
Также нужно контролировать содержимое файла /etc/nginx/sites-available/default. Это виртуальный хост по умолчанию, который определяет, как будет обслуживаться контент. Этот блок состояния будет похож на предыдущий. Основное различие между ними заключается в том, что этот файл будет шаблоном Jinja.
Шаблоны Jinja позволяют Salt добавлять в файл индивидуальные параметры для каждого из миньонов. Это позволяет извлекать информацию с каждого хоста и создавать соответствующую версию файла для каждого из веб-серверов. Чтобы указать, что этот файл будет использовать Jinja, добавьте параметр template. Также нужно использовать суффикс .jinja в исходном файле.
Теперь виртуальный хост по умолчанию будет размещен в каталоге sites-available на хостах-миньонах. Однако его все равно нужно связать с каталогом sites-enabled, чтобы активировать его. Это можно сделать с помощью функции file.symlink. Здесь просто нужно указать исходное местоположение файла в качестве target. Также необходимо добавить параметр require, чтобы это состояние выполнялось только после успешного выполнения предыдущего состояния:
Состояние для контента сайта
Теперь в файле есть записи для установки и настройки Nginx. После этого нужно создать состояние для файла index.html, который будет содержать контент сайта.
Это состояние использует тот же формат, что и предыдущее состояние шаблона. Отличаются только идентификатор, источник и права доступа:
Сохраните и закройте файл.
1: Сбор информации MySQL с помощью debconf-utils
Процесс создания состояний MySQL будет немного более сложным, чем в предыдущих примерах с Nginx и HAProxy. В отличие от этих двух приложений, установка MySQL обычно подразумевает ответы на ряд вопросов инсталлятора.
Прежде чем начать работу над файлом состояния, нужно выполнить тестовую установку MySQL на одном из миньонов. Затем вы можете использовать пакет debconf-utils для сбора информации о вопросах инсталлятора, которые нужно будет заполнить.
Если у вас до сих пор нет промежуточной среды, создайте ее:
После того, как серверы баз данных будут доступны, выберите один из этих серверов и установите на него MySQL, чтобы затем собрать соответствующую информацию:
Чтобы легко запросить в базах данных debconf необходимую информацию, нужно установить пакет debconf-utils на миньон базы данных:
Теперь в Salt будут доступны функции debconf. Можно использовать функцию модуля выполнения debconf.get_selections, чтобы собрать всю информацию для установки базы данных. эти данные нужно направить в less, потому что это вернет всю информацию из пакетов, установленных на этом хосте.
В выводе найдите раздел для MySQL.
Две верхние записи содержат имена полей, которые вам нужны (mysql-server/root_password и mysql-server/root_password_again). Вторая строка в этих записях задает тип поля, который нужно указать в файле состояния.
Скопировав эту информацию из вывода debconf, вы должны извлечь файл /etc/mysql/my.cnf. Он понадобится позже при настройке MySQL.
Переместив файл /etc/mysql/my.cnf на мастер Salt, удалите этот ресурс, чтобы создать свежий сервер для дальнейшей работы.
Удалив сервер, вы можете воссоздать его в фоновом режиме с помощью этой команды (где sm – имя мастера Salt).
Пока создается сервер БД, вы можете создать файл состояния для MySQL.
