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

29

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ę.

smp7d
źródło
2
Czy możesz wyjaśnić naturę różnych zadań i procesów, które masz na myśli?
Stephen Gross
mieszanka skryptów w różnych językach, procesach java i komendach linuxowych
smp7d
Potrzebujemy więcej szczegółów. Jaki jest charakter zadań? Co oni robią? Jak są zarządzane?
Stephen Gross
@StephenGross Zbierz dane z zewnętrznych systemów do lokalnego przechowywania, wysyłaj powiadomienia do użytkowników na podstawie reguł biznesowych, sprawdzaj użycie dysku, usuwaj sieroty i około tysiąca innych rzeczy. Wszystkie są zarządzane przez crona, jeśli są w ogóle zarządzane w tym momencie. Dlaczego potrzebujesz tych informacji? Możesz po prostu założyć, że wykonują kluczowe funkcje biznesowe zgodnie z harmonogramem.
smp7d
2
Powodem, dla którego potrzebuję tych szczegółów, jest to, że aby pomóc ci rozwiązać problem, muszę go zrozumieć. Chociaż wiesz już dużo o tych zadaniach / procesach, ja nie; pomocne jest zrozumienie charakteru zadań, które należy wykonać, oceniając, jakie rozwiązanie techniczne działa najlepiej.
Stephen Gross

Odpowiedzi:

17

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ą ...

Dylan Cali
źródło
8

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.

ChrisF
źródło
Twoje uczucia na ten temat odzwierciedlają moje. Ponieważ powszechnie wiadomo, że CI służy do kompilacji i testów, uważam to za niekonwencjonalne rozwiązanie. Inne odpowiedzi na to pytanie zdecydowanie pokazały, że tak jest, ponieważ wielu uważa, że ​​jest to niewłaściwe narzędzie do pracy. Ponieważ TeamCity może wykonywać te dodatkowe zadania, każde narzędzie CI korzystające z projektów Maven może wykonywać dowolną liczbę czynności. Nadal nie czuję się dobrze, że to dobry pomysł.
smp7d,
1
@ smp7d - uzgodniony. To możliwe rozwiązanie, ale nie idealne .
ChrisF
6

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.

Stephen Gross
źródło
2

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.

Guerry
źródło
Zadania to mieszanka skryptów w różnych językach, procesów Java i poleceń Linux. Sam Quartz nie zapewni mi zarządzania frontem / kompilacją, które zapewni Jenkins, a ja nie chcę budować tego wszystkiego. Nie zdziwiłbym się, gdyby Jenkins używał Kwarcu za kulisami. Sprawdzę jednak tego menedżera kwarcu ( terracotta.org/products/quartz-scheduler ).
smp7d
2

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ą.

Nikolay Fominyh
źródło
1
Dziękuję za odpowiedź. Czy możesz opisać, co rozumiesz przez „aplikację nadzorczą”?
smp7d,
W kilku słowach - to jest supervisord.org . Meta program kontrolujący status i wykonywanie innych procesów. Możesz łatwo opracować własne rozwiązanie, które będzie pasować do twoich potrzeb. Mam dużo okresowych zadań w moim projekcie i github.com/ask/django-celery pomaga mi wydostać się z crona.
Nikolay Fominyh
Dzięki, przyjrzę się nadzorcy. Celem korzystania z narzędzia CI było uniemożliwienie nam napisania własnego narzędzia. Narzędzie CI jest zręczne, jak może być już.
smp7d,
1
Chyba nie mam przedstawiciela, który zagłosuje za tym, ale to dość okropna odpowiedź - szkoda, że ​​dostał nagrodę. Co sprawia, że ​​narzędzie jest „właściwym narzędziem”? Nawet jeśli ma dokładnie wszystkie potrzebne komponenty, jest to „złe narzędzie”, ponieważ nazywa się to systemem CI?
DougW,
1

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.

As w dziurze
źródło
Być może ma to zastosowanie, ale nie jestem pewien, czy jest to już więcej przypadek zastosowania niewłaściwego narzędzia, jakim byłby CI. Mam wrażenie, że ESB będzie wykorzystywany, gdy potrzebna będzie komunikacja lub choreografia procesowa. W tym przypadku chcemy tylko centralnego zarządzania dla szeregu niezależnych procesów. Nie przeszkadza nam uruchamianie niestandardowych poleceń Linuksa przez centralne zarządzanie, więc każda agnostycyzm w OS / Programming Language jest prawdopodobnie przesadą. Prawdopodobnie warto się temu przyjrzeć, dzięki.
smp7d,
Jeśli jesteś sklepem uniksowym, zdecydowanie skorzystaj z tego, wiem, że IBM ma produkt w swojej linii websphere, i istnieją również metody internetowe, które są komercyjne, a appache ma ofertę open source; masz rację w swojej definicji ESB, niestety ESB stał się nieco niejednoznaczny w jego użyciu, ale zastanów się, czy w końcu chcesz dodać scentralizowane raportowanie błędów lub jakiekolwiek inne raportowanie, takie jak „czy to się stało” w twoim procesie, który jest choreografia.
aceinthehole
@ smp7d Wiem, że serwer integracyjny webMethods ma obsługę planowania pierwszej klasy. Działa dobrze.
Robert Grant,
1

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.

Stephen Senkomago Musoke
źródło
To są dobre myśli. Uważasz więc, że to, czego szukam, nie istnieje i że narzędzie CI nie jest rozsądną alternatywą?
smp7d,
Może istnieć, ale pragmatyzm co do tego, czego używasz, może spowodować, że nadal będziesz mieć zadania crona i skrypty bash. Jednak korzystanie ze środowiska CI może być później przeszkodą, ponieważ CI jest głównie przeznaczony do przepływów pracy programistycznej, ale gdy środowisko dojrzewa, szukasz rozwiązań związanych z operacją. Później możesz zdecydować się na przeniesienie kontroli wersji / CI do chmury, nie chcesz, aby się to ugrzęzło, ponieważ codzienne operacje w Twojej organizacji.
Stephen Senkomago Musoke
Myśleliśmy, że użyjemy oddzielnego narzędzia CI do zarządzania procesami, ale rozumiem, co mówisz.
smp7d,
Ponieważ patrzysz na oddzielny CI, dlaczego nie spojrzeć na narzędzia skoncentrowane na zarządzaniu procesami, monitorowaniu i raportowaniu. W ten sposób wykorzystujesz wysiłek, aby skonfigurować CI w celu uzyskania odpowiedniego narzędzia do pracy, jeśli się nie powiedzie, masz CI, na którym można
polegać
Zgadzam się, że jest to najbardziej rozsądna droga. Zalecano program Quartz Scheduler, supervisord.org i ESB. Czy masz jakieś dodatkowe zalecenia lub przemyślenia na ich temat? (też: Kiedy powiedziałem osobne CI, miałem na myśli kolejną instalację naszego obecnego narzędzia z być może nowym brandingiem ... konfiguracja nie byłaby problemem)
smp7d
0

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.

Archimedes Trajano
źródło
Twoje zalecenie doprowadziło mnie do tego ... en.wikipedia.org/wiki/Job_scheduler - Zaskakująco nikt nigdy nie wspominał o tej nazwie dla takiego narzędzia. Być może tego właśnie szukałem, ponieważ jest przeznaczony do robienia tego, czego szukam, czas prawdopodobnie pokaże, że robi to lepiej niż narzędzie CI. Potrzeba jednak kilku badań, aby to zweryfikować.
smp7d,