Docker Compose là chưa đủ

• docker-compose là công cụ để xử lý các container Docker, giúp giải quyết các vấn đề triển khai ứng dụng phức tạp, nhưng không đủ cho nhu cầu tự host đơn giản dành cho thị trường đại chúng
• Cần một mức trừu tượng cao hơn, bao gồm các khái niệm như cơ sở dữ liệu SQL, bộ nhớ đệm cục bộ, lưu trữ bền vững, khám phá dịch vụ và quản lý tài nguyên

Vai trò của Docker

• Docker là công cụ đã phổ biến hóa việc container hóa, có thể ví hệ thống máy chủ như một con tàu.
• Có phần cứng, hệ điều hành và container runtime; các container chạy bên trong runtime và giao tiếp với các dịch vụ khác như cơ sở dữ liệu hoặc máy chủ web.

Vai trò của Docker-compose

• docker-compose là công cụ để chỉ định một nhóm container hoạt động cùng nhau, giúp việc triển khai các ứng dụng tự host trở nên dễ dàng hơn.
• Tuy nhiên, nó phá vỡ giao diện được chuẩn hóa và tái tạo lại những vấn đề mà container vốn được tạo ra để giải quyết.
• Ví dụ: Pihole
  • Pihole là một máy chủ DNS và cần một tệp docker-compose phức tạp.
  • Cần cấu hình tên container, image, cổng, biến môi trường, volume, tính năng bổ sung, chính sách khởi động lại, v.v.
  • Cấu hình phức tạp buộc người dùng phải tự quản lý, đây là nhược điểm của Docker Compose
• Ví dụ: Jitsi Meet
  • Jitsi Meet là phần mềm phức tạp, tạo ra cấu hình docker-compose gồm 4 container, 7 volume, 9 cổng và hơn 200 thiết lập môi trường.
• Ví dụ: các ứng dụng tự host phổ biến khác cũng gặp vấn đề tương tự
  • Có nhiều ứng dụng như Authentik, Nextcloud, Immich, Jellyfin, Paperless NGX, và cấu hình docker-compose của mỗi ứng dụng thay thế từ vài chục đến vài trăm lệnh docker.
  • Mỗi ứng dụng có thể đi kèm cơ sở dữ liệu, bộ nhớ đệm, trình xử lý HTTP riêng, dẫn đến việc sử dụng tài nguyên trùng lặp.

Vấn đề

• docker-compose quá linh hoạt, quá chi tiết và hoạt động ở sai tầng trừu tượng.
• Mỗi ứng dụng đều có quy trình xử lý HTTP, bộ nhớ đệm hoặc cơ sở dữ liệu riêng. Việc sao lưu cơ sở dữ liệu thuộc trách nhiệm của quản trị viên hệ thống.
• Ví dụ: Reverse HTTP proxy
  • Reverse HTTP proxy là chương trình chuyển tiếp các yêu cầu HTTP đi vào sang chương trình khác. Mỗi chương trình phải tự quyết định có bao gồm máy chủ web hay không.
  • Có bao gồm máy chủ web
    • Nếu có máy chủ web, chương trình sẽ hoạt động nhưng chỉ trên một cổng nhất định; khi có nhiều container, phải remap cổng.
  • Không bao gồm máy chủ web
    • Nếu không có máy chủ web thì không lãng phí tài nguyên, nhưng phải cấu hình ứng dụng mà không có giao diện quản trị.
  • DNS
    • Giao diện web cần có địa chỉ, và nếu muốn TLS thì cần có tên. Khi chạy nhiều dịch vụ trên một máy chủ, phải định tuyến yêu cầu bằng tên miền hoặc đường dẫn.
  • Cổng
    • docker-compose cho phép expose và remap cổng, nhưng trên thực tế cần hỗ trợ các thiết lập mạng phức tạp hơn.
• Ví dụ: cơ sở dữ liệu
  • Với cơ sở dữ liệu, khi container bị xóa thì mọi thay đổi đối với tệp cũng bị xóa theo. Container cơ sở dữ liệu phải thêm volume để lưu nội dung dữ liệu.
  • N+1=2 hoặc hơn
    • Để sao lưu cơ sở dữ liệu, cần có bản sao lưu ngoài site. Nếu mỗi dịch vụ đều đi kèm một tiến trình máy chủ cơ sở dữ liệu riêng thì sẽ lãng phí tài nguyên tính toán.

Giải pháp

• Chuyển sang tầng trừu tượng cao hơn và bổ sung ngữ nghĩa để phân biệt các loại container như cơ sở dữ liệu, reverse web proxy, bộ nhớ đệm, tài nguyên web tĩnh, v.v.
• Ví dụ về ngữ nghĩa
  • Giới thiệu một định dạng cấu hình mới để chỉ định tên ứng dụng, build, reverse proxy HTTPS và dịch vụ bộ nhớ đệm.
• Giải pháp #1
  • Mỗi chương trình yêu cầu reverse proxy, tránh trùng lặp và lãng phí. Reverse proxy cung cấp tên DNS và chuyển tiếp mọi đường dẫn đến chương trình.
• Giải pháp #1.5
  • Thêm phần cơ sở dữ liệu để yêu cầu một cơ sở dữ liệu tuân thủ chuẩn SQL, và chương trình kỳ vọng quyền hạn “đầy đủ”.
• Giải pháp cho cổng
  • Mỗi chương trình nhận địa chỉ IPv6 riêng để có thể dùng số cổng chuẩn. Vì bảo mật, dùng tường lửa để chỉ reverse proxy được phép truy cập các cổng.

Tealok - container runtime mới

• Tealok là container runtime mới cung cấp mức trừu tượng cao hơn và giao diện được chuẩn hóa.
  • Tự động xử lý chứng chỉ TLS, cấu hình reverse proxy, bản ghi DNS, quản lý sao lưu, v.v.
  • Tận dụng IPv6 để mỗi container có một địa chỉ IP độc lập và có thể dùng số cổng chuẩn.
  • Nhà phát triển ứng dụng có thể triển khai ứng dụng qua giao diện chuẩn mà không cần cấu hình phức tạp.
• Với người vận hành, nó mang lại các thực tiễn tốt nhất nhất quán, giảm lãng phí tài nguyên và giảm gánh nặng quản trị.
• Với nhà phát triển, nó đơn giản hóa cách triển khai và giảm gánh nặng ra quyết định.
• Người dùng có thể được đảm bảo quyền sở hữu dữ liệu và tính độc lập khỏi điện toán đám mây.

[luminance]

Vào tealok xem thì thấy chưa ở trạng thái có thể trở thành một phương án thay thế.

[savvykang]

Giá mà họ cũng loại bỏ luôn cả runtime thì tốt biết mấy.

[tujuc]

Tôi vẫn nghĩ việc dùng docker-compose để dựng môi trường vận hành và đi vào làm việc vẫn là điều cần thiết, nhưng...

Dựa trên trải nghiệm trong một môi trường đặc thù của riêng mình rồi nói rằng cách đó là sai nên đã tạo ra cái mới... thì thật khó để đồng tình.. hhhhhh

Đây là nội dung rất dễ khiến người ta hiểu nhầm đấy hhhhhh...

Vì chỉ nhìn tiêu đề thôi là tôi đã nghĩ kiểu 'Ơ, đúng là mình rất không thích dùng nó trong môi trường phát triển....' rồi.. hhh

[ilbanin00]

Tôi nghĩ ngay từ đầu, việc cố dùng Docker Compose cho cùng mục đích như trong bài viết đã là một cách tiếp cận sai.

[tujuc]

Tôi phần nào đồng ý với ý kiến đó, nhưng tôi không nghĩ cách tiếp cận là sai.
Trong môi trường mà họ có thể làm được, có lẽ đó là lựa chọn tốt nhất thôi :)

[GN⁺]

Ý kiến trên Hacker News

• Có những cách giải quyết đơn giản cho vấn đề ánh xạ cổng và sao lưu volume dữ liệu

  • Có thể dùng một tệp docker-compose riêng cho môi trường phát triển để định nghĩa cấu hình khác nhau theo từng môi trường
  • Có thể viết một script Bash đơn giản để sao lưu và tải lên S3

• Với tư cách là người tự host trên máy chủ cá nhân bằng Docker, họ đánh giá cao sự linh hoạt trong cấu hình Docker

  • Thiết lập ban đầu có mất thời gian, nhưng sau đó việc quản lý trở nên dễ dàng
  • Việc thêm dịch vụ mới gần như không tốn thời gian, và để bảo mật họ tạo người dùng không phải root cho từng dịch vụ
  • Dùng mạng macvlan để gán cho mỗi container một địa chỉ IP và MAC riêng
  • Dùng Nginx Proxy Manager để quản lý reverse proxy, và ngay cả khi chạy nhiều instance với cơ sở dữ liệu cũng không gặp vấn đề gì

• docker-compose chủ yếu được dùng cho mục đích phát triển hoặc cá nhân, và V2 là plugin đã được tích hợp vào Docker, khác với V1

• Trong môi trường production, nên dùng Kubernetes, còn docker-compose phù hợp cho phát triển cục bộ

• docker-compose là một sản phẩm dành cho self-hosting quy mô nhỏ, nhắm đến những người không có nền tảng kỹ thuật

  • Họ hoài nghi rằng việc chuyển sang TOML sẽ khiến self-hosting trở nên dễ dàng hơn

• Viết một chương trình để điều khiển Docker đơn giản hơn tưởng tượng, và có thể dùng script Python để giải quyết vấn đề

• Họ đang phát triển để canine.sh giúp việc sử dụng cụm Kubernetes trở nên dễ như Heroku

  • Đang dùng nó cho dự án cá nhân và có thể host nhiều ứng dụng với chi phí thấp

• Việc Tealok đang phát triển một lựa chọn thay thế cho docker-compose là điều đáng chú ý

• Họ cho rằng docker-compose, Kubernetes và Helm là các tầng trừu tượng hóa sai

  • Có rất nhiều nỗ lực nhằm phát triển các cách khác nhau để chạy và giao tiếp giữa các container

• Họ cảm thấy bối rối trước nhận định rằng docker-compose là một tầng trừu tượng hóa sai

  • Có vẻ như người đó đang kỳ vọng một giao diện cấp cao để giải quyết một vấn đề cụ thể
  • Vấn đề tạo các instance trùng lặp không phải là chuyện lớn với hầu hết ứng dụng
  • Việc ép ứng dụng phải được thiết kế theo một cách nhất định sẽ chỉ hoạt động tốt trong một số tình huống nhất định