CI/CD from on-premise to cloud Trình bày bởi: Thạnh Nguyễn & Hiếu Phan 1

Nội dung 1. Giới thiệu chung về CI/CD 2. Hướng tiếp cận pull vs push trong việc xây dựng CI/CD 3. Giới thiệu về Gitlab CI/CD 4. Giới thiệu về AWS CI/CD 2

1. Giới thiệu chung về CI/CD ❖ Khái niệm ➢ Continuous integration ➢ Continuous delivery ➢ Continuous deployment ❖ Các thành phần chính trong khía cạnh kỹ thuật ➢ CI server ➢ Deploy server ➢ Artifacts ➢ Triggers ➢ Cache ➢ ... 3

4

Continuous integration ❖ Mục tiêu ➢ Phát hiện lỗi nhanh nhất có thể ➢ Giảm thiểu thời gian phát triển phần mềm và những vấn đề gặp phải trong quá trình tích hợp ❖ Khía cạnh kỹ thuật ➢ Tự động tạo một release mới khi có code mới ➢ Build và chạy (unit / integration test cases) trong môi trường nhất quán (ví dụ như docker, ...) ➢ Liên tục tạo ra artifact sẵn sàng cho deployment ➢ Liên tục tạo ra feedback khi build fails 5

Continuous integration ❖ Cách thành phần chính trong khía cạnh kỹ thuật ➢ Version control system: là công cụ quản lý code ➢ Branching strategy: xác định cách thức và trường hợp nào phân nhánh (branch) và hợp nhất (merge): gitflow branching model, truck- based development, task/feature branching, … ➢ CI tools: gitlab CI, jenkins, aws codebuild, ... ➢ Self-triggered builds: công cụ giúp trigger tự động build khi có code mới ➢ Code coverage tools: static code analysis (sonarqube, ...) ➢ Artifact repository tools: (docker hub,gitlab registry, ECR, artifactory, ...) 6

7

Continuous delivery ❖ Mục tiêu ➢ Triển khai code mới đến môi trường staging một cách tự động ➢ Sẵn sàng deploy lên môi trường production ❖ Khía cạnh kỹ thuật ➢ Automated testing với system integration testing (SIT), User Acceptance Testing (UAT), performance test (PT), ... ➢ Có thể manual testing với UI testing, API testing, ... ➢ Cần approval và deploy thủ công lên môi trường production 8

Continuous delivery ❖ Trường hợp sử dụng ➢ Cấu hình ở môi trường staging và prod không giống nhau về network topology, số lượng instance ➢ Khó để automated testing hoàn toàn ➢ Cần bên thứ ba xác nhận và testing ➢ Cần chuyển giao sản phẩm cho khách hàng để họ tự deploy lên server của họ ❖ Được khuyến khích sử dụng trong CI/CD vì đảm bảo nhanh trong quá trình phát triển, ổn định trong quá trình vận hành hệ thống và an toàn trong giai đoạn triển khai đến khách hàng 9

Continuous deployment 10

Continuous deployment ❖ Mục tiêu ➢ Deploy lên prod mà không ảnh hưởng đến customers ➢ Chuyển giao đến customers nhanh hơn bởi tăng tần suất deployment ❖ Khía cạnh kỹ thuật ➢ Tự động deploy code mới lên staging cho việc testing ➢ Tự động deploy lên prod khi việc testing thành công ➢ Xử lý sự phức tạp của việc cập nhật phần mềm mà không ảnh hưởng đến khách hàng ➢ Tránh downtime trong suốt quá trình triển khai ứng dụng với các strategy: canary, blue-green, ... ➢ Roll back tự động nếu phát hiện defect (lỗi được phát hiện trên prod) 11

Continuous deployment ❖ Trường hợp sử dụng ➢ Trong giai đoạn POC (Proof of Concept) hoặc MVP (Minimum Viable Product) của sản phẩm nhằm thử nghiệm một ý tưởng mới ➢ Cần feedback liên tục từ khách hàng để hoàn thiện sản phẩm ➢ Có thể dùng để phát triển phần mềm nội bộ 12

2. Hướng tiếp cận pull vs push trong xây dựng CI/CD ❖ Push-based: một hệ thống bên ngoài trigger đến, pipeline có khả năng truy cập đến infra, thay đổi infra trực tiếp ❖ Pull-based: pipeline không có khả năng thay đổi infra trực tiếp, tất cả thay đổi được áp dụng bên trong infra thông qua một operator 13

2.1 Push-based CI/CD 14

2.1 Push-based CI/CD ❖ Ưu điểm ➢ Hiện thực CI/CD flow dễ dàng ➢ Công cụ đa dạng, có thể tùy chỉnh đa dạng theo yêu cầu của hệ thống ❖ Nhược điểm ➢ Pipeline có quyền thực thi trực tiếp đến infra => không an toàn ➢ Strongly coupled với hệ thống => khi muốn migrate sang một hệ thống khác cần thay đổi nhiều về cấu hình công cụ ➢ Ví dụ: gitlab CI dùng gitlab-ci.yml chuyển sang jenkins thì dùng Jenkinsfile 15

Ví dụ điển hình là auto devops trong gitlab 16

2.2 Pull-based CI/CD 17

2.2 Pull-based CI/CD ❖ Operator pattern: có một operator trong infra liên kết với git, registries, ... nó sẽ scan sự thay đổi, nếu có sự thay đổi thì nó sẽ cập nhật lại trạng thái của infra ❖ Ưu điểm ➢ Rất an toàn, vì không có external client có quyền để cập nhật infra ➢ Có thể áp dụng multi-tenant model. Team A dùng namespace A, Team B dùng namespace B, Infra team truy cập được toàn bộ, … ➢ No coupling với CD pipeline ❖ Nhược điểm ➢ Quản lý khó hơn vì phân tán công cụ ➢ Hiện thực CI/CD flow khó hơn ➢ Phụ thuộc vào công cụ có chức năng pull ➢ Phải cài đặt agent / operator trong infra ➢ Supply chain attacks 18

Ví dụ điển hình là fux 19

3.1. Giới thiệu về Gitlab CI/CD ❖ Là CI/CD và là 1 phần của Gitlab ❖ Đơn giản, dễ dùng, dễ tích hợp vào các repository của Gitlab ❖ Free 20

3.1. Giới thiệu về Gitlab CI/CD https://docs.gitlab.com/ee/ci/yaml/ 21

3.2. Một số tính năng hay của Gitlab CI/CD 1. Extends: 22

3.2. Một số tính năng hay của Gitlab CI/CD 2. Template: template.yml .gitlab-ci.yml 23

3.2. Một số tính năng hay của Gitlab CI/CD 3. Coverage: 24

3.2. Một số tính năng hay của Gitlab CI/CD 4. Retry: https://docs.gitlab.com/ee/ci/yaml/#retry 25

3.3. Tối ưu tốc độ Gitlab CI/CD Tận dụng multi-stage để cache khi build docker image Cach e 26

3.3. Tối ưu tốc độ Gitlab CI/CD Cache ở runner 27

3.4. Điểm mạnh của Gitlab CI/CD ❖ Có tính năng template, YAML anchors and aliases => dễ tái sử dụng ❖ Có thể re-run lại từng job riêng lẻ => Tiết kiệm thời gian ❖ Tính năng Auto DevOps ❖ Runner setup dễ trên nhiều môi trường: shell, docker, kubernetes ❖ Container registry: webhook, high availability, expiration policies, garbage collection ❖ Helm chart repository 28

3.5. Điểm yếu của Gitlab CI/CD ❖ Không có Marketplace như Github Action ❖ Chỉ dùng được với Gitlab 29

4. Giới thiệu về AWS CI/CD ❖ CodeCommit: ➢ Lưu trữ code ➢ Tương tự github,gitlab ❖ CodeBuild: ➢ Building và testing code ➢ Tương tự gitlab CI, Jenkins ❖ CodeDeploy: ➢ Deploying build đến EC2 fleet với file cấu hình appspec.yml ➢ EC2 sẽ chạy các lệnh trong file appspec.yml ❖ CodePipeline: ➢ Giúp xây dựng pipeline nhằm triển khai ứng dụng một các liên tục và tự động ➢ Trực quan hóa các bước như kết nối với source code, build, automated deploy, manual deploy 30

31

Codepipeline ❖ Continuous delivery ❖ Visual workflow có thể gồm: ➢ Source: GitHub, CodeCommit, S3, … ➢ Build: CodeBuild, Jenkins, … ➢ Load Testing: sử dụng bên thứ ba ➢ Deploy: CodeDeploy, Beanstalk, CloudFormation, ECS, … ❖ Mỗi stage có những actions chạy tuần tự hoặc song song ❖ Manual approval có thể định nghĩa ở bất kỳ stage nào => công cụ giúp tùy chỉnh việc sử dụng phương pháp continuous delivery hay continuous deployment 32

Codepipeline artifact ❖ Mỗi stage có thể tạo “artifacts” ❖ Artifacts được lưu trữ trong S3 và truyền đến stage tiếp theo 33

Demo 34

35

Cách bước thực hiện 1. Push source code to github 2. Create github token to pipeline connect to github 3. Create infra by terraform, it consists of load balancer, ecs cluster, ... 4. Create aws code pipeline by terraform 5. Change code 6. Push a commit 7. Watch CI/CD process in AWS 8. Test change 36

Tài liệu tham khảo https://viblo.asia/p/phat-trien-phan-mem-bot-nong-dan-voi-cicd- XL6lAyzrlek https://www.weave.works/blog/why-is-a-pull-vs-a-push-pipeline- important https://dzone.com/articles/why-is-a-pull-vs-a-push-pipeline-important https://stackoverflow.com/questions/14972853/pull-vs-push-deployment https://alex.kaskaso.li/post/pull-based-pipelines https://faun.pub/pull-based-cd-pipelines-for-security-4e044b403f56 37

THANKS FOR LISTENING 38