Share: |


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>

 

;install JBoss

2. groupadd www

3. useradd -g www -d /opt/jboss jboss

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

 

<snip>

 

;add permissions to logs

32. mkdir /opt/jboss/logs

33. cd /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/

 

<snip>

 

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.

user.jpg
group.jpg

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.

dir.jpg

7-10: To manage configuration files we can create a Configuration File object in BSA's Configuration Object Dictionary.

cod.jpg

After creating this Configuration File in the Configuration Object Dictionary we can access and package any configuration parameter in this configuration file as an individual object.
conf file.jpg

cfinblp.jpg

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.

fd.jpg

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.

nohup.jpg

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.

fullpack.jpg

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.