Introducing the IBM MQ Puppet module.
Yesterday we announced the availability of our new IBM puppet modules. Besides modules for IBM Integration Bus (IIB), we also announced puppet modules to install and configure IBM MQ. This blog post will introduce these modules.
Get the examples
We have created a git repository that contains an example on how to use our MQ puppet modules. In there we show you how to use best our modules. We are going to use this repository.
Go to your preferred working directory and enter:
$ git clone git@github.com:enterprisemodules/simple_mq_demo.git
This will create a local copy.
The tools of trade
This example is designed, so you run on your own Workstation running Vagrant and VirtualBox. So to get started, you’ll need Vagrant and VirtualBox. You can find the information on how to install VirtualBox here at the VirtualBox website. 
To install Vagrant, go to the vagrant downloads page, and download the package for your platform. Then install it using standard procedures for your operating system. Because we only use Puppet inside the virtual machine, you don’t need to install Puppet on our workstation.
Required software
The examples repository doesn’t contain the IBM software needed to get the nodes running. You’ll need to contact your IBM representative to get the software. Rember that this is licensed software and you can only use it if you are licensed. In the [README(https://github.com/enterprisemodules/simple_mq_demo/blob/master/README.md), you can find a list of the software needed when you want to run the box.
Masterless Puppet
Most of our clients use Puppet Enterprise and of course our modules work with the newest version of Puppet Enterprise. But to focus on the IBM MQ installation and configuration, this example contains a Puppet masterless setup. A setup you can easily run on any PC or laptop.
All set….go
Before we dive in and explain some things, let’s first get our MQ machine up and running.
$ vagrant up ml-mq01
This will start Vagrant, create a virtual machine and start Puppet. This is how it should look.
The installation of MQ
The installation of MQ is taken care of by our mq_install module. Here is the code that does this:
contain ::mq_install::installmq
Yes this is it. The module has a lot of sane defaults, so installing MQ is as easy as it gets. You must, however, tell it what version to install and where to find the tar file containing the software. This is done in the hiera data.
mq_install::software::source_location: /vagrant/software
mq_install::software::version: 9.0.0.0
You can find these settings in the file `hieradata/nodes/mq01.example.com.yaml’
At this point the mq_install module supports the installation of MQ versions 8 and 9. The only thing you have to do to install version 8 of MQ, is to provide it with the correct tar file and change the setting mq_install::software::version: 9.0.0.0 to 8.0.0.0.
Optional MQ components
By default the mq_install::installmq will only install required components. But you can instruct it to install some or all of the optional components. You can do this by putting the next settings in your hiera data:
mq_install::software::install_ams: true # Install AMS packages
mq_install::software::install_ft: true # Install FT packages
mq_install::software::install_client: true # Install Client packages
mq_install::software::install_explorer: true # Install Explorer packages
mq_install::software::install_xrserver: true # Install XRServer packages
mq_install::software::install_samples: true # Install Samples packages
mq_install::software::install_sdk: true # Install SDK packages
mq_install::software::install_man: true # Install man packages
mq_install::software::install_gskit: true # Install GSKit packages
mq_install::software::install_amqp: true # Install AMQP packages
Configuring your MQ setup
When it comes to Enterprise Middleware, Installation is where most Puppet modules stop. But we think the configuration of your middleware setup is just as important if not more important. So our mq_config module allows you to customize your entire MQ setup. It has support for:
mq_managerfor setting up and maintaining queue managersmq_queuefor creating and maintaining queue’s and their settingsmq_topicfor creating and maintaining topics and their settingsmq_channelfor creating and maintaining channels and their settings.
In the example repo, all the MQ configuration is done in the file profile/manifest/example/mq_setup.pp. Let’s look at some content.
Queue Managers
The first thing that has to be done is defining a queue manager. Here is the puppet code for that:
mq_manager { 'QM1':
ensure => 'present',
# acctcono => 'DISABLED',
# acctint => '1800',
# acctmqi => 'OFF',
# acctq => 'OFF',
# activrec => 'MSG',
# actvcono => 'DISABLED',
# actvtrc => 'OFF',
# authorev => 'DISABLED',
# ccsid => '1208',
# certlabl => 'ibmwebspheremqqm1',
# certvpol => 'ANY',
# chad => 'DISABLED',
# chadev => 'DISABLED',
# chlauth => 'ENABLED',
# chlev => 'DISABLED',
# clwllen => '100',
# clwlmruc => '999999999',
# clwluseq => 'LOCAL',
# cmdev => 'DISABLED',
# configev => 'DISABLED',
# connauth => 'SYSTEM.DEFAULT.AUTHINFO.IDPWOS',
# defclxq => 'SCTQ',
# inhibtev => 'DISABLED',
# ipaddrv => 'IPV4',
# localev => 'DISABLED',
# loggerev => 'DISABLED',
# markint => '5000',
# maxhands => '256',
# maxmsgl => '4194304',
# maxpropl => 'NOLIMIT',
# maxumsgs => '10000',
# monacls => 'QMGR',
# monchl => 'OFF',
# monq => 'OFF',
# perfmev => 'DISABLED',
# psclus => 'ENABLED',
# psmode => 'ENABLED',
# psnpmsg => 'DISCARD',
# psnpres => 'NORMAL',
# psrtycnt => '5',
# pssyncpt => 'IFPER',
# remoteev => 'DISABLED',
# revdns => 'ENABLED',
# routerec => 'MSG',
# schinit => 'QMGR',
# scmdserv => 'QMGR',
# sslev => 'DISABLED',
# sslfips => 'NO',
# sslkeyr => '/var/mqm/qmgrs/QM1/ssl/key',
# sslrkeyc => '0',
# statacls => 'QMGR',
# statchl => 'OFF',
# statint => '1800',
# statmqi => 'OFF',
# statq => 'OFF',
# status => 'running',
# strstpev => 'ENABLED',
# suiteb => 'NONE',
# treelife => '1800',
# trigint => '999999999',
}
This puppet code define’s an MQ queue manager named QM1. In this example, we only use the ensure => present. This means we only make sure the queue manager exists. The mq_config module will use defaults for all specified properties. All the properties commented out with the # can bu used to change on of the defaults. As you can see this is a large list of properties. Check the documentation here, to see what all these properties mean and what values are allowed.
Queues
After the creation of the queue manager, we can start defining some queues. Here we difine the queue MY.QUEUE.FIRST:
mq_queue { 'QM1/MY.QUEUE.FIRST':
ensure => 'present',
# acctq => 'QMGR',
# bothresh => '0',
# clwlprty => '0',
# clwlrank => '0',
# clwluseq => 'QMGR',
# defbind => 'OPEN',
# defpresp => 'SYNC',
# defprty => '0',
# defpsist => 'NO',
# defreada => 'NO',
# defsopt => 'SHARED',
# distl => 'NO',
# get => 'ENABLED',
# maxdepth => '5000',
# maxmsgl => '4194304',
# monq => 'QMGR',
# msgdlvsq => 'PRIORITY',
# npmclass => 'NORMAL',
# propctl => 'COMPAT',
# put => 'ENABLED',
# qdepthhi => '80',
# qdepthlo => '20',
# qdphiev => 'DISABLED',
# qdploev => 'DISABLED',
# qdpmaxev => 'ENABLED',
# qsvciev => 'NONE',
# qsvcint => '999999999',
# qtype => 'QLOCAL',
# retintvl => '999999999',
# scope => 'QMGR',
# statq => 'QMGR',
# trigdpth => '1',
# trigmpri => '0',
# trigtype => 'FIRST',
# usage => 'NORMAL',
}
Again, we use the bare minimal setting: ensure => present and leave all defaults to MQ. But there is a large list of properties you can manage. The title of the resource is: QM1/MY.QUEUE.FIRST. As you can see, the title contains the name of the queue manager the queue is defined on. This means that the mq_config module supports managing multiple queues on multiple queue managers. You can see the documentation of all properties available for mq_queue here.
Topics
After the queues are defined, we start defining the topics. The way this is done, is very similar to defining queues.
mq_topic { 'QM1/MY.TOPIC.FIRST':
ensure => 'present',
ttype => 'LOCAL',
topicstr => 'my_topic_str',
# defpresp => 'ASPARENT',
# defprty => 'ASPARENT',
# defpsist => 'ASPARENT',
# dursub => 'ASPARENT',
# mcast => 'ASPARENT',
# npmsgdlv => 'ASPARENT',
# pmsgdlv => 'ASPARENT',
# proxysub => 'FIRSTUSE',
# pub => 'ASPARENT',
# pubscope => 'ASPARENT',
# sub => 'ASPARENT',
# subscope => 'ASPARENT',
# usedlq => 'ASPARENT',
# wildcard => 'PASSTHRU',
}
You can find the documentation for all properties here
Introspection
Not a lot of people know (or use) this, but puppet allows introspection of the current configuration. All of our config modules support the puppet introspection. You can ask puppet what queues are defined on a system and what their properties are. Let’s log into the Vagrant box and ask puppet what queues are available:
$ vagrant ssh ml-mq01 # ssh into the Vagrant box as vagrant
[vagrant@mq01 ~]$ sudo -i # Log in as root user
[root@mq01 ~]# puppet resource mq_queue # Ask for all mq_queues
Using this feature, you can inspect your current MQ configuration and save it in the form of a puppet manifest.
Conclusion
We hope this article helps you to get a glimpse of what you can do with Puppet and MQ. There is a lot more though. If you are interested, contact us so we can discuss how you can use these puppet modules to speed up your IBM software provisioning and deployment. If you want to start in your own infrastructure, take a look at our FREE MQ starter pack
