Bạn có thể xây dựng một vùng chứa với Dockerfile sau vài giây, vậy tại sao mọi người cần cài đặt môi trường ảo bên trong vùng chứa docker?Tại sao mọi người tạo virtualenv trong vùng chứa docker?
Nó giống như một "máy ảo" trong máy ảo?
Bạn có thể xây dựng một vùng chứa với Dockerfile sau vài giây, vậy tại sao mọi người cần cài đặt môi trường ảo bên trong vùng chứa docker?Tại sao mọi người tạo virtualenv trong vùng chứa docker?
Nó giống như một "máy ảo" trong máy ảo?
tôi đang làm việc với virtualenvs trong Docker và tôi nghĩ rằng có một số lý do:
Tôi nghĩ rằng đây là tất cả những lý do hợp lý để thêm một chút pip install virtualenv
vào cuối quá trình cài đặt! :)
Vì chính sách docker có xu hướng là "một ứng dụng cho mỗi vùng chứa" nên điểm thứ tư có thể không phải là lý do chính đáng. –
cảm ơn @ BenoîtLatinier, chúng tôi có thể nói cùng một điều: Tôi có nghĩa là bởi vì bạn đang chạy ứng dụng bên trong một thùng chứa, đây là cách tốt để cô lập các yêu cầu của nó :) – gru
Bạn không cần phải cài đặt «RUN pip virtualenv' trước đó trong dockerfile, tạo thư mục virtualenv, và sau đó 'pip install' phần còn lại của các gói ở đó, thay vì ở cuối quá trình cài đặt? – Davos
Cách ly xa hơn không bao giờ là xấu, đặc biệt vì nó không gây ra phí. Và tôi tin rằng đó là một thói quen tốt để giữ. –
Tôi phải thêm: virtualenv không phải là máy ảo. Không phải Docker. virtualenv chỉ tạo một bản sao của trình thông dịch python và tạo ra một nơi riêng biệt cho các thư viện, cách ly nơi bạn giữ các phụ thuộc của mình. Hầu như cùng một khái niệm cho Docker, bạn giữ sự phụ thuộc của bạn trong các lớp, và bạn cô lập các phần bộ nhớ, CPU, lưu trữ, mạng và vv cho vùng chứa của bạn, bạn không chạy một hệ điều hành đầy đủ. –
Lý do duy nhất tôi thấy sử dụng virtualenv là nếu bạn xung đột với sự phụ thuộc của hệ thống, ví dụ: một thành phần hệ điều hành đang sử dụng một phiên bản khác của lib python. –