Elixir/Erlang Ứng dụng với Docker trong sản xuất?

Question

Tôi muốn biết những lý do mạnh mẽ để đi hoặc không đi với Docker với Elixir/Erlang ứng dụng trong sản xuất.Đây là lần đầu tiên tôi được yêu cầu bắt đầu với Docker trong production.I làm việc trên sản xuất Tôi là một nhà phát triển Erlang/Elixir. Tôi đã làm việc trên các máy chủ sản xuất lưu lượng truy cập cao với hàng triệu giao dịch mỗi giây đang chạy mà không có Docker. Tôi đã dành một ngày để tạo và chạy một hình ảnh Ứng dụng Elixir với nhiều vấn đề với mạng Tôi đã phải làm rất nhiều cấu hình để thiết lập DNS, vv Sau đó tôi bắt đầu suy nghĩ những lý do mạnh mẽ để tiến xa hơn. Có bất kỳ lý do mạnh mẽ để đi hoặc không đi với Docker với Elixir/Erlang ứng dụng trong sản xuất.

Tôi đã đi qua một số lý do trong diễn đàn nhưng vẫn không thuyết phục.Tất cả những lợi thế mà docker đang cung cấp đã có trong máy ảo Erlang. Có thể bất kỳ chuyên gia Erlang trong mẫu xin vui lòng giúp tôi.

Answer 1

Có thể nó phụ thuộc vào máy chủ bạn muốn sử dụng. Từ những gì tôi biết, ví dụ, Docker tạo điều kiện cho việc triển khai một ứng dụng Phoenix trên AWS Elastic Beanstalk rất nhiều, nhưng tôi không đủ thẩm quyền để cung cấp cho bạn những lý do rất cụ thể vào lúc này.

Có thể ai đó có thể xây dựng thêm.

Answer 2

Docker chủ yếu là công cụ triển khai và phân phối. Từ tài liệu Docker:

Docker sắp xếp vòng đời phát triển bằng cách cho phép nhà phát triển làm việc trong môi trường chuẩn hóa sử dụng các ứng dụng và dịch vụ của bạn. Các thùng chứa rất tốt cho việc tích hợp liên tục và các quy trình phát triển liên tục (CI/CD).

Nếu ứng dụng của bạn có phụ thuộc bên ngoài (ví dụ, thư viện crypto), tương tác với một ứng dụng viết bằng ngôn ngữ khác (ví dụ, một cơ sở dữ liệu chạy như một quá trình riêng biệt), hoặc nếu nó dựa trên hệ điều hành nhất định/cấu hình môi trường (bạn đã đề cập bạn phải làm một số cấu hình DNS), sau đó đóng gói ứng dụng của bạn trong một docker container giúp bạn tránh làm việc trùng lặp cài đặt phụ thuộc và cấu hình môi trường. Nó giúp bạn tránh việc làm thêm trong việc đồng bộ hóa môi trường thử nghiệm và sản xuất của bạn về mặt phụ thuộc hoặc điều tra lý do tại sao một ứng dụng hoạt động trên một máy trong một môi trường, nhưng không phải là một môi trường khác.

Ở trên không dành riêng cho ứng dụng Erlang, mặc dù tôi có thể đồng ý rằng Erlang giúp loại bỏ một số vấn đề là nền tảng và trừu tượng đi một số phụ thuộc và xử lý phát hành OTP giúp bạn đóng gói ứng dụng của mình.

Vì bạn đã đề cập bạn là nhà phát triển, điều đáng nói đến là Docker cung cấp nhiều lợi thế hơn cho quản trị viên hoặc nhóm chạy cơ sở hạ tầng thay vì cho nhà phát triển.

Answer 3

Tôi triển khai Elixir được đóng gói trong Docker trên AWS trong sản xuất. Điều này từng là cách ưa thích của tôi khi làm việc nhưng bây giờ tôi có khuynh hướng tạo AMI của riêng mình bằng cách sử dụng Packer với mọi thứ được cài đặt sẵn.

Trung tâm quan trọng trong triển khai là kiểm soát, mà ở một mức độ nhất định mà tôi cảm thấy bị từ bỏ khi tận dụng Docker.

Những bất lợi chính của Docker là nó giới hạn khả năng của Erlang/Elixir, chẳng hạn như kết nối internode qua epmd. Điều này cũng có nghĩa là remsh thực tế nằm ngoài câu hỏi và số :observer.start là không có.Nếu bạn cần phải tương tác với một nút sản xuất vì bất kỳ lý do gì, có thêm một rào cản nhập cảnh ssh-ing đầu tiên vào máy chủ, đi vào bên trong Docker vv .. Tốt khi nó chỉ là kiểm tra thứ gì đó, bực bội khi sản xuất đang cháy xuống trong đau đớn. Việc khởi chạy nhiều thùng chứa trong một Nút là vô ích khi BEAM sử dụng hiệu quả tất cả các lõi của bạn. Nâng cấp nóng là thực tế trong số các câu hỏi, nhưng đó không phải là thực sự là một tính năng chúng tôi cá nhân có một nhu cầu kinh doanh nội tại cho.

nỗ lực đã được thực hiện để có epmd làm việc trong thiết lập container, chẳng hạn như: https://github.com/Random-Liu/Erlang-In-Docker nhưng điều đó sẽ yêu cầu bạn phải xây dựng lại Erlang cho tùy chỉnh net_kernel sửa đổi.

Amazon gần đây đã phát hành một tính năng mới cho AWS ECS, AWS VPC Networking Chế độ, có lẽ có thể tạo điều kiện giao tiếp giữa các container epmd và do đó kết nối trực tiếp với nút của bạn. Tôi chưa xác nhận điều đó.

Bên cạnh vấn đề liên lạc epmd là vấn đề thời gian triển khai. Tạo hình ảnh của bạn với Docker, mặc dù bạn có hình ảnh chỉ khoe khoang 5MB, nhanh chóng sẽ kết thúc với 300MB, với 200 MB chỉ dành cho tất cả các phụ thuộc khác nhau để bản phát hành của bạn được tạo. Có thể có những cách để giảm bớt điều đó, nhưng điều đó đòi hỏi kiến ​​thức chuyên môn và nỗ lực tận tuỵ. Tôi sẽ phân loại thêm không gian này như là một sự phiền toái như trái ngược với một máy cắt giao dịch, nhưng hãy tin tôi nếu bạn phải chờ 25 phút để triển khai bất biến của bạn để hoàn thành, bất kỳ phút nào bạn có thể cạo râu sẽ là đáng giá.

Hiệu suất khôn ngoan, tôi đã không nhận thấy sự khác biệt đáng kể giữa triển khai kim loại trần và triển khai docker. AWS EB Docker mở rộng độc đáo các tài nguyên vùng chứa tới phiên bản EC2.

Ưu điểm của khóa học là tính di động. Nếu bạn có một kỹ sư giao diện người dùng cần nhấn API JSON thì về mặt phát triển địa phương, đó là một chiến thắng lớn với một số thiết lập cẩn thận, họ có thể sinh ra api mới nhất chạy trên địa phương mà không cần phải biết về Erlang/Elixir/Rserve/Postgres.

Ngoài ra, người bán hàng lock-in sẽ giảm đáng kể, đặc biệt là kể từ khi AWS đưa ra sự ủng hộ của họ cho Kubernetes

Đây là một vấn đề cân bằng, nếu bạn là một nhà phát triển có nhu cầu để có được sản xuất và có Devops rất ít kiến thức, sau đó có lẽ một triển khai Docker có thể được bảo hành. Nếu bạn quen thuộc hơn với cơ sở hạ tầng, triển khai, vv, thì với tư cách là nhà phát triển, tôi tin rằng việc tạo AMI của riêng bạn sẽ mang lại cho bạn nhiều quyền kiểm soát hơn đối với môi trường của mình. Tất cả, tôi sẽ khuyến khích ít nhất là chơi xung quanh với Docker và thử nghiệm với nó, nó có thể mở ra một lĩnh vực mới của khả năng.