TÓM TẮT
Ở phần 1, tôi có nhắc về công việc của Devops Engineering được xây dựng hoàn toàn tự động hóa, digital pipelines chuyển code từ máy của một developer đến production.
Để làm công việc này một cách hiệu quả đòi hỏi một sự hiểu biết có cơ sở về nguyên tắc cơ bản, được mô tả như sau:
Cũng như là sự hiểu biết tốt về công cụ và kỹ năng (hình minh họa kế ở dưới) rằng dựa vào nguyên tắc cơ bản này.
Note: mục tiêu của bạn là để học những điều màu xanh trước, từ trái qua phải, rồi sau đó học những điều màu tím, từ trái qua phải. Có tổng cộng có 6 cột, mỗi cột một tháng.
Xong, trở lại chủ đề. Trong bài viết này, chúng ta sẽ hoàn toàn nói về giao đoạn đầu của digital pipeline: Configure.
Tổng quan
Trong giai đoạn cấu hình diễn ra cái gì?
Kể từ khi the code chúng ta đang tạo ra cần nhiều máy móc để vận hành, Configure stage thật sự xây dựng cơ sở để vận hành code.
Trong quá khứ, sự cung cấp cở sở hạ tầng rất dài dòng, cần nhiều người làm, dễ bị lỗi. Ngày nay, nhờ sự tuyệt vời của cloud, provisioning có thể xong chỉ với 1 cái click. Hoặc, cùng lắm là nhiều cái click. Bây giờ, hóa ra nhấn click để hoàn thành những task này là một ý tưởng tồi. Tại sao?
- Dễ bị lỗi (con người thường phạm lỗi)
- Not versioned (click không thể lưu được trên git)
- Không thể lặp lại ( nhiều máy móc = nhiều lần click)
- Và không kiếm tra được (không biết nếu những lần click của tôi sẽ thật hiệu quả hoặc là làm mọi thứ rối lên.
Ví dụ, nghĩ về tất cả các công việc cần thiết để cung cấp môi trường dev của bạn rồi staging…rồi prod in US…và prod in EU…Nó trở nên ngán ngẩm, khó chịu, rất nhanh.
Vì vậy, thật sự cần thiết tìm ra giải pháp mới. Cách mới đó là infrastructure-as-code và đó là lí do giai đoạn Configure rất quan trọng.
As a best practice, infrastructure-as-code mandates that whatever work is needed to provision computing resources it must be done via code only.
Chú thích: Bằng cách “computing resources”, tôi nghĩ mọi thứ cần vận hành hợp lý một thiết bị in prod: compute, storge, networking, databases, etc. Sau đó là “infrastrutre-as-code”.
- Viết lên infrastruture stage mong muốn trên Terraform
- Lưu trữ nó trên source code control (ví dụ git)
- Thông qua Pull Request để nhận các feedback
- Kiểm tra
- Thực hiện cung cấp tất cả các resources cần thiết
Tại sao là Terraform mà không phải các khác?
Bây giờ, có một câu hỏi rõ ràng là “tại sao là Teraform? Mà không phải là Chef hoặc là Puppet hoặc Ansible hoạc là CFEEngine hoạc Salt hoặc là Cloudformation hoặc bất kì cái nào khác?”
Đó là câu hỏi hay! Đã có nhiều bài viết đã nói về vấn đề này
Nói tóm lại, Tôi nghĩ bạn nên học Terraform bởi vì
1. Nó đang là xu hướng, có nhiều tiềm năng trong công việc
2. Nó dễ học hơn những trang khác
3. Đa tiềm năng
Hiện tại, bạn hoàn toàn có thể chọn một cái khác tương tự và vẫn thành công.
Chú thích: khoảng trống này được rút ra và khá là rối. Tôi muốn dành ra vài phút để nói về sự việc gần đây và là nơi tôi hiểu vài thứ đang tiến triển.
Theo truyền thống, Terraform và CloudFormation đã từng được được sử dụng làm nguồn cung cấp cơ sở hạ tầng, trong khi đó Ansible được sử dụng để cấu hình nó (configure)
Bạn có thể nghĩ về Terraform như là một công cụ để làm nền, Ansible thì đặt ngôi nhà ở phía trên và rồi the application trở nên hiệu quả hơn, tuy nhiên bạn mong muốn rằng (Ansible cũng có thể làm được như thế)
Nói cách khác, bạn tạo nên VMs với Terraform và rồi sử dụng Ansible để cấu hình các máy chủ, cũng như là hiệu quả đầy tiềm năng cho applications của bạn.
Đó là tại sao những thứ này thường được đi chung với nhau.
Tuy nhiên, Ansible có thể làm nhiều thứ nhưng nếu Ansible không làm được thì Terraform có thể làm. Điều trái ngược thì hầu hết cũng là đúng.
Đừng vì thế mà bạn khó chịu. Chỉ hiểu là Terraform là một trong những thứ có ưu thế trong không gian infrastructure-as-code, vì vậy tôi nhấn mạnh sử dụng nó khi bạn bắt đầu.
Sự thật là, ngay bây giờ chuyên môn về Terraform + AWS là một trong kỹ năng hot nhất được yêu cầu.
Immutable Deployments
Thật ra, tôi tiên đoán rằng configuration management công cụ như là Ansible sẽ giảm đi tầm quan trọng, trong khi đó infrastructure provisioning công cụ như Terraform hoặc Cloudformation sẽ tăng tầm quan trọng.
Tại sao?
Bởi vì một thứ gì đó được gọi là “immutable deployments”
Nói một cách đơn giản nhất, immutable deployments liên quan đến thực tế là không bao giờ thay thế deployed infrastructure. Nói cách khác, mỗi đơn vị deployment là VM hoặc là Docker container, không phải là 1 phần code.
Vì vậy, bạn đừng triển khai code cho một static virtual machines,
bạn triển khai toàn bộ VMs bằng the code đã sẫn sàng baked in.
Bạn không thay đổi VMs configured, bạn deploy VMs mới với cấu hình mong muốn.
Bạn không nối patch prod machines, bạn deploy new machines, với các patched đã có sẵn.
Bạn đừng chạy một bộ VM trong dev và một bộ VM khác trong prod, chúng đều giống nhau.
Trên thực tế, bạn có thể vô hiệu hóa một cách an toàn tất cả quyền truy cập SSH vào tất cả các máy prod vì không có gì để làm ở đó – không có cài đặt nào để thay đổi, không có logs để xem (về log chúng ta sẽ để cập về sau).
Bạn hiểu ý tôi chứ?
Khi được sử dụng một cách chính xác, đây là một mô hình rất mạnh mẽ và tôi rất khuyến khích!
Note: Immutabe deployments mandadte rằng cấu hình sẽ bị tách bởi code của bạn. Vui lòng đọc 12 Factor App rất là chi tiết ngoài ra còn có nhiều ý tưởng tuyêt vời khác. 12 Factor App là rất là đáng đọc cho người thực hành DevOps.
Việc tách code từ cấu hình là cực kỳ quan trọng – chắc chắn bạn không muốn deploy lại toàn application stack mỗi khi bạn thay đổi mật khẩu DB của mình. Thay vào đó, hãy đảm bảo các ứng dụng lấy nó từ một cửa hàng cấu hình bên ngoài (SSM / Consul / v.v.)
Hơn nữa, bạn có thể dễ dàng nhận thấy những điều có được từ sự phát triển immutable deployments, công cụ như Ansible bắt đầu đóng vai trò ít nổi bật hơn.
Lý do là, bạn chỉ cần cấu hình một máy chủ và triển khai toàn bộ số lần như một phần của auto-scaling group.
Hoặc là, nếu bạn đang làm containers, bạn tất nhiên hầu hết muốn immutable deployments bằng định nghĩa. Bạn không muốn dev container khác với QA Contanier và prod.
Bạn muốn cùng một container chính xác trên tất cả các môi trường của bạn. Điều này tránh sự cố khi cấu hình và đơn giản hóa việc roll-backs trong trường hợp có vấn đề.
Bỏ qua một bên, đối với những người mới bắt đầu, việc cung cấp AWS infrastructure bằng cách sử dụng Terraform là sách giáo khoa cho DevOps và là thứ bạn thực sự cần phải thành thạo.
Nhưng chờ đã…Liệu bạn nhìn vào logs để khắc phục cố một vấn đề? Chà, bạn sẽ không truy cập vào máy để nhìn vào logs nữa, thay vào đó bạn sẽ nhìn vào cơ sở hạ tầng centrailized cho tất cả logs của bạn.
Trên thực tế, đã có nhiều bài viết chi tiết về cách deploy ELK stack trong AWS – hãy đọc nếu bạn muốn xem nó thực hiện như thế nào trong thực tế
Một lần nữa, bạn có thể vô hiệu hóa truy cập từ xa hoàn toàn và cảm thấy tốt về việc an toàn hơn hầu hết mọi người ngoài kia!
Tổng kết
Con đường trở thành DevOps bắt đầu với nguồn cung cấp tài nguyên cần thiết để run code – giai đoạn cấu hình. Và cách tốt nhất để thực hiện điều đó là thông qua immutable deployments.
Cuối cùng, nếu bạn tò mò nên bắt đầu từ đâu, Terraform + AWS là một combo để bắt đầu hành trình.
Trong bài cũng có một số Tool thật ngữ bạn cũng nên tìm hiểu, hoặc tìm hiểu sâu hơn nhé:
- Immutable Deployments
- 12 Factor App
- Terraform
- Config store (SSM/Consul)
- Deploy an ELK stack in AWS
Phần này có nhiều thứ khó hiểu và cũng nhiều lí thuyết mà chưa có ví dụ cụ thể, những phần tiếp theo tôi sẽ xen kẽ với nhưng phần thực hành để có thể dễ hiểu hơn, có lẽ tôi sẽ lấy ví dụ là mình sẽ deploy một WordPress blog lên AWS với Terraform và Ansible để làm demo, mong các bạn sẽ ủng hộ tôi.
Bài viết được tham khảo từ : https://medium.com/@devfire/how-to-become-a-devops-engineer-in-six-months-or-less-part-2-configure-a2dfc11f6f7d