Infra as Code (terraform)

- Giới thiều về Infra as Code (IaC) và những công cụ
- Giới thiệu chuyên sâu về terraform

Transcript

1. Infra as Code (terraform) Thạnh Nguyễn
2. Infra as Code - Nói một cách đơn giản là dùng code hoặc script để tự động cấu hình cơ sở hạ tầng CNTT thay vì làm thủ công - Việc dùng công cụ infra as code sẽ giúp tăng tốc quá trình xây dựng cơ sở hạ tầng CNTT, tránh sai sót do cấu hình thủ công gây ra, quản lý infra bằng version -> dễ dàng revert khi cần - Một số công cụ phổ biến như terraform, ansible, chef, puppet, salt stack, cloudformation, … - Infra as code có 2 loại: - Configuration management tool như ansible, chef, puppet, salt stack, ... - Provisioning tool như terraform, cloudformation, pulumi, ...
3. Terraform - Là một công cụ mã nguồn mở giúp quản lý cơ sở hạ tầng dưới dạng code và giúp tự động hóa việc xây dựng, thay đổi, quản lý phiên bản infa một cách an toàn, hiệu quả và chính xác do có thể dự đoán trước được kết quả thay đổi - Dùng ngôn ngữ HCL (hashicorp configuration language) - Terraform có thể quản lý và hỗ trợ hầu hết các cloud provider hiện nay như: - Amazon web service - Google cloud - Microsoft azure - ... - Đồng thời nó cũng quản lý và hỗ trợ các tools khác do hashicorp hoặc người dùng xây dựng modules như gitlab, keycloak, kubernetes, … - Ref: https://registry.terraform.io/browse/providers
4. Tại sao dùng IaC trên cloud - Khi một lỗi xảy ra ở một resource, chỉ cần xóa resource đó và deploy lại - Khi một thảm họa xảy ra ở một nơi, chỉ cần deploy ở một region khác - Có thể trả về nhanh trạng thái trước đó (rollback hoặc redeploy) - Drift detection - Sandbox environment: muốn test gì đó thì build up infra lên một sandbox-account một cách dễ dàng và destroy nó sau đó
5. IaC pipeline Dùng CI/CD tool như github actions, gitlab CI, AWS codepipeline, ...
6. Build account - Là account với permissions cho tất cả các accounts khác - Account này ở mức độ workflow, department hoặc organization, … - Account này cần cực kỳ bảo mật vì là administrator có thể truy cập đến tất cả account khác - Account này chứa images của OS, services, … mà những account khác tương tác và làm việc với nó
7. Difference stage - Là giai đoạn chúng ta có thể nhìn thấy những gì đang xảy ra. Tool sẽ kiểm tra sự thay đổi giữa current state và expected state - Cloudformation có ChangeSets - Terraform có plan - CDK có diff
8. Approval stage - Dev env: có thể làm việc trực tiếp trên nó như deploy apps, build/provisioning infra, ... - Staging env: cần request đến Devops/SysAdmin team kiểm tra sự thay đổi khi deploy apps, build/provisioning infra, … - Production env: cần sự approval của manager liên quan, để họ biết được sự thay đổi của hệ thống sắp xảy ra, họ sẽ điều phối tổng thể đến các stakeholder khác như phòng ban, tổ chức, … để quyết định thời gian tốt nhất cho sự thay đổi
9. Apply stage - Đây là giai đoạn tạo ra những thay đổi thực tế trên infra - Terraform có apply - Cần giám sát giai đoạn này: - Xem bất kỳ sự gián đoạn nào xảy ra không và trong bao lâu - Mất bao lâu để áp dụng tất cả các thay đổi - Thứ tự apply các thành phần infra (cực kỳ quan trọng) - Staging và Production env cần giống nhau nhất có thể, mỗi một thay đổi trên staging thì cần apply cho production env ngay sau đó
10. Tại sao dùng terraform - Terraform là declarative IaC tool, có nghĩa là mình chỉ viết code diễn tả những gì mình cần, xem thử trạng thái mình mong muốn và trạng thái hiện tại có khác gì không. Mình chỉ cần apply thì terraform sẽ làm các việc còn lại, mục tiêu là infra thay đổi đến trạng thái mình muốn -> code đọc dễ hiểu, đơn giản hóa quá trình cấu hình, tăng khả năng tái sử dụng code - Nâng cao tính chính xác, giảm thời gian thực hiện do thực thi bằng code hoặc script một cách tự động - Tài liệu hóa thông tin cơ sở hạ thành bằng chính code terraform - Khả năng cấu hình, kiểm tra và triển khai hạ tầng trên nhiều cloud provider - Hỗ trợ cộng tác giữa các developers do khả năng tạo module riêng, tạo cơ sở hạ tầng trên một nguồn duy nhất (source code) -> tăng tốc cộng tác với CICD
11. Ví dụ tạo một VPC từ một resource - Trong một vpc gồm có: - CIDR là range ip mà gateway của VPC sẽ cấp phát IP cho các resource cũng như routing đến các resource bên trong VPC - VPC có tạo DNS cho các resource bên trong VPC không ? - VPC có hỗ trợ truy vấn dns không ? - Tags cho resource để gợi nhớ ai tạo, tổ chức tạo, ... - Ref: https://registry.terraform.io/provider s/hashicorp/aws/latest/docs/resource s/vpc
12. Ví dụ tạo một VPC từ một module có sẵn từ local - Tái sử dụng module có sẵn - Chỉ cần truyền vào các biến được định nghĩa (thông thường trong file variables.tf) - Ví dụ này ta phải xác định vị trí của module, VPC nằm ở region, zone nào ?, các thông số network như CIDR của VPC, public network và private network
13. Ví dụ tạo một Kubernetes từ module có sẵn từ registry Ref: https://registry.terraform.io/modules/coreos/kubernetes/aws/latest
14. Cấu trúc thông thường định nghĩa một module
15. Gồm có 3 thành phần chính - main.tf : định nghĩa resource cần triển khai - outputs.tf : định nghĩa các biến cần rút trích từ resource cần triển khai - variables.tf : định nghĩa các biến cần truyền vào resource cần triển khai
16. Kiến trúc terraform
17. Terraform workflow
18. Terraform backends - Locking - Versioning - Encryption at rest - Workspaces (tương tư như env) - Chú ý: backend configuration không hỗ trợ các phép tính nội suy (interpolations)
19. terraform init - Lệnh này sẽ không xóa bất kỳ configuration hoặc state nào - Kiểm tra plugins (provisioners/providers) có đúng với khai báo trong code chưa, nếu thiếu thì cài thêm, nếu dư thì xóa - Tạo ra thư mục .terraform chứa các thông tin về providers - Load backend config (chứa thông tin lưu trữ file terraform state ví dụ như S3) nếu có, mặc định là local
20. terraform plan + terraform apply - Chạy plugins: provisioners / providers - Xây dựng đồ thị resources thể hiện sự phụ thuộc cha con giữa resources và modules từ đó khám phá sự thay đổi để chuyển từ trạng thái hiện tại đến trạng thái mong muốn - Kiểm tra cú pháp providers: resource validation - Nếu backend == nil thì mặc định dùng local - Nếu -out = plan.out thì lưu thành file không mã hóa chứa thông tin thay đổi infra - Terraform tính toán sự khác nhau giữa trạng thái mong muốn (desired state) và trạng thái hiện tại (current state) của infra - Hiển thị ra ở dạng stdin hoặc lưu thành file - Có thể tự động apply với -auto-approve flag hoặc tự gõ thủ công yes trong prompt apply
21. terraform destroy - “Measure twice, cut once” -> cực kỳ cẩn thận khi dùng lệnh này - Có thể dùng flag -target để xác định resources, modules cần xóa - Tránh chạy trên production, thay vì đó hãy comment code rồi apply - Nếu muốn không quản lý resources/modules nào đó bằng code thì có thể dùng `terraform state rm modules/resources` để xóa trạng thái infra ra khỏi file state
22. Các câu lệnh thường dùng khác terraform import: import một resource đã tồn tại vào file tate, nhằm quản lý resource đó bằng code terraform state: quản lý state của các resource terraform fmt: format code terraform workspace: quản lý workspace <-> quản lý môi trường deployment (dev, staging, prod) ...
23. Best practise https://github.com/ozbillwang/terraform-best-practices https://stroobants.dev/make-your-infrastructure-immutable.html
24. Một số trường hợp thực hành 1. Tạo thêm một VPC chứa RDS + EC2 2. Tăng cường một module như thêm một tính năng encrypt trong RDS 3. Cách ignore changes một số services do thay đổi trên console nhiều 4. Cách output một số thông tin