CI 도구로 프로세스를 실행하는 것이 합리적입니까?

우리 회사에는 여러 시스템에서 서로 다른 크론 작업에 대한 소동이 있었고 수동으로 프로세스를 시작하여 수년간의 편리한 개발과 그로 인한 소홀의 결과로 비즈니스 기능을 유지했습니다.

언젠가는 분명한 이유로보다 중앙 집중화 된 솔루션을 마련해야합니다.

우리가 생각하고있는 한 가지 생각은 Continuous Integration 소프트웨어 (Jenkins)를 사용하여 이러한 프로세스를 실행하는 것입니다. 이는 논리적으로 보입니다.

내 질문은 : 다른 회사가 이것을하고 있습니까? 이것이 일반적으로 인정되는 관행입니까? 이것이 이름에 내재 된 CI 도구의 정의와 충돌하지 않습니까? 다른 옵션이 있습니까?

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

Jenkins는 "크론 작업 및 procmail 작업과 같은 외부 실행 작업의 실행 모니터링"에 중점을두고 있다고 주장합니다. 이것이 내가 말하는 것과 정확히 일치하는지 잘 모르겠습니다.

우리는 몇 년 동안 Jenkins를 cron 드롭으로 사용 해 왔으며 다음과 같은 장단점이 있습니다.

찬성

• 수십 개의 서버와 여러 환경에서 많은 수의 프로세스를 관리하는 경우 많은 작업이 쉬워집니다. 기본적으로 전자 메일 알림, 모든 것을위한 공통 대시 보드, 로그를위한 웹 인터페이스 및 추가 노드를 설정하여 작업을 실행할 수있는 쉬운 방법이 제공됩니다. 지원 팀은 특히 문제를 확인하고 작업을 다시 실행하기 위해이 중앙 위치에 있다는 점을 높이 평가합니다.

• Jenkins 플러그인 생태계는 매우 활발하고 추가 기능을 많이 제공합니다 ... Jenkins 자체가 원하는 것을 제공하지 않는 경우이 경우 실제로 Jenkins의 '킬러'기능이라고 생각합니다. 종종 플러그인이 없습니다. 내가 좋아하는 것 중 일부는 Cron Column, Rebuild, NodeLabel Parameter, Log Parser 및 Email-ext입니다.

• 고급 스케줄링 / 트리거 지원 : 스케줄 구문은 기본적으로 cron이므로 유연성이 동일하지만 트리거, REST API 및 Groovy / Java API가 보완됩니다.

단점

• 중앙 장애 지점 : 모든 작업이 하나의 서버에서 시작되므로 해당 상자가 작동 중지되고 아무도 알지 못하는 경우 큰 문제입니다. 따라서 소스 제어에 저장된 모든 구성뿐만 아니라 중단을 즉시 포착 할 수있는 좋은 모니터링 기능이 있습니다. 원래 서버를 백업 할 수 없더라도 작업 구성이있는 한 다른 서버를 설정하는 것은 쉽지 않습니다. 해결 시간이 문제가 될 경우 대기 사전 설정을하는 것이 좋습니다.

• 여러 환경 (Dev, UAT, Prod)이있는 경우 일반적으로 각 환경에서 실행되는 작업 버전이 약간 다릅니다. 이러한 모든 작업을 하나의 Jenkins에 두는 것은 어려워 질 수 있으며 수동으로 구성하는 것은 큰 고통이됩니다. 이 경우 각 환경에 대해 별도의 Jenkins 'Cron'인스턴스를 실행합니다. 인스턴스는 사내 배포 도구를 사용하여 자동으로 설치 및 구성됩니다. 그런 것이 없을 수도 있지만 비슷한 일을하는 오픈 소스 도구가 있습니다 (템플릿을 사용하여 구성 생성). 구성 생성 문제를 해결할 수 있으면 Jenkins를 설정하고 배포하는 것이 훨씬 쉬워지고 모든 항목을 소스 제어로 유지하는 것이 더 쉬워집니다.

• Jenkins를 업그레이드하면 기능, 특히 플러그인의 기능이 중단되는 경우가 있습니다. 먼저 다른 곳에서 새 버전을 시도 할 때까지 미션 크리티컬 Jenkins 인스턴스를 업그레이드하지 마십시오. 여기에는 자체 Jenkins 인스턴스가있는 미러 개발 환경이 매우 유용합니다.

한 가지 강조해야 할 점 : 우리는 실제로 CI에도 Jenkins를 사용하지만 이것은 별도의 인스턴스입니다. 'cron'인스턴스는 작업 관리 전용이며 'CI'인스턴스는 CI 전용입니다. 우려를 분리하면 일이 더 깨끗해 보입니다.

참고로, 나는 집에있는 Linux 상자에서 cron 대신 Jenkins를 사용합니다 :)

그건 그렇고, 이것은 실제로 꽤 일반적인 Jenkins 유스 케이스입니다. 예를 들어 Sandia National Lab은 다음과 같이 Jenkins를 사용합니다. https://software.sandia.gov/trac/fast/wiki/Hudson

그리고 이것을 설명하는 수많은 블로그 게시물과 튜토리얼이 있습니다. 다음은 몇 가지 예입니다. http://blog.vuksan.com/2011/08/22/using-jenkins-as-a-cron-server/

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

또한 이것이 실제로 모든 CI 도구가 아니라 Jenkins와 관련이 있다는 점도 덧붙여 야합니다. Jenkins가 적합하기 때문에 다른 사람들 (TeamCity, buildbot 등)이 ...

CI 도구의 주요 요점으로 작업에 적합한 도구를 사용하지 않는다고 말했을 것입니다. 일반적으로 소스 코드를 모니터링하고 변경이있을 때 빌드 / 배포 / 무엇을 시작하는지 .

그러나 이러한 도구 는 예약 된 작업 (예 : TeamCity가 수행)을 실행할 수 있으므로 주변에 사람이 없을 때 웹 사이트를 배포 할 수 있습니다. 따라서 실행하는 모든 작업의 ​​단일 중앙 목록을 갖는 것이 좋습니다. 도구를 사용하면 이러한 작업을 언제, 얼마나 자주 실행할지 결정할 수 있습니다.

또 다른 이점은 시스템을 원격으로 모니터링 할 수도 있다는 것입니다 (원하는 경우).

균형 잡히면, 그것이 합리적인 일이라고 말하고 싶습니다.

cron이 이미 귀하의 요구에 적합한 도구 인 것 같습니다. 시스템을 더 잘 문서화하여 시작하는 것이 좋습니다. 다양한 시스템을 감사하고 어떤 시스템에서 어떤 프로세스가 실행되는지에 대한 포괄적 인 목록을 작성하십시오.

그런 다음 이러한 모든 크론 프로세스를 실행할 전용 머신을 지정하십시오. 이 컴퓨터가 어떤 컴퓨터인지 문서화하고이를 제어하기위한 적절한 관리자 권한을 할당하십시오. 모든 크론 작업을 해당 시스템에 배치하면 다양한 자동화 프로세스를 중앙에서 제어 할 수 있습니다.

내 직감 반응은 일정 계획 개념이있는 도구를 사용하여 작업 스케줄러의 작업을 수행하는 것과 같습니다.

당신은 당신의 직업이 무엇인지 언급하지 않았지만 CRON에 대한 언급은 그들이 쉘 스크립트 등으로 추측합니다. 오픈 소스 및 상용 작업 스케줄러 패키지가 있습니다. 때로는 배치 스케줄러라고도합니다. 일부는 CRON을 마무리하고 더 친숙하게 만듭니다. Quartz 스케줄러와 같은 일부는 강력한 작업 관리를 수행하지만 Java 클래스로 구현해야합니다. 잠재적으로 그것을 사용할 수 있으며 java 래퍼를 사용하여 다양한 스크립트에 대한 런타임 호출을 마무리합니다. 더 자세히 살펴보면 많은 옵션을 찾을 수 있다고 생각합니다.

빌드와 관련이없는 주기적 작업을 실행하기 위해 CI를 사용하지 마십시오.

또한 시스템 유지 보수와 관련이없는 작업에 대해서는 cron을 사용하지 마십시오.

올바른 도구를 사용하십시오. 응용 프로그램 요구의 경우 AMQP 기반 솔루션을 사용해보십시오.

추신 : 나는 그 cron이 당신의 경우에 적합하다는 것을 알았습니다. 반면에 많은 작업이 있으므로 관리자 응용 프로그램을 작성하십시오.

이 유형의 작업에는 ESB ( Enterprise Service Bus) 를 사용해야합니다 .

이제 내 배경은 windows / BizTalk에 있지만 모든 해당 항목이 유닉스 측면에도 존재한다고 확신합니다. 우리가 일반적으로하는 일은 BizTalk 상자에서 다른 상자의 작업을 시작하고 진행 상황 / 오류를 모니터링하며 상태를 SharePoint (또는 웹) 포털에 다시보고하거나 전자 메일을 보내는 프로세스를 설정하는 것입니다. 주의가 필요한 경우.

이 접근 방식의 이점은 다양한 비즈니스 프로세스의 모든 구성 및 관리가 중앙에 위치하고 있으므로 어디에서 찾아야하는지 알 수 있습니다. 물리적 구성에서 코딩 부분을 추상화 할 수있는 소프트웨어가 이미 존재합니다 (BizTalk에서는 SQL Server와 같은 논리적 '포트'에 대해 프로그래밍 한 다음 SQL 상자의 위치가 변경되거나 업그레이드 된 경우 등 관리 도구를 사용하여 구성된 실제 포트를 변경할 수 있습니다. 유닉스쪽에 해당 항목이 있음을 확신합니다.

CI 도구를 사용하는 것의 이점은 프로세스 오류가 자동으로 물리적으로 메시지를 다시 제출할 수 있고 레코드 및 로깅 시스템에 더 적합한 클러스터 된 페일 오버 환경을 설정할 수있는 경우와 같은 이점이 있습니다. 또한 일단 시스템을 구축하면 조직에서 SOA를보다 잘 활용하도록 설계 할 수 있습니다. 단점은 조직의 규모에 따라 개발 노력이 높을 수 있으며 라이센스 비용이 엄청날 수 있다는 것입니다.

이론적으로 모든 분리 된 작업을 제어 할 수있는 단일 위치를 갖는 것이 합리적이지만 "성배"와 같은 업계 경험을 바탕으로 여기에는 크론 작업, 여기에는 bash 스크립트 및 여기에 cli 스크립트가 필요합니다.

또한 "파산하지 않으면 고치지 말 것"이라는 문구가 있습니다. 따라서 플로팅하는 동안 먼저 실행중인 스크립트, 스크립트 및 수행하는 시스템을 문서화하여 "알아두기" "비즈니스 운영 방식.

그런 다음 장기 전략으로 작업을 실행하기위한 중앙 집중식 시스템을 설정하려면 솔루션을 함께 사용해야하므로 현명하게 솔루션을 선택하십시오. 그런 다음 비즈니스 아키텍처 내에 추가하는 각 변경 요청, 개선, 업그레이드, 버그 수정 또는 새로운 솔루션에 대해 예약되고 자동화 된 작업이 "엔터프라이즈 제어 솔루션"에 추가됩니다.

이렇게하면 스크립트 배치에서보다 엔터프라이즈 친화적 인 환경으로 점차 마이그레이션 할 수 있습니다.

내가 작업 한 대기업 시스템에서는 일정을 위해 설계된 도구를 사용하는 경향이 있습니다. 내가 사용한 가장 인기있는 것은 CA7입니다. 모든 시스템에 대한 모든 스케줄링을 중앙 집중화 할 수 있습니다.

Cron은 일반적으로 단일 컴퓨터에 사용되지만 ssh 원격 호출을 통해 "해킹"할 수 있습니다. 그러나 종속성 및 기타 개념의 개념은 없습니다. 범위가 훨씬 제한된 운영 팀의 경우 도구를 사용하는 것이 가장 좋습니다.