This document provides an introduction and overview of Salt for Ansible users. It discusses how Salt uses a master-minion architecture like Ansible but also allows running commands directly on minions. States in Salt are similar to Ansible playbooks but are rendered with Jinja. Pillars and grains in Salt provide more flexible ways to handle variables than Ansible. The document highlights how Salt's pluggable architecture and features like returners, reactors, engines make it more powerful than Ansible for automating infrastructure.

1. Salt for Ansible Users
Paul Traylor
Fukuoka SRE Meetup #2
2019/10/12
1 / 19

2. Introduction
LINE Fukuoka Server Observability Team
Providing tools for developers to increase their development velocity
Promgen - Prometheus management tool https://github.com/line/promgen
Prometheus as a Service
Grafana as a Service
Sentry as a Service
https://linefukuoka.co.jp/ja/career/list/engineer/Monitoring_System
2 / 19

3. Agenda
What is Salt ?
Salt intro for Ansible users
Salt for automating (almost) everything
3 / 19

4. What is Salt ?
Salt is a new approach to infrastructure management built on a dynamic
communication bus. Salt can be used for data-driven orchestration, remote
execution for any infrastructure, configuration management for any app stack,
and much more.
https://docs.saltstack.com/en/latest/
4 / 19

5. Salt Intro - Master + Minion
By default, Salt uses a Client/Server model
Minions are authenticated using RSA keys
Commands and Results are sent over ZeroMQ by
default
https://docs.saltstack.com/en/getstarted/overview.html
5 / 19

6. Salt Intro - SSH Mode
Salt also supports an SSH mode which is similar to Ansible
https://docs.saltstack.com/en/getstarted/overview.html
6 / 19

7. Salt Intro - Master
Running commands is similar to Ansible
# salt <target> <command> <args>
salt '*' test.version
salt 'web*' pkg.install nginx
salt 'database*' state.apply mysql.server test=True
7 / 19

8. Salt Intro - Minion
But you can also run the same commands on the minion directly
This is super userful for testing and debugging
salt-call test.version
salt-call pkg.install nginx
salt-call state.apply mysql.server test=True
8 / 19

9. Salt Intro - States
Salt states look similar to Ansible playbooks
States are rendered as Jinja and then loaded as Yaml
/etc/foo.conf:
file.managed:
- source:
- salt://foo.conf.{{ grains['fqdn'] }}
- salt://foo.conf.fallback
- user: foo
- group: users
- mode: 644
- attrs: i
- backup: minion
https://docs.saltstack.com/en/latest/ref/states/all/salt.states.file.html
9 / 19

10. Salt Intro - States
There is no distinction between playbooks and roles, everything is a state
include:
- nginx
/etc/nginx/conf.d/example.conf:
file.managed:
- source: salt://example/example.conf
- template: jinja
10 / 19

11. Salt Intro - Pillars and Grains
Ansible precidence always confuses me.
https://docs.ansible.com/ansible/latest/user_guide/playbooks_variables.html
command line values (eg “-u user”)
role defaults [1]
inventory file or script group vars [2]
inventory group_vars/all [3]
playbook group_vars/all [3]
inventory group_vars/* [3]
playbook group_vars/* [3]
inventory file or script host vars [2]
inventory host_vars/* [3]
playbook host_vars/* [3]
host facts / cached set_facts [4]
play vars
play vars_prompt
play vars_files
role vars (defined in role/vars/main.yml)
block vars (only for tasks in block)
task vars (only for the task)
include_vars
set_facts / registered vars
role (and include_role) params
include params
extra vars (always win precedence)
11 / 19

12. Salt Intro - Pillars and Grains
Pillars come from the salt-master and are for cluster level or secrets
Grains come from the target machine, and are used for things like OS version, CPU
count, memory, etc
Salt gives you flexibility to handle variables how you want
# Import from other files
{% import_yaml "myfile.yml" as myfile %}
{% import_json "defaults.json" as defaults %}
{% import_text "completeworksofshakespeare.txt" as poems %}
{{defaults.port}}
# Read from Grains or Pillars
{{salt['grains.get']('fqdn')}}
{{salt['pillar.get']('role')}}
# or write your own module
{{ salt['vars.get']('example:db:password')}}
https://docs.saltstack.com/en/latest/ref/renderers/all/salt.renderers.jinja.html
12 / 19

13. Salt for automating - Plugable
https://docs.saltstack.com/en/getstarted/system/plugins.html
13 / 19

14. Salt for automating
Salt is a new approach to infrastructure management built on a dynamic
communication bus. Salt can be used for data-driven orchestration, remote
execution for any infrastructure, configuration management for any app stack,
and much more.
The dynamic communication bus and well defined plugable architecture makes Salt
significantly more powerful than ansible
https://docs.saltstack.com/en/latest/
14 / 19

15. Salt for Automating - Returners
Returns provide Salt with a flexibile system
for sending the output of jobs into any
system imagionable
mysql
elasticsearch
kafka
mongodb
slack
https://docs.saltstack.com/en/getstarted/overview.html
https://docs.saltstack.com/en/latest/ref/returners/
15 / 19

16. Salt for Automating - Reactors
Salt can react to various events within your
system
reactor:
- 'salt/minion/*/start':
- /srv/reactor/start.sls
- /srv/reactor/monitor.sls
- 'salt/cloud/*/destroyed':
- /srv/reactor/destroy/*.sls
- 'myco/custom/event/tag':
- salt://reactor/mycustom.sls
https://docs.saltstack.com/en/getstarted/overview.html
https://docs.saltstack.com/en/latest/topics/reactor/
16 / 19

17. Salt for Automating - Engines
Salt engines can be used to accept or process internal or external events
engines:
- webhook:
port: 8000
address: 10.128.1.145
ssl_crt: /etc/pki/tls/certs/localhost.crt
ssl_key: /etc/pki/tls/certs/localhost.key
- slack:
token: 'xoxb-xxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx'
control: True
fire_all: False
- docker_events:
docker_url: unix://var/run/docker.sock
filters:
event:
- start
- stop
- die
- oom
https://docs.saltstack.com/en/latest/topics/engines/index.html
17 / 19

18. Salt for Automating - Automate Github
Deployments
# salt-master configuration
# Load a simple webhook so that we can easily map GitHub webhooks
engines:
- webhook: {}
reactor:
- 'salt/engines/hook/github':
- salt://_reactor/autodeploy.sls
#!yaml|github
# salt://_reactor/autodeploy.sls
line/promgen: # Whenever we update Promgen
refs/heads/master: # we want to deploy the master branch
deploy-promgen-web:
local.state.sls: # by applying a salt state
- tgt: role:promgen # matching our promgen servers
- tgt_type: pillar
- args:
- mods: promgen.web
- ret: slack # and let me know the result on slack
https://github.com/kfdm/salt-deployhook 18 / 19

19. Questions ?
https://linefukuoka.co.jp/ja/career/list/engineer/Monitoring_System
19 / 19