Có hợp lý để chạy các quy trình với các công cụ CI?

Tại công ty của tôi, chúng tôi có một loạt các công việc khác nhau (trên nhiều hệ thống) và tự khởi động các quy trình giữ cho hoạt động kinh doanh của chúng tôi là kết quả của nhiều năm phát triển nhanh chóng và bỏ bê sau đó.

Một ngày nào đó, chúng ta sẽ cần đưa ra một giải pháp tập trung hơn vì những lý do rõ ràng.

Một người nghĩ rằng chúng tôi đã và đang sử dụng phần mềm Tích hợp liên tục (Jenkins) để chạy các quy trình này, điều này có vẻ hợp lý.

Câu hỏi của tôi là: Các công ty khác đang làm điều này? Đây có phải là một thực tế thường được chấp nhận? Điều này có mâu thuẫn với định nghĩa của một công cụ CI ẩn trong tên của nó không? Có sự lựa chọn nào khác không?

Lưu ý: https://wiki.jenkins-ci.org/display/JENKINS/Meet+Jenkins

Jenkins tuyên bố rằng nó tập trung vào "Giám sát việc thực hiện các công việc được điều hành từ bên ngoài, chẳng hạn như công việc định kỳ và công việc procmail". Tôi không chắc đây có phải là chính xác những gì tôi đang nói không.

Chúng tôi đã sử dụng Jenkins như một người bạn thân trong vài năm nay và đây là một số ưu và nhược điểm:

Ưu

• Nếu bạn đang quản lý một số lượng lớn các quy trình trên hàng tá máy chủ và nhiều môi trường, điều đó làm cho nhiều việc trở nên dễ dàng hơn. Bạn nhận được thông báo qua email, bảng điều khiển chung cho mọi thứ, giao diện web cho nhật ký và cách dễ dàng để thiết lập các nút bổ sung để chạy công việc. Các nhóm hỗ trợ đặc biệt đánh giá cao việc có vị trí trung tâm này để kiểm tra các vấn đề và chạy lại công việc.

• Hệ sinh thái trình cắm thêm của Jenkins rất tích cực và cung cấp một loạt các chức năng bổ sung ... Tôi nghĩ rằng đây thực sự là tính năng 'sát thủ' của Jenkins, vì nếu chính Jenkins không cung cấp những gì bạn đang tìm kiếm (thường là vậy) thường không có plugin nào. Một số mục yêu thích của tôi: Cột Cron, Rebuild, Tham số NodeLabel, Trình phân tích cú pháp Đăng nhập và Email-ext.

• Hỗ trợ lập lịch / kích hoạt nâng cao: Cú pháp lịch biểu về cơ bản là cron, do đó bạn có tính linh hoạt tương tự ở đó, nhưng điều này được bổ sung bởi Triggers, API REST và API Groovy / Java

Nhược điểm

• Điểm trung tâm của sự thất bại: Bởi vì tất cả các công việc của bạn bị khởi động bởi một máy chủ, nếu hộp đó bị hỏng và không ai nhận thấy, Rắc rối lớn. Vì vậy, tốt hơn hết bạn nên có sự giám sát tốt để bắt kịp sự cố ngay lập tức, cũng như tất cả các cấu hình của bạn được lưu trong kiểm soát nguồn. Ngay cả khi bạn không thể sao lưu máy chủ gốc, miễn là bạn có cấu hình công việc của mình, việc cài đặt chúng ở một nơi khác không quan trọng. Nếu thời gian để giải quyết là một mối quan tâm, có một chế độ chờ được cấu hình sẵn ở đâu đó có lẽ cũng là một ý tưởng tốt.

• Nếu bạn có nhiều môi trường (Dev, UAT, Prod), thông thường bạn có các phiên bản công việc hơi khác nhau đang chạy trên mỗi môi trường. Có tất cả các công việc này trên một Jenkins có thể trở nên khó sử dụng, và cấu hình thủ công chúng trở thành một nỗi đau rất lớn. Trong trường hợp của chúng tôi, chúng tôi chạy một cá thể 'Cron' riêng của Jenkins cho từng môi trường. Các phiên bản được cài đặt và cấu hình tự động bằng công cụ triển khai trong nhà. Bạn có thể không có cái gì đó tương tự, nhưng có những công cụ nguồn mở thực hiện những điều tương tự (tạo cấu hình bằng các mẫu). Nếu bạn có thể giải quyết vấn đề tạo cấu hình, điều này giúp cho việc thiết lập và triển khai Jenkins dễ dàng hơn nhiều và cũng giúp việc kiểm soát nguồn của bạn dễ dàng hơn.

• Nâng cấp Jenkins đôi khi phá vỡ chức năng, đặc biệt là với các plugin. Đừng nâng cấp nhiệm vụ quan trọng của Jenkins cho đến khi bạn thử phiên bản mới ở nơi khác trước. Đây là nơi có một môi trường Dev gương với ví dụ Jenkins của riêng nó thực sự tiện dụng.

Một điều có lẽ cần nhấn mạnh: Chúng tôi thực sự cũng sử dụng Jenkins cho CI, nhưng đây là một trường hợp riêng biệt ... các trường hợp 'cron' được dành riêng cho quản lý công việc và ví dụ 'CI' dành riêng cho CI. Tách các mối quan tâm dường như làm cho mọi thứ sạch hơn.

Là một lưu ý phụ, tôi sử dụng Jenkins thay vì cron trên hộp Linux của tôi ở nhà :)

Nhân tiện, đây thực sự là một trường hợp sử dụng Jenkins khá phổ biến. Ví dụ: Phòng thí nghiệm quốc gia Sandia sử dụng Jenkins theo cách này: https://software.sandia.gov/trac/fast/wiki/Hudson

Và có rất nhiều bài viết blog và hướng dẫn mô tả điều này. Dưới đây là một vài ví dụ: http://blog.vuksan.com/2011/08/22/USE-jenkins-as-a-cron-server/

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

Tôi cũng nên nói thêm rằng điều này thực sự chỉ liên quan đến Jenkins, và không phải tất cả các công cụ CI nói chung. Chỉ vì Jenkins rất phù hợp để làm điều này không có nghĩa là những người khác (TeamCity, buildbot, v.v.) là ...

Tôi có thể nói rằng bạn không sử dụng đúng công cụ cho công việc ở đây vì điểm chính của các công cụ CI là họ giám sát một cái gì đó - mã nguồn của bạn thông thường - và khi có thay đổi, họ sẽ khởi động xây dựng / triển khai / bất cứ điều gì .

Tuy nhiên, các công cụ này có thể chạy các công việc được lên lịch (chẳng hạn như TeamCity), vì vậy bạn có thể triển khai một trang web (ví dụ) khi không có ai xung quanh. Vì vậy, có một danh sách trung tâm duy nhất của tất cả các nhiệm vụ bạn chạy trong thực tế là một ý tưởng tốt. Các công cụ cũng sẽ cho phép bạn quyết định thời gian và tần suất các công việc này được chạy.

Một lợi ích khác là bạn thậm chí có thể giám sát hệ thống từ xa (nếu bạn muốn).

Vì vậy, về sự cân bằng, tôi muốn nói rằng đó là một điều hợp lý để làm.

Có vẻ như cron đã là một công cụ thích hợp cho nhu cầu của bạn. Tôi khuyên bạn nên bắt đầu bằng cách ghi lại hệ thống của bạn tốt hơn. Kiểm tra các hệ thống khác nhau và tập hợp một danh sách toàn diện các quy trình chạy trên máy nào.

Sau đó xem xét chỉ định một máy chuyên dụng để chạy tất cả các quy trình cron này. Đảm bảo rằng bạn ghi lại tài liệu của máy này và gán các đặc quyền quản trị viên phù hợp để kiểm soát nó. Đặt tất cả các cronjobs trên máy đó và sau đó bạn đã có một điểm kiểm soát trung tâm cho các quy trình tự động khác nhau của mình.

Phản ứng ruột của tôi cũng vậy, rằng bạn đang sử dụng một công cụ có khái niệm về lịch trình trong đó, để thực hiện công việc của một người lập lịch công việc.

Bạn đã không đề cập đến công việc của bạn là gì, nhưng việc bạn đề cập đến CRON khiến tôi đoán chúng là các tập lệnh shell, v.v. Có các gói lập lịch công việc thương mại và nguồn mở ngoài kia. Đôi khi chúng được gọi là lịch trình hàng loạt. Một số sẽ chỉ gói CRON và làm cho nó thân thiện hơn. Một số, như bộ lập lịch Quartz, quản lý công việc mạnh mẽ, nhưng yêu cầu chúng phải được thực hiện như các lớp Java. Bạn có khả năng có thể sử dụng điều đó và kết thúc các cuộc gọi thời gian chạy đến các tập lệnh khác nhau của bạn bằng cách sử dụng trình bao bọc java. Tôi tin rằng bạn sẽ tìm thấy nhiều lựa chọn nếu bạn nhìn xa hơn.

Không sử dụng CI để chạy các tác vụ định kỳ không liên quan đến bản dựng.

Cũng nên tránh cron cho các nhiệm vụ không liên quan đến bảo trì hệ thống.

Sử dụng đúng công cụ. Đối với nhu cầu ứng dụng - hãy thử sử dụng các giải pháp dựa trên AMQP.

PS tôi thấy, cron đó phù hợp với trường hợp của bạn. Mặt khác, bạn có rất nhiều nhiệm vụ - vì vậy hãy thử viết ứng dụng giám sát cho họ.

Bạn cần sử dụng xe buýt dịch vụ doanh nghiệp (ESB) cho loại nhiệm vụ này.

Bây giờ nền của tôi là trong windows / BizTalk, nhưng tôi chắc chắn rằng tất cả các tương đương tồn tại ở phía unix của mọi thứ là tốt. Những gì chúng ta thường làm là thiết lập các quy trình trên hộp BizTalk chịu trách nhiệm khởi động mọi thứ trên hộp kia, theo dõi tiến trình / lỗi và báo cáo lại trạng thái cho cổng thông tin SharePoint (hoặc web) hoặc gửi email và như vậy nếu nó cần sự chú ý.

Lợi ích của phương pháp này là tất cả các cấu hình và quản lý các quy trình kinh doanh khác nhau của bạn được đặt ở vị trí trung tâm, vì vậy bạn biết nơi để bắt đầu tìm kiếm. Phần mềm đã tồn tại cho phép bạn trừu tượng hóa phần mã hóa khỏi cấu hình vật lý (trong BizTalk, bạn có thể lập trình dựa trên 'cổng' logic như máy chủ sql, sau đó trong prod, nếu hộp sql thay đổi vị trí hoặc được nâng cấp hoặc bất cứ điều gì, bạn có thể thay đổi cổng vật lý được cấu hình bằng công cụ quản trị của họ, một lần nữa, tôi chắc chắn tương đương tồn tại ở phía unix).

Lợi ích của việc sử dụng các công cụ CI sẽ là những thứ như, nếu quá trình của bạn bị lỗi, bạn có thể tự động gửi lại tin nhắn và bạn có thể thiết lập một môi trường chuyển đổi dự phòng, có hệ thống ghi và ghi nhật ký phù hợp hơn; đồng thời, khi bạn đã có hệ thống, nó sẽ cho phép bạn bắt đầu kiến ​​trúc tổ chức của mình để sử dụng hoặc sử dụng tốt hơn SOA. Mặt trái là tùy thuộc vào quy mô tổ chức của bạn, nỗ lực phát triển có thể cao và chi phí cấp phép có thể bị cấm.

Về mặt lý thuyết, bạn nên có một vị trí duy nhất để kiểm soát tất cả các công việc khác nhau, tuy nhiên dựa trên kinh nghiệm trong ngành giống như "Chén Thánh", bạn sẽ cần các công việc định kỳ ở đây, bash script ở đó và cli script ở đây.

Ngoài ra còn có một câu thần chú "Nếu nó không bị hỏng, đừng sửa nó", vì vậy trong khi họ đang cố gắng, ban đầu hãy tập trung vào việc ghi lại những đoạn script bạn đang chạy, những gì họ làm và những gì họ chạm vào để bạn "biết "Làm thế nào doanh nghiệp của bạn đang được điều hành.

Sau đó, như một chiến lược dài hạn thiết lập một hệ thống tập trung để điều hành các công việc, hãy chọn giải pháp của bạn một cách khôn ngoan vì bạn sẽ phải sống với nó. Sau đó, đối với mỗi yêu cầu thay đổi, nâng cao, nâng cấp, sửa lỗi hoặc giải pháp mới mà bạn thêm vào trong kiến ​​trúc doanh nghiệp của mình, hãy đảm bảo rằng các tác vụ được lên lịch và tự động của nó được thêm vào "giải pháp kiểm soát doanh nghiệp" của bạn.

Bằng cách đó, bạn dần dần di chuyển từ một loạt các tập lệnh sang một môi trường thân thiện với doanh nghiệp hơn.

Trong các hệ thống doanh nghiệp lớn mà tôi làm việc cùng, họ có xu hướng sử dụng một công cụ được thiết kế để lên lịch. Loại phổ biến nhất mà tôi đã sử dụng là CA7. Nó cho phép bạn tập trung tất cả các lịch trình cho tất cả các hệ thống của bạn.

Cron thường được sử dụng cho một máy, mặc dù bạn có thể "hack nó" bằng cách thực hiện các cuộc gọi từ xa ssh. Tuy nhiên, nó sẽ không có khái niệm về sự phụ thuộc và những thứ khác. Khi nói đến các nhóm hoạt động trong đó phạm vi của họ thậm chí còn hạn chế hơn, tốt nhất là sử dụng một công cụ.