Giới thiệu:
Bài viết trước chúng ta đã tìm hiểu chi tiết về Tự động hóa quản lý cấu hình (Configuration management). Và hôm nay là ngày thứ 10, chúng ta sẽ tìm hiểu Tổng quan về CI/CD pipelines
Bức tranh toàn cảnh: CI/CD Pipelines
Triển khai CI/CD Pipeline (Tích hợp liên tục/Triển khai liên tục) là xương sống của môi trường Devops hiện đại.
Nó rút ngắn khoảng cách giữa phát triển và vận hành bằng cách tự động hóa quá trình xây dựng, kiểm thử và triển khai ứng dụng.
Chúng ta đã đề cập khá nhiều về triết lý liên tục này trong phần mở đầu của chuỗi bài. Nhưng để nhấn mạnh lại:
Tích hợp Liên tục (CI) là một phương pháp phát triển phần mềm hiện đại, trong đó thay đổi mã nguồn được thực hiện thường xuyên và đáng tin cậy hơn. Các bước xây dựng và kiểm thử tự động được kích hoạt bởi Tích hợp Liên tục đảm bảo tính tin cậy của những thay đổi mã nguồn được gộp vào kho mã nguồn.
Mã nguồn/Ứng dụng sau đó được triển khai một cách nhanh chóng và liền mạch như một phần của quá trình Triển khai Liên tục.
Tầm quan trọng của CI/CD?
- Tạo ra phần mềm nhanh chóng và hiệu quả.
- Tạo ra một quy trình hiệu quả để đưa ứng dụng ra thị trường nhanh nhất có thể.
- Triển khai các bản sửa lỗi và tính năng mới liên tục mà không cần phải chờ hàng tháng hoặc hàng năm để phát hành phiên bản mới.
Khả năng cho phép các nhà phát triển thực hiện những thay đổi nhỏ mang tính ảnh hưởng định kỳ nghĩa là chúng ta có thể nhận được các bản vá nhanh chóng hơn và nhiều tính năng hơn một cách nhanh chóng.
Vậy điều này có ý nghĩa là gì?
Như đã được đề cập trong bài viết này, CI/CD Pipelines là nền móng của môi trường DevOps hiện đại.
Tôi muốn nhấn mạnh một số điểm mấu chốt ở hình trên, bây giờ chúng ta đã tiến xa hơn một chút trong hành trình học DevOps cơ bản.
Chúng ta đang đề cập đến vòng đời phát triển phần mềm (software development life cycle – SDLC).
Các bước thường được viết ra bên trong các vòng lặp vô tận vì nó là một chu kỳ lặp lại mãi mãi.
Các bước trong quy trình là việc các nhà phát triển viết mã nguồn sau đó được xây dựng hoặc biên dịch, sau đó được kiểm thử để tìm lỗi và triển khai vào môi trường sản phẩm nơi mà nó được sử dụng (Operated – Vận hành) bởi người dùng cuối hoặc khách hàng sau đó chúng ta theo dõi, thu thập phản hồi và cuối cùng lên kế hoạch cải tiến xung quanh phản hồi đó, sau cùng là lặp lại toàn bộ quy trình.
Xem thêm: Kiến thức về mạng
Tìm hiểu sâu hơn về CI/CD
CI
CI là một thực hành trong quy trình phát triển yêu cầu nhà phát triển tích hợp mã nguồn vào kho mã nguồn nhiều lần trong một ngày.
Khi mã nguồn được viết và đẩy lên một kho lưu trữ như Github hoặc GitLab, đó là nơi bắt đầu phép màu.
Mã nguồn được xác minh bằng quá trình xây dựng tự động, cho phép các nhóm hoặc chủ dự án phát hiện sớm bất kỳ vấn đề nào.
Từ đó, mã nguồn được phân tích và chạy qua một loạt các bài kiểm tra tự động, với ba ví dụ sau đây:
- Kiểm thử đơn vị (Unit testing) kiểm tra từng đơn vị riêng biệt của mã nguồn.
- Kiểm thử xác thực (Validation testing) đảm bảo rằng phần mềm đáp ứng hoặc phù hợp với việc mục đích sử dụng.
- Kiểm thử định dạng (Format testing) kiểm tra lỗi cú pháp và định dạng khác.
Các bài kiểm tra này được tạo thành một quy trình làm việc và sau đó chúng được chạy mỗi khi bạn đẩy mã lên nhánh chính (master branch), vì vậy hầu như mọi đội phát triển lớn đều có một quy trình làm việc CI/CD và hãy nhớ rằng trong một đội phát triển, mã nguồn mới có thể đến từ các đội khắp nơi trên thế giới vào các thời điểm khác nhau trong ngày từ các nhà phát triển làm việc trên nhiều dự án khác nhau. Xây dựng một quy trình làm việc tự động kiểm tra đảm bảo mọi người đều hoạt động theo cùng một tiêu chuẩn trước khi mã được chấp nhận, điều này hiệu quả hơn so với việc con người thực hiện điều này mỗi lần.
Khi chúng ta đã hoàn thành các bài kiểm thử và thành công, chúng ta có thể biên dịch và gửi chúng đến kho mã nguồn. Ví dụ, tôi đang sử dụng Docker Hub hoặc có thể bất cứ kho lưu trữ nào khác và sau đó sẽ được tận dụng cho khía cạnh triển khai liên tục (CD) của pipeline.
Vì vậy, quá trình này chủ yếu liên quan đến quá trình phát triển phần mềm. Chúng ta đang tạo ứng dụng, thêm, sửa lỗi và sau đó cập nhật quản lý mã nguồn và phiên bản cùng với việc kiểm thử.
Chuyển sang giai đoạn tiếp theo là yếu tố triển khai liên tục (CD), mà ngày càng nhiều chúng ta thường thấy trong bất kỳ phần mềm nào có sẵn trên thị trường. Chúng ta sẽ thấy một xu hướng, nếu chúng ta nhận phần mềm từ một nhà cung cấp như Oracle hoặc Microsoft, chúng ta sẽ sử dụng chúng từ một kho lưu trữ kiểu Docker Hub, sau đó sẽ sử dụng đường ống (pipeline) triển khai liên tục của mình để triển khai các phầm mềm đó lên môi trường của chúng ta.
CD
Bây giờ chúng ta đã có phiên bản mã nguồn đã được kiểm thử và sẵn sàng để được triển khai, nhà cung cấp phần mềm sẽ trải qua giai đoạn này, nhưng tôi rất tin rằng đây là cách chúng ta sẽ triển khai tất cả phần mềm có sẵn mà chúng ta cần trong tương lai.
Bây giờ là lúc phát hành mã nguồn vào môi trường. Điều này sẽ bao gồm Môi trường Sản phẩm (Production) nhưng cũng có thể bao gồm các môi trường khác như Môi trường Staging.
Trong bước tiếp theo, ít nhất là trong Ngày 1 của phiên bản 1 của việc triển khai phần mềm, chúng ta cần đảm bảo việc sử dụng đúng mã nguồn cho môi trường tương ứng. Điều này có thể bao gồm việc kéo từ kho lưu trữ phần mềm (DockerHub), nhưng có khả năng chúng ta cũng sẽ kéo (pull) cấu hình bổ sung từ một kho lưu trữ mã nguồn khác, chẳng hạn cấu hình cho ứng dụng. Trong biểu đồ dưới đây, chúng ta đang kéo phiên bản phần mềm mới nhất từ DockerHub, sau đó chúng ta triển khai nó vào môi trường của mình, có thể sẽ kèm theo việc lấy cấu hình từ một kho lưu trữ Git. Công cụ CD của chúng ta đang thực hiện việc này và đẩy mọi thứ vào môi trường của chúng ta.
Rất có thể việc này không được thực hiện cùng lúc. Ví dụ, chúng ta có thể đi vào một môi trường Staging và chạy kiểm tra với cấu hình của chúng ta để đảm bảo mọi thứ đúng đắn, và đây có thể là bước kiểm tra thủ công hoặc có thể lại được thực hiện tự động (hãy chọn việc tự động). Sau đó chúng ta cho phép mã nguồn này được triển khai vào môi trường Sản phẩm.
Sau đó, khi phiên bản 2 của ứng dụng ra mắt, chúng ta lặp lại các bước này. Lần này, chúng ta đảm bảo rằng ứng dụng cùng cấu hình của chúng ta được triển khai vào môi trường Staging, đảm bảo mọi thứ ổn định, sau đó chúng ta triển khai vào môi trường Sản phẩm.
Xem thêm: Điện toán đám mây
Tại sao sử dụng CI/CD?
Tôi nghĩ chúng ta có thể đã bàn về những điều này nhiều lần, đó là vì nó tự động hóa những thứ mà ban đầu phải được thực hiện thủ công. Nó tìm ra các vấn đề nhỏ trước khi chúng ảnh hưởng vào mã nguồn chính, bạn có thể tưởng tượng rằng nếu bạn sử dụng mã nguồn không tốt cho khách hàng của bạn, bạn sẽ có một khoảng thời gian khó khăn!
Nó cũng giúp ngăn chặn “nợ kỹ thuật” (technical debt), vì kho mã nguồn chính liên tục được xây dựng theo thời gian sau đó một chỉnh sửa lỗi tạm thời được thực hiện vào ngày đầu tiên sẽ trở thành một chỉnh sửa lỗi đắt đỏ hơn theo thời gian, vì bây giờ chỉnh sửa đó đã được gắn chặt chẽ và được tích hợp vào tất cả các mã nguồn và logic.
Công cụ
Tương tự như các phần khác, chúng ta sẽ thực hành với một số công cụ để thực hiện quá trình CI/CD Pipeline.
Tôi nghĩ quan trọng là chúng ta cần lưu ý rằng không phải tất cả các công cụ đều phải thực hiện cả quá trình CI và CD. Chúng ta sẽ xem xét ArgoCD, như bạn có thể đoán được, nó tốt ở với CD trong việc triển khai phần mềm của chúng ta lên một cụm Kubernetes. Nhưng một công cụ như Jenkins có thể làm việc trên nhiều nền tảng khác nhau.
Tôi có kế hoạch xem xét các công cụ sau đây:
- Jenkins
- ArgoCD
- GitHub Actions
Jenkins là gì?
Jenkins là một công cụ triển khai liên lục cho phép việc phát triển, kiểm thử và triển khai liên tục của mã nguồn mới được tạo ra.
Có hai cách chúng ta có thể đạt được điều này, thông qua việc xây dựng hàng đêm (Nightly builds) hoặc phát triển liên tục. Lựa chọn đầu tiên là các nhà phát triển phát triển mã nguồn cho các công việc vào ban ngày và đến cuối ngày làm việc, họ đẩy những thay đổi đó lên kho mã nguồn. Sau đó, vào ban đêm, chúng ta thực hiện các bài kiểm tra đơn vị và xây dựng phần mềm. Điều này được coi như cách cũ để tích hợp tất cả mã nguồn lại với nhau.
Lựa chọn còn lại và cũng là cách được ưa thích hơn đó là các nhà phát triển vẫn tiếp tục thực hiện việc commit mã nguồn tới kho mã nguồn, sau khi commit mã nguồn đó được thực hiện quá trình xây dựng mã nguồn được khởi động liên tục.
Các phương pháp trên có nghĩa là với việc các kỹ sư phát triển ở các địa điểm khác nhau trên khắp thế giới, chúng ta không có một thời gian cố định hàng ngày để dừng lại quá trình commit và thay đổi mã nguồn. Đây chính là thời điểm Jenkins ra đời đóng vai trò như một máy chủ CI để kiểm soát các quá trình kiểm thử và xây dựng.
Tôi biết chúng ta đang nói về Jenkins ở bài này nhưng tôi cũng muốn thêm một vài công cụ khác phía dưới để có cái nhìn tại sao tôi thấy Jenkins là công cụ phổ biến nhất và tại sao các công cụ khác có thể làm gì tốt hơn Jenkins.
- TravisCI – Một dịch vụ tích hợp lưu trữ, phân phối liên tục được sử dụng để xây và kiểm thử các dự án phần mềm được lưu trữ trên Github.
- Bamboo – Có thể chạy nhiều tiến trình xây dựng song song để biên dịch nhanh hơn, chức năng kết nối với kho lưu trữ tích hợp và có các tác vụ xây dựng cho Ant và Maven.
- Buildbot – là một framework mã nguồn mở để tự động hóa quy trình xây dựng, kiểm thử và phát hành phần mềm. Nó được viết bằng Python và hỗ trợ việc thực hiện song song, phân tán các công việc trên nhiều nền tảng khác nhau.
- Apache Gump – Dành riêng cho các dự án Java, được thiết kế để xây dựng và kiểm thử các dự án Java mỗi đêm, đảm bảo tất cả các dự án đều tương thích ở cả cấp độ chức năng và API.
Vì chúng ta bây giờ sẽ tập trung vào Jenkins – Jenkins một lần nữa là công cụ mã nguồn mở như các công cụ trên và là một máy chủ tự động hóa được viết bằng Java. Nó được sử dụng để tự động hóa quá trình phát triển phần mềm thông qua tích hợp liên tục và hỗ trợ quá trình phân phối liên tục.
Đặc điểm của Jenkins
Như bạn mong đợi, Jenkins có nhiều đặc điểm bảo phủ nhiều lĩnh vực.
Cài đặt dễ dàng – Jenkins là một chương trình độc lập (self-contained) viết bằng java và sẵn sàng trên mọi hệ điều hành như Windows, macOS và Linux.
Cấu hình dễ dàng – Cài đặt và cấu hình dễ dàng thông qua giao diện web bao gồm kiểm tra lỗi và hỗ trợ tích hợp sẵn.
Plug-in – Nhiều plugin có sẵn trong Trung tâm Cập nhật và tích hợp với nhiều công cụ khác trong chuỗi công cụ CI / CD.
Có thể mở rộng– Ngoài các plugin có sẵn, Jenkins có thể mở rộng được thông qua kiến trúc plugin, cung cấp gần như vô tận các tùy chọn cho những gì nó có thể được sử dụng.
Phân tán – Jenkins dễ dàng chạy trên hệ phân tán với nhiều máy chủ, giúp tăng tốc độ xây dựng, kiếm thử và triển khai qua nhiều nền tảng.
Jenkins Pipeline
Bạn sẽ thấy pipeline này nhưng được sử dụng ở phạm vi rộng hơn và ở đây chúng tôi đề cập tới các công cụ cụ thể.
Bạn commit mã nguồn tới Jenkins, nơi sau đó sẽ xây dựng ứng dụng của bạn, với tất cả bài kiểm thử tự động, nó sẽ phát hành và triển khai mã nguồn đó khi mỗi bước được hoàn thành. Jenkins sẽ tự động hoá quá trình này.
Kiến trúc Jenkins
Đầu tiên, để không làm lại những thứ đã có sẵn, Tài liệu chính thức của Jenkins luôn là nơi để bắt đầu, dù vậy, tôi vẫn sẽ ghi lại các ghi chú và kiến thức của mình ở đây.
Jenkins có thể được cài đặt trên nhiều hệ điều hành khác nhau như Windows, Linux và macOS và cả khả năng triển khai như một Docker container và trong Kubernetes. Cài đặt Jenkins
Đi sâu hơn vào vấn đề này, chúng ta có thể xem xét việc cài đặt Jenkins trong một cụm minikube mô phỏng việc triển khai trên Kubernetes. Nhưng điều này sẽ phụ thuộc vào các kịch bản chúng ta tạo ra trong phần còn lại của bài học.
Chúng ta hãy phân tích hình ảnh dưới đây.
Bước 1 – Nhà phát triển commit các thay đổi tới kho lưu trữ mã nguồn.
Bước 2 – Jenkins kiểm tra kho mã nguồn theo các khoảng thời gian đều đặn và kéo mã nguồn mới.
Bước 3 – Máy chủ xây dựng sau đó xây các mã nguồn thành chương trình thực thi, trong ví dụ này chúng ta đang dùng maven – một máy chủ xây dựng phổ biến. Đây là một lĩnh vực khác cần đề cập.
Bước 4 – Nếu việc xây dựng thất bại thì phản hồi được gửi trả về các nhà phát triển.
Bước 5 – Jenkins sau đó chuyển giao ứng dụng đã xây dựng lên máy chủ kiểm thử, trong ví dụ này, chúng ta đang dùng selenium – một máy chủ kiểm thử phổ biến. Đây là cũng là một lĩnh vực khác cần bàn luận.
Bước 6 – Nếu việc kiểm thử thất bại thì phản hồi được gửi trả về các nhà phát triển.
Bước 7 – Nếu kiểm thử thành công thì chúng ta có thể phát hành tới môi trường sản phẩm.
Chu kỳ này diễn ra liên tục, điều này cho phép các ứng dụng được cập nhật trong vài phút thay vì hàng giờ, ngày, tháng, năm!
Có rất nhiều khía cạnh khác về kiến trúc của Jenkins, ví dụ như nó có khả năng hoạt động theo kiến trúc master-slave, cho phép một master phân tán tới các slave của Jenkins.
Để tham khảo thêm, Jenkins là mã nguồn mở, sẽ có nhiều doanh nghiệp cần được hỗ trợ, Cloudbees là phiên bản doanh nghiệp của Jenkins cung cấp hỗ trợ và các chức năng trả phí khác cho các khách hàng doanh nghiệp.
Ví dụ như một trong số các khách hàng là Bosch, bạn có thể tìm hiểu về trường hợp của Bosch ở đây
Tôi sẽ tìm kiếm một ví dụ về một ứng dụng mà chúng ta có thể dùng qua đó hiểu được việc sử dụng Jenkins và sử dụng nó với các công cụ khác.
Thực hành cùng Jenkins
Bây giờ chúng ta sẽ thực hành cùng Jenkins và thực hiện một số việc như một phần của CI pipeline, xem xét một số mã nguồn ví dụ mà chúng ta có thể sử dụng.
Pipeline là gì?
Trước khi bắt đầu chúng ta cần biết một pipeline là gì khi đến với CI, và chúng ta đã đề cập điều này ở ngày trước đó với ảnh sau đây
Chúng ta muốn thực hiện quy trình hoặc các bước phía trên và tự động hóa chúng để có một kết quả cuối cùng, nghĩa là chúng ta đã triển khai ứng dụng mà chúng ta có thể đưa tới khách hàng, người dùng cuối, vân vân.
Quy trình tự động này cho phép chúng ta duy trì kiểm soát phiên bản đến người dùng và khách hàng của chúng ta. Mọi thay đổi, nâng cao tính năng, sửa lỗi, vân vân đều thông qua quy trình tự động này xác nhận rằng mọi thứ đều ổn mà không tốn quá nhiều sự can thiệp thủ công để đảm bảo rằng mà nguồn của chúng ta là tốt.
Quy trình này bao gồm việc xây dựng phần mềm một cách đáng tin cậy và có thể lặp lại, cũng như đưa phần mềm đã được xây dựng (gọi là “build”) qua nhiều giai đoạn kiểm thử và triển khai.
Jenkins pipeline được viết vào một tệp văn bản gọi là Jenkinsfile. Nó được commit tới một kho điều khiển mã nguồn. Điều này cũng được biết như là Pipeline dưới dạng mã nguồn, chúng ta cũng có thể thấy rất giống với Cơ sở hạ tầng dưới dạng mã nguồn mà ta đã đề cập ở vài tuần trước.
Triển khai Jenkins
Tôi có chút thích thú khi triển khai Jenkins, bạn sẽ nhận ra từ tài liệu rằng có nhiều tùy chọn giúp bạn có thể cài đặt Jenkins.
Với việc tôi đã có sẵn minikube và chúng ta đã sử dụng nó một số lần, tôi cũng muốn sử dụng nó cho tác vụ này.(Nó cũng là miễn phí!) Mặc dù các bước đưa ra trong Cài đặt Kubernetes khiến tôi gặp khó khăn và không khởi chạy được Jenkins, bạn có thể so sánh với các bước tôi ghi lại ở đây.
Bước đầu tiên là khởi chạy cụm minikube của chúng ta, chúng ta có thể làm điều này với câu lệnh minikube start
Tôi đã thêm một thư mục với tất cả giá trị và cấu hình YAML có thể thấy ở đây. Bây giờ chúng ta đã có cụm riêng và có thể chạy lệnh sau đây để tạo không gian tên jenkins. kubectl create -f
Chúng ta sẽ sử dụng Helm để triển khai Jenkins tới cụm, chúng ta đã đề cập tới helm ở phần Kubernetes. Đầu tiên chúng ta cần thêm kho lưu trữ jenkinsci helm helm repo add jenkinsci https://charts.jenkins.io sau đó cập nhật các biểu đồ của helm helm repo update .
Ý tưởng đằng sau Jenkins là nó sẽ lưu trạng thái pipeline của nó, bạn có thể khởi chạy cài đặt helm như ở trên nhưng nếu các pod đó khởi động lại, bị thay đổi hoặc chỉnh sửa thì mọi pipeline hoặc cấu hình đã tạo sẽ bị mất. Chúng ta sẽ tạo một ổ đĩa để lưu trữ lâu dài bằng sử dụng tệp jenkins-volume.yml với câu lệnh kubectl apply -f jenkins-volume.yml .
Chúng ta cũng cần một service account (shoud i change to tài khoản dịch vụ) có thể tạo bằng câu lệnh và tệp YAML này. kubectl apply -f jenkins-sa.yml
Ở giai đoạn này, chúng ta đã sẵn sàng triển khai bằng cách sử dụng biểu đồ helm, chúng ta đầu tiên cần định nghĩa biểu đồ sử dụng chart=jenkinsci/jenkins và sau đó chúng ta sẽ triển khai sử dụng câu lệnh này, trong đó tệp jenkins-values.yml các service account mà chúng ta đã triển khai trước đó tới cụm. helm install jenkins -n jenkins -f jenkins-values.yml $chart
Tại giai đoạn này, các pod sẽ kéo hình ảnh nhưng pod sẽ không có quyền truy cập tới tài nguyên lưu trữ, vì vậy cấu hình không thể bắt đầu để khởi tạo Jenkins.
Đây chính là điều mà tài liệu không giúp tôi hiểu rõ điều gì cần phải xảy ra. Nhưng chúng ta có thể thấy rằng chúng ta không có quyền để bắt đầu việc cài đặt Jenkins.
Để khắc phục vấn đề trên hoặc giải quyết nó, chúng ta cần đảm bảo rằng chúng ta cung cấp quyền truy cập hoặc quyền hợp lệ cho các Jenkins pod có thể ghi dữ liệu vào vị trí chúng ta đề xuất. Chúng ta có thể thực hiện điều này bằng cách sử dụng minikube ssh, điều này sẽ đưa chúng ta vào bên trong container docker của minikube mà chúng ta đang chạy, sau đó sử dụng sudo chown -R 1000:1000 /data/jenkins-volume để đảm bảo rằng chúng ta đã đặt quyền hợp lệ trên volume lưu dữ liệu của chúng ta.
Quá trình trên có thể sửa được lỗi các pod, tuy nhiên, nếu không thành công bạn có thể làm mới các pod với câu lệnh kubectl delete pod jenkins-0 -n jenkins. Lúc này, bạn sẽ có 2/2 pod đang chạy gọi là jenkns-0.
Bây giờ chúng ta cần mật khẩu admin và có thể sử dụng câu lệnh sau để lấy thông tin. kubectl exec --namespace jenkins -it svc/jenkins -c jenkins -- /bin/cat /run/secrets/chart-admin-password && echo
Hãy mở một cửa sổ terminal mới vì chúng ta sẽ sử dụng câu lệnh port-forward cho phép chúng ta truy cập từ máy trạm. kubectl --namespace jenkins port-forward svc/jenkins 8080:8080
Chúng ta bây giờ có thể mở trình duyệt và truy cập http://localhost:8080 xác thực với tài khoản: admin và mật khẩu đã lấy ở bước trước đó.
Sau khi xác thực thành công, trang chào mừng tới Jenkins sẽ có giao diện như hình:
Từ đây, tôi đề xuất bạn đi đến mục “Manage Jenkins” và ban sẽ thấy mục “Manage Plugins” có một số bản cập nhật có sẵn. Chọn tất cả các plugin và chọn “Download now and install after restart”
Nếu bạn muốn đi sâu hơn và tự động triển khai Jenkins sử dụng tập lệnh shell hãy tham khảo kho lưu trữ này đã được chia sẻ với tôi trên Twitter mehyedes/nodejs-k8s
Jenkinsfile
Bây giờ chúng ta đã có Jenkins được triển khai trong cụm Kubernetes, chúng ta có thể quay lại và suy nghĩ về Jenkinsfile.
Mọi Jenkinsfile có thể bắt đầu như sau, đầu tiên là nơi bạn xác định các bước của pipeline, ở trường hợp này bạn có Xây dựng > Kiểm thử > Triển khai. Nhưng chúng ta sẽ không làm điều gì khác ngoài sử dụng lệnh echo để gọi ra các giai đoạn cụ thể.
Jenkinsfile (Declarative Pipeline)
pipeline {
agent any
stages {
stage('Build') {
steps {
echo 'Building..'
}
}
stage('Test') {
steps {
echo 'Testing..'
}
}
stage('Deploy') {
steps {
echo 'Deploying....'
}
}
}
}
Trong bảng điều khiển Jenkins, chọn “New Item” và đặt tên, tôi sẽ đặt là “echo1” và tôi đề xuất lựa chọn tiếp theo là Pipeline.
Bấm OK và bạn sẽ có các tab (General, Build Triggers, Advanced Project Options and Pipeline), cho một bài kiểm tra đơn giản chúng ta chỉ quan tâm đến Pipeline. Dưới Pipeline bạn có thể thêm tập lệnh, chúng ta có thể sao chép và dán tập lệnh ở trên vào ô trống.
Như đã đề cập ở trên, Pipeline này sẽ không làm gì nhiều nhưng nó sẽ cho chúng ta thấy các giai đoạn của Xây dựng > Kiểm thử > Triển khai.
Bấm Save, chúng ta bây giờ có thể khởi chạy xây dựng sử dụng lựa chọn build now như ảnh dưới.
Chúng ta cũng sẽ mở một cửa sổ terminal và chạy câu lệnh kubectl get pods -n jenkins để xem điều gì xảy ra.
Được rồi, rất đơn giản nhưng chúng ta có thể thấy rằng triển khai và cài đặt Jenkins của chúng ta đã hoạt động chính xác và có thể bắt đầu thấy các khối xây dựng của CI pipeline ở đây.
Ở phần tiếp theo, chúng ta sẽ xây dựng một Jenkins Pipeline.
