IaC

Ngày 8: Cơ sở hạ tầng dưới dạng mã (Infrastructure as Code)

Tạo máy ảo với Terraform và biến

Trong bài này, chúng ta sẽ tạo một hoặc hai máy ảo bằng cách sử dụng terraform trong VirtualBox. Điều này không phải là một trường hợp thông thường, VirtualBox là một lựa chọn ảo hóa máy trạm và điều này không phải là một trường hợp sử dụng cho Terraform, nhưng hiện tại tôi đang ở độ cao 36.000ft và dù tôi đã triển khai các tài nguyên trên public cloud, nhưng việc làm điều này trên máy tính xách tay của tôi nhanh hơn nhiều.

Chỉ cho mục đích demo, nhưng khái niệm là tương tự, chúng ta sẽ có mã cấu hình trạng thái mong muốn của chúng ta và sau đó chúng ta sẽ chạy mã đó với nhà cung cấp VirtualBox. Trong quá khứ, chúng ta đã sử dụng vagrant ở đây và tôi đã đề cập đến sự khác biệt giữa vagrant terraform ở đầu phần này.

Tạo máy ảo trong VirtualBox

Điều đầu tiên chúng ta sẽ làm là tạo một thư mục mới được gọi là VirtualBox, sau đó chúng ta có thể tạo một tệp tin VirtualBox.tf và đây sẽ là nơi chúng ta định nghĩa các tài nguyên của chúng ta. Đoạn mã dưới đây, có thể được tìm thấy trong thư mục VirtualBox với tên VirtualBox.tf, sẽ tạo 2 máy ảo trong VirtualBox.

Bạn có thể tìm hiểu thêm về nhà cung cấp VirtualBox của cộng đồng tại đây

terraform {
  required_providers {
    virtualbox = {
      source = "terra-farm/virtualbox"
      version = "0.2.2-alpha.1"
    }
  }
}

# There are currently no configuration options for the provider itself.

resource "virtualbox_vm" "node" {
  count     = 2
  name      = format("node-%02d", count.index + 1)
  image     = "https://app.vagrantup.com/ubuntu/boxes/bionic64/versions/20180903.0.0/providers/virtualbox.box"
  cpus      = 2
  memory    = "512 mib"

  network_adapter {
    type           = "hostonly"
    host_interface = "vboxnet1"
  }
}

output "IPAddr" {
  value = element(virtualbox_vm.node.*.network_adapter.0.ipv4_address, 1)
}

output "IPAddr_2" {
  value = element(virtualbox_vm.node.*.network_adapter.0.ipv4_address, 2)
}

Bây giờ sau khi chúng ta đã định nghĩa mã của mình, chúng ta có thể thực hiện lệnh terraform init trên thư mục của chúng ta để tải xuống nhà cung cấp cho Virtualbox.

Bạn cũng cần phải cài đặt VirtualBox trên hệ thống của bạn. Sau đó, chúng ta có thể chạy lệnh terraform plan để xem mã của chúng ta sẽ tạo ra gì cho chúng ta. Tiếp theo là terraform apply. Hình ảnh dưới đây hiển thị quá trình hoàn thành của bạn.

Trong Virtualbox, bạn sẽ nhìn thấy 2 máy ảo mới được khởi tạo.

Thay đổi cấu hình

Hãy thay đổi cấu hình triển khai để thử nghiệm. Chúng ta chỉ cần thay đổi dòng count để hiển thị số lượng nút mới mong muốn của chúng ta. Khi chúng ta chạy terraform apply, nó sẽ trông giống như dưới đây.

Một khi đã hoàn thành, trong VirtualBox bạn sẽ nhìn thấy 3 máy ảo được khởi tạo và chạy.

Khi mọi thứ đã hoàn thành, chúng ta có thể dọn dẹp bằng cách sử dụng terraform destroy, tất cả máy ảo sẽ được xóa bỏ sau đó.

Biến và đầu ra

Trong buổi trước, chúng ta đã đề cập đến outputs khi chạy ví dụ hello-world. Nhưng chúng ta có thể đi vào chi tiết hơn ở đây.

Tuy nhiên, cũng có nhiều biến số khác mà chúng ta có thể sử dụng, cũng như một số cách khác nhau để định nghĩa biến số.

  • Chúng ta có thể nhập biến số bằng tay với lệnh terraform plan hoặc terraform apply
  • Chúng ta có thể định nghĩa chúng trong tệp .tf trong khối
  • Chúng ta có thể sử dụng biến môi trường trong hệ thống của chúng ta bằng cách sử dụng định dạng TF_VAR_NAME.
  • Sở thích của tôi là sử dụng tệp terraform.tfvars trong thư mục dự án của chúng ta.
  • Có tùy chọn tệp *auto.tfvars
  • Hoặc chúng ta có thể định nghĩa khi chạy lệnh terraform plan hoặc terraform apply với -var hoặc -var-file.

Bắt đầu từ dưới lên sẽ là thứ tự các biến số được định nghĩa.

Chúng ta cũng đã đề cập đến việc tệp trạng thái sẽ chứa thông tin nhạy cảm. Chúng ta có thể định nghĩa thông tin nhạy cảm như là một biến số và chúng ta có thể định nghĩa nó như là thông tin nhạy cảm.

variable "some resource"  {
    description = "something important"
    type: string
    sensitive = true

}

Docker Containers, Provisioners & Modules

Trong phần này, chúng ta sẽ triển khai một Docker container với một số cấu hình đến môi trường Docker tại máy tính cá nhân của chúng ta.

Docker Demo

Trước tiên, chúng ta sẽ sử dụng đoạn mã dưới đây, kết quả của đoạn mã này là chúng ta muốn triển khai một ứng dụng web đơn giản vào docker và công bố nó để nó có thể truy cập được từ mạng của chúng ta. Chúng ta sẽ sử dụng nginx và chúng ta sẽ làm cho nó có sẵn từ bên ngoài trên máy tính xách tay của chúng ta qua localhost và cổng 8000. Chúng ta đang sử dụng một nhà cung cấp docker từ cộng đồng và bạn cũng có thể thấy image docker chúng ta đang sử dụng cũng được nêu trong cấu hình của chúng ta.

terraform {
  required_providers {
    docker = {
      source  = "kreuzwerker/docker"
      version = "2.16.0"
    }
  }
}

provider "docker" {}

resource "docker_image" "nginx" {
  name         = "nginx:latest"
  keep_locally = false
}

resource "docker_container" "nginx" {
  image = docker_image.nginx.latest
  name  = "tutorial"
  ports {
    internal = 80
    external = 8000
  }
}

Nhiệm vụ đầu tiên là sử dụng lệnh terraform init để tải xuống nhà cung cấp vào máy tính cục bộ của chúng ta.

Tiếp theo, chúng ta chạy lệnh terraform apply, sau đó là docker ps, và bạn sẽ thấy chúng ta có một container đang chạy.

Nếu chúng ta mở trình duyệt và điều hướng đến http://localhost:8000/, bạn sẽ thấy chúng ta có quyền truy cập vào container NGINX của chúng ta.

Các bạn có thể tìm hiểu thêm về Docker Provider tại đây Docker Provider

Phía trên là một ví dụ rất đơn giản về những gì có thể làm được với Terraform và Docker và cách chúng ta có thể quản lý nó dưới trạng thái Terraform. Chúng ta đã bàn về docker-compose trong phần container và có một chút sự chồng chéo theo cách nào đó giữa việc này, cơ sở hạ tầng như mã và sau đó Kubernetes.

Để chứng minh điều này và cho thấy cách Terraform có thể xử lý một chút phức tạp hơn, chúng ta sẽ lấy tệp docker-compose cho WordPress và MySQL mà chúng ta đã tạo bằng docker-compose và đặt nó vào Terraform. Bạn có thể tìm thấy tệp docker-wordpress.tf

terraform {
  required_providers {
    docker = {
      source  = "kreuzwerker/docker"
      version = "2.16.0"
    }
  }
}

provider "docker" {}

variable wordpress_port {
  default = "8080"
}

resource "docker_volume" "db_data" {
  name = "db_data"
}

resource "docker_network" "wordpress_net" {
  name = "wordpress_net"
}

resource "docker_container" "db" {
  name  = "db"
  image = "mysql:5.7"
  restart = "always"
  network_mode = "wordpress_net"
  env = [
     "MYSQL_ROOT_PASSWORD=wordpress",
     "MYSQL_PASSWORD=wordpress",
     "MYSQL_USER=wordpress",
     "MYSQL_DATABASE=wordpress"
  ]
  mounts {
    type = "volume"
    target = "/var/lib/mysql"
    source = "db_data"
    }
}

resource "docker_container" "wordpress" {
  name  = "wordpress"
  image = "wordpress:latest"
  restart = "always"
  network_mode = "wordpress_net"
  env = [
    "WORDPRESS_DB_HOST=db:3306",
    "WORDPRESS_DB_USER=wordpress",
    "WORDPRESS_DB_NAME=wordpress",
    "WORDPRESS_DB_PASSWORD=wordpress"
  ]
  ports {
    internal = "80"
    external = "${var.wordpress_port}"
  }
}

Chúng ta lại tệp vào một thư mục mới và sau đó chạy lệnh terraform init để tải về các công cụ cần thiết.

Sau đó, chúng ta chạy lệnh terraform apply và kiểm tra đầu ra của lệnh docker ps, chúng ta sẽ thấy các container mới được tạo ra.

Sau đó, chúng ta có thể truy cập vào giao diện WordPress. Tương tự như khi chúng ta đã thực hiện quá trình này với docker-compose trong phần container, bây giờ chúng ta có thể tiếp tục thiết lập và các bài viết WordPress của chúng ta sẽ được lưu trong cơ sở dữ liệu MySQL.

Bây giờ chúng ta đã thảo luận khá chi tiết về containers và Kubernetes, chúng ta có thể hiểu rằng việc sử dụng containers một mình chỉ phù hợp cho việc kiểm thử, và nếu bạn đang chạy ứng dụng, bạn sẽ không chỉ sử dụng containers mà còn xem xét sử dụng Kubernetes để đạt được điều này. Tiếp theo, chúng ta sẽ tìm hiểu cách sử dụng Terraform với Kubernetes.

Provisioners

Provisioners được sử dụng để xử lý những công việc không thể được miêu tả theo cách khai báo, giúp chúng ta triển khai các tác vụ đó.

Nếu không có cách thức khác và việc thêm phức tạp vào mã của bạn là điểm đến cuối cùng, bạn có thể thực hiện điều này bằng cách chạy một đoạn mã tương tự như khối mã sau đây.

resource "docker_container" "db" {
  # ...

  provisioner "local-exec" {
    command = "echo The server's IP address is ${self.private_ip}"
  }
}

Provisioner remote-exec được sử dụng để gọi một script trên tài nguyên từ xa sau khi nó được tạo ra. Điều này có thể được sử dụng cho một số công việc đặc thù của hệ điều hành hoặc có thể được sử dụng để kết hợp với một công cụ quản lý cấu hình. Tuy nhiên, hãy lưu ý rằng một số công việc này đã được bao gồm trong các provisioner tương ứng của chúng.

Thông tin chi tiết về provisioners

  • file
  • local-exec
  • remote-exec
  • vendor
    • ansible
    • chef
    • puppet

Modules

Modules là các container chứa nhiều tài nguyên được sử dụng cùng nhau. Một module bao gồm một tập hợp các file .tf trong cùng một thư mục.

Modules là một cách tốt để tách biệt các tài nguyên cơ sở hạ tầng của bạn và cũng cho phép bạn sử dụng các module của bên thứ ba đã được tạo trước để không phải phát minh lại bánh xe.

Ví dụ, nếu chúng ta muốn sử dụng cùng một dự án để xây dựng các máy ảo (VMs), mạng riêng ảo (VPCs), nhóm bảo mật (Security Groups) và một cụm Kubernetes, chúng ta có thể muốn chia tách các tài nguyên của chúng thành các module để xác định rõ hơn các tài nguyên và nhóm chúng lại.

Một lợi ích khác của modules là bạn có thể sử dụng chúng cho các dự án khác hoặc chia sẻ chúng công khai để giúp cộng đồng.

Chúng ta đang chia cơ sở hạ tầng thành các thành phần, và các thành phần này được gọi là modules ở đây.

Kubernetes & Đa môi trường

Cho đến nay, trong phần về Cơ sở hạ tầng mã nguồn, chúng ta đã xem xét triển khai máy ảo, mặc dù chúng ta đã sử dụng VirtualBox, nhưng nguyên tắc là giống nhau, chúng ta xác định bằng mã nguồn những gì chúng ta muốn máy ảo của mình trông như thế nào và sau đó triển khai. Tương tự cho các container Docker và trong buổi học này, chúng ta sẽ xem cách Terraform có thể được sử dụng để tương tác với các tài nguyên được hỗ trợ bởi Kubernetes.

Tôi đã sử dụng Terraform để triển khai các cụm Kubernetes cho mục đích trình diễn trên ba nhà cung cấp đám mây chính và bạn có thể tìm thấy kho lưu trữ tại đây tf_k8deploy

Tuy nhiên, bạn cũng có thể sử dụng Terraform để tương tác với các đối tượng bên trong cụm Kubernetes, điều này có thể được thực hiện bằng cách sử dụng Kubernetes provider hoặc Helm provider để quản lý việc triển kahi trong kubernetes

Bây giờ chúng ta có thể sử dụng kubectl như đã được hiển thị trong các phần trước. Tuy nhiên, việc sử dụng Terraform trong môi trường Kubernetes có một số lợi ích.

  • Quy trình làm việc thống nhất – nếu bạn đã sử dụng Terraform để triển khai các cụm của mình, bạn có thể sử dụng cùng quy trình làm việc và công cụ để triển khai trong các cụm Kubernetes của bạn.
  • Quản lý vòng đời – Terraform không chỉ là một công cụ cung cấp, nó còn cho phép thay đổi, cập nhật và xóa bỏ.

Ví dụ Kubernetes đơn giản

Tương tự như demo chúng ta đã tạo trong buổi học trước, bây giờ chúng ta có thể triển khai nginx vào cụm Kubernetes của chúng ta. Trong mục này, tôi sẽ sử dụng minikube để làm ví dụ. Chúng ta tạo file Kubernetes.tf và bạn có thể tìm thấy nó tại đây

Trong tệp đó, chúng ta sẽ xác định nhà cung cấp Kubernetes, chúng ta sẽ trỏ đến tệp kubeconfig của chúng ta, tạo một namespace có tên là nginx, và sau đó chúng ta sẽ tạo một deployment chứa 2 bản sao và cuối cùng là service.

terraform {
  required_providers {
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = ">= 2.0.0"
    }
  }
}
provider "kubernetes" {
  config_path = "~/.kube/config"
}
resource "kubernetes_namespace" "test" {
  metadata {
    name = "nginx"
  }
}
resource "kubernetes_deployment" "test" {
  metadata {
    name      = "nginx"
    namespace = kubernetes_namespace.test.metadata.0.name
  }
  spec {
    replicas = 2
    selector {
      match_labels = {
        app = "MyTestApp"
      }
    }
    template {
      metadata {
        labels = {
          app = "MyTestApp"
        }
      }
      spec {
        container {
          image = "nginx"
          name  = "nginx-container"
          port {
            container_port = 80
          }
        }
      }
    }
  }
}
resource "kubernetes_service" "test" {
  metadata {
    name      = "nginx"
    namespace = kubernetes_namespace.test.metadata.0.name
  }
  spec {
    selector = {
      app = kubernetes_deployment.test.spec.0.template.0.metadata.0.labels.app
    }
    type = "NodePort"
    port {
      node_port   = 30201
      port        = 80
      target_port = 80
    }
  }
}

Điều đầu tiên chúng ta phải làm trong thư mục dự án mới của chúng ta là chạy lệnh terraform init.

Và trước khi chúng ta chạy lệnh terraform apply, để tôi cho bạn thấy rằng chúng ta không có bất kỳ namespace nào.

Khi chúng ta chạy lệnh terraform apply, điều này sẽ tạo ra 3 tài nguyên mới đó là namespace, deployment và service trong cụm Kubernetes của chúng ta.

Bây giờ chúng ta có thể xem các tài nguyên đã triển khai trong cụm của chúng ta.

Bây giờ, vì chúng ta đang sử dụng minikube như bạn đã thấy trong phần trước, điều này có một số hạn chế khi chúng ta thử nghiệm với mạng docker cho ingress.

Nhưng nếu chúng ta chỉ đơn giản sử dụng lệnh kubectl port-forward -n nginx svc/nginx 30201:80 và mở trình duyệt đến http://localhost:30201/, chúng ta sẽ thấy trang NGINX của chúng ta.

Nếu bạn muốn thử các bài thực hành chi tiết hơn với Terraform và Kubernetes, thì trang web HashiCorp Learn site là một nguồn tuyệt vời để thực hiện.

Đa môi trường

Nếu chúng ta muốn lấy bất kỳ bài thực hành nào đã được thực hiện nhưng bây giờ muốn có môi trường sản xuất, staging và phát triển cụ thể trông giống nhau và tận dụng mã nguồn này, có hai phương pháp để làm được điều này với Terraform:

  • terraform workspaces– nhiều phần được đặt tên trong một backend duy nhất
  • cấu trúc file – Cấu trúc thư mục cung cấp phân tách, các module cung cấp tái sử dụng.

Tuy nhiên, mỗi phương pháp trên đều có ưu điểm và nhược điểm riêng.

Terraform workspaces

Ưu điểm

  • Dễ bắt đầu: Sử dụng Terraform workspaces giúp bắt đầu một cách dễ dàng, vì bạn có thể tạo các workspace riêng biệt một cách đơn giản và nhanh chóng.
  • Tiện lợi khi có terraform.workspace
  • Giảm thiểu sự trùng lặp code

Nhược điểm

  • Dễ mắc lỗi do con người
  • Lưu trạng thái trong cùng backend
  • Mã nguồn không hiển thị rõ ràng các cấu hình triển khai

File Structure

Ưu điểm

  • Cô lập, tách riêng backend state
    • Cải thiện an ninh bảo mật
    • Giảm thiểu lỗi cá nhân
  • Mã nguồn (code) thể hiện chính xác so với trạng thái triển khai

Nhược điểm

Phải chạy nhiều lần terraform apply để triển khai cho nhiều môi trường
Gia tăng sự trùng lặp,. nhưng có thể giảm thiểu khi sử dụng module

Kiểm thử, Công cụ và Các phương pháp thay thế

Khi kết thúc phần này về Cơ sở hạ tầng dưới dạng Mã, chúng ta phải đề cập đến việc kiểm thử mã nguồn, các công cụ khác nhau có sẵn và sau đó là một số phương pháp thay thế Terraform để đạt được điều này. Như tôi đã nói ở đầu phần này, tập trung của tôi là Terraform vì nó trước tiên là miễn phí và mã nguồn mở, thứ hai, nó là đa nền tảng và không phụ thuộc vào môi trường. Nhưng cũng có các phương pháp thay thế khác mà cần được xem xét, nhưng mục tiêu chung là làm cho mọi người nhận thức rằng đây là cách triển khai cơ sở hạ tầng của bạn.

Mã lỗi

Phần đầu tiên mà tôi muốn đề cập trong phiên này là mã lỗi. Khác với mã ứng dụng, cơ sở hạ tầng dưới dạng mã có thể được sử dụng và sau đó không được sử dụng trong một thời gian rất dài. Hãy lấy ví dụ rằng chúng ta sẽ sử dụng Terraform để triển khai môi trường máy ảo trên AWS, hoàn hảo và nó hoạt động lần đầu tiên và chúng ta có môi trường của chúng ta. Nhưng môi trường này không thay đổi quá thường xuyên, vì vậy mã bị bỏ lại trong trạng thái hiện tại, có thể hoặc hy vọng được lưu trữ ở một vị trí trung tâm, nhưng mã không thay đổi.

Điều gì sẽ xảy ra nếu có thay đổi trong cơ sở hạ tầng? Nhưng nó được thực hiện bên ngoài quy trình chính hoặc các yếu tố khác thay đổi trong môi trường của chúng ta.

Các thay đổi bên ngoài quy trình chính Phiên bản không được gắn kết Các phụ thuộc đã bị loại bỏ Các thay đổi chưa được áp dụng

Kiểm thử

Một lĩnh vực quan trọng khác liên quan đến mã lỗi và nói chung là khả năng kiểm thử IaC và đảm bảo rằng tất cả các phần đều hoạt động theo đúng yêu cầu.

Đầu tiên, chúng ta có thể xem xét một số lệnh kiểm thử tích hợp sẵn:

CommandDescription
terraform fmtĐịnh dạng lại tệp terraform (.tf), giúp cho việc đọc code dễ dàng hơn
terraform validateXác thực, phát hiện lỗi cú pháp các tệp cấu hình trong một thư mục
terraform planTạo một kế hoạch thực thi, cho phép xem trước các thay đổi mà Terraform dự định thực hiện.
Custom validationXác thực lại các biến đầu vào, bảo đảm khớp với những gì mà chúng ta yêu cầu

Ngoài ra chúng ta cũng có một số công cụ kiểm thử khác không thuộc hệ sinh thái của Hashicorp nhưng hỗ trợ terraform:

  • tflint
    • tìm các lỗi có thể xảy ra.
    • ảnh báo về cú pháp đã bị loại bỏ và các khai báo không được sử dụng.
    • áp dụng các quy ước tốt nhất và quy ước đặt tên.

Công cụ dò quét

  • checkov – dò quét toàn bộ hệ thống hạ tầng, phát hiện và cảnh báo các lỗi cấu hình.
  • tfsec – Phân tích tính bảo mật của hạ tầng dựa vào code.
  • terrascan – Phân tích hạ tầng.
  • terraform-compliance – một framework kiểm thử nhẹ, tập trung vào bảo mật và tuân thủ quy định để kiểm tra terraform, giúp bạn có khả năng kiểm thử phản tác dụng cho cơ sở hạ tầng dưới dạng mã.
  • snyk -dò quét code phát hiện và cảnh báo các lỗi cấu hình về bảo mật.

Managed Cloud offering

  • Terraform Sentinel – embedded policy-as-code framework integrated with the HashiCorp Enterprise products. It enables fine-grained, logic-based policy decisions, and can be extended to use information from external sources.

Công cụ tương tự như unit test cho terraform

Terratest – Terratest là một thư viện Go cung cấp mẫu và hàm kiểm thử cơ sở hạ tầng.

Một số công cụ khác nổi bật – tự động hóa

  • Terraform Cloud – Terraform Cloud là dịch vụ quản lý của HashiCorp. Nó loại bỏ sự cần thiết của các công cụ và tài liệu không cần thiết cho các nhà thực hành, nhóm và tổ chức sử dụng Terraform trong môi trường sản xuất.
  • Terragrunt – Terragrunt is a là lớp bọc bên ngoài, cung cấp tính năng giữ cấu hình và triển khai, tránh việc lặp lại code, làm việc với nhiều module khác nhau.
  • Atlantis – Tự động hóa triển khai dựa trên gitops

Các lựa chọn thay thế

Như đã đề cập ở ngày 57, dưới đây là các công cụ thay thế cho terraform

Cloud SpecificCloud Agnostic
AWS CloudFormationTerraform
Azure Resource ManagerPulumi
Google Cloud Deployment Manager

Tôi đã sử dụng AWS CloudFormation nhiều nhất trong danh sách trên, đặc biệt là trong môi trường AWS, nhưng tôi chưa sử dụng các công cụ khác ngoại trừ Terraform. Như bạn có thể tưởng tượng, các phiên bản dành riêng cho một nhà cung cấp điện toán đám mây cụ thể rất tốt trong đám mây đó, nhưng nếu bạn có nhiều môi trường đám mây khác nhau, bạn sẽ gặp khó khăn trong việc di chuyển các cấu hình đó hoặc bạn sẽ phải sử dụng nhiều mặt phẳng quản lý khác nhau cho các nỗ lực IaC của mình.

Tôi nghĩ bước tiếp theo thú vị đối với tôi là dành thời gian để tìm hiểu thêm về Pulumi

Theo so sánh Pulumi trên trang web của họ:

“Cả Terraform và Pulumi đều cung cấp mô hình mã hóa cơ sở hạ tầng dựa trên trạng thái mong muốn, trong đó mã đại diện cho trạng thái hạ tầng mong muốn và bộ triển khai so sánh trạng thái mong muốn này với trạng thái hiện tại của stack và xác định những tài nguyên cần tạo, cập nhật hoặc xóa.”

Sự khác biệt lớn nhất mà tôi nhìn thấy là, so với ngôn ngữ cấu hình HashiCorp (HCL), Pulumi cho phép sử dụng ngôn ngữ thông dụng như Python, TypeScript, JavaScript, Go và .NET.

Tôi đã xem qua một video giới thiệu Giới thiệu về Pulumi Introduction to Pulumi: Modern Infrastructure as Code: Cơ sở hạ tầng như mã hiện đại và tôi thích sự dễ dàng và sự lựa chọn mà nó mang lại. Tôi muốn tìm hiểu thêm về Pulumi.

Tài liệu tham khảo

Điều này kết thúc phần về Cơ sở hạ tầng như mã (Infrastructure as Code) trong Lộ trình học DevOps trong 12 ngày của chúng ta, tiếp theo chúng ta sẽ di chuyển đến một phần chồng chéo nhỏ với quản lý cấu hình cụ thể, đặc biệt là khi chúng ta vượt qua cái nhìn tổng quan về quản lý cấu hình lớn, chúng ta sẽ sử dụng Ansible cho một số tác vụ và bài thực hành.

Hẹn gặp lại vào Ngày 9: Tự động hóa quản lý cấu hình (Configuration management)

Các bài viết là bản tiếng Việt của tài liệu 90DaysOfDevOps của Micheal Cade và có qua sửa đổi, bổ sung. Tất cả đều có license [Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License][cc-by-nc-sa]

Mọi thắc mắc xin hãy liên hệ
Email: [email protected]

(Nguồn: vntechies.dev)

Previous page 1 2

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button