Rundeck example job definition

The below is a rundeck example job definition that uses options inside a script.

<joblist>
  <job>
    <id>3f6b1581-9b1d-4477-9980-627a95c0d676</id>
    <loglevel>INFO</loglevel>
    <sequence keepgoing='false' strategy='node-first'>
      <command>
        <scriptargs>${option.args_1}</scriptargs>
        <script><![CDATA[#Inline.sh
#!/bin/bash
echo "got this from the Job: @option.args_1@"
cat /dev/null >/tmp/${HOSTNAME}_rd_tst
echo "#inserting value from the RD job" >>/tmp/${HOSTNAME}_rd_tst
if [ "x${1}" = "x" ]
then
    echo "testid=100" >>/tmp/${HOSTNAME}_rd_tst
else
    echo "testid=${1}" >>/tmp/${HOSTNAME}_rd_tst
fi
echo "executed on ${HOSTNAME} at `date`"
echo "done"]]></script>
      </command>
    </sequence>
    <description>This job will create a file named ${HOSTNAME}_rd_tst on a remote node on temp folder and put in a key and default value of testid=100.</description>
    <name>Simple_file_key_value</name>
    <context>
      <project>Test_remote</project>
      <options>
        <option name='args_1' value='100' required='true' />
      </options>
    </context>
    <dispatch>
      <threadcount>1</threadcount>
      <keepgoing>false</keepgoing>
      <excludePrecedence>false</excludePrecedence>
      <rankOrder>ascending</rankOrder>
    </dispatch>
    <uuid>3f6b1581-9b1d-4477-9980-627a95c0d676</uuid>
    <nodefilters>
      <filter>beren.*</filter>
    </nodefilters>
  </job>
</joblist>

Rundeck API small script

This is a demo script for using Rundeck and its API.

Rundeck API is a cumulative work that has api numbers from 1 to 12 up to now.
It will allow you to list and execute rundeck jobs remotely and also to monitor them remotely.
This will be very useful also for rundeck scripts that would call another remote rundeck jobs, this can be a good work around for remote execution when SSH is not allowed for security reasons.
Also would server to put your entire Ops jobs and infra under control using a simple web application.

The applications for this is limitless.
link this with my earlier post for nodeJS shell execution and u will have a lot of options to automation.

Below is a small example:

PROJECTS=`curl -H "Accept: application/json" http://beren:4440/api/1/projects?authtoken=It4kb1tIgw8gBpKI3rQhscKTp0OVYSNo |tr "}" "\n"|tr "," "\n"|grep name|cut -d":" -f2 |tr -d "\""`

#echo $PROJECTS
for proj in $PROJECTS
do
        #get all Jobs in all projects:
        echo "Project: $proj"
        curl "http://beren:4440/api/1/jobs?authtoken=It4kb1tIgw8gBpKI3rQhscKTp0OVYSNo&project=${proj}" #egrep "\<name>|\<job id="
done

To Run your job directly use a URL similar to below:

curl "http://beren:4440/api/1/job/61894b63-d687-4a39-a583-e0eba070339f/run?authtoken=It4kb1tIgw8gBpKI3rQhscKTp0OVYSNo"

Systemd vs SysV Linux services

Check the below commands for systemd new config:

[root@localhost systemd]# systemctl disable firewalld.service
rm '/etc/systemd/system/basic.target.wants/firewalld.service'
rm '/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service'
[root@localhost systemd]#

[root@localhost systemd]# systemctl enable firewalld.service
ln -s '/usr/lib/systemd/system/firewalld.service' '/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service'
ln -s '/usr/lib/systemd/system/firewalld.service' '/etc/systemd/system/basic.target.wants/firewalld.service'
[root@localhost systemd]#


[root@localhost systemd]# systemctl stop firewalld.service
[root@localhost systemd]#

[root@localhost systemd]# systemctl disable firewalld.service
rm '/etc/systemd/system/basic.target.wants/firewalld.service'
rm '/etc/systemd/system/dbus-org.fedoraproject.FirewallD1.service'
[root@localhost systemd]#

[root@localhost systemd]#  systemctl list-unit-files -t service ^C

of F5 BigIP and Session stickiness

F5 BigIP is well know for its robustness and superior performance in the the Loadbalancer business.

I was exposed to using it in a architecture similar to the one described below:
http://www.f5.com/pdf/deployment-guides/tomcat-dg.pdf

Actually, F5 would better serve as SSL offloading step and will mask the underlying Apache and Tomcat instances.

Two things needs to be considers:
1- Since we have 2 LB VIPs, each of them should maintain a separated cookie for session stickiness. this is to avoid one overwriting another.
2- If your app contains a lot of Ajax and asyncronous calls, OneConnect needs to be enabled on the Tomcat LB, so that the session stickiness decision is processed correctly for each request. this is becasue BigIP does the load balancing on the TCP connection rather than request basis.