{"id":774,"date":"2021-04-12T13:01:09","date_gmt":"2021-04-12T12:01:09","guid":{"rendered":"https:\/\/nine30.info\/?p=774"},"modified":"2021-04-12T13:01:09","modified_gmt":"2021-04-12T12:01:09","slug":"vra-saltstack-config-declarative-configuration-management","status":"publish","type":"post","link":"https:\/\/nine30.nxt70.com\/index.php\/2021\/04\/12\/vra-saltstack-config-declarative-configuration-management\/","title":{"rendered":"vRA SaltStack Config \u2013 Declarative Configuration Management"},"content":{"rendered":"\n

So far we covered SaltStack remote execution (do you remember the command salt myminionid pkg.install httpd<\/code> and the Salt Execution Module? If not check this post<\/a>) which is great and powerful, but it is more suited for spot activities. Actually when you have to manage complex systems configuration at scale you need a combination of many operations, commands and tests each with their peculiarity. This would turn out into a script which is procedural.<\/p>\n\n\n\n

Actually Salt also supports (and it is popular for) declarative approach. SaltStack lets you create a re-usable configuration template, called a State file<\/strong>, that describes everything required to put a system or application into a known configuration. With State file SaltStack adopts a declarative approach: you describe the desired state of your managed systems and SaltStack make sure this is applied to the Target you specify<\/strong>. States are described using YAML and are simple to create and read. Honestly, States are much easier to understand when you see them in action, so let\u2019s play with them.<\/p>\n\n\n\n

States<\/h2>\n\n\n\n

States can install packages, manage files, manage users, restart services when changes are made, copy entire directories, explicitly require that other states run first, use variables, and much more. To get a introduction to these capabilities with a very simple, but non trivial, example we will create a State file that installs and provides basic configuration for an Apache Web Server on a CentOS 7 machine. We will do this in a single State file step by step.<\/p>\n\n\n\n

SaltStack cool kids work with YAML file editor (e.g. VS Code) and git repos and we’ll get there sooner or later, but here I think it is better to stick with the vRA SaltStack Config user interface so that we can focus on the heart of the matter. In order to create our state file you have to login in the UI and navigate to Elements > File Server, here you select base<\/code> in the Saltenv drop down menu and type \/applications\/apache\/init.sls<\/code> in path name text field as in the picture below. Click on the Save button (that now should be blue and not greyed out) in order to create a (empty) State file named init.sls<\/code> in the base<\/code> environment (Saltenv) under the path \/applications\/apache<\/code>. This nesting under Applications and Apache directories is not really needed now, but it will be useful in our future activities. In general it is best practice to keep directory structure as flat as possible. <\/p>\n\n\n\n

\n
\"\"<\/figure>\n<\/figure>\n\n\n\n

Here we just introduced a couple of new things: File Server and Environment, these are important concept and we might cover them in another post as I do not want to divert now from the main topic. So far it is enough to know that as in SaltStack all configurations are based on files, it comes with a simple File Server<\/strong> suitable to present files for use in the SaltStack state system. In addition to the default File Server backend (named roots<\/code>) you can configure other backends (e.g. gitfs<\/code>), here<\/a> you can access the list of available backends. The SaltStack File Server supports multiple Environments<\/strong>, allowing for State files and other files to be isolated for better organization. Each File Server backend comes with its own way to configure Environments. <\/p>\n\n\n\n

Let’s start building our State file step by step. As a first thing we will install the Apache Web Server, the related software package in the Red Hat family is named httpd; it is important to know the package name in the OS family you are working with (remember to automate something you need to know how to do it manually). The piece of YAML configuration required is reported in the snippet below, easy no? Type the snippet below in your init.sls<\/code> files and hit Save button.<\/p>\n\n\n\n

# Install and Configure Apache HTTPD on RHEL\/CoreOS\n\ninstall_apache:\n  pkg.installed:\n    - name: httpd<\/code><\/pre>\n\n\n\n
OK, what’s in there?<\/p>\n\n\n\n