Speaker 1: Welcome curious minds to another deep dive. Today. We're taking
Speaker 1: a bit of a shortcut. We want you to be
Speaker 1: exceptionally well informed on a topic that's well fundamentally reshaping
Speaker 1: how we manage technology. That topic is antible automation. We're
Speaker 1: digging into the Red Hat Certified Engineer Antible Automation Steady
Speaker 1: Guide by Alex Soda Bueno and Andrew Block. That's a
Speaker 1: fresh off the press from O'Reilly. Our mission really just
Speaker 1: to pull out those key insights, those aha moments for
Speaker 1: you without you having to wade through absolutely everything, whether
Speaker 1: you're prepping for something, maybe a project meeting, or just
Speaker 1: catching up, or maybe you're just you know, super curious.
Speaker 1: Let's unpack it.
Speaker 2: Yeah, and it's a great resource for that, this guide.
Speaker 2: It gives a really in depth, hands on perspective. The
Speaker 2: authors Alex Soda Bueno and Andrew Block, they bring like
Speaker 2: a massive amount of real world experience from red Hat
Speaker 2: Alex's director of Developer Experience Andrew's distinguished architect. They're involved in
Speaker 2: everything from app life cycles to cloud native stuff. So
Speaker 2: this isn't just about the mechanics. The how it really
Speaker 2: gets into the why answer is so critical. Now.
Speaker 1: Okay, so let's start right there. Why should you listening
Speaker 1: right now care about antsable? I mean it, infrastructures today,
Speaker 1: they're just sprawling, aren't they. You've got cloud, you've got
Speaker 1: virtual machines, bare metal servers, networking gear. Trying to manage
Speaker 1: all that manually, it just feels well, not just slow,
Speaker 1: but like you're constantly fixing mistakes exactly.
Speaker 2: That's the core issue. The guide really highlights this managing
Speaker 2: complexity and ensuring consistency. Ansable lets you store your entire
Speaker 2: infrastructure as code. Think about that, it becomes maintainable, reproducible,
Speaker 2: you know, version controlled. Even It's not just about speed,
Speaker 2: though speed is nice. It's about control, consistency, preventing those
Speaker 2: unintended consequences you get from manual tweaks.
Speaker 1: And you know, for a lot of folks listening thinking
Speaker 1: about their careers, boosting their skills. The RHC certification, specifically
Speaker 1: this ansible exam that e X two ninety four. That's
Speaker 1: pretty big deal, isn't it.
Speaker 2: It really is? And the guide asks, you know, why
Speaker 2: get certified? It's not just enough line on the resume.
Speaker 2: This sert proves a deep understanding of antsable It genuinely
Speaker 2: distinguishes you in the job market. It can accelerate your career,
Speaker 2: push you towards those senior automation or DevOps roles. Plus,
Speaker 2: it just makes you better at your job right, equiped
Speaker 2: to handle complex stuff. And importantly the ex two ninety
Speaker 2: four exam, it's not multiple choice, it's hands on. You
Speaker 2: have to perform real tasks using ansible. It proves you
Speaker 2: can actually do it.
Speaker 1: Okay, practical skills, career boost got it. So let's get
Speaker 1: into the nuts and bolts. What makes ansable well answable.
Speaker 1: One of the first things people mention is that it's agentless.
Speaker 1: What does that actually mean in practice? Why is it significant?
Speaker 2: Yeah, the agentless thing is pretty fundamental. It's a key differentiator.
Speaker 2: See a lot of configuration tools, they need you to
Speaker 2: install a piece of software and agent on every single
Speaker 2: machine you want to manage. Ansable doesn't do that. You
Speaker 2: set up what's called a control node that could be
Speaker 2: your laptop, could be a CICD server, maybe even a
Speaker 2: container that's where ansable lives, and from there it pushes
Speaker 2: instructions out to the managed nodes you're target, get servers,
Speaker 2: network devices, whatever.
Speaker 1: Oh okay, So no extra software cluttering up those managed machines.
Speaker 1: How does it talk to them? Then? Securely?
Speaker 2: Yep, securely usually over ssh for Linux or Unix systems,
Speaker 2: or WinRM sometimes open ssh for Windows hosts, so it
Speaker 2: uses existing secure pathways and those instructions you mentioned. They're
Speaker 2: basically small programs called modules. Ansible copies the module over
Speaker 2: runs it, say to install a package using yum or
Speaker 2: copy of file with faceyp gets the result and then removes.
Speaker 1: The module, so cleans up after.
Speaker 2: Itself exactly, very little footprint left behind. Ansible comes with
Speaker 2: tons of built in modules, but you can also write
Speaker 2: your own, usually in Python or PowerShell.
Speaker 1: That's quite elegant. Actually just sends what it needs, runs
Speaker 1: it gets out okay. So if someone wants to get
Speaker 1: started get their hands dirty, what does the setup look like?
Speaker 1: According to the guide.
Speaker 2: It walks you through it pretty clearly. For your control node,
Speaker 2: you basically need any Unix like machine with a reasonably
Speaker 2: recent Python like three point nine or later, or Windows
Speaker 2: with WSL works two. Managed nodes are more flexible. They
Speaker 2: can often work with older Python versions like two point
Speaker 2: seven or three point five and up. Installation itself is straightforward.
Speaker 2: Usually your OS package manager like DNF or APP or
Speaker 2: PIP on mac os or from source if you really
Speaker 2: want to. The book used Ansible two point one five
Speaker 2: one two. But you know, any currently supported version should
Speaker 2: be fine.
Speaker 1: And you need machines to manage, right. You can't just
Speaker 1: manage the control node itself.
Speaker 2: Right, You need targets. The guide suggests using virtual machines,
Speaker 2: which makes sense for learning. They introduce the idea of
Speaker 2: the host your physical machine, and the guest the VM
Speaker 2: running on it, and to make that easy, they recommend
Speaker 2: using something like Oracle VM virtual box as the hypervisor
Speaker 2: the software that runs the vms, and then crucially Vagrant.
Speaker 2: Vagrant is fantastic for managing these development environments.
Speaker 1: Vagrant Yeah, I've used That makes spinning up vms much
Speaker 1: easier totally.
Speaker 2: You just define your machines maybe a staging server, a
Speaker 2: prod server in a text file called a vagrant file.
Speaker 2: Then you just type vagrant up and boom, your vms
Speaker 2: are running. You can check ips ssh in. It makes
Speaker 2: the hands on part really accessible.
Speaker 1: Okay, environments set up. We've got antsable on a control node,
Speaker 1: some vms managed by Vagrant. What's next? How do we
Speaker 1: tell antsable what to manage.
Speaker 2: That's where the inventory file comes in. This is like
Speaker 2: ansable's address book. It's just a text file usually I
Speaker 2: I or yamal format, where you list all your managed hosts.
Speaker 2: You can group them too, which is super powerful, like
Speaker 2: put all your web servers in a webservers group, databases
Speaker 2: and debservers as.
Speaker 1: You can target commands at whole groups exactly.
Speaker 2: Imagine you have fifty back end servers, define a back
Speaker 2: end group and then run one command to install Java
Speaker 2: on all of them. That's the power. The default file
Speaker 2: is usually a cancible host, but you can point ansable
Speaker 2: to any inventory file you want.
Speaker 1: Can you put other info in there besides just host
Speaker 1: names or ips?
Speaker 2: Oh yeah, You can add variables directly in the inventory,
Speaker 2: things like the username to connect as antsib, loser, vagrant,
Speaker 2: or maybe even the SSH password, though using keys is better.
Speaker 1: Right right? Okay, so we have an inventory. What about
Speaker 1: running simple quick commands not full automation yet, just like
Speaker 1: checking if servers are up.
Speaker 2: That's what ad hoc commands are for. You use the
Speaker 2: answerable command line tool directly. For example, to check connectivity,
Speaker 2: you'd run something like antsable all I inventory rumping.
Speaker 1: All, meaning all hosts in the inventory.
Speaker 2: YEP, or you could specify a group name like webservers.
Speaker 2: The imping tells it to use the ping module, which
Speaker 2: just checks if it can connect and run Python on
Speaker 2: the remote host. You can do lots with ad hoc commands.
Speaker 2: Use the user module to add a user, use the
Speaker 2: commander shell module to run arbitrary commands, even reboot servers.
Speaker 1: What's the difference between command and shell modules.
Speaker 2: A good question. The command module is simpler, safer, maybe,
Speaker 2: but it doesn't understand shell things like pipes or redirects.
Speaker 2: The shell module runs the command through the nodes default shell,
Speaker 2: so it understands all that syntax.
Speaker 1: Got it? Before we jump into the big stuff playbooks,
Speaker 1: the guide mentioned something called gathering facts. What's that about?
Speaker 2: Facts are super important. There are pieces of information about
Speaker 2: the remote hosts, things like host name, IP addresses, amount
Speaker 2: of memory, disk space, operating system version, kernel version, loads
Speaker 2: of stuff. By default, Ansable runs the setup module at
Speaker 2: the beginning of every play to gather these facts. It
Speaker 2: stores them in variables, typically under ansible facts, and then
Speaker 2: you can use these facts in your automation, like.
Speaker 1: Only install a certain package if it's a specific OS.
Speaker 2: Version exactly that kind of thing, or configure an application
Speaker 2: based on the available memory. It makes your automation dynamic
Speaker 2: and adaptable.
Speaker 1: Okay, that makes sense. Facts provide context, but ad hoc commands,
Speaker 1: while useful, seem limited for complex stuff. That must be
Speaker 1: where playbooks come in.
Speaker 2: Absolutely, playbooks are the core of Answable for anything beyond
Speaker 2: simple one liners. They let you orchestrate complex, multi step
Speaker 2: processes repeatably. A playbook is basically a list of tasks
Speaker 2: written in Yamel that Ansable executes against specified hosts from
Speaker 2: your inventory. A single playbook can contain multiple plays. Each
Speaker 2: play targets a set of hosts and runs a series
Speaker 2: of tasks on them. Fundamentally, playbooks are about defining the
Speaker 2: desired state of your systems, and.
Speaker 1: This ties back to that concept you mentioned earlier, idempotency,
Speaker 1: right ensuring tasks only run if needed precisely.
Speaker 2: Most built in ansable modules are idempatent. They check the
Speaker 2: current state first. If the system is already in the
Speaker 2: desired state, say a package is already installed or a
Speaker 2: file has the correct permissions, the module does nothing.
Speaker 1: Which saves time and prevents errors from running the same
Speaker 1: thing over and over.
Speaker 2: Correct It makes playbooks safe to rerun. You're saying, ensure
Speaker 2: the state exists, not run these commands regardless.
Speaker 1: So what does a simple playbook look like? Can you
Speaker 1: give an example?
Speaker 2: Sure, it's a yamal file. It might start with three dashes.
Speaker 2: Then you define a play You give the play a name,
Speaker 2: specify the hosts, a targets like webservers, maybe set become
Speaker 2: true if you need root privileges for the tasks. Then
Speaker 2: you list the tasks. Each task typically has a name
Speaker 2: and calls a module. For instance, a task might use
Speaker 2: antsable dot built in dot em with name dot httpd
Speaker 2: and state latest to ensure the Apache webserver package is
Speaker 2: installed and up to date. Another task could ensure the
Speaker 2: services started.
Speaker 1: Okay, yammel. List of tasks calling modules seems logical. What
Speaker 1: about controlling how the playbook runs across multiple hosts? Does
Speaker 1: it just blast it out to all of them at once?
Speaker 2: Good question. Ansible has different execution strategies. The default is linear.
Speaker 2: With linear, Ansible runs the play on a small batch
Speaker 2: of hosts at a time, often five. By default, it
Speaker 2: waits for them to finish before moving to the next batch,
Speaker 2: but you can change that. There's a free strategy where
Speaker 2: ansable doesn't wait, it just runs tasks on hosts as
Speaker 2: fast as possible, up to the limit set by forks.
Speaker 2: Forks control the maximum number of simultaneous processes ansable will
Speaker 2: spawn to connect to hosts. The default is usually five.
Speaker 2: You can increase it if your control node can handle it.
Speaker 2: You can also control batch sizes explicitly using the serial
Speaker 2: keyword in a play. This is crucial for things like
Speaker 2: rolling updates where you only want to update say once
Speaker 2: or maybe twenty percent of your servers at a time
Speaker 2: to avoid downtime.
Speaker 1: Rolling updates, Yeah, that's a critical use case. What about
Speaker 1: the order within a batch or running a task just once?
Speaker 2: You can control the order with the order keyword. Options
Speaker 2: like sorted, alphabetical, shuffle or reverse inventory and yes, run
Speaker 2: down to stat true tells ansible to execute that specific
Speaker 2: task only once, usually on the first host in the batch.
Speaker 2: Useful for things like updating essential database schema during a deploy.
Speaker 2: You can even make a task run on a different
Speaker 2: host than the one it's currently targeting, using delegate to
Speaker 2: maybe run a task on a load balancer while deploying
Speaker 2: to webnes.
Speaker 1: That's all okay, Lots of control there Now a big
Speaker 1: challenge in automation is handling differences between environments dev staging PROD.
Speaker 1: They need slightly different settings. How does ansible manage that? Variables?
Speaker 2: Variables are absolutely key. They let you parameterize your playbooks.
Speaker 2: A variable can be a simple string, a number, a list,
Speaker 2: a dictionary, standard data types. You reference them in your
Speaker 2: playbooks using jingjit to templing syntax which looks like double
Speaker 2: kurl braces.
Speaker 1: And where do you define these variables?
Speaker 2: So many places? That's both powerful and sometimes confusing. You
Speaker 2: can define them directly in the playbook using a VARs section.
Speaker 2: You can put them in separate files loaded with varse files.
Speaker 2: You can have dedicated directories like host VARs for variables
Speaker 2: specific to one host, or group VARs for variables shared
Speaker 2: by a group. You can pass them on the command
Speaker 2: line with extra VARs. There's a well defined variable precedence
Speaker 2: order that determines which variable definition wins if the same
Speaker 2: variable name is defined in multiple places. Higher precedence overrides lower.
Speaker 1: Okay, lots of options, but what about sensitive stuff? Passwords,
Speaker 1: API keys. You don't want those sitting in plain text
Speaker 1: in your Git repo.
Speaker 2: Absolutely not for that Ansable provides Ansible Vault. Vault is
Speaker 2: a built in future that lets you encrypt sensitive data
Speaker 2: within your gammle files. You use the ansible Vault create
Speaker 2: command to make a new encrypted file or ansible Vault
Speaker 2: edit to modify one. It prompts you for a password.
Speaker 2: Then when you run your playbook, you provide the vault password,
Speaker 2: either interactively or through other secure means, and ansable decrypts
Speaker 2: the data on the fly just when it needs it.
Speaker 1: But you really need to keep that password.
Speaker 2: It safe, Oh, absolutely critical. The guide emphasizes this. If
Speaker 2: you lose your vault password, your encrypted data is gone.
Speaker 2: There's no recovery mechanism, So manage those passwords carefully.
Speaker 1: Okay. Volts for secrets good. As playbooks get bigger or
Speaker 1: you start doing the same kinds of setups often, how
Speaker 1: do you avoid massive repetitive playbook files? Make things reusable.
Speaker 2: That's where ansable rolls and more recently collections come into play.
Speaker 2: They are all about reusability and structure. A role provides
Speaker 2: a standard directory structure for grouping tasks, variables, file templates, handlers.
Speaker 2: We'll get to those, and even custom modules related to
Speaker 2: a specific well role like setting up a web server
Speaker 2: or configuring a database. You create this self contained unit,
Speaker 2: maybe a Java role or an Enginx role. Then in
Speaker 2: your playbook, instead of listing all the tasks, you just
Speaker 2: say rolls.
Speaker 1: So bundles all the related logic together needly exactly.
Speaker 2: And roles are distributable, you can share them easily. Antsible
Speaker 2: Galaxy is the public hub for sharing and finding roles,
Speaker 2: developed by the community. The ansible Galaxy command line tool
Speaker 2: helps you install and manage roles from Galaxy or other sources.
Speaker 1: And collections are like roles plus plus arns that fair.
Speaker 2: Kind of yeah. Collections are a newer, more flexible way
Speaker 2: to package and distribute ansible content. A collection can bundle
Speaker 2: multiple things roles, yes, but also custom modules, plugins, documentation,
Speaker 2: even entire playbooks. It's a more comprehensive packaging format. You
Speaker 2: often see things like the ansable dot poseis collection, which
Speaker 2: bundles modules and roles for managing common poltestic system things
Speaker 2: like Cylenix, firewalled mounts, et cetera, or Community dot General,
Speaker 2: which has a huge range of modules. They help manage
Speaker 2: dependencies and name spaces better, especially as the ansible ecosystem
Speaker 2: has grown so much.
Speaker 1: Makes sense. So the guide probably shows how to build
Speaker 1: your own roles too.
Speaker 2: Yep, it shows you how to use Ansible Galaxy role
Speaker 2: in it roll name to scaffold the standard directory structure, tasks, VARs, templates, handlers, files,
Speaker 2: meta defaults, and it touches on developing custom modules too.
Speaker 2: Explaining the key Python variables like ansible metadata, documentation, examples
Speaker 2: and return that Ansible uses for self documentation and integration.
Speaker 1: Cool let's shift gears a bit within a playbook. Sometimes
Speaker 1: you need more sophisticated logic than just running tasks sequentially.
Speaker 1: What about things like loops or running tasks only under
Speaker 1: certain conditions.
Speaker 2: Absolutely, Ansable has robust flow control for repetition. You use loops,
Speaker 2: you can iterate over a simple list, say a list
Speaker 2: of software packages to install or usernames to create the
Speaker 2: loop keyword makes this really clean. You can also have
Speaker 2: loops that retry a task if it fails initially. Using
Speaker 2: until retries and delay lets you handle temporary glitches like
Speaker 2: a network kickup or a service that takes a moment
Speaker 2: to start up.
Speaker 1: And making tasks conditional like only run this cast on
Speaker 1: Fedora systems that's.
Speaker 2: Done using conditionals with the when directive you attach when
Speaker 2: clause to a task, role, import or even a whole play.
Speaker 2: The value is a gingitow expression that must evaluate too
Speaker 2: true for the task to run. So you could have
Speaker 2: when answible fact distribution a case of a doora to
Speaker 2: make a task Fedora specific, or when inventory host name
Speaker 2: in groups webservers very flexible.
Speaker 1: Okay, loops retries conditions. What about handlers? You mentioned them
Speaker 1: when talking about rolls. What are they?
Speaker 2: Handlers are like special tasks, but they only run if
Speaker 2: notified by another task. You define a handler, say one
Speaker 2: that restarts the HTTPD service. Then in a task that
Speaker 2: modifies the Apache configuration file hggpd dot com f you
Speaker 2: add a notify restart a patchy directive. If and only
Speaker 2: if that configuration TAC actually makes a change, it notifies
Speaker 2: the restart Apache handler. All the notifications are collected, and
Speaker 2: then at the end of the play ansable runs each
Speaker 2: notified handler once, even if it was notified multiple times.
Speaker 1: Ah, so you don't restart the service unnecessarily only if
Speaker 1: the config actually changed.
Speaker 2: Efficient exactly perfect for service restarts reloading configurations. Things like
Speaker 2: that insures consistency and efficiency.
Speaker 1: Real world automation isn't always smooth sailing though things go wrong?
Speaker 1: How does ansible handle errors?
Speaker 2: Error handling is crucial, and Ansable gives you quite a
Speaker 2: few tools. You can simply tell a task to ignore
Speaker 2: errors true if its failure isn't critical to the overall play.
Speaker 2: Maybe you're trying to remove a file that might not exist.
Speaker 2: You can define custom failure conditions using failed when maybe
Speaker 2: a command return success exit comes zero, but you know
Speaker 2: it actually failed. If certain text isn't present in its
Speaker 2: output failed when lets you check for that? Similarly changed
Speaker 2: when lets you define what constitutes a change for a task,
Speaker 2: overriding the default behavior. For more critical plays, you can
Speaker 2: set any errors fatal true. At the play level. This
Speaker 2: means the first task failure on any host stops the
Speaker 2: entire playbook run immediately, or you could use max fail
Speaker 2: percentage to tolerate a certain percentage of host failures before
Speaker 2: boarding the level of control. Pretty impressive.
Speaker 1: Okay, that covers playbooks in their advanced features. Pretty well,
Speaker 1: Let's talk about common system administration tasks. Managing files must
Speaker 1: be a huge part of this.
Speaker 2: Oh, absolutely. The guide covers a whole suite of modules
Speaker 2: for file and folder management. There's the file module itself
Speaker 2: for setting permissions, ownership, creating directories, deleting things, creating sim links,
Speaker 2: archive and unarchive for handling compressed files like tarballs or zips.
Speaker 2: A symbol is cool It lets you build a configuration
Speaker 2: file from smaller fragments or template parts. Copy you for
Speaker 2: getting files from your control node to the managed nodes.
Speaker 2: Fetch does the reverse pulling files back. Stat checks the
Speaker 2: status of a file like whether it exists, its size, etc.
Speaker 2: Without changing anything, and line and file and block and
Speaker 2: file are really useful for making targeted changes within existing
Speaker 2: configuration files, ensuring a specific line exists, or managing a
Speaker 2: whole block of text.
Speaker 1: Those line block modules sound handy but also potentially fiddly.
Speaker 1: If they can fig files complex or changes.
Speaker 2: Format they can be, and that's why for managing entire
Speaker 2: configuration files, templates are often a much better approach. Templates
Speaker 2: use the Gingitoo templating engine. Just like variables. You create
Speaker 2: a skeleton config file say engine x, dot COMF dot
Speaker 2: J two. Inside you mix static text with ginga two
Speaker 2: placeholders for variables or even logic like loops and conditionals.
Speaker 2: Then you use the template module in your playbook ansable
Speaker 2: reads the dot J two file, processes the GINGA two
Speaker 2: parts using facts and variables available for that host, and
Speaker 2: writes out the final rendered configuration file on the managed node.
Speaker 1: So instead of editing lines, you generate the whole file
Speaker 1: based on variables exactly.
Speaker 2: It avoids maintaining dozens of slightly different config files. You
Speaker 2: have one template and the variables handle the differences between
Speaker 2: dev staging, PROD or different server roles. It's much cleaner
Speaker 2: and less error prone.
Speaker 1: Makes sense. What about managing storage discs partitions? That kind
Speaker 1: of thing?
Speaker 2: Yep, that's covered two. There are modules for managing discs.
Speaker 2: The filesystem module can create filesystems like X two four
Speaker 2: XSA fat be fat on a block device. The mount
Speaker 2: module manages entries and etcetera stab and controls active mount points.
Speaker 2: The parted module lets you configure disc partitions directly, and importantly,
Speaker 2: it covers logical volume management LVM. LVM adds a layer
Speaker 2: of abstraction over physical discs, making storage much more flexible.
Speaker 2: Modules like LVG for volume groups and elvol for logical
Speaker 2: volumes let you manage LVM setups, dynamically resizing volumes, adding discs,
Speaker 2: et cetera. All through ansable.
Speaker 1: Okay, disc management. What about running tasks on a schedule
Speaker 1: like chron jobs.
Speaker 2: Essential sissudmin task right. The ansable dot built in dot
Speaker 2: chron module handles that perfectly. You can use it to add, modify,
Speaker 2: or remove entries in a user's chron tab. Great for
Speaker 2: automating regular maintenance like backups, log rotation, cleaning up temporary files.
Speaker 2: You define the job schedule and command write in your playbook.
Speaker 1: And finally, security always critical.
Speaker 2: How does ansable help There several ways mentioned in the guide.
Speaker 2: For SSH and figuration. You might use line file to
Speaker 2: ensure specific settings are present in sisash dot config like
Speaker 2: setting max authrees, though be careful not to lock yourself out.
Speaker 1: Good warning.
Speaker 2: For managing software sources like YM repositories on red Hat systems,
Speaker 2: there's the RPM key module to import GPG keys for
Speaker 2: verifying package signatures, and the m repository module manages the
Speaker 2: actual repository configuration files in etzm dot repos dot d
Speaker 2: ensuring your systems only pull packages from trusted sources. And
Speaker 2: then there's ceslnux. Managing selenx can be complex, but it's
Speaker 2: crucial for security on many Linux distros. The guide points
Speaker 2: towards using the official Linux system dash rolls dot selnux role,
Speaker 2: which simplifies things. It helps you set the overall state
Speaker 2: enforcing or permissive manage selnicx booleans like allowing web servers
Speaker 2: to connect to the network and handle file security contexts.
Speaker 1: Wow. Okay, so anseble really touches almost every aspect of
Speaker 1: system management. Now you mentioned earlier this idea of ensuring
Speaker 1: automation runs consistently everywhere. Let's circle back to that with execution.
Speaker 2: Environment right, Execution environments or ease. These are really central
Speaker 2: to modern Ansible usage, especially with tools like Ansible Automation Platform,
Speaker 2: but also valuable for anyone wanting consistency. They solve that
Speaker 2: classic it works on my machine problem how by packaging
Speaker 2: everything your automation needs into a container image, everything like
Speaker 2: what ansable core itself, the Ansible Runner tool which executes playbooks,
Speaker 2: the correct Python version, any Python libraries, your modules depend
Speaker 2: on the Ansible collections you're using, like ansable, dot poseis
Speaker 2: and even underlying OS packages if needed. It creates a
Speaker 2: self contained, predictable run time.
Speaker 1: And how do you build these ees? Manually? Craft a
Speaker 1: Docker file?
Speaker 2: You could, but there's a dedicated tool called Ansible builder
Speaker 2: that makes it much easier. You define the components you
Speaker 2: need base image collections, Python requirements, system packages, and EAML
Speaker 2: file typically execution dash environment dot EML. Then you run
Speaker 2: ansable builder build and it generates the necessary container file
Speaker 2: or Docker file and builds the container image for you
Speaker 2: using tools like Podman or Docker. The result is a
Speaker 2: portable e image that guarantees your automation runs the same
Speaker 2: way wherever that image can run.
Speaker 1: Okay, So you have these consistent EES, how do you
Speaker 1: actually use them day to day? Especially for development and
Speaker 1: running playbooks.
Speaker 2: That's the job of automation content navigator, usually just called
Speaker 2: ansable navigator. Think of it as the modern interface for
Speaker 2: interacting with Antsable, especially when using EES. Is both a
Speaker 2: command line tool ansable Navigator run my playbook dot iml,
Speaker 2: and a text based UI TUI you can navigate. When
Speaker 2: you run a playbook with ansable Navigator, it defaults to
Speaker 2: using a specified execution environment as its run time.
Speaker 1: So it runs the playbook inside the containerized EE exactly.
Speaker 2: It ensures you're using the precise versions of ansable collections
Speaker 2: and dependencies defined in that EE. The TUI is also
Speaker 2: great for exploring. You can browse your inventory, look at
Speaker 2: the configuration, view detailed output from playbook runs, even look
Speaker 2: up module documentation, all within the context of the EE.
Speaker 2: It's really become the standard way to develop, test and
Speaker 2: run ansable automation consistently, and it's a key part of
Speaker 2: that rhce X two ninety four exam we talked about earlier.
Speaker 2: You need to be comfortable using Navigator.
Speaker 1: What an incredible journey through ansable seriously, from understanding why
Speaker 1: it matters that agentless approach, the power of idempotency through
Speaker 1: building blocks like inventory and ad hoc commands, the core
Speaker 1: strength of playbooks, making things reusable with roles and collections,
Speaker 1: managing errors, handling files, disc security. Although these modern concepts
Speaker 1: like execution environments and Navigator insuring consistency, you listening should
Speaker 1: now have a really solid grasp on how ansible teams
Speaker 1: it complexity, that you manage infrastructure as code, and yeah,
Speaker 1: maybe even gives your career boost in this whole DevOps world.
Speaker 2: Definitely. The authors Alex Odebueno and Andrew Block really drive
Speaker 2: home that ansable is, and I think they freeze it
Speaker 2: nicely one of the most powerful yet accessible automation tools available.
Speaker 2: Their guide truly helps unlock that potential.
Speaker 1: So, reflecting on all this, what does it mean for you?
Speaker 1: Think about ID and see again. How could truly internalizing
Speaker 1: that concept knowing your automation will achieve the same state
Speaker 1: safely every time change how you approach say patging or
Speaker 1: configuration updates across dozens, maybe hundreds of servers, could it
Speaker 1: remove some of that fear associated with large scale changes?
Speaker 1: Or consider execution environments. If your team could package and
Speaker 1: share automation that always runs predictably, regardless of individual setups
Speaker 1: or CICD infrastructure nuances, how would that impact your deployment
Speaker 1: speed and reliability? What new possibilities might that open up?
Speaker 1: Something to mull over till next time. Keep digging deeper