cleaned up linting and added AAP on Code ready
This commit is contained in:
77
old-demo-repository/docs/contribute.md
Normal file
77
old-demo-repository/docs/contribute.md
Normal file
@@ -0,0 +1,77 @@
|
||||
# Contribute
|
||||
|
||||
So you want to create a demo? What do you do? These demos are considered "demos as code" so every demo must adhere to our standards and be highly re-usable.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Must work with Ansible Tower / Ansible Automation Platform. There has to be a UX component to the demo.
|
||||
- Must be ephemeral and require no service that cannot be reproduced in an automated fashion. This means a demo that requires the user to create a personalized token with an external service (e.g. ServiceNow, Slack) is not appropriate here because it would require manual steps for a user to recreate your demo.
|
||||
- Must align with Red Hat use-cases. A demo that programs your lawn mower is not something we would actually demonstrate. You can easily create a fork of this repo and make your own fun project.
|
||||
|
||||
You need **three** major components to get a demo accepted
|
||||
|
||||
## 1. Demo var file
|
||||
|
||||
In the principle of "everything as code", these are "demos as code". Each demo has its own individual var file. All var files are installed under:
|
||||
|
||||
```shell
|
||||
/roles/install_demo/vars/main
|
||||
```
|
||||
|
||||
There are four categories of demos:
|
||||
|
||||
1. **infrastructure** - automation for IT infrastructure such as Linux and Windows.
|
||||
2. **network** - automation for network infrastructure such as routers and switches.
|
||||
3. **security** - automation for SIEMs, firewalls, and IPS such as IBM Qradar, Splunk and Checkpoint.
|
||||
4. **developer** - automation for developer persona, such as CI/CD pipelines, web hooks, developer environments and automated testing
|
||||
|
||||
Look at a very specific example here: `deploy_application.yml`
|
||||
|
||||
Location: `roles/install_demo/vars/main/infrastructure/deploy_application.yml`
|
||||
Link: [https://github.com/ansible/product-demos/blob/master/roles/install_demo/vars/main/infrastructure/deploy_application.yml](https://github.com/ansible/product-demos/blob/master/roles/install_demo/vars/main/infrastructure/deploy_application.yml)
|
||||
|
||||
## 2. Ansible Playbook
|
||||
|
||||
In the demo var file above you will notice a `playbook` line. For example in the `deploy_application.yml` example:
|
||||
|
||||
`playbook: "playbooks/infrastructure/deploy_application.yml"`
|
||||
|
||||
There is also a **project** section of the demo var file
|
||||
|
||||
```yml
|
||||
project:
|
||||
name: "Ansible official demo project"
|
||||
description: "prescriptive demos from Red Hat Management Business Unit"
|
||||
organization: "Default"
|
||||
scm_type: git
|
||||
scm_url: "https://github.com/ansible/product-demos"
|
||||
```
|
||||
|
||||
The Ansible Playbook **does NOT** have to exist in this repo. In fact it is encouraged to fork this repo and test it out by pointing to your own repo. It is also recommended to create Ansible Playbooks that work on the [Ansible Automation Workshop](https://github.com/ansible/workshops) topologies. This makes them extremely re-usable.
|
||||
|
||||
## 3. Walkthrough
|
||||
|
||||
Each demo should have a walkthrough. In the demo var file there is a line with the key `readme`. For example for the `deploy_application.yml`:
|
||||
|
||||
```yml
|
||||
readme: "https://github.com/ansible/product-demos/blob/master/docs/infrastructure/deploy_application.md"
|
||||
```
|
||||
|
||||
Here is an example walkthrough for the `deploy_application.yml` demo: [https://github.com/ansible/product-demos/blob/master/docs/infrastructure/deploy_application.md](https://github.com/ansible/product-demos/blob/master/docs/infrastructure/deploy_application.md)
|
||||
|
||||
## Converting Existing Workflows into ephemeral demos
|
||||
|
||||
There is no way in the Ansible Tower API to access the workflow schema at this time (March 2020). Please refer to the docs and use the awx-cli/tower-cli command to export existing Workflow schema: [https://github.com/ansible/tower-cli/blob/master/docs/source/cli_ref/usage/WORKFLOWS.rst](documentation).
|
||||
|
||||
The Workflow schema can be automated by using the [tower_workflow_template](https://docs.ansible.com/ansible/latest/modules/tower_workflow_template_module.html#parameter-schema) module to load Ansible Tower with an entire Workflow.
|
||||
|
||||
## update May 2020
|
||||
|
||||
The [awx.awx collection](https://galaxy.ansible.com/awx/awx) has some new enhancements to allow installation of Ansible workflows Please coordinate with Ansible API team if you need help.
|
||||
|
||||
## Going Further
|
||||
|
||||
The following links will be helpful if you want to contribute code to the Ansible Workshops project, or any Ansible project:
|
||||
|
||||
- [Ansible Committer Guidelines](http://docs.ansible.com/ansible/latest/committer_guidelines.html)
|
||||
- [Learning Git](https://git-scm.com/book/en/v2)
|
||||
6
old-demo-repository/docs/features.md
Normal file
6
old-demo-repository/docs/features.md
Normal file
@@ -0,0 +1,6 @@
|
||||
# Red Hat Ansible Automation Platform Features
|
||||
|
||||
| Feature | How? | Long Description | Product Documentation |
|
||||
| ------- | ---- | ---------------- | --------------------- |
|
||||
|Push button deployment| Ansible Platform UI| The Ansible Automation Platform provides a intuitive web user-interface. This can be locked down so that only certain individuals or groups can launch Jobs on specific inventory. This allows automation to have guard rails on who can automate what. Users don't have to be an Ansible Playbook writers to launch and use automation. | [Docs Link](https://docs.ansible.com/ansible-tower/latest/html/userguide/overview.html#push-button-automation)|
|
||||
| Self Service IT| Surveys | Ansible Automation Platform `surveys` allow simple prompts to guide automation. For example a user can choose one application they want to install on their inventory from a pre-defined list. Surveys are fully customizable by administrators for that specific Job.| [Docs Link](https://docs.ansible.com/ansible-tower/latest/html/userguide/job_templates.html#surveys)|
|
||||
107
old-demo-repository/docs/infrastructure/aws_provision_vm.md
Normal file
107
old-demo-repository/docs/infrastructure/aws_provision_vm.md
Normal file
@@ -0,0 +1,107 @@
|
||||
# Demo: AMS Provision VM
|
||||
|
||||
[Click here to return to master demo list](../../README.md#demo-repository)
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Demo: AMS Provision VM](#demo-ams-provision-vm)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Objective](#objective)
|
||||
- [What business problem is solved?](#what-business-problem-is-solved)
|
||||
- [Features show cased](#features-show-cased)
|
||||
- [Video](#video)
|
||||
- [Installing Demo](#installing-demo)
|
||||
- [Guide](#guide)
|
||||
|
||||
## Objective
|
||||
|
||||
Demostrate how anisble can be used to provision a RHEL VM in AWS
|
||||
|
||||
## What business problem is solved?
|
||||
|
||||
- **speed to market**:
|
||||
reducing human time to provision VMs
|
||||
- **reduce human error**:
|
||||
standardize and automation a complex set of steps to reduce human errors
|
||||
- **reduce complexity**:
|
||||
does not require a System Administrator familiar with any cloud provider or its interface in order to provision any resources
|
||||
|
||||
## Features show cased
|
||||
|
||||
- Push button cloud provisioning
|
||||
- Self Service IT - Surveys
|
||||
|
||||
For description of these and other features of the Red Hat Ansible Automation Platform please refer to the [features README](../features.md)
|
||||
|
||||
## Video
|
||||
|
||||
Coming Soon
|
||||
|
||||
## Installing Demo
|
||||
|
||||
1. You will need to create programmatic access keys by following these [AWS Docs instructions](https://docs.aws.amazon.com/general/latest/gr/aws-sec-cred-types.html) See the section called "Programmatic access"
|
||||
|
||||
2. Then set the public_cloud variable to aws. As well as provide the folowing variable values before loading this demo as shown below.
|
||||
|
||||
- public_cloud: aws
|
||||
- my_access_key:
|
||||
- my_secret_key:
|
||||
|
||||
See sample file named choose_demo_example_aws.yml
|
||||
|
||||
## Guide
|
||||
|
||||
1. Login to Ansible Platform UX
|
||||
|
||||
2. Navigate to **Templates**
|
||||
|
||||

|
||||
|
||||
3. Click the rocket next to **INFRASTRUCTURE / AWS Provision VM** to launch the Job
|
||||
|
||||

|
||||
|
||||
4. The survey will prompt you to define the key pair, AWS region, VPC, Instance Type, and name of the new VM.
|
||||
|
||||

|
||||
|
||||
5. Enter values and press **NEXT**
|
||||
|
||||

|
||||
|
||||
Explain to audience what is happening here depending on audience persona
|
||||
|
||||
**Persona A**: Technical audience that has written Ansible Playbooks before:
|
||||
Ansible can be used for more than on prem infrustructure it can also be used to provision many resource on the public clouds. Surveys create variables that the Job can use within Ansible Playbooks. This gives you the ability to create one playbook that can be used for various instance sizes of RHEL provisioned in various AWS regions instead of a job template for each region or VM provisioned. Again saving you time and effort to write seperate playbooks for each use case. In the screenshot you will see the variables are named **keypair**, **aws_region**, **vpc_name**, **instance_type** and **instance_name** with the values of testkey1, us-west-1, testvpc1, t2.micro, demo1
|
||||
|
||||
**Persona B**: Decision maker audience, IT manager or above:
|
||||
reiterate business values above. This allows a non AWS Cloud expert the ability to automate routine tasks within a cloud environment. They can't provision servers that are not vetted and put within the job template or to locations that are not preapproved within the Survey. Freeing them from the mundance and repeative task of VM provisioning while maintaining the highest level of security and compliance across your organization. In the event that your IT process does not allow the Red Hat Ansible Automation Platform to be the front end, it has a rich and powerful API that can work with existing workflows such as ServiceNow.
|
||||
|
||||
6. Execute the job by pressing the green **LAUNCH** button
|
||||
|
||||
7. Explain what is happening:
|
||||
|
||||
- Job has started executed in the background. The user can navigate off this page and the job will continue to execute.
|
||||
- On the left is the **Job Details Pane** labeled simply with **DETAILS**. This information is logged and tells you who, what, when and how.
|
||||
- **who** - who launched the job, in this example is the admin user
|
||||
- **what** - the project and Ansible Playbook used, and which credential to login to the infrastructure
|
||||
- **when** - time stamps for start, end and duration of the job run.
|
||||
- **how** - the job status (pass, fail), enviornment and execution node
|
||||
- The larger window on the right is the **Standard Out Pane**. This provides the same console output the user would be used to on the command-line for troubleshooting purposes. Some important takeways to showcase are:
|
||||
- aggregate info is at the top including the amount of Plays, tasks, hosts and time duration.
|
||||
- this pane can be expanded to take up entire browser window
|
||||
- Ansible Playbook can be downloaded for troubleshooting purposes
|
||||
- **click on task output** to show them task-by-task JSON output that can be used for troubleshooting or just getting additional information
|
||||

|
||||
|
||||
8. Circle back and summarize
|
||||
|
||||
You need to circle back what has been showcased to the [business reasons listed above](#what-business-problem-is-solved). You are welcome to verify on AWS Console that the RHEL server was actually provisioned but unless you have a very technical audience you are going to start losing folks. The real business solution here is automating away the mundane and repetative.
|
||||
|
||||
9. Verify RHEL VM is up (Optional)
|
||||
|
||||
Login to the AWS Console. Navigate to the EC2 service and locate your EC2 instances. You should see the new VM. You can cick on that new VM to see the details which should match how you defined it. Below is an example of what you will see
|
||||

|
||||
|
||||
---
|
||||
You have finished this demo. [Click here to return to master demo list](../../README.md#demo-repository)
|
||||
104
old-demo-repository/docs/infrastructure/azure_mysql_server.md
Normal file
104
old-demo-repository/docs/infrastructure/azure_mysql_server.md
Normal file
@@ -0,0 +1,104 @@
|
||||
# Demo: Azure MySQL Server
|
||||
|
||||
[Click here to return to master demo list](../../README.md#demo-repository)
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Demo: Azure MySQL Server](#demo-azure-mysql-server)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Objective](#objective)
|
||||
- [What business problem is solved?](#what-business-problem-is-solved)
|
||||
- [Features show cased](#features-show-cased)
|
||||
- [Video](#video)
|
||||
- [Installing Demo](#installing-demo)
|
||||
- [Guide](#guide)
|
||||
|
||||
## Objective
|
||||
|
||||
Demostrate how anisble can be used to provision a MySQL server and Database in the Azure Cloud
|
||||
|
||||
## What business problem is solved?
|
||||
|
||||
- **speed to market**:
|
||||
reducing human time to provision a database
|
||||
- **reduce human error**:
|
||||
standardize and automation a complex set of steps to reduce human errors
|
||||
- **reduce complexity**:
|
||||
does not require a System Administrator familiar with any cloud provider or its interface in order to provision any resources
|
||||
|
||||
## Features show cased
|
||||
|
||||
- Push button cloud provisioning
|
||||
- Self Service IT - Surveys
|
||||
|
||||
For description of these and other features of the Red Hat Ansible Automation Platform please refer to the [features README](../features.md)
|
||||
|
||||
## Video
|
||||
|
||||
Coming Soon
|
||||
|
||||
## Installing Demo
|
||||
|
||||
1. You will need to create a Service Principal following these [Azure Docs instructions](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal)
|
||||
|
||||
2. Then set the public_cloud variable to azure. As well as provide the folowing variable values before loading this demo as shown below.
|
||||
|
||||
- public_cloud: azure
|
||||
- my_subscription:
|
||||
- my_tenant:
|
||||
- my_client:
|
||||
- my_secret:
|
||||
|
||||
See sample file named choose_demo_example_azure.yml
|
||||
|
||||
## Guide
|
||||
|
||||
1. Login to Ansible Platform UX
|
||||
|
||||
2. Navigate to **Templates**
|
||||
|
||||

|
||||
|
||||
3. Click the rocket next to **INFRASTRUCTURE / Azure create a MySQL Server** to launch the Job
|
||||
|
||||

|
||||
|
||||
4. The survey will prompt you to define the resource group, Azure region, name MySQL database, and admin login for database.
|
||||
|
||||

|
||||
|
||||
5. Enter values and press **NEXT**
|
||||
|
||||

|
||||
|
||||
Explain to audience what is happening here depending on audience persona
|
||||
|
||||
**Persona A**: Technical audience that has written Ansible Playbooks before:
|
||||
Ansible can be used for more than on prem infrustructure it can also be used to provision many resource on the public clouds. Surveys create variables that the Job can use within Ansible Playbooks. This gives you the ability to create one playbook that can be used for reoccuring database provisioning in various Azure regions instead of a job template for each region or mySQL provisioned. Again saving you time and effort to write seperate playbooks for each use case. In the screenshot you will see the variables are named **resource_group**, **location**, **sqlserver_name**, **admin_pw**, **and adminuser** with the values you entered
|
||||
|
||||
**Persona B**: Decision maker audience, IT manager or above:
|
||||
reiterate business values above. This allows a non Azure Cloud expert the ability to automate routine tasks within a cloud environment. They can't provision servers that are not vetted and put within the job template or to locations that are not preapproved within the Survey. Freeing them from the mundance and repeative task of datebase provisioning while maintaining the highest level of security and compliance across your organization. In the event that your IT process does not allow the Red Hat Ansible Automation Platform to be the front end, it has a rich and powerful API that can work with existing workflows such as ServiceNow.
|
||||
|
||||
6. Execute the job by pressing the green **LAUNCH** button
|
||||
|
||||
7. Explain what is happening:
|
||||
|
||||
- Job has started executed in the background. The user can navigate off this page and the job will continue to execute.
|
||||
- On the left is the **Job Details Pane** labeled simply with **DETAILS**. This information is logged and tells you who, what, when and how.
|
||||
- **who** - who launched the job, in this example is the admin user
|
||||
- **what** - the project and Ansible Playbook used, and which credential to login to the infrastructure
|
||||
- **when** - time stamps for start, end and duration of the job run.
|
||||
- **how** - the job status (pass, fail), enviornment and execution node
|
||||
- The larger window on the right is the **Standard Out Pane**. This provides the same console output the user would be used to on the command-line for troubleshooting purposes. Some important takeways to showcase are:
|
||||
- aggregate info is at the top including the amount of Plays, tasks, hosts and time duration.
|
||||
- this pane can be expanded to take up entire browser window
|
||||
- Ansible Playbook can be downloaded for troubleshooting purposes
|
||||
- **click on task output** to show them task-by-task JSON output that can be used for troubleshooting or just getting additional information
|
||||

|
||||
|
||||
8. Circle back and summarize
|
||||
|
||||
You need to circle back what has been showcased to the [business reasons listed above](#what-business-problem-is-solved). You are welcome to verify on the Azure Portal that the MySQL server database was actually provisioned but unless you have a very technical audience you are going to start losing folks. The real business solution here is automating away the mundane and repetative.
|
||||
|
||||
---
|
||||
You have finished this demo. [Click here to return to master demo list](../../README.md#demo-repository)
|
||||
@@ -0,0 +1,99 @@
|
||||
# Demo: Azure Provision VM
|
||||
|
||||
[Click here to return to master demo list](../../README.md#demo-repository)
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Demo: Azure Provision VM](#demo-azure-provision-vm)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Objective](#objective)
|
||||
- [What business problem is solved?](#what-business-problem-is-solved)
|
||||
- [Features show cased](#features-show-cased)
|
||||
- [Installing Demo](#installing-demo)
|
||||
- [Guide](#guide)
|
||||
|
||||
## Objective
|
||||
|
||||
Demostrate how anisble can be used to provision a RHEL VM in the Azure Cloud
|
||||
|
||||
## What business problem is solved?
|
||||
|
||||
- **speed to market**:
|
||||
reducing human time to provision VMs
|
||||
- **reduce human error**:
|
||||
standardize and automation a complex set of steps to reduce human errors
|
||||
- **reduce complexity**:
|
||||
does not require a System Administrator familiar with any cloud provider or its interface in order to provision any resources
|
||||
|
||||
## Features show cased
|
||||
|
||||
- Push button cloud provisioning
|
||||
- Self Service IT - Surveys
|
||||
|
||||
For description of these and other features of the Red Hat Ansible Automation Platform please refer to the [features README](../features.md)
|
||||
|
||||
## Installing Demo
|
||||
|
||||
1. You will need to create a Service Principal following these [Azure Docs instructions](https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal)
|
||||
|
||||
2. Then set the public_cloud variable to azure. As well as provide the folowing variable values before loading this demo as shown below.
|
||||
|
||||
- public_cloud: azure
|
||||
- my_subscription:
|
||||
- my_tenant:
|
||||
- my_client:
|
||||
- my_secret:
|
||||
|
||||
See sample file named choose_demo_example_azure.yml
|
||||
|
||||
## Guide
|
||||
|
||||
1. Login to Ansible Platform UX
|
||||
|
||||
2. Navigate to **Templates**
|
||||
|
||||

|
||||
|
||||
3. Click the rocket next to **INFRASTRUCTURE / Chocolatey App Install*- to launch the Job
|
||||
|
||||

|
||||
|
||||
4. The survey will prompt you to define the resource group, Azure region, name of the new VM.
|
||||
|
||||

|
||||
|
||||
5. Enter values and press **NEXT**
|
||||
|
||||

|
||||
|
||||
Explain to audience what is happening here depending on audience persona
|
||||
|
||||
**Persona A**: Technical audience that has written Ansible Playbooks before:
|
||||
Ansible can be used for more than on prem infrustructure it can also be used to provision many resource on the public clouds. Surveys create variables that the Job can use within Ansible Playbooks. This gives you the ability to create one playbook that can be used for reoccuring RHEL provisioning in various Azure regions instead of a job template for each region or VM provisioned. Again saving you time and effort to write seperate playbooks for each use case. In the screenshot you will see the variables are named **resource_group**, **location**, and **vm_name*- with the values of testdemorg7, eastus, and test-server07.
|
||||
|
||||
**Persona B**: Decision maker audience, IT manager or above:
|
||||
reiterate business values above. This allows a non Azure Cloud expert the ability to automate routine tasks within a cloud environment. They can't provision servers that are not vetted and put within the job template or to locations that are not preapproved within the Survey. Freeing them from the mundance and repeative task of VM provisioning while maintaining the highest level of security and compliance across your organization. In the event that your IT process does not allow the Red Hat Ansible Automation Platform to be the front end, it has a rich and powerful API that can work with existing workflows such as ServiceNow.
|
||||
|
||||
6. Execute the job by pressing the green **LAUNCH*- button
|
||||
|
||||
7. Explain what is happening:
|
||||
|
||||
- Job has started executed in the background. The user can navigate off this page and the job will continue to execute.
|
||||
- On the left is the **Job Details Pane*- labeled simply with **DETAILS**. This information is logged and tells you who, what, when and how.
|
||||
- **who*- - who launched the job, in this example is the admin user
|
||||
- **what*- - the project and Ansible Playbook used, and which credential to login to the infrastructure
|
||||
- **when*- - time stamps for start, end and duration of the job run.
|
||||
- **how*- - the job status (pass, fail), enviornment and execution node
|
||||
- The larger window on the right is the **Standard Out Pane**. This provides the same console output the user would be used to on the command-line for troubleshooting purposes. Some important takeways to showcase are:
|
||||
- aggregate info is at the top including the amount of Plays, tasks, hosts and time duration.
|
||||
- this pane can be expanded to take up entire browser window
|
||||
- Ansible Playbook can be downloaded for troubleshooting purposes
|
||||
- **click on task output*- to show them task-by-task JSON output that can be used for troubleshooting or just getting additional information
|
||||

|
||||
|
||||
8. Circle back and summarize
|
||||
|
||||
You need to circle back what has been showcased to the [business reasons listed above](#what-business-problem-is-solved). You are welcome to verify on the Azure Portal that the RHEL server was actually provisioned but unless you have a very technical audience you are going to start losing folks. The real business solution here is automating away the mundane and repetative.
|
||||
|
||||
---
|
||||
You have finished this demo. [Click here to return to master demo list](../../README.md#demo-repository)
|
||||
@@ -0,0 +1,74 @@
|
||||
# Demo: Chocolatey App Install
|
||||
|
||||
[Click here to return to master demo list](../../README.md#demo-repository)
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Demo: Chocolatey App Install](#demo-chocolatey-app-install)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Features show cased](#features-show-cased)
|
||||
- [Video](#video)
|
||||
- [Guide](#guide)
|
||||
|
||||
## Features show cased
|
||||
|
||||
- Push button deployment
|
||||
- Self Service IT - Surveys
|
||||
|
||||
For description of these and other features of the Red Hat Ansible Automation Platform please refer to the [features README](../features.md)
|
||||
|
||||
## Video
|
||||
|
||||
[Chocolatey Install App Packages Video Demo](https://www.youtube.com/watch?v=6OIgqaMBnfU&list=PLdu06OJoEf2bnEaWYY0DXF90KkyqjVqOF)
|
||||
|
||||
## Guide
|
||||
|
||||
1. Login to Ansible Platform UX
|
||||
|
||||
2. Navigate to **Templates**
|
||||
|
||||

|
||||
|
||||
3. Click the rocket next to **INFRASTRUCTURE / Chocolatey App Install** to launch the Job
|
||||
|
||||

|
||||
|
||||
4. The survey will prompt you to install or remove a package.
|
||||
|
||||

|
||||
|
||||
5. Choose a package or packages and press **NEXT**
|
||||
|
||||

|
||||
|
||||
Explain to audience what is happening here depending on audience persona
|
||||
|
||||
**Persona A**: Technical audience that has written Ansible Playbooks before:
|
||||
Surveys create variables that the Job can use within Ansible Playbooks. This gives you the ability to create one playbook that can be used for multiple installs instead of a job template for each app. In this case due to the multiple Select option you are not limited to 1 app but can select and install 2 or more apps at once. The survey also gives you the ability to select if the app will be installed, removed, or simply updated to the latest version. Again saving you time and effort to write seperate playbooks for each use case. In the screenshot you will see the variables are named **choco_package** and **app_state** with values of **git** and **present**
|
||||
|
||||
**Persona B**: Decision maker audience, IT manager or above:
|
||||
reiterate business values above. This allows a non subject matter expert the ability to automate routine tasks within a Windows environment. They can't install applications that are not vetted and put within the survey. Freeing them from the mundance and repeative task for application installation while maintaining the highest level of security and compliance across your organization. In the event that your IT process does not allow the Red Hat Ansible Automation Platform to be the front end, it has a rich and powerful API that can work with existing workflows such as ServiceNow.
|
||||
|
||||
6. Execute the job by pressing the green **LAUNCH** button
|
||||
|
||||
7. Explain what is happening:
|
||||
|
||||
- Job has started executed in the background. The user can navigate off this page and the job will continue to execute.
|
||||
- On the left is the **Job Details Pane** labeled simply with **DETAILS**. This information is logged and tells you who, what, when and how.
|
||||
- **who** - who launched the job, in this example is the admin user
|
||||
- **what** - the project and Ansible Playbook used, and which credential to login to the infrastructure
|
||||
- **when** - time stamps for start, end and duration of the job run.
|
||||
- **how** - the job status (pass, fail), enviornment and execution node
|
||||
- The larger window on the right is the **Standard Out Pane**. This provides the same console output the user would be used to on the command-line for troubleshooting purposes. Some important takeways to showcase are:
|
||||
- aggregate info is at the top including the amount of Plays, tasks, hosts and time duration.
|
||||
- this pane can be expanded to take up entire browser window
|
||||
- Ansible Playbook can be downloaded for troubleshooting purposes
|
||||
- **click on task output** to show them task-by-task JSON output that can be used for troubleshooting or just getting additional information
|
||||

|
||||
|
||||
8. Circle back and summarize
|
||||
|
||||
You need to circle back what has been showcased to the [business reasons listed above](#what-business-problem-is-solved). You are welcome to verify on the Windows hosts that the package(s) was actually installed but unless you have a very technical audience you are going to start losing folks. The real business solution here is automating away the mundane and repetative.
|
||||
|
||||
---
|
||||
You have finished this demo. [Click here to return to master demo list](../../README.md#demo-repository)
|
||||
89
old-demo-repository/docs/infrastructure/chocolatey_config.md
Normal file
89
old-demo-repository/docs/infrastructure/chocolatey_config.md
Normal file
@@ -0,0 +1,89 @@
|
||||
# Demo: Chocolatey Config
|
||||
|
||||
[Click here to return to master demo list](../../README.md#demo-repository)
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Demo: Chocolatey Config](#demo-chocolatey-config)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Objective](#objective)
|
||||
- [What business problem is solved?](#what-business-problem-is-solved)
|
||||
- [Features show cased](#features-show-cased)
|
||||
- [Guide](#guide)
|
||||
|
||||
## Objective
|
||||
|
||||
Demostrate how Anisble can be used not only to enable or disable Chocolatey configuration parameters but to set specifc values for those parameters
|
||||
|
||||
## What business problem is solved?
|
||||
|
||||
- **Operational Efficiency**:
|
||||
Ansible provides the ability to save dozen to hundreds of hours of reconfiguration work by systems admins through the configuration automation
|
||||
- **Increase Compliance**:
|
||||
Ansible provides the means to get and stay in compliance throughout all your systems
|
||||
|
||||
## Features show cased
|
||||
|
||||
- Configuration as code
|
||||
- Self Service IT - Surveys
|
||||
|
||||
For description of these and other features of the Red Hat Ansible Automation Platform please refer to the [features README](../features.md)
|
||||
|
||||
## Guide
|
||||
|
||||
1. Login to Ansible Platform UX
|
||||
|
||||
2. Navigate to **Templates**
|
||||
|
||||

|
||||
|
||||
3. Click the rocket next to **INFRASTRUCTURE / Chocolatey Features Config** to launch the Job
|
||||
|
||||

|
||||
|
||||
4. The survey will prompt you with 3 questions. What Parameter you want to change, whether you want to make it present or absent in the config, and the value for that paramater.
|
||||
|
||||

|
||||
|
||||
5. Choose a parameter. Select if you want to make it present or absent in the config. Finally, add the value for that parameter and press **NEXT**
|
||||
Note: These are just a few of the parameters they can add to the list. For these 3 see below for correct format for response.
|
||||
|
||||
- **proxyUser** single text line such as drojas or student25
|
||||
- **commandExecutionTimeoutSeconds** integer value. 0 is infinite, 2700 is default, recomendation is 14400
|
||||
- **cacheLocation** text of a path to location on windows node such as c:\chocolatey_temp2
|
||||
|
||||
For more info on possible parameter see [Chocolatey Documentation](https://chocolatey.org/docs/chocolatey-configuration)
|
||||
|
||||

|
||||
|
||||
Explain to audience what is happening here depending on audience persona
|
||||
|
||||
**Persona A**: Technical audience that has written Ansible Playbooks before:
|
||||
Surveys create variables that the Job can use within Ansible Playbooks. This gives you the ability to create one playbook that can be used to enable or disable and set configuration values instead of having to create or maintain many job templates. Again saving you time and effort to write seperate playbooks for each use case. In the screenshot you will see the variables are named **config-item**, **state**, and **value** with values of **cacheLocation**, **present**, and **c:\chocolatey_temp2**. These will be treated as extra vars and as such overirde any variables from any other source such as the playbook itself
|
||||
|
||||
**Persona B**: Decision maker audience, IT manager or above:
|
||||
reiterate business values above. This allows a systems admin to automate the reconfiguration of Chocolatey in a low risk repeatable manner. This will free up IT staff for larger more mission critical projects all while reducing risk to your production operations. In the event that your IT process does not allow the Red Hat Ansible Automation Platform to be the front end, it has a rich and powerful API that can work with existing workflows such as ServiceNow.
|
||||
|
||||
6. Execute the job by pressing the green **LAUNCH** button
|
||||
|
||||
7. Explain what is happening:
|
||||
|
||||
- Job has started executed in the background. The user can navigate off this page and the job will continue to execute.
|
||||
- On the left is the **Job Details Pane** labeled simply with **DETAILS**. This information is logged and tells you who, what, when and how.
|
||||
- **who** - who launched the job, in this example is the admin user
|
||||
- **what** - the project and Ansible Playbook used, and which credential to login to the infrastructure
|
||||
- **when** - time stamps for start, end and duration of the job run.
|
||||
- **how** - the job status (pass, fail), enviornment and execution node
|
||||
- The larger window on the right is the **Standard Out Pane**. This provides the same console output the user would be used to on the command-line for troubleshooting purposes. Some important takeways to showcase are:
|
||||
- aggregate info is at the top including the amount of Plays, tasks, hosts and time duration.
|
||||
- this pane can be expanded to take up entire browser window
|
||||
- Ansible Playbook can be downloaded for troubleshooting purposes
|
||||
- **click on task output** to show them task-by-task JSON output that can be used for troubleshooting or just getting additional information
|
||||

|
||||
|
||||
8. Circle back and summarize
|
||||
|
||||
You need to circle back what has been showcased to the [business reasons listed above](#what-business-problem-is-solved). You are welcome to verify on the Windows hosts that the configuration was actually changed but unless you have a very technical audience you are going to start losing folks. The real business solution here is automating away the mundane and repetative.
|
||||
|
||||
---
|
||||
You have finished this demo. [Click here to return to master demo list](../../README.md#demo-repository)
|
||||
@@ -0,0 +1,82 @@
|
||||
# Demo: Chocolatey Features Config
|
||||
|
||||
[Click here to return to master demo list](../../README.md#demo-repository)
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Demo: Chocolatey Features Config](#demo-chocolatey-features-config)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Objective](#objective)
|
||||
- [What business problem is solved?](#what-business-problem-is-solved)
|
||||
- [Features show cased](#features-show-cased)
|
||||
- [Guide](#guide)
|
||||
|
||||
## Objective
|
||||
|
||||
Demostrate how Anisble can be used to enable or disable features in Chocolatey
|
||||
|
||||
## What business problem is solved?
|
||||
|
||||
- **Operational Efficiency**:
|
||||
Ansible provides the ability to save dozen to hundreds of hours of reconfiguration work by systems admins through the configuration automation
|
||||
- **Increase Compliance**:
|
||||
Ansible provides the means to get and stay in compliance throughout all your systems
|
||||
|
||||
## Features show cased
|
||||
|
||||
- Configuration as code
|
||||
- Self Service IT - Surveys
|
||||
|
||||
For description of these and other features of the Red Hat Ansible Automation Platform please refer to the [features README](../features.md)
|
||||
|
||||
## Guide
|
||||
|
||||
1. Login to Ansible Platform UX
|
||||
|
||||
2. Navigate to **Templates**
|
||||
|
||||

|
||||
|
||||
3. Click the rocket next to **INFRASTRUCTURE / Chocolatey Features Config** to launch the Job
|
||||
|
||||

|
||||
|
||||
4. The survey will prompt you for what feature to enable or disable.
|
||||
|
||||

|
||||
|
||||
5. Choose a feature and press **NEXT**
|
||||
|
||||

|
||||
|
||||
Explain to audience what is happening here depending on audience persona
|
||||
|
||||
**Persona A**: Technical audience that has written Ansible Playbooks before:
|
||||
Surveys create variables that the Job can use within Ansible Playbooks. This gives you the ability to create one playbook that can be used to enable or disable any feature instead of having to create or maintain many job templates. The survey also gives you the ability to select if the feature will be enabled or disabled. Again saving you time and effort to write seperate playbooks for each use case. In the screenshot you will see the variables are named **feature** and **state** with values of **virusCheck** and **enabled**
|
||||
|
||||
**Persona B**: Decision maker audience, IT manager or above:
|
||||
reiterate business values above. This allows a systems admin to automate the reconfiguration of Chocolatey in a low risk repeatable manner. This will free up IT staff for larger more mission critical projects all while reducing risk to your production operations. In the event that your IT process does not allow the Red Hat Ansible Automation Platform to be the front end, it has a rich and powerful API that can work with existing workflows such as ServiceNow.
|
||||
|
||||
6. Execute the job by pressing the green **LAUNCH** button
|
||||
|
||||
7. Explain what is happening:
|
||||
|
||||
- Job has started executed in the background. The user can navigate off this page and the job will continue to execute.
|
||||
- On the left is the **Job Details Pane** labeled simply with **DETAILS**. This information is logged and tells you who, what, when and how.
|
||||
- **who** - who launched the job, in this example is the admin user
|
||||
- **what** - the project and Ansible Playbook used, and which credential to login to the infrastructure
|
||||
- **when** - time stamps for start, end and duration of the job run.
|
||||
- **how** - the job status (pass, fail), enviornment and execution node
|
||||
- The larger window on the right is the **Standard Out Pane**. This provides the same console output the user would be used to on the command-line for troubleshooting purposes. Some important takeways to showcase are:
|
||||
- aggregate info is at the top including the amount of Plays, tasks, hosts and time duration.
|
||||
- this pane can be expanded to take up entire browser window
|
||||
- Ansible Playbook can be downloaded for troubleshooting purposes
|
||||
- **click on task output** to show them task-by-task JSON output that can be used for troubleshooting or just getting additional information
|
||||

|
||||
|
||||
8. Circle back and summarize
|
||||
|
||||
You need to circle back what has been showcased to the [business reasons listed above](#what-business-problem-is-solved). You are welcome to verify on the Windows hosts that the feature was actually enabled or disabled but unless you have a very technical audience you are going to start losing folks. The real business solution here is automating away the mundane and repetative.
|
||||
|
||||
---
|
||||
You have finished this demo. [Click here to return to master demo list](../../README.md#demo-repository)
|
||||
@@ -0,0 +1,91 @@
|
||||
# Demo: Deploy Application
|
||||
|
||||
[Click here to return to master demo list](../../README.md#demo-repository)
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Demo: Deploy Application](#demo-deploy-application)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Objective](#objective)
|
||||
- [What business problem is solved?](#what-business-problem-is-solved)
|
||||
- [Features show cased](#features-show-cased)
|
||||
- [Video](#video)
|
||||
- [Guide](#guide)
|
||||
|
||||
## Objective
|
||||
|
||||
Demonstrate application deployment for Linux systems. This demonstration will install applications on multiple RHEL servers.
|
||||
|
||||
## What business problem is solved?
|
||||
|
||||
- **speed to market**:
|
||||
reducing human time to install applications
|
||||
- **reduce human error**:
|
||||
automation of routine manual processes
|
||||
- **reduce complexity**:
|
||||
does not require a System Administrator familiar with the specific operating system to install the Application. Automate and test once and allow all users access to deploy Ansible Jobs.
|
||||
- **enforce policy**:
|
||||
Ansible creates guard rails on which applications can be deployed and how they are installed on IT infrastructure.
|
||||
|
||||
# Features show cased
|
||||
|
||||
- Push button deployment
|
||||
- Self Service IT - Surveys
|
||||
|
||||
For description of these and other features of the Red Hat Ansible Automation Platform please refer to the [features README](../features.md)
|
||||
|
||||
## Video
|
||||
|
||||
[Watch here](https://youtu.be/pU8ZgSBuEJw)
|
||||
|
||||
## Guide
|
||||
|
||||
1. Login to Ansible Platform UX
|
||||
|
||||
2. Navigate to **Templates**
|
||||
|
||||

|
||||
|
||||
3. Click the rocket next to **INFRASTRUCTURE / Deploy Application** to launch the Job
|
||||
|
||||

|
||||
|
||||
4. The survey will prompt you to install an application.
|
||||
|
||||

|
||||
|
||||
5. Choose an application and press **NEXT**
|
||||
|
||||

|
||||
|
||||
Explain to audience what is happening here depending on audience persona
|
||||
|
||||
**Persona A**: Technical audience that has written Ansible Playbooks before:
|
||||
Surveys create variables that the Job can use within Ansible Playbooks. In this example a pre-defined list of applications that are tested and allowed on IT infrastructure. The variable is named **application** and the value is **httpd** in this screenshot.
|
||||
|
||||
**Persona B**: Decision maker audience, IT manager or above:
|
||||
reiterate business values above. This allows a non subject matter expert the ability to automate routine tasks. They can't install applications that are not vetted and put within the survey. In the event that your IT process does not allow the Red Hat Ansible Automation Platform to be the front end, it has a rich and powerful API that can work with existing workflows such as ServiceNow.
|
||||
|
||||
6. Execute the job by pressing the green **LAUNCH** button
|
||||
|
||||
7. Explain what is happening:
|
||||
|
||||
- Job has started executed in the background. The user can navigate off this page and the job will continue to execute.
|
||||
- On the left is the **Job Details Pane** labeled simply with **DETAILS**. This information is logged and tells you who, what, when and how.
|
||||
- **who** - who launched the job, in this example is the admin user
|
||||
- **what** - the project and Ansible Playbook used, and which credential to login to the infrastructure
|
||||
- **when** - time stamps for start, end and duration of the job run.
|
||||
- **how** - the job status (pass, fail), enviornment and execution node
|
||||
- The larger window on the right is the **Standard Out Pane**. This provides the same console output the user would be used to on the command-line for troubleshooting purposes. Some important takeways to showcase are:
|
||||
- aggregate info is at the top including the amount of Plays, tasks, hosts and time duration.
|
||||
- this pane can be expanded to take up entire browser window
|
||||
- Ansible Playbook can be downloaded for troubleshooting purposes
|
||||
- **click on task output** to show them task-by-task JSON output that can be used for troubleshooting or just getting additional information
|
||||

|
||||
|
||||
8. Circle back and summarize
|
||||
|
||||
You need to circle back what has been showcased to the [business reasons listed above](#what-business-problem-is-solved). You are welcome to verify on the RHEL web nodes that the application was actually installed but unless you have a very technical audience you are going to start losing folks. The real business solution here is automating away the boring and routine.
|
||||
|
||||
---
|
||||
You have finished this demo. [Click here to return to master demo list](../../README.md#demo-repository)
|
||||
@@ -0,0 +1,97 @@
|
||||
# Demo: Windows Use Regedit to update legal notice
|
||||
|
||||
[Click here to return to master demo list](../../README.md#demo-repository)
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Demo: Windows Use Regedit to update legal notice](#demo-windows-use-regedit-to-update-legal-notice)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Objective](#objective)
|
||||
- [What business problem is solved?](#what-business-problem-is-solved)
|
||||
- [Features show cased](#features-show-cased)
|
||||
- [Video](#video)
|
||||
- [Guide](#guide)
|
||||
|
||||
## Objective
|
||||
|
||||
Demostrate how anisble can be used to automate the updating of Windows registry items such as the legal notice enterprise wide witth one simple playbook.
|
||||
|
||||
## What business problem is solved?
|
||||
|
||||
- **speed to production**:
|
||||
reducing human time to make large scale changes across an enterprise
|
||||
- **reduce human error**:
|
||||
automation of routine manual processes
|
||||
- **reduce complexity**:
|
||||
does not require a System Administrator to be familar with Ansible or even regedit. Provides a self services option to make technical changes to 1000's of devices
|
||||
|
||||
## Features show cased
|
||||
|
||||
- Push button deployment
|
||||
- Self Service IT - Surveys
|
||||
|
||||
For description of these and other features of the Red Hat Ansible Automation Platform please refer to the [features README](../features.md)
|
||||
|
||||
## Video
|
||||
|
||||
[Windows Regedit Legal Notice Video Demo](https://www.youtube.com/watch?v=L_S74rdLat8&list=PLdu06OJoEf2bnEaWYY0DXF90KkyqjVqOF&index=2)
|
||||
|
||||
## Guide
|
||||
|
||||
1. Login to Ansible Platform UX
|
||||
|
||||
2. Navigate to **Templates**
|
||||
|
||||

|
||||
|
||||
3. Click the rocket next to **INFRASTRUCTURE / Windows regedit legal notice** to launch the Job
|
||||
|
||||

|
||||
|
||||
4. The survey will prompt you for the title and text of the legal notice.
|
||||
|
||||

|
||||
|
||||
5. Type in the Tile and Text and press **NEXT**
|
||||
|
||||

|
||||
|
||||
Explain to audience what is happening here depending on audience persona
|
||||
|
||||
**Persona A**: Technical audience that has written Ansible Playbooks before:
|
||||
Surveys create variables that the Job can use within Ansible Playbooks. This gives you the ability to create one playbook that can be used for any future updates. In this case you can update the title and test of the legal notice. Again saving you time and effort to modify the playbook directly each time you need to make an update. In the screenshot you will see the variables are named **text_legal_notice** and **title_legal_notice** with some default values but the admin can modify them as they need.
|
||||
|
||||
**Persona B**: Decision maker audience, IT manager or above:
|
||||
reiterate business values above. This allows a non subject matter expert the ability to automate routine tasks within a Windows environment. They can make these changes on all windows devices with one run. Freeing them from the mundance and repeative task for application installation while maintaining the highest level of security and compliance across your organization. They can do all this with little to no risk as no chance of a fat-finger mistake which in regedit can be disasterous. In the event that your IT process does not allow the Red Hat Ansible Automation Platform to be the front end, it has a rich and powerful API that can work with existing workflows such as ServiceNow.
|
||||
|
||||
6. Execute the job by pressing the green **LAUNCH** button
|
||||
|
||||
7. Explain what is happening:
|
||||
|
||||
- Job has started executed in the background. The user can navigate off this page and the job will continue to execute.
|
||||
- On the left is the **Job Details Pane** labeled simply with **DETAILS**. This information is logged and tells you who, what, when and how.
|
||||
- **who** - who launched the job, in this example is the admin user
|
||||
- **what** - the project and Ansible Playbook used, and which credential to login to the infrastructure
|
||||
- **when** - time stamps for start, end and duration of the job run.
|
||||
- **how** - the job status (pass, fail), enviornment and execution node
|
||||
- The larger window on the right is the **Standard Out Pane**. This provides the same console output the user would be used to on the command-line for troubleshooting purposes. Some important takeways to showcase are:
|
||||
- aggregate info is at the top including the amount of Plays, tasks, hosts and time duration.
|
||||
- this pane can be expanded to take up entire browser window
|
||||
- Ansible Playbook can be downloaded for troubleshooting purposes
|
||||
- **click on task output** to show them task-by-task JSON output that can be used for troubleshooting or just getting additional information
|
||||

|
||||
|
||||
8. Circle back and summarize
|
||||
|
||||
You need to circle back what has been showcased to the [business reasons listed above](#what-business-problem-is-solved). You are welcome to verify on the Windows hosts that legal notice was actually changed but unless you have a very technical audience you are going to start losing folks. The real business solution here is automating away the mundane and repetative.
|
||||
|
||||
9. Show new legal notice (optional)
|
||||
|
||||
Using some version of RDP you will need to connect to the windows host. The info needed to connect can be found within "inventories" You will need to navigate to Inventories first. Then click on "workshop inventory". Then click on "hosts". You should see your list of hosts. Click on your windows host which will give you the host IP, the username and the password required to connect via RDP.
|
||||
|
||||

|
||||
|
||||
Once you connect you will see both the title and text first thing. It should match what you updated it to.
|
||||
|
||||
---
|
||||
You have finished this demo. [Click here to return to master demo list](../../README.md#demo-repository)
|
||||
70
old-demo-repository/docs/network/configlet_vtyacl.md
Normal file
70
old-demo-repository/docs/network/configlet_vtyacl.md
Normal file
@@ -0,0 +1,70 @@
|
||||
# Demo: Deploy Application
|
||||
|
||||
[Click here to return to master demo list](../../README.md#demo-repository)
|
||||
|
||||
## Table of Contents
|
||||
|
||||
- [Demo: Deploy Application](#demo-deploy-application)
|
||||
- [Table of Contents](#table-of-contents)
|
||||
- [Objective](#objective)
|
||||
- [What business problem is solved?](#what-business-problem-is-solved)
|
||||
- [Features show cased](#features-show-cased)
|
||||
- [Guide](#guide)
|
||||
|
||||
## Objective
|
||||
|
||||
Demonstrate managing the VTY ACL on a Cisco router.
|
||||
|
||||
## What business problem is solved?
|
||||
|
||||
- **speed to market**:
|
||||
Reduce the time needed to make changes to Cisco configs.
|
||||
- **reduce human error**:
|
||||
Automation of routine manual processes
|
||||
- **reduce complexity**:
|
||||
Allows one Network Engineer to update multiple devices at once. Automate and test once and allow all users access to deploy Ansible Jobs.
|
||||
- **enforce policy**:
|
||||
Ansible ensures every device has the same config.
|
||||
|
||||
## Features show cased
|
||||
|
||||
- Push button deployment
|
||||
|
||||
For description of these and other features of the Red Hat Ansible Automation Platform please refer to the [features README](../features.md)
|
||||
|
||||
## Guide
|
||||
|
||||
1. Verify rtr1 config
|
||||
|
||||
ssh to rtr1 from the workshop bastion and perform a ***show run*** on the router. Verify that there is no VTY ACL on the router.
|
||||
|
||||
2. Login to Ansible Platform UX
|
||||
|
||||
3. Navigate to **Templates**
|
||||
|
||||

|
||||
|
||||
4. Click the rocket next to **Cisco IOS VTY ACL config audit/remediation** to launch the Job
|
||||
|
||||

|
||||
|
||||
5. The job will launch and update the VTY ACL on rtr1.
|
||||
|
||||
6. What is happening:
|
||||
|
||||
- Job has started executed in the background. The user can navigate off this page and the job will continue to execute.
|
||||
- On the left is the **Job Details Pane** labeled simply with **DETAILS**. This information is logged and tells you who, what, when and how.
|
||||
- **who** - who launched the job, in this example is the admin user
|
||||
- **what** - the project and Ansible Playbook used, and which credential to login to the infrastructure
|
||||
- **when** - time stamps for start, end and duration of the job run.
|
||||
- **how** - the job status (pass, fail), environment and execution node
|
||||
- The larger window on the right is the **Standard Out Pane**. This provides the same console output the user would be used to on the command-line for troubleshooting purposes. Some important takeaways to showcase are:
|
||||
- aggregate info is at the top including the amount of Plays, tasks, hosts and time duration.
|
||||
- this pane can be expanded to take up entire browser window
|
||||
- Ansible Playbook can be downloaded for troubleshooting purposes
|
||||
- **click on task output** to show them task-by-task JSON output that can be used for troubleshooting or just getting additional information
|
||||
|
||||
7. ssh to rtr1 and verify the VTY ACL has been changed.
|
||||
|
||||
---
|
||||
You have finished this demo. [Click here to return to master demo list](../../README.md#demo-repository)
|
||||
Reference in New Issue
Block a user