Tôi có nên bao gồm các thử nghiệm trong hình ảnh Docker?


18

Khi nói đến các bài kiểm tra, tôi có thể nghĩ đến hai lựa chọn:

  1. Đặt cả thử nghiệm và ứng dụng trong một hình ảnh.
  2. Chỉ bao gồm mã ứng dụng trong hình ảnh. Tạo một thùng chứa dành riêng cho thử nghiệm xây dựng sau hình ảnh chính và thêm một số lớp vào nó (mã kiểm tra, phụ thuộc, v.v.).

Với tùy chọn đầu tiên, tôi có thể kiểm tra container và vận chuyển chính xác như đã kiểm tra. Một nhược điểm rõ ràng là mã không cần thiết (và có khả năng dữ liệu thử nghiệm) sẽ được đưa vào hình ảnh.

Với tùy chọn thứ hai, hình ảnh được gửi không hoàn toàn giống với hình ảnh được thử nghiệm.

Cả hai trông giống như chiến lược xấu. Có một chiến lược thứ ba, tốt hơn?


1
Bạn cơ bản trả lời. Cả hai đều là ý tưởng tồi. Bạn sẽ gửi các quy trình có thể chạy được thử nghiệm vào một thùng chứa có kích thước và tùy chỉnh theo nhu cầu. Bạn không muốn phụ thuộc dev hay mã src. Trong sản xuất, nó được coi là một rủi ro.
Laiv

1
Kiểm tra trước khi container có nghĩa là môi trường không được kiểm tra, chỉ có mã là. Bạn sẽ chỉ kiểm tra một phần của những gì bạn đang vận chuyển, không phải tất cả trong số đó.
lfk

Câu trả lời:


10

Để chạy thử nghiệm thời gian xây dựng, cách ưa thích sẽ là sử dụng xây dựng nhiều giai đoạn . Dockerfiles nhiều giai đoạn cho phép bạn có một sân khấu lớn hơn với tất cả các phụ thuộc để xây dựng và thử nghiệm, sau đó sao chép các tạo phẩm chính xác mà bạn đã thử nghiệm vào một giai đoạn khác cho hình ảnh thời gian chạy nhỏ hơn.

Bạn cũng muốn kiểm tra mức hệ thống của nhiều container, sử dụng giao diện bên ngoài của chúng thay vì chạy trong container. Vì các thử nghiệm này liên quan đến sự phối hợp giữa các dịch vụ, yêu cầu các phụ thuộc khác nhau như quyền truy cập vào dàn nhạc của bạn, không triệt để như các thử nghiệm trong thời gian xây dựng và thường được viết bằng các ngôn ngữ hoàn toàn khác nhau, nên việc chạy chúng từ Docker riêng biệt không phải là vấn đề lớn container dành riêng để thử nghiệm hệ thống.


1
Vì vậy, đó là khá nhiều lựa chọn 2 - Tôi chạy thử nghiệm trong một môi trường / thùng chứa rất giống với sản xuất, nhưng không hoàn toàn giống nhau. Có đúng không?
lfk

9

Có một cách thứ ba, như bạn nói chính mình. Tôi nghĩ rằng bạn đang trộn lẫn phát triển, thử nghiệm và triển khai. Tôi đề nghị rằng toàn bộ SDLC phải được xem xét một cách tổng thể, trước tiên, để hiểu những gì bạn đang cố gắng đạt được. Đây là một chủ đề lớn, nhưng tôi sẽ cố gắng hết sức để tóm tắt.

TL; DR;

Nói tóm lại, bạn cần tách ra:

  • mã của bạn, từ
  • cấu hình ứng dụng, từ
  • cấu hình môi trường hệ thống.

Mỗi người cần độc lập với nhau và phù hợp:

  • kiểm soát phiên bản
  • thử nghiệm
  • có thể triển khai

Phiên bản dài hơn

Đầu tiên, bạn có một ứng dụng được tạo thành từ mã và (các bộ cấu hình) riêng biệt. Điều này cần phải được kiểm tra, đối với cả chức năng xây dựng và chức năng có chủ ý - đây được gọi là tích hợp liên tục (CI). Có nhiều nhà cung cấp dịch vụ này cả trực tuyến và cục bộ - ví dụ CircleCI cho nhà cung cấp đám mây liên kết với kho lưu trữ của bạn, xây dựng và kiểm tra bất cứ khi nào bạn cam kết. Nếu kho lưu trữ của bạn tại chỗ và không thể sử dụng nhà cung cấp đám mây, một cái gì đó như Jenkinssẽ là một tương đương. Nếu ứng dụng của bạn khá chuẩn, có thể có hình ảnh Docker hiện có mà dịch vụ CI có thể sử dụng. Nếu không, bạn sẽ phải tạo một hoặc một cụm như vậy, mã ứng dụng và cấu hình của bạn có thể được triển khai. Cấu hình chính xác, bạn sẽ có rất nhiều số liệu thống kê về chất lượng mã ứng dụng của bạn.

Tiếp theo, một khi bạn hài lòng với chức năng và tính chính xác của ứng dụng của mình, cơ sở mã phải được gắn thẻ phù hợp cho một bản phát hành cụ thể. Bản dựng này sau đó nên được triển khai vào môi trường thử nghiệm. Lưu ý rằng mã sẽ giống như được kiểm tra trong CI của bạn (có thể chứng minh là như vậy, nếu bạn đã thực hiện điều này một cách chính xác), nhưng cấu hình của bạn có thể khác. Một lần nữa, một số nhà cung cấp CI có thể cung cấp bước này để bạn có thể kiểm tra việc triển khai ứng dụng đóng gói và cấu hình riêng biệt. Giai đoạn này thường sẽ bao gồm kiểm tra chức năng người dùng (cho chức năng mới), cũng như kiểm tra tự động (cho chức năng đã biết). Nếu bản phát hành vượt qua giai đoạn này, bạn có một ứng cử viên phát hành để thử nghiệm tích hợp. Bạn có thể chạy thử nghiệm tự động hóa từ một container Docker khác,một số số liệu cho thấy nỗ lực kiểm tra trạng thái là 1: 1 cho nỗ lực mã hóa (mặc dù bản thân tôi không chắc chắn về điều này).

Áp chót, bước tiếp theo là nơi bạn xây dựng môi trường (hệ thống) của mình như thể nó đang sản xuất. Nếu bạn đang sử dụng Docker trong sản xuất, đây là nơi bạn sẽ nghĩ đến việc tăng cường bảo mật, tối ưu hóa mạng và máy chủ, v.v. Hình ảnh Docker của bạn có thể dựa trên những gì bạn đã sử dụng trong Phát triển (lý tưởng là như vậy), nhưng có thể có những thay đổi để mở rộng và bảo mật , như tôi đã nói. Đến bây giờ việc kiểm tra chức năng của ứng dụng đã hoàn tất, bạn quan tâm nhiều hơn đến bảo mật và hiệu suất. Theo thử nghiệm chức năng, các thử nghiệm của bạn ở đây có thể được phát triển, triển khai và chạy từ các hình ảnh Docker khác. Bước này từng rất tốn kém và hiếm khi được thực hiện để bạn cần phần cứng chuyên dụng thay thế cho sản xuất. Ngày nay, điều này là hoàn toàn khả thi khi bạn có thể đứng lên và phá hủy toàn bộ môi trường của hầu hết mọi quy mô theo yêu cầu.

Cuối cùng, bạn có một bản phát hành nên sẵn sàng sản xuất chỉ với một bộ deltas cấu hình nhỏ từ thử nghiệm tích hợp của bạn (địa chỉ IP, URI cơ sở dữ liệu, mật khẩu, v.v.) Cơ sở mã của bạn đã được kiểm tra ít nhất trong ba môi trường khác nhau điểm và phần lớn cấu hình hệ thống ít nhất một lần.


Điều đó có nghĩa là CI của bạn sẽ không kiểm tra Dockerfiles của bạn chứ? Ví dụ: nếu Dockerfile của bạn thiếu phụ thuộc, các bài kiểm tra vẫn vượt qua?
lfk

1
Không có gì. Đầu tiên kiểm tra mã, sau đó kiểm tra cấu hình ứng dụng, sau đó kiểm tra hệ thống. Điều tôi đang nói là đây là những hoạt động rời rạc. Điều tuyệt vời về container hóa là giấc mơ phát triển trong một môi trường giống như prod rất gần gũi. Nhưng sự cứng lại sẽ làm cho sự phát triển quá khó khăn.
avastmick

0

Tôi nghĩ rằng bạn đang trộn lẫn các loại thử nghiệm khác nhau. Về cơ bản bạn cần tự hỏi: đơn vị đang thử nghiệm ở đây là gì?

Kịch bản phổ biến nhất khi bạn làm việc với tư cách là nhà phát triển là viết các bài kiểm tra đơn vị / tích hợp cho một số đoạn mã bạn đang làm việc, trong đó đoạn mã đó là đơn vị được kiểm tra. Bạn chạy các thử nghiệm cục bộ và / hoặc trong CI.

Khi bạn đã xây dựng một hình ảnh docker mới, nó sẽ trở thành một đơn vị mới mà bạn có thể kiểm tra. Những loại điều bạn muốn kiểm tra cho hình ảnh này? API mà nó đang cung cấp là gì? Làm thế nào để bạn kiểm tra điều đó?

Nếu đó là một ứng dụng web, bạn có thể khởi động một thùng chứa dựa trên hình ảnh và thực hiện một số yêu cầu HTTP và kiểm tra xem các phản hồi có đúng như bạn mong đợi không. Vấn đề tôi nghĩ bạn đang gặp phải là bạn rất quen với khung kiểm tra được ghép với mã ứng dụng. Điều đó tốt trong quá trình phát triển, nhưng bây giờ bạn muốn kiểm tra hình ảnh docker và vì vậy bạn cần một loại khung kiểm tra mới có thể làm điều đó và không bị ràng buộc với mã ứng dụng.

Vì vậy, tôi nghĩ rằng tùy chọn thứ 3 mà bạn đang tìm kiếm là:

  • Chạy thử nghiệm đơn vị / tích hợp của bạn trước khi xây dựng hình ảnh docker.
  • Xây dựng hình ảnh docker chỉ chứa ứng dụng bạn muốn phân phối.
  • Thay vì thêm các lớp bổ sung lên trên hình ảnh ứng dụng đó, bạn kiểm tra nó như hiện tại bằng cách chạy nó với một số tham số đã cho và khẳng định kết quả đầu ra dự kiến ​​của bạn.

Vì vậy, các bước CI / CD sẽ là:

Thiết lập môi trường phát triển -> Chạy thử nghiệm trên mã -> Xây dựng hình ảnh cuối cùng -> Chạy thử nghiệm trên hình ảnh -> Triển khai hình ảnh.

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.