forked from ansible/workshops
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathansible-networking.html
1144 lines (1090 loc) · 60.9 KB
/
ansible-networking.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!doctype html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
<title>Ansible Networking Workshop</title>
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/reveal.js/3.4.1/css/reveal.css">
<!-- Printing and PDF exports -->
<script>
var link = document.createElement( 'link' );
link.rel = 'stylesheet';
link.type = 'text/css';
link.href = window.location.search.match( /print-pdf/gi ) ? 'https://cdnjs.cloudflare.com/ajax/libs/reveal.js/3.4.1/css/print/pdf.css' : 'https://cdnjs.cloudflare.com/ajax/libs/reveal.js/3.4.1/css/print/paper.css';
document.getElementsByTagName( 'head' )[0].appendChild( link );
</script>
<link rel="stylesheet" href="css/theme/ansible.css">
<!-- Theme used for syntax highlighting of code -->
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/reveal.js/3.4.1/lib/css/zenburn.css">
</head>
<body>
<div class="ans-mark">
<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" viewBox="-449 450 125 125" style="enable-background:new -449 450 125 125;" xml:space="preserve">
<g id="XMLID_3_">
<circle id="XMLID_7_" class="circle" cx="-386.5" cy="512.5" r="62"/>
<path id="XMLID_4_" class="a-mark" d="M-356.9,537.1l-24.7-59.4c-0.7-1.7-2.1-2.6-3.9-2.6c-1.7,0-3.2,0.9-4,2.6l-27.1,65.2h9.2 l10.7-26.9l32,25.9c1.3,1,2.2,1.5,3.4,1.5c2.4,0,4.6-1.8,4.6-4.5C-356.5,538.5-356.6,537.8-356.9,537.1z M-385.4,488.4l16.1,39.6 l-24.2-19L-385.4,488.4z"/>
</g>
</svg>
</div>
<div class="reveal">
<div class="slides">
<section data-state="cover">
<p class="ans-logo"><img src="images/ansible-wordmark-white.svg" width="260" alt="" /></p>
<h1>Ansible Networking Workshop</h1>
<!--p>NAME HERE, TITLE HERE</p>
<p>COMPANY HERE</p-->
</section>
<section data-background-image="images/30years.svg">
</section>
<section>
<h1>What You Will Learn</h1>
<p>Ansible is capable of handling many powerful automation tasks with the flexibility to adapt to many environments and workflows. With Ansible, users can very quickly get up and running to do real work.<br><br></p>
<ul>
<li>What is Ansible and The Ansible Way</li>
<li>Installing Ansible</li>
<li>How Ansible Works and its Key Components</li>
<li>Ad-Hoc Commands</li>
<li>Playbook Basics</li>
<li>Reuse and Redistribution of Ansible Content with Roles</li>
</ul>
<aside class="notes">
<p>This deck is designed to provide students with direct introductory instruction and guidance to beginning to automate with Ansible. It is the starting point for students intent on becoming more proficient with Ansible through other Linklight modules and their own usage.</p>
<p>This deck supports lecture and hands-on forms of presenting this material. </p>
<p>Allow 2 hours to deliver the lecture-based form and 4 hours for stopping to do the workshop assignments. To access the additional slides for delivering the workshops, navigate down when available. </p>
<p>See the <a href="../facilitator/README.md">Ansible Linklight facilitator’s guide</a> for more details on using this deck and it’s associated material.</p>
</aside>
</section>
<section>
<h1>What is Ansible?</h1>
<p>It's a <b>simple automation language</b> that can perfectly describe an IT application infrastructure in Ansible Playbooks.</p>
<p>It's an <b>automation engine</b> that runs Ansible Playbooks.</p>
<p>Ansible Tower is an <b>enterprise framework</b> for controlling, securing and managing your Ansible automation with a <b>UI and RESTful API</b>.</p>
<aside class="notes speaker">
<p>Ansible is an automation platform:
<ul>
<li>Playbooks make up the automation language</li>
<li>The code base is the automation engine.</li>
<li>Ansible Tower manages existing automation</li>
</ul>
</p>
</aside>
</section>
<section data-background-image="images/simple-powerful-agentless-diagram.svg">
<aside class="notes">
<p>Ansible has a number of qualities that make it the most rapidly growing automation platform in the world. </p>
<p><strong>Ansible is simple.</strong> Playbooks are human and machine readable, no special coding skills required – and even people in your IT organization that don’t know Ansible can read an Ansible playbook and understand what’s happening.</p>
<p>This simplicity also means that it’s easy to install and get started to do real work with it quickly – usually in just minutes. </p>
<p>Ansible also works like you think – tasks are always executed in order. All together, the simplicity ensures that you can get started quickly.</p>
<p><strong>Ansible is powerful.</strong> Simplicity is great, but to be really useful, you also need the powerful features that ensure you can model even the most complex of IT workflows.</p>
<p>Ansible is complete automation, able to deploy apps, manage orchestration, and configure the infrastructure, networks, operating systems, and services that you’re already using today. </p>
<p>Together, Ansible’s capabilities allow you to orchestrate the entire application and environment lifecycle, regardless of where It's deployed.</p>
<p><strong>Ansible is Agentless.</strong> Ansible relies on industry-standard and trusted SSH and WinRM protocols to automate. There are no agents or other software to install, and no additional firewall ports to open. With no need to separately stand up a management infrastructure, Ansible further reduces the activation energy required from your team to start automating today.</p>
<p>In a world where IT complexity stymies even the most basic of IT tasks, Ansible provides a much needed respite – and path forward enabling teams to crush productivity-stealing complexity and overhead.</p>
</aisde>
</section>
<section>
<h1>The Ansible Way</h1>
<div style="font-size: 0.75em;"><br>
<p><strong>CROSS PLATFORM</strong> – Linux, Windows, UNIX, Cisco, Juniper, Arista, Cumulus</br>
Agentless support for all major OS variants, physical, virtual, cloud and network</p>
<p><strong>HUMAN READABLE</strong> – YAML</br>
Perfectly describe and document every aspect of your application environment</p>
<p><strong>DYNAMIC INVENTORIES</strong></br>
Capture all the network hosts 100% of the time, regardless of infrastructure, location, etc.</p>
</div>
<aside class="notes">
</aside>
</section>
<section>
<h1>Ansible: The Language of DevOps</h1>
<div style="font-size: 0.75em; text-align:center;">
<img src="images/devops-language-diagram.svg" width="60%" height="60%" style="padding-top: 20px;"/>
<p class="fullwidth"><strong>COMMUNICATION IS THE KEY TO DEVOPS.</strong></p>
<p class="fullwidth">Ansible is the first <strong>automation language</strong><br/>that can be read and written across IT.</p>
</div>
<aside class="notes">
</aside>
</section>
<section>
<h1>Batteries Included</h1>
<p>Ansible comes bundled with hundreds of modules for a wide variety of automation tasks</p>
<div class="columns">
<div class="col">
<ul>
<li>cloud</li>
<li>containers</li>
<li>database</li>
<li>files</li>
<li>messaging</li>
<li>monitoring</li>
</ul>
</div>
<div class="col">
<ul>
<li>networking</li>
<li>notifications</li>
<li>packaging</li>
<li>system</li>
<li>testing</li>
<li>utilities</li>
</ul>
</div>
</div>
<aside notes="notes">
<p>Ansible Modules control the things that you’re automating. They can do everything from acting on system files, installing packages, or making API calls to a service framework.</p>
</aside>
</section>
<section data-background-image="images/most_meetups.svg">
<aside class="notes">
<p>Ansible is open source. Created with contributions from an active open source community and built for the people who use it every day. At its heart, Ansible was made to help more people experience the power of automation so they could work better and faster together.</p>
</aside>
</section>
<section data-background-image="images/most_contrib.svg">
</section>
<section data-background-image="images/most_searched.svg">
</section>
<section data-background-image="images/network_automation.svg">
</section>
<section data-background-image="images/journey.svg">
<aside class="notes">
<p>What can you do with Ansible? Nearly anything. Ansible is the Swiss Army knife of DevOps, capable of handling many powerful automation tasks with the flexibility to adapt to many environments and workflows.</p>
<p>Many folks like to categorize Ansible as a configuration manager, and although yes, Ansible can do that, it"s just the tip of the iceberg. When you couple configuration management with orchestration, you can start to model complicated multi-tier deployments with ease.</p>
<p>With Ansible, once someone on your team automates something, everyone on the team now knows how to do it.</p>
</aside>
</section>
<section data-background-image="images/build.svg">
</section>
<section data-background-image="images/manage.svg">
</section>
<section data-background-image="images/scale.svg">
</section>
<section>
<h1>Installing Ansible</h1>
<pre><code>
# the most common and preferred way of
# installation
$ sudo pip install ansible
# you will need the EPEL repo configured on
# CentOS, RHEL, or Scientific Linux
$ sudo yum install ansible
# you will need the PPA repo configured on
# Debian or Ubuntu
$ sudo apt-get install ansible
</code></pre>
<aside class="notes">
<p>As open source, Ansible is freely-available thru numerous means and can be installed in minutes with only a few requirements that most system already have. The installation methods listed here are the most commonly used.</p>
<p>Currently Ansible can be run from any machine with Python 2.6 or 2.7 installed. Python 3 support is in tech preview as of version 2.2. Windows isn’t supported for the control machine.</p>
<p>The requirements of nodes being managed by Ansible vary based on the type and access used to work with them. Ansible needs a way to communicate, which is normally ssh or winrm though other means such as RESTful APIs and specialized connection types may be necessary. Linux servers will need Python 2.6 or later. Windows serves need PowerShell 3.</p>
<p>For more details see <a href="http://docs.ansible.com/ansible/intro_installation.html">the Installation page</a> in the Ansible documentation.
</aside>
</section>
<section data-state="title alt">
<h1>Demo Time: <br/>Installing Ansible</h1>
<aside class="notes">
<p>To demonstrate how easy it is to install Ansible, open an SSH session to your control host and install ansible using one of the methods in the previous slide. Once complete do a <code>$ ansible --version</code>.</p>
</aside>
</section>
<section>
<h1>How Ansible Works</h1>
<img src="images/how-ansible-works-diagram-01.svg" />
<aside class="notes">
<p>The diagram on this slide shows the relationship between all the key components of Ansible starting with the user who writes an Ansible playbook.</p>
</aside>
</section>
<section>
<h1>Plays & Playbooks</h1>
<img src="images/how-ansible-works-diagram-02.svg" />
<aside class="notes">
<p>Playbooks are written in YAML and are used to invoke Ansible modules to perform tasks that are executed sequentially i.e top to bottom. They can describe a policy you want your remote systems to enforce, or a set of steps in a general IT workflow. Playbooks are like an instruction manual and describe the state of environment.</p>
<p>For more details see <a href="http://docs.ansible.com/ansible/playbooks.html">the Playbook page</a> in the Ansible documentation.</p>
</aside>
</section>
<section>
<h1>Modules & Tasks</h1>
<img src="images/how-ansible-works-diagram-03.svg" />
<aside class="notes">
<p>If playbooks are the instruction manual for setting up and managing your infrastructure, Ansible modules are the tools in your toolkit.</p>
<p>Modules are executable bits of code that operate on hosts; however, we don’t need to understand the underlying implementation to get them to work. Modules do the heavy-lifting in Ansible and abstract users from the complexity of the underlying details.</p>
<p>For more details see the <a href="http://docs.ansible.com/ansible/modules_intro.html">Introduction to Modules</a> and <a href="http://docs.ansible.com/ansible/modules_by_category.html">Module Index</a> page in the Ansible documentation.</p>
</aside>
</section>
<section>
<h1>Plugins</h1>
<img src="images/how-ansible-works-diagram-04.svg" />
<aside class="notes">
<p>Continuing our metaphor, plugins are the gears in the engine.</p>
<p>Plugins are pieces of code that extend Ansible’s core functionality. Ansible ships with a number of handy plugins, and you can easily write your own.</p>
<p>These are some of the more common plugin types:</p>
<ul>
<li>Action plugins manage the execution on the controller and deployment of modules to hosts.</li>
<li>Callback plugins enable you to hook into Ansible events for display or logging purposes.</li>
<li>Connection plugins define how to communicate with inventory hosts.</li>
<li>Filters plugins allow you to manipulate data inside Ansible plays and/or templates. This is a Jinja2 feature; Ansible ships extra filter plugins.</li>
</ul>
<p>For more details see the <a href="http://docs.ansible.com/ansible/dev_guide/developing_plugins.html">Developing Plugins</a> page in the Ansible documentation.</p>
</aside>
</section>
<section>
<h1>Inventory</h1>
<img src="images/networking-how-ansible-works-diagram-05.svg" />
<aside class="notes">
<p>Your inventory of hosts are your raw material. They are a list of nodes and associated meta data that Ansible can automate.</p>
<p>Inventory lists can be built and stored several different ways, including static files, or can be dynamically-generated from an an external source.</p>
<p>You can also specify variables as part of an inventory list. For instance, set a particular host key that’s needed to log into that system remotely. Inventories are ultimately lists of things you want to automate across.</p>
<p>Here in this slide was see an example of a simple static inventory list of three hosts (webserver1, webserver2 and dbserver1) in two groups (web and db).</p>
<p>For more details see the <a href="http://docs.ansible.com/ansible/intro_inventory.html">Inventory</a> page in the Ansible documentation.</p>
</aside>
</section>
<section>
<h1>Inventory</h1>
<img src="images/how-ansible-works-diagram-06.svg" />
<aside class="notes">
<p>In large-scale environment subject to constant change, synchronizing and maintaining inventory statically is tedious and error prone endeavor. That is why Ansible includes support of external sources such as public and private cloud providers and configuration management database (CMDB) systems.</p>
<p>For more details see the <a href="http://docs.ansible.com/ansible/intro_dynamic_inventory.html">Dynamic Inventory</a> page in the Ansible documentation.</p>
</aside>
</section>
<section>
<h1>Modules</h1>
<p>Modules do the actual work in ansible, they are what gets executed in each playbook task. But you can also run a module ad-hoc using the <b>ansible</b> command.</p>
<div class="columns">
<div class="col">
<ul>
<li>*os_facts</li>
<li>*os_command</li>
<li>*os_config</li>
<li>more modules depending on platform</li>
</ul>
</div>
<div class="col">
<ul>
<li>Arista EOS = eos_</li>
<li>Cisco IOS/IOS-XE = ios_</li>
<li>Cisco NX-OS = nxos_</li>
<li>Cisco IOS-XR = iosxr_</li>
<li>Juniper Junos = junos_</li>
<li>VyOS = vyos_</li>
</ul>
</div>
</div>
<aside class="notes">
<p>If playbooks are the instruction manual for setting up and managing your infrastructure, Ansible modules are the tools in your toolkit.</p>
<p>We’ve already discussed, Ansible modules. They are the “batteries” and the “tools in a users toolkit.”</p>
<p>While there are hundreds of modules at your disposal out-of-the-box these are the most common ones.</p>
<p>Playbook tasks and how they relate to modules will be covered ahead. Tasks are the application of a module to perform a specific unit of work.</p>
</aside>
</section>
<section>
<h1>Modules per network platform</h1>
<pre><code data-noescape>
tasks:
- name: configure eos system properties
<mark>eos_system:</mark>
domain_name: ansible.com
vrf: management
when: ansible_network_os == 'eos'
- name: configure nxos system properties
<mark>nxos_system:</mark>
domain_name: ansible.com
vrf: management
when: ansible_network_os == 'nxos'
</code></pre>
</section>
<section>
<h1>Modules Documentation</h1>
<div class="columns">
<div class="col">
<p><strong>http://docs.ansible.com/</strong></p>
</div>
<div class="col">
<img src="images/modules-doc-screenshots.png" />
</div>
</div>
<aside class="notes">
<p><a href="http://docs.ansible.com/ansible/modules_by_category.html">A categorized index of included Ansible modules</a> along with detailed documentation for the requirements, parameters and return values of each Ansible module can be found on the <a href="http://docs.ansible.com/ansible/">Ansible documentation site</a>. </p>
</aside>
</section>
<section>
<h1>Modules Documentation</h1>
<pre><code>
# List out all modules installed
$ ansible-doc -l
...
ios_banner Manage multiline banners on Cisco IOS devices
ios_command Run commands on remote devices running Cisco IOS
ios_config Manage Cisco IOS configuration sections
...
# Read documentation for installed module
$ ansible-doc ios_command
> IOS_COMMAND
Sends arbitrary commands to an ios node and returns the results read from the
device. This module includes an argument that will cause the module to wait for a
specific condition before returning or timing out if the condition is not met. This
module does not support running commands in configuration mode. Please use
[ios_config] to configure IOS devices.
Options (= is mandatory):
...
</code></pre>
<aside class="notes">
<p>Module documentation is also available from the commandline using the <code>ansible-doc</code>.</p>
<p>One noteworthy advantage, of ansible-doc is that it can display any custom module with it's own embedded documentation that you may have added to your Ansible environment.</p>
</aside>
</section>
<section>
<h1>Modules: Run Commands</h1>
<p>If Ansible doesn’t have a module that suits your needs there are the “run command” modules:</p><br>
<ul>
<li><b>command</b>: Takes the command and executes it on the host. The most secure and predictable.</li>
<li><b>ios_command</b>: Sends arbitrary commands to an ios node and returns the results read from the device.</li>
</ul>
<p><br><b>NOTE:</b> Unlike standard modules, run commands have no concept of desired state and should only be used as a last resort.</p>
<aside class="notes">
<p>"Run commands" are what we collectively call these modules that enable users to do commandline operations in different ways. They’re a great catch all mechanism for getting things done, but they should be used sparingly and as a last resort. The reasons are many and varied.</p>
<p>The overuse of run commands is common amongst those just becoming familiar with Ansible for automating their work. They use <code>shell</code> to fire off a bash command they already know without stopping to look at the Ansible docs. That works well enough initially, but it undermines the value of automating with Ansible and sets things up for problems down the road. <b>As a best practice, always check the hundreds of Ansible shipping modules for what you need and use those first and run commands as a last resort.</b></p>
<p><b>NOTE:</b> <code>shell</code> allows for IO redirection such as pipes. This is why It's best practice to use <code>command</code> unless they need to pipe something. It also best practice to <strong>never</strong> pass user input or variables thru a run command.</p>
</aside>
</section>
<section>
<h1>How it works</h1>
<img src="images/local_execution.svg">
</section>
<section>
<h1>Inventory</h1>
<p>Inventory is a collection of hosts (nodes) with associated data and groupings that Ansible can connect and manage.</p>
<ul>
<li>Hosts (nodes)</li>
<li>Groups</li>
<li>Inventory-specific data (variables)</li>
<li>Static or dynamic sources</li>
</ul>
<aside class="notes">
<p>We've already discussed inventory in our review of Ansible's key components.</p>
<p>Inventory consists of hosts, groups, inventory specific data. Inventory can either be static or dynamic.</p>
<p>Inventory is a collection of the hosts (nodes) with associated metadata and groupings that Ansible can connect and manage. An inventory source can be static files or dynamically retreived from an external system.</p>
<p>You can specify a different inventory file using the <code>-i <path></code> option on the commandline or your Ansible configuration file.</p>
</aside>
</section>
<section>
<h1>Static Inventory Example</h1>
This inventory will work but is not human readable.
<pre><code>
10.42.0.2
10.42.0.6
10.42.0.7
10.42.0.8
10.42.0.100
host.example.com
</code></pre>
<aside class="notes">
<p>Static inventory is the easiest source to get started with. This example shows a static inventory source in It’s simplist form – a single file with a list of IP addresses or hostnames.</p>
<p><strong>NOTE:</strong> Ansible infers a localhost is present even if it is not explictly listed. This is why you can actually run Ansible without a inventory source. Ansible will only be able to operate on the localhost where it is being run.</p>
</aside>
</section>
<section>
<h1>Static Inventory Example</h1>
<pre><code>
[all:vars]
ansible_user=lcage
ansible_ssh_pass=ansible
ansible_port=22
[routers]
rtr1 ansible_host=54.174.116.49 ansible_user=ec2-user ansible_network_os=ios
rtr2 ansible_host=54.86.17.101 ansible_user=ec2-user ansible_network_os=ios
[hosts]
host1 ansible_host=34.224.57.27 ansible_user=ec2-user
[control]
ansible ansible_host=34.228.79.198 ansible_user=ec2-user
</code></pre>
<aside class="notes">
<p>The example shown here is a more practical and common example of a static inventory file.</p>
<p>Static inventory files are expressed in INI format. The headings in brackets are group names, which are used in classifying systems and deciding what systems you are controlling at what times and for what purpose. Hosts can belong to multiple groups and groups can be members of other groups. (The latter is not shown here.)</p>
<p>NOTE: This example contains variables, a topic we haven't touched on just yet. We'll go into them on the next slide.</p>
<p>Other noteworthy attributes in our example:</p>
<ul>
<li><code>ansible_host</code> is an example of a host variable.</li>
<li>Hosts can be assigned arbitrary human-meaningful names or aliases such as "control" and "haproxy". Ansible will instead use the value of <code>ansible_host</code> (one of several <a href="http://docs.ansible.com/ansible/playbooks_variables.html#magic-variables-and-how-to-access-information-about-other-hosts">"magic" inventory variables</a>) as the network address to connect.</li>
<li>Static inventory files can support character ranges such as "node-[1:3]"</li>
<li>Like localhost, Ansible infers an "all" group is present. As its name implies, all inventory hosts are memebers of this group.</li>
<li>The heading "all:vars" is an example of group variable assignment using two more "magic" variables, <code>ansible_ssh_private_key_file</code> and <code>ansible_user</code>.</li>
</ul>
<p>This example just covers the basics. There's a lot more to inventory that is not covered here. See the <a href="http://docs.ansible.com/ansible/intro_inventory.html">Ansible inventory documentation</a> for more details.</p>
</aside>
</section>
<section>
<h1>Ad-Hoc Commands</h1>
<p>An ad-hoc command is a single Ansible task to perform quickly, but don’t want to save for later.</p>
<aside class="notes">
<p>Ansible ad-hoc commands is a good place to start to understand the basics of what Ansible can do before learning how to use playbooks – ad-hoc commands can also be used to do quick things that you might not necessarily want to write a full playbook for.</p>
<p>Generally speaking, the true power of Ansible lies in playbooks. So why would you use ad-hoc tasks versus playbooks?</p>
<p>For instance, if you wanted to restart a service on all of your lab nodes, you could execute a quick one-liner in Ansible without writing a playbook.</p>
</aside>
</section>
<section>
<h1>Ad-Hoc Commands: Common Options</h1>
<ul style="font-size: 0.75em;">
<li><b>-m MODULE_NAME, --module-name=MODULE_NAME</b><br/>Module name to execute the ad-hoc command</li>
<li><b>-a MODULE_ARGS, --args=MODULE_ARGS</b><br/>Module arguments for the ad-hoc command</li>
<li><b>-b, --become</b><br/>Run ad-hoc command with elevated rights such as sudo (Linux) or enable (Networking)</li>
<li><b>-e EXTRA_VARS, --extra-vars=EXTRA_VARS</b><br/>Set additional variables as key=value or YAML/JSON</li>
<li><b>--version</b><br/>Display the version of Ansible</li>
<li><b>--help</b><br/>Display the MAN page for the ansible tool</li>
</ul>
<aside class="notes">
<p>This slide shows essential commandline options for running ad-hoc commands that will be useful in our upcoming workshop assignment.</p>
</aside>
</section>
<section>
<h1>Ad-Hoc Commands</h1>
<pre><code>
# check all my inventory hosts are ready to be
# managed by Ansible
$ ansible all -m ping
# collect and display the discovered facts
# for the localhost
$ ansible localhost -m setup
# run the uptime command on all hosts in the
# web group
$ ansible web -m command -a "uptime"
</code></pre>
<aside class="notes">
<p>Ad-hoc commands are quick checks on your servers that you don’t want to preserve in an Ansible playbook.</p>
<p>An ad-hoc command can be used to do some tasks that you might not necessarily want to write a full playbook and save for later.</p>
<p>This is a good place to start to understand the basics of what Ansible can do prior to learning about playbooks where the true power of Ansible automation lies.</p>
<p>For more information see <a href="http://docs.ansible.com/ansible/intro_adhoc.html">Introduction To Ad-Hoc Commands</a>.</p>
</aside>
</section>
<section>
<h1>Sidebar: Discovered Facts</h1>
<p>Facts are bits of information derived from examining a host systems that are stored as variables for later use in a play.</p>
<pre><code>
$ ansible localhost -m setup
localhost | success >> {
"ansible_facts": {
"ansible_default_ipv4": {
"address": "192.168.1.37",
"alias": "wlan0",
"gateway": "192.168.1.1",
"interface": "wlan0",
"macaddress": "c4:85:08:3b:a9:16",
"mtu": 1500,
"netmask": "255.255.255.0",
"network": "192.168.1.0",
"type": "ether"
},
</code></pre>
<aside class="notes">
<p>The second ad-hoc command example from the prior slide provides the following JSON output of a localhost facts run.</p>
<p>Facts are bits of information derived from examining a host systems that are stored as variables for later use. An example of this might be the ip address of the host, or what operating system it is running. The facts Ansible will discover about a host is extensive. What's shown here is just a small sample. Run <code>ansible localhost -m setup</code> for a more complete representation.</p>
<p>Ansible collects facts using the <code>setup</code> module. By default, Ansible will run the <code>setup</code> module before any other tasks are executed in a playbook. These facts can be referenced by subsequent automation tasks on a per host-basis during the playbook run.</p>
</aside>
</section>
<section>
<h1>Sidebar: Network Facts</h1>
<p>For non-Linux systems there are vendor specific modules for fact collection.</p>
<pre><code>
$ ansible -m ios_facts routers -c network_cli
student1-rtr1 | SUCCESS => {
"ansible_facts": {
"ansible_net_all_ipv4_addresses": [
"172.17.1.238"
],
"ansible_net_all_ipv6_addresses": [],
"ansible_net_filesystems": [
"bootflash:"
],
"ansible_net_gather_subset": [
"hardware",
"default",
"interfaces"
],
"ansible_net_hostname": "ip-172-17-1-238",
"ansible_net_image": "bootflash:csr1000v-universalk9.16.05.01b.SPA.bin",
</code></pre>
<aside class="notes">
<p>ios_facts, junos_facts, eos_facts, etc all return JSON just like Linux facts</p>
</aside>
</section>
<section data-state="title alt">
<h1>Demo Time: <br/>Ad-Hoc Commands</h1>
<h3>Exercise 1.1 - Running Ad-hoc commands</h3>
<aside class="notes">
<p>To demonstrate ad-hoc commands in action, open an SSH session to your control host and run the ad-hoc commands in the previous slides.</p>
<pre><code>
$ ansible all -m ping
$ ansible localhost -m setup
$ ansible web -m command -a "uptime"
</code></pre>
</aside>
</section>
<section data-state="title alt">
<h1>Workshop: <br/>Ad-Hoc Commands</h1>
<h3>Exercise 1.1 - Running Ad-hoc commands</h3>
<aside class="notes">
<p>This brief exercise demonstrates Ansible in-action at it's most basic and simple level. Thru ad-hoc commands, students are exposed to Ansible modules and usage and will apply to their understanding of tasks and playbooks. This exercise also begins to expose students to the concepts of Ansible facts and inventory.</p>
<p>This workshop is also a good way to verify their lab environments are properly configured before going forward.</p>
<p>See <code>workshops/adhoc_commands</code> in the Ansible linklight repo.</p>
</aside>
</section>
<section>
<h1>Variables</h1>
<p>Ansible can work with metadata from various sources and manage their context in the form of variables.</p>
<ul>
<li>Command line parameters</li>
<li>Plays and tasks</li>
<li>Files</li>
<li>Inventory</li>
<li>Discovered facts</li>
<li>Roles</li>
</ul>
<aside class="notes">
<p>While automation exists to make it easier to make things repeatable, all of your systems are not exactly alike.</p>
<p>Variables are used to store metadata for each host drawing from numerous sources. For example variable may be for things like facts or file paths or package versions.</p>
</aside>
</section>
<section>
<h1>Variable Precedence</h1>
<p>The order in which the same variable from different sources will override each other.</p>
<div class="columns">
<div class="col">
<ol>
<li>extra vars</li>
<li>task vars (only for the task)</li>
<li>block vars (only for tasks in block)</li>
<li>role and include vars</li>
<li>play vars_files</li>
<li>play vars_prompt</li>
<li>play vars</li>
<li>set_facts</li>
</ol>
</div>
<div class="col">
<ol start="9" class="col">
<li>registered vars</li>
<li>host facts</li>
<li>playbook host_vars</li>
<li>playbook group_vars</li>
<li><strong>inventory host_vars</strong></li>
<li><strong>inventory group_vars</strong></li>
<li>inventory vars</li>
<li>role defaults</li>
</ol>
</div>
</div>
<aside class="notes">
<p>If variables of the same name are defined in multiple sources, they get overwritten in a certain and specific order. This is why this variable precedence is important to understand.</p>
<p>There are 16 levels of variable precedence as of Ansible 2.x. The <code>extra_vars</code> (passed thru the commandline) always take precedence vs. role defaults which will always get overridden by any other source. The previous inventory example defines vars at 13 and 14 (higlighted in the list) in the variable precedence chain.</p>
<p>It's a good idea to limit the different sources where a specific variable is being set. While Ansible's variable precedence handling is comprehensive and well-defined, it can laborious to keep the resolution of multiple sources straight.</p>
<p>NOTE: The inventory variables sources showed in the static inventory example a couple of slides back are in bold type.</p>
</aside>
</section>
<section>
<h1>Tasks</h1>
<p>Tasks are the application of a module to perform a specific unit of work.</p>
<ul>
<li><b>file</b>: A directory should exist</li>
<li><b>yum</b>: A package should be installed</li>
</ul>
<p>There are also tasks for network devices as well</p>
<ul>
<li><b>ios_facts</b>: collect the version of code running on Cisco IOS/IOS-XE</li>
<li><b>ios_system</b>: configure DNS server(s) on Cisco IOS/IOS-XE</li>
<li><b>nxos_snmp_user</b>: add an SNMP user on Cisco NX-OS</li>
<li><b>eos_command</b>: turn off a port on Arista EOS</li>
<li><b>junos_banner</b>: manage the banner on Juniper Junos OS</li>
</ul>
<aside class="notes">
<p>We've already reviewed modules, the batteries and tools Ansible provides. Tasks are the specific application of a module to perform a unit of automation.</p>
<p>Here we see a list of examples of common modules being applied to do something.</p>
<aside>
</section>
<section>
<h1>Example Tasks in a Play</h1>
<pre><code>
tasks:
- name: gather ios_facts
ios_facts:
register: version
- debug:
msg: "{{version}}"
- name: Backup configuration
ios_config:
backup: yes
</code></pre>
<aside class="notes">
<p>This example shows the task list of an Ansible playbook.</p>
</aside>
</section>
<section>
<h1>Plays & Playbooks</h1>
<p>Plays are ordered sets of tasks to execute against host selections from your inventory. A playbook is a file containing one or more plays.</p>
<aside class="notes">
<p>Playbooks are text files that contain one or more plays that are expressed in YAML. A play defines target hosts and a task list that are executed sequentially (i.e top to bottom) to achieve a certain state on those hosts.</p>
<p>For more details see <a href="http://docs.ansible.com/ansible/playbooks.html">the Playbook page</a> in the Ansible documentation.</p>
</aside>
</section>
<section>
<h1>Playbook Example</h1>
<pre><code data-noescape>
---
- name: backup router configurations
hosts: routers
connection: network_cli
gather_facts: no
tasks:
- name: gather ios_facts
ios_facts:
register: version
- debug:
msg: "{{version}}"
- name: Backup configuration
ios_config:
backup: yes
</code></pre>
<aside class="notes">
<p>Here we can see an example of a simple but complete Ansible play. The slides that follow will explore each of these parts and what they do.</p>
</aside>
</section>
<section>
<h1>Human-Meaningful Naming</h1>
<pre><code data-noescape>
---
- <mark>name: backup router configurations</mark>
hosts: routers
connection: network_cli
gather_facts: no
tasks:
- <mark>name: gather ios_facts</mark>
ios_facts:
register: version
- debug:
msg: "{{version}}"
- <mark>name: Backup configuration</mark>
ios_config:
backup: yes
</code></pre>
<aside class="notes">
<p>Every play and each task in it can be assigned a name that describes its objective in the automation workflow and is output during execution.</p>
<p>It's best practice to always name your plays and tasks. Adding name with a human-meaningful description better communicates the intent to users when running a play.</p>
</aside>
</section>
<section>
<h1>Host Selector</h1>
<pre><code data-noescape>
---
- name: backup router configurations
<mark>hosts: routers</mark>
connection: network_cli
gather_facts: no
tasks:
- name: gather ios_facts
ios_facts:
register: version
- debug:
msg: "{{version}}"
- name: Backup configuration
ios_config:
backup: yes
</code></pre>
<aside class="notes">
<p>The Ansible play host selector defines which nodes in the inventory the automation is targetting.</p>
<p>In this example, a single group of "web" is being targetted. Ansible supports targetting intersections, unions and filters of multiple groups or hosts though.</p>
<p>For more details see <a href="http://docs.ansible.com/ansible/intro_patterns.html">the host selector Patterns page</a> in the Ansible documentation.</p>
</aside>
</section>
<section>
<h1>Tasks</h1>
<pre><code data-noescape>
---
- name: backup router configurations
hosts: routers
connection: network_cli
gather_facts: no
tasks:
- name: gather ios_facts
<mark>ios_facts:</mark>
<mark>register: version</mark>
- <mark>debug:</mark>
<mark>msg: "{{version}}"</mark>
- name: Backup configuration
<mark>ios_config:</mark>
<mark>backup: yes</mark>
</code></pre>
</section>
<section data-state="title alt">
<h1>Demo Time: <br/>Exercise 1.2 - Backing up Configurations</h1>
<aside class="notes">
<p>To demonstrate how an Ansible, open an SSH session to your control host and run the playbook in <code>workshops/networking/1.2-backup/backup.yml</code>. That example playbook is essentially the same one we just examined.</p>
<p>Don't forget to reverse what this playbook does before continuing to not interfere with later demos and workshops.</p>
</aside>
</section>
<section data-state="title alt">
<h1>Workshop: <br/>Exercise 1.2 - Backing up Configurations</h1>
<aside class="notes">
<p>This assignment provides a quick introduction to playbook structure to give them a feel for how Ansible works, but in practice is too simplistic to be useful.</p>
<p>See <code>workshops/simple_playbook</code> in the Ansible Linklight repo.</p>
<p>Note: If your time is limited, this is a workshop you can skip. We'll cover this and more topics in the next workshop.</p>
</aside>
</section>
<section>
<h1>Variables - Recap</h1>
<ul>
<li>host vars - variable specific to one host</li>
<li>group vars - variables for all hosts within the group</li>
</ul>
<p>It is possible, but not required, to configure variables in the inventory file.</p>
</section>
<section>
<h1>Inventory ini file</h1>
<pre><code>
[junos]
vsrx01 ansible_host=an-vsrx-01.rhdemo.io private_ip=172.16.1.1
vsrx02 ansible_host=an-vsrx-02.rhdemo.io private_ip=172.17.1.1
[junos:vars]
ansible_network_os=junos
ansible_password=Ansible
[ios]
ios01 ansible_host=an-ios-01.rhdemo.io
[ios:vars]
ansible_network_os=ios
ansible_become=yes
ansible_become_method=enable
ansible_become_pass=cisco
</pre></code>
</section>
<section>
<h1>Host Variables - hostvars</h1>
<pre><code data-noescape>
[junos]
vsrx01 ansible_host=an-vsrx-01.rhdemo.io <mark>private_ip=172.16.1.1</mark>
vsrx02 ansible_host=an-vsrx-02.rhdemo.io <mark>private_ip=172.17.1.1</mark>
[junos:vars]
ansible_network_os=junos
ansible_password=Ansible
[ios]
ios01 ansible_host=an-ios-01.rhdemo.io
[ios:vars]
ansible_network_os=ios
ansible_become=yes
ansible_become_method=enable
ansible_become_pass=cisco
</pre></code>
</section>
<section>
<h1>Group Variables - groupvars</h1>
<pre><code data-noescape>
[junos]
vsrx01 ansible_host=an-vsrx-01.rhdemo.io private_ip=172.16.1.1
vsrx02 ansible_host=an-vsrx-02.rhdemo.io private_ip=172.17.1.1
[junos:vars]
<mark>ansible_network_os=junos
ansible_password=Ansible</mark>
[ios]
ios01 ansible_host=an-ios-01.rhdemo.io
[ios:vars]
<mark>ansible_network_os=ios
ansible_become=yes
ansible_become_method=enable
ansible_become_pass=cisco</mark>
</pre></code>
</section>
<section>
<h1>Conditionals</h1>
<p>Ansible supports the conditional execution of a task based on the run-time evaluation of variable, fact, or previous task result.</p>
<pre><code data-noescape>
- name: configure interface settings
ios_config:
lines:
- description shutdown by Ansible
- shutdown
parents: interface GigabitEthernet2
<mark>when: ansible_network_os == "ios"</mark>
</code></pre>
<aside class="notes">
<p>Conditionals are another instance of Jinja2 in action within Ansible plays themselves. In the provided example "ansible_os_family" is a fact variable Ansible will set.</p>
<p>There are other forms of conditional clauses, but <code>when</code> is usually all that is needed.</p>
<p>NOTE: Conditional clauses are consdered to be raw Jinja2 expression without double curly braces.</p>
</aside>
</section>
<section>
<h1>Multi-Platform Playbooks</h1>
<pre><code>
- name: run on eos
include_tasks: tasks/eos.yml
when: ansible_network_os == eos
- name: run on ios
include_tasks: tasks/ios.yml
when: ansible_network_os == ios
- name: run on junos
include_tasks: tasks/junos.yml
when: ansible_network_os == junos
- name: run on nxos
include_tasks: tasks/nxos.yml
when: ansible_network_os == iosxr
</code></pre>
</section>
<section>
<h1>Using a config module</h1>
<p>Manage configuration on a network platform</p>
<code><pre>
- name: configure top level configuration
ios_config:
lines: hostname {{ inventory_hostname }}
- name: configure interface settings
ios_config:
lines:
- description test interface
- ip address 172.31.1.1 255.255.255.0
parents: interface Ethernet1
- name: configure from a jinja2 template
ios_config:
src: config.j2
</code></pre>
</section>
<section>
<h1>Exercise 1.3 - Network Diagram</h1>
<p>As a lab precursor look at the network diagram</p>
<img src="images/gre_diagram.png">
</section>
<section data-state="title alt">
<h1>Demo Time: <br/>Exercise 1.3 - Creating a GRE Tunnel</h1>
<aside class="notes">
<p>To demonstrate how an Ansible, open an SSH session to your control host and run the playbook in <code>workshops/networking/1.2-backup/backup.yml</code>. That example playbook is essentially the same one we just examined.</p>
<p>Don't forget to reverse what this playbook does before continuing to not interfere with later demos and workshops.</p>
</aside>
</section>
<section data-state="title alt">
<h1>Workshop: <br/>Exercise 1.3 - Creating a GRE Tunnel</h1>
<aside class="notes">
<p>This assignment provides a quick introduction to playbook structure to give them a feel for how Ansible works, but in practice is too simplistic to be useful.</p>
<p>See <code>workshops/simple_playbook</code> in the Ansible Linklight repo.</p>
<p>Note: If your time is limited, this is a workshop you can skip. We'll cover this and more topics in the next workshop.</p>
</aside>
</section>
<section>
<h1>Doing More with Playbooks</h1>
<p>Here are some more essential playbook features that you can apply:</p>
<ul>
<li>Templates</li>
<li>Loops</li>
<li>Conditionals</li>
<li>Tags</li>
<li>Blocks</li>
</ul>
<aside class="notes">
<p>We only have covered the most essential capabiltites of what can be done with a playbook so far.</p>
<p>Here we list a few more though this is still far from all there is. There's many other powerful playbook features for handling less common though vital automation workflows. No need to learn everything at once. You can start small and pick up more features over time as you need them.</p>
</aside>
</section>
<section>
<h1>Templates</h1>
<p>Ansible embeds the <a href="http://jinja.pocoo.org/docs/">Jinja2 templating engine</a> that can be used to dynamically:</p>
<ul>
<li>Set and modify play variables</li>
<li>Conditional logic</li>
<li>Generate files such as configurations from variables</li>
</ul>
<aside class="notes">
<p>Templates are a vital feature provided by the Jinja2 template engine, a powerful piece of software independent of Ansible. Ansible makes this usage as seamless and transparent as possible. Most will not realize they are doing templating when they develop plays with Ansible.</p>
<p>We don't show any specific template examples at the moment because we'll have plenty of opportunity to see templates in action as we cover other topics.</p>
<p>In all actuality, what is covered here only touches upon a few of its most basic features. To go deeper see these docs:</p>
<ul>
<li><a href="http://jinja.pocoo.org/docs/dev/templates/">Jinja2 Template Designer Documentation</a></li>
<li><a href="http://docs.ansible.com/ansible/playbooks_filters.html">Ansible Jinja2 Filters</a></li>
<li><a href="http://docs.ansible.com/ansible/playbooks_tests.html">Ansible Jinja2 Tests</a></li>
</ul>
</aside>
</section>
<section>
<h1>Loops</h1>
<p>Loops can do one task on multiple things, such as create a lot of users, install a lot of packages, or repeat a polling step until a certain result is reached.</p>
<pre><code data-noescape>
---
- hosts: cisco
connection: local
tasks:
- nxos_snmp_user:
user: "{{item.user}}"
group: network-admin
authentication: sha
pwd: "{{item.password}}"
<mark>with_items:</mark>
<mark>- { user: 'exampleuser', password: 'testPASS123' }</mark>
<mark>- { user: 'gerald', password: 'testPASS456' }</mark>
<mark>- { user: 'sean', password: 'testPASS789' }</mark>
<mark>- { user: 'andrius', password: 'vTECH1234' }</mark>
</code></pre>
<aside class="notes">
<p>This example demonstrates a basic loop with <code>with_items</code>. The loop sets a variable called "item", a template variable courtesy of the embedded Jinja2 template engine, with the list value that is in context.</p>
<p>There are many different and specialized types of task loops to work with. See the <a href="http://docs.ansible.com/ansible/playbooks_loops.html">Loops documentation</a> to go deeper.</p>
</aside>
</section>
<section>
<h1>Tags</h1>
<p>Tags are useful to be able to run a subset of a playbook on-demand.</p>
<pre><code data-noescape>
tasks:
- name: gather ios_facts
ios_facts:
register: version
<mark>tags: debug</mark>
- debug:
msg: "{{version}}"
<mark>tags: debug</mark>
- name: Backup configuration
ios_config:
backup: yes
<mark>tags: </mark>
<mark>- backup</mark>
</code></pre>
<aside class="notes">
<p>In the provided example, if the playbook were run with <code>--tags "packages"</code> the yum task would execute and the template task would be skipped. If the playbook were run with <code>--tags "configuration"</code> the opposite would happen. Without a <code>--tags</code> both tasks would execute like normal.</p>
<p>Tags can be seen as a simple though specialized form of conditional statement designed to enable the execution of a subset tasks. Tags are a bit more than simple boolean flags though. To dig deeper see the <a href="http://docs.ansible.com/ansible/playbooks_tags.html">playbook Tags documentation</a>.</p>
</aside>
</section>
<section>
<h1>Blocks</h1>
<p>Blocks cut down on repetitive task directives, allow for logical grouping of tasks and even in play error handling.</p>
<pre><code data-noescape>
- name: Configure Hostname and DNS
<mark>block:</mark>
- ios_config:
lines: hostname {{ inventory_hostname }}