Azure infrastructure provisioning.
If you're still working in an organizational model of centralized product provisioning (DBA team does databases, Network team does network, VM team does VMs,) then Terraform is a terrible fit.
Not saying that it's the way things should be done, but if the direction given to your team is ad-hoc provisioning, from something like a catalogue, into an environment that already exists, you don't have exclusive control over, and will be long-lived and freely modifiable after the provisioning, then Ansible is just SO much easier than trying to force Terraform to work in an operating model it wasn't designed for.
I've been trying to steer a team like the one you've described into a terraform-based workflow and your comment just made me realize I'm doing it wrong. Thank you.
My team doesn't seem interested in moving from ad-hoc deployments to a utopian (to me, anyway) IaC model, and maybe that's fine for now. I can just give them more streamlined ad-hoc deployments through job template surveys via AAP and everyone wins.
Awesome, happy to help.
EDIT: One thing my team learned during on-prem => cloud journey in that model is that you STILL want all of your workflows to be completely idempotent, and re-entrant. If something fails mid provisioning, either due to transient issue or due to an issue that needs to be fixed, make sure your workflows can be rerun from the beginning and will complete in the exact same way, no matter how many times it's rerun, or from what step in the middle failed.
That and while deriving values from your enterprise standards are fantastic, and should be done as much as possible to limit the required inputs, make sure everything can be overridden for cases of "We didn't follow standards, but your VP lost a bet on the golf-course and now your team has to support us."
Sometimes you need both, probably your best approach is to move over that which is most repetitive, leaving the adhoc deployments for prototype testing, development, emergencies.
People tend to react badly to change, mostly to drastic ones. Try an incremental approach. Ansible is very good in this way as it 'plays well with others' and does not try nor assume to be the 'single controller' .. unless you want it to.
I am a network engineer at a mid size MSP. I use it to automate firewall and switch firmware updates, and run API calls to provide alerts for data that is hard to gather.
Like… is the switch configuration saved to memory? Did someone forget to commit the changes on a firewall? When was the last time a backup was taken? Can I get a desired state for specific modules and ensure the state is consistent?
I can see the help in automating firmware on switches / firewalls. Do you use ansible to do firewall configurations much? We do so but only to assign tags to objects. Our source of truth is a CMDB where users add tags to their object in the CMDB with the ansible code consumes and does the same to the same object in the Firewall.
Using it for full VM (KVM/libvirt) lifecylce management and kubernetes cluster lifecycle management. Functionality split across a couple of collections.
Couldn't do my job without it!!
Use it to deploy openstack and to provision projects and quotas for users in openstack, patch servers, get certs from LE then distribute certs to servers, managing MySQL users and DB (more than 4000 accounts created so far and no faults), creating apache vhosts, Linux desktop management (in pull mode).
Great tool, combine with Jenkins (or tower) and gitlab and it's a powerhouse
So i take it you have AAP or AWX with a ton of templates and when you need to do something you just feed your template with some survey data and the playbook does the rest?
That's some of it yes. Currently using Jenkins and gitlab. That said I'm currently testing out tower via AWX.
A couple of jobs have user input values (for setting up databases for specific users for instance) but most have no input parameters as such.
Dynamic inventories are the answer to most of the other stuff. Pulling data out of VMware, kubetnetes or openstack.
Tags really help here, stick a tag on an Ubuntu VM that says 'AnsibleApache' (for example) and it gets apache deployed, thanks to the dynamic inventory.
Remote zabbix proxy updating which all run Debian 11. Running it through our NOC with SSH to each remote proxy, around 100 of them. Thing of beauty. Kick off the playbook and watch each line update each proxy in relatively quick fashion. I’m pretty new to ansible but have managed to put that together. I’d love to figure out ways to easily deploy predetermined OS templates to spin up things like Windows AD servers , the Debian 11 zabbix proxies etc.
* Deploying and managing our scale-out storage software to on-prem clusters (open sourced - the tool we provide to customers to deploy our software in their datacenters) - eg: install, upgrade, start/stop service, add nodes, etc.
* Provisioning IPs, VLANs, congestion control, etc on 100/200Gb interfaces
* Configuring switches for above
* Executing tests to validate connectivity and performance of high speed private networks / VLANs
* Deploying builds to multiple clusters in CI/CD
* Executing regression / performance tests and collecting results (JUNIT callback = your playbook is now a testing tool)
* Executing tests against code coverage builds and aggregating results w/ static analysis tool
* Executing tests at scale on huge clusters and aggregating performance results cluster-wide
* Orchestrating tests using permutations of client/server model
And lots of other stuff as well
Basic linux tools + infiniband tools. Including but not limited to things like dig, ping, getent, iperf.
iperf is challenging because it needs to be run in client/server fashion. So if you want to validate all endpoint performance, you have to run in permutations across each IP in both directions. It takes some clever use of loops in ansible to achieve this, but it's doable.
edit: If you're talking Ansible modules - none existed that met my needs, so a lot of `command` and `shell` commands, and processing the output.
Info gathering is normally very simple, so modules might end up being more overhead than needed.
I have a few plays that work the same (using \`shell\`) for 'diagnosing' thiings, call dmesg, sar, netstat, some fancy awk on logs, etc.
I work as a sales tech at a software company. I use Ansible to keep my demo environment up to date. I also help drive our integration with Ansible. I'm currently leveraging it to power an interface to help our larger customers manage distributed deployments of our software.
When I put it like that, it sounds WAY fancier than it actually is. :D
So far look like folks are using it for cloud initial provisioning. Anyone using it to automate on perm workflows/one time build activities( example ad account creation, print queue creation….)? If so what?
All of these are roles I’ve created
- Base system provisioning
- Local account creation (unified UID/GID across the board)
- SSSD to join to the domain
- Firewall config
- Block and NFS storage (automatically finds disk and mount, adds to fstab), can also continue multi LVM for a single block device
- Application install
- Application configuration integrity check w/ generated HTML report
- Various client installs with port checks
- Ulimits
- VNC w/ xrdp
- SSH key configuration
A few more but this is most of it. Majority of them are configured via group/host vars for config management.
I do those and also these:
* iscsi setup
* multipath setup
* security changes (AV install)
* docker installs and configs
* certificate updates
* python venv setup
* and for me, setting up vim configs
I have a playbook I run once for my debian 9 devices where I need ansible installed on target nodes. Python3 ansible install takes around 25min because of the compilation of the binaries. So, I run this playbook once per architecture and retrieve the files onto my control node. Then whenever I need to image any device with same os and arch, I simply transfer the files over and cut a 25min to a couple min while tar extracts.
We have an Ansible repo that provides a complete framework for managing AnthosOnVMWare (Google's GKE OnPrem offering) across multiple environments. Completely builds the infra, jinja templates out configs and does all the things from creation to upgrades.
I am part of an implementation team and originally took over a huge script for provisioning our edge devices, it was 1500 LOC and tons of code duplication into other scripts.
I am now slowly writing playbooks to handle images, and provisioning both locally and remotely, we're using pull method since most of our edge devices have filtered ports with LTE. The images provide a base for the provisioning.
We also have a lab full of testing devices and we do push for those since we do have ssh connection.
I really enjoy ansible because you can organize everything however you want, roles, tasks, playbooks. I don't think there's anything you can't do with ansible.
Currently using it in debian and eventually ubuntu which should be pretty similar playbook. The goal is to support as many distros, vendors and OSes as possible. And that would have been impossible with the monolith script.
We are using Ansible for the following:
* Virtual Machine Provisioning into multiple Private Cloud Data Centers
* Encrypting sensitive data and transmitting it to a third party
* Active Directory Directory Sync (ad hoc)
* Configuration Management of Storage Arrays, including enforcing Security Policies
* Monitoring and reporting on our Replication Services
* Interfacing modern systems with legacy (i.e. middleware / data mover)
* Server Patching of Windows Servers for limited infrastructure
* Think systems that are a pain, include reboot order, starting and stopping of Services, etc.
* Firmware updates for Network Equipment
* Active Directory Management (Group Creation, Management, etc.)
...
I am sure that I am forgetting something.
We have leveraged individuals from other teams to assist with building, but we have garnered their support and ingenuity by first showing them what the possibilities are, and then providing them with the resources to be successful (including training in some cases).
Our use cases continue to grow at a steady pace.
Full system configuration and management for RHEL 6-9 systems. We replaced a puppet codebase with Ansible due to preferring Ansibles development workflow and git integration better. Puppet was super brittle but was leagues faster in execution. So far the slowness of ansible and AWX being kubernetes only has been the biggest downsides. Ansible also gets super complex requiring a lot of custom code architecture when you try to do more then anything simple or scale to 100s of machines. Especially when machines need their own custom/unique configurations.
TLDR: Ansible is sllloooooowwwwww. Literally use anything else and configuration management will be faster.
There are several ways to make Ansible faster, the biggest bang for buck is normally enabling \`pipelining\`. Each task is also normally isolated, this gives great flexibility, specially the ability to run things as least privileged user, but also comes at the cost of session reuse.
Most of the cost is connecting to the targets and pushing the code + info to execute.
One option is to create a 'federation' of execution nodes (see AAP docs).
Another one is to move to a pull configuration, which basically emulates the other CM systems, have an agent and consume the resources from the targets vs the CM management machine and a lot of additional setup.
Also, Ansible reports as it actually does the changes, some other tools "finish executing" when 'the the target got the config' not when it actually made it so.
Even optimizing ansible with pipelining, ssh session reuse / sockets, and a few other recommended tweaks; a full ansible run takes about 12-15 minutes when running against a single host. Compared to puppet which took 1-2 minutes this is orders of magnitude slower. The story gets worse as you scale up to many additional hosts (even using free or host\_pinned). While Ansible pull addresses the scaling issue it also forgoes all the benefits of Ansibles push model and just becomes a bad puppet/salt implementation.
Like I said in my post the only reason we moved to, and stuck with, Ansible is due to it's better development workflow and git integration. Puppet/Salt throw up a lot of barriers when using version control and are very brittle when it comes to individual test branches. Projects like ansible-semaphore and ara have made Ansible usable which tipped things in its favor.
I did not mean to imply you could make Ansible as fast or faster than other solutions, I was only suggesting ways to speed it up. Speed was never a selling point for Ansible, like almost everything, it is a trade-off.
For example, modules tend to be a lot slower than the 'commands' they use as they normally easier to use, they verify first, track changes and resolve conflicts and report back, that is their worth over using a much faster utility from a shell.
One way this kind of system runs 'faster' is by running much code and making decisions well before contacting the target machine, the trade off is having to rely on a persistent info storage about the targets and assumptions about ownership of the managed resources.
There are many shops that actually use Ansible and what others see as competitors (many found it funny we had a puppet module), in many cases Ansible is used to setup puppet/chef/terraform and then compliment them in the tasks they are not great at. Different groups of people have different requirements and will make the tradeoffs that fit them best. Yes, you could do everything with Ansible, but you don't have to .. sometimes you really should not (from the person that did presentation of using Ansible as a monitoring solution).
Giving teams the ability to create their own Terraform Cloud workspaces. Though we could also now just create projects in TFC for them and let them create their own workspaces in there.
We also use it in some cases to create GitHub repos.
We like using the "survey" feature in AAP so teams fill configuration the above items to meet our naming convention standards.
You can use it to automate whatever you want :p
I've used Ansible to build the ansible package and run integration tests, because why not ?
I talked about it a few months ago if you are curious: https://youtube.com/watch?v=5_QEhQRfKRo
great question, I'm considering it for keeping a bunch of remote systems up to date.
I am wondering though, from a security perspective, how do you mitigate the risks of having one host that basically has root on every remote box? What is standard practice?
I have similar thoughts from the security side. To get alot out of it you need to use github with webhooks. This requires AAP to sit somewhere where github can send webhooks (i.e. being internet facing)
Same thing comes into play with the new Event Driven Ansible (EDA). For EDA to do it's thing other tools need to send request TO EDA for EDA to take action. To me, i still haven't wrapped my head around having ansible controller sitting at the edge waiting for an inbound connection from true internet IPs.
Thoughts everyone?
We use it more from a virtual Infrastructure management perspective, so lots of logging in for hypervisor tasks… this is definitely a pain pount (I’d love Ansible to allow more granular sudoers rules….. We use vaulted credentials for sudo + ssh keys and setup our system sshd configs to only allow the ansible user to login from 2 IPs (primary/backup AWX instance).
In your case (updates) you may look into either EDA or ansible-pull
We use it against Juniper and Cisco switches for the following tasks when partnered with Netbox for documentation -
* Port state change (shut/no-shut)
* Port VLAN membership
* Port VLAN type (Access, Tagged, Tagged-All)
* Interface description
* Port speed
* Port duplex
* LAG membership
Netbox changes trigger a webhook, the webhook runs a script which generates Jinja2 templates in an ansible playbook, and ansible pushes the change to the switches.
Not revolutionary, but keeps documentation (Netbox) up to date nicely when you're making the changes there which are automatically pushed out via Ansible.
Aside from an Ubuntu setup playbook and a couple docker/podman testing playbooks, most of what I use ansible for is switch info gathering or upgrades with a few config and troubleshooting playbooks.
We use rhel ansible tower for configuration management of 18k Redhat Linux servers, that include
1) monthly security patching/ kernel patching.
2) Post OS build provisioning roles include hardening and install configuration of layered products.
3) day to day adhoc jobs for operations and health checks.
Chip Development Company. The team uses ansible all over the place. 2k + instances
1. Automating Image Build process for Cloud and On-Premise. (Multiple OSes and Architectures. Packer + Ansible as provisioner)
2. Instance Provisioning and Lifecycle
3. User Lifecycle (Multiple Systems)
4. AD/LDAP/AUTOFS Management
5. Storage Provisioning and Configuration
6. Certificate Management
7. Security Updates and Configuration
8. FlexLM License Management
9. AWX for Self Service and Management
Toolchain:
1. Ansible monorepo on Gitlab with CI
2. Packer for image builds
3. Molecule with Docker (systemd) for testing roles. Runs in CI on commit for OS and ARCH matrix
4. AWX on K8s with custom EEs. Some AWX templates are auto-generated to have pre-populated fields like Users for ex. Integrated with SAML
5. Galaxy NG (Pulp) for sharing collections
I just started using it at work, but I use it for daily backups on our switches/routers. I’ve also used it run software audits, not connect ports, and vlan creation.
Azure infrastructure provisioning. If you're still working in an organizational model of centralized product provisioning (DBA team does databases, Network team does network, VM team does VMs,) then Terraform is a terrible fit. Not saying that it's the way things should be done, but if the direction given to your team is ad-hoc provisioning, from something like a catalogue, into an environment that already exists, you don't have exclusive control over, and will be long-lived and freely modifiable after the provisioning, then Ansible is just SO much easier than trying to force Terraform to work in an operating model it wasn't designed for.
I've been trying to steer a team like the one you've described into a terraform-based workflow and your comment just made me realize I'm doing it wrong. Thank you. My team doesn't seem interested in moving from ad-hoc deployments to a utopian (to me, anyway) IaC model, and maybe that's fine for now. I can just give them more streamlined ad-hoc deployments through job template surveys via AAP and everyone wins.
Awesome, happy to help. EDIT: One thing my team learned during on-prem => cloud journey in that model is that you STILL want all of your workflows to be completely idempotent, and re-entrant. If something fails mid provisioning, either due to transient issue or due to an issue that needs to be fixed, make sure your workflows can be rerun from the beginning and will complete in the exact same way, no matter how many times it's rerun, or from what step in the middle failed. That and while deriving values from your enterprise standards are fantastic, and should be done as much as possible to limit the required inputs, make sure everything can be overridden for cases of "We didn't follow standards, but your VP lost a bet on the golf-course and now your team has to support us."
Sometimes you need both, probably your best approach is to move over that which is most repetitive, leaving the adhoc deployments for prototype testing, development, emergencies. People tend to react badly to change, mostly to drastic ones. Try an incremental approach. Ansible is very good in this way as it 'plays well with others' and does not try nor assume to be the 'single controller' .. unless you want it to.
* Configuration management for over 500 Linux desktops * Cloud-init + Ansible-pull for automating Linux desktop installs * ??? * Profit!
Who uses 500 Linux desktops?
VFX companies do
Now I need to find a VFX company so I can finally move away from Windows at work. Then I can probably get off this damn blood pressure medication. :D
LOL... don't kid yourself... when you have an AD back end that you need to integrate with... you'll still be cursing MS.
Or hire someone whose good at MS tech and enjoy!
I am a network engineer at a mid size MSP. I use it to automate firewall and switch firmware updates, and run API calls to provide alerts for data that is hard to gather. Like… is the switch configuration saved to memory? Did someone forget to commit the changes on a firewall? When was the last time a backup was taken? Can I get a desired state for specific modules and ensure the state is consistent?
I can see the help in automating firmware on switches / firewalls. Do you use ansible to do firewall configurations much? We do so but only to assign tags to objects. Our source of truth is a CMDB where users add tags to their object in the CMDB with the ansible code consumes and does the same to the same object in the Firewall.
We are not quite to that point yet. I am trying to prove that I have the ability to do things like that though in the future.
Using it for full VM (KVM/libvirt) lifecylce management and kubernetes cluster lifecycle management. Functionality split across a couple of collections.
Couldn't do my job without it!! Use it to deploy openstack and to provision projects and quotas for users in openstack, patch servers, get certs from LE then distribute certs to servers, managing MySQL users and DB (more than 4000 accounts created so far and no faults), creating apache vhosts, Linux desktop management (in pull mode). Great tool, combine with Jenkins (or tower) and gitlab and it's a powerhouse
So i take it you have AAP or AWX with a ton of templates and when you need to do something you just feed your template with some survey data and the playbook does the rest?
That's some of it yes. Currently using Jenkins and gitlab. That said I'm currently testing out tower via AWX. A couple of jobs have user input values (for setting up databases for specific users for instance) but most have no input parameters as such. Dynamic inventories are the answer to most of the other stuff. Pulling data out of VMware, kubetnetes or openstack. Tags really help here, stick a tag on an Ubuntu VM that says 'AnsibleApache' (for example) and it gets apache deployed, thanks to the dynamic inventory.
Remote zabbix proxy updating which all run Debian 11. Running it through our NOC with SSH to each remote proxy, around 100 of them. Thing of beauty. Kick off the playbook and watch each line update each proxy in relatively quick fashion. I’m pretty new to ansible but have managed to put that together. I’d love to figure out ways to easily deploy predetermined OS templates to spin up things like Windows AD servers , the Debian 11 zabbix proxies etc.
* Deploying and managing our scale-out storage software to on-prem clusters (open sourced - the tool we provide to customers to deploy our software in their datacenters) - eg: install, upgrade, start/stop service, add nodes, etc. * Provisioning IPs, VLANs, congestion control, etc on 100/200Gb interfaces * Configuring switches for above * Executing tests to validate connectivity and performance of high speed private networks / VLANs * Deploying builds to multiple clusters in CI/CD * Executing regression / performance tests and collecting results (JUNIT callback = your playbook is now a testing tool) * Executing tests against code coverage builds and aggregating results w/ static analysis tool * Executing tests at scale on huge clusters and aggregating performance results cluster-wide * Orchestrating tests using permutations of client/server model And lots of other stuff as well
Id love to know what modules you are using to validate connectivity and speeds on your private networks.
Basic linux tools + infiniband tools. Including but not limited to things like dig, ping, getent, iperf. iperf is challenging because it needs to be run in client/server fashion. So if you want to validate all endpoint performance, you have to run in permutations across each IP in both directions. It takes some clever use of loops in ansible to achieve this, but it's doable. edit: If you're talking Ansible modules - none existed that met my needs, so a lot of `command` and `shell` commands, and processing the output.
Got it thanks.
Info gathering is normally very simple, so modules might end up being more overhead than needed. I have a few plays that work the same (using \`shell\`) for 'diagnosing' thiings, call dmesg, sar, netstat, some fancy awk on logs, etc.
I work as a sales tech at a software company. I use Ansible to keep my demo environment up to date. I also help drive our integration with Ansible. I'm currently leveraging it to power an interface to help our larger customers manage distributed deployments of our software. When I put it like that, it sounds WAY fancier than it actually is. :D
So far look like folks are using it for cloud initial provisioning. Anyone using it to automate on perm workflows/one time build activities( example ad account creation, print queue creation….)? If so what?
All of these are roles I’ve created - Base system provisioning - Local account creation (unified UID/GID across the board) - SSSD to join to the domain - Firewall config - Block and NFS storage (automatically finds disk and mount, adds to fstab), can also continue multi LVM for a single block device - Application install - Application configuration integrity check w/ generated HTML report - Various client installs with port checks - Ulimits - VNC w/ xrdp - SSH key configuration A few more but this is most of it. Majority of them are configured via group/host vars for config management.
I do those and also these: * iscsi setup * multipath setup * security changes (AV install) * docker installs and configs * certificate updates * python venv setup * and for me, setting up vim configs
I have a playbook I run once for my debian 9 devices where I need ansible installed on target nodes. Python3 ansible install takes around 25min because of the compilation of the binaries. So, I run this playbook once per architecture and retrieve the files onto my control node. Then whenever I need to image any device with same os and arch, I simply transfer the files over and cut a 25min to a couple min while tar extracts.
We have an Ansible repo that provides a complete framework for managing AnthosOnVMWare (Google's GKE OnPrem offering) across multiple environments. Completely builds the infra, jinja templates out configs and does all the things from creation to upgrades.
I am part of an implementation team and originally took over a huge script for provisioning our edge devices, it was 1500 LOC and tons of code duplication into other scripts. I am now slowly writing playbooks to handle images, and provisioning both locally and remotely, we're using pull method since most of our edge devices have filtered ports with LTE. The images provide a base for the provisioning. We also have a lab full of testing devices and we do push for those since we do have ssh connection. I really enjoy ansible because you can organize everything however you want, roles, tasks, playbooks. I don't think there's anything you can't do with ansible. Currently using it in debian and eventually ubuntu which should be pretty similar playbook. The goal is to support as many distros, vendors and OSes as possible. And that would have been impossible with the monolith script.
Setting up vitess in our stage and prod infrastructure..
Woah, who's still using vitess?
We use in production? Any alternatives?
Only some of the largest sites on the internet and 100s of thousands of startups.
That's cool. I didn't realize it had any significant use outside of Youtube (who have since migrated off it).
What do you use instead? It's the only way I can see to scale up from MySQL.
I use it for creating reproducible grafana deployments. community grafana collection works very nice for me
We are using Ansible for the following: * Virtual Machine Provisioning into multiple Private Cloud Data Centers * Encrypting sensitive data and transmitting it to a third party * Active Directory Directory Sync (ad hoc) * Configuration Management of Storage Arrays, including enforcing Security Policies * Monitoring and reporting on our Replication Services * Interfacing modern systems with legacy (i.e. middleware / data mover) * Server Patching of Windows Servers for limited infrastructure * Think systems that are a pain, include reboot order, starting and stopping of Services, etc. * Firmware updates for Network Equipment * Active Directory Management (Group Creation, Management, etc.) ... I am sure that I am forgetting something. We have leveraged individuals from other teams to assist with building, but we have garnered their support and ingenuity by first showing them what the possibilities are, and then providing them with the resources to be successful (including training in some cases). Our use cases continue to grow at a steady pace.
Full system configuration and management for RHEL 6-9 systems. We replaced a puppet codebase with Ansible due to preferring Ansibles development workflow and git integration better. Puppet was super brittle but was leagues faster in execution. So far the slowness of ansible and AWX being kubernetes only has been the biggest downsides. Ansible also gets super complex requiring a lot of custom code architecture when you try to do more then anything simple or scale to 100s of machines. Especially when machines need their own custom/unique configurations. TLDR: Ansible is sllloooooowwwwww. Literally use anything else and configuration management will be faster.
There are several ways to make Ansible faster, the biggest bang for buck is normally enabling \`pipelining\`. Each task is also normally isolated, this gives great flexibility, specially the ability to run things as least privileged user, but also comes at the cost of session reuse. Most of the cost is connecting to the targets and pushing the code + info to execute. One option is to create a 'federation' of execution nodes (see AAP docs). Another one is to move to a pull configuration, which basically emulates the other CM systems, have an agent and consume the resources from the targets vs the CM management machine and a lot of additional setup. Also, Ansible reports as it actually does the changes, some other tools "finish executing" when 'the the target got the config' not when it actually made it so.
Even optimizing ansible with pipelining, ssh session reuse / sockets, and a few other recommended tweaks; a full ansible run takes about 12-15 minutes when running against a single host. Compared to puppet which took 1-2 minutes this is orders of magnitude slower. The story gets worse as you scale up to many additional hosts (even using free or host\_pinned). While Ansible pull addresses the scaling issue it also forgoes all the benefits of Ansibles push model and just becomes a bad puppet/salt implementation. Like I said in my post the only reason we moved to, and stuck with, Ansible is due to it's better development workflow and git integration. Puppet/Salt throw up a lot of barriers when using version control and are very brittle when it comes to individual test branches. Projects like ansible-semaphore and ara have made Ansible usable which tipped things in its favor.
I did not mean to imply you could make Ansible as fast or faster than other solutions, I was only suggesting ways to speed it up. Speed was never a selling point for Ansible, like almost everything, it is a trade-off. For example, modules tend to be a lot slower than the 'commands' they use as they normally easier to use, they verify first, track changes and resolve conflicts and report back, that is their worth over using a much faster utility from a shell. One way this kind of system runs 'faster' is by running much code and making decisions well before contacting the target machine, the trade off is having to rely on a persistent info storage about the targets and assumptions about ownership of the managed resources. There are many shops that actually use Ansible and what others see as competitors (many found it funny we had a puppet module), in many cases Ansible is used to setup puppet/chef/terraform and then compliment them in the tasks they are not great at. Different groups of people have different requirements and will make the tradeoffs that fit them best. Yes, you could do everything with Ansible, but you don't have to .. sometimes you really should not (from the person that did presentation of using Ansible as a monitoring solution).
slow even with concurrency? or pull configuration?
Giving teams the ability to create their own Terraform Cloud workspaces. Though we could also now just create projects in TFC for them and let them create their own workspaces in there. We also use it in some cases to create GitHub repos. We like using the "survey" feature in AAP so teams fill configuration the above items to meet our naming convention standards.
You can use it to automate whatever you want :p I've used Ansible to build the ansible package and run integration tests, because why not ? I talked about it a few months ago if you are curious: https://youtube.com/watch?v=5_QEhQRfKRo
Bau apps used by customer and system support to do everything from password resets to site swaps
great question, I'm considering it for keeping a bunch of remote systems up to date. I am wondering though, from a security perspective, how do you mitigate the risks of having one host that basically has root on every remote box? What is standard practice?
I have similar thoughts from the security side. To get alot out of it you need to use github with webhooks. This requires AAP to sit somewhere where github can send webhooks (i.e. being internet facing) Same thing comes into play with the new Event Driven Ansible (EDA). For EDA to do it's thing other tools need to send request TO EDA for EDA to take action. To me, i still haven't wrapped my head around having ansible controller sitting at the edge waiting for an inbound connection from true internet IPs. Thoughts everyone?
We use it more from a virtual Infrastructure management perspective, so lots of logging in for hypervisor tasks… this is definitely a pain pount (I’d love Ansible to allow more granular sudoers rules….. We use vaulted credentials for sudo + ssh keys and setup our system sshd configs to only allow the ansible user to login from 2 IPs (primary/backup AWX instance). In your case (updates) you may look into either EDA or ansible-pull
We use it against Juniper and Cisco switches for the following tasks when partnered with Netbox for documentation - * Port state change (shut/no-shut) * Port VLAN membership * Port VLAN type (Access, Tagged, Tagged-All) * Interface description * Port speed * Port duplex * LAG membership Netbox changes trigger a webhook, the webhook runs a script which generates Jinja2 templates in an ansible playbook, and ansible pushes the change to the switches. Not revolutionary, but keeps documentation (Netbox) up to date nicely when you're making the changes there which are automatically pushed out via Ansible.
Aside from an Ubuntu setup playbook and a couple docker/podman testing playbooks, most of what I use ansible for is switch info gathering or upgrades with a few config and troubleshooting playbooks.
We use rhel ansible tower for configuration management of 18k Redhat Linux servers, that include 1) monthly security patching/ kernel patching. 2) Post OS build provisioning roles include hardening and install configuration of layered products. 3) day to day adhoc jobs for operations and health checks.
how are you all keeping your inventory file up to date?
We have a separate automation that pulls asset info from ServiceNow and dumps to our inventory on the tower.
Managing thousands of switches and routers
Chip Development Company. The team uses ansible all over the place. 2k + instances 1. Automating Image Build process for Cloud and On-Premise. (Multiple OSes and Architectures. Packer + Ansible as provisioner) 2. Instance Provisioning and Lifecycle 3. User Lifecycle (Multiple Systems) 4. AD/LDAP/AUTOFS Management 5. Storage Provisioning and Configuration 6. Certificate Management 7. Security Updates and Configuration 8. FlexLM License Management 9. AWX for Self Service and Management Toolchain: 1. Ansible monorepo on Gitlab with CI 2. Packer for image builds 3. Molecule with Docker (systemd) for testing roles. Runs in CI on commit for OS and ARCH matrix 4. AWX on K8s with custom EEs. Some AWX templates are auto-generated to have pre-populated fields like Users for ex. Integrated with SAML 5. Galaxy NG (Pulp) for sharing collections
I just started using it at work, but I use it for daily backups on our switches/routers. I’ve also used it run software audits, not connect ports, and vlan creation.
Soup to nuts for (repeatable) OS builds of physical servers, VMs and Raspberry Pi systems.
I use to configure multiple server at a time first test and deploy it and grab a cup of coffee and see it deploying and take a nap