Recently, in our company, we decided to use Ansible for deployment and continuous integration. But when I started using Ansible I didn't find modules for building Java projects with Maven, or modules for running JUnit tests, or JMeter tests.
So, I'm in a doubtful state: it may be I'm using Ansible in a wrong way.
When I looked at Jenkins, it can do things like build, run tests, deploy. The missing thing in Hudson is creating/deleting an instance in cloud environments like AWS.
So, in general, for what purposes do we need to use Ansible/Jenkins? For CI do I need to use a combination of Ansible and Jenkins?
Please throw some light on correct usage of Ansible.
First, Jenkins and Hudson are basically the same project. I'll refer to it as Jenkins below. See How to choose between Hudson and Jenkins?, Hudson vs Jenkins in 2012, and What is the most notable difference between Jenkins and Hudson from a user perpective? for more.
Second, Ansible isn't meant to be a continuous integration engine. It (generally) doesn't poll git repos and run builds that fail in a sane way.
When can I simply use Jenkins?
If your machine environment and deployment process is very straightforward (such as Heroku or iron that is configured outside of your team), Jenkins may be enough. You can write a custom script that does a deploy as the final build step (or a chained step).
When can I simply use Ansible?
If you only need to "deploy" without needing to build/test, Ansible might be enough. For instance, you can run a deploy from the commandline or using Ansible Tower. This is great for small projects, static sites, etc.
How do they work together?
A good combination is to use Jenkins to build, test, and save artifacts. Add a step to call Ansible or Ansible Tower to handle the actual deployment process. That allows Ansible to handle machine configuration and lets Jenkins handle the CI process.
What are the alternatives to Jenkins?
I strongly recommend Thoughtworks Go (not to be confused with Go the language) instead of Jenkins. Others include CruiseControl, TravisCI, and Integrity.
Ansible is just a "glorified SSH loop".
CI is not only the software running, but the whole process of how success and failure is handled, who gets notification, and how the change is merged into the target version control.
If we only focus on the software, CI is a reactive scheduler triggered by code changes, and triggering typical build-validate-release-deploy sequence of "steps".
So in respect of software, Ansible without additional "sugaring" is just a toolkit to run things, which can be those very steps, but it is not CI.
The Ansible (without tower) totally lacks this reactive nature.
If you want to marry Ansible with CI, you can.
Ansible tower is a very Ansible oriented scheduler, but if you need CI software, I think you not necessarily need it. Any CI app capable of running shell script would be capable to launch Ansible playbooks.
Yet unlike Ansible tower - CI tools know to display test reports of all test frameworks, trigger notifications, etc.
Ansible tower can make sense in a complex environment with lots of groups touching Ansible code... The truth is I haven't seen a single real reason to pay for it. But if a manager liked the web interface nothing can stand "but others use it" logic.
I suspect the concept of Ansible tower was in response to puppet enterprise.
:)
Related
As part of QA pipeline(in Jenkins), goal is to automate provisioning and configuration of a VM to run the QA tests.
Jenkins pipeline can trigger Terraform code to automate provisioning of VM and ansible code for configuration of a VM, but, issues like rollback, error handling is not easy unless we use some vendor specific template like AzureResourceManager template.
So, with Jenkins pipeline,What should be the best approach to provision and configure a VM in Azure cloud? we write pipeline scripts for jenkins pipeline...
As the goal is to know the best approach to automate provisioning and configuration of a VM to run the QA tests so I would go with simple jenkins pipeline script by leveraging Azure CLI commands in it.
To be precise, I would just add an Azure service principal to Jenkins credential. And then write simple Jenkins pipeline script by having 'withCredentials([azureServicePrincipal('SERVICEPRINCIPALCREDENTIALID')])' and then by using 'sh' part to have Azure CLI command to provision and configure VM. For illustration related to this you may refer https://learn.microsoft.com/en-us/azure/jenkins/execute-cli-jenkins-pipeline#add-azure-service-principal-to-jenkins-credential.
Regarding the issues like rollback and error handling when going with the approach of having Jenkins pipeline that triggers Ansible code (with or without using ARM templates) that can automate provisioning and configuration of a VM to run the QA tests, (you might already be aware of this but wanted to let you know that) for certain types of tasks you may write custom modules that can leverage the error handling functionality and in few scenarios you may leverage 'failed_when' option. Also you may leverage 'blocks' functionality by which you can define a set of tasks to be executed in the rescue: section. This 'blocks' functionality specially should help in enabling us to get the things rolled back.
Hope this helps!! :)
I wanted to build a Jenkins server which would run test of my puppet code on Vagrant. The issue I found is that the we run our server as VMs already, either in vmWare or AWS and Vagrant will not work as another virtualisation.
Does anyone have an idea how can I create a test platform for my puppet code. What I want to test the deployment of manifest on the nodes them self i.e. If I deploy a class web server or make changes to it I would like to check if it affects/breaks deployment of other classes.
The idea would be to iterate over all the classes/roles and see if the deployments are passing. I would like to make it automatic and independent of our engineers. At the moment we are running manual test with vagrant up however there are too many roles to do that by hand.
Any ideas how can I tackle this?
You can use either Docker or AWS provider for Vagrant.
In case of AWS provider you need to set-up RSync to get your environment into newly launched instance.
If your Vagrant scripts are robust, you can use the same script for both local deployment on your workstation and AWS/Docker deployment on CI server.
There are drawbacks to doing these techniques, in case of Docker you are limited to the same kernel that Jenkins server is running, in case of AWS you will incur additional costs. However, for AWS your don't need to allocate as much resources for your Jenkins server, so you might even save money this way because you will be using paying for extra VMs only when you are running you tests. Just make sure you will shut them down after you done.
Is there any special reason why you want to use vagrant? I'm not sure if you are setting up your production environment with vagrant or not.
In case you are not bound to vagrant, I would recommend you to think about using a docker image to prepare a lightweight environment to run your setups and verifications in.
When doing your tests, spin up a container from your image that contains your puppet distribution and run your setups/tests inside. If you have special kernel requirements, use a separate jenkins slave/agent machine rather than executing jobs on the jenkins master.
If you are not sure how to get started using jenkins with docker, have a look into the examples section of the Jenkins Documentation. The provided examples are showing the declarative pipeline syntax thats still a bit new. Also consider the collapsed Toggle Scripted Pipeline Sections which show the groovy pipeline scripts that are alot more forgiving for jenkins pipeline beginners.
Those should be quite good pointers to get started with running+testing your puppet scripts inside docker. For building and using a docker image there should be more than enough tutorials out there.
Let me know if this was a hint in the right direction or if I mistinterpreted your question.
I feel it's a little crazy I couldn't find anything along these lines, especially as it's an incredibly simple requirement: Is there a way you can deploy from Jenkins using SSH/SCP, yet write only one instance of a transfer-set/exec script?
As it stands, deploying to servers is kind of INSANE in that I need to create a new "Deploy to SSH" task, choose a different server from the drop down and then copy/past all transfer-sets and execs from the previous entry. Then do it again. And again. And again.
There must be a better way?
This may not be a short-term immediate solution for your question---
(On long run this can be used)
Your requirement seems to me like you need a configuration management equipment. You could use Chef, Puppet or Ansible. And automation of this deployment can be done using Jenkins CI.
One example of how to deploy an application on jboss using Ansible -
Deploy a hello world application
jboss: src=/tmp/hello-1.0-SNAPSHOT.war deployment=hello.war state=present
Of course, this will require installation of Ansible and little bit of initial configuration. Ansible is simplest of all deployment mechanisms.
Check this for more details - http://docs.ansible.com/ansible/intro.html
My development setup is such that for every svn checkin code is built,unit tested, packaged and published in Artifactory. Now I want to automate my deployment process & run integration(Selenium) test as part of this process. I am thinking of using Puppet to managed the deployment
Is puppet the correct tool for this
What is the process I should use to trigger puppet master to initiate a fresh installation on agents, I couldn't find any Jenkins plugin that would actually trigger puppet. One option is to call
puppet apply ...
as a Jenkins post build task
Any suggestions welcome, thank you.
Have a look at this Selenium Jenkins article from Saucelabs, a service that automates cross-browser testing. Though they are a vendor with a service to sell, the article covers how to do Selenium testing yourself with Jenkins. It also exposes common pain points you are likely to run into with this approach.
A Puppet master doesn't serve the function of orchestrating client convergences. Take a look at Mcollective. This is a tool that will allow you to trigger puppet runs on target systems from a Jenkins agent via script commands.
Some Mcollective getting started material:
http://www.slideshare.net/PuppetLabs/presentation-16281121
http://puppetlabs.com/mcollective
I'm running Jenkins on one server and want to use chef and automatically install a snapshot (including runtime artifacts etc) on a separate server.
Currently Jenkins will use ssh to invoke chef on the seperate machine. Is there a better way?
Maven is also involved in this.
I've found that majority of "Deploy" type plugins are lacking in customization. We use "Execute" (bash or batch) build steps to trigger deployment scripts on remote machines (written in house, be they Puppet, Chef, or plain bash/batch).
The correlation between builds and deployments is achieved through "Promotions" and explained in detail here:
How to promote a specific build number from another job in Jenkins?