Trong bài chia sẻ về kiến trúc Microservices cho các bạn sinh viên tuần trước, mình có nói rằng ở công ty công nghệ thông thường thì có thể có hàng chục developer, nhưng chỉ có 1 hoặc 2 system designer (Nhà thiết kế hệ thống) và tất nhiên vị trí này nhìn chung sẽ được săn đón và bổng lộc cao hơn developer.
“Từ một developer trở thành một system designer mất bao lâu?” là câu hỏi mà một bạn sinh viên đã đặt ra cho Tuấn trong buổi chia sẻ này và thiết nghĩ đây là một câu hỏi hay và câu trả lời của mình sẽ giúp các bạn định hướng được chặn đường phát triển của một developer trong tương lai.
Một developer có thể có nhiều con đường phát triển sự nghiệp, trở thành một system designer là một lựa chọn không tệ. Hiện nay, bạn có thể khá dễ dàng để tuyển một developer, nhưng tuyển những vị trí system designer rất là khó, và thông thường ở những vị trí như CTO (giống Tứng) mới có skill này (flex tí ^^!).
Kiến thức của một system designer sẽ rất là dàn trải và đòi hỏi nghiên cứu, thử nghiệm không ngừng nghỉ vì số lượng những công nghệ mới sinh ra liên tục, phải phân tích, đánh giá, so sánh các công nghệ và tìm ra những công nghệ phù hợp với lộ trình phát triển của công ty và tốt nhất là đi lên từ một developer.
Cho nên để từ một developer trở thành một system designer thì cần khoảng 5 năm theo đuổi lĩnh vực này, am hiểu về cách hệ thống vận hành và các thành phần trong một hệ thống liên kết với nhau thế nào, cũng như điểm mạnh, điểm yếu của các thành phần trong tổng thể hệ thống.
Do đó, nếu muốn xây dựng một đội ngũ công nghệ, trước tiên bạn phải tìm system designer, đừng tìm developer nếu không muốn nhiều vấn đề nhức đầu về sau.
Liệu mở một lớp dạy về System Design dành cho developer thì có ai học không ta ?!!!
Sau 2 tuần mò mẫm trong Google Cloud, PHP, Apache, Go, Angular … để hỗ trợ một ông bạn kiểm soát lại toàn bộ hệ thống cũ do team dev quăng bom để lại, thì thấy nếu sản phẩm tech hay đội code trong nhà của mấy sếp mà có một trong bảy triệu chứng dưới đây thì nên bắt đầu lo sợ là vừa, vì có thể một ngày nào đó lại inbox Tứng và hỏi thuốc giải.
Các ý tưởng này chỉ là góc nhìn cá nhân dựa trên đống shit mà Tứng ngụp lặn bữa giờ, mong ace đừng ném đá và kì thị:
🚩 – Không có CI/CD, code được pull trực tiếp trên production server thông qua Git và chỉnh sửa trực tiếp bằng tay (rồi không biết có bị quên push ngược lên repo hay không) 🚩 – Không có tài liệu cài đặt hệ thống 🚩 – Cấu hình như URL, Key, IP… được set cứng trong source code (Ví dụ các so sánh if … else, switch…case…) hoặc nằm rải rác ở rất nhiều file khác nhau 🚩 – Không có Load Balancer routing vào các server bên trong (Ví dụ Haproxy, Traefik, Cloud Load Balancer..) 🚩 – Không sử dụng Docker (hay công nghệ tương tự) hoặc thực hiện `docker build…` tại máy của cha nội dev hoặc trên server rồi push trực tiếp lên Registry 🚩 – Source code được đóng gói và publish công khai trên Docker Hub. 🚩 – Web server (Apache, Nginx..) tự handle các xử lý liên quan SSL Certificate
Hy vọng sau status này thì team DevOps của mấy sếp có một vài ngày làm việc bận rộn hoặc…bỏ của chạy lấy người.
Nhớ cách đây 6 năm, #CropCom bắt đầu dấn thân vào con đường DevOps bán chuyên với Monolithic, SVN, Jenkins…cho đến 4 năm trước với sự trưởng thành hơn về stack DevOps với kiến trúc Microservices, Git, Gitlab CI… cho thấy sự thay đổi công nghệ liên tục cũng như giá trị mà nó mang lại.
Mở đầu tháng 2 cũng như mở màn chuỗi ngày “bị” nghỉ Tết với một cuốn sách khá hay về DevOps là Accelerate. Đây là một cuốn sách nói về lợi ích của phương pháp xây dựng quy trình phần mềm tinh gọn và Devops, dựa trên một nghiên cứu hàng năm trong hơn 4 năm của nhóm tác giả, với gần 30.000 người làm DevOps tham gia khảo sát.
Nếu để ý thì một trong những tác giá là Gene Kim, tác giả của 2 cuốn tiểu thuyết hư cấu nổi tiếng bàn về áp dụng DevOps là The Phoenix Project (Dự án Phượng Hoàng).
Ở phần đầu, sách đi sâu vào việc tìm hiểu mối tương quan giữa việc áp dụng quy trình xây dựng phần mềm theo phương pháp Lean, Devops và giá trị cho doanh nghiệp, tổ chức như cải thiện hiệu quả công việc, văn hóa công ty và chuyển đổi số. Trình bày chi tiết 24 khía cạnh DevOps thuộc 5 nhóm lớn bao gồm: Continuous delivery, Architecture, Product and process, Lean management and monitoring, Culture.
Ngoài ra, ở phần 2 (là phần mình thích nhất trong sách) các tác giả đưa ra những phương pháp, lý do dẫn đến việc thiết kế bảng khảo sát (survey) của mình để đảm bảo khách quan nhất có thể như các tip lựa chọn phương pháp lấy dữ liệu, phương pháp thống kê, cách sử dụng từ ngữ, đặt câu hỏi sao cho tránh các thiên kiến (bias) hoặc đóng khung (framing) và hiểu lầm.
Nếu bạn là một nhà quản lý công nghệ của công ty hay tổ chức (Vd: CTO, CIO..) thì không thể bỏ qua cuốn sách này nếu muốn tìm hiểu sâu hơn các phương pháp đánh giá, xây dựng quy trình tinh gọn cho các đội phát triển phần mềm. Đặc biệt là những ai chỉ nghe nói đến DevOps nhưng chưa thật rõ công dụng và hiệu quả của nó lên giá trị của doanh nghiệp. Khuyến đọc.
—
“Nearly every company relies on software, delivery performance is critical to any organization doing business today. And software delivery performance is affected by many factors, including leadership, tools, automation, and a culture of continuous learning and improvement.”
“You can’t buy or copy high performance. You will need to develop your own capabilities as you pursue a path that fits your particular context and goals. This will take sustained effort, investment, focus, and time.”
– trích Accelerate (Nicole Forsgren, Jez Humble & Gene Kim)
Chào mọi người, nếu như các bạn cũng biết thì dự án Teamcrop của mình xây dựng và chạy hoàn toàn trên kiến trúc Microservices và sau hơn 2 năm triển khai thì có một số vấn đề liên quan đến kiến trúc này, thiết nghĩ cần chia sẻ thêm với mọi người để mọi người thấy được rằng Microservices không phải là chìa khóa vạn năng như vẫn hay nghe quảng cáo, dụ dỗ. Mọi kiến trúc đều có đánh đổi và Microservices cũng vậy.
Sau mấy tuần vật lộn với công việc sau Tết thì cũng có thời gian viết lách. Đây là bài viết về kỹ thuật đầu tiên của năm và là bài đầu tiên trong loạt bài chia sẻ về các chiến thuật scaling hệ thống web có tên là “Web scalability 101 (vỡ lòng)”.
Nếu quan tâm đến scale hệ thống, bạn có thể google những từ khóa liên quan đến scale, ngôn ngữ, công nghệ mà hệ thống bạn đang sử dụng, và phần lớn là các bài viết chỉ về các cài đặt, cấu hình cụ thể của một công nghệ nào đó như tùy chỉnh PHP thế nào, tùy chỉnh nginx, tùy chỉnh mysql ra sao…và có thể bạn sẽ lạc trong một mớ hỗn độn các kiến thức cấu hình này.
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.
