Số là hôm nay vừa chuyển 2 repo framework và restful sdk của Teamcrop từ composer về submodule nên chia sẻ nhanh 1 số bước để sử dụng submodule cho repo của bạn. Một phần để lưu lại sau này dùng vì kiến thức rồi sẽ ra đi, chỉ có blog là ở lại và cũng chia sẻ cho bạn nào chưa biết.
Nói một cách ngắn gọn thì submodule giúp bạn mang 1 repo khác bỏ vào repo đang làm việc, giúp việc tái sử dụng code hiệu quả hơn. Ví dụ như đối với dự án Teamcrop là muốn nhúng core framework và restful sdk dùng cho tất cả microservices. Còn vì sao mình dùng submodule mà không dùng composer hoặc các hình thức khác thì mình thấy submodule khá phù hợp với mô hình private repository.
Lựa chọn IaaS nào luôn là trăn trở của công ty cung cấp dịch vụ cloud-based (SaaS) như mình vì vấn đề cân đối giữa giá và performance hệ thống, người dùng luôn được cân nhắc. Vừa chuyển về cloud của Việt Nam (VCCloud, không có quảng cáo, cái nào tốt thì xài) thấy giá không như xưa, có thể nói là ngang ngửa giá với cloud thuộc dạng rẻ nhất của nước ngoài (Linode, mình sử dụng Linode vì chính sách giá cũng như support khá tốt, và có data center ở Singapore), nếu biết tweak có thể có một số cấu hình rẻ hơn nước ngoài về memory. Được cái cloud ở VN thì performance là tốt nhất so với nước ngoài vì độ trễ thấp hơn nhiều (trừ những lúc mấy ông nội VN cấu hình sao đó mà truy cập site ở VN mà chậm hơn ở Sing ^^!). Sau khi đo đạc, nghiên cứu thì sau 10 ngày, tức là hôm nay thì data center của Teamcrop đã về với đất mẹ.
Nội dung bài viết chia sẻ một số cách tiếp cận của mình khi phân tích performance và quyết định dời nhà hệ thống về Việt Nam.
Về giá cả
Trước đây, khi quyết định chuẩn bị một hệ thống scale thì đã quyết định không sử dụng bare metal server mà xem xét nâng cấp lên cloud server để scale cho dễ. Thời điểm cách đây nửa năm các dịch vụ cloud ở Việt Nam còn khá mơ hồ về chất lượng và giá cả, còn về mảng dịch vụ VPS hoặc Dedicated server thì chi phí khá cao.
Mình đã quyết định chuyển toàn bộ hệ thống sang Singapore và sử dụng dịch vụ server của Linode. Linode là một trong những nhà cung cấp có tiếng trên thế giới về hạ tầng Cloud server và giá thì rất cạnh tranh so với Amazon Web Service (AWS), vì dùng AWS tính toàn giá trên trời và giá của Linode cũng rẻ gần như bằng 1 nửa so với các server cùng cấu hình ở VN.
Về performance
Khi chuyển Data center ra ngoài Việt Nam thì một trong những vấn đề performance lớn nhất là tốc độ kết nối, kéo theo khá nhiều thứ bị chậm lại theo. Do hệ thống sử dụng HTTPS và đặc thù của HTTPS là cần 3 RTT (round-trip time) nên nếu 1 RTT chậm thì sẽ kéo theo https sẽ rất chậm. Còn về performance của server thì hầu như không có sự khác biệt về CPU, Memory, HDD.
Mình có cung cấp 1 số thông tin mình test và quyết định chuyển hệ thống về Việt Nam bên dưới.
Về kiến trúc ứng dụng
Do đặc thù định hướng xây dựng theo kiến trúc Microservices và Single Page App (SPA) nên một trang trong tương lai sẽ gọi khá nhiều web service và đồng thời mở ra các web service cho 3rd-party khiến cho việc di chuyển về VN sẽ có nhiều lợi thế về tốc độ hơn, kẻo đã chậm lại càng thêm chậm khi chuyển sang kiến trúc mới.
Khảo sát & so sánh
Một số kết quả khảo sát của mình thực hiện trước khi ra quyết định chuyển về dùng Cloud ở Việt Nam. Thời điểm khảo sát là ngày 29/9/2015 và thực hiện tại TPHCM. Mình có benchmark kết nối với Redis server vì hệ thống mình dùng chủ yếu là Redis cho layer cache.
1. VCCloud – SAS – 1CPU, 2G RAM
– iperf3 giữa 2 server là ~380Mbits/sec. Metric này khá quan trọng nếu bạn xây dựng microservice vì tốc độ giữa 2 server nội mạng là cực kỳ quan trọng vì các server sẽ request lẫn nhau khá nhiều. Do data center trong nước chưa đầu tư các đường truyền hoành tráng nên có vẻ metric này khá thấp so với data center của quốc tế.
– PING RTT giữa 2 server là: 0.578ms
– PING RTT từ Client Viettel đến server: 50.913
– PING RTT từ Client FPT đến server: 26.558ms
– PING RTT từ Client VNPT đến server: 31.834ms
– PING RTT từ Client 3G Mobifone đến server: 105ms
– Redis benchmark
Without pipeline:
./redis-benchmark -h redis.server.lan.ip -n 100000 -t get,set -q
SET: ~ 44K requests per second
GET: ~ 48K requests per second
With pipeline -P 1000
./redis-benchmark -h redis.server.lan.ip -n 100000 -t get,set -q -P 1000
SET: ~ 550K – 610k requests per second
GET: ~ 560K – 610k requests per second
2. Linode – SSD – 2CPU, 2G Ram
– iperf giữa 2 server là 5.78Gbits/sec
– PING RTT giữa 2 server là: 0.508ms
– PING RTT từ Client Viettel đến server: 49.015
– PING RTT từ Client FPT đến server: 160.753ms
– PING RTT từ Client VNPT đến server: 306.097 ms
– PING RTT từ Client 3G Mobifone đến server: 311ms
– Redis benchmark
Without pipeline:
./redis-benchmark -h redis.server.lan.ip -n 100000 -t get,set -q
SET: ~ 33K requests per second
GET: ~ 32K requests per second
With pipeline -P 1000
./redis-benchmark -h redis.server.lan.ip -n 100000 -t get,set -q -P 1000
SET: ~ 790k – 950K requests per second
GET: ~ 1100K requests per second
—
Một số lưu ý là Cloud server ở Việt Nam nếu bạn dùng nhiều ổ cứng, SSD thì giá sẽ khá cao nên cần tối ưu giữa sử dụng nhiều ở cứng hay không vì mình không dùng nhiều ổ cứng mà dùng nhiều memory, nên một số server cache memory thì cứ để memory mong muốn, hdd và cpu ở mức chạy được là sẽ tiết kiệm hơn khá nhiều so với cloud ở quốc tế.
Hy vọng một số chia sẻ ở đây sẽ giúp các bạn có một số góc nhìn về hệ thống cũng như hạ tầng cloud và ra quyết định sao cho có lợi cho sản phẩm của mình trong quá trình triển khai và scale phục vụ nhiều người dùng.
Docker registry là nơi chứa các image trong quá trình khởi động các container. Hầu hết mọi người đang sử dụng các image có sẵn và nếu chưa biết thì nó được host tại Docker hub chính thức. Tuy nhiên, có một số hạn chế khi sử dụng docker hub như sau:
– Server đặt ở nước ngoài (khác VN)
– Tính phí cho các private image. Bạn không thể nào public các image nội bộ nên bạn chỉ có lựa chọn private image. Nếu bạn có một vài project thì chi phí không cao. Nhưng nếu bạn phát triển theo hướng microservice như mình thì sẽ có vài chục đến vài trăm private image, nếu thuê theo gói thì hoàn toàn không kinh tế lắm.
Với 2 hạn chế trên thì hầu hết các công ty tự triển khai các registry cho riêng mình vì registry cũng là open source. Bạn thuê / mua một con server, vps và start cái image registry 2.0 là xong, và có rất nhiều hướng dẫn trên mạng chỉ bạn cách dựng một private registry như vậy. Tuy nhiên, registry bạn dựng lên hầu như không thực tế và chỉ để test mà thôi.
Nội dung bài viết này mình hướng đến một cài đặt registry production tức là chạy thực sự chứ không phải để test đòi hỏi một số yêu cầu như tên miền riêng, ngắn, hỗ trợ https, có backup và có hỗ trợ ACL (Access Control List).
1. Tên miền và SSL Certificate
Tên miền
Bạn cần chọn một tên miền cho registry của mình. Lời khuyên của mình là chọn một tên miền khác với tên miền đang dùng và dự kiến là sẽ không public tên miền này ở port 80, 443, có nghĩa là không dùng tên miền này để chạy web server. Ví dụ mình chọn tên miền docker2.com là registry của mình.
Bạn có thể mua tên miền và tạo A record trở đến IP của VPS/Server của bạn.
SSL Certificate
Vì private registry mặc định hỗ trợ https nên bạn cần phải có SSL Certificate cho domain của mình. Cách đăng ký mua SSL Certificate thì có rất nhiều bài hướng dẫn, chịu khó google là ra. Ở đây mình ví dụ là mua ở sslcertificate.com.
Quy trình tiếp theo của mua SSL Certificate là kích hoạt và nhập CSR của bạn. CSR (Certificate Signing Request) là một chuỗi có được trong quá trình tạo ra private key. Nó chứa các thông tin cần thiết trong quá trình tạo ra SSL Certificate của bạn. Bạn phải cung cấp CSR thì mới có được SSL Certificate.
Có thể dễ dạng tạo ra cặp CSR và private key thông qua openssl, ví dụ trong hình là mình tạo csr và private key.
Lưu ý là “common name” thường là domain hoặc subdomain dùng để đăng ký SSL Certificate. Vì loại SSL Certificate rẻ nhất chỉ áp dụng cho 1 domain hoặc subdomain. Còn loại Wildcard SSL Certificate thì áp dụng cho toàn bộ subdomain của 1 domain nên giá của wildcard khá chát.
Bạn copy nội dung của file CSR bỏ vào phần thông tin yêu cầu CSR của nhà cung cấp.
Màn hình confirm các thông tin CSR và thông tin sẽ submit để lấy SSL Certificate
Sau đó, bạn làm theo chỉ dẫn của nhà cung cấp để có các file cần thiết của Certificate. Bạn sẽ nhận được 1 file Certificate hoặc nội dung email chứa certificate của bạn. Thường thì với certificate này là có thể cấu hình ssl được. Tuy nhiên, hầu hết các nhà cung cấp SSL đều có một (một số) key gọi là intermediate certificate (cũng là file crt). Khi tạo file crt cuối cùng thường nối thêm các file intermediate certificate này nữa. Có thể nối thông qua câu lệnh CAT.
Ví dụ trong trường hợp mua SSL của COMODO, ngoài file CRT của domain, họ còn cung cấp 1 số intermediate crt, có thể gom các crt và tạo ra bundle các certificate bằng câu lệnh sau:
Bạn sẽ dùng file crt bundle này và file .key (generate ở bước tạo csr) là có thể cấu hình được https.
Để thuận tiện cho các bước chạy các container, đổi tên file bundle crt thành file “domain.crt” và file .key thành “domain.key”. Tiến hành đến bước khởi tạo private registry.
Trong thư mục này thì 2 file “domain.crt” và “domain.key” là 2 file đã được đề cập ở phần 1.
Nội dung file “docker-compose.yml” sẽ là chỉ dẫn để khởi tạo 2 container từ 2 image có sẵn “registry” để tạo container chạy registry 2.0 và image “cesanta/docker_auth” để sử dụng cơ chế token authentication. Trong file docker-composer.yml cũng tạo các volume mount đến các thư mục cần sử dụng như là “certs”, “data”, “log”…Lưu ý là thư mục “certs” sẽ được mount thành thư mục gốc “/certs” trong các container, điều này giải thích vì sao các đường dẫn của certificate bạn thấy là “/certs/domain.crt” và “/certs/domain.key” thay vì sử dụng đường dẫn khác.
Nội dung file “auth_config.yml” chính là config cho hệ thống phân quyền và config trỏ đến đường dẫn của 2 file certificate sau khi mount tại “/certs”. Bạn có thể tham khảo thêm chi tiết về image này tại project https://github.com/cesanta/docker_auth. Dưới đây là ví dụ file cấu hình của mình.
Lưu ý là phần password được tạo bên ngoài và copy vào file config. Password được tạo bằng “htpasswd -n -B yourusername” thì sẽ hiển thị password cho bạn. Ví dụ:
Thư mục “log” dùng để lưu lại các log trong quá trình chứng thực private registry. Thư mục “data” là thư mục quan trọng, chứa toàn bộ dữ liệu của registry. Bạn có thể stop và remove container và khi start lại có thể mount lại volume trên thư mục “data” là có thể sử dụng được dữ liệu của registry. Bạn có thể backup thư mục “data” này để backup cho toàn bộ registry.
Sau khi các file và thư mục đã chuẩn bị sẵn sàng, bạn có thể sử dụng docker composer để nhanh chóng khởi động private registry của mình thông qua câu lệnh:
docker-composer up -d
Bạn có thể verify bằng cách thực hiện docker login, ví dụ: “docker login yourdomain:5000” và nhập “username” và “password” như đã cài đặt trong file “auth_config.yml”.
Cấu hình port 443 (HTTPS)
Trong một số trường hợp, mình muốn chạy domain của registry không cần port 5000, vậy thì mình phải config để có thể forward từ port 443 sang port 5000.
Hầu hết các request của mình đều thông qua Haproxy nên mình có thể điều hướng trong haproxy. Khi có request https đến từ port 443 thì forward sang port 5000 đang chạy registry service.
Bởi vì bản thân registry service đang chạy port 5000 hỗ trợ SSL nên mình cấu hình haproxy sẽ đơn giản hơn, bởi vì mình không terminate SSL tại haproxy mà service registry đang chạy trên port 5000 đã terminate SSL rồi. Do đó, cấu hình SSL ở Haproxy chỉ đơn giản là pass-through sang service đang chạy port 5000.
Ví dụ của file /etc/haproxy/haproxy.cfg:
Sau khi chỉnh sửa file config thì tiến hành reload haproxy để apply. Như vậy bạn có thể sử dụng yourdomain.com thay vì yourdomain.com:5000 như thông thường.
Lưu ý là làm cách này thì bạn không thể cung cấp được website bình thường (https) vì registry đã sử dụng port này rồi, nên domain để chạy registry thường không được sử dụng để truy cập trực tiếp nếu bạn muốn dùng https trên domain.
—
Hy vọng bài viết này sẽ giúp các bạn triển khai được một private registry ngon lành cho công ty của mình.
