Terraform 0.11 - Getting Started with AWS EKS

AWS EKS के साथ आरंभ करना




terraform

AWS EKS के साथ आरंभ करना

अमेज़ॅन वेब सर्विसेज ईकेएस सेवा Kubernetes सर्वरों के सरलीकृत प्रबंधन के लिए अनुमति देती है। जबकि सेवा अपने आप में एक ऑपरेटर दृष्टिकोण से काफी सरल है, यह समझना कि यह AWS सेवा ब्रह्मांड के अन्य टुकड़ों के साथ कैसे जुड़ता है और स्थानीय कुबेरनेट ग्राहकों को प्रबंधित समूहों में कैसे कॉन्फ़िगर किया जा सकता है।

हालांकि ईकेएस उपयोगकर्ता गाइड एक सामान्य दृष्टिकोण से सेवा के साथ आरंभ करने के बारे में बहुत सारी जानकारी प्रदान करता है, यह गाइड एक टेराफॉर्म कॉन्फ़िगरेशन आधारित परिचय प्रदान करता है।

यह मार्गदर्शिका बताएगी कि टेराफॉर्म के उपयोग से एक नमूना वास्तुकला को कैसे तैनात किया जाए। गाइड कुबेरनेट्स के साथ कुछ बुनियादी परिचितता मानता है, लेकिन पहले से मौजूद तैनाती को नहीं मानता है। यह भी मानता है कि आप सामान्य टेराफ़ॉर्म योजना से परिचित हैं / वर्कफ़्लो लागू करते हैं; यदि आप टेराफ़ॉर्म में नए हैं, तो सबसे पहले आरंभ करने वाले मार्गदर्शक को देखें।

यह ध्यान देने योग्य है कि इन सेवाओं और संसाधनों का उपयोग करने के अन्य वैध तरीके हैं जो विभिन्न ट्रेडऑफ़ बनाते हैं। हम पाठकों को अतिरिक्त संदर्भ और सर्वोत्तम प्रथाओं के लिए संबंधित सेवाओं और संसाधनों के लिए आधिकारिक दस्तावेज से परामर्श करने के लिए प्रोत्साहित करते हैं। यह मार्गदर्शिका अभी भी इन सेवाओं से जुड़े मुख्य संसाधनों के लिए एक परिचय के रूप में काम कर सकती है, भले ही आप एक अलग वास्तुकला का चयन करें।

गाइड अवलोकन

यहां प्रस्तुत नमूना वास्तुकला में निम्नलिखित संसाधन शामिल हैं:

  • EKS क्लस्टर: AWS मास्टर सर्वर के कुबेरनेट क्लस्टर को प्रबंधित करता है
  • नवीनतम ईकेएस अमेज़ॅन लिनक्स 2 एएमआई पर आधारित 2 m4.large इंस्टेंस वाले AutoScaling समूह: ऑपरेटर ने कुबेरनेट्स सेवा चलाने के लिए Kuberneted कार्यकर्ता नोड प्रबंधित किए
  • एसोसिएटेड VPC, इंटरनेट गेटवे, सुरक्षा समूह, और सबनेट: ऑपरेटर EKS क्लस्टर और श्रमिक नोड शेष के लिए नेटवर्किंग संसाधनों का प्रबंधन करता है
  • एसोसिएटेड IAM रोल्स और नीतियां: ऑपरेटर ईकेएस और कार्यकर्ता नोड उदाहरणों के लिए एक्सेस संसाधनों का प्रबंधन करता है

तैयारी

इस गाइड का पालन करने के लिए आपको AWS खाते की आवश्यकता होगी और Terraform स्थापित करने के लिए। अपने क्रेडेंशियल्स को कॉन्फ़िगर करें ताकि Terraform आपकी ओर से कार्य करने में सक्षम हो।

यहां सादगी के लिए, हम मान लेंगे कि आप पहले से ही ऑटो एक्सेसिंग, EC2, EKS, और IAM संसाधनों को बनाने के लिए उपयुक्त पहुंच के साथ IAM क्रेडेंशियल्स का एक सेट का उपयोग कर रहे हैं। यदि आप निश्चित नहीं हैं और केवल विकास के लिए उपयोग किए जाने वाले AWS खाते में काम कर रहे हैं, तो आरंभ करने का सबसे सरल तरीका है लक्ष्य AWS खाते में पूर्ण प्रशासनिक पहुँच के साथ क्रेडेंशियल्स का उपयोग करना।

यदि आप स्थानीय रूप से मानक कुबेरनेट्स क्लाइंट, kubectl उपयोग करने की योजना बना रहे हैं, तो heptio-authenticator-aws उपयोग के साथ exec प्रमाणीकरण का समर्थन करने के लिए कम से कम संस्करण 1.10 होना चाहिए। इन अनुप्रयोगों की स्थापना और कॉन्फ़िगरेशन के बारे में अतिरिक्त जानकारी के लिए, उनके आधिकारिक दस्तावेज देखें।

प्रासंगिक लिंक:

AWS में नमूना वास्तुकला बनाएँ

क्लस्टर नाम चर

नीचे का नमूना टेराफ़ॉर्म कॉन्फ़िगरेशन cluster-name ( var.cluster-name ) नामक एक चर का संदर्भ देता है जिसका उपयोग स्थिरता के लिए किया जाता है। अपने स्वयं के क्लस्टर नाम को प्रतिस्थापित करने या चर कॉन्फ़िगरेशन बनाने के लिए स्वतंत्र महसूस करें:

variable "cluster-name" {
  default = "terraform-eks-demo"
  type    = "string"
}

आधार VPC नेटवर्किंग

ईकेएस को अपने नेटवर्किंग कॉन्फ़िगरेशन के लिए आधार प्रदान करने के लिए वर्चुअल प्राइवेट क्लाउड के उपयोग की आवश्यकता है।

नीचे एक 10.0.0.0/16 VPC, दो 10.0.X.0 / 24 सबनेट, एक इंटरनेट गेटवे बनाएगा, और इंटरनेट गेटवे के माध्यम से बाहरी ट्रैफ़िक को रूट करने के लिए सबनेट रूटिंग सेट करेगा:

# This data source is included for ease of sample architecture deployment
# and can be swapped out as necessary.
data "aws_availability_zones" "available" {}

resource "aws_vpc" "demo" {
  cidr_block = "10.0.0.0/16"

  tags = "${
    map(
     "Name", "terraform-eks-demo-node",
     "kubernetes.io/cluster/${var.cluster-name}", "shared",
    )
  }"
}

resource "aws_subnet" "demo" {
  count = 2

  availability_zone = "${data.aws_availability_zones.available.names[count.index]}"
  cidr_block        = "10.0.${count.index}.0/24"
  vpc_id            = "${aws_vpc.demo.id}"

  tags = "${
    map(
     "Name", "terraform-eks-demo-node",
     "kubernetes.io/cluster/${var.cluster-name}", "shared",
    )
  }"
}

resource "aws_internet_gateway" "demo" {
  vpc_id = "${aws_vpc.demo.id}"

  tags {
    Name = "terraform-eks-demo"
  }
}

resource "aws_route_table" "demo" {
  vpc_id = "${aws_vpc.demo.id}"

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = "${aws_internet_gateway.demo.id}"
  }
}

resource "aws_route_table_association" "demo" {
  count = 2

  subnet_id      = "${aws_subnet.demo.*.id[count.index]}"
  route_table_id = "${aws_route_table.demo.id}"
}

कुबेरनेट्स मास्टर्स

यह वह जगह है जहां ईकेएस सेवा खेल में आती है। इसके लिए पहले से ही कुछ ऑपरेटर प्रबंधित संसाधनों की आवश्यकता होती है ताकि कुबेरनेट्स अन्य AWS सेवाओं को ठीक से प्रबंधित कर सकें और साथ ही अपने स्थानीय कार्य केंद्र (यदि वांछित) और कार्यकर्ता नोड्स से इनबाउंड नेटवर्किंग संचार की अनुमति दे सकें।

ईकेएस मास्टर क्लस्टर IAM भूमिका

नीचे एक उदाहरण IAM भूमिका और नीति है जो EKS सेवा को अन्य AWS सेवाओं से डेटा का प्रबंधन या पुनर्प्राप्त करने की अनुमति देता है। इन नीतियों को aws_iam_policy_document डेटा स्रोत के साथ बनाना भी संभव है

नवीनतम आवश्यक नीति के लिए, ईकेएस उपयोगकर्ता गाइड देखें

resource "aws_iam_role" "demo-cluster" {
  name = "terraform-eks-demo-cluster"

  assume_role_policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "eks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
POLICY
}

resource "aws_iam_role_policy_attachment" "demo-cluster-AmazonEKSClusterPolicy" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
  role       = "${aws_iam_role.demo-cluster.name}"
}

resource "aws_iam_role_policy_attachment" "demo-cluster-AmazonEKSServicePolicy" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSServicePolicy"
  role       = "${aws_iam_role.demo-cluster.name}"
}

ईकेएस मास्टर क्लस्टर सुरक्षा समूह

यह सुरक्षा समूह Kubernetes मास्टर्स के लिए नेटवर्किंग पहुंच को नियंत्रित करता है। हम बाद में वर्कर नोड्स से ट्रैफिक को अनुमति देने के लिए इसे एक इन्ग्रेस नियम से कॉन्फ़िगर करेंगे।

resource "aws_security_group" "demo-cluster" {
  name        = "terraform-eks-demo-cluster"
  description = "Cluster communication with worker nodes"
  vpc_id      = "${aws_vpc.demo.id}"

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags {
    Name = "terraform-eks-demo"
  }
}

# OPTIONAL: Allow inbound traffic from your local workstation external IP
#           to the Kubernetes. You will need to replace A.B.C.D below with
#           your real IP. Services like icanhazip.com can help you find this.
resource "aws_security_group_rule" "demo-cluster-ingress-workstation-https" {
  cidr_blocks       = ["A.B.C.D/32"]
  description       = "Allow workstation to communicate with the cluster API Server"
  from_port         = 443
  protocol          = "tcp"
  security_group_id = "${aws_security_group.demo-cluster.id}"
  to_port           = 443
  type              = "ingress"
}

ईकेएस मास्टर क्लस्टर

यह संसाधन वास्तविक कुबेरनेट्स मास्टर क्लस्टर है। AWS में प्रावधान करने में कुछ मिनट लग सकते हैं।

resource "aws_eks_cluster" "demo" {
  name            = "${var.cluster-name}"
  role_arn        = "${aws_iam_role.demo-cluster.arn}"

  vpc_config {
    security_group_ids = ["${aws_security_group.demo-cluster.id}"]
    subnet_ids         = ["${aws_subnet.demo.*.id}"]
  }

  depends_on = [
    "aws_iam_role_policy_attachment.demo-cluster-AmazonEKSClusterPolicy",
    "aws_iam_role_policy_attachment.demo-cluster-AmazonEKSServicePolicy",
  ]
}

टेराफॉर्म से कुब्जेकल विन्यास प्राप्त करना

यदि आप कुबेरनेट क्लस्टर का प्रबंधन करने के लिए कुबेटेल का उपयोग करने की योजना बना रहे हैं, तो अब अपने ग्राहक को कॉन्फ़िगर करने के लिए एक शानदार समय हो सकता है। नीचे kubectl आउटपुट आपके क्लस्टर से कनेक्ट करने के लिए एक नमूना kubectl कॉन्फ़िगरेशन उत्पन्न करता है।

आप kubectl version पहुँच को स्थानीय क्लाइंट संस्करण जानकारी के अलावा सर्वर संस्करण जानकारी प्रदर्शित करने के माध्यम से सत्यापित कर सकते हैं।

locals {
  kubeconfig = <<KUBECONFIG


apiVersion: v1
clusters:
- cluster:
    server: ${aws_eks_cluster.demo.endpoint}
    certificate-authority-data: ${aws_eks_cluster.demo.certificate_authority.0.data}
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: aws
  name: aws
current-context: aws
kind: Config
preferences: {}
users:
- name: aws
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      command: heptio-authenticator-aws
      args:
        - "token"
        - "-i"
        - "${var.cluster-name}"
KUBECONFIG
}

output "kubeconfig" {
  value = "${local.kubeconfig}"
}

कुबेरनेट्स कार्यकर्ता नोड्स

ईकेएस सेवा वर्तमान में वर्कर नोड्स चलाने के लिए प्रबंधित संसाधन प्रदान नहीं करती है। यहां हम कुछ ऑपरेटर प्रबंधित संसाधन बनाएंगे ताकि कुबेरनेट्स अन्य AWS सेवाओं, नेटवर्किंग पहुंच और अंत में एक कॉन्फ़िगरेशन का प्रबंधन कर सकें, जो कार्यकर्ता नोड्स की स्वचालित स्केलिंग की अनुमति देता है।

कार्यकर्ता नोड IAM भूमिका और उदाहरण प्रोफ़ाइल

नीचे एक उदाहरण IAM भूमिका और नीति है जो कार्यकर्ता को नोड्स को अन्य AWS सेवाओं से डेटा प्रबंधित या पुनर्प्राप्त करने की अनुमति देता है। इसका उपयोग कुबेरनेट्स द्वारा कार्यकर्ता नोड्स को क्लस्टर में शामिल होने की अनुमति देने के लिए किया जाता है। इन नीतियों को aws_iam_policy_document डेटा स्रोत के साथ बनाना भी संभव है

नवीनतम आवश्यक नीति के लिए, ईकेएस उपयोगकर्ता गाइड देखें

resource "aws_iam_role" "demo-node" {
  name = "terraform-eks-demo-node"

  assume_role_policy = <<POLICY
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
POLICY
}

resource "aws_iam_role_policy_attachment" "demo-node-AmazonEKSWorkerNodePolicy" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy"
  role       = "${aws_iam_role.demo-node.name}"
}

resource "aws_iam_role_policy_attachment" "demo-node-AmazonEKS_CNI_Policy" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"
  role       = "${aws_iam_role.demo-node.name}"
}

resource "aws_iam_role_policy_attachment" "demo-node-AmazonEC2ContainerRegistryReadOnly" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly"
  role       = "${aws_iam_role.demo-node.name}"
}

resource "aws_iam_instance_profile" "demo-node" {
  name = "terraform-eks-demo"
  role = "${aws_iam_role.demo-node.name}"
}

कार्यकर्ता नोड सुरक्षा समूह

यह सुरक्षा समूह Kubernetes कार्यकर्ता नोड्स तक नेटवर्किंग पहुंच को नियंत्रित करता है।

resource "aws_security_group" "demo-node" {
  name        = "terraform-eks-demo-node"
  description = "Security group for all nodes in the cluster"
  vpc_id      = "${aws_vpc.demo.id}"

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = "${
    map(
     "Name", "terraform-eks-demo-node",
     "kubernetes.io/cluster/${var.cluster-name}", "owned",
    )
  }"
}

resource "aws_security_group_rule" "demo-node-ingress-self" {
  description              = "Allow node to communicate with each other"
  from_port                = 0
  protocol                 = "-1"
  security_group_id        = "${aws_security_group.demo-node.id}"
  source_security_group_id = "${aws_security_group.demo-node.id}"
  to_port                  = 65535
  type                     = "ingress"
}

resource "aws_security_group_rule" "demo-node-ingress-cluster" {
  description              = "Allow worker Kubelets and pods to receive communication from the cluster control plane"
  from_port                = 1025
  protocol                 = "tcp"
  security_group_id        = "${aws_security_group.demo-node.id}"
  source_security_group_id = "${aws_security_group.demo-cluster.id}"
  to_port                  = 65535
  type                     = "ingress"
}

ईकेएस मास्टर क्लस्टर में श्रमिक नोड एक्सेस

अब जब हमारे पास यह जानने का एक तरीका है कि कार्यकर्ता नोड्स से ट्रैफ़िक कहाँ से आ रहा है, तो हम कार्यकर्ता नोड्स को EKS मास्टर क्लस्टर में नेटवर्क एक्सेस की अनुमति दे सकते हैं।

resource "aws_security_group_rule" "demo-cluster-ingress-node-https" {
  description              = "Allow pods to communicate with the cluster API Server"
  from_port                = 443
  protocol                 = "tcp"
  security_group_id        = "${aws_security_group.demo-cluster.id}"
  source_security_group_id = "${aws_security_group.demo-node.id}"
  to_port                  = 443
  type                     = "ingress"
}

वर्कर नोड नोडल ग्रुप

अब हमारे पास EC2 इंस्टेंसेस बनाने और प्रबंधित करने के लिए सब कुछ है जो कुबेरनेट क्लस्टर में हमारे कार्यकर्ता नोड्स के रूप में काम करेंगे। यह सेटअप EC2 इंस्टेंस के साथ मैन्युअल रूप से काम करने के बजाय EC2 AutoScaling Group (ASG) का उपयोग करता है। यह AutoScaling नीतियों (यहां लागू नहीं) के साथ संयोजन में उपयोग किए जाने पर मांग को कम करने और काम करने वाले को कम करने के लिए लचीलापन प्रदान करता है।

सबसे पहले, हमें नवीनतम अमेज़ॅन मशीन इमेज (एएमआई) लाने के लिए एक डेटा स्रोत बनाएं जो अमेज़ॅन ईकेएस संगत कुबेरनेट्स के साथ प्रदान करता है।

data "aws_ami" "eks-worker" {
  filter {
    name   = "name"
    values = ["eks-worker-*"]
  }

  most_recent = true
  owners      = ["602401143452"] # Amazon Account ID
}

इसके बाद, एक AutoScaling लॉन्च कॉन्फ़िगरेशन बनाने की अनुमति देता है जो हमारे सभी पूर्वापेक्षा संसाधनों का उपयोग करके परिभाषित करता है कि EC2 इंस्टेंसेस को कैसे बनाया जाए।

# This data source is included for ease of sample architecture deployment
# and can be swapped out as necessary.
data "aws_region" "current" {}

# EKS currently documents this required userdata for EKS worker nodes to
# properly configure Kubernetes applications on the EC2 instance.
# We utilize a Terraform local here to simplify Base64 encoding this
# information into the AutoScaling Launch Configuration.
# More information: https://amazon-eks.s3-us-west-2.amazonaws.com/1.10.3/2018-06-05/amazon-eks-nodegroup.yaml
locals {
  demo-node-userdata = <<USERDATA
#!/bin/bash -xe

CA_CERTIFICATE_DIRECTORY=/etc/kubernetes/pki
CA_CERTIFICATE_FILE_PATH=$CA_CERTIFICATE_DIRECTORY/ca.crt
mkdir -p $CA_CERTIFICATE_DIRECTORY
echo "${aws_eks_cluster.demo.certificate_authority.0.data}" | base64 -d >  $CA_CERTIFICATE_FILE_PATH
INTERNAL_IP=$(curl -s http://169.254.169.254/latest/meta-data/local-ipv4)
sed -i s,MASTER_ENDPOINT,${aws_eks_cluster.demo.endpoint},g /var/lib/kubelet/kubeconfig
sed -i s,CLUSTER_NAME,${var.cluster-name},g /var/lib/kubelet/kubeconfig
sed -i s,REGION,${data.aws_region.current.name},g /etc/systemd/system/kubelet.service
sed -i s,MAX_PODS,20,g /etc/systemd/system/kubelet.service
sed -i s,MASTER_ENDPOINT,${aws_eks_cluster.demo.endpoint},g /etc/systemd/system/kubelet.service
sed -i s,INTERNAL_IP,$INTERNAL_IP,g /etc/systemd/system/kubelet.service
DNS_CLUSTER_IP=10.100.0.10
if [[ $INTERNAL_IP == 10.* ]] ; then DNS_CLUSTER_IP=172.20.0.10; fi
sed -i s,DNS_CLUSTER_IP,$DNS_CLUSTER_IP,g /etc/systemd/system/kubelet.service
sed -i s,CERTIFICATE_AUTHORITY_FILE,$CA_CERTIFICATE_FILE_PATH,g /var/lib/kubelet/kubeconfig
sed -i s,CLIENT_CA_FILE,$CA_CERTIFICATE_FILE_PATH,g  /etc/systemd/system/kubelet.service
systemctl daemon-reload
systemctl restart kubelet
USERDATA
}

resource "aws_launch_configuration" "demo" {
  associate_public_ip_address = true
  iam_instance_profile        = "${aws_iam_instance_profile.demo-node.name}"
  image_id                    = "${data.aws_ami.eks-worker.id}"
  instance_type               = "m4.large"
  name_prefix                 = "terraform-eks-demo"
  security_groups             = ["${aws_security_group.demo-node.id}"]
  user_data_base64            = "${base64encode(local.demo-node-userdata)}"

  lifecycle {
    create_before_destroy = true
  }
}

अंत में, हम एक AutoScaling Group बनाते हैं जो वास्तव में AutoScaling लॉन्च कॉन्फ़िगरेशन के आधार पर EC2 इंस्टेंस लॉन्च करता है।

resource "aws_autoscaling_group" "demo" {
  desired_capacity     = 2
  launch_configuration = "${aws_launch_configuration.demo.id}"
  max_size             = 2
  min_size             = 1
  name                 = "terraform-eks-demo"
  vpc_zone_identifier  = ["${aws_subnet.demo.*.id}"]

  tag {
    key                 = "Name"
    value               = "terraform-eks-demo"
    propagate_at_launch = true
  }

  tag {
    key                 = "kubernetes.io/cluster/${var.cluster-name}"
    value               = "owned"
    propagate_at_launch = true
  }
}

कार्यकर्ता नोड्स में शामिल होने के लिए आवश्यक कुबेरनेट कॉन्फ़िगरेशन

EKS सेवा क्लस्टर-स्तरीय API पैरामीटर या संसाधन को स्वचालित रूप से अंतर्निहित Kubernetes क्लस्टर को कॉन्फ़िगर करने के लिए AWS IAM भूमिका प्रमाणीकरण के माध्यम से क्लस्टर में कार्यकर्ता नोड्स को शामिल करने की अनुमति नहीं देती है।

अंतर्निहित कुबेरनेट क्लस्टर कॉन्फ़िगरेशन का प्रबंधन करना इस मार्गदर्शिका के दायरे से परे है, हम इस बात का उदाहरण प्रदान करते हैं कि kubectl नीचे ConfigMap माध्यम से आवश्यक कुबेरनेट ConfigMap कैसे लागू किया जाए।

अपने ConfigMap कॉन्फ़िगरेशन से एक उदाहरण IAM भूमिका प्रमाणीकरण विन्यास का उत्पादन करने के लिए:

locals {
  config-map-aws-auth = <<CONFIGMAPAWSAUTH


apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: ${aws_iam_role.demo-node.arn}
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
CONFIGMAPAWSAUTH
}

output "config-map-aws-auth" {
  value = "${local.config-map-aws-auth}"
}
  • terraform output config-map-aws-auth config-map-aws-auth.yaml को एक फाइल में सेव करें, जैसे config-map-aws-auth.yaml
  • रन kubectl apply -f config-map-aws-auth.yaml
  • आप सत्यापित कर सकते हैं कि कार्यकर्ता नोड्स के माध्यम से क्लस्टर में शामिल हो रहे हैं: kubectl get nodes --watch - kubectl get nodes --watch

इस बिंदु पर, आपको उम्मीद के मुताबिक कुबेरनेट्स का उपयोग करने में सक्षम होना चाहिए!

AWS में नमूना वास्तुकला को नष्ट करें

मान लें कि आपने एक अलग कॉन्फ़िगरेशन में नमूना आर्किटेक्चर का निर्माण किया है, बस इस गाइड के साथ सभी संबंधित संसाधनों को फाड़ने के लिए terraform destroy का उपयोग करें।