<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Ansible 101 Workshop :: Flywheel Data Labs - Workshops</title>
    <link>http://localhost:8080/ansible_101/index.html</link>
    <description>Description In this workshop you will use Ansible from a terminal hosted in a Coder container to access and modify VMs running in a Nutanix cluster.&#xA;Who should attend Developers Engineers Technical leads Systems Administrators What you will learn The basic use cases for Ansible How to make configuration changes on remote Linux systems A little bit about Gitlab, Coder and containers Introduction to Ansible Automation Platform Prerequisites This workshop can be done entirely through the browser; there are no prerequisites.</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Mon, 08 Jun 2026 10:40:21 -0400</lastBuildDate>
    <atom:link href="http://localhost:8080/ansible_101/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Workshop Environment</title>
      <link>http://localhost:8080/ansible_101/0.env/index.html</link>
      <pubDate>Wed, 03 Jun 2026 10:40:21 -0400</pubDate>
      <guid>http://localhost:8080/ansible_101/0.env/index.html</guid>
      <description>Following is a diagram of the workshop environment:</description>
    </item>
    <item>
      <title>Setup for the Ansible 101 Workshop</title>
      <link>http://localhost:8080/ansible_101/1.setup/index.html</link>
      <pubDate>Wed, 03 Jun 2026 10:40:21 -0400</pubDate>
      <guid>http://localhost:8080/ansible_101/1.setup/index.html</guid>
      <description>In this lab we’ll get connected to the Flywheel Data lab environment and walk through the premise for the workshop. This is typically the hardest part of the workshop, if we can make it through this then it’s all smooth sailing!&#xA;How it works The lab is in a private enclave which is not directly accessible over the Internet. Workshop attendees can connect to specific services using a secure proxy with access controlled by Azure Active Directory.</description>
    </item>
    <item>
      <title>Ansible Setup</title>
      <link>http://localhost:8080/ansible_101/2.ansible_setup/index.html</link>
      <pubDate>Wed, 27 Mar 2024 10:40:21 -0400</pubDate>
      <guid>http://localhost:8080/ansible_101/2.ansible_setup/index.html</guid>
      <description>In this section we will run some initial ansible commands to get setup and explore our environment.&#xA;First, select the Terminal button in coder to launch a terminal.&#xA;This will open a shell terminal within your coder container. Drag the corner of the terminal window to make it bigger.&#xA;You have two choices for viewing/editing files in this lab. You can either edit them from the CLI (vi/vim) or you can use the built-in visual studio code client by selecting the code-server button on the Coder page. All execution of ansible commands will be done through the terminal CLI.</description>
    </item>
    <item>
      <title>Ansible Playbooks</title>
      <link>http://localhost:8080/ansible_101/3.playbooks/index.html</link>
      <pubDate>Fri, 05 Jun 2026 10:40:21 -0400</pubDate>
      <guid>http://localhost:8080/ansible_101/3.playbooks/index.html</guid>
      <description>An Ansible playbook is a YAML-formatted file that defines a series of automation tasks to be executed on one or more managed hosts, allowing administrators to consistently configure systems, deploy applications, and orchestrate infrastructure through repeatable, human-readable automation.&#xA;Core Components of an Ansible Playbook Playbook - The overall YAML file that contains one or more plays. Play - A set of tasks applied to a specified group of hosts. Hosts - The target systems or inventory groups on which the play runs. Tasks - Individual actions executed in sequence, such as installing packages or creating files. Modules - The built-in or custom units of work that tasks invoke (for example, package, service, copy, or user). Variables - User-defined values that make playbooks reusable and customizable. Handlers - Special tasks that run only when notified, typically used to restart services after a configuration change. Roles - A standardized structure for organizing playbooks, tasks, variables, templates, and files into reusable components. Templates - Dynamic configuration files, usually written with Jinja2 syntax, that are rendered with variable values before deployment. Inventory - The list of managed hosts and groups that Ansible targets during execution. Facts - Information automatically gathered about managed hosts, such as operating system, IP addresses, and memory details. Tags - Labels that allow selective execution of specific tasks or plays. Together, these components enable Ansible to automate infrastructure management in a modular, repeatable, and maintainable way.</description>
    </item>
    <item>
      <title>Ansible Advanced Topics</title>
      <link>http://localhost:8080/ansible_101/4.advanced/index.html</link>
      <pubDate>Mon, 08 Jun 2026 10:40:21 -0400</pubDate>
      <guid>http://localhost:8080/ansible_101/4.advanced/index.html</guid>
      <description>So far we’ve covered some of the basics of using ansible to make changes on a target Linux host. In this section we’ll cover slightly more advanced topics that can be useful when using ansible for configuration management.&#xA;The logical progression when starting to use ansible from the command line is to implement a level of governance around who can make changes, track the changes that are made and control access to who can make the changes. Redhat has a product, Ansible Automation Platform (AAP) designed to implement these controls and more. See https://www.redhat.com/en/technologies/management/ansible for more details on the product.</description>
    </item>
  </channel>
</rss>