- Introduction
- Prerequisites
- Ansible playbooks - a short introduction
- Overview of files
- Running and testing the playbook
There several possibilities of configuring a Solace message router via the cli:
- interactively at the Solace cli prompt
- by using the command source at the cli prompt
- by using the cli options.
For Using Ansible we need the hidden options of the cli. The sample code configures two syslog objects by using Ansible and the Solace Cli with its hidden options. The big advantage of this cli approach is that you are able to do a complete router configuration. Using the SEMPv2 API - together with your prefered configuration management tool - allows only a partial configuration of the message router.
Before you can start applying the sample code you have to create a user on the Solace router, e.g. ansible. This user has to be member of the sysadmin group. Unlike the default admin user - which has the cli has the login program - the user ansible has /bin/bash as login program. Furthermore the user should have a ~ansible/.ssh/authorized_keys file. You also need a SSH public key which fits to SSH private key you will use on the Ansible server. This public key has to be pasted into the authorized_keys file. If you are using the Solace docker image you can create a Dockerfile that will do these adjustments. Code was tested with the default solace Docker image release 9.0.0.17.
Docker hostname in the sample code is mysrv001. The Solace SSH port 2222 is only published to the service LAN interface of the docker host. We use the name mysrv001sv for this interface.
The sample configuration definitions have to reside on the Ansible management server. All code was tested on RHEL 7.3 and Ansible 2.7.9. The user on the Ansible server should be able to contact the message router via ssh using port 2222. The following command must work
ssh -p 2222 ansible@mysrv001sv
With Ansible playbook you can send commands to a solace message router using ssh. Playbooks are written in YAML data serialization format. Each playbook is build of one or several tasks. For configuring Solace objects we normally have to run some Ansible tasks, e.g.
- Transfer, Run and check current config
- Build the cli script by using a template cli script
- Transfer the cli script to the message router
- ...
This file ist the playbook. hosts: {{env}} defines the group of routers we want to configure. A group is defined in the ini file. In our example the ini file is hosts.yml. We pass the value for the host key as an extra variable env with the ansible-playbook command using the -e option. become: true means that all commands will be run through sudo, so the commands will be run as the root user. We include the file vars/syslog-{{env}}.yml which contains all variables related to the syslog configuration for test group. Infos from the managed Solace router aren't necessary so we set gather_facts: false We find one task in our playbook. But by using include_role further tasks inside the appropriate role subdirectory will run. By using with_items we are looping the main task and we are able to two several syslog configurations.
Ansible works against multiple systems in your infrastructure at the same time. It does this by selecting portions of systems listed in the inventory. In our example the inventory file is hosts.yml. In this file we define the group test* of message routers. We have one router mysrv001sv in this group. Also we define 2 group specific vars. ansible_port defines the SSH port we want to connect to. The ansible_user variable conatins the name of the user we defined on the router
In this file all variables for the syslog configuration are set. In this file also the variables status and overwrite are set. With their values you can define if an object is present or absent and how to handle an already existing syslog object.
This is the cliscript to get the current-config of the message router.
This ist the template for building the syslog cli-scripts. The jinja code and the variables allow a flexible build of the appropriate cli script.
The tasks defined in this file are doing the syslog configuration:
- Copy the show_current_config.cli to the cliscripts directory if it not exists and execute it.
- Depending on the current configuration and the value of the status respective the overwrite variable the fact cliaction will be set.
- The cliscript based on the template syslog.tp.cli will be transfered to the message router. The name of the syslog object is part of the cliscript name.
- Finally the transfered cliscript will be excuted and the output will be checked.
If you want to test the sample code just do the following steps:
- Replace the name mysrv001sv in hosts.yml
- Adjust the syslog configuration in vars/syslog-test.yml
Afterwards you can run the following command:
ansible-playbook -e env=test syslog.yml -i hosts.yml
If the syslog objects defined in the syslog-test.yml do not exist they will be created if you set status: present You can verify the creation of the syslog object at the solace prompt:
show syslog *
Afterwards you can change one port for mysyslog1 If overwrite: no is set the configuration will stay the same on the message router. Because mysyslog1 already exists and you defined the object will not be overwritten. If you set overwrite: yes the old config will be updated by deleting the old object and rebuilding it with the same name. If you run the playbook a second time with overwrite: yes without changing any value also the complete config will be deleted and rebuild. Updating an object this manner is not optimal. But it makes things much easier. Checking all values of the current configuration against the desired values defined on you Ansible server is much more complicated If you want to avoid overwriting an existing config than just set overwrite: no. If you want to delete an object then set status: absent