Nội dung:

• Giới thiệu
• What is DevOps?
• DevOps Culture
• DevOps Phases and Tools
• DevOps Concepts
• How to become DevOps Engineer?
• Giới thiệu tổng quan các tool trong DevOps.
• The 2019 DevOps RoadMap
• Learn and Practice

🔰 Giới thiệu

Chào mọi người, lại là mình đây. Có lẽ nhiều bạn đã đọc các blog trước của mình, các chủ đề thường liên quan đến DevOps, Kubernetes, v.v... Mình sẽ tự giới thiệu 1 chút.
Tên: N.X.Phong - DevOps công ty GMO Z.com VietNam Lab Center, Số năm kinh nghiệm làm DevOps là 2,5 năm (quá ít phải không nhỉ :D ). Hiện tại mình cùng với team 8 thành viên (4 member VN, 4 member ở Nhật) phát triển và vận hành hệ thống web thương mại điện tử (point service) khoảng hơn 20 triệu người dùng, cung cấp API cho khoảng gần 20 site liên kết. Số lượng server cho các môi trường (dev, staging, design, security, pre product, product) trên 150 server, Riêng số server dành riêng cho Product đã hơn 50 server chạy hàng chục service khác nhau. Dưới đây là hầu hết các công nghệ dự án mình đang sử dụng.

Ngoài ra còn một số công cụ như Rancher, Harbor, Redash, v.v... mình tạm thời chưa liệt kê hết.

Đối tượng bài viết này là ai? Sẽ hướng đến những bạn sinh viên, những bạn chưa có kiến thức nhiều về DevOps, cho những bạn đang còn loay hoay không biết đi hướng nào để trở thành DevOps. và có thể là tham khảo cho những bạn khác. Các bạn có nhiều kinh nghiệm khi đọc bài này xin hãy để lại ít gạch đá để mình xây nhà nhé! :D Mình mạn phép "mùa rìu qua mắt thợ" tý.

Mục đích bài viết này? chia sẻ kiến thức thu được trong quá trình làm dự án với các Kỹ sư dày dạn kinh nghiệm ở Nhật. Bản thân tự đánh giá và đưa ra các gợi ý về các kiến thức cũng như các công nghệ cần thiết để vận hành hệ thống.

Bản thân tự cảm thấy đã hiểu được các lợi ích của DevOps, liên quan trực tiếp đến việc cải thiện quy trình triển khai và phát triển phần mềm. Tuy nhiên, từ kinh nghiệm hạn hẹp của mình, trở thành kỹ sư DevOps không bao giờ là dễ dàng.

Do yêu cầu sâu rộng về kiến thức, công cụ và nhiều kinh nghiệm thực tiễn, việc chọn đúng con đường để trở thành một kỹ sư DevOps thành công có thể là một nhiệm vụ khó khăn.

🔰 What is DevOps?

Có lẽ các bạn đã nghe nhiều đến khái niệm devops rồi. Đại khái nó là thế này

DevOps là một văn hóa làm việc đề cao sự hợp tác, kéo hai giai đoạn phát triển (development) và vận hành (operations) xích lại gần nhau hơn. Khái niệm DevOps ra đời nhằm tối ưu hóa chu trình phát triển phần mềm, giúp sản phẩm IT được release nhanh và thường xuyên hơn.

Bạn nào chưa hiểu rõ có đọc thêm ở đây:
https://www.quora.com/What-is-DevOps
https://viblo.asia/p/tim-hieu-ve-devops-phan-1-ByEZk9Mo5Q0

🔰 DevOps Culture

DevOps is a culture, not a role!

Ngày nay, mọi cơ quan, tổ chức lớn đều liên quan đên phát triển phần mềm. Có nhiều áp lực đối với việc chuyển giao nhanh hơn mà không phải bỏ qua tính bảo mật hay độ tin cậy. Áp lực này thể hiện ở việc các dự án bị hủy bỏ hoặc tạm dừng. Đây là tính huống mà DevOps phải tìm cách giải quyết: làm thể nào để các nhóm development, operation và các nhóm khác trong tố chức hợp tác xung quanh 1 mục tiêu chung để cung cấp phầm mềm nhanh và tin cậy đến end user. Từ đó nảy sinh ra văn hóa gọi là DevOps để chuẩn hóa bộ quy trình và công cụ cho việc delivery phần mềm, chúng thường bao gồm:

• Automated configuration management, testing and application deployment
• Version control of application and infrastructure code to enable collaboration and rollbacks
• CI (continuous integration) to automate code builds and enable faster feedback and iteration through more frequent, lower risk releases.

Về văn hoá làm việc của DevOps các bạn cũng có thể đọc ở đây nhé.
https://medium.com/@neonrocket/devops-is-a-culture-not-a-role-be1bed149b0
https://viblo.asia/p/tim-hieu-ve-devops-phan-1-ByEZk9Mo5Q0

🔰 DevOps Phases and Tools

DevOps Phases

Các giai đoạn trong quy trình làm việc DevOps các bạn có thể hình dung như hình bên dưới:

Phần việc của Developer là Plan - Coding -Build - Test, Phần việc của Operation là Deploy - Operator - Monitoring. Và khối chính giữa chính là sự tích hợp giữa Development và Operation tạo nên một quy trình thống nhất.

DevOps Phases and Tool

Để dễ hình dung các giai đoạn, mình sẽ nêu ra đây vài đại diện các tool được sử dụng.

Nguồn: https://www.edureka.co/blog/devops-tools

Có thể có nhiều tool các bạn còn chưa biết, nhưng không sao, chúng ta cứ đi tiếp.

🔰 DevOps Concepts

Dưới đây mình sẽ nêu ra những khái niệm mà mình nghĩ nó quan trọng đối với DevOps.

1. Build Automation

Tùy vào ngôn ngữ được sử dụng mà cần phải compile, transform hoặc thực hiện unit test,... đối với code. Thông thường build automation cũng giống như việc chạy một command - line tool để chạy đoạn code đã được viết script hoặc được setting trong file config.

• Build Automation là một quy trình tự động để chuẩn bị source code deploy lên môi trường bằng cách sử dụng script hoặc tool.
• Build automation sẽ giúp tiết kiệm thời gian, có thể handle được những task cần phải build theo một quy trình nhất định nào đó.
• Build automation còn giúp thực hiện việc build code trên bất kỳ môi trường nào.
• Bất cứ ai trong team cũng có thể làm được.

2. Continuous Integration ( CI - Tích hợp liên tục)

Tích hợp liên tục (CI) là phương pháp phát triển phần mềm đòi hỏi các thành viên trong nhóm tích hợp công việc thường xuyên.
Các developer phải thường xuyên merge code thay đổi, build, auto test để detect vấn đề khi merge.
Khi developer commit source code thay đổi của họ lên, CI Server sẽ thấy sự thay đổi này và bắt đầu thực hiện build, test source code thay đổi một cách tự động. Quá trình này sẽ được thực hiện nhiều lần trong 1 ngày, và nếu CI server phát hiện có vấn đề xảy ra nó sẽ ngay lập tức hiển thị thông báo cho developer.

Các lợi ích khi sử dụng CI

• CI sẽ giúp phát hiện ra bug sớm, thông báo cho developer.
• CI sẽ giúp tránh việc phải merge một lượng code lớn khi release.
• Khi code được build liên tục nó cũng tạo ra Continuos Testing (Test liên tục), QA có thể test ngay lập tức những chỉnh sửa đã được đưa lên mà không cần chờ đến khi mọi thứ hoàn thành.

Tham khảo thêm tại:

1. https://viblo.asia/p/continuous-integration-with-jenkins-bai-1-gioi-thieu-ve-ci-va-jenkins-OeVKBggEZkW
2. https://viblo.asia/p/tim-hieu-ve-devops-phan-1-ByEZk9Mo5Q0
   
   Nguồn: toidicodedao

CI tool

• http://www.scmgalaxy.com/tutorials/top-10-continuous-integration-tool/

Trong các tool để vận hành CI thì có lẽ Jenkins được gợi ý nhiều nhất, có lẽ do Jenkins là open source và free. Hiện tại bên mình đang dùng Bamboo, Bamboo là một trong các sản phẩm của Atlassian. Nói về Atlassian thì bên mình đang sử dụng Jira(quản lý task theo Agile-Scrum), Confluence(Quản lý tài liệu dự án online, VIP hơn SVN rất nhiều, thay đổi tài liệu có mail bắn về cho team, có thể review và comment tài liệu. Trước đây toàn sử dụng SVN để quản lý tài liệu Excel...), Bitbucket quản lý source code. (Bitbucket thực sự có nhiều chức năng VIP hơn Github, GitLab nhiều, xài rất OK). Nhưng ở mức độ doanh nghiệp nhỏ hay chỉ học thôi thì Jenkins là sự lựa chọn Ok rồi.

3. Continuous Delivery và Continuous Deployment

Trước hết Continuous Delivery: được hiểu là chuyển giao liên tục, là 1 tập hợp các kỹ thuật nhằm đảm bảo việc triển khai tích hợp souce code trên môi trường staging (một môi trường rất giống với môi trường production). Theo cách này ta có thể đảm bảo source được kiểm thử một cách tỉ mỉ trước khi deploy lên môi trường production. Khi đó source code sẽ không được deploy tự động sang môi trường production.
Continuous Deployment: là 1 bước phát triển của Coninuous Delivery, giúp hoàn tất giai đoạn triển khai từ môi trường staging ( môi trường kiểm thử) sang môi trường production. Bằng cách này sources code sẽ đuợc tự động deploy lên môi trường production.
Vì vậy, ta sẽ hiểu CD là Continuous Delivery hay Continuous Deployment thì phụ thuộc vào cách thức mà nó triển khai trai trên môi trường production hay môi trường testing/staging.

Nguồn:https://puppet.com/blog/continuous-delivery-vs-continuous-deployment-what-s-diff

So sánh tổng quan về CI/CD thì như hình bên dưới

Nguồn: stackoverflow
Nhìn nhận tổng quan thì CI/CD pipeline thường gồm các bước sau:

• Commit. Khi lập trình viên hoàn thành một thay đổi thì anh ta sẽ commit thay đổi đó vào một source code repository
• Build. Thay đổi được lấy ra từ repository và sau đó phần mềm được build để có thể chạy trên máy tính. Bước này phụ thuộc vào ngôn ngữ nào được dùng, đối với các ngôn ngữ phiên dịch (interpreted languages) thì bước này có thể được loại bỏ.
• Automated tests. Đây là phần chính của CI/CD pipeline. Các thay đổi được test ở nhiều góc độ để đảm bảo nó hoạt động và không làm hại đến những phần khác.
• Deploy. Phiên bản đã được build sẽ được đưa lên production.

Với cách làm như vậy Continuous Delivery và Continuous Deployment sẽ đem lại những lợi ích như dưới đây:

• Nhanh chóng đưa sản phẩm đến tay khách hàng
• Giảm thiếu các vấn đề xảy ra khi deploy
• Giảm thiếu risk: lượng deploy trong 1 lần càng nhiều, risk càng cao. Việc chia nhỏ lượng deploy sẽ giảm thiểu risk.
• Rollback lập tức khi xảy ra lỗi
• Giúp developer không còn lo lắng khi deploy khi đã có chức năng roll back automation.

Đến đây thì mình nhìn nhận lại dự án hiện tại của mình một chút. Hiện tại đang dùng CI/CD, nhưng là Continuous Delivery chứ không phải Continuous Deployment, và Continuous Delivery cũng không áp dụng cho toàn bộ. Mình tự hỏi tại sao lại như thế?
Hiện tại với mỗi commit của member, sẽ được build và automation test (CI), nhưng có triển khai ngay lên môi trường Staging (gần với Production) không? thì cũng tuỳ trường hợp. Hiện tại đối với những thay đổi của design, sẽ tiến hành Continuous Delivery. còn đối với Developer, sau khi code được merge vào master mới triển khai lên môi trường DEV -> Staging. Sao lại rườm rà và thủ công như vậy. Cái này tuỳ thuộc vào dự án, mà triển khai sao cho hợp lý. Môi trường DEV bên mình có thể tự do deploy, test thoải mái nhưng môi trường Staging còn được dùng bởi gần 20 site liên kết. Vậy nên các thay đổi đến Staging thông thường sẽ được test trước ở môi trường DEV. còn Continuous Deployment thì bên mình không triển khai, thực hiện bằng con người chứ không để tool chạy tự động.

4. Infrastructure as Code (IaC)

Infrastructure as Code là method giúp quản lý, xây dựng cơ sở hạ tầng (Infra) cho sản phẩm của bạn. Với Infrastructure as Code, thay vì thực hiện thủ công theo manual. Bạn có thể viết code và cho chạy tự động.
Các đối tượng xây dựng trong Infra bao gồm: Server, Instance, môi trường, Container,...

Với mình đây thứ tuyệt với nhất với DevOps. Các bạn có thể hình dung thế này. Khi bạn bắt đầu vào dự án, leader hay ai đó đưa cho bạn 1 cái GUI để setup môi trường, và bạn phải hì hục đi tìm các công cụ, rồi chạy command, copy file/folder, v.v... đủ thứ các thể loại. Mất cả ngày nếu như môi trường phức tạp. Chưa kể làm đã đời nó lại không chạy, mà đấy đôi khi chỉ là môi trường để run cái web thôi, chứ chưa nói gì đến các môi trường khác... Thế đấy, chưa kể bạn còn có thể sai sót trong quá trình chọn version, bỏ qua step bla bla.
Ở đây thật sự Infrastructure as Code rất quan trọng. khi chỉ vài command line, môi trường đồ sộ của bạn đã chạy được. tất cả các member đều dùng 1 môi trường phát triển thống nhất. dù cho bạn xài Windows, Mac hay Linux đều không ảnh hưởng gì. Chúng ta cùng xem qua các lợi ích của IaC.

Vì sao nên sử dụng IaC?

• Tạo và quản lý resource đúng tiêu chuẩn. Tất cả mọi việc được thực hiện automation.
• Tính linh hoạt: IaC cho phép thực hiện cùng một thay đổi giống nhau trên nhiều host, và có thể sử dụng lại trong tương lai.
• Tính co dãn (Scalability) : khi cần thêm instance bạn chỉ cần cho chạy lại config giống với instance có sẵn và một instance mới được tạo ra chỉ trong vài phút hoặc vài giây.
• Self-documenting: với IaC để xem những config của hệ thống chỉ cần xem trong source control, bạn không cần phải log lại hoặc tạo 1 tài liệu bất kỳ nào để lưu giữ thông tin config. Chính bản thân code được dùng để build infra chính là document.

Tất nhiên để sử dụng các công cụ Infrastructure as Code, bạn phải mất nhiều thời gian để học, tối ưu hoá. mục đích hướng đến là tính automation, và quản lý Infrastructure bằng việc viết code.
Một số Infrastructure as Code Tool:
https://www.thorntech.com/2018/04/15-infrastructure-as-code-tools/

Có nhiều công cụ được đưa ra, bản thân mình khuyên dùng 3 công cụ trong khung đỏ.

🔰 How to become DevOps Engineer?

Theo ý kiến cá nhân mình:

• Hiểu được bản chất của DevOps
• Là một Developer (bạn chắc chắn phải lập trình như 1 developer)
• Kỹ năng lập trình Python, shell script.
• Hiểu sâu, thông thạo về HDH đang sử dụng (Linux, Docker, v.v...)
• Khả năng research tốt
• Có tính cẩn thận, tỉ mỉ
• Kinh nghiệm về system và IT operation
• Nắm vững các tiến trình (CI/CD) và các công cụ tự động hóa
• Khả năng sử dụng nhiều công cụ mã nguồn mở, coding/scripting

Trong các yếu tố trên thì mình muốn nhấn mạnh các điểm sau:
Tính cẩn thận, tỉ mỉ:
Vận hành hệ thống không phải là chuyện ngày một ngày hai, hệ thống có chạy trơn tru thì DevOps mới ngủ ngon được. Vì vậy, không được cẩu thả, command phải chính xác. "Đừng bao giờ thực thi command khi không hình dung được kết quả nhận được là gì ". Bản thân cũng làm chết server nhiều lần rồi nên đúc kết như vậy :D.

Khả năng research tốt
Đương nhiên rồi, không chỉ riêng DevOps mà công việc nào cũng đòi hỏi cả. Nhưng DevOps lại càng yêu cầu khắt khe hơn, chuyện gặp lỗi là chuyện hàng ngày, hãy quen với nó và đừng thấy khó chịu, không có chuyện một phát ăn ngay. Ở đây để research hiệu quả còn cần phải có khả năng phân tích vấn đề nữa. Mình sẽ ví dụ về 1 trường hợp phân tích nguyên nhân:
Ví dụ bạn access đến Nginx thông qua Browser và xảy ra lỗi.
Phương châm ở đây là nginx lỗi hay network có vấn đề
Nội dung cần confirm là:
Login trực tiếp đến nginx server và thực hiện gửi request đến localhost thông qua lệnh curl. Dựa vào kết quả có thể chia ra như sau:

• Có response trả về -> Nginx hoạt động bình thường, vấn đề có thể nằm ở firewall hoặc network (Như vậy có thể hiểu vấn đề không nằm ở nginx)
• Không có response trả về -> Cần kiểm tra nginx có đang hoạt động không? hay nginx config có vấn đề gì không. (Như vậy có thể hiểu vấn đề nằm ở nginx.)

Có nhiều trường hợp khi triển khai một middleware nào đó gồm nhiều thành phần, và không hoạt động như mong đợi. Việc phân tách xem vấn nằm ở đâu rất cần thiết.

Dành cho các bạn đi lên từ Developer.

Bản thân mình cũng là một Developer -> DevOps. Mình gặp những khó khăn khi bắt đầu học DevOps như sau.

1. Chưa thông thạo về HDH Linux. (ở trường đại học có môn Linux nhưng mà học dc rất ít :D)
2. Rất ngại sử dụng command line (khó nhớ, không có giao diện dể nhìn, toàn màn hình đen)
3. Chưa có cái nhìn tổng quát về vận hành hệ thống. (đại khái là web nó chạy dc ở local là dc, còn ở Production họ triển khai như thế nào không biết)
4. Kinh nghiệm về system và IT operation (Cái này thì đúng là Developer bình thường không biết được)
5. Khá nhiều công cụ dành cho vận hành mình chưa biết đến.

Vì vậy mình nghĩ các bạn Dev muốn đi lên DevOps thì khắc phục các điểm phía trên của mình. Ngoài ra thì có một tiền bối nào đó chỉ đường nữa là quá tuyệt vời.

Dành cho các bạn đi lên từ System Admin, IT Operation.

Với những bạn như vậy chắc là chỉ khuyên các bạn học lập trình như Developer, tham gia dự án để hiểu được hệ thống, hiểu được các chức năng cũng như yêu cầu hệ thống. từ đó có cái nhìn phù hợp để triển khai hệ thống tốt hơn.

Các bạn System Admin, IT Operation đi lên DevOps có khi lại dễ hơn các bạn DEV.

🔰 Giới thiệu tổng quan các công nghệ/tool trong DevOps

Quả thật hệ sinh thái DevOps vô cùng khổng lồ và liên tục gia tăng đến mức choáng ngợp.
Thế thì học cái gì trong đống này, bản thân mình cũng rất phân vân. Tình cờ mình đọc được 2 bài viết dưới đây và mình nghĩ rất đáng để tham khảo.

🔰 DevOps RoadMap

Tham khảo từ itviec Blog

Mình có đọc 1 bài viết, 1 anh DevOps được phỏng vấn trong bài đó đưa ra các công nghệ/tool cần học.
https://itviec.com/blog/devops-engineer-la-gi/ Phần 3. Kĩ năng mới.

Nguồn: https://itviec.com/blog/devops-engineer-la-gi/

Mình cũng đồng tình phần lớn với các recommend của anh được phỏng vấn trong bài viết trên.

The 2019 DevOps RoadMap của tác giả Kamranahmedse

Vô tình mình đọc được Github của tác giả Kamranahmedse nói về lộ trình hữu ích dành cho các kỹ sư Frontend, kỹ sư Backend cũng như lộ trình dành cho DevOps Engineer.
Lộ trình này không chỉ giải thích vai trò cụ thể của các kỹ sư DevOps, mà còn chỉ định những công cụ nào cần thiết để bao quát các lĩnh vực công việc của các kỹ sư DevOps. Các bạn có thể in ra, dán lên bàn làm việc để flow theo.

Nguồn:https://github.com/kamranahmedse/developer-roadmap

Trên đây mình đã chia sẻ 2 nguồn để các bạn tham khảo lộ trình để trở thành DevOps Engineer, quả thật lắm chông gai và cần nhiều thời gian công sức để học tập.
Lộ trình thì có rồi nhưng cũng nhiều quá phải không, mình đã trãi qua việc học các kiến thức và công cụ dưới đây để join vào team DevOps và làm việc cho đến bây giờ (2,5 năm). Mình sẽ giới thiệu đến các bạn mới để các bạn có thể nhanh chóng tiến lên con đường DevOps và cảm nhận được sự thú vị của nó.

Phần tiếp theo mình sẽ đưa ra 1 practice đơn giản để các bạn mới học và thực hành DevOps.

🔰 Learn and Practice

Đây cũng gần như là chương trình thực tập DevOps công ty mình, cho các bạn sinh viên năm 4,5.
Let's get started!

1. Hãy bắt đầu với GIT
2. Linux (Sử dụng được thành thạo các command cơ bản của linux, thao tác với user, file, ssh, v.v...)
3. Vagrant (Công cụ kết hợp với Virtual Box để tạo máo ảo trên local)
4. Ansible (Công cụ để thực hiện Infrastructure as Code)
5. Docker, Docker Compose (Thời đại container hoá rồi nên phải học cái này :D)
6. Web server (Bên mình thì cho các bạn học Nginx - cài đặt, cấu hình cơ bản, học 1 cái này thì các web server khác như Apache, IIS, v.v... cũng gần gần)
7. Do Exercise 1
8. Học php, Framework Yii2
9. Do Exercise 2 (Phát triển và vận hành hệ thống CI/CD, IaC dựa trên các công cụ đã học, sử dụng php, Yii2 FW)
10. Triển khai cả môi trường Prodcution (Bên mình cung cấp VPS Conoha cloud)

---------------------Chương trình thực tập đến đây-------------------

Các bạn vào chính thức sẽ tiếp tục học

1. Kubernetes
2. Do Exercise 3

Bây giờ mình sẽ nói về "Do Exercise 1". Đây chỉ là bài tập vận dụng đơn giản, hệ thống thật sẽ khác lắm.

1. Sử dụng Vagrant tạo 3 máy ảo CI, WEB, DB. CI có thể ssh đến 2 server kia, CI được cài đặt sẵn Git, Ansible. Vì là môi trường local nên có thể syns source playbook với máy CI.
2. Chạy provision để cài đặt các thứ cần thiết cho cả 3 server như docker, v.v... WEB cần được triển khai 2 container là nginx và php-fpm, có thể thực hiện bằng docker-compose. DB cần triển khai mysql container, tiện nhất là bằng docker-compose.
3. Viết role để có thể copy nginx config đã được chuẩn bị sẵn/khi muốn thay đổi.
4. Chuẩn bị source ứng dụng (ở đây chỉ là 1 file php đơn giản có nội dung kết nối đến mysql, nếu thành công thì trả về message "Connection Successful!" ngược lại thì trả về "Connection Failure!") ở một git repository khác.
5. Viết role để triển khai source này vào container php-fpm.
6. Viết README

Kết quả cần đạt được:
Chỉ vài command có thể chạy được môi trường.

🔰 Tổng kết

Bài viết mình đến đây thôi, phần tiếp theo mình sẽ nói về "Do Exercise 2", "Do Exercise 3", hy vọng các bạn thu được nhiều kiến thức cũng như quan tâm, có hứng thú hơn với DevOps. Comment thật nhiều để giúp mình hoàn thiện hơn về kiến thức, khả năng trình bày cũng như có thêm động lực cho các bài blog sau nhé!

Chào thân ái!