Presentation about integrating Rundeck with Ansible as well as about Rundeck itself.

1. Maciej Lasyk
DevopsKRK meetup #9
Kraków 2016-04-14
Ansible + Rundeck = śpij adminie, śpij

2. Dołącz do projektu Fedora!
http://fedoraproject.org/en/join-fedora

3. https://fedoramagazine.org/flock-2016-krakow-poland/

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

9. Model współpracy dev ↔ ops

10. Model współpracy dev ↔ ops

11. Model współpracy dev ↔ ops

12. Model współpracy dev ↔ ops

13. Model współpracy dev ↔ ops

14. Model współpracy dev ↔ ops

15. Model współpracy dev ↔ ops

16. Model współpracy dev ↔ ops

17. Model współpracy dev ↔ ops

18. Model współpracy dev ↔ ops

19. Model współpracy dev ↔ ops

20. Model współpracy dev ↔ ops

21. Model współpracy dev ↔ ops

22. Model współpracy dev ↔ ops

23. Model współpracy dev ↔ ops

24. Model współpracy dev ↔ ops

25. Model współpracy dev ↔ ops

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

59. http://www.slideshare.net/dev2ops/rundecks-history-and-future

60. Niskopoziomowe zalety Rundecka
→ Spora liczb pluginów I integracji
→ webhooki
→ Jira, IRC
→ Pagerduty, Slack, Hipchat, Redmine
→ Puppet, Salt, Ansible, Chef
→ Nexus, Jenkins
→ AWS EC2, S3
→ Paczki w popularnych dystrybucjach

61. Niskopoziomowe zalety Rundecka
→ Spora liczb pluginów I integracji
→ webhooki
→ Jira, IRC
→ Pagerduty, Slack, Hipchat, Redmine
→ Puppet, Salt, Ansible, Chef
→ Nexus, Jenkins
→ AWS EC2, S3
→ Paczki w popularnych dystrybucjach

62. Niskopoziomowe zalety Rundecka
→ Spora liczb pluginów I integracji
→ webhooki
→ Jira, IRC
→ Pagerduty, Slack, Hipchat, Redmine
→ Puppet, Salt, Ansible, Chef
→ Nexus, Jenkins
→ AWS EC2, S3
→ Paczki w popularnych dystrybucjach

63. Niskopoziomowe zalety Rundecka
→ Spora liczb pluginów I integracji
→ webhooki
→ Jira, IRC
→ Pagerduty, Slack, Hipchat, Redmine
→ Puppet, Salt, Ansible, Chef
→ Nexus, Jenkins
→ AWS EC2, S3
→ Paczki w popularnych dystrybucjach

64. Niskopoziomowe zalety Rundecka
→ Spora liczb pluginów I integracji
→ webhooki
→ Jira, IRC
→ Pagerduty, Slack, Hipchat, Redmine
→ Puppet, Salt, Ansible, Chef
→ Nexus, Jenkins
→ AWS EC2, S3
→ Paczki w popularnych dystrybucjach

65. Niskopoziomowe zalety Rundecka
→ Spora liczb pluginów I integracji
→ webhooki
→ Jira, IRC
→ Pagerduty, Slack, Hipchat, Redmine
→ Puppet, Salt, Ansible, Chef
→ Nexus, Jenkins
→ AWS EC2, S3
→ Paczki w popularnych dystrybucjach

66. Niskopoziomowe zalety Rundecka
→ Spora liczb pluginów I integracji
→ webhooki
→ Jira, IRC
→ Pagerduty, Slack, Hipchat, Redmine
→ Puppet, Salt, Ansible, Chef
→ Nexus, Jenkins
→ AWS EC2, S3
→ Paczki w popularnych dystrybucjach

67. Niskopoziomowe zalety Rundecka
→ Spora liczb pluginów I integracji
→ webhooki
→ Jira, IRC
→ Pagerduty, Slack, Hipchat, Redmine
→ Puppet, Salt, Ansible, Chef
→ Nexus, Jenkins
→ AWS EC2, S3
→ Paczki w popularnych dystrybucjach

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

75. Rundeck and Jenkins
http://rundeck.org/news/2014/01/08/Jenkins-is-for-development-Rundeck-is-for-operations.html

76. Architektura Rundecka
http://rundeck.org/docs/administration/installation.html

81. Lab for demo
https://github.com/docent-net/sesja-linuksowa-2016-rundeck

82. Rundeck: przegląd
→ konfiguracja ogólna
→ projekt
→ job
→ nodes
→ command

83. Rundeck: przegląd
→ konfiguracja ogólna
→ projekt
→ job
→ nodes
→ command

84. Rundeck: przegląd
→ konfiguracja ogólna
→ projekt
→ job
→ nodes
→ command

85. Rundeck: przegląd
→ konfiguracja ogólna
→ projekt
→ job
→ nodes
→ command

86. Rundeck: przegląd
→ konfiguracja ogólna
→ projekt
→ job
→ nodes
→ command

87. Rundeck adhocs
demo (bez ansible'a)

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

99. Rundeck & Ansible
demo

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

126. Jak chciałem to podsumować?

127. Jak chciałem to podsumować?

128. Maciej Lasyk
DevopsKRK meetup #9
Kraków 2016-04-14
Ansible + Rundeck = śpij adminie, śpij
Dzięki :)