Ansible Deployment Type
rejected
F
Future Shrimp
Ansible is basically Helm for non-cloud VMs: it uses YAML templates to describe deployment goals (in terms of files and processes instead of resources and pods). You can use the same solutions for configuration file management as for K8s, and greatly increase quality of support for traditional deployments. Basically give Harness the major capabilities of Ansible Tower/Redhat Ansible Automation Platform.
Log In
Canny AI
Merged in a post:
Native support of Ansible in Harness
N
Novel Cod
There is already an ansible feature request which was rejected. I am resubmitting with additional bullets for your reconsideration. I do not work for the same organization as the original requestor so pls consider this as coming from a different Org.
I can personally attest to the fact that, if I had ansible step, it would be much easier for me to convince a lot of Jenkins users to move their deployments and provisioning tasks to Harness.
The thing with Ansible is, it is still a very popular provisioning and configuration management tool. Terraform is great, but a lot of users are not big fans of terraform due to the fact that it maintains a state whereas ansible dont. So it is easy to provision something with Ansible than terraform.
TF is great if you are a greenfield deployment. But not easy if you already have an installed base and you want to start using TF to manage resources already provisioned by other means.
We in devops provision Azure resources using Ansible (not TF). Because of the same above reason.
Can we do Ansible in Harness? - Sure you can using shell script step as you described.
Can we do terraform with shell script step - Sure you can. However you have a native TF step. Because it gives the convenience of using the native capabilities of harness on terraform .
I will try to bullet out some of the inconvenience factors of using shell script step to call ansible:
1) if there was an ansible step , the playbook becomes available to use in Harness step directly inline or stored in git. If using shell script step you have to copy the playbook to a VM either via shell or via with the copy step and then run a playbook on it.
You cant use the copy step to copy ansible playbooks to the delegate because delegate dont run ssh service.
So either you have to have a VM set aside for running playbooks or you have to figure out ways to copy ansible playbooks to delegate.
2) ansible variables. If using shell script step, there is no first class support of ansible variables. Whereas in TF step, TF variables are first class citizens in Harness.
3)Failure and failure action logic. Difficult to manage if using shell script logic whereas if ansible step was native in harness, the failure and failure action logic would be just like any other step
4)Ansible return data which carries ton of information on the provisioned resource and the status. With shell script step wrapping ansible, very difficult to make this return data available for further processing in pipeline
5)Exit status and output variables. Shell script step doesn't create an output variable if script exit without completion. So if I have an ansible playbook which exit due to some issue, shell script step will not attach an output variable. I can workaround it by doing a set +e in script. But then the step is marked as success all the time which means the failure and failure logic would not work.
In my opinion,
a) can we do ansible by wrapping a shell script around it?
Possibly yes but it is a difficult journey.
b) Is shell script for ansible the best way to do it - Absolutely not.
c) If a devops guy who have worked with Ansible for past 10 yrs would like the idea of a native Ansible step in Harness - Absolutely.
Shell script step in my pov should be a last resort way to get something done. if something is so common and frequently used in customer base, then there is a great advantage in giving first class support of it in the tool.
Canny AI
Merged in a post:
Native Ansible Support in IACM
M
Maroon Hummingbird
Support for Ansible executions native in Harness IACM so we can centrally execute Ansible and Terraform securely in a single place and sunset Ansible tower.
L
Lively Aardvark
Allowing for centralized, secure execution of both IaC and CaC in a unified platform would provide us a substantial competitive edge.
Rohan Gupta
rejected
We do not plan to support Ansible as a Deployment Type. Our users leverage the shell script provisioner which is designed to orchestrate things like Ansible. https://developer.harness.io/docs/continuous-delivery/cd-infrastructure/shell-script-provisioning/
We also have customers using Custom Deployments to perform this job as well.
F
Future Shrimp
Rohan Gupta: Exactly! you already have user who do Ansible deployments, but who are having to use the catch-all options, so it would be awesome if Harness can also manage Ansible yaml files the way it manages K8s yaml files, i.e. doing the template modifications for different environments, services, and artifact versions. It would be easier for your customers AND lessen technical requirements on the ssh script execution backend (because there are definitely some deficiencies there; just check my team's other requests!).
N
Novel Cod
Rohan Gupta: I would kindly request to reconsider this request.
I can personally attest to the fact that, if I had ansible step, it would be much easier for me to convince a lot of Jenkins users to move their deployments and provisioning tasks to Harness.
The thing with Ansible is, it is still a very popular provisioning and configuration management tool. Terraform is great, but a lot of users are not big fans of terraform due to the fact that it maintains a state whereas ansible dont. So it is easy to provision something with Ansible than terraform.
TF is great if you are a greenfield deployment. But not easy if you already have an installed base and you want to start using TF to manage resources already provisioned by other means.
We in devops provision Azure resources using Ansible (not TF). Because of the same above reason.
Can we do Ansible in Harness? - Sure you can using shell script step as you described.
Can we do terraform with shell script step - Sure you can. However you have a native TF step. Because it gives the convenience of using the native capabilities of harness on terraform .
I will try to bullet out some of the inconvenience factors of using shell script step to call ansible:
1) if there was an ansible step , the playbook becomes available to use in Harness step directly inline or stored in git. If using shell script step you have to copy the playbook to a VM either via shell or via with the copy step and then run a playbook on it.
You cant use the copy step to copy ansible playbooks to the delegate because delegate dont run ssh service.
So either you have to have a VM set aside for running playbooks or you have to figure out ways to copy ansible playbooks to delegate.
2) ansible variables. If using shell script step, there is no first class support of ansible variables. Whereas in TF step, TF variables are first class citizens in Harness.
3)Failure and failure action logic. Difficult to manage if using shell script logic whereas if ansible step was native in harness, the failure and failure action logic would be just like any other step
4)Ansible return data which carries ton of information on the provisioned resource and the status. With shell script step wrapping ansible, very difficult to make this return data available for further processing in pipeline
5)Exit status and output variables. Shell script step doesn't create an output variable if script exit without completion. So if I have an ansible playbook which exit due to some issue, shell script step will not attach an output variable. I can workaround it by doing a set +e in script. But then the step is marked as success all the time which means the failure and failure logic would not work.
In my opinion,
a) can we do ansible by wrapping a shell script around it?
Possibly yes but it is a difficult journey.
b) Is shell script for ansible the best way to do it - Absolutely not.
c) If a devops guy who have worked with Ansible for past 10 yrs would like the idea of a native Ansible step in Harness - Absolutely.
Shell script step in my pov should be a last resort way to get something done. if something is so common and frequently used in customer base, then there is a great advantage in giving first class support of it in the tool.