4. Ansible & Rundeck?
→ monolityczne instalacje (np. CI)
→ a gdyby tak developerzy sami zarządzali CI?
→ i do tego są potrzebne narzędzia
→ ansible jest prosty
→ rundeck jest jeszcze prostszy
5. Ansible & Rundeck?
→ monolityczne instalacje (np. CI)
→ a gdyby tak developerzy sami zarządzali CI?
→ i do tego są potrzebne narzędzia
→ ansible jest prosty
→ rundeck jest jeszcze prostszy
6. Ansible & Rundeck?
→ monolityczne instalacje (np. CI)
→ a gdyby tak developerzy sami zarządzali CI?
→ i do tego są potrzebne narzędzia
→ ansible jest prosty
→ rundeck jest jeszcze prostszy
7. Ansible & Rundeck?
→ monolityczne instalacje (np. CI)
→ a gdyby tak developerzy sami zarządzali CI?
→ i do tego są potrzebne narzędzia
→ ansible jest prosty
→ rundeck jest jeszcze prostszy
8. Ansible & Rundeck?
→ monolityczne instalacje (np. CI)
→ a gdyby tak developerzy sami zarządzali CI?
→ i do tego są potrzebne narzędzia
→ ansible jest prosty
→ rundeck jest jeszcze prostszy
26. Czym jest Ansible?
→ prosty orkiestrator
→ tworzymy playbooki
→ posiada inventory hostów
→ używa ssh
→ pod spodem Python
→ przykładowy playbook I inventory
27. Czym jest Ansible?
→ prosty orkiestrator
→ tworzymy playbooki
→ posiada inventory hostów
→ używa ssh
→ pod spodem Python
→ przykładowy playbook I inventory
28. Czym jest Ansible?
→ prosty orkiestrator
→ tworzymy playbooki
→ posiada inventory hostów
→ używa ssh
→ pod spodem Python
→ przykładowy playbook I inventory
29. Czym jest Ansible?
→ prosty orkiestrator
→ tworzymy playbooki
→ posiada inventory hostów
→ używa ssh
→ pod spodem Python
→ przykładowy playbook I inventory
30. Czym jest Ansible?
→ prosty orkiestrator
→ tworzymy playbooki
→ posiada inventory hostów
→ używa ssh
→ pod spodem Python
→ przykładowy playbook I inventory
31. Czym jest Ansible?
→ prosty orkiestrator
→ tworzymy playbooki
→ posiada inventory hostów
→ używa ssh
→ pod spodem Python
→ przykładowy playbook I inventory
32. Czym jest Rundeck?
→ “Turn your operations procedures into self-service jobs.”
→ “Safely give others the control and visibility they need.”
→ "...it's the swiss army knife for ops."
→ biblioteka procedur
→ scheduler
→ łatwa integracja z systemami do incydentów
→ po CI / buildzie nadchodzi deployment
→ GUI & API
33. Czym jest Rundeck?
→ “Turn your operations procedures into self-service jobs.”
→ “Safely give others the control and visibility they need.”
→ "...it's the swiss army knife for ops."
→ biblioteka procedur
→ scheduler
→ łatwa integracja z systemami do incydentów
→ po CI / buildzie nadchodzi deployment
→ GUI & API
34. Czym jest Rundeck?
→ “Turn your operations procedures into self-service jobs.”
→ “Safely give others the control and visibility they need.”
→ "...it's the swiss army knife for ops."
→ biblioteka procedur
→ scheduler
→ łatwa integracja z systemami do incydentów
→ po CI / buildzie nadchodzi deployment
→ GUI & API
35. Czym jest Rundeck?
→ “Turn your operations procedures into self-service jobs.”
→ “Safely give others the control and visibility they need.”
→ "...it's the swiss army knife for ops."
→ biblioteka procedur
→ scheduler
→ łatwa integracja z systemami do incydentów
→ po CI / buildzie nadchodzi deployment
→ GUI & API
36. Czym jest Rundeck?
→ “Turn your operations procedures into self-service jobs.”
→ “Safely give others the control and visibility they need.”
→ "...it's the swiss army knife for ops."
→ biblioteka procedur
→ scheduler
→ łatwa integracja z systemami do incydentów
→ po CI / buildzie nadchodzi deployment
→ GUI & API
37. Czym jest Rundeck?
→ “Turn your operations procedures into self-service jobs.”
→ “Safely give others the control and visibility they need.”
→ "...it's the swiss army knife for ops."
→ biblioteka procedur
→ scheduler
→ łatwa integracja z systemami do incydentów
→ po CI / buildzie nadchodzi deployment
→ GUI & API
38. Czym jest Rundeck?
→ “Turn your operations procedures into self-service jobs.”
→ “Safely give others the control and visibility they need.”
→ "...it's the swiss army knife for ops."
→ biblioteka procedur
→ scheduler
→ łatwa integracja z systemami do incydentów
→ po CI / buildzie nadchodzi deployment
→ GUI & API
39. Czym jest Rundeck?
→ “Turn your operations procedures into self-service jobs.”
→ “Safely give others the control and visibility they need.”
→ "...it's the swiss army knife for ops."
→ biblioteka procedur
→ scheduler
→ łatwa integracja z systemami do incydentów
→ po CI / buildzie nadchodzi deployment
→ GUI & API
40. Czym jest Rundeck?
→ stworzony w Javie + Grails + Jetty + Bootstrap
→ początki w roku 2010
→ Apache license v2.0
→ Copyright 2010 DTO Solutions
→ “DevOps and Automation Specialists”
→ “RunDeck is a command dispatcher with a
modern web console. It lets you easily run commands
across a set of nodes.”
41. Czym jest Rundeck?
→ stworzony w Javie + Grails + Jetty + Bootstrap
→ początki w roku 2010
→ Apache license v2.0
→ Copyright 2010 DTO Solutions
→ “DevOps and Automation Specialists”
→ “RunDeck is a command dispatcher with a
modern web console. It lets you easily run commands
across a set of nodes.”
42. Czym jest Rundeck?
→ stworzony w Javie + Grails + Jetty + Bootstrap
→ początki w roku 2010
→ Apache license v2.0
→ Copyright 2010 DTO Solutions
→ “DevOps and Automation Specialists”
→ “RunDeck is a command dispatcher with a
modern web console. It lets you easily run commands
across a set of nodes.”
43. Czym jest Rundeck?
→ stworzony w Javie + Grails + Jetty + Bootstrap
→ początki w roku 2010
→ Apache license v2.0
→ Copyright 2010 DTO Solutions
→ “DevOps and Automation Specialists”
→ “RunDeck is a command dispatcher with a
modern web console. It lets you easily run commands
across a set of nodes.”
44. Czym jest Rundeck?
→ stworzony w Javie + Grails + Jetty + Bootstrap
→ początki w roku 2010
→ Apache license v2.0
→ Copyright 2010 DTO Solutions
→ “DevOps and Automation Specialists”
→ “RunDeck is a command dispatcher with a
modern web console. It lets you easily run commands
across a set of nodes.”
45. Czym jest Rundeck?
→ stworzony w Javie + Grails + Jetty + Bootstrap
→ początki w roku 2010
→ Apache license v2.0
→ Copyright 2010 DTO Solutions
→ “DevOps and Automation Specialists”
→ “RunDeck is a command dispatcher with a
modern web console. It lets you easily run commands
across a set of nodes.”
46. Główne koncepty Rundecka
→ projekt (kontener jobów, node'ów I konfiguracji)
→ job (sekwencja komend, skryptów)
→ workflow (sekwencja jobów)
→ nodes (hosty dostępne przez SSH)
→ wykonanie (uruchomienia jobów)
→ użytkownicy
→ uprawnienia
→ API
47. Główne koncepty Rundecka
→ projekt (kontener jobów, node'ów I konfiguracji)
→ job (sekwencja komend, skryptów)
→ workflow (sekwencja jobów)
→ nodes (hosty dostępne przez SSH)
→ wykonanie (uruchomienia jobów)
→ użytkownicy
→ uprawnienia
→ API
48. Główne koncepty Rundecka
→ projekt (kontener jobów, node'ów I konfiguracji)
→ job (sekwencja komend, skryptów)
→ workflow (sekwencja jobów)
→ nodes (hosty dostępne przez SSH)
→ wykonanie (uruchomienia jobów)
→ użytkownicy
→ uprawnienia
→ API
49. Główne koncepty Rundecka
→ projekt (kontener jobów, node'ów I konfiguracji)
→ job (sekwencja komend, skryptów)
→ workflow (sekwencja jobów)
→ nodes (hosty dostępne przez SSH)
→ wykonanie (uruchomienia jobów)
→ użytkownicy
→ uprawnienia
→ API
50. Główne koncepty Rundecka
→ projekt (kontener jobów, node'ów I konfiguracji)
→ job (sekwencja komend, skryptów)
→ workflow (sekwencja jobów)
→ nodes (hosty dostępne przez SSH)
→ wykonanie (uruchomienia jobów)
→ użytkownicy
→ uprawnienia
→ API
51. Główne koncepty Rundecka
→ projekt (kontener jobów, node'ów I konfiguracji)
→ job (sekwencja komend, skryptów)
→ workflow (sekwencja jobów)
→ nodes (hosty dostępne przez SSH)
→ wykonanie (uruchomienia jobów)
→ użytkownicy
→ uprawnienia
→ API
52. Główne koncepty Rundecka
→ projekt (kontener jobów, node'ów I konfiguracji)
→ job (sekwencja komend, skryptów)
→ workflow (sekwencja jobów)
→ nodes (hosty dostępne przez SSH)
→ wykonanie (uruchomienia jobów)
→ użytkownicy
→ uprawnienia
→ API
53. Główne koncepty Rundecka
→ projekt (kontener jobów, node'ów I konfiguracji)
→ job (sekwencja komend, skryptów)
→ workflow (sekwencja jobów)
→ nodes (hosty dostępne przez SSH)
→ wykonanie (uruchomienia jobów)
→ użytkownicy
→ uprawnienia
→ API
54. Wysokopoziomowe zalety Rundecka
→ Formalizacja procedur w spójnej formie
→ Przejrzysty dashboard
→ Logowanie, audyt, widoczność
→ Elastyczna granulacja uprawnień
→ Interfejs współpracy pomiędzy zespołami
55. Wysokopoziomowe zalety Rundecka
→ Formalizacja procedur w spójnej formie
→ Przejrzysty dashboard
→ Logowanie, audyt, widoczność
→ Elastyczna granulacja uprawnień
→ Interfejs współpracy pomiędzy zespołami
56. Wysokopoziomowe zalety Rundecka
→ Formalizacja procedur w spójnej formie
→ Przejrzysty dashboard
→ Logowanie, audyt, widoczność
→ Elastyczna granulacja uprawnień
→ Interfejs współpracy pomiędzy zespołami
57. Wysokopoziomowe zalety Rundecka
→ Formalizacja procedur w spójnej formie
→ Przejrzysty dashboard
→ Logowanie, audyt, widoczność
→ Elastyczna granulacja uprawnień
→ Interfejs współpracy pomiędzy zespołami
58. Wysokopoziomowe zalety Rundecka
→ Formalizacja procedur w spójnej formie
→ Przejrzysty dashboard
→ Logowanie, audyt, widoczność
→ Elastyczna granulacja uprawnień
→ Interfejs współpracy pomiędzy zespołami
68. → Jenkins is for Development (software builds)
→ Rundeck is for Operations (executing operational tasks)
→ Both are complementary
→ Rundeck has nodes (hosts) and inventory concept
→ Rundeck executes jobs / workflows on nodes (inventory)
→ Rundeck has ad-hoc commands (you can run those on nodes)
→ Rundeck provides you with fain – grained ACLs
Rundeck vs Jenkins?
69. → Jenkins is for Development (software builds)
→ Rundeck is for Operations (executing operational tasks)
→ Both are complementary
→ Rundeck has nodes (hosts) and inventory concept
→ Rundeck executes jobs / workflows on nodes (inventory)
→ Rundeck has ad-hoc commands (you can run those on nodes)
→ Rundeck provides you with fain – grained ACLs
Rundeck vs Jenkins?
70. → Jenkins is for Development (software builds)
→ Rundeck is for Operations (executing operational tasks)
→ Both are complementary
→ Rundeck has nodes (hosts) and inventory concept
→ Rundeck executes jobs / workflows on nodes (inventory)
→ Rundeck has ad-hoc commands (you can run those on nodes)
→ Rundeck provides you with fain – grained ACLs
Rundeck vs Jenkins?
71. → Jenkins is for Development (software builds)
→ Rundeck is for Operations (executing operational tasks)
→ Both are complementary
→ Rundeck has nodes (hosts) and inventory concept
→ Rundeck executes jobs / workflows on nodes (inventory)
→ Rundeck has ad-hoc commands (you can run those on nodes)
→ Rundeck provides you with fain – grained ACLs
Rundeck vs Jenkins?
72. → Jenkins is for Development (software builds)
→ Rundeck is for Operations (executing operational tasks)
→ Both are complementary
→ Rundeck has nodes (hosts) and inventory concept
→ Rundeck executes jobs / workflows on nodes (inventory)
→ Rundeck has ad-hoc commands (you can run those on nodes)
→ Rundeck provides you with fain – grained ACLs
Rundeck vs Jenkins?
73. → Jenkins is for Development (software builds)
→ Rundeck is for Operations (executing operational tasks)
→ Both are complementary
→ Rundeck has nodes (hosts) and inventory concept
→ Rundeck executes jobs / workflows on nodes (inventory)
→ Rundeck has ad-hoc commands (you can run those on nodes)
→ Rundeck provides you with fain – grained ACLs
Rundeck vs Jenkins?
74. Rundeck vs Jenkins?
→ Jenkins is for Development (software builds)
→ Rundeck is for Operations (executing operational tasks)
→ Both are complementary
→ Rundeck has nodes (hosts) and inventory concept
→ Rundeck executes jobs / workflows on nodes (inventory)
→ Rundeck has ad-hoc commands (you can run those on nodes)
→ Rundeck provides you with fain – grained ACLs
88. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
89. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
90. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
91. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
92. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
93. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
94. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
95. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
96. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
97. Rundeck & Ansible
→ Use Rundeck only as GUI, API and scheduler
→ Bring Rundeck inventory to common with Ansible
→ Remember that Rundeck is stupid
→ Create workspace for jobs
→ Clean up this workspace automatically
→ Only run ansible-playbooks
→ Good practices (in my opinion)?
→ Common provisioning core jobs
→ Common “playbook-runner” job
→ Integrate Rundeck & Ansible debug
98. Rundeck & Ansible
run job on localhost node
this job actually invokes ansible-playbook
on choosen hosts
100. Rundeck & Ansible plugin
I'm new to both Rundeck and Ansible so I expect
there to be room for improvements.
Only basic features have been implemented
in this first pass, so I can play around with both tools.
Liking it very much so far! :)
https://github.com/Batix/rundeck-ansible-plugin
101. Rundeck API
→ nieoficjalny wrapper pythonowy:
https://github.com/marklap/rundeckrun
→ rundeck_api_helper.py
→ apitoken.policy vs JSESSIONID
102. Rundeck API
→ nieoficjalny wrapper pythonowy:
https://github.com/marklap/rundeckrun
→ rundeck_api_helper.py
→ apitoken.policy vs JSESSIONID
103. Rundeck API
→ nieoficjalny wrapper pythonowy:
https://github.com/marklap/rundeckrun
→ rundeck_api_helper.py
→ apitoken.policy vs JSESSIONID
104. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
105. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
106. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
107. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
108. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
109. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
110. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
111. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
112. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
113. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
114. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
115. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
provisioning jobs, rundeck maintenance
116. To jak z tą współpracą DEV ↔ OPS?
(aka Ocado – use case)
provisioning jobs, rundeck maintenance
maintenance of own app clusters
creating app clusters
costs supervision
117. To jak z tą współpracą DEV ↔ OPS?
Dobre praktyki utrzymania Rundecka w środowisku dev – ops?
→ **nie** edytujcie jobów na codzień w UI
→ joby definiujcie w repo i importujcie (np. przez wrapper API)
→ dzielcie się między sobą swoimi jobami / template'ami
→ trzymajcie logikę w Ansible'u (Puppecie / cokolwiek) – nie
w definicjach jobów rundeckowych
→ testujcie automatycznie wykonanie swoich jobów
→ przekręcajcie często całą instancję Rundecka (powtarzalność)
118. To jak z tą współpracą DEV ↔ OPS?
Dobre praktyki utrzymania Rundecka w środowisku dev – ops?
→ **nie** edytujcie jobów na codzień w UI
→ joby definiujcie w repo i importujcie (np. przez wrapper API)
→ dzielcie się między sobą swoimi jobami / template'ami
→ trzymajcie logikę w Ansible'u (Puppecie / cokolwiek) – nie
w definicjach jobów rundeckowych
→ testujcie automatycznie wykonanie swoich jobów
→ przekręcajcie często całą instancję Rundecka (powtarzalność)
119. To jak z tą współpracą DEV ↔ OPS?
Dobre praktyki utrzymania Rundecka w środowisku dev – ops?
→ **nie** edytujcie jobów na codzień w UI
→ joby definiujcie w repo i importujcie (np. przez wrapper API)
→ dzielcie się między sobą swoimi jobami / template'ami
→ trzymajcie logikę w Ansible'u (Puppecie / cokolwiek) – nie
w definicjach jobów rundeckowych
→ testujcie automatycznie wykonanie swoich jobów
→ przekręcajcie często całą instancję Rundecka (powtarzalność)
120. To jak z tą współpracą DEV ↔ OPS?
Dobre praktyki utrzymania Rundecka w środowisku dev – ops?
→ **nie** edytujcie jobów na codzień w UI
→ joby definiujcie w repo i importujcie (np. przez wrapper API)
→ dzielcie się między sobą swoimi jobami / template'ami
→ trzymajcie logikę w Ansible'u (Puppecie / cokolwiek) – nie
w definicjach jobów rundeckowych
→ testujcie automatycznie wykonanie swoich jobów
→ przekręcajcie często całą instancję Rundecka (powtarzalność)
121. To jak z tą współpracą DEV ↔ OPS?
Dobre praktyki utrzymania Rundecka w środowisku dev – ops?
→ **nie** edytujcie jobów na codzień w UI
→ joby definiujcie w repo i importujcie (np. przez wrapper API)
→ dzielcie się między sobą swoimi jobami / template'ami
→ trzymajcie logikę w Ansible'u (Puppecie / cokolwiek) – nie
w definicjach jobów rundeckowych
→ testujcie automatycznie wykonanie swoich jobów
→ przekręcajcie często całą instancję Rundecka (powtarzalność)
122. To jak z tą współpracą DEV ↔ OPS?
Dobre praktyki utrzymania Rundecka w środowisku dev – ops?
→ **nie** edytujcie jobów na codzień w UI
→ joby definiujcie w repo i importujcie (np. przez wrapper API)
→ dzielcie się między sobą swoimi jobami / template'ami
→ trzymajcie logikę w Ansible'u (Puppecie / cokolwiek) – nie
w definicjach jobów rundeckowych
→ testujcie automatycznie wykonanie swoich jobów
→ przekręcajcie często całą instancję Rundecka (powtarzalność)
123. To jak z tą współpracą DEV ↔ OPS?
Rundeck per zespół? Czemu nie
124. To jak z tą współpracą DEV ↔ OPS?
Rundeck per zespół? Czemu nie
125. To jak z tą współpracą DEV ↔ OPS?
Rundeck per zespół? Czemu nie