Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Rundeck & Ansible

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

  • Inicia sesión para ver los comentarios

Rundeck & Ansible

  1. 1. Maciej Lasyk DevopsKRK meetup #9 Kraków 2016-04-14 Ansible + Rundeck = śpij adminie, śpij
  2. 2. Dołącz do projektu Fedora! http://fedoraproject.org/en/join-fedora
  3. 3. https://fedoramagazine.org/flock-2016-krakow-poland/
  4. 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. 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. 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. 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. 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. 9. Model współpracy dev ↔ ops
  10. 10. Model współpracy dev ↔ ops
  11. 11. Model współpracy dev ↔ ops
  12. 12. Model współpracy dev ↔ ops
  13. 13. Model współpracy dev ↔ ops
  14. 14. Model współpracy dev ↔ ops
  15. 15. Model współpracy dev ↔ ops
  16. 16. Model współpracy dev ↔ ops
  17. 17. Model współpracy dev ↔ ops
  18. 18. Model współpracy dev ↔ ops
  19. 19. Model współpracy dev ↔ ops
  20. 20. Model współpracy dev ↔ ops
  21. 21. Model współpracy dev ↔ ops
  22. 22. Model współpracy dev ↔ ops
  23. 23. Model współpracy dev ↔ ops
  24. 24. Model współpracy dev ↔ ops
  25. 25. Model współpracy dev ↔ ops
  26. 26. Czym jest Ansible? → prosty orkiestrator → tworzymy playbooki → posiada inventory hostów → używa ssh → pod spodem Python → przykładowy playbook I inventory
  27. 27. Czym jest Ansible? → prosty orkiestrator → tworzymy playbooki → posiada inventory hostów → używa ssh → pod spodem Python → przykładowy playbook I inventory
  28. 28. Czym jest Ansible? → prosty orkiestrator → tworzymy playbooki → posiada inventory hostów → używa ssh → pod spodem Python → przykładowy playbook I inventory
  29. 29. Czym jest Ansible? → prosty orkiestrator → tworzymy playbooki → posiada inventory hostów → używa ssh → pod spodem Python → przykładowy playbook I inventory
  30. 30. Czym jest Ansible? → prosty orkiestrator → tworzymy playbooki → posiada inventory hostów → używa ssh → pod spodem Python → przykładowy playbook I inventory
  31. 31. Czym jest Ansible? → prosty orkiestrator → tworzymy playbooki → posiada inventory hostów → używa ssh → pod spodem Python → przykładowy playbook I inventory
  32. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 59. http://www.slideshare.net/dev2ops/rundecks-history-and-future
  60. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 75. Rundeck and Jenkins http://rundeck.org/news/2014/01/08/Jenkins-is-for-development-Rundeck-is-for-operations.html
  76. 76. Architektura Rundecka http://rundeck.org/docs/administration/installation.html
  77. 77. Lab for demo https://github.com/docent-net/sesja-linuksowa-2016-rundeck
  78. 78. Rundeck: przegląd → konfiguracja ogólna → projekt → job → nodes → command
  79. 79. Rundeck: przegląd → konfiguracja ogólna → projekt → job → nodes → command
  80. 80. Rundeck: przegląd → konfiguracja ogólna → projekt → job → nodes → command
  81. 81. Rundeck: przegląd → konfiguracja ogólna → projekt → job → nodes → command
  82. 82. Rundeck: przegląd → konfiguracja ogólna → projekt → job → nodes → command
  83. 83. Rundeck adhocs demo (bez ansible'a)
  84. 84. 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
  85. 85. 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
  86. 86. 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
  87. 87. 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
  88. 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. 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. 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. 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. 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. 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. 94. Rundeck & Ansible run job on localhost node this job actually invokes ansible-playbook on choosen hosts
  95. 95. Rundeck & Ansible demo
  96. 96. 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
  97. 97. Rundeck API → nieoficjalny wrapper pythonowy: https://github.com/marklap/rundeckrun → rundeck_api_helper.py → apitoken.policy vs JSESSIONID
  98. 98. Rundeck API → nieoficjalny wrapper pythonowy: https://github.com/marklap/rundeckrun → rundeck_api_helper.py → apitoken.policy vs JSESSIONID
  99. 99. Rundeck API → nieoficjalny wrapper pythonowy: https://github.com/marklap/rundeckrun → rundeck_api_helper.py → apitoken.policy vs JSESSIONID
  100. 100. To jak z tą współpracą DEV ↔ OPS? (aka Ocado – use case)
  101. 101. To jak z tą współpracą DEV ↔ OPS? (aka Ocado – use case)
  102. 102. To jak z tą współpracą DEV ↔ OPS? (aka Ocado – use case)
  103. 103. To jak z tą współpracą DEV ↔ OPS? (aka Ocado – use case)
  104. 104. To jak z tą współpracą DEV ↔ OPS? (aka Ocado – use case)
  105. 105. To jak z tą współpracą DEV ↔ OPS? (aka Ocado – use case)
  106. 106. To jak z tą współpracą DEV ↔ OPS? (aka Ocado – use case)
  107. 107. To jak z tą współpracą DEV ↔ OPS? (aka Ocado – use case)
  108. 108. To jak z tą współpracą DEV ↔ OPS? (aka Ocado – use case)
  109. 109. To jak z tą współpracą DEV ↔ OPS? (aka Ocado – use case)
  110. 110. To jak z tą współpracą DEV ↔ OPS? (aka Ocado – use case)
  111. 111. To jak z tą współpracą DEV ↔ OPS? (aka Ocado – use case) provisioning jobs, rundeck maintenance
  112. 112. 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
  113. 113. 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ść)
  114. 114. 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ść)
  115. 115. 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ść)
  116. 116. 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ść)
  117. 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. 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. 119. To jak z tą współpracą DEV ↔ OPS? Rundeck per zespół? Czemu nie
  120. 120. To jak z tą współpracą DEV ↔ OPS? Rundeck per zespół? Czemu nie
  121. 121. To jak z tą współpracą DEV ↔ OPS? Rundeck per zespół? Czemu nie
  122. 122. Jak chciałem to podsumować?
  123. 123. Jak chciałem to podsumować?
  124. 124. Maciej Lasyk DevopsKRK meetup #9 Kraków 2016-04-14 Ansible + Rundeck = śpij adminie, śpij Dzięki :)

×