Là Beanstalk đàn hồi phù hợp cho CD cấp doanh nghiệp?


11

Tôi đang làm việc với một dự án sử dụng Jenkins để xây dựng và triển khai các dịch vụ siêu nhỏ cho Elastic Beanstalk. Chúng tôi triển khai một nhánh tích hợp vào một môi trường thử nghiệm, phát hành các nhánh sang môi trường dàn dựng và sau đó là bản dựng chính cuối cùng để sản xuất. Tôi có một vài mối quan tâm khi thực hiện theo cách này: đầu tiên, điều đó có nghĩa là chúng tôi kết thúc với một ma trận một bản dựng cho mỗi dự án cho mỗi môi trường, nhân đôi nỗ lực; và hai, điều đó có nghĩa là chúng tôi không triển khai các tạo tác xây dựng giống nhau cho sản xuất đã được xác nhận trong dàn dựng.

Tôi có xu hướng từ bỏ Beanstalk và chuyển sang các ASG đơn giản bằng cách sử dụng thứ gì đó như Chef để triển khai. Điều đó sẽ để lại cho chúng tôi một bản dựng cho mỗi dự án, tạo ra một tạo tác xây dựng và chúng tôi có thể triển khai cùng một vật phẩm để sản xuất đã được phê duyệt trong dàn dựng. Tuy nhiên, quá trình chuyển đổi có chi phí trả trước không đáng kể. Có cách nào để sử dụng Beanstalk tốt hơn cho phép CI / CD đáng tin cậy hơn, dễ quản lý hơn không?

Lưu ý : Quảng bá cùng một tạo phẩm xây dựng là chính xác những gì tôi muốn làm, nhưng từ các tài liệu tôi không thấy bất kỳ cách rõ ràng nào để làm điều đó; nó giải thích cách triển khai EB từ nguồn ứng dụng của bạn, nhưng không giải thích làm thế nào để quảng bá phiên bản hiện có sang môi trường khác, trừ khi tôi quản lý để cuộn ngay qua nó. Nếu bản thân nó có sẵn trong EB, có thể có một hạn chế trong plugin triển khai EB của Jenkins ngăn không cho nó được thực hiện trong Jenkins, nhưng tôi chưa thấy cách nào để làm điều đó.


Có phải môi trường Jenkins của bạn đang đặt ra bản dựng duy nhất cho mỗi hạn chế môi trường không? Tôi sử dụng Elastic Beanstalk để triển khai các ứng dụng và các tạo phẩm của ứng dụng được tải lên có thể được quảng bá (triển khai) đến nhiều môi trường tốt. Vì vậy, tôi không thực sự nhìn thấy những hạn chế mà bạn đang mô tả. Có vẻ như có thể có một cách bạn có thể sử dụng Cây đậu đàn hồi để làm những gì bạn muốn. Nhưng câu hỏi này khá rộng vì nó hiện đang đứng.
Andy Shinn

Tại sao bạn xây dựng lại tài sản của mình thay vì quảng bá cùng một tài sản sang các môi trường khác sau khi thử nghiệm?
Evgeny

Câu trả lời:


4

IMO cho rằng vấn đề của bạn không phải là với Bean Beanalk trong kịch bản đó, đó là với Jenkins, hoặc ít nhất là cách bạn đang sử dụng nó. Bạn thực sự nên tập trung vào việc xây dựng "một thứ" chỉ một lần, bất kể đó là gì.

Tiết lộ đầy đủ: Tôi làm việc cho Th ThinkWorks và cực kỳ thiên vị với GoCD. Tôi sẽ cố gắng đánh vần những gì tôi muốn nói là trung lập hết mức có thể. Tôi sẽ sử dụng tài liệu của công cụ của chúng tôi là ví dụ, nhưng hy vọng mọi người có thể ngoại suy hệ thống của họ.

Ở đâu đó trong đường ống của bạn, bạn đang xây dựng "đồ tạo tác". Đây có thể là nhị phân đại diện cho tất cả hoặc một phần ứng dụng của bạn hoặc chúng có thể là đầu ra từ bất kỳ số lượng công cụ nào như công cụ kiểm tra. Những cổ vật này nên được lưu trữ bởi hệ thống và không bao giờ được xây dựng lại. Sau đó, hệ thống sẽ tìm nạp cổ vật từ bản sửa đổi phù hợp khi cần thiết.

Ví dụ...

  1. Tôi xây dựng một tệp .jar và chạy một số bài kiểm tra đơn vị trên đó, công cụ C / I cơ bản. Nếu nó vượt qua, tệp .jar đó và đầu ra của các bài kiểm tra sẽ được tải lên công việc đường ống cụ thể đó .
  2. Các đường ống tiếp theo có thể là việc bạn triển khai đến một môi trường thử nghiệm phức tạp hơn. Nó nên lấy jar chính xác từ công việc chính xác đã xây dựng nó. Sau đó, nó thực thi Elastic Beanstalk để triển khai jar đó đến đúng môi trường.
  3. Các đường ống tiếp theo là triển khai dàn của bạn. Nó đi ngược trở lại đường ống đầu tiên và lấy bình chính xác từ công việc chính xác đã xây dựng nó. Sau đó, thực hiện Elastic Beanstalk để triển khai jar đó đến đúng môi trường.

Đây là mỗi đường ống riêng biệt vì cho phép bạn chạy song song hoặc theo yêu cầu mà không bị chặn.

Bạn có thể sử dụng Elastic Beanstalk, Chef, Puppet, Ansible, uDeploy hoặc bất kỳ công cụ nào khác để thực hiện các triển khai thực tế. Đó không phải là vấn đề của bạn đến từ đâu. Máy chủ tích hợp liên tục không được xây dựng ban đầu để làm điều này. Tất nhiên, có rất nhiều plugin bạn có thể sử dụng để đến cùng một địa điểm nếu đó là sở thích của bạn.

Các máy chủ phân phối liên tục như GoCD , Chef Tự động hóaConcourseCI được xây dựng đặc biệt để giải quyết mọi thứ như thế này.


Có, mục tiêu của tôi là xây dựng một lần và thúc đẩy sản xuất. Câu hỏi của tôi là liệu beanstalk có phù hợp với loại sử dụng này không. Từ những gì tôi có thể nói, nó thực sự không có vẻ gì; ví dụ, phương pháp được đề xuất để triển khai một ứng dụng .NET là làm như vậy từ visual studio, đây chỉ là cách thực hành tồi tệ nhất mà tôi có thể nghĩ ra.
Adrian

Tôi đã không sử dụng nó một cách cá nhân, nhưng có vẻ như nó sẽ là nếu bạn thay đổi từ "quảng bá" thành "triển khai". Hệ thống CD của bạn gọi beanstalk để triển khai để kiểm tra, chạy một số thử nghiệm và sau đó báo cáo thành công / thất bại. Nếu thành công, hệ thống CD của bạn gọi beanstalk để triển khai để dàn dựng, v.v. Vì vậy, quảng cáo được thực hiện bởi công cụ điều phối của bạn, việc triển khai được thực hiện bởi công cụ triển khai của bạn. (FYI, đây là lý do tại sao các công ty như Chef có Hibernate (điều), Tự động hóa (thúc đẩy điều) và Chef (triển khai điều).
Ken Mugrage

FYI, có vẻ như bạn có thể viết kịch bản (cơ sở hạ tầng dưới dạng mã là "điều tốt") docs.aws.amazon.com/elasticbeanstalk/latest/dg/ Lỗi - nhưng một lần nữa, hoàn toàn 0 kinh nghiệm cá nhân.
Ken Mugrage

Bất kể bạn sử dụng từ gì, beanstalk dường như không làm điều đó, theo như tôi có thể nói. Nó dường như được hướng tới việc triển khai từ nguồn, không phải từ các tạo tác. Từ trang bạn đã liên kết: "Khi bạn chạy eb triển khai, EB CLI gói nội dung của thư mục dự án của bạn và triển khai nó vào môi trường của bạn." Tôi đánh giá cao câu trả lời nhưng câu hỏi của tôi là dành riêng cho beanstalk vì vậy hy vọng ai đó có kinh nghiệm về beanstalk có thể kêu vang.
Adrian

À, xin lỗi về điều đó. Tôi đã giải thích ~/eb$ eb deploy Creating application version archive "app-150630_014338". Uploading elastic-beanstalk-example/app-150630_014338.zip to S3có nghĩa là bất kỳ tập tin zip bạn bị mắc kẹt trong thư mục đó. Chúc may mắn!
Ken Mugrage
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.