Welcome back to our “How to Install and configure Jenkins on CentOS 6.4” series. In this series of articles I am trying to make an user understand about the usage of Jenkins step by step. Don’t forgot to add comments if you found any error or mistakes in the articles. Also please mention if you have any better idea to make these task easier.
In the earlier part of the “How to Install and configure Jenkins on CentOS 6.4” we discussed about how to install Jenkins server, how to configure it, how to add nodes to our Jenkins server, how to deploy a GIT repository using Jenkins. In our Part -III we saw that, the application is available in the defined workspace folder of the node after deploying the application from GIT using git plugin. But sometimes it requires to deploy the application to a particular location. For an example if you have an existing PHP application running behind Apache web server. The root directory of the application is /var/www/html/www.linuxfunda.com then, what to do ?? Well don’t worry it can be possible. Jenkins allows us to execute shell script while executing the Job. So we can write a shell script to do all the required stuffs for us instead of using any plugin. In this article we will discuss about how to build or deploy a application using Jenkins and shell script.
- A machine (CentOS 6.4) which should have Jenkins Server installed. If you don’t have the Jenkins server then follow the article Part-I to install Jenkins.
- A machine with LAMP setup where we will deploy the application using Jenkins. It will be a node of our Jenkins server.
In this article I will configure my job to update my web application named www.linuxfunda.com. Basically it is a PHP application running behind Apache web server. I have the source codes in Git and my requirements is to update the code in the web server and after updating the code restart the Apache web server.You can modify the script according to your requirements. Add your web server as a node on the Jenkins Server.
Two things to do in the node server before creating the job.
- Your Node should have Java installed. Java is required to run Jenkins. Refer the article “How to install Java” to install Java on the machine.
- Your Node should have access to the GIT repository. As we are using Shell script for the build, it will execute the commands on the Node. You need to create a RSA keypair in your node. Add the public key to your GIT repository as a deployment key.
Now we will create a job. Login to your Jenkins server and create a freestyle job.
After clicking on the OK button, the job Jenkins will redirect you to the detail configuration page of the Job. We need to specify that on which node the job is going to be executed. So, check the option “Restrict where this project can be run” and enter the Node name.
Click on the “Add build step” drop-down from Build section. Click on “Execute shell”. You will find a text box after selecting the “Execute Shell” option.
We are at the final step of the configuration of the Job. Just we need to write down a script to update the local GIT repository on the web server and restart the Apache. I don’t think the script will more than two to three lines.
#Go to the root directory of the application
#Issue the Git command to update the local repository
#Restart the Apache web server after updating the codes. I usually reload the Apache instead restart.
service httpd reload
Now our Job configuration page should look like the below image after writing the script. Finally we need to save the Job. Save it and execute the Job. Verify on your web server and you should able to find the latest updated from your GIT after executing the job.
Sometimes we have multiple application severs for one web application. In my next article I will show you how to create a job to update multiple application servers. Please don’t forget to add your valuable comments.
Latest posts by Tapas Mishra (see all)
- Working with Docker – II - December 16, 2016
- Working with Docker – I - November 28, 2016
- How to work with Chef using Oracle VirtualBox and Vagrant on a Windows host – Part II - November 30, 2014