When we go into a customer doing a pre-sales presentation or a PoC, a regular question comes up: "We currently have a whole range of scripts currently in production, can we re-use these scripts?" and the answer is "Yes, you can". And this is true, we can just copy the existing scripts into a BLPackage as external commands and 9 out of 10 times this will work.
But there is a huge disadvantage of doing this.
First of all there is the readability of the BLPackage. Usually only OS experts are able to understand what the commands in the scripts mean.
Then there is the matter of roll-back. Usually the script gets added as an external command, but the Undo Commands are never created. So what happens if the package get deployed to the wrong server? In the worst case you have to restore a backup.
So what do we do? While importing scripts in a BLPackage works we better "migrate" the script into a BLPackage. How do we do that? Here is an example. Let's take the following piece of a script that installs JBoss on a RedHat server:
;copy JBoss source files to target server
1. scp <jboss source dir> <target server>
2. groupadd www
4. chmod -R 755 /opt/jboss
5. cp -r /opt/jboss/* /opt/jboss
6. cd /opt/jboss/bin
7. sed 's/#JAVA_HOME="\/usr\/java\/jdk1.6.0"/JAVA_HOME="\/opt\/java\/jdk1.6.2"/g' run.conf >> run_variable.conf
8. chmod 755 /opt/jboss/bin/run_variable.conf
9. mv /opt/jboss/bin/run.conf /opt/jboss/bin/run.conf_original
10. cp /opt/jboss/bin/run_variable.conf /opt/jboss/bin/run.conf
11. cd /opt/jboss/server
12. rm -rf web standard minimal all
;add permissions to logs
32. mkdir /opt/jboss/logs
34. touch nohup.out
35. chmod 755 /opt/jboss/logs/nohup.out
36. mkdir /opt/jboss/server/default/log
37. chmod 755 /opt/jboss/server/default/log/
and the script goes on and on. A total of over 100 lines.
So how do we translate this into a package BSA-style? The first thing we need to do is to let go of the idea that BSA has to perform the actions that we want. This is script-thinking. What we want is to describe the desired state of our server after deployment of JBoss. And we don't really care what operations BSA uses to accomplish that.
Let's break the script up line-by-line.
2,3: Unix Users and Groups are native BSA objects, so we will create and entry in the BLPackage with the user and group.
1,4,5: Instead of copying the source files to temporary storage on the target server and then copying it to the right directory, we can include the files directly in the BLPackage AND with the right permissions.
7-10: To manage configuration files we can create a Configuration File object in BSA's Configuration Object Dictionary.
11-12: As i explained before, BLPackages describe the desired state of a server. If, for some reason, the directories mentioned in line 12 of the script are present on the target server, you can explicitly tell BSA to remove those directories by selecting the Delete option for these directory objects.
32-35 and 36,37: This can all be done by just adding the file nohup.out to the BLPackage with the correct path and permissions.
The script is much larger than this, but i think i made my point.
Using BSA's BLPackage technology i have been able to convert 37 lines (so far) of scripting into 6 BLPackage objects. I could have made it into 4 if i had included the nohup.out file and the /opt/jboss/server/default/log into the initial jboss file structure i created in step 2.
Now the BLPackage is perfectly readable for anyone who has basic knowledge of BSA no matter if he or she is a Unix expert or not. Also we have perfect visibility on what will happen to the server when we deploy this package. Only native BSA objects are used, so automatically we have the ability to roll-back the deployment if needed.
So yes, we can leverage existing scripts in BSA, but think about the advantages of using native BSA technology.