Now lets quickly define our objectives.

1. Remotely manage ( Start/Stop ) the JBoss server with the help of a custom SystemD initialization script which is in turn called using Ansible remotely.
2. Deploy a war file on JBoss application server which is placed at a remote machine.
3. Undeploy a war file on JBoss server remotely.

As explained in our previous article, we can define static variables and defaults inside roles/webserver/defaults/main.yml file. So lets define our defaults variables. place these in the specified file(on ansible server machine) :

name : test

Username: DBuser

Password: DBPass

driver : <drivername>

connection_url : <connection_url>

pool_name: <pool_name>

JNDI_HOME: <jndi_home>

filter : “<user-name>{ { Username} }</user-name>”

deployname: warfile.war

deploy_path: /path/to/deployment/scanner/path

DeploySrcTemp: /remotepath/to/deployment

Now lets create a systemd service to control Jboss service. let us name it as   JbossControl.service with the following content.for tutorial on systemD refer my previous article :

[unit]

Description= Jboss Application server control script

After = network.target

[Service]

Type=idle

ExecStart=/path/to/jboss/bin/standalone.sh

ExecStop=/path/to/jboss/bin/jboss-cli.sh –connect command=:shutdown

TimeoutStartSec=400

TimeoutStopSec=400

[install]

WantedBy=multi-user.target

save the file on remote machine and move it to roles/webserver/templates/ JbossControl.service.

Now we have required resources which are required for managing a Jboss app server remotely.

Now on our ansible server machine, we can update our roles/webserver/tasks/main.yml file with following content.

 —

 – name: copy jboss service file to systemd folder

   copy:

     src : “/path/to/ansible/roles/server/templates/JbossControl.service”

    dest: /etc/systemd/system/jbossControl.service

tags: [copyService]

 – name: start JBoss service

     systemd:

          state: started

          name: jbossControl

    tags: [StartJboss]

 – name: stop JBoss service

     systemd:

          state: stopped

          name: jbossControl

    tags: [StopJboss]

As we see in the tasks file, we have  used systemd module of ansible to invoke systemd services and targets . We have also utilized copy module to copy files from one location to another on remote system .now we can create a play.yml in the project root directory. with the following content:

 -hosts : RemoteMachines

  sudo : yes

  roles:

   – webserver 

now we can invoke this playbook to start jboss/stop jboss on remote machine as follows :

to start Jboss application server on remote machines defined in RemoteMachines file :

> ansible-playbook play.yml –tags “copyService,StartJboss”

to stop Jboss application server on remote machines defined in RemoteMachines file :

> ansible-playbook play.yml –tags “StopJboss”

here , tags attribute while calling the playbook helps us to specify which services to run from the role. if we do not specify the tags, every task on the specified role runs and returns the result.

We have successfully completed the first objective of managing the remote JBoss application server! In the next tutorial we will see how to deploy and un deploy the war file remotely which also in turn involves managing data sources and config files. Stay Tuned !

The post Introduction to Ansible Part 3 appeared first on .

Now before we dive  into the structure, Ansible uses YAML syntax inside its file called playbook(playbook means simply a file with set of tasks bundled together)  . If you are not comfortable with YAML syntax or if you want to skim it through please refer Ansible documentation. They have the best explanation out there. http://docs.ansible.com/ansible/latest/reference_appendices/YAMLSyntax.html

now lets create our first basic ansible playbook.

Create a file named test.yml inside project folder,And paste this content.

—

– hosts: remoteMachines
   tasks:
      – shell: echo “Hi!”

Save the file . Before running this append this line to the host under remoteMachines in the hosts file we created in the previous tutorial.

like this ,

192.168.1.112 ansible_user=sshuser1

192.168.1.113 ansible_user=sshuser2

This line specifies this user is used to SSH into the remote Host.(by default it takes the current user of the ansible server machine)

and to run the playbook we just created , use the following command :

> ansible-playbook  test.yml

this should return “Hi!” from both the remote machine output. And in the playbook we just created, hosts specifies the hosts we want to run the tasks on. It has a single task which uses the shell module to run echo “Hi!” command.

Now lets assume a scenario in which we have many common tasks to be run on multiple playbooks. To address such scenario , we will follow a specific structure and in order to reuse tasks spread across multiple playbooks, we will use a feature called “roles”.

Inside the project folder create a folder called as “roles”. Inside roles directory we will create another folder this folder is the name of role we want to use.(ex: webserver).

Inside webserver folder we will create these folders and files respectively. hierarchy as follows,
Roles > Webserver > defaults > main.yml

Roles > Webserver > tasks > main.yml

Roles > Webserver > handlers > main.yml

Roles > Webserver > templates 

Inside defaults folder ,we will find variables and default values in format of “name:value” pair inside main.yml file, these are extensively used in playbooks , templates and are placed to increase re usability.

Inside tasks folder , we will find set of tasks associated to the role inside main.yml file .

Inside handlers folder, we will find different handlers associated with the tasks. Handlers are similar to tasks . only difference is handlers are invoked only by another task.

Inside templates folder, we will find templates , which contains changing  values inside configuration files and these can be replaced by values inside defaults folder. They are processed by Jinja 2  template language.

Now in order to run this role, create a file named play.yml file inside project root folder. and place the following content and save

 – hosts: remoteMachines
roles:
– webserver

As we can see there is a granularity of different type of functionalities and reusability of tasks can be achieved by the concept of roles.

In the next tutorial , we will look at how to use this hierarchy to write a functional role and execute this playbook. Thank you!

The post Introduction to Ansible : Part 2 appeared first on .

In this article we will look at basics of Ansible and we will cover some more extensive features in later tutorials.

What is Ansible?

Ansible is an Infrastructure Automation Tool , widely used for automating day to day management of remote server tasks.

Why Ansible?

Management of multiple  Linux remote Hosts using SSH, in parallel.

Also supports Windows environment using powershell

Easy to use and works out of the box, no overhead of installing extra tools on slave machines . (relies on SSH for controlling)

Uses concept of states in which comparision of current state and the desired state of the task at hand is made, if the condition satisfies , task returns the existing state without running the task .

You can read more about Ansible  : https://www.ansible.com

Main goal of this tutorial : have a centralized server with ansible installed to control remote(slave) machines to run or accomplish a specific task.

Lets Now setup ansible on Server machine.

How To install Ansible ?

You can install Ansible as a python pip package.

> pip install ansible

Once done, create a test project folder and inside it lets create an inventory file named “hosts” . This file is mainly used to define various groups of machine we would like to remotely manage.(use your favourite text editor and save this as content)

content of hosts file :

[myMachine]

127.0.0.1

[remoteMachines]

192.168.1.112

192.168.1.113

As we can see , there are two groups with labels myMachine and remoteMachines to administer different set of machines. myMachine would control my local machine ,whereas the remoteMachines would control other machines in the network.

Note : As a prerequisite the server machine should be configured to auto SSH  to slave machines. ( to avoid specifying parameters on runtime)

now lets run a simple task against myMachine (that is localhost)

> ansible -i hosts   myMachine –connection=local  -m ping

here we can see , -i parameter specifies the inventory file name , in this case its “hosts” . myMachine specifies the group label of the machines for which task has to run. here machines under that label will run the task. “–connection=local” which specifies run the command on localhost (not to use SSH). -m arg specifies the module to be used. Here we are using Ping module.(we will see more in upcoming tutorials)

typical response should be,

127.0.0.1 | success >> {
“changed”: false,
“ping”: “pong”
}

If you have successfully completed this , congratulations! you have run your first ansible task. In upcoming tutorials, we will look at more granular ways of running tasks using concept of roles.

The post Introduction to Ansible : Part 1 appeared first on .