Chào mọi người, mình là Quang hiện tại đang là một DevOps Engineer. Mình xuất phát điểm là .Net Developer, con đường mình trở thành một DevOps Engineer khá là lòng vòng và gặp những cái mình hay gọi là dại dột đầu đời 😅. Mình viết series này để chia sẽ chút kinh nghiệm, kiến thức (dù biết bản thân không nhiều) và những vấn đề khi từ một Developer trở thành DevOps Engineer. Thôi không dài dòng nữa chúng ta cùng bắt đầu nhé.
1. Bước chân đầu tiên – DevOps là gì?
Trước mắt chúng ta phải hiểu DevOps không phải một công cụ, nó là một văn hóa làm việc đề cao sự hợp tác, kết hợp của hai giai đoạn phát triển (development) và vận hành (operations). 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.
Từ góc độ DevOps, Phát triển, Kiểm thử và Triển khai đều liên quan tới DevOps.
Cuối cùng, Tự động hoá việc triển khai hệ thống để các công việc đạt hiệu quả cao nhất.
2. Trách nhiệm của một DevOps Engineer
Để hiểu rõ về DevOps và các nhiệm vụ mà một kỹ sư DevOps cần thực hiện, chúng ta cần hiểu về các công cụ, quy trình, tổng quan về chúng và cách chúng kết hợp với nhau.
Các Developer tạo ra các ứng dụng bằng nhiều công nghệ khác nhau. Để phát triển ứng dụng, developer cũng có thể sử dụng nhiều ngôn ngữ lập trình, công cụ xây dựng (build tools), kho mã (code repositories), v.v.
Là một DevOps Engineer, bạn không lập trình các ứng dụng nhưng việc hiểu rõ về cách làm việc của một developer cũng như các hệ thống, công cụ và quy trình mà họ sử dụng là điều thật sự cần thiết.
Bạn cần biết ứng dụng được cấu hình như thế nào để tương tác với tất các các dịch vụ hoặc dữ liệu cũng như đưa ra yêu cầu về cách mà chúng ta có thể và nên kiểm tra điều đó.
Ứng dụng cần được triển khai ở đâu đó, để cho đơn giản thì chúng ta sẽ coi đó là một máy chủ. Sau đó, người dùng cuối hoặc khách hàng sẽ truy cập tới ứng dụng thông qua máy chủ được triển khai.
Máy chủ này sẽ chạy ở đâu đó, có thể là on-premise, public cloud hoặc serverless (cái này vẫn trending lắm, mình sẽ nói về nó một ngày không xa). Ai đó cần triển khai, cài đặt cấu hình các máy chủ này và chuẩn bị để chúng có thể chạy ứng dụng đã được phát triển. Công việc này có thể sẽ là nhiệm vụ của một DevOps Engineer.
Các máy chủ chạy một hệ điều hành và để đơn giản thì chúng ta sẽ chọn Linux (hoặc là Windows Server)
Chúng ta cũng nên có kiến thức về mạng và cấu hình mạng vì có thể các máy chủ cần giao tiếp với nhau hoặc với các thành phần khác trong mạng và môi trường của nó. Đôi khi đây cũng sẽ là trách nhiệm của một kỹ sư DevOps. Chúng ta sẽ đi vào chi tiết trong các phần riêng về DNS, DHCP, cân bằng tải, v.v…
3. Vòng đời DevOps
Continuous Development:
Giai đoạn này đóng vai trò then chốt trong việc vạch ra tầm nhìn cho toàn bộ chu trình phát triển phần mềm. Nó chủ yếu tập trung vào lập kế hoạch và mã hóa dự án. Trong giai đoạn này, các yêu cầu của dự án được thu thập và thảo luận với các bên liên quan. Hơn nữa, sản phẩm tồn đọng cũng được duy trì dựa trên phản hồi của khách hàng được chia thành các bản phát hành nhỏ hơn và các cột mốc để phát triển phần mềm liên tục.
Là một DevOps Engineer, bạn có có thể không phải là người lên kế hoạch cũng như lập trình ứng dụng cho người dùng cuối. Tuy nhiên, sẽ rất tuyệt vời nếu bạn có thể đọc được một số đoạn mã và hiểu được các yêu cầu của ứng dụng, từ đó đưa ra các quyết định tốt nhất cho cơ sở hạ tầng cho hệ thống mới.
Ứng dụng này có thể được viết bằng bất cứ ngôn ngữ nào, nhưng điều quan trọng là mã ứng dụng nên được quản lý bởi một hệ thống kiểm soát phiên bản (version control system) như: GitLab, GIT, TFS, SVN, Mercurial, Jira, BitBucket, Confluence và Subversion
Continuous Integration
Có thể giải thích chủ yếu theo 4 giai đoạn trong DevOps. Chúng như sau:
- Lấy Source Code từ Repository
- Building code
- Đánh giá Source Code (chạy test)
- Lưu trữ lại các file build artifacts
Các công cụ được sử dụng: Jenkin, Bamboo, GitLab CI, Buddy, TeamCity, Travis và CircleCI là một số công cụ DevOps được sử dụng để làm cho quy trình làm việc của dự án trở nên trơn tru và năng suất hơn. Ví dụ, Jenkin (công cụ mã nguồn mở) được sử dụng rộng rãi để tự động hóa các bản dựng và thử nghiệm. Mặt khác, CircleCI và Buddy là những công cụ thương mại.
Continuous Delivery và Continuous Deployment
- 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.
Nhìn nhận tổng quan thì CI/CD pipeline thường gồm các bước sau:
- Commit. Khi một developer hoàn thành một thay đổi thì người đấy sẽ commit thay đổi đó vào một source code repository.
- Build. Khi có thay đổi trên branch của một repository, ta sẽ thiết lập các lệnh build tương ứng với từng ngôn ngữ. Các lệnh này sẽ được chạy trên một con hoặc nhiều runner.
- Automated tests. Đây là phần quan trọng của CI/CD pipeline. Các commit mới sẽ được chạy test tự động để đảm bảo nó sẽ hoạt động với các bản build mới và sẽ không gây ảnh hưởng đến toàn bộ hệ thống.
- Deploy. Phiên bản đã được build sẽ được đưa lên các stage như dev/stg/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 đội tester, khách hàng của dự án, người dùng cuối.
- 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.
Continuous Testing
Ở quá trình này, chúng ta đã có các yêu cầu và đang phát triển ứng dụng. Vấn đề tiếp theo là chúng ta cần đảm bảo rằng mã ứng dụng cần được kiểm thử ở các môi trường khác nhau mà chúng ta có hoặc cụ thể hơn là với ngôn ngữ lập trình chúng ta đã chọn.
Quá trình này cho phép nhóm quản lý chất lượng (QA) kiểm tra lỗi, chúng ta thường sử dụng các containers để mô phỏng môi trường kiểm thử để có thể giảm thiểu chi phí cho các máy chủ vật lý hoặc cơ sở hạ tầng trên cloud.
Continuous Monitoring
Chúng ta đã triển khai ứng dụng mới và liên tục cập nhật những tính năng mới và luôn kiểm thử trước mỗi lần phát hành để đảm bảo không có bug nào trong ứng dụng. Ứng dụng cũng đang chạy trong môi trường mà cấu hình cũng như hiệu năng ổn định theo đúng yêu cầu.
Nhưng bây giờ chúng ta phải đảm bảo rằng người dùng cuối có được trải nghiệm theo đúng những gì họ mong đợi. Trong quá trình này, chúng ta cần phải đảm bảo rằng hiệu suất của ứng dụng được theo dõi liên tục. Việc này cũng giúp nhóm developer có thể đưa ra quyết định tốt hơn để cải tiến ứng dụng, hoặc vá lại các bug đấy nhanh chóng trong các bản phát hành tiếp theo nhằm đem lại trải nghiệm tốt hơn cho người dùng cuối. Các vấn đề bảo mật có thể được phát hiện và giải quyết tự động trong giai đoạn này.
Các công cụ được sử dụng: Kibana, Prometheus, Grafana, …
Continuous Feedback
Sau khi ứng dụng được phát hành ra thị trường, người dùng cuối sẽ sử dụng ứng dụng và họ sẽ cung cấp cho chúng tôi phản hồi về hiệu suất của ứng dụng cũng như bất kỳ trục trặc nào ảnh hưởng đến trải nghiệm người dùng, sau khi nhận được nhiều phản hồi từ người dùng cuối, nhóm DevOps sẽ phân tích các phản hồi đó và họ sẽ liên hệ với nhóm developer để cố gắng khắc phục những lỗi họ mắc phải trong đoạn mã đó bằng cách này. Phản hồi liên tục có thể tăng hiệu suất của ứng dụng và giảm lỗi trong code, giúp người dùng cuối sử dụng ứng dụng một cách suôn sẻ.
Continuous Operations
Giai đoạn cuối cùng trong vòng đời DevOps là rất quan trọng để giảm thời gian ngừng hoạt động theo kế hoạch, chẳng hạn như bảo trì theo lịch trình. Các nhà phát triển được yêu cầu đưa máy chủ ngoại tuyến để thực hiện cập nhật, điều này làm tăng thời gian ngừng hoạt động và thậm chí có thể gây thiệt hại đáng kể cho công ty.
Các công cụ được sử dụng: Kubernetes và Docker Swarm là các công cụ điều phối vùng chứa được sử dụng cho tính khả dụng cao của ứng dụng và để triển khai nhanh hơn.
4. Như vậy thì chúng ta cần phải làm gì để trở thành một DevOps Engineer?
Theo ý kiến cá nhân mình:
- Đi lên từ một developer chắc chắn bạn phải có tư duy và bộ kỹ năng của developer.
- Nắm vững các kiến thức về hệ điều hành đặc biệc là Linux, shell script.
- Khả năng research tốt.
- Tỉ mỉ và cẩn thận là đức tính cần có ở một DevOps Engineer, việc sai xót trong quá trình triển khái sẽ gây thiệt hại rất lớn về chi phí (dù sao cẩn thận mà chập một chút vẫn hơn).
- Có kiến thức về system và IT operation.
- Có khả năng vận dụng các công cụ từ open source.
- Nắm vững CI/CD
- Có kiến thức về Cloud: AWS, GCP, Azure.
Đây chỉ là bài giới thiệu sơ qua về DevOps, mình hy vọng qua Series này sẽ giúp mọi có cái nhìn tổng quát và biết thêm những kiến thức tổng quan hơn. Đừng ngại chia sẽ thêm ý kiến của mọi người qua phần bình luận ở dưới. Hẹn gặp lại mọi người ở bài sau!
Nguồn tham khảo:
https://dev.to/michaelcade1/90daysofdevops-day-1-kn8
https://www.geeksforgeeks.org/lifecycle-of-devops/