Czy rozsądne jest uruchamianie procesów za pomocą narzędzi CI?

W mojej firmie mamy kłopoty z odmiennymi zadaniami crona (na wielu systemach) i ręcznie uruchamiamy procesy, które utrzymują funkcjonowanie naszej firmy, co jest wynikiem lat celowego rozwoju i późniejszych zaniedbań.

Kiedyś będziemy musieli wymyślić bardziej scentralizowane rozwiązanie z oczywistych powodów.

Jedną z myśli, że skopaliśmy, jest użycie naszego oprogramowania do ciągłej integracji (Jenkins) do uruchamiania tych procesów, co wydaje się logiczne.

Moje pytanie brzmi: czy robią to inne firmy? Czy jest to ogólnie przyjęta praktyka? Czy nie koliduje to z definicją narzędzia CI ukrytą w jego nazwie? Są jakieś inne opcje?

Uwaga: https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins

Jenkins twierdzi, że koncentruje się na „Monitorowaniu wykonywania zadań uruchamianych zewnętrznie, takich jak zadania cron i zadania procmail”. Nie jestem pewien, czy właśnie o tym mówię.

Używamy Jenkinsa jako crona od kilku lat, a oto kilka zalet i wad:

Plusy

• Jeśli zarządzasz dużą liczbą procesów na kilkudziesięciu serwerach i wielu środowiskach, ułatwia to wiele rzeczy. Otrzymujesz powiadomienia e-mail po wyjęciu z pudełka, wspólny pulpit nawigacyjny do wszystkiego, interfejs WWW dla dzienników i łatwy sposób na skonfigurowanie dodatkowych węzłów do uruchamiania zadań. Zespoły wsparcia szczególnie doceniają to centralne miejsce do sprawdzania problemów i ponownego uruchamiania zadań.

• Ekosystem wtyczek Jenkinsa jest bardzo aktywny i zapewnia wiele dodatkowych funkcji ... Myślę, że to naprawdę „zabójca” Jenkinsa, ponieważ jeśli sam Jenkins nie zapewnia tego, czego szukasz (często tak jest), więcej często jest to plugin. Niektóre z moich ulubionych: Cron Column, Rebuild, NodeLabel Parameter, Log Parser i Email-ext.

• Zaawansowana obsługa harmonogramów / wyzwalaczy: Składnia harmonogramu to w zasadzie cron, więc masz tam tę samą elastyczność, ale uzupełnia ją Trigger, REST API i Groovy / Java API

Cons

• Centralny punkt awarii: Ponieważ wszystkie twoje zadania są uruchamiane przez jeden serwer, jeśli to pole się wyłączy i nikt nie zauważy, Big Trouble. Lepiej więc mieć dobry monitoring, aby natychmiast wychwytywać awarie, a także wszystkie konfiguracje zapisane w kontroli źródła. Nawet jeśli nie możesz odzyskać oryginalnego serwera, o ile masz konfiguracje zadań, to jest trywialne, aby skonfigurować je gdzie indziej. Jeśli problemem jest czas na rozwiązanie problemu, posiadanie wstępnie skonfigurowanego trybu gotowości jest prawdopodobnie dobrym pomysłem.

• Jeśli masz wiele środowisk (Dev, UAT, Prod), zazwyczaj masz nieco inne wersje zadania uruchomionego w każdym środowisku. Posiadanie wszystkich tych zadań na jednym urządzeniu Jenkins może stać się nieporadne, a ręczne ich konfigurowanie staje się ogromnym bólem. W naszym przypadku uruchamiamy osobną instancję Jenkinsa „Crona” dla każdego środowiska. Instancje są instalowane i konfigurowane automatycznie przy użyciu wewnętrznego narzędzia do wdrażania. Możesz nie mieć czegoś takiego, ale istnieją narzędzia typu open source, które robią podobne rzeczy (generują konfiguracje za pomocą szablonów). Jeśli możesz rozwiązać problem z generowaniem konfiguracji, znacznie ułatwia to konfigurowanie i wdrażanie Jenkinsa, a także ułatwia kontrolę nad źródłami.

• Aktualizacja Jenkins czasami psuje funkcjonalność, szczególnie w przypadku wtyczek. Nie uaktualniaj instancji Jenkins o znaczeniu krytycznym, dopóki nie wypróbujesz nowej wersji gdzieś indziej. Tutaj bardzo przydatne jest posiadanie lustrzanego środowiska Dev z własną instancją Jenkins.

Jedną rzecz, którą należy podkreślić: rzeczywiście używamy również Jenkins dla CI, ale jest to osobna instancja ... instancje „cron” są dedykowane do zarządzania zadaniami, a instancja „CI” jest dedykowana dla CI. Wydaje się, że rozdzielenie problemów sprawia, że ​​wszystko staje się czystsze.

Na marginesie, używam Jenkins zamiast crona na moim Linux-ie w domu :)

Nawiasem mówiąc, jest to dość powszechny przypadek użycia Jenkinsa. Na przykład Sandia National Lab używa Jenkins w ten sposób: https://software.sandia.gov/trac/fast/wiki/Hudson

Istnieje wiele postów na blogu i samouczków opisujących to. Oto kilka przykładów: http://blog.vuksan.com/2011/08/22/using-jenkins-as-a-cron-server/

http://morgajel.net/2011/12/12/1108

Powinienem również dodać, że tak naprawdę dotyczy to tylko Jenkinsa, a nie wszystkich narzędzi CI w ogóle. To, że Jenkins jest do tego odpowiedni, nie oznacza, że ​​inni (TeamCity, buildbot itp.) Są ...

Powiedziałbym, że nie używasz tutaj odpowiedniego narzędzia do tego zadania, ponieważ głównym punktem narzędzi CI jest to, że monitorują one coś - zwykle twój kod źródłowy - a kiedy jest zmiana, rozpoczynają kompilację / wdrożenie / cokolwiek .

Narzędzia te mogą jednak uruchamiać zaplanowane zadania (na przykład TeamCity), dzięki czemu można wdrożyć witrynę internetową (na przykład), gdy nikogo nie ma w pobliżu. Tak więc posiadanie jednej centralnej listy wszystkich wykonywanych zadań jest dobrym pomysłem. Narzędzia powinny również pozwolić ci zdecydować, kiedy i jak często te zadania będą uruchamiane.

Kolejną korzyścią jest to, że możesz nawet monitorować system zdalnie (jeśli chcesz).

Podsumowując, powiedziałbym, że było to rozsądne.

Wygląda na to, że cron jest już odpowiednim narzędziem dla twoich potrzeb. Polecam zacząć od udokumentowania swojego systemu. Dokonaj audytu różnych systemów i zbierz wyczerpującą listę procesów, które działają na poszczególnych komputerach.

Następnie zastanów się nad wyznaczeniem dedykowanej maszyny do uruchamiania wszystkich tych procesów cron. Upewnij się, że udokumentujesz, który to komputer, i nadaj mu odpowiednie uprawnienia administratora do kontrolowania go. Umieść wszystkie cronjoby na tym komputerze, a wtedy będziesz mieć centralny punkt kontroli dla różnych zautomatyzowanych procesów.

Moja reakcja brzucha jest taka sama, że ​​używasz narzędzia z koncepcją harmonogramu, aby wykonać pracę harmonogramu zadań.

Nie wspomniałeś o swoich zadaniach, ale wspomnienie o CRON sprawia, że ​​zgaduję, że są to skrypty powłoki itp. Istnieją pakiety open source i komercyjne harmonogramy zadań. Czasami są one nazywane harmonogramami wsadowymi. Niektórzy po prostu zakończą CRON i uczynią go bardziej przyjaznym. Niektóre, takie jak harmonogram kwarcowy, zapewniają wydajne zarządzanie zadaniami, ale wymagają ich implementacji jako klas Java. Możesz potencjalnie tego użyć i zamknąć wywołania środowiska wykonawczego do różnych skryptów za pomocą opakowania Java. Wierzę, że znajdziesz wiele opcji, jeśli spojrzysz dalej.

Nie należy używać CI do uruchamiania okresowych zadań niezwiązanych z kompilacją.

Unikaj także crona dla zadań niezwiązanych z konserwacją systemu.

Używaj odpowiednich narzędzi. Na potrzeby aplikacji - spróbuj użyć rozwiązań opartych na AMQP.

PS Rozumiem, że cron pasuje do twojej skrzynki. Z drugiej strony masz wiele zadań - spróbuj więc napisać dla nich aplikację nadzorczą.

Do tego typu zadania należy użyć magistrali usług korporacyjnych (ESB).

Teraz moje tło znajduje się w systemie Windows / BizTalk, ale jestem pewien, że wszystkie ekwiwalenty istnieją również po unixowej stronie rzeczy. To, co normalnie robilibyśmy, to konfigurowanie procesów na polu BizTalk, które byłyby odpowiedzialne za uruchamianie rzeczy na drugim polu, monitorowanie postępu / błędów i zgłaszanie statusu do portalu SharePoint (lub sieci) lub wysyłanie e-maili i takie, jeśli wymaga uwagi.

Zaletą tego podejścia jest to, że cała konfiguracja i zarządzanie różnymi procesami biznesowymi są zlokalizowane centralnie, dzięki czemu wiesz, od czego zacząć. Oprogramowanie już istnieje, które pozwala wyodrębnić część kodującą z fizycznej konfiguracji (w BizTalk można zaprogramować na logicznym „porcie”, takim jak serwer sql, a następnie w prod, jeśli skrzynka sql zmienia lokalizację lub jest aktualizowana, czy cokolwiek innego, mogę zmienić skonfigurowany port fizyczny za pomocą narzędzia administratora, ponownie, jestem pewien, że istnieją odpowiedniki po stronie Uniksa).

Korzyści wynikające z używania narzędzi CI byłyby takie, że jeśli błąd procesu się zakończy, możesz automatycznie, fizycznie przesłać wiadomości ponownie i możesz skonfigurować klastrowe środowisko pracy awaryjnej, mając lepiej dopasowany system rejestrowania i rejestrowania; Ponadto, gdy już będziesz mieć system, możesz rozpocząć projektowanie swojej organizacji pod kątem użycia lub lepszego wykorzystania SOA. Wadą jest to, że w zależności od wielkości organizacji wysiłek rozwojowy może być wysoki, a koszty licencji mogą być zaporowe.

Teoretycznie sensowne jest posiadanie jednego miejsca do kontrolowania wszystkich różnych zadań, jednak w oparciu o doświadczenie branżowe, takie jak „Święty Graal”, potrzebujesz tutaj zadań cron, skryptów bash i skryptów cli tutaj.

Istnieje również mantra „Jeśli się nie zepsuła, nie naprawiaj tego”, więc podczas gdy oni postępują, początkowo skup się na dokumentowaniu uruchomionych skryptów, tego, co robią i jakich systemów dotykają, abyś „wiedział” „w jaki sposób prowadzona jest Twoja firma.

Następnie jako strategię długoterminową skonfiguruj scentralizowany system do uruchamiania zadań, wybierz mądrze swoje rozwiązanie, ponieważ będziesz musiał z nim żyć. Następnie dla każdego żądania zmiany, rozszerzenia, aktualizacji, naprawy błędu lub nowego rozwiązania dodanego w architekturze biznesowej upewnij się, że jego zaplanowane i zautomatyzowane zadania zostaną dodane do „rozwiązania kontroli przedsiębiorstwa”.

W ten sposób stopniowo migrujesz z serii skryptów do środowiska bardziej przyjaznego dla przedsiębiorstw.

W dużych systemach korporacyjnych, z którymi pracowałem, zwykle używają one narzędzi zaprojektowanych do planowania. Najpopularniejszym, którego użyłem, jest CA7. Pozwala scentralizować wszystkie harmonogramy dla wszystkich systemów.

Cron jest zwykle używany do pojedynczego komputera, chociaż można go „zhakować”, wykonując połączenia zdalne ssh. Jednak nie będzie miał pojęcia zależności i innych rzeczy. Jeśli chodzi o zespoły operacyjne, których zakres jest jeszcze bardziej ograniczony, najlepiej jest użyć narzędzia.