on 25-Jul-2017 03:36
Problem this snippet solves:
Advantages of using iApps for automation instead of plain ansible, plain REST calls, etc...
When deploying configurations as iApps the configurations are self-contained, that is: on delete all objects created by the iApp are automatically deleted and there will be no stale configurations left
iApps can be deployed with ansiblle, REST, etc... configurations just become easier to deploy because regardless the configuration size only two calls are quired: one call to import the template (if it is not already in the BIG-IP) and one to create an instance of the iApp.
tmsh2iapp allows creation of iApps that contain base configs too (ie: L1/L2/L3 network elements including non floating ones) which can be sync'ed in HA configurations seamlessly.
Main characteristics of tmsh2iapp
- apache-ssl-cert SSL certificates management
- asm-policy ASM policies
- browser-capabilities-db browser capabilities DB file management
- dashboard-viewset
- data-group External Data Group files management
- device-capabilities-db Device capabilities DB file management
- external-monitor External Monitor files management
- ifile iFile files management
- lwtunneltbl LW4o6 table files management
- ssl-cert SSL certificates management
- ssl-csr SSL Certificate Signing Request
- ssl-key SSL certificate keys management
How to use this snippet:
Visit the project's page and wiki in https://github.com/f5devcentral/f5-tmsh2iapp
Code :
https://github.com/f5devcentral/f5-tmsh2iapp
Sep 28 - New feature and fixes release
The two fixes have been found thanks to a new semi-automated regression testing that I'm now running on this tool.
New feature release
Like any other iApp, the iApps created by tmsh2iapp can be deployed in any partition. By default iApp's objects are created in the //. This allows having several instances of the same iApp in the same partition.
I had a request of optionally implementing a different behavior. The next two features allow iApp's objects to be created by default in /. In other words: without a per-iApp folder. Therefore when using this option it will not be possible to create two instances of the same iApp in the same partition but several instances in several partitions will be still possible.
Features:
I wanted to share with you a new release of tmsh2iapp which has got relevant new features over the last months:
It now supports all LTM, ASM, APM, AFM and PEM modules.
Yes, the tool is also able to import ASM policies specifying an external file or URL. For referencing an ASM policy no special BIG-IP version is required. For importing an external ASM policy it requires fixes for ID693694 and ID675232 and ideally ID721717.
Yes, the tool is able to generate APM policies.
The tool got it's first contribution to this Open Source project! tmsh2iapp already supported routing domains and partitions but Colin Stubbs provided enhanced support for detecting the partition’s default routing domain and create pool member’s nodes more appropriately.
The tool got other minor fixes and features including automated testing with ansible. Check out the wiki for more details
If you are using the tool It would be great to hear from you. Please let me know if you have any questions.
New release with two new features:
Allow input variables to be a JSON list. This is useful for Ansible Tower surveys or any other YAML/JSON based automation.
Dump all variables values in /var/tmp/scriptd.out before execution
New release with a new feature for improved GUI usability: