Bài viết tập trung vào các ví dụ và mô tả về các vấn đề liên quan đến sự ra đời của IaC, đồng thời tránh không đề cập quá sâu đến kĩ thuật và kiến thức chuyên sâu về hạ tầng nên phù hợp với đa số mọi người có kiến thức cơ bản về quy trình sản xuất phần mềm
Các ví dụ trong bài được viết dưới dạng pseudo code (mã giả) như vậy sẽ đảm bảo sự chính xác tương đối với thời gian khi các công cụ thay đổi, nên những ví dụ này không có tác dụng để chạy thử một cách chính xác
Mở đầu
Infrastructure as Code là một chủ đề được bàn luận khá sôi nổi trong những năm gần đây, đặc biệt khi Cloud ngày càng được sử dụng rộng rãi.
Vậy là một người quan tâm công nghệ bạn có nên biết về nó hay không? Có, ít nhất là bạn cũng có thể biết đủ để hiểu những gì mọi người đang nói (ít nhất thì nó cũng là hot trend)
Để hiểu rõ hơn vấn đề, hãy cùng nhìn lại một chút về lịch sử
The Iron Age (Kỉ nguyên sắt)
Có một giai đoạn khi mà thời gian để deploy một server có thể tốn vài ngày thậm chí vài tuần và phải trải qua hàng loạt công đoạn như
review yêu cầu
chờ phần cứng được mua về
thiết lập phần cứng để tương thích với hệ thống đang có
và cuối cùng là cấu hình VM cũng như cài các phần mềm cần thiết
những công đoạn như vậy thường đòi hỏi nhiều người tham gia vì thế phát sinh những chi phí (cost) liên quan tới thời gian, nhân sự, phần cứng, và phần cứng thì thường phải mua dư hơn mức cần thiết nhiều vì sẽ khó để có thể thay đổi
Ngoài những bất cập về chi phí, một hệ thống như vậy cũng khó đảm bảo về
khả năng mở rộng (scalability), vì tốn quá nhiều chi phí cho việc thiết lập và vận hành nên việc mở rộng thêm nhiều server sẽ rất hạn chế và đòi hỏi việc lên kế hoạch cũng như tính toán kĩ lưỡng
độ ổn định của hệ thống (availability) vì những server vật lí nằm cạnh nhau trong 1 khuôn viên, khi có những sự cố xảy ra với cụm server đang chạy khó mà có thể dựng lại một cụm server mới tương tự trong thời gian ngắn
tính nhất quán (consistency), khi tất cả các cấu hình và thiết lập server cũng như software được làm thủ công thì sẽ khó đảm bảo được rằng việc cấu hình những cụm server cùng chức năng với nhau được sao chép hoàn chỉnh cũng như dễ có sai sót khi thực hiện update (ví dụ security patch) cho một cụm server
Giai đoạn này được gọi là The Iron Age, và rất nhiều người sẽ mừng rỡ khi những năm tháng đen tối này qua đi và chào đón một thời đại mới
The Age of Cloud Computing (Thời đại của điện toán đám mây)
Ở thời đại mới, việc dựng lên 1 server chỉ tốn vài phút với vài cú click chuột. Điều này mở ra những lợi ích to lớn
giảm hẳn chi phí về thời gian, nhân sự (vì đa số công đoạn đã được quản lí tự động bởi Cloud) và cả phần cứng (chỉ cần dựng VM với resource đủ dùng sau đó có thể mở rộng thêm tùy ý)
nâng cao đáng kể việc mở rộng hệ thống vì cần ít người thao tác và quản lí hơn cũng như thời gian setup nhanh hơn
độ ổn định của hệ thống được tăng lên không tưởng khi Cloud Provider thậm chí còn đảm bảo chỉ số SLA > 99.99% và server có thể được backup 1 cách định kì ở nhiều vùng khác nhau
Những điều này càng làm bùng nổ hơn sự phát triển và mở rộng về quy mô của hệ thống Nếu như trước đây những cụm server vật lý với application vận hành theo mô hình Monolithic thường chỉ có khoảng vài chục server cỡ lớn (tham khảo Link để hiểu về khải niệm monolithic và microservice)
Thì với nền tảng của cloud có thể cho phép mô hình Microservices với hàng trăm, hàng ngàn application nhỏ nằm rải rác trong nhiều cụm server lớn mà con số VM của mỗi cụm cũng có thể lên đến hàng trăm, hàng ngàn
Vậy làm thế nào để thiết lập và quản lí một cơ sở hạ tầng lớn như vậy? Chỉ dựa vào UI của Cloud để config thủ công sẽ tốn rất nhiều công sức và khó mà vận hành tốt
Lấy ví dụ 1 số tình huống
1. Di chuyển Cloud
Cơ sở hạ tầng của công ty bạn đang được đặt trên một Cloud provider nội địa. Sau này business phát triển mạnh hơn và cần scale hệ thống lớn hơn nữa nhưng cloud provider nội địa thiếu những công cụ cần thiết để đáp ứng.
Vì vậy quyết định di dời sang một cloud provider quốc tế với khả năng hỗ trợ và những công cụ mạnh mẽ hơn được đưa ra và bạn là người nắm trọng trách.
Rất nhanh chóng bạn nhận ra những điều không ổn
cơ sở hạ tầng đã được dựng từ rất lâu, document đã lâu không được update, những người ban đầu dựng nên hệ thống đã không còn
infrastructure và server được setup thủ công, script thì nơi có nơi không và commit gần nhất là cách đây hơn 1 năm khi mà bạn còn chưa vào công ty và không có gì đảm bảo script chạy đúng với trạng thái của server hiện tại
2. Thay đổi hàng loạt config
Một tình huống khác nhẹ nhàng hơn
Hệ thống có một lọat những VM giống nhau được thiết lập để chạy môi trường của web application được viết bởi cùng 1 ngôn ngữ.
Mỗi khi cần 1 VM mới cho 1 application mới, đơn giản bạn chỉ cần clone 1 VM tương tự cái đang có, hoặc sử dụng image template chuẩn được tạo sẵn và cài đặt application mới lên.
Vấn đề xảy ra khi web application ngày càng có nhiều traffic hơn và performance bắt đầu giảm, bạn tăng resource của VM (cpu, ram) nhưng chưa đủ, bạn phải tinh chỉnh application và một số config của hệ thống để tối ưu việc tận dụng memory.
Bạn test trên 1 VM và thấy mọi việc đã ổn thỏa, bạn tạo 1 base image mới cho những VM sau này để có config tối ưu tương tự.
Tuy nhiên bạn nhận ra là bạn vẫn cần phải config tương tự cho những VM khác cùng chức năng. Và số lượng VM càng nhiều thì lại càng tốn thời gian.
Sau một vài ngày ổn thỏa, đột nhiên tất cả các VM trên lại xuất hiện các triệu chứng lạ, sau khi kiểm tra bạn phát hiện mình đã mắc sai lầm khi điều chỉnh thông số của bộ nhớ. Thế là bạn phải vào từng VM và chỉnh lại config.
Liệu đây có phải là lần cuối bạn phải làm như vậy?
Cloud Computing có vẻ như đã giảm đáng kể 3 khuyết điểm lớn của The Iron Age là: cost, scalability, availability. Tuy nhiên consistency vẫn là một hạn chế nếu các thao tác vẫn là thủ công.
Là con người thì sẽ có những giới hạn nhất định, làm nhiều mệt, dễ quên thao tác và thứ tự và dễ dẫn ra sai sót.
Vì vậy để hạn chế tối đa “lỗi do sơ suất” (human mistake), đã đến lúc chúng ta đề cập đến automation
Automation
Automation là việc vận dụng những công cụ và máy móc để giảm sự tương tác của con người. Automation đã có từ rất lâu vậy có gì khác biệt và đã có những bước tiến gì với sự phát triển của cloud?
Đầu tiên hãy xem những phần nào của cơ sở hạ tầng có thể ứng dụng automation
hình 5.1
Nếu trong The Iron Age, automation có thể được thực hiện cho nhóm Applications và Application Runtime Platforms (với nhiều hạn chế)
Thì với Cloud Computing, automation có thể bao quát được toàn bộ tất cả các phần của hệ thống
Để có thể ứng dụng automation, những thao tác thủ công cần người thực hiện phải được chuyển thành những đoạn mã mà máy có thể hiểu được.
Chúng ta có một khái niệm đơn giản là scripting, viết những script (tập hợp các đoạn code đơn giản) để tự động một số hoặc một chuỗi những thao tác lặp đi lặp lại.
Sự tiến hóa của các công cụ
Có gì khác biệt giữa shell script với những công cụ mới hỗ trợ quản lí infrastructure?
Lấy ví dụ 1 đoạn code để setup 1 VM mới trên Google Cloud, với 2 file cùng thực hiện 1 chuỗi các thao tác
2 file code này có chức năng gần như tương tự nhau, nhưng cách thức vận hành và thực thi hoàn toàn khác nhau.
Cùng nhìn qua sự so sánh nho nhỏ ở bảng bên dưới
cách chạy
`shell -c ./main.sh`
`terraform apply`
lần chạy đầu tiên
tạo 1 disk, tạo 1 vm boot từ disk vừa tạo
tạo 1 disk, tạo 1 vm boot từ disk vừa tạo
lần chạy thứ 2
báo lỗi disk và vm đã tồn tại
thông báo trạng thái của hệ thống đã là mới nhất
sửa disk size để tăng dung lượng và run lại
báo lỗi disk và vm đã tồn tại
update disk với size mới
Có thể thấy những tool như terraform được tối ưu để giúp việc vận hành cơ sở hạ tầng được đơn giản hơn.
(Terraform là một công cụ để quản lí và giúp khởi tạo cơ sở hạ tầng bằng cách viết code, có thể tham khảo thêm ở đây)
Bạn có thể lập luận rằng file main.sh cũng có thể được viết lại để cung cấp những tính năng như terraform hay thậm chí bạn có thể dùng cloud sdk và viết automation code với những ngôn ngữ mạnh mẽ hơn như Go, Java hoặc .Net chắc chắn sẽ có thể cung cấp nhiều tính năng hơn và tùy biến tốt hơn nhiều do với terraform.
Tuy nhiên điều này đồng nghĩa với việc tăng thêm độ phức tạp.
Những tool như Terraform ép bạn phải theo những syntax chủ quan và thiếu sự linh hoạt cũng như sự mở rộng nhưng nhờ vào đó khi nhìn vào những file code bạn hiểu ngay lập tức tình trạng hiện tại của hạ tầng đang được thiết lập như thế nào chứ không phải vò đầu bức óc với những vòng lặp, điều kiện if else và hàng loạt những resource được khai báo động
Bạn càng giữ cho infrastructure code càng đơn giản càng tốt, bạn cũng có thể xem nó như data mô tả chính xác hạ tầng của hệ thống
Áp dụng những công cụ hiện đại
Hãy xem qua 1 ví dụ khác. Lần này là 1 redis cluster để đảm bảo High Availability như hình (giới thiệu về Redis, ví dụ thiết lập HA Redis Cluster)
2 node ha-proxy: làm proxy để route request vào redis
3 node redis: trong đó có 1 node master và 2 node slave
3 node sentinels: làm nhiệm vụ health check các redis node và thực hiện failover
hình 5.2
Cùng nhìn qua những đoạn psuedo code bên dưới
terraform code
main.tf
---
resource "google_compute_instance""redis"{ count = 3, name = "redis-${count.index}", ... }
resource "google_compute_instance""sentinels"{ count = 3, name = "sentinels-${count.index}", ... }
resource "google_compute_instance""ha-proxy"{ count = 2, name = "proxy-${count.index}", ... }
ansible code
hosts
---
[redis_master]
redis-ip-1
[redis_slave]
redis-ip-2
redis-ip-3
[sentinels]
sentinels-ip-1
sentinels-ip-2
sentinels-ip-3
[ha_proxy]
proxy-ip-1
proxy-ip-2
...
main.yaml
---
- name:redis_master
hosts:redis_master
tasks:
-name:install redis
...
-name:config redis
...
-name:tweak system config
...
-name:redis_replica
hosts:redis_replica
tasks:
-name:install redis
...
-name:config redis
...
-name:tweak system config
...
-name:sentinels
hosts:sentinels
tasks:
-name:install sentinels
...
-name:config sentinels
...
-name:ha_proxy
hosts:ha_proxy
tasks:
-name:install ha-proxy
...
-name:config ha-proxy
...
Thực hiện tuần tự các bước sau
terraform apply: sẽ tạo ra những cơ sở hạ tầng cần thiết, server, disk, ip, …
update file hosts của ansible để nhập vào ip của những resource tạo ra bởi terraform
ansible-playbook main.yaml: chịu trách nhiệm install và config tất cả những gì cần thiết để 1 cluster redis chạy hoàn chỉnh
sau đó bạn gọi redis thông qua ip loadbalancer của ha-proxy, request sẽ được đưa đến đúng server redis cần thiết, write sẽ được gửi đến master, read sẽ gửi đến replica
bạn tắt server master của redis, cluster sẽ tiến hành failover bầu 1 node mới làm master và mọi thứ vẫn làm việc trơn tru
Vì sao phải dùng 2 tool khác nhau là Terraform và Ansible? Có thể dùng 1 tool duy nhất để làm tất cả mọi việc không?
Thực tế, bạn có thể dùng Ansible để làm tất cả những việc trên và không cần đến Terraform hoặc 1 tool nào đó khác hỗ trợ tương tự
Tuy nhiên bạn nên cẩn thận với việc này!
Nếu bạn vẫn còn nhớ ở hình 5.1, các resources trong hệ thống được chia làm 3 nhóm khác nhau. Trong ví dụ hiện tại
Terraform: đảm nhiệm việc vận hành Infrastructure Platform
Ansible: đảm nhiệm việc vận hành Application Runtime Platform và có thể cả Applications
Việc quản lí những nhóm khác nhau đòi hỏi cách tư duy và cách vận hành khác nhau.
Một công cụ càng mạnh mẽ để có thể quản lí nhiều nhóm sẽ càng phức tạp.
Bạn dùng tool của Application Runtime Platform làm thay việc của Infrastructure Platform sẽ phức tạp hơn nhiều
Những thách thức
Giờ cùng nhìn lại 2 tình huống đưa ra ở phần Cloud Computing
1. Di chuyển Cloud
Terraform hỗ trợ nhiều cloud khác nhau.
Lấy ví dụ bạn đang vận hành ở Google Cloud và muốn chuyển qua AWS.
Bạn có thể viết thêm config cho AWS tương tự với những resource bên Google, chạy terraform, thế là bạn sẽ có một cơ sở hạ tầng tương ứng ở cloud mới
2. Thay đổi hàng loạt config
Bạn update code của Ansible và sau đó chạy, config mới sẽ được áp dụng lên các server cần thiết.
Nếu config mới có vấn đề, bạn chỉ cần revert lại code như trước và chạy lại, các server sẽ quay về trạng thái cũ
Có vẻ như dùng công cụ hiện đại đã giúp cuộc sống dễ dàng hơn. Tuy nhiên như thế vẫn chưa đủ, vẫn có gì đó chưa ổn
terraform và ansible code vẫn phải phụ thuộc vào 1 người nào đó chạy chúng
làm sao để biết ai sẽ là người chạy những đoạn code terraform hoặc ansible trên?
ai sẽ là người update những đoạn code terraform hoặc ansible?
làm sao để biết khi nào thì hợp lí để chạy?
làm sao biết được code hiện tại có phản ánh đúng hiện trạng của hạ tầng?
làm sao biết được sau khi chạy những code đó không có vấn đề gì nghiêm trọng xảy ra?
Mặc dù bạn đã áp dụng những công cụ hiện đại hỗ trợ automation, tuy nhiên nếu quản lí không hiệu quả và chưa áp dụng đầy đủ vẫn có hàng loạt những thách thức được đặt ra
hình 5.3
Những server ngổn ngang (Server Prawl)
Việc những server có thể được thiết lập một cách nhanh chóng nhờ vào sự trợ giúp của cloud và các công cụ dẫn đến một thời điểm mà số lượng server vượt quá tầm kiểm soát của team
khó để có thể update và apply những update mới nhất cho toàn bộ hệ thống
vì thế hệ thống gặp những rủi ro về security, performance và config không đồng bộ giữa các server với nhau
khó để tận dụng hiệu quả tài nguyên của hệ thống (các server có thể chạy dư thừa)
Trôi cấu hình (Configuration Drift)
Dù hệ thống có ứng dụng automation thì những hiện tượng trôi cấu hình vẫn rất hay xảy ra. Lấy 1 số ví dụ
hotfix trực tiếp lên server trong tình huống khẩn cấp nhưng sau đó quên update code. Lần kế tiếp automation chạy sẽ không có hotfix. Trường hợp này sẽ khó truy ra nguyên nhân hơn với những resource ít được update
automation chưa hỗ trợ việc cài thêm plugin từ bên ngoài cho java server, để nhanh chóng 1 bạn dev ssh và cài trực tiếp plugin vào server, với suy nghĩ là sẽ update automation sau. Và technical debt ngày càng nhiều hơn, dẫn đến 1 broken automation pipeline không ai dám chạy
Những Server mỏng manh (Snowflake Server)
Với những vấn đề như configuration drift, technical debt, workaround dẫn đến việc hình thành những snowflake server
snowflake là những server đòi hỏi phải được chăm sóc đặc biệt so với phần còn lại của hệ thống
Lấy ví dụ đa số server NodeJs của hệ thống đang chạy với version 10x, và những tool automation deploy và testing đều được cấu hình cho môi trường NodeJs 10x
Tuy nhiên có một vài NodeJs server vẫn phải dùng version 8x vì thế những server này không thể dùng những tool hỗ trợ như phần còn lại của hệ thống. Làm việc với những server này là một ám ảnh và dev luôn cầu nguyện rằng các server này sẽ sống mãi vì nếu nó chết thì khó biết cách nào để dựng lại 1 server tương tự
Cơ sở hạ tầng mong manh (Fragile Infrastructure)
Nhiều snowflake server và những vấn đề liên quan tới configuration drift dẫn đến một cơ sở hạ tầng không ổn định
Nỗi sợ automation (Automation Fear)
Bởi vì những sự bất ổn của server và infrastructure dẫn đến việc sợ áp dụng và chạy những công cụ automation, chạy automation sợ rằng sẽ làm hư phần nào đó
Thiếu automation lại dẫn đến một infrastructure thiếu ổn định. Cứ như vậy một vòng lặp được hình thành
Thật may cơ sở hạ tầng giờ đây đã là code, và những vấn đề gặp phải gần như tương tự với code, vậy thì chúng có thể được giải quyết bằng những quy trình, tiêu chuẩn áp dụng cho code
Infrastructure as Code
Vậy Infrastructure as Code hay IaC là gì?
Trích dẫn trong cuốn Infrastructure as Code của tác giả Kief Morris
Infrastructure as code is an approach to infrastructure automation based on practices from software development
Cơ sở hạ tầng dưới dạng mã là một cách thức để tự động hóa cơ sở hạ tầng dựa trên các thực hành của việc phát triển phần mềm
Đây không phải là một ngôn ngữ hay một framework hay công cụ cụ thể mà là một cách tư duy và vận hành cơ sở hạ tầng dựa trên những file code (file config), từ đó có thể áp dụng những framework hoặc công cụ quản lí code sẵn có trong các quy trình automation testing, continuous integration để đảm bảo chất lượng và độ ổn định
Thế nên chỉ dùng những công cụ như Terraform và Ansible một cách máy móc không phải là một mô hình IaC hoàn chỉnh. Cần có những quy trình và sự hợp tác từ những con người liên quan để vận hành hệ thống một cách ổn định
Các nguyên lý
Hệ thống có thể dễ dàng tái hiện (Reproducibility)
Khả năng build và rebuild bất cứ phần nào của hệ thống
Giảm đi những rủi ro khi thực hiện thay đổi
Và sự cố về hệ thống có thể được khắc phục 1 cách nhanh chóng
Hệ thống có thể được bỏ đi (Disposability)
Application có thể tiếp tục chạy một cách ổn định mỗi khi server gặp sự cố và được phục hồi lại
Server có thể bỏ đi và thay thế bằng 1 server khác với cấu hình tương tự 1 cách tự động
Hệ thống toàn vẹn (Consistency)
Những thành phần cùng cung cấp một tính năng trong hệ thống thì server của chúng phải giống nhau (hay những server được deploy bởi cùng 1 code phải hành xử giống nhau)
Như trong ví dụ về redis cluster ở trên
mỗi server của redis node phải được config giống nhau (chung 1 code) chỉ khác biệt ở tên và ip
Khi có sự thay đổi (vd nâng ram) thì thay đổi đó phải được áp dụng cho tất cả server thông qua automation
Những công đoạn có thể được lặp lại (Repeatability)
Tất cả những thay đổi lên hệ thống cần được track lại bằng code
Lại lấy ví dụ redis cluster
sau 1 thời gian chạy 1 replica node gặp traffic lớn và cần nâng cấp ram, có thể dễ dàng vào trực tiếp server và thao tác nhưng thao tác đó không được lưu lại
khi có 1 node khác cần nâng ram, 1 người khác lại tiếp tục nâng ram trực tiếp trên server của node này (có thể 1 giá trị khác vd 8Gb ram thay vì 6Gb như lần thao tác trước)
vậy trong cùng 1 cluster có những node với server khác nhau (vi phạm luôn về nguyên tắc consistency)
Hệ thống luôn thay đổi (Always changing)
Một hệ thống trong thời đại cloud có thể được thay đổi liên tục để phù hợp với những yêu cầu về business
Điều này đòi hỏi những người quản lí hệ thống thích ứng liên tục với những thay đổi và tìm hiểu để vận dụng các cách thức, chuẩn mực để quản lí hệ thống hiệu quả hơn
Cách vận hành
Một ví dụ về flow xử lí của một quy trình IaC
hình 5.4
Và đây là ví dụ về cách tổ chức code cho ví dụ về setup redis cluster ở phần trước
Example project structure
project
|_ env
| |_ staging
| | |_ redis
| |_ prod
| |_ redis
| |_ sentinels
| |_ ha-proxy
|
|_ modules
| |_ redis
| |_ sentinels
| |_ ha-proxy
|
|_ ci.yaml
modules
Nơi chứa tất cả những module dùng chung cho hệ thống. Ví dụ ở đây là những module để setup
redis
sentinels
ha-proxy
env
Nơi chứa config riêng biệt cho từng environment. Sẽ tái sử dụng code từ modules
Trong ví dụ hiện tại
staging: chỉ cần 1 server redis đơn giản để chạy
prod: cần 1 cluster redis với các công cụ khác như sentinels và ha-proxy
ci.yaml
config của continuous integration tool để khi code được merge vào nhánh chính sau khi review sẽ tự động chạy test và deploy
Điều quan trọng là tất cả quy trình có thể vận hành một cách tự động
Khi các công đoạn được tự động hóa thì nguồn nhân sự cần để quản lí hệ thống cũng sẽ giảm và việc quản lí cũng hiệu quả hơn, server prawl sẽ không còn là nỗi lo
Configuration Drift sẽ khó xảy ra hơn khi tất cả thay đổi được đánh version và deploy 1 cách tự động
Và vì thế số lượng snowflake server sẽ ngày càng giảm, đồng nghĩa với một cơ sở hạ tầng ổn định và bền vững hơn
Mọi người sẽ tự tin với những thay đổi của mình và chào đón việc áp dụng automation thay vì dè dặt như trước
Một số practice để giúp việc vận hành mô hình IaC hiệu quả
Tận dụng công cụ
Những công cụ như Terraform và Ansible được thiết kế để hỗ trợ cho mô hình IaC một cách tối ưu
Nhờ những công cụ này
tất cả những thao tác lên hệ thống có thể được lưu trữ dưới dạng code file
việc này vô cùng quan trọng để ứng dụng những công cụ khác quản lí code khác như versioning và continuous integration
ngoài ra những file code này được thiết kế riêng biệt cho IAC để trở nên đơn giản và dễ quản lí
Code as document
Document có một mục đích cao cả là giúp cho hệ thống ổn và chuẩn hóa tuy nhiên thực tế thì hoàn toàn trái ngược
thay đổi thường xuyên không được lưu giữ lại
và khó có cách hiệu quả để kiểm tra độ chính xác của document với hiện trạng của hệ thống
Một document với thông tin sai sẽ nguy hiểm hơn việc không có document
Với những công cụ IaC
file code đã được đơn giản hóa và trình bày rõ ràng cấu trúc của hệ thống
và đó cũng là những đơn vị thực thi trực tiếp hình thành nên hệ thống
vậy có thể xem đó như những document chính, những document khác nếu có chỉ nên là những thông tin hướng dẫn và phải đảm bảo sát nhất với code hiện tại
Versioning
đặt tất cả mọi thứ dưới sự quản lí của version control tool
traceability: mọi thay đổi điều có thể trace ngược lại khi có sự cố
rollback: khi có sự cố hệ thống có thể quay ngược về về version ổn định gần nhất
visibility: tất cả mọi người đều có thể thấy những thay đổi mới và review nếu có gì đó bất ổn
actionability: version control có thể trigger những flow automation khi có thay đổi
Continouse Testing
Automation Test là một trong những nhân tố đảm bảo sự ổn định trong Software Development và với Infrastructure cũng vậy
Với việc test nhanh và liên tục
cung cấp những feedback cần thiết khi có thay đổi để kịp thời chỉnh sửa
điều này giúp mọi người tự tin và code nhiều hơn trong flow automation
ngoài ra cũng góp phần ngăn chặn sớm những thay đổi làm sập hệ thống
Small change
Với những công cụ và quy trình automation được ứng dụng, những thay đổi nhỏ và nhanh được khuyến khích hơn những thay đổi lớn và lâu
dễ thực hiện hơn
test nhanh hơn và nhận feedback nhanh hơn
dễ rollback hơn khi có sự cố
Tổng kết
IaC không chỉ là việc sử dụng những công cụ configuration management hay orchestration management như Ansible và Terraform.
Cũng như một số mô hình khác, việc vận dụng IaC có hiệu quả hay không phụ thuộc lớn vào con người từ quy trình, tư duy đến cách thức phối hợp và thực thi
Một công ty có thể xây nên một hệ thống automation hoàn chỉnh với những công cụ xịn xò, tuy nhiên những con người làm việc với nó mới quyết định việc hệ thống đó có thích ứng kịp với những thay đổi liên tục về product và business hay không.
Nếu không thích ứng kịp thì sẽ lại nảy sinh vòng lặp từ server prawl đến automation fear. Ngược lại nếu vận dụng hiệu quả thì IaC mang lại những lợi ích không nhỏ về chi phí và sự ổn định cho hệ thống
Tham khảo
Bài viết tham khảo kiến thức từ
sách Infrastructure as Code của tác giả Kief Morris
