Giới thiệu về công cụ IaC Terraform

ToiVietBlog - Trong bài viết này, mình sẽ giới thiệu với các bạn công cụ IaC Terraform. Vậy Terraform là gì? Và tại sao lại cần dùng đến công cụ này? Khoan hãy nói đến việc làm sao để sử dụng Terraform đã bạn nhé. Những điều đó, mình sẽ trình bày trong các bài viết tiếp theo.

Terraform là gì?

Terraform là một công cụ mã nguồn mở được tạo ra bởi HashiCorp. Nó cho phép bạn: định nghĩa, triển khai (deploy) và quản lý hạ tầng của bạn thông qua các dòng code (IaC).

Terraform có thể làm việc với các hạ tầng public cloud như AWS, GCP, Azure, Digital Ocean,… Nó cũng có thể làm việc với các hạ tầng private cloud như OpenStack, VMWare.

Điều này cho phép bạn có thể linh hoạt sử dụng Terraform để quản lý hạ tầng nằm trên các nền tảng hạ tầng khác nhau, mà ta gọi là hybrid infrastructure.

Tại sao Terraform lại ra đời?

Đây là một câu chuyện dài nhưng mình có thể tóm gọn nó qua một số mục nhỏ như sau.

Sysadmin thủ công

Trước đây, các system administrator (Sysadmin) phải cài đặt hạ tầng rất thủ công. Họ phải cài đặt từng server, cài đặt từng database, cài đặt từng thiết bị network,… Và tất cả mọi thứ đều làm thủ công. Điều đó mang lại rủi ro rất lớn như: sai sót khi thực hiện, sai khác giữa các lần cài đặt, không đồng bộ giữa các môi trường,…

Sysadmin script

Qua một thời gian, các Sysadmin đã tiến thêm một bước là sử dụng các script. Mục đích để tự động hóa một phần quá trình cài đặt hạ tầng CNTT. Việc sử dụng script như Bash script, Shell script, Python script,.. giúp việc sai sót cũng ít hơn. Tuy nhiên thì nó vẫn còn nhược điểm:

• Dù sử dụng script, Sysadmin vẫn phải vào từng server, từng thiết bị để chạy script. Việc này sẽ trở nên rất mất thời gian nếu số lượng thiết bị rất lớn, hàng ngàn thiết bị, server.
• Khó quản lý phiên bản. Nếu bạn đã sử dụng script thì bạn biết việc quản lý phiên bản script cũng không dễ dàng. Các Sysadmin có thể đặt tên script như kiểu install_v1.sh, install_v2.sh,… Tuy nhiên điều đó vẫn có thể gây sai lầm khi sử dụng sai script.
• Khó sử dụng cho một team, đặc biệt là team đông người. Bởi vì lý do khó quản lý phiên bản script cộng thêm nhiều người cùng sử dụng trong team. Sai lầm là điều hoàn toàn có thể xảy ra.

Sysadmin trở thành DevOps

Văn hóa DevOps ra đời. Lúc này công việc, môi trường đòi hỏi các Sysadmin phải tự động hóa tối đa mọi thứ. Để làm việc này thì sử dụng script là không đủ.

Các công việc triển khai hạ tầng, xóa bỏ hạ tầng development diễn ra liên tục trong môi trường phát triển sản phẩm. Tự động hóa hạ tầng kết hợp với quá trình CI/CD phát triển sản phẩm. Quy chung thành 3 yêu cầu cơ bản:

• Tự động mọi thứ
• Nhanh, ít sai sót
• Thực hiện liên tục

Đến đây thì HashiCorp đã cho ra đời Terraform. Một công cụ viết bằng ngôn ngữ HCL (HashiCorp Configuration Language). Nó cho phép các Sysadmin/devops thực hiện yêu cầu công việc ở trên. Vậy là cuộc sống trở nên dễ thở hơn dù phải hối hả hơn.

Ở phần trên bạn đọc thấy một cụm từ là IaC. Vậy thì nó là gì?

IaC – Infrastructure as Code. Đây chính là thuật ngữ dùng để mô tả các công cụ tương tự như Terraform. Những công cụ cho phép bạn khai báo, triển khai, quản lý hạ tầng CNTT bằng những dòng code và lệnh. Đến đây thì bạn cũng hình dung ra rằng kỹ sư DevOps sẽ phải học một chút về lập trình đúng không.

Tuy nhiên thì lập trình của kỹ sư DevOps sẽ có chút khác biệt với các Developer thông thường. Cái mà DevOps hướng đến đó là lập trình tự động hệ thống/hạ tầng. Không phải là lập trình để viết ứng dụng, viết web,…

Ý tưởng sử dụng Terraform như thế nào trong công việc?

Nói cả buổi thì ít ra cũng phải có một ý tưởng về việc sử dụng công cụ này như thế nào chứ nhỉ. Dĩ nhiên, bài này chưa đi chi tiết vào việc sử dụng Terraform. Nhưng ta hãy nêu lên cái ý tưởng xem có ổn không.

Môi trường làm việc

Để nói việc sử dụng nó như thế nào, trước hết ta cần xem nó trong môi trường nào. Các công cụ DevOps nói chung và Terraform nói riêng hiện tại không thích hợp cho doanh nghiệp, tổ chức thông thường.

Nó chỉ thích hợp với các doanh nghiệp chuyên về CNTT, các doanh nghiệp lớn – vừa đã có hạ tầng CNTT tương đối hoàn chỉnh.

Nơi mà có đầy đủ các team: Developer, Tester, Sysadmin, DevOps,… Khi môi trường có tương đối đủ các team phát triển và vận hành sản phẩm CNTT thì khi đó văn hóa DevOps mới có thể áp dụng. Mà cụ thể hơn là khi đó các công cụ DevOps mới có thể sử dụng được.

Bạn sẽ không thể nào bước vào một công ty sản xuất tranh vẽ với quy mô 20 người. Chỉ có một IT Support và bảo muốn áp dụng DevOps, điều đó là không thể.

Yêu cầu công việc

• Sếp: muốn sản phẩm được tung ra thị trường nhanh chóng, ổn định. Nói chung là “ngon.
• Developer: muốn build các app thật nhanh mà không cần dụng tay chân gì cả. DevOps “lo hết”.
• Sysadmin/DevOps: phải tự động hóa tối đa mọi thứ. Chứ một ngày Developer nó build app 10 lần mà vào build thủ công 10 lần có mà oải.

Quy mô team

• Team DevOps có khoảng 3-5 người. Công ty lớn có thể team đông hơn rất nhiều.
• Làm sao để mọi người sử dụng chung resource của nhau? Kiến trúc hạ tầng do anh Lead thiết kế thì làm sao bạn Member fresher có thể triển khai được?
• Lỡ mà anh Lead nghỉ việc sang công ty khác, làm sao cả team nắm được những gì anh ấy đã làm với hạ tầng?
• Ví dụ hạ tầng triển khai tháng 1, bẵng đi tháng 8 có yêu cầu triển khai tiếp thì phải làm sao. Lúc đấy lục tại tài liệu triển khai cũ hay là đập đi làm lại từ đầu?
• v.v…

Cách vận hành team

Từ yêu cầu công việc cho đến yêu cầu của team DevOps thì bạn cũng có thể nhận ra sẽ có rất nhiều vấn đề xảy ra trong một team.

Thế thì tạm cái ý tưởng để vận hành team DevOps như sau, đây là lúc mà bạn sẽ thấy Terraform xuất hiện.

Phần 1: Anh Lead cân tất cả

1. Team Developer yêu cầu một môi trường dev và một môi trường production. Giống hệt nhau về kiến trúc hạ tầng, chỉ khác nhau về kích thước.
2. Anh Lead team DevOps sau khi nhận yêu cầu xong ok. Anh ấy tạo một repository trên Github để lưu code Terraform mà anh ấy sẽ viết.
3. Tiếp theo anh Lead add cả team DevOps vào repository này.
4. Sau đó, anh Lead bắt đầu dùng Terraform để viết code triển khai môi trường như yêu cầu. Vì 2 môi trường có kiến trúc y hệ nhau nên việc khá là khỏe. Anh viết code cho môi trường dev đẩy lên nhánh dev. Sau đó anh copy code, thay đổi thông số size một chút và đẩy code lên nhánh master.
5. Vậy là lúc này, anh Lead đã có thể git clone code từ repository về và apply. Sau 1 phút 30 giây, 2 môi trường đã sẵn sàng.

Phần 2: Cả team DevOps cùng làm việc

1. Tuy nhiên, anh Lead không thể cứ làm thế mãi được. Anh cũng phải giao lại việc này cho các member khác làm. Mà mỗi lần apply Terraform lại phải clone về rồi gõ lệnh apply, có vẻ mất công.
2. Thế là anh Lead sử dụng tool CI Jenkins để tự động apply Terraform mỗi khi có sửa đổi code. Lúc này khỏe hơn rồi, team DevOps chỉ việc viết code Terraform dưới máy. Push code mới lên repository và Jenkins làm mọi thứ còn lại. Xong.
3. Đến đây thì việc của anh Lead khỏe hơn một chút. Các member sẽ viết code Terraform và push lên repository. Anh Lead chỉ việc review code thay đổi và merge vào repository nếu ổn. Mọi thứ tự động sau đó và xong.
4. Nửa năm sau team Developer có yêu cầu thay đổi môi trường một chút. Đơn giản, member sẽ thay đổi code Terraform một chút và xong. Mọi thứ lại như bước số 8 ở trên.

Đến đây bạn có thể thấy rằng:

1. Team DevOps hoạt động gần như tự động hóa việc triển khai hạ tầng CNTT.
2. Cả team đều có thể sử dụng chung nguồn resouce Terraform.
3. Có tính kế thừa trong team. Dù anh Lead có nghỉ thì team vẫn có thể dựa vào code Terraform đó để tự động triển khai hạ tầng lại. Không sợ bị sai sót hay thiếu hụt thành phần nào trong hệ thống.

Ý tưởng là vậy. Hy vọng bạn thấy mình viết ra không quá dài nha.

Kết luận

Thông qua bài viết này, mình đã giới thiệu cơ bản với các bạn Terraform là gì và nó sử dụng vào mục đích gì. Ngành CNTT đã bước vào thời kỳ tự động hóa cao, đòi hỏi các kỹ sư Sysadmin hay DevOps phải tự động hóa công việc theo. Trong các bài viết tiếp theo, mình sẽ nói cụ thể hơn về việc sử dụng Terraform như thế nào.

Chia sẻ Facebook

Tweet

Theo dõi blog