Việc triển khai thực hành kỹ thuật DevOps trong một tổ chức thường bao gồm ba giai đoạn. Các giai đoạn này tuân theo một tiến trình tự nhiên dẫn đến mô hình hoạt động code-to-deployment hoàn toàn tự động
Một số lượng lớn các công cụ kỹ thuật có thể được sử dụng để tự động hóa môi trường DevOps, đến từ các dự án mã nguồn mở hiện đại. Bạn cần biết về chuỗi công cụ DevOps này nếu bạn được yêu cầu quản lý môi trường DevOps. XebiaLabs là một công ty chuyên về DevOps và liên tục phân phối, và đây là một nguồn tài nguyên tuyệt vời để hiểu các công cụ khác nhau trong quy trình DevOps. Biểu đồ tuần hoàn DevOps của công ty cung cấp một cái nhìn tương tác về các công cụ này, đồng thời cung cấp các liên kết và mô tả về các công cụ và công nghệ mà bạn có thể gặp phải (xem hình 13-20). Bạn có thể truy cập https://xebialabs.com/periodictable-of-devops tools/ để có quyền truy cập và tải xuống bản sao của riêng bạn.
Hình 13-20 Bảng tuần hoàn XebiaLabs của các công cụ DevOps (Source: https://xebialabs.com/periodic-tableof-devops-tools/)
Nếu bạn không quan tâm đến bản chất do-it-yourself(tự làm) của việc kết nối và cấu hình các công cụ mã nguồn mở, tốt hơn hết bạn nên tìm đến nhà cung cấp nền tảng dưới dạng dịch vụ hoặc nhà cung cấp đó sẽ xây dựng DevOps pipeline cho bạn cũng như đưa ra hỗ trợ với bảo trì và nâng cấp. Bất kể nền tảng hoặc công cụ DevOps bạn sử dụng hay bạn tự xây dựng hay mua chúng, có một số sự tương đồng phổ biến với tất cả các DevOps pipeline. Dễ dàng nhất để hiểu hoạt động của một DevOps pipeline đó là xem nó hoạt động. Hình 13-21 là biểu diễn đồ họa về những gì xảy ra ở mỗi bước của DevOps pipeline mẫu.
Hình 13-21 DevOps Pipeline trong hoạt động
Đây là cách pipeline làm việc :
Bước 1. Nhà phát triển lấy code mới nhất từ hệ thống kiểm soát phiên bản Git. Điều này đảm bảo rằng nhà phát triển có những thay đổi gần nhất và không làm việc với phiên bản cũ.
Bước 2. Nhà phát triển tạo ra những thay đổi trong code , thêm các tính năng mới hoặc sửa lỗi. Nhà phát triển cũng viết các test case sẽ được sử dụng để tự động kiểm tra code mới đối với các yêu cầu chức năng của phần mềm. Cuối cùng, nhà phát triển sẽ xử lý các thay đổi trong Git để gửi đi.
Bước 3. Nhà phát triển sử dụng Git để đẩy code và các bài test đến hệ thống kiểm soát phiên bản(ví dụ: GitHub), đồng bộ hóa phiên bản cục bộ với kho chứa code từ xa được lưu trữ trong hệ thống kiểm soát phiên bản.
Bước 4. Máy chủ tích hợp liên tục, chẳng hạn như Jenkins, có thông tin đăng nhập giám sát GitHub để gửi code mới lên. Khi Jenkins nhìn thấy một commit mới, nó có thể kéo phiên bản mới nhất về và bắt đầu quá trình xây dựng tự động bằng cách sử dụng các test case.
Bước 5. Jenkins bắt đầu xây dựng tự động môi trường test cho phần mềm mới. Có thể sử dụng Python scripts, Ansible hoặc các công cụ tự động hóa cơ sở hạ tầng khác để xây dựng môi trường testing gần với sản xuất nhất có thể.
Bước 6. Jenkins thực thi các bài test tự động khác nhau, bao gồm unit test(kiểm thử đơn vị), integration testing(Kiểm thử tích hợp), smoke testing(stress testing) and security testing. Khi tất cả các bài kiểm thử kết thúc, kết quả được gửi lại cho Jenkins để tổng hợp.
Bước 7. Jenkins gửi kết quả kiểm tra cho nhà phát triển để xem xét. Chúng có thể được gửi qua email, nhưng một cách hiện đại hơn để thông báo cho nhà phát triển là thông qua một công cụ cộng tác như Webex Teams. Jenkins có các flug-in cho tất cả các công cụ quản lý nhóm chính và cho phép tích hợp dễ dàng. Nếu quá trình xây dựng không thành công, nhà phát triển có thể sử dụng các liên kết đến thông tin về những gì đã thất bại và tại sao, thay đổi code và khởi động lại quá trình.
Bước 8. Nếu quá trình xây dựng thành công và tất cả các bài kiểm tra đều vượt qua, Jenkins có thể deploy(triển khai) code mới và một artifact repository (chỉ là một cái tên ưa thích cho nơi lưu trữ phần mềm đã hoàn thiện). Phần mềm này không thể được deploy trong sản xuất.
Bước 9. Jenkins thông báo cho cơ sở hạ tầng rằng phiên bản cập nhật của phần mềm đã sẵn sàng. Ví dụ: có thể có một container mới sẵn sàng được deploy vào nền tảng Kubernetes. Container được cập nhật sẽ thay thế các container hiện tại bằng code mới đã được kiểm tra đầy đủ và sẵn sàng hoạt động. Giờ đây, ứng dụng được cập nhật với sự gián đoạn tối thiểu(hoặc không).
Những điểm quan trọng của xây dựng DevOps pipeline là ngoài của phạm vi của kỳ thi 200-901 DevNet Associate DEVASC. Đơn giản là có nhiều công cụ hơn là những hạt cát ở bãi biển, và may mắn là bạn sẽ không phải thử nghiệm tất cả chúng. Đối với các nhà công nghệ, thật thật dễ dàng tập trung vào các công cụ và công nghệ, nhưng thành thật mà nói, đó là phần dễ dàng của DevOps. Thay đổi văn hóa và áp dụng các phương pháp Lean là nơi mà nhiều công ty đã phải vật lộn. Tập trung vào việc hợp lý hóa các quy trình và triển khai các công nghệ giúp đẩy nhanh nỗ lực của bạn.
DOCKER
Một số cải tiến tuyệt vời nhất là đến từ việc sử dụng lại các công nghệ cũ hơn. Đó chính xác là những gì Solomon Hykes và Sebastien Pahl đã làm vào năm 2010 khi họ bắt đầu một nền tảng nhỏ dưới hình thức là một công ty dịch vụ được gọi là (PaaS) được gọi là dotCloud. Họ đang tìm cách giúp tạo ứng dụng dễ dàng hơn và deploy chúng theo cách tự động vào dịch vụ của họ. Họ bắt đầu một dự án nội bộ để khám phá việc sử dụng một số công nghệ UNIX thú vị được phát triển ban đầu vào những năm 1970 để cho phép cô lập quy trình ở cấp độ kernel. Những gì cuối cùng sẽ trở thành Docker bắt đầu như một dự án sử dụng những khả năng này để phát triển kinh doanh PaaS. Vào năm 2013, thế giới đã biết đến Docker, đại diện cho một mô hình mới trong việc triển khai và đóng gói ứng dụng đã thành công theo cấp số nhân. Trong khi dotCloud cuối cùng đã biến mất, Docker đã phát triển thành nền tảng container hàng đầu. May mắn cho chúng ta, nó là mã nguồn mở ngay từ đầu và bản thân container runtime được lưu trữ bởi Cloud Native Computing Foundation. Mặc dù có những container runtime khác, chẳng hạn như Rocket và Linux Containers, không có cái nào trong số chúng phổ biến hoặc được triển khai rộng rãi như Docker.
TÌM HIỂU DOCKER
Docker containers sử dụng hai khả năng trong Linux kernal(nhân Linux): namespaces, cung cấp khả năng cô lập cho các quy trình đang chạy, tiếp theo là cgroups(control groups), giúp quy định giới hạn tài nguyên về những gì một tiến trình có thể được cấp phát. Các tính năng này cho phép bạn chạy một hệ thống Linux trong một hệ thống Linux khác nhưng không cần sử dụng công nghệ ảo hóa để làm cho nó hoạt động. Từ góc nhìn của hệ điều hành máy chủ, bạn chỉ đang chạy một ứng dụng khác, nhưng ứng dụng đó cho rằng nó là ứng dụng duy nhất đang chạy. Thay vì cần ảo hóa phần cứng, bạn chỉ cần chia sẻ kernel(phần lõi), bạn không cần tải toàn bộ hệ điều hành, trình điều khiển(driver) và quy trình quản lý bộ nhớ mỗi khi bạn muốn chạy một ứng dụng.
Namespaces
Namespaces rất cần thiết để cung cấp sự cô lập cho vùng container. Sáu namesapces được sử dụng cho mục đích này:
Hình 13 - 22 cho thấy một máy chủ Linux đang sử dụng namespaces để cô lập ba container khác nhau.
Hình 13-22 Cô lập Namespace Linux cho các Container
Cgroups(Control groups)
Cgroups, hoặc control group, được sử dụng để quản lý mức tiêu thụ tài nguyên của từng quy trình container. Bạn có thể thiết lập bao nhiêu CPU và RAM được phân bổ cũng như I / O mạng và lưu trữ. Mỗi tham số có thể được quản lý để tinh chỉnh những gì container nhìn thấy và sử dụng. Các giới hạn này được thực thi bởi cgroups thông qua Linux scheduler và chức năng gốc để hạn chế tài nguyên phần cứng. Hình 13-23 cho thấy một ví dụ về một cgroup phân bổ tối đa 25% các tài nguyên phần cứng khác nhau của host container.
Hình 13-23 Control Group trong hoạt động
