1. ansible
  2. Commit cef08640a439db972d22ba090529520f2ed87a40
Browse code

[stable-2.7] Add an example to serial usage (#48669) (cherry picked from commit b759862daa59ca856ada1f813c0601553cd662a9)

Co-authored-by: Toshio Kuratomi <a.badger@gmail.com>

Toshio Kuratomi authored on 2018/11/15 01:57:10
Showing 1 changed files
docs/docsite/rst/user_guide/playbooks_delegation.rst
History View file @ cef0864
... ... 
@@ -19,21 +19,55 @@ You'll also want to read up on :doc:`playbooks_reuse_roles`, as the 'pre_task' a
19 19
20 20 
 Be aware that certain tasks are impossible to delegate, i.e. `include`, `add_host`, `debug`, etc as they always execute on the controller.
21 21
22 
+
22 23 
 .. _rolling_update_batch_size:
23 24
24 25 
 Rolling Update Batch Size
25 26 
 `````````````````````````
26 27
27 
-
28 28 
 By default, Ansible will try to manage all of the machines referenced in a play in parallel.  For a rolling update use case, you can define how many hosts Ansible should manage at a single time by using the ``serial`` keyword::
29 29
30 30
31 31 
     - name: test play
32 32 
       hosts: webservers
33 
-      serial: 3
33 
+      serial: 2
34 
+      gather_facts: False
35 
+      tasks:
36 
+      - name: task one
37 
+        comand: hostname
38 
+      - name: task two
39 
+        command: hostname
40 
+
41 
+In the above example, if we had 4 hosts in the group 'webservers', 2
42 
+would complete the play completely before moving on to the next 2 hosts::
43 
+
44 
+
45 
+    PLAY [webservers] ****************************************
46 
+
47 
+    TASK [task one] ******************************************
48 
+    changed: [web2]
49 
+    changed: [web1]
50 
+
51 
+    TASK [task two] ******************************************
52 
+    changed: [web1]
53 
+    changed: [web2]
54 
+
55 
+    PLAY [webservers] ****************************************
56 
+
57 
+    TASK [task one] ******************************************
58 
+    changed: [web3]
59 
+    changed: [web4]
60 
+
61 
+    TASK [task two] ******************************************
62 
+    changed: [web3]
63 
+    changed: [web4]
64 
+
65 
+    PLAY RECAP ***********************************************
66 
+    web1      : ok=2    changed=2    unreachable=0    failed=0
67 
+    web2      : ok=2    changed=2    unreachable=0    failed=0
68 
+    web3      : ok=2    changed=2    unreachable=0    failed=0
69 
+    web4      : ok=2    changed=2    unreachable=0    failed=0
34 70
35 
-In the above example, if we had 100 hosts, 3 hosts in the group 'webservers'
36 
-would complete the play completely before moving on to the next 3 hosts.
37 71
38 72 
 The ``serial`` keyword can also be specified as a percentage, which will be applied to the total number of hosts in a
39 73 
 play, in order to determine the number of hosts per pass::
... ... 
@@ -77,6 +111,7 @@ You can also mix and match the values::
77 77 
 .. note::
78 78 
      No matter how small the percentage, the number of hosts per pass will always be 1 or greater.
79 79
80 
+
80 81 
 .. _maximum_failure_percentage:
81 82
82 83 
 Maximum Failure Percentage