2

I am new to Ansible and was wondering about the capabilities of Ansible. Can Ansible alone be a complete CI-CD tool?

Scenario that needs to be implemented:

As soon as a developer perform a git commit, the build should be generated and placed some central server or maybe Amazon S3. This is a JAR file assuming a Java application. One can then download the build and deploy that build to the testing environment and after deployment invoke the automated test cases. Upon successful implementation of the test cases,one should be able to deploy this build onto the production environment in a rolling fashion. Note that one must not deploy this build every time, but it should be a discretionary power. I.e. even if during a day let us say, 5 builds were created and 3 of them passed the test cases, It should not go and deploy the builds on production. I should decide when to deploy the build, this could be a flag that I set to "Go" and then the deployment to production should take place.

Points that I am apprehensive about Ansible's capability are:

  1. Will ansible be able to detect the git commit event. Is there a way my playbook to constantly poll the GIT server on a regular basis to detect any commits?

  2. Is it possible to create Build using just Ansible. (Can I use command module to just execute the build creation process(assuming there is some command to create the build and I was thinking of firing those command using the command module, maybe maven or ant command).

    Kindly forgive me for my ignorance if there is no such thing. I have never done development and hence am complete beginner.

  3. How can I invoke automated test cases on the testing environment where the build was deployed (I am assuming a successful deploy on the stage environment).

  4. Can I capture the success or failure result? (It maybe be a suite of test cases and won't be an objective o/p as pass or fail.)

  5. Is there a way to achieve the discretion based deployment to production systems using Ansible?

Note that I don't want to use Jenkins or any such tools for creation of builds or deployment to test environments .

This may sound like a beginner question on DevOps, but I just wanted to assess the scope of Ansible as a CI tool. Is Jenkins (or any other variant) inevitable for achieving this? Or can people do away without using Jenkins.

Also if someone can comment on what is the recommended way to achieve this pipeline.

  • 3
    You probably can reinvent the wheel of CI with Ansible, that doesn't mean you should. As well as you can travel oversea on a piece of wood but I really wouldn't recommend it... Why do you want to avoid using tools for what they are made ? A CI tool for build/unit test and a configuration management tool for setup/deploy sounds reasonable and you don't give any reason to why you throw this option before starting to evaluate it. – Tensibai Jan 31 '18 at 16:47
  • Scaling jenkins is just awful. The more plugins you add the more likely your whole jenkins will fail to work. Even adding lots of jobs with a small stable set of plugins will eventually become so arduous that you start looking for some other way to do it. The build hosts are special snowflake artifacts that have to be rebuild by hand. So when your wheel looks like it was invented by people that only work in squares it might be a good time to reinvent it. – chicks Jan 31 '18 at 17:07
  • No, At a minmum, based on this scenario, you will at least need git ;) and probably a git hook. Ansible doesn't need to detect the event, git can trigger Ansible with the hook. – James Shewey Jan 31 '18 at 20:31
4

This is totally possible. Of course you can achieve it without jenkins or similar tools being required. We're always free to reinvent the wheel. The question becomes is it worth the effort? When it helps you avoid jenkins I'd be inclined to put the effort in. (I'd also suggest looking at Concourse before doing jenkins again, but that's not what this question is about...)

For your case you need two things:

  1. a playbook that automates your build using ansible.
  2. a git hook to invoke your ansible playbook, probably post-commit.

If you are using gitlab or github you should look at their specific documentation for creating hooks, but otherwise the generic help I linked to should do it.

To answer your specific questions:

  1. Yes, use the git hook.

  2. Sure. You probably want ansible to do a fresh git checkout first. Eventually you will want to add any prerequisites to be verified too.

  3. You don't have to assume anything, just add these steps to the end of your playbook. If the build fails, it will stop before wasting effort on testing anything. You could split build, deploy, and validate into their own roles within one larger playbook. This will help make each of the sets of tasks easier to manage and you could call them manually if needed for debugging or emergencies.

  4. You could do this in a myriad of ways. I'd create a text file with a date/time stamp and the results inside. You could write it to a database or K/V store.

  5. I'm not sure what you mean.

4

Frankly, if you go this route, you do not even need Ansible as a CI/CD driver. Ansible does not bring any infrastructure anyways, it just uses an existing ssh connection, so you can just use said ssh connection directly with your own scripts.

If the ultimate goal is to avoid any of the established solutions (Jenkins, Gitlab CI, whatever), then nothing really keeps you from rolling your own:

  • Create some scripts "prepare.sh", "build.sh", "test.sh", "deploy.sh" etc. which do their thing. "prepare.sh" would maybe use Ansible itself to setup a working environment somewhere, do the clone etc.
  • Either in a git hook on the server side, or if you cannot install it there, in some permanently running (or cron-started) master script which polls the git repository regularly, implement a detector which looks for new commits and then executes the other scripts in order, until one of them fails or you are done.
  • If you need nothing fancy regarding reporting etc., then just redirect the output of all those scripts to some logfile, or log files tagged with the current time.
  • It's easy to send a quick mail to the devs when the build or test goes wrong, if you are so inclined.

All in all, this would probably not be that much more effort than using Jenkins - with Jenkins, you'd write the content of your scripts somewhere in the job definition, anyways.

Obviously, you do not get all the fluff that Jenkins or other solutions give you - statistics, reports, GUI, load-balancing the worker nodes etc., but as long as you do not need those, why not.

  • I think you mean "ultimate" (final) rather than "penultimate" (second-to-last). – Monty Harder Jan 31 '18 at 20:52
  • Actually, "penultimate" goal made sense, since obviously the ultimate goal is the automatic deployment of some app. – kubanczyk Jan 31 '18 at 22:13
  • You're killing me, guys. :D – AnoE Jan 31 '18 at 22:28
  • @kubanczyk Or, is the ultimate goal that the app be quickly deployed in a reliably-repeatable fashion, so that automatic deployment is penultimate, and avoiding established solutions becomes antepenultimate? – Monty Harder Feb 1 '18 at 18:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.