Có lợi ích gì khi chạy môi trường phát triển của tôi trong bộ chứa Docker không?

Tôi phát triển chủ yếu bằng Visual Studio trên Windows. Vấn đề là sau một thời gian Windows bị sa lầy và tôi phải đối mặt với việc cần phải cài đặt lại Windows. Tương tự chuyển sang máy mới là một vấn đề.

Cài đặt lại Windows rất khó khăn vì môi trường phát triển của tôi có rất nhiều phụ thuộc (chẳng hạn như các tệp cấu hình MSBuild bổ sung, các phần mở rộng VS, npm, Java, v.v.). Tôi không tưởng tượng rằng tôi đơn độc khi có một hệ thống phức tạp và việc thiết lập lại nó có thể sẽ mất tối thiểu một ngày.

Tôi chưa thực sự sử dụng Docker, nhưng theo lý thuyết thì có vẻ như tôi có thể thiết lập môi trường dev của mình trong Windows Container và sau đó gửi nó đi (ví dụ: sao chép vào máy tính xách tay của tôi, cài đặt Windows mới) và nó không gây đau đớn .

Là những gì tôi đang mô tả có thể? Có bất kỳ nhược điểm, chẳng hạn như hiệu suất, độ tin cậy? Gotchas khác?

Đây không phải là một vấn đề hiếm gặp, nhưng Docker không thực sự là công cụ phù hợp để giải quyết nó. Các bộ chứa nói chung (bao gồm Docker) nhằm cung cấp thời gian chạy ứng dụng cho một quy trình , chẳng hạn như máy chủ web, không dành cho kịch bản nhiều quy trình như môi trường dev. Trong có thể được thực hiện, nhưng không phải là một giải pháp rất thanh lịch.

Cách tiếp cận tốt hơn (và phổ biến hơn) là tạo VM thông qua một trình ảo hóa truyền thống như VirtualBox hoặc Hyper-V (vì bạn đang ở trên Windows). Một quy trình công việc điển hình là:

• Tìm hoặc tạo một hình ảnh VM cơ sở dựa trên hương vị hệ điều hành ưa thích của bạn. Điều này có thể được thực hiện trực tiếp với trình cài đặt ISO hoặc ai đó ở nơi làm việc của bạn có thể đã có.
• Khi hình ảnh cơ sở được xây dựng, hãy thêm vào tất cả các công cụ và cài đặt dev mà bạn cần. Ảnh chụp hoặc lưu ảnh này dưới dạng hình ảnh riêng biệt.
• Bây giờ bạn có thể chạy hình ảnh này, RDP hoặc điều khiển từ xa vào nó và hoạt động cho đến khi bạn đến một điểm mà bạn "bị sa lầy", và sau đó chỉ cần lưu các tệp bạn cần (cam kết kiểm soát nguồn, v.v.), sau đó thổi loại bỏ hình ảnh và bắt đầu lại từ một trong hai ảnh chụp / hình ảnh bạn đã tạo. Điều này có thể được thực hiện trong vài giây, so với một ngày theo cách lỗi thời.
• Tại bất kỳ điểm nào dọc theo đường, tạo các ảnh chụp nhanh bổ sung khi bạn gặp phải tình huống mà bạn có thể muốn quay lại để tái tạo vấn đề, v.v.

Vagrant cũng là một công cụ tuyệt vời để thực hiện nhiều điều trên theo cách có cấu trúc hơn.

Một lợi ích phụ của tất cả những điều này là giờ đây bạn có các môi trường được tiêu chuẩn hóa có thể được chia sẻ với cả nhóm của bạn, giúp mọi người tiết kiệm công sức. Điều này đặc biệt tuyệt vời cho những người mới lên máy bay nhanh chóng.

Quay lại câu hỏi ban đầu của bạn, Docker không thực sự có ý định này, nhưng nếu bạn có một môi trường phát triển đủ nhỏ (nói PHP trên Linux), bạn có thể thực hiện nó trong một thùng chứa và lợi ích sẽ là một hình ảnh nhỏ hơn nhiều (có khả năng dưới 100 MB so với nhiều GB đối với máy ảo Windows có đĩa ảo).

không phải trong một container docker nhưng có trong n container docker.

Mặc dù về mặt lý thuyết, bạn có thể lắp ráp toàn bộ môi trường dev của mình trong một container, docker không có nghĩa là làm điều này.

Thay vào đó, bạn nên triển khai từng dịch vụ vào các thùng chứa riêng biệt, sử dụng soạn thảo docker , quản lý toàn bộ cơ sở hạ tầng của bạn trong một tệp duy nhất, trong đó mỗi dịch vụ sẽ có logfile, không gian người dùng, mạng, v.v.

Hãy để tôi cho bạn một ví dụ, đây là bản nháp của tôi docker-compose.yml

version: '2'
services:

  myproxy:
    build: myproxy
    container_name: ppproxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/tmp/docker.sock:ro
    networks:
      default:
        aliases:
          - www.domain1.it
          - www.domain2.it
          - www.domain4.it

  mydb1:
    build: mydb
    environment:
      DB_USER: sdffdssdf
      DB_PASSWORD:  fdsfsdsdf
      DB_NAME: dbanme1
      DB_ENCODING: UTF-8    
      VIRTUAL_HOST: myhost1.net.lan
      VIRTUAL_PORT: 5432

  mydb2:
    build: mydb
    environment:
      DB_USER: ssdfsdfs
      DB_PASSWORD:  sffdssd
      DB_NAME: dbanme2
      DB_ENCODING: UTF-8    
      VIRTUAL_HOST: myhost2.net.lan
      VIRTUAL_PORT: 5432

  www:
    image: myimages/oldservice:v1.1
    container_name: www
    command: /bin/bash /root/launch
    environment:
        VIRTUAL_HOST: www.domain1.it
        VIRTUAL_PORT: 80
    ports:
      - 80
    depends_on:
      - mydb1
      - mydb1
      - myws

  myws:
    build: myjettycontainer
    environment:
        HTTPS_METHOD: noredirect
        VIRTUAL_HOST: www.domain2.it
        VIRTUAL_PORT: 8080
    ports:
      - 8080
    depends_on:
      - mydb1
      - mydb2
      - myproxy
      - mypostfix

  mypostfix:
    image: catatnight/postfix
    container_name: mailer
    environment:
      maildomain: domain1.it
      smtp_user: mymail:sfsfdfds
    ports:
      - 25

Có một nginx proxy (myproxy), hai cơ sở dữ liệu postgres tương tự (mydb1 và 2), một máy chủ ứng dụng web java cũ (www), một bộ chứa jetty java cung cấp một dịch vụ web còn lại và cuối cùng là một thùng chứa hậu tố SMTP rất đơn giản.

Mọi thứ bắt đầu - thường là :) - với docker-compose up, trên máy dev của tôi hoặc trong sản xuất; các tệp nhật ký được tổng hợp thành một tệp dễ đọc và có thể sao chép cục bộ gần như mọi chức năng với đảm bảo rằng, nếu nó hoạt động trên máy tính xách tay của tôi thì nó sẽ hoạt động.

Tôi sử dụng máy ảo VirtualBox cho loại điều này.

Tính di động của việc có môi trường dev của bạn trong một thùng chứa là tiện dụng, nhưng điều thực sự tuyệt vời là tôi có thể chụp nhanh thứ đó trước bất kỳ nỗ lực nâng cấp nào, và nếu tôi làm hỏng nó, sẽ không có vấn đề gì để quay lại và bắt đầu lại.

Tôi cũng thấy hữu ích khi làm điều này vì tôi thường xuyên làm việc với nhiều phiên bản của Qt và tôi không cảm thấy muốn tìm ra cách để hai phiên bản cùng tồn tại - thay vào đó, tôi chỉ đưa chúng vào các máy ảo khác nhau và Tôi không phải lo lắng về các tương tác vì tôi đã cài đặt một cái gì đó không chính xác.