Nói chung một nhà phát triển quan tâm đến việc đáp ứng yêu cầu kinh doanh. Anh ấy / cô ấy có thể có chuyên môn trong một ngăn xếp cụ thể hoặc một khung. Nhưng anh ấy / cô ấy có nên nỗ lực học docker và đó là các phương thức triển khai khác nhau (swarm, kube, mesos, v.v.)?
Đơn giản chỉ cần đặt tại sao một nhà phát triển nên quan tâm đến docker?
PS: Câu hỏi phụ huynh cho bài đăng này là Ý nghĩa của việc giới thiệu docker cho nhóm phát triển
Câu trả lời:
Có lẽ không phải là câu trả lời mà bạn đang tìm kiếm, nhưng dù sao cũng là một câu trả lời :)
Tìm hiểu về docker và các phương thức triển khai của nó thực sự có thể được bao gồm trong các yêu cầu nghiệp vụ bằng cách biến nó thành một phần của môi trường phát triển dự án hoặc nhóm, giống như ngôn ngữ mã, hệ thống kiểm soát phiên bản, trình biên dịch, cơ sở hạ tầng kiểm tra, v.v. nhóm đó hoặc trong dự án đó người ta cần biết và sử dụng tất cả những thứ này, không thể "mang theo của riêng bạn" (trong hầu hết các trường hợp).
Mọi thứ trở nên phức tạp hơn một chút nếu "nhà phát triển" thực sự có nghĩa là phần lớn hoặc thậm chí toàn bộ nhóm phát triển. Đẩy một công cụ trong môi trường phát triển mà không thực sự có bất kỳ nhà phát triển nào hỗ trợ nó sẽ thực sự khó khăn. Dành thời gian để tạo một người hỗ trợ như vậy trước tiên từ lãnh đạo kỹ thuật của đội.
Lưu ý bên lề: có thể không cần thiết cho mỗi và mọi nhà phát triển trong nhóm để trở thành một chuyên gia về docker. Các công thức sử dụng được thiết lập sẵn được gói trong các lệnh đơn giản, sẵn sàng cho phép các nhà phát triển sử dụng các giải pháp dựa trên docker mà không thực sự biết quá nhiều về hoạt động bên trong của họ, điều này có thể được chấp nhận, đặc biệt là trong các nhóm lớn. Giống như có thể đóng góp mã mà không cần biết tất cả các chi tiết về cách sản phẩm cuối cùng được xây dựng.
Tôi sẽ cho bạn quan điểm của tôi. Các nhà phát triển nên quan tâm đến docker vì có những nhà phát triển khác sẵn sàng sử dụng docker và đã xây dựng chuyên môn về nó. Họ sẵn sàng đảm nhận vai trò của một kỹ sư DevOps cùng với việc trở thành một nhà phát triển. Vì vậy, phần Ops của DevOps là những gì họ đang xây dựng chuyên môn.
Ngày nay, bạn sẽ tìm thấy ngày càng nhiều người có thể phát triển, sắp xếp, tự động hóa các bài kiểm tra, tự động hóa công việc và xây dựng các công cụ để giám sát và đưa gói hoàn chỉnh này vào sản xuất một tay. Đây là những kẻ đang đẩy docker và các công cụ khác trong cộng đồng nhà phát triển.
Ngoài ra, làn sóng của thị trường là hướng tới ảo hóa, tự động mở rộng quy mô, tự động hóa, học máy và docker phù hợp với tất cả những điều này. Nó đã trở nên rất bắt buộc để sử dụng docker. Các doanh nghiệp sẵn sàng trả gấp 2 lần cho một anh chàng duy nhất đảm nhận tất cả các trách nhiệm này và khi có nhu cầu cho những người như vậy, nguồn cung cũng sẽ bắt đầu. Đây là từ quan điểm của một nhân viên-sử dụng lao động.
Về mặt kỹ thuật, trong các tổ chức tôi đã làm việc, có các nhóm phát triển và DevOps riêng biệt, mặc dù họ làm việc rất chặt chẽ cho việc giao hàng. Các kỹ sư và nhà phát triển DevOps chia sẻ phần lớn các bộ kỹ năng ở đây và do đó đôi khi có một cuộc đàm phán về nhiệm vụ.
Tối thiểu mà một nhà phát triển có thể làm là chia sẻ các nhị phân của mình, nhưng anh ta cần hiểu rằng các nhị phân sẽ được sử dụng để chạy bên trong một container docker và để anh ta hiểu cách hoạt động của docker. Đối với kubes, swarms, mesos, v.v., nhà phát triển thậm chí không quan tâm đến những gì đang được sử dụng, nhưng những điều cơ bản của docker nên được nhà phát triển hiểu rất rõ và ngay từ đầu nên xây dựng ứng dụng một cách lỏng lẻo để sử dụng lại như dịch vụ vi mô. Nếu ứng dụng được xây dựng từ tư duy đó (đòi hỏi những điều cơ bản về docker), thì các kỹ sư của DevOps có thể đưa nó lên từ đó để tự động chia tỷ lệ, sắp xếp, kiểm tra, triển khai và giám sát.
Ngoài ra, hầu hết thời gian không có một kích thước phù hợp với tất cả các loại. Một nhà phát triển không biết rõ ràng cách xây dựng một ứng dụng thân thiện với docker và một kỹ sư DevOps hoàn toàn không biết các phần bên trong của quá trình xây dựng ứng dụng. Do đó, hầu hết thời gian, các tổ chức thích giao cả hai nhiệm vụ này cho cùng một anh chàng để tăng tốc mọi thứ. Nếu có những thứ riêng biệt, thì cần phải có cơ chế phản hồi liên tục từ nhóm DevOps đến nhóm nhà phát triển để làm cho các ứng dụng trở nên tương lai hơn và docker / cloud / scale sẵn sàng.
Đây không phải là về Docker hoặc bất kỳ công nghệ container hóa nào khác ngoài kia.
Các container như Docker, rkt, v.v. chỉ là cách phân phối ứng dụng của bạn theo cách tương tự như nhị phân tĩnh. Bạn đang xây dựng triển khai của mình rằng nó chứa mọi thứ nó cần bên trong và người dùng cuối không cần gì hơn ngoài thời gian chạy.
Các giải pháp này tương tự như các JAR béo trong Java, trong đó mọi thứ bạn (về lý thuyết) cần chỉ là thời gian chạy (JRE) được cài đặt sẵn và mọi thứ Chỉ hoạt động ™.
Lý do tại sao các nhà phát triển cần phải hiểu (họ không cần học cách vận hành công cụ đó, chỉ tại sao điều này là cần thiết) công cụ điều phối là vì điều này cho phép bạn có một số lợi thế so với triển khai "truyền thống".
EngineYard đã viết bài báo tốt về điều đó. Toàn bộ vấn đề đó là khi máy chủ của bạn chết, sau đó bạn nhún vai và chờ đợi như mới sẽ xuất hiện. Bạn coi chúng như gia súc, bạn có hàng chục, hàng trăm, hàng ngàn con đang chạy và khi một con đi xuống, cả bạn và khách hàng của bạn đều không nên biết điều đó.
Các công cụ phối hợp đạt được điều đó bằng cách theo dõi trạng thái của tất cả các ứng dụng (nhóm / công việc, bất cứ thứ gì) trong cụm và khi thấy một trong các máy chủ ngừng phản hồi (đi xuống) thì nó sẽ tự động di chuyển tất cả các ứng dụng đang chạy trên máy chủ đó sang một nơi khác.
Nhờ điều phối, bạn có thể chạy nhiều ứng dụng trên một máy chủ và người điều phối sẽ theo dõi tài nguyên cho bạn. Nó sẽ sắp xếp lại các ứng dụng khi có yêu cầu.
Nhờ xử lý chuyển đổi dự phòng tự động trong dàn nhạc, bạn có thể chạy các hình ảnh tùy chỉnh của mình trong đám mây. Khi bạn cần cập nhật, bạn chỉ cần xây dựng hình ảnh mới, đặt Cấu hình khởi chạy để sử dụng hình ảnh đó ngay bây giờ và chỉ cần cuộn. Mọi thứ sẽ được xử lý cho bạn:
TL; DR Toàn bộ điểm không phải là về Docker mà là về sự phối hợp. Docker chỉ là một phiên bản mở rộng của JAR tarball / fat cần thiết cho việc phối hợp thích hợp.
Dưới đây là ví dụ một số đối số từ một bài đăng trên blog được xuất bản vào năm 2014 và có tiêu đề hoàn toàn phù hợp với câu trả lời của bạn:
- Linh hoạt hơn nhiều công nghệ mới vào môi trường
- vẫn còn một điểm đau lớn giữa việc cam kết mã được thử nghiệm cuối cùng và sau đó để nó chạy trên các máy chủ sản xuất cuối cùng. Docker đơn giản hóa rất nhiều bước cuối cùng này
- Docker làm cho nó trở nên tầm thường để giữ hệ điều hành cũ, bất kể bạn đang chạy Linux ở vị trí nào
Từ: https://thenewstack.io/why-you-should-care-about-docker/
Nếu bạn đang chạy sản xuất của mình trong bộ chứa docker, điều quan trọng là những bộ chứa đó đang được tạo ra bởi cùng các nhà phát triển đã xây dựng ứng dụng chạy trên chúng. Ai khác là nơi tốt hơn để biết những gì phụ thuộc bên ngoài là cần thiết và như vậy ...?
Ngoài ra, đường ống có thể thất bại ở bất kỳ bước nào trong CD, đặc biệt khi đó là bước xây dựng hình ảnh docker, đôi khi đó là một tệp bị thiếu hoặc một lib cần thiết.
Trong công việc, chúng tôi đã giới thiệu tất cả các nhà phát triển cho docker giải thích cho họ những điều cơ bản để xây dựng dockerfile để phục vụ ứng dụng của họ, chúng tôi cũng làm cho đường ống dễ dàng để người ta chỉ có thể thêm tên và dockerfile và ứng dụng của nó sẽ tự động được xây dựng trên đẩy tiếp theo bất kể công nghệ chạy nó.
Docker quickstart thực sự là một lời giới thiệu tuyệt vời để làm như vậy, sau những gì nhóm devOps hướng dẫn các nhà phát triển trong sự lựa chọn phân phối của họ (rất nhiều người trong số họ không biết những điều như thế alpine).
Công việc của chúng tôi là cung cấp cho họ quyền truy cập dễ dàng vào các công cụ, họ làm phần còn lại để họ có thể khắc phục khi có sự cố. Docker thực sự là một phần của quá trình phát triển và nhóm devOps cung cấp cho họ hình ảnh docker phù hợp với nhu cầu của chúng tôi và đủ dễ dàng để chỉ mất vài phút để tạo một ứng dụng mới và triển khai nó mà không cần hỗ trợ.
Docker nhận được rất nhiều báo chí và blog đề cập đến việc các nhà phát triển quan tâm đến việc sử dụng nó. Đối với một số người, đó là sự thích thú khi chơi với một công nghệ mới hoặc hiểu cách mọi thứ hoạt động. Đối với những người khác, nó là một mong muốn để thêm từ khóa vào sơ yếu lý lịch của họ. Dù bằng cách nào, càng nhiều nhà phát triển biết về cách mọi thứ hoạt động và cách họ được triển khai thì họ sẽ càng ít ngạc nhiên hơn về sau. Từ những gì tôi đã thấy, có một số lượng đáng kể tiền lãi trong việc này vì vậy không khó để khuyến khích nó hơn nữa.
Chà, nếu bạn đã từng sử dụng máy ảo để thử nghiệm, bạn có thể muốn thử sử dụng container và docker thực sự là một công cụ tuyệt vời để thử nghiệm và nó đơn giản hơn nhiều để sử dụng thay vì LXC :)