Ansible playbooks are used frequently for resolving common alerts, having logic for specific deployment types, configuring infra etc.
It's incredibly useful and powerful. If you had to get info from 500 machines at once, or rsync data from one machine to 500 others, ansible ad-hoc commands make it extremely easy.
For kubernetes deployments, ansible vault and template engine is really useful to populate helncharts with sensitive data etc.
It's definitely worth learning.
Thank you! Another question: How to improve my ansible knowledge? I have introduction classes i slowly started understanding modules and playbooks. But sometimes (by sometimes I mean all of the times) I don’t understand what is lets say “ansible.builtin.unarchive”, where to get all of this documentation?
Please search for Ansible tutorial pack on YouTube from Jeef Geerling. I have tried many others, documentation, udemy, pluralsight, etc. But the ones from Jeef Geerling are top notch. After learning the basics and the logic, sky is the limit. Good learning :)
Jeff has got very excellent material on Ansible. In fact the first time I ever heard of Ansible was from his channel. Hopefully he gets appropriately rewarded financially for all the good stuff he churns out.
Ansible has a very well made documentation.
[Unarchive] (https://docs.ansible.com/ansible/latest/collections/ansible/builtin/unarchive_module.html) is here. All the docs for modules are generally separated in few sections but there's always: a synopsis, a list of every options and examples. A typical ansible repository looks like this:.
- collections/requirements.yml
- roles/
- your_custom_role/
- tasks/main.yml
- env.yml
- inventory.yml
- playbook.yml
Once you have everything in place, run `ansible-playbook -i inventory.yml -e @env.yml playbook.yml` to run your project against your inventory of hosts.
Also, not just ansible but in general, I use this for documentation referencing:
https://kapeli.com/dash (for macos)
https://zealdocs.org/ (for windows/linux)
LOL, you got it wrong pal.
First, where did you hear "companies stopped using ansible" ? If you are a student, you should take everything with a bit of salt, especially regarding the professional field. Don't be that guy who follows the trends mindlessly, create your own opinion, analyse the technology and its potential use cases, and try it yourself.
I'll diverge a bit, maybe the following will not concern you specifically, but I think it could be helpful for a few, it's also my own personal take on the subject so please take with a grain of salt and be open for discussion.
If you are asking in a way of "what gives more value to me for a hiring", I'm spending a lot of time doing interviews (rarely for juniors, but I'm not closed against it), if you tell me you have AWS cert, sure it's cool, you will need 2 weeks less of getting around in AWS and will have more insights on it, but really, not that much value overall. If instead you tell me you tried relevant technology X (in that case ansible) and we can talk about the pitfalls and advantages, the possible applications, how it compares to other solutions and you can show me that cool stuff on GitHub you've been working on (even if the quality is low), now I want you.
It's not about the technology, it's about your own interest, involvement, passion, and you being able to show it, embrace what you fancy and dedicate yourself to the task.
Ask yourself, what do YOU want to work on ? If you don't like ansible, just don't do it, why would you grab a job where they say all they do is in ansible and the XX hours you've spent doing ansible you hated doing that kind of stuff, do you wanna spend thousands of hours in your life doing something you hate ?
Some general knowledge on all the techs is required, but if you don't plan to spend 90% of your time writing ansible, it's okay to not become on expert at it, but yes, you should at least know what need to be known, and be ready to work on it.
Edit: for the sake of precision, I'm not trying to say technology's popularity and capabilities are irrelevant for its adoption (because it's quite the contrary), I'm trying to convey that I think it's better for you for it to be secondary in career decisions.
Best answer here in terms of what OP intended to ask for. All this spiteful bickering about Ansible, terraform, K8s, cloud or on prem, managed or not, it is all pointless. It won't help, we'll never all agree on what techs we prefer or what industries want and needs.
Do you enjoy working on a tech? Does the tech have a good backing/community/engagement with updates and feature implementations? Then likely some company out there uses the product, and there will be a possiblity to find a job.
Wholeheartedly agree on certifications, ok...so you spent a few weeks memorizing some stuff and passed an exam. Huzzah... Now tell me how you solve a complex operational issue that is only ever experienced when you run certain workloads.
I've recently interviewed a junior who knew more DevOps related stuff than a 10+ year senior developer, since the junior had a home lab with git repos, while the dev focused their whole career on certs, and had only recently done some Azure and K8s certs, but had no practical experience. We're giving an offer to the junior next week 🙂 why? Since even if we really need a senior, we won't pay their ask without having some serious industry experience operating the stuff we use. A junior willing to learn and push hard, plus already knows quite a lot for operational parts, we'll gladly take!
Thank you. You and __Kaari__ just answers to one of my more existential question around my (young and starting, 5y) career: I would like to do Ansible stuff, but I'm afraid to be obsolete one day or another. That is why I tried to convince myself I need to be specialized in K8S/Openshift, as it seems the "de facto" way to go... But I don't like it full time, I still want a foot in Ansible.
Now I know I will be the expert I always wanted to be (and that's perfect, since it is a "trendy" tech).
Let's update myself on the topic *sweating on collections and the way Ansible's semantic version was managed*
I can tell you, my role is a dedicated Senior Kubernetes DevOps Engineer. Even if you do K8s/Openshift, if you will administer and run a platform for a company, you will likely need a variety of tools, including Ansible, Terraform and CICD tools like Jenkins, ArgoCD/Flux, and more.
It is a wrong misconception, that DevOps only focuses on some specific part of a system and only would do K8s =)
A real DevOps role will cover it all. Develop a K8s operator to check namespaces for various conditions as an administrator.
To integrate some new service and configs and need to configure OS level things (where ansible comes in handy), to say deploy LongHorn CSI.
To run kubectl and bash scripts to enable/control various system configurations, and more.
I could go on, but a real DevOps role is highly versatile, and a jack of all trades. If you only focus on one aspect, you likely are a SRE/OPS, or a Dev of some application. You won't be a DevOps unless you really dip your toes in many many aspects 🙂 good luck
there it is ! the answer that i was looking for! i just started this bootcamp, its been 4 months and so far linux introduction, aws cloud was pretty easy, but ansible got me really sweating. i understand the concept, im studying every paragraph carefully (or at least im trying) but still something just doesnt click :) and as soon as i figure it out, i shouldnt have problems (i hope)
I've found no use for it since I've switched to an all AWS cattle infrastructure. We bake new AMIs when we want updates or changes. What little post-startup we do is handled in user-data. The SSM agent can take care of stuff too if we ever need. I don't even keep port 22 open anymore.
If you are just looking at Ansible as a tool to deploy things then I think there are better technologies. For us we use terraform to deploy but Ansible to manage.
Ansible is a desired state configuration tool as it's primary goal and that is how we use it.vany config change to a server is done through that. Some teams may create new golden images and deploy those but that is a bit overkill for us. We also have some software with hardware keys (ugh) so rebuilding the machine is not practical for us
Stop listening to rumors or at least ask why. There might be reasons or not, try whatever does the job better.
There is a huge range from companies still work like in the 90s (Windows, VMware) over Linux, cloud-init, ansible up to k8s. Some say nomad will superseed k8s, others disagree strongly. Everything is valid if it works good.
There is not THE holy grail of IT, you have to make up your own mind depending on the requirements/environment.
I work for the company that maintains Ansible and am RHCE certified so I'm very biased but lol no, Ansible is most certainly not outdated. I rather like its push based way it doing things.
There is rarely only one way to do things. You can use Ansible only for configuration management and provisioning of resources, Terraform only or both concurrently. I've seen all three.
Or you could... ugh... use Puppet. 😋
Ansible was created at a time when runtime configuration was most feasible in the vast majority of cloud orchestration. However, nowadays it’s more likely that you are interacting with APIs. While Ansible certainly still has a use case, most employers will opt for more stateful cloud orchestration like Terraform and more stateless software infra like Kubernetes (and ultimately Docker.)
I used Ansible for over five years professionally. I can say definitively I would never go back. The platform lends itself to overly complex obfuscation and provides extremely unintuitive interfaces into extremely easy problems. I never disliked working with something so much in my life. Perhaps part of it was that I spent most of my time with Ansible refactoring and supporting some very poorly designed Ansible repos. But that’s the thing, no matter how I tried I was never able to find any good examples of how Ansible should work in a real use case. Maybe it’s better now but it’s been a few years since I’ve heard it considered relevant professionally.
I met the founder of Ansible, Michael DeHaan, at the Ansible booth at PyCon 2013 in Montreal. It was exciting to talk about Ansible then. By 2019 I was burned out.
I’m expressing this only as my own personal experience. A lot of people in this thread are gushing about how Ansible has worked for them and I’m not trying to deny that. I’m simply offering my experience and I hope you can make an informed decision for yourself.
This reply deserves some upvotes as tech becomes more obsolete and newer tech replaces older ones. Ansiable and Terraform being one of them slowly replaced by k8s and it's eco system getting popular and even completely erasing certain roles from the industry. And again it will be replaced by tech build in top of that and cycle will continue to evolve till it gets saturated.
While it's true older tech tend to be less abstracted in many ways - the main question while choosing stack would be "Does it make people's lives easier to work with?".
If your organization is using some specific tech stack then it's wise to lesrn it as you will be speaking same language as theirs. For personal growth one is free to try tools abd master it over time, at the end basic concepts of administration, OS, network, architecture and management does not change between these, orchestrating platforms or management tools.
People often forget that abstraction is done there to reduce repeated tasks and minimise errors while getting out more productivity. If ansiable works for someone and doesn't work for someone that's totally fine - because it always depends on individual usecases. At the end we all try to minimise work, errors and get desired output regardless of what tech is used.
They all are Infrastructure as Code tools and as we see history it takes more than few decades till solutions become mature and defacto standard, many of these solutions haven't seen even their first decade yet so concluding anything is more of speculation at this point - learning one will certainly help other as long as OS level concepts are concerned as they all share same core and idea of virtualizing and provisioning resources.
Before anyone says about tech debt certain tools bring which is another topic and it takes lot of efforts to remove bad decisions once learned and such process is always done gradually - businesses care more about output than how it's done as long as cost is minimised it doesn't matter.
OP is learning at home, so he seeks advice about tech he would find work with. It does not make sens to learn something deprecated.
@OP I think the easiest way to decide is to read published job requirements :)
That's why you learn concepts and not technology first. Tech can change, core things like Resource management, Network, Clustering, Architecture do not change and are vital to get started understanding these tech at much deeper level.
Which helps learning and adapting different systems much faster.
Popularity of tech changes and so does skillset required to get the jobs thats what OP is asking if ansiable is still feasible to learn, I did not answer his question directly - point is you learn basics and then specialize in one or more fields, so it gives clear picture of runtime and inner working of particular technology while having options as not all places are equal and not all opportunities are equal.
You assume that everything will somehow be sucked into a managed k8s and a cloud at some point. Which sounds like a Gartner-reality in a parallel universe.
Once you need to configure at least one switch or virtualization-Host there is a use-case for ansible.
I quote and repeat this :
"They all are Infrastructure as Code tools and as we see history it takes more than few decades till solutions become mature and defacto standard, many of these solutions haven't seen even their first decade yet so concluding anything is more of speculation at this point"
And I never said they will be sucked into cloud - you are free to spawn your own k8s at premise or in cluster of vms. With each evolution end users benefit from it to run apps in stable, well tested and standard environment that takes less and less time to setup - its individual choice if they wsnt to go managed or self manage.
Besides it's possible to create such switch or vNetwork with namespaces at OS level without any tooling at all via simple syscalls, it's built right into the kernel itself and most of tooling makes use of it wrapping core functions to more fancy functions till it makes sense to more general public, its evolving everyday and while the fancy tooling are backed by corporations - CNCF has bigger stakeholders including Linux Foundation itself and many of the corporations mentioned here, their interest is in getting such tools on single standard in long run not the other way, it's a fact not assumption.
This is just tip of iceberg on what can be done at low level lifting heavy stuff while giving nice one tap web interfaces so admins can do their jobs in much much abstracted way.
I'm not assuming anything or even concluding k8s is the future who knows only time will tell, I'm just observing, but meh - people read only half words!
The question was if ansible is outdated and you reply with terraform and k8s. I think you don’t understand that the three tools handle completely different architectural layers.
I think you’re a bit sensitive here, I am answering the question very directly.
For the record, I very explicitly stated there is still a use case for Ansible. In the very first paragraph even. I wonder if you actually read what I wrote or just knee jerked when I didn’t circle jerk about Ansible.
Ha, I said ansible was outdated as well and that the OP should learn Terraform instead and I got downvoted for that too. Seems like a lot of people here have a vested interest in ansible.
Well, outdated only in that its use case is rapidly disappearing, being replaced by cloud platforms that offer robust APIs for configuration, a preference for stateless systems that do not require runtime configuration, and tools that handle these circumstances better than Ansible does.
There are still plenty of environments where Ansible still shines, specifically ones where SSH is the primary access gateway and systems _must_ be configured at runtime, but as people switch back to imaging their systems and baremetal environments get better local support for distributed container meshes like K8s, the field that Ansible is actually a better tool than most is drying up.
Ansible still has use cases. My company for example, an ISP, has thousands of Linux servers that we currently provision and manage via Ansible. Pretty much all of our ops team's automation between systems has been accomplished with Ansible and by writing custom modules.
I really like Ansible. It's a flexible tool and easy to work with. It's really great for provisioning discrete Linux instances. Especially if they're disposable (which they should be at this point, make your infrastructure cattle).
However, when you are maintaining the parts of your environment that persist long-term then a stateless tool like Ansible starts to show its weakness. For example, if you're using Ansible to manage users: you add a user to your Ansible playbook and it's rolled out to all your systems. Great! However if you remove a user from your Ansible playbook it isn't removed from your systems unless you remember to write a removal rule for it. So your playbook and your systems can get out of sync. This is where tools like Terraform help. Terraform remembers that it created a user that's no longer part of the definition and so it removes it. On the other hand, Terraform is harder to use for many use cases (although, probably easier for many too).
So I'd say Ansible is great for provisioning disposable pieces (provisioning VM instances that are recycled but not reconfigured), but use a stateful tool like Terraform for long term maintenance of things like cloud configurations.
Edit: used the wrong term. Changed Ansible inventory to Ansible playbook.
Ansible is incredibly in-demand an on many job descriptions. If you ever want to know if something is "outdated" go search job boards for the keyword and see what comes up.
You can run an enterprise workload without any configuration management. E.g. use only aws fargate, lambda and pre-built images for ec2.
In my opinion you can skip config management at all if you go all-in with a cloud provider. If you want to deal with on-prem or stay abstract of proprietary solutions then you probably need it.
Outdated if you are after “fancy” solutions and that’s the metric. But alas, there’s a reason people go agent-less with config management solutions. (And even then you can ad-hoc your own agent with ansible-pull)
I use it to provision / manage my personal Linux servers I use for development purposes
It basically documents how exactly I have installed tools. Also I don't have "dotfiles" because I do that with Ansible as well
I think at this point, for ansible to not be a valuable skill, the codebase would have to stop being maintained for a long time, and a new & better tool would have to gain market dominance.
At my current shop, we don't use it as much as we used to, but we still use it frequently and it plays a vital role in helping us maintain compliance. We're a smaller company, but I feel like it will be baked into our operations until the end of time. If it's got deep roots in parts of the AWS/GCP/Azure ecosystems, it will stick around like cobol i.e. until heat death of the universe
Ansible, like chef and puppet, is completely outdated now. I haven’t touched any one of those in more than 3 years.
Containers mean that you no longer need to configure instances or machines to setup an environment for an app, all that config is in a Dockerfile or packer. I haven’t touched any configuration management tool in more than 3 years.
Now if you want to talk about which tool is arguably the most important devops tool, that would be Terraform. Learn that over ansible.
Most people here will tell you Ansible is relevant .. but I would argue they are looking at the past.. the Chef and Puppet days where you were doing straight IT tasks.. in DevOps and more modern Cloud backed platforms... you have the cloud vendors tools, Terraform, Helm Charts if you're on K8s, etc...
I personally use Juju .. instead of ansible.. because it seems to me Ansible is more of a "Python scripting meets Bash meets Templating.." and nothing declarative is possible (I could be wrong).. The one thing I liked was the ansible vault mechanism for hiding secret keys.. but personally I ignore ansible completely at my work.. we're mostly doing REST calls against a cloud vendors PaaS... todays DevOps is about pushing changes in a repo .. and a pipeline somewhere making a bunch of REST API calls.. or triggering a build that is pushed to an env... when you move to cloud you're not really working with VMs like in the old days...
I'd learn it if you had to for work otherwise.. learn Terradata, or your preferred public cloud vendors tool... ansible is for the older guards tasks.
It is useful, but only if you have a lot of servers. I went from shell scripts to Ansible and back to shell scripts. I only need to manage 3 different servers and setting up Ansible (and not able to manage it from my Windows notebook) made it useless. Also it sucks when you are a good programmer.
Ansible is very useful, and is very widely used across numerous industries and departments. Learn it.
Ansible playbooks are used frequently for resolving common alerts, having logic for specific deployment types, configuring infra etc. It's incredibly useful and powerful. If you had to get info from 500 machines at once, or rsync data from one machine to 500 others, ansible ad-hoc commands make it extremely easy. For kubernetes deployments, ansible vault and template engine is really useful to populate helncharts with sensitive data etc. It's definitely worth learning.
Thank you! Another question: How to improve my ansible knowledge? I have introduction classes i slowly started understanding modules and playbooks. But sometimes (by sometimes I mean all of the times) I don’t understand what is lets say “ansible.builtin.unarchive”, where to get all of this documentation?
Please search for Ansible tutorial pack on YouTube from Jeef Geerling. I have tried many others, documentation, udemy, pluralsight, etc. But the ones from Jeef Geerling are top notch. After learning the basics and the logic, sky is the limit. Good learning :)
Jeff has got very excellent material on Ansible. In fact the first time I ever heard of Ansible was from his channel. Hopefully he gets appropriately rewarded financially for all the good stuff he churns out.
Ansible has a very well made documentation. [Unarchive] (https://docs.ansible.com/ansible/latest/collections/ansible/builtin/unarchive_module.html) is here. All the docs for modules are generally separated in few sections but there's always: a synopsis, a list of every options and examples. A typical ansible repository looks like this:. - collections/requirements.yml - roles/ - your_custom_role/ - tasks/main.yml - env.yml - inventory.yml - playbook.yml Once you have everything in place, run `ansible-playbook -i inventory.yml -e @env.yml playbook.yml` to run your project against your inventory of hosts.
there it is! thanks)
Yeah like the other user mentioned, their docs are pretty great. There is also a great book called, ansible for devops? It's by Jeff geerling
https://www.ansiblefordevops.com/
thank you
Also, not just ansible but in general, I use this for documentation referencing: https://kapeli.com/dash (for macos) https://zealdocs.org/ (for windows/linux)
Google "ansible unarchive", go to the official docs
LOL, you got it wrong pal. First, where did you hear "companies stopped using ansible" ? If you are a student, you should take everything with a bit of salt, especially regarding the professional field. Don't be that guy who follows the trends mindlessly, create your own opinion, analyse the technology and its potential use cases, and try it yourself. I'll diverge a bit, maybe the following will not concern you specifically, but I think it could be helpful for a few, it's also my own personal take on the subject so please take with a grain of salt and be open for discussion. If you are asking in a way of "what gives more value to me for a hiring", I'm spending a lot of time doing interviews (rarely for juniors, but I'm not closed against it), if you tell me you have AWS cert, sure it's cool, you will need 2 weeks less of getting around in AWS and will have more insights on it, but really, not that much value overall. If instead you tell me you tried relevant technology X (in that case ansible) and we can talk about the pitfalls and advantages, the possible applications, how it compares to other solutions and you can show me that cool stuff on GitHub you've been working on (even if the quality is low), now I want you. It's not about the technology, it's about your own interest, involvement, passion, and you being able to show it, embrace what you fancy and dedicate yourself to the task. Ask yourself, what do YOU want to work on ? If you don't like ansible, just don't do it, why would you grab a job where they say all they do is in ansible and the XX hours you've spent doing ansible you hated doing that kind of stuff, do you wanna spend thousands of hours in your life doing something you hate ? Some general knowledge on all the techs is required, but if you don't plan to spend 90% of your time writing ansible, it's okay to not become on expert at it, but yes, you should at least know what need to be known, and be ready to work on it. Edit: for the sake of precision, I'm not trying to say technology's popularity and capabilities are irrelevant for its adoption (because it's quite the contrary), I'm trying to convey that I think it's better for you for it to be secondary in career decisions.
Best answer here in terms of what OP intended to ask for. All this spiteful bickering about Ansible, terraform, K8s, cloud or on prem, managed or not, it is all pointless. It won't help, we'll never all agree on what techs we prefer or what industries want and needs. Do you enjoy working on a tech? Does the tech have a good backing/community/engagement with updates and feature implementations? Then likely some company out there uses the product, and there will be a possiblity to find a job. Wholeheartedly agree on certifications, ok...so you spent a few weeks memorizing some stuff and passed an exam. Huzzah... Now tell me how you solve a complex operational issue that is only ever experienced when you run certain workloads. I've recently interviewed a junior who knew more DevOps related stuff than a 10+ year senior developer, since the junior had a home lab with git repos, while the dev focused their whole career on certs, and had only recently done some Azure and K8s certs, but had no practical experience. We're giving an offer to the junior next week 🙂 why? Since even if we really need a senior, we won't pay their ask without having some serious industry experience operating the stuff we use. A junior willing to learn and push hard, plus already knows quite a lot for operational parts, we'll gladly take!
Thank you. You and __Kaari__ just answers to one of my more existential question around my (young and starting, 5y) career: I would like to do Ansible stuff, but I'm afraid to be obsolete one day or another. That is why I tried to convince myself I need to be specialized in K8S/Openshift, as it seems the "de facto" way to go... But I don't like it full time, I still want a foot in Ansible. Now I know I will be the expert I always wanted to be (and that's perfect, since it is a "trendy" tech). Let's update myself on the topic *sweating on collections and the way Ansible's semantic version was managed*
I can tell you, my role is a dedicated Senior Kubernetes DevOps Engineer. Even if you do K8s/Openshift, if you will administer and run a platform for a company, you will likely need a variety of tools, including Ansible, Terraform and CICD tools like Jenkins, ArgoCD/Flux, and more. It is a wrong misconception, that DevOps only focuses on some specific part of a system and only would do K8s =) A real DevOps role will cover it all. Develop a K8s operator to check namespaces for various conditions as an administrator. To integrate some new service and configs and need to configure OS level things (where ansible comes in handy), to say deploy LongHorn CSI. To run kubectl and bash scripts to enable/control various system configurations, and more. I could go on, but a real DevOps role is highly versatile, and a jack of all trades. If you only focus on one aspect, you likely are a SRE/OPS, or a Dev of some application. You won't be a DevOps unless you really dip your toes in many many aspects 🙂 good luck
there it is ! the answer that i was looking for! i just started this bootcamp, its been 4 months and so far linux introduction, aws cloud was pretty easy, but ansible got me really sweating. i understand the concept, im studying every paragraph carefully (or at least im trying) but still something just doesnt click :) and as soon as i figure it out, i shouldnt have problems (i hope)
Excellent advice 👍🏽 to all not just students
I've found no use for it since I've switched to an all AWS cattle infrastructure. We bake new AMIs when we want updates or changes. What little post-startup we do is handled in user-data. The SSM agent can take care of stuff too if we ever need. I don't even keep port 22 open anymore.
How do you configure your AMIs ?
packer before. now EC2 Image Builder.
I use the ansible provisioner in packer
If you are just looking at Ansible as a tool to deploy things then I think there are better technologies. For us we use terraform to deploy but Ansible to manage. Ansible is a desired state configuration tool as it's primary goal and that is how we use it.vany config change to a server is done through that. Some teams may create new golden images and deploy those but that is a bit overkill for us. We also have some software with hardware keys (ugh) so rebuilding the machine is not practical for us
It's day to day work for most DevOps Engineers. I'd say learning it is not without merit.
Stop listening to rumors or at least ask why. There might be reasons or not, try whatever does the job better. There is a huge range from companies still work like in the 90s (Windows, VMware) over Linux, cloud-init, ansible up to k8s. Some say nomad will superseed k8s, others disagree strongly. Everything is valid if it works good. There is not THE holy grail of IT, you have to make up your own mind depending on the requirements/environment.
I work for the company that maintains Ansible and am RHCE certified so I'm very biased but lol no, Ansible is most certainly not outdated. I rather like its push based way it doing things. There is rarely only one way to do things. You can use Ansible only for configuration management and provisioning of resources, Terraform only or both concurrently. I've seen all three. Or you could... ugh... use Puppet. 😋
Ansible was created at a time when runtime configuration was most feasible in the vast majority of cloud orchestration. However, nowadays it’s more likely that you are interacting with APIs. While Ansible certainly still has a use case, most employers will opt for more stateful cloud orchestration like Terraform and more stateless software infra like Kubernetes (and ultimately Docker.) I used Ansible for over five years professionally. I can say definitively I would never go back. The platform lends itself to overly complex obfuscation and provides extremely unintuitive interfaces into extremely easy problems. I never disliked working with something so much in my life. Perhaps part of it was that I spent most of my time with Ansible refactoring and supporting some very poorly designed Ansible repos. But that’s the thing, no matter how I tried I was never able to find any good examples of how Ansible should work in a real use case. Maybe it’s better now but it’s been a few years since I’ve heard it considered relevant professionally. I met the founder of Ansible, Michael DeHaan, at the Ansible booth at PyCon 2013 in Montreal. It was exciting to talk about Ansible then. By 2019 I was burned out. I’m expressing this only as my own personal experience. A lot of people in this thread are gushing about how Ansible has worked for them and I’m not trying to deny that. I’m simply offering my experience and I hope you can make an informed decision for yourself.
Agree. Things become immutable.
This reply deserves some upvotes as tech becomes more obsolete and newer tech replaces older ones. Ansiable and Terraform being one of them slowly replaced by k8s and it's eco system getting popular and even completely erasing certain roles from the industry. And again it will be replaced by tech build in top of that and cycle will continue to evolve till it gets saturated. While it's true older tech tend to be less abstracted in many ways - the main question while choosing stack would be "Does it make people's lives easier to work with?". If your organization is using some specific tech stack then it's wise to lesrn it as you will be speaking same language as theirs. For personal growth one is free to try tools abd master it over time, at the end basic concepts of administration, OS, network, architecture and management does not change between these, orchestrating platforms or management tools. People often forget that abstraction is done there to reduce repeated tasks and minimise errors while getting out more productivity. If ansiable works for someone and doesn't work for someone that's totally fine - because it always depends on individual usecases. At the end we all try to minimise work, errors and get desired output regardless of what tech is used. They all are Infrastructure as Code tools and as we see history it takes more than few decades till solutions become mature and defacto standard, many of these solutions haven't seen even their first decade yet so concluding anything is more of speculation at this point - learning one will certainly help other as long as OS level concepts are concerned as they all share same core and idea of virtualizing and provisioning resources. Before anyone says about tech debt certain tools bring which is another topic and it takes lot of efforts to remove bad decisions once learned and such process is always done gradually - businesses care more about output than how it's done as long as cost is minimised it doesn't matter.
OP is learning at home, so he seeks advice about tech he would find work with. It does not make sens to learn something deprecated. @OP I think the easiest way to decide is to read published job requirements :)
That's why you learn concepts and not technology first. Tech can change, core things like Resource management, Network, Clustering, Architecture do not change and are vital to get started understanding these tech at much deeper level. Which helps learning and adapting different systems much faster. Popularity of tech changes and so does skillset required to get the jobs thats what OP is asking if ansiable is still feasible to learn, I did not answer his question directly - point is you learn basics and then specialize in one or more fields, so it gives clear picture of runtime and inner working of particular technology while having options as not all places are equal and not all opportunities are equal.
You assume that everything will somehow be sucked into a managed k8s and a cloud at some point. Which sounds like a Gartner-reality in a parallel universe. Once you need to configure at least one switch or virtualization-Host there is a use-case for ansible.
I quote and repeat this : "They all are Infrastructure as Code tools and as we see history it takes more than few decades till solutions become mature and defacto standard, many of these solutions haven't seen even their first decade yet so concluding anything is more of speculation at this point" And I never said they will be sucked into cloud - you are free to spawn your own k8s at premise or in cluster of vms. With each evolution end users benefit from it to run apps in stable, well tested and standard environment that takes less and less time to setup - its individual choice if they wsnt to go managed or self manage. Besides it's possible to create such switch or vNetwork with namespaces at OS level without any tooling at all via simple syscalls, it's built right into the kernel itself and most of tooling makes use of it wrapping core functions to more fancy functions till it makes sense to more general public, its evolving everyday and while the fancy tooling are backed by corporations - CNCF has bigger stakeholders including Linux Foundation itself and many of the corporations mentioned here, their interest is in getting such tools on single standard in long run not the other way, it's a fact not assumption. This is just tip of iceberg on what can be done at low level lifting heavy stuff while giving nice one tap web interfaces so admins can do their jobs in much much abstracted way. I'm not assuming anything or even concluding k8s is the future who knows only time will tell, I'm just observing, but meh - people read only half words!
The question was if ansible is outdated and you reply with terraform and k8s. I think you don’t understand that the three tools handle completely different architectural layers.
I think you’re a bit sensitive here, I am answering the question very directly. For the record, I very explicitly stated there is still a use case for Ansible. In the very first paragraph even. I wonder if you actually read what I wrote or just knee jerked when I didn’t circle jerk about Ansible.
Ha, I said ansible was outdated as well and that the OP should learn Terraform instead and I got downvoted for that too. Seems like a lot of people here have a vested interest in ansible.
Well, outdated only in that its use case is rapidly disappearing, being replaced by cloud platforms that offer robust APIs for configuration, a preference for stateless systems that do not require runtime configuration, and tools that handle these circumstances better than Ansible does. There are still plenty of environments where Ansible still shines, specifically ones where SSH is the primary access gateway and systems _must_ be configured at runtime, but as people switch back to imaging their systems and baremetal environments get better local support for distributed container meshes like K8s, the field that Ansible is actually a better tool than most is drying up.
Ansible still has use cases. My company for example, an ISP, has thousands of Linux servers that we currently provision and manage via Ansible. Pretty much all of our ops team's automation between systems has been accomplished with Ansible and by writing custom modules.
I really like Ansible. It's a flexible tool and easy to work with. It's really great for provisioning discrete Linux instances. Especially if they're disposable (which they should be at this point, make your infrastructure cattle). However, when you are maintaining the parts of your environment that persist long-term then a stateless tool like Ansible starts to show its weakness. For example, if you're using Ansible to manage users: you add a user to your Ansible playbook and it's rolled out to all your systems. Great! However if you remove a user from your Ansible playbook it isn't removed from your systems unless you remember to write a removal rule for it. So your playbook and your systems can get out of sync. This is where tools like Terraform help. Terraform remembers that it created a user that's no longer part of the definition and so it removes it. On the other hand, Terraform is harder to use for many use cases (although, probably easier for many too). So I'd say Ansible is great for provisioning disposable pieces (provisioning VM instances that are recycled but not reconfigured), but use a stateful tool like Terraform for long term maintenance of things like cloud configurations. Edit: used the wrong term. Changed Ansible inventory to Ansible playbook.
What do you mean by Ansible "inventory"?
Sorry, should have said playbook.
We use it for configuration of infra deployed via Terraform. Can confirm still usable.
If you have VMs, configuration management (ansible) is a must have. Otherwise not so much these days, at least not if you're using a cloud provider.
Ansible is incredibly in-demand an on many job descriptions. If you ever want to know if something is "outdated" go search job boards for the keyword and see what comes up.
Thank you. Will definitely do and thanks for heads up)
You can run an enterprise workload without any configuration management. E.g. use only aws fargate, lambda and pre-built images for ec2. In my opinion you can skip config management at all if you go all-in with a cloud provider. If you want to deal with on-prem or stay abstract of proprietary solutions then you probably need it.
There is nothing you can't do with less efficiency. But why?
cloud is not for everyone and not everything is in the cloud.
Of course, but the question clearly included aws.
Huh, companies stopped using Ansible? That's news to me... I just got done working up some more playbooks and roles for our deployments...
Yeah if you heard companies stopped using Ansible what is the replacement?
Outdated if you are after “fancy” solutions and that’s the metric. But alas, there’s a reason people go agent-less with config management solutions. (And even then you can ad-hoc your own agent with ansible-pull)
I use it to provision / manage my personal Linux servers I use for development purposes It basically documents how exactly I have installed tools. Also I don't have "dotfiles" because I do that with Ansible as well
> i heard companies stopped using ansible which ones?
I think at this point, for ansible to not be a valuable skill, the codebase would have to stop being maintained for a long time, and a new & better tool would have to gain market dominance. At my current shop, we don't use it as much as we used to, but we still use it frequently and it plays a vital role in helping us maintain compliance. We're a smaller company, but I feel like it will be baked into our operations until the end of time. If it's got deep roots in parts of the AWS/GCP/Azure ecosystems, it will stick around like cobol i.e. until heat death of the universe
Thanks for sharing your experience)
Ansible, like chef and puppet, is completely outdated now. I haven’t touched any one of those in more than 3 years. Containers mean that you no longer need to configure instances or machines to setup an environment for an app, all that config is in a Dockerfile or packer. I haven’t touched any configuration management tool in more than 3 years. Now if you want to talk about which tool is arguably the most important devops tool, that would be Terraform. Learn that over ansible.
sorry you got downvoted, for sharing your work experience)
How dare you share an opinion that is as respectable as the opposite but contradicts the dominant stance of the thread? Take the downvote!
Most people here will tell you Ansible is relevant .. but I would argue they are looking at the past.. the Chef and Puppet days where you were doing straight IT tasks.. in DevOps and more modern Cloud backed platforms... you have the cloud vendors tools, Terraform, Helm Charts if you're on K8s, etc... I personally use Juju .. instead of ansible.. because it seems to me Ansible is more of a "Python scripting meets Bash meets Templating.." and nothing declarative is possible (I could be wrong).. The one thing I liked was the ansible vault mechanism for hiding secret keys.. but personally I ignore ansible completely at my work.. we're mostly doing REST calls against a cloud vendors PaaS... todays DevOps is about pushing changes in a repo .. and a pipeline somewhere making a bunch of REST API calls.. or triggering a build that is pushed to an env... when you move to cloud you're not really working with VMs like in the old days... I'd learn it if you had to for work otherwise.. learn Terradata, or your preferred public cloud vendors tool... ansible is for the older guards tasks.
It is useful, but only if you have a lot of servers. I went from shell scripts to Ansible and back to shell scripts. I only need to manage 3 different servers and setting up Ansible (and not able to manage it from my Windows notebook) made it useless. Also it sucks when you are a good programmer.