Triển khai ứng dụng theo mô hìnhmicroservice

BỘ GIÁO DỤC VÀ ĐÀO TẠO   TRƯỜNG ĐẠI HỌC MỎ - ĐỊA CHẤT  BÁO CÁO SEMINAR TÊN ĐỀ TÀI: TRIỂN KHAI ỨNG DỤNG THEO MƠ HÌNH MICROSERVICE  Người thực hiện: TS Nguyễn Thế Lộc (Mã cán bộ: 0801-02) Đơn vị:  Bộ môn Công nghệ phần mềm  Khoa Công nghệ Thông tin  Hà Nội - 2022 MỤC LỤC  DANH MỤC HÌNH VẼ ii MỞ  ĐẦU CHƯƠNG TỔ NG QUAN VỀ CÔNG NGHỆ TRIỂN KHAI 1.1 Ubuntu 1.2 Docker 1.3 Microservice 1.4 Traefik 13 1.5 Đăng nhậ p lần - Single sign-on (SSO) 14 CHƯƠNG CÁC BƯỚ C TÍCH HỢ P VÀ TRIỂN KHAI 16 2.1 Chuẩn bị 16 2.2 Các bước cài đặ t 18 2.3 Các bướ c cấu hình 19 2.4 K ết 20 KẾT LUẬN 21 TÀI LIỆU THAM KHẢO 22 i DANH MỤC HÌNH VẼ  Hình 1.1 Giao diện hình Ubuntu Desktop Hình 1.2 Minh h ọa Docker Image Hình 1.3 Kiến trúc Docker Hypervisors Hình 1.4 Mơ hình ki ến trúc Microservice Hình 1.5 Mơ hình hoạt động Traefik 14 Hình 1.6 Mơ hình hoạt động SSO 14 ii MỞ  ĐẦU Tích hợ   p h ệ th ống ho ạt động giữ vai trị quan tr ọng quy trình  phát triển phần mềm m ột hoạt động cuối không thể thiếu d ự án sản xuất gia cơng phần mềm Chính thế mà tích hợ   p hệ thống tr ở thành công đoạn định sự thành công d ự án Chất lượ ng hệ thống hỗ tr ợ ra định đánh giá qua mộ t mơ hình chất lượ ng c ụ th ể H ệ h ỗ tr ợ  định đượ c phân tách theo cấ p b ậc vào  phần mềm vớ i tiêu chí nh ững tiêu chí con, cho có th ể sử d ụng chúng danh sách để ki ểm tra v ấn đề phát sinh liên quan đến chất lượ ng Trong nội dung này, nhóm nghiên cứu sẽ tậ p trung trình bày về vấn đề tích hợ   p triển khai hệ thống Đồng thời cần phải kiểm tra toàn bộ hệ thống, vớ i bộ d ữ liệu khác để  đánh giá cách tổng thể từ đó có cậ p nhật, chỉnh sửa bổ sung phù hợ   p giúp cho h ệ thống v ận hành cách t ối ưu, đáp ứng đượ c yêu cầu ngườ i dùng CHƯƠNG TỔNG QUAN VỀ CÔNG NGHỆ TRIỂN KHAI Khi xây d ựng hệ thống yêu cầu cần phải có hiệu cao, tốc độ  nhanh quan tr ọng ổn định, hoạt động liên tục sẽ cần cơng nghệ phù hợ   p (về tài nguyên, hạ tầng, nhân sự) Những công nghệ đượ c đề xuất sử d ụng Docker, Traefik đượ c triển khai theo mơ hình Microservice h ệ  điều hành Ubuntu Những công nghệ này đượ c k ết h ợ   p vớ i sẽ t ạo h ệ th ống có khả năng chịu tải tốt nhằm phục vụ đượ c số lượng ngườ i dùng lớn thông qua chế cân tải (Load Balancing) d ễ dàng mở  r ộng 1.1 Ubuntu Ubuntu (phát âm IPA uːˈbuːntuː) mộ t hệ  điều hành máy tính d ựa Debian GNU/Linux, phân phối Linux thơng d ụng Tên bắt nguồn từ “ubuntu” tiếng Zulu, có nghĩa “tình người”, mơ tả triết lý ubuntu: “Tơi đượ c nh ờ  có người xung quanh,” khía cạnh tích cực cộng đồng  Hình 1.1 Giao diện hình Ubuntu Desktop Ubuntu đượ c tài tr ợ bở i công ty Canonical Ltd (ch ủ sở  hữu ngườ i Nam Phi Mark Shuttleworth) Thay bán Ubuntu, Canonical tạo doanh thu cách bán hỗ tr ợ kĩ thuật Canonical phát triển Ubuntu thành dịng sản phẩm chính: Ubuntu Desktop: cài đặt cho máy tính cá nhân ph ục v ụ những ngườ i dùng thông thườ ng Ubuntu Server: cài đặt cho máy ch ủ để phục vụ các d ịch vụ trên internet mạng doanh nghiệ p 1.2 Docker Docker open platform cung c ấp cho ngườ i sử d ụng công cụ và service để ngườ i sử d ụng có thể đóng gói chạy chương trình môi trườ ng khác cách nhanh Docker m ột phương thức để  đóng gói sắ p xế p phần mềm giúp nhà phát triển phần mềm tự  động triển khai ứng d ụng Linux Windows vào container ảo hóa Docker khiến cho việc d ựng chạy kiến trúc vi d ịch vụ đượ c phân phối, triển khai mã c bạn vớ i quy trình tích hợ   p phân phối liên tục đượ c tiêu chuẩn hóa, xây d ựng hệ thống xử lý d ữ liệu có quy mô c ực k ỳ linh hoạt tạo n ền tảng đượ c quản lý đầy đủ d ễ dàng cho nhà phát triể n Container thuật ngữ  để  chỉ  Process đượ c quản lý bở i Container Enginer (Ngồi Docker Engine cịn số  công cụ  khác Solaris Zones, LXC, etc) V ớ i Docker Engine (Hay g ọi tắt Docker), có thể  tạo th ực thi Container Lợ i ích việc “Container hố” (Containerized) Process s ẽ giúp qu ản lý sử d ụng nguồn tài nguyên máy tách biệt (isolating) môi trườ ng Process Một khái niệm khác Docker: Image  –   Những mẫu (template) chứa dòng quy định Container chạy lên thế nào Nếu hiểu theo lậ p trình hướng đối tượ ng ta có th ể xem Image Class Containers đượ c tạo từ Image Object Instance c Class    Hình 1.2 Minh họa Docker Image Ở mơ hình trên, ta có th ể thấy container đượ c khở i tạo từ Image có tên Python Một Docker Image thường đượ c build từ một Base Image khác (Thườ ng sẽ bắt nguồn từ các phân nhánh Linux Ubuntu, Alpine, Slim, etc) Nhữ ng Base Image có Base Image cho gố c cuối Scratch Image  Ngoài Docker Container Docker Image, cần biết thêm về:   Dockerfile: Là tậ p tin chứa mô tả để build Docker Image •   Docker Registry: Là m ột kho chứa Docker Image, v ề  • sẽ có sẵn Docker Registry s ẵn sàng để sử d ụng:   Local Registry: Những Image đượ c kéo về máy chủ hay đượ c build máy • chủ s ẽ n ằm t ại Cũng giống source code bạ n clone về máy từ  GitHub   • Docker Hub: Đây Public Registry Registry mặc đị nh c Docker Đa số các Image s ẽ đuộc pull (kéo về) từ đây.    Volume / Binding Volume: Khi Container đượ c khở i tạo, sẽ có • Volume (Ổ chứa d ữ liệu) tách biệt để chứa t ậ p tin hệ thống hay source code, Container ngừng chạy, s ẽ  khơng cịn access đượ c tậ p tin Do đó, việc binding Docker Volume m ột ổ  chứa c máy chủ (Host machine) cần thiết n ếu mu ốn lưu giữ  tậ p tin sinh từ Container (ví d ụ  log files, configuration files, etc)   Container Port / Binding Ports: Tương tự  Volume, Container có • riêng Network ports, để access Port từ máy ch ủ, phải bind port máy ch ủ vớ i Containers   Docker Client: cơng cụ chính để chúng ta giao tiế p vớ i Docker Engine •   Docker Daemon: đóng vai trị Listener để   thực thi lệnh quản lý • Docker build Image, run Container, get Image list get Container list, etc Sự  khác biệt giữ a Docker Hypervisors: Hypervisor ảo hỏa nằm ở   tầng Hardware (phần cứng), tức mô  phần cứng chạy OS phần cứng (Các công cụ  Hypervisor Virtual Box, VMware ) Virtual Machine (Hypervisors): C ần thêm Guest OS sẽ tốn tài nguyên làm chậ m máy thật sử d ụng Thờ i gian khở i động trung bình 20s có thể lên đến hàng phút, thay đổi phụ thuộc vào tốc độ của ổ đĩa.  Docker: Dùng chung kernel, ch ạy độc lậ p Host Operating System có thể chạy hệ điều hành cloud Khởi động làm cho ứng d ụng sẵn sàng chạy 500ms, mang lại tính khả thi cao cho nh ững d ự án cần sự mở  r ộng nhanh  Hình 1.3 Kiế n trúc Docker Hypervisors 1.3 Microservice Trong tiếng anh, micro có nghĩa nhỏ, vi mơ Vậy Microservice, tên nó, chia khối phần mềm thành service nh ỏ  hơn, có thể  triển khai server khác M ỗi service sẽ xử lý t ừng phần công việc đượ c k ết nối vớ i thông qua các giao th ức khác nhau, http, SOA, socket, Message queue (Active MQ, Kafka) để  truyền tải d ữ liệu Trướ c Microservices xu ất hiện, ứng d ụng thườ ng phát triển theo mơ hình Monolithic architecture (Kiến trúc kh ối) Có nghĩa tất c ả các module (view, business, database) đượ c gộ p project, ứng d ụng đượ c  phát triển theo mơ hình kiến trúc khối thường đượ c phân chia làm nhiều module Nhưng đóng gói cài đặ t sẽ thành khối (monolithic) Lợ i ích mơ hình ki ến trúc khối dễ dàng phát tri ển triển khai Nhưng  bên cạnh có nhiề u hạn chế ví d ụ như khó khăn việc bảo trì, tính linh hoạt khả năng mở  r ộng kém, đặc biệt vớ i ứng d ụng doanh nghiệ p có quy mơ lớn Đó lí đờ i kiến trúc Microservices  Hình 1.4 Mơ hình kiế n trúc Microservice Microservice cho phép vi ệc phát triển ứng d ụng lớ n qua nhiều giai đoạn nhiều nhóm có thể làm việc độc lậ p vớ i về ngơn ngữ, nguờ i, tiêu chuẩn k ết nối Điều c ần thiết vớ i việc thị trường thay đổi ngày cách nhanh chóng sản phẩm phải liên tục đượ c sửa đổi nâng cấp để  đáp ứng Trong kiến trúc nguyên khối qua m ột thờ i gian cậ p nhật sửa đổi bắt đầu để  lộ ra nh ững khó khăn về th ờ i gian, nguời, … việc nâng cấp địi hỏi ngườ i  phát triển phải hiểu tồn bộ hệ thống tại, kiến trúc microser vices đượ c đời để giải khó khăn Vớ i microservices việc nâng cấ p phát triển thêm tính cho sản phẩm sử d ụng chỉ cần phát triển modun mớ i cho tính cần cậ p nhật giao tiế p vớ i ứng d ụng lõi khác có thơng qua cá c interface đượ c thiết k ế bở i d ịch vụ đã tồn trước Cách nhữ ng d ịch vụ nhỏ  k ết nối với sau:  ❖  Cơ chế k ết nối: o  Xử lý đồng bộ (Synchronous): Gửi yêu cầu chờ  đợ i tr ả lờ i r ồi mớ i tiế p tục xử lý o  Bất đồng bộ (Asynchronous): Gửi yêu cầu tiế p tục xử lý ngay, có câu tr ả lờ i sẽ được thơng báo để xử lý k ết ❖  Về chuẩn giao tiế p: o  HTTP (RESTFUL API, SOAP) o  RPC (remote procedure call -l ệnh gọi từ xa) o  MQ (message queue) Những đặc điểm microservice:   Decoupling - Các service hệ thống phần lớn • đượ c tách r ời  Vì vậy, tồn bộ ứng d ụng có thể d ễ dàng đượ c xây d ựng, thay đổi thu nhỏ   Componentization - • Microservices đượ c coi thành phần độc lậ p có thể d ễ dàng thay thế và nâng c ấ p   Business Capabilities - thành phần kiến trúc microservice r ất • đơn giản tậ p trung vào nhiệm vụ duy   Autonomy - l ậ p trình viên hay nhóm có thể làm việc • độc lậ p vớ i trình phát triển   Continous Delivery - Cho phép phát hành phần mềm • thườ ng xuyên, liên tục   Responsibility •   Decentralized Governance - khơng có m ẫu chuẩn hóa bất k ỳ mẫu cơng • nghệ nào Đượ c tự do l ựa ch ọn cơng c ụ h ữu ích tốt để có thể giải vấn đề   Agility - microservice hỗ tr ợ phát triển theo mơ hình Agile • Ưu điểm: Kiến trúc Microservices sinh để kh ắc ph ục h ạn ch ế của kiến trúc khối:   Independent Development - Tất cả các service có th ể  đượ c phát triển d ễ  • dàng d ựa chức cá nhân củ a service Có th ể chia nhỏ để phát triển độc lậ p   Independent Deployment - Có thể đượ c triển khai riêng lẻ trong bất k ỳ ứng • d ụng   Fault Isolation - service ứng d ụng khơng hoạt • động, hệ th ống tiế p tục hoạt động   Mixed Technology Stack - Các ngơn ngữ và cơng nghệ khác có thể  • đượ c sử d ụng để xây d ựng service khác c ứng d ụng   Granular Scaling • Kiến trúc Microservices giúp đơn giả n hóa hệ thống, chia nhỏ hệ th ống làm nhiều service nhỏ lẽ d ể dàng quản lý triển khai phần so v ớ i kiến trúc nguyên khối Phân tách rõ ràng gi ữa service nh ỏ Cho phép việc m ỗi service 10 đượ c phát triển độc l ập Cũng cho phép lậ p trình viên có thể t ự do chọn l ựa technology stack cho service phát tri ển service có th ể  đượ c triển khai cách độc lậ p (VD: Mỗi service có th ể  đượ c đóng gói vào docker container độc lậ p, giúp giảm tối đa thời gian deploy) Nó cho phép mỗ i service có thể đượ c scale m ột cách độc lậ p vớ i Việc scale có th ể đượ c thực d ễ dàng cách tăng số instance cho service r ồi phân t ải load  balancer Nhược điểm: Kiến trúc Microservices xu hướng, có nhượ c điểm Microservice khuy ến khích làm nhỏ gọn service, chia nhỏ sẽ d ẫn đến thứ vụn vặt, khó kiểm sốt Hơn từ đặc tính phân tán khiến cho lậ p trình viên phải lựa chọn cách thức giao tiế p phù h ợ   p x ử  lí request service Một nhược điểm lớ n khác microservices s ự phức tạ p phát sinh từ thực tế là ứng d ụng microservices hệ thống phân tán Các developer c ần phải lựa ch ọn thực hi ện chế giao tiế p process d ựa messaging RPC Hơn nữ a, họ cũng phải viết mã để xử lý việc thất bại chừng (partial failure) điểm đến request có thể chậm khơng khả d ụng Rõ ràng  phức t ạp nhiều so vớ i ứng d ụng nguyên khối nơi mô-đun gọi thông qua cu ộc gọi phương thức / thủ tục mức ngôn ngữ Một thách thức khác vớ i microservices ki ến trúc sở  d ữ liệu phân vùng (partitioned database architecture) Các business transactions c ậ p nhật nhiều  business entities điều phổ biến Các lo ại transaction thường đượ c thực d ễ dàng ứng d ụng nguyên khối chỉ có sở  d ữ liệu Tuy nhiên, m ột ứng d ụng d ựa microservices, b ạn cần cậ p nhật nhiều sở   d ữ  liệu thuộc sở   hữu d ịch vụ  khác S ử  d ụng distributed transactions thườ ng lựa chọn, khơng ch ỉ vì định lý CAP Đơn giản sự tồn vẹn về cơ sở  d ữ liệu không đượ c hỗ tr ợ bở i d ạng sở  d ữ li ệu NoSQL (có khả  mở  r ộng cao) messaging brokers 11 Chúng ta cuối phải sử d ụng phương pháp tiế p cận d ựa sự nhất quán cuối (eventual consistency), điều gây khơng tí khó khăn cho developer Test ứng d ụng microservices phức t ạp nhiều Ví d ụ, v ớ i m ột framework đại Spring Boot, đơn giản để  viết lớ   p thử nghiệm khở i động m ột ứng d ụng web nguyên khối kiểm tra API REST c Ngượ c l ại, lớ   p thử nghiệm tương tự cho d ịch vụ sẽ cần phải khở i chạy d ịch vụ đó  bất k ỳ d ịch vụ nào mà ph ụ thuộc (hoặc nh ất cấu hình stubs cho d ịch vụ đó) Một lần không đánh giá thấ p sự phức tạ p việc Một thách thức lớ n khác vớ i mô hình Microservices th ực thay đổi tr ải r ộng nhiều d ịch vụ Ví d ụ, tưởng tượ ng r ằng bạn thực câu chuyện yêu cầu thay đổi đối v ớ i d ịch v ụ  A, B C, A phụ  thu ộc vào B B phụ thuộc vào C Trong ứng d ụng nguyên khối, bạn có thể thay đổi mơ-đun tương ứng, tích hợp thay đổi, triển khai chúng lần Ngượ c lại, Microservices, bạn cần phải lậ p k ế hoạch điều phối cẩn thận việc triển khai thay đổi cho d ịch vụ Ví d ụ, bạn sẽ cần cậ p nhật d ịch vụ C, tiế p theo d ịch vụ B, cu ối d ịch vụ A May thay, h ầu hết thay đổi thườ ng chỉ  tác động đến m ột d ịch v ụ  thay đổi d ịch v ụ  đa yêu cầu ph ối h ợp tương đối Triển khai ứng d ụng d ựa microservices phứ c tạp nhiều Một ứng d ụng nguyên khối đượ c triển khai đơn giản tậ p hợ   p máy chủ  giống hệt phía sau b ộ cân tải truyền thống Mỗi cá thể ứng d ụng đượ c cấu hình vớ i vị trí (host and ports) d ịch vụ cơ sở  hạ tầng sở  d ữ  liệu message broker Ngượ c l ại, m ột ứng d ụng microservice thườ ng bao gồm số lượ ng lớ n d ịch vụ Ví d ụ, Hailo có 160 d ịch vụ khác Netflix có 600 dịch v ụ M ỗi d ịch v ụ s ẽ có nhiều phiên running Có nhiều b ộ ph ận cần đượ c cấu hình, triển khai, thu nhỏ và giám sát Ngoài ra, b ạn sẽ cần triển khai chế khám phá d ịch v ụ  (service discovery) (đượ c th ảo lu ận sau) cho phép d ịch vụ khám phá vị trí (host and ports) c bất k ỳ d ịch vụ  khác mà c ần giao tiế p Các cách ti ế p cận th ủ công truyền thống d ựa 12 ticket-based thủ công không thể mở  r ộng đến mức độ phức tạp Do đó, việ c triển khai thành công ứng d ụng microservices yêu c ầu developer ki ểm soát  phương thức triển khai mức độ tự động hóa cao hơn.  1.4 Traefik Traefik Reverse- proxy đờ i m ớ i, load balancer để  làm cho việc deploy hệ thống microservice đượ c tr ở  lên d ễ  dàng Tích hợ   p r ất nhiều thành phần infrastructure Docker, Swarm mode, Kubernetes, Marathon, Consul, Etcd, Rancher, Amazon ECS Và tính t ự  động điểm quan tr ọng config vớ i traefik Triển khai mô hình Microservice k ết h ợ   p v ớ i Docker đem lại nhiều l ợ i ích Để  ngườ i dùng truy cậ p vào hệ th ống microservice ta c ần m ột reverse proxy Và reverse proxy m ột số các v ấn đề mà g ặ p phải kiến trúc Traefik sinh để  giải việc đó.  13  Hình 1.5 Mơ hình hoạt động Traefik 1.5 Đăng nhập lần - Single sign-on (SSO) Đăng nhậ p lần (SSO) d ịch vụ xác thực phiên ngườ i dùng cho phép ngườ i dùng cuối nh ậ p m ột b ộ  thơng tin đăng nhậ p (có thể g ồm tên m ật kh ẩu) để có quyền truy cậ p vào nhiều ứng d ụng  Hình 1.6 Mơ hình hoạt động SSO OAuth, đượ c phát âm "oh-auth", tảng framework cho phép d ịch vụ bên thứ ba sử d ụng thông tin tài khoản ngườ i dùng cuối, chẳng hạn 14 Facebook, mà không để l ộ m ật kh ẩu c ngườ i dùng OAuth hoạt động trung gian đại diện cho ngườ i dùng cuối thông qua mã token truy cậ p, mã sẽ cho phép thông tin tài khoản cụ thể đượ c chia sẻ Khi ngườ i dùng cố gắng truy cậ p m ột ứng d ụng t ừ nhà cung cấ p d ịch v ụ, nhà cung cấ p d ịch v ụ s ẽ g ửi yêu cầu đến bên nhận d ạng thứ  để  xác thực Nhà cung c ấ p d ịch v ụ  sau sẽ xác minh xác thực cho phép người dùng đăng nhậ p 15 CHƯƠNG CÁC BƯỚ C TÍCH HỢ P VÀ TRIỂN KHAI Chương sẽ  trình bày bướ c tích hợ  p triển khai h ệ thống h ọc tậ p tr ực tuyến d ựa mã ngu ồn mở  Moodle theo mơ hình microservice 2.1 Chuẩn bị  - Máy chủ cấu hình cao, dung lượ ng lớ n (CPU cores, RAM GB, HDD 300 GB); - Hệ  điều hành Ubuntu server phiên cài đặ t sẵn bở i quản tr ị  hệ  thống; - File k ịch docker-compose.yml (để tự  động cài d ịch vụ) đượ c tạo sẵn bở i nhóm nghiên cứu; - File cấu hình traefik.yml (để  cấu hình reverse proxy), dynamic_conf.yml (để cấu hình cân tải –  load balancing) đượ c tạo sẵn bở i nhóm nghiên cứu  N ội dung file docker-compose.yml: version: '2' services: mariadb: image: 'mariadb:10' container_name: db environment: MYSQL_RANDOM_ROOT_PASSWORD: MYSQL_DATABASE: moodle MYSQL_USER: moodle MYSQL_PASSWORD: moodlePassword volumes: - $HOME/volumes/mysql:/var/lib/mysql moodle: image: 'bitnami/moodle:3' container_name: moodle environment: MOODLE_USERNAME: programster MOODLE_PASSWORD: thisIsMyMoodleLoginPassword MOODLE_EMAIL: admin@programster.org MARIADB_HOST: db MARIADB_PORT_NUMBER: 3306 MOODLE_DATABASE_USER: moodle MOODLE_DATABASE_NAME: moodle MOODLE_DATABASE_PASSWORD: moodlePassword ALLOW_EMPTY_PASSWORD: "no" 16 ports: - '80:80' - '443:443' volumes: - $HOME/volumes/moodle:/bitnami' depends_on: - mariadb traefik: image: traefik:v2.0 restart: always volumes: - "./traefik.yml:/etc/traefik/traefik.yml" - "./conf:/conf" - "./secure-config:/secure-config" ports: - "80:80" - "443:443" - "8888:8888" volumes: mariadb_data: driver: local moodle_data: driver: local  N ội dung file traefik.yml: api: insecure: false dashboard: true debug: true log: level: DEBUG #INFO format: json entryPoints: web: address: ":80" web-secure: address: ":443" api: address: ":8888" providers: file: directory: "/conf" filename: "dynamic_conf.yml" watch: true  N ội dung file dynamic_conf.yml: http: routers: api: entryPoints: 17 - "api" rule: PathPrefix(`/`) service: api@internal moodle-secure: entryPoints: - "web-secure" rule: "Host(`elearning.humg.edu.vn`)" service: moodle-secure tls: {} moodle: entryPoints: - "web" rule: "Host(`elearning.humg.edu.vn`)" service: moodle middlewares: moodle-stripprefix: stripPrefix: prefixes: - "/moodle" forceSlash: false services: moodle-secure: loadBalancer: servers: - url: http://moodle:8080 passHostHeader: true sticky: cookie: {} moodle: loadBalancer: servers: - url: http://moodle:8080 passHostHeader: true sticky: cookie: {} 2.2 Các bướ c cài đặt Mở   terminal Ubuntu ch ạy l ệnh sau để  thực việc cài đặ t Docker, Docker compose th ực thi file script docker-compose.yml.  - Cài đặt Docker:   Cậ p nhật kho phần mềm Unix: sudo apt-get update •   Gỡ   bỏ  phiên Docker (nếu có): sudo apt-get remove • docker docker-engine docker.io   Cài phiên Docker mớ i nhất: sudo apt install docker.io •   Thiết lậ p chế  độ  chạy tự  động cho Docker: sudo systemctl start • docker & sudo systemctl enable docker 18   Kiểm tra lại việc cài đặt (xem phiên Docker): docker version • - Cài đặt Docker compose:   Tải phiên m ớ i nh ất hi ện t ại c Docker compose: sudo curl -L • "https://github.com/docker/compose/releases/download/1.27.4/doc ker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/dockercompose   Gán quyền thực thi cho t ệ p tin vừa tải xuống: sudo chmod +x • /usr/local/bin/docker-compose   Kiểm tra lại việc cài đặ t (xem phiên bản): docker-compose version • - Chạy file k ịch docker-compose.yml:   Di chuyển đến thư mụ c chứa file k ịch docker-compose.yml •   Chạy lệnh: docker-compose up -d (có thể scale để tăng hiệu năng)  • K ết quả cài đặt máy ch ủ: 2.3 Các bướ c cấu hình Để hệ thống có thể hoạt động đượ c hạ tầng quan vớ i tên miền elearning.humg.edu.vn, cần phải thực bướ c cấu hình sau: -  Tạo ghi A record vớ i tên subdomain elearning hệ  thống quản lý tên mi ền (domain) humg.edu.vn c Trường Đại học Mỏ - Địa chất trì cơng ty PA Vietnam địa chỉ: https://access.pavietnam.vn 19 -  Cấu hình Sophos firewall c Nhà trường để ánh xạ tên miền đến địa chỉ IP port c d ịch vụ đã đượ c nhóm nghiên cứu cài đặt ở  trên 2.4 Kết quả  Hệ thống sau đượ c triển khai máy ch ủ sẽ hoạt động địa chỉ đượ c nêu ở  trong file cấu hình phía 20 KẾT LUẬN Kiến trúc microservice khơng nh ỏ như cái tên c Mà m ột kiến trúc dành cho ứng d ụng lớ n Nếu ứng d ụng bạn chưa đủ lớn khơng có ý định mở  r ộng tươ ng lai hướ ng phát triển theo kiến trúc nguyên khối lựa chọn hợ   p lý Kiến trúc microservice gi ải đượ c r ất nhiều vấn đề của kiến trúc nguyên khối, tỏ ra vượ t tr ội ki ến trúc nguyên khối ở  nhi ều khía cạnh Tuy nhiên kiến trúc có khơng hạn chế 21 TÀI LIỆU THAM KHẢO [1] https://smartbear.com/learn/api-design/what-are-microservices/ [2] https://www.edureka.co/blog/what-is-microservices/ [3] https://searchmicroservices.techtarget.com/definition/businesscapability [4] https://smartbear.com/learn/api-design/what-are-microservices/ [5] The What, Why, and How of a Microservices Architecture [6] https://blog.newrelic.com/technology/microservices-what-they-arewhy-to-use-them/ [7] https://whatis.techtarget.com/definition/business-logic [8] https://www.quora.com/Should-each-microservice-have-its-owndatabase [9] http://blog.christianposta.com/microservices/the-hardest-part-aboutmicroservices-data/ [10] Best Practices for Building a Microservice Architecture [11] https://blog.runscope.com/posts/5-reasons-not-to-use-microservices 22