ਟੈਰਾਫਾਰਮ ਨੁਕਸਾਨ

ਆਉ ਕੁਝ ਖਤਰਿਆਂ ਨੂੰ ਉਜਾਗਰ ਕਰਦੇ ਹਾਂ, ਜਿਸ ਵਿੱਚ ਲੂਪਸ, ਜੇ ਸਟੇਟਮੈਂਟਸ ਅਤੇ ਡਿਪਲਾਇਮੈਂਟ ਤਕਨੀਕਾਂ, ਅਤੇ ਨਾਲ ਹੀ ਹੋਰ ਆਮ ਮੁੱਦੇ ਜੋ ਟੈਰਾਫਾਰਮ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹਨ, ਨਾਲ ਸਬੰਧਤ ਹਨ:

• ਗਿਣਤੀ ਅਤੇ for_each ਪੈਰਾਮੀਟਰਾਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਹਨ;
• ਜ਼ੀਰੋ ਡਾਊਨਟਾਈਮ ਤੈਨਾਤੀਆਂ ਨੂੰ ਸੀਮਤ ਕਰੋ;
• ਇੱਕ ਚੰਗੀ ਯੋਜਨਾ ਵੀ ਅਸਫਲ ਹੋ ਸਕਦੀ ਹੈ;
• ਰੀਫੈਕਟਰਿੰਗ ਦੇ ਨੁਕਸਾਨ ਹੋ ਸਕਦੇ ਹਨ;
• ਮੁਲਤਵੀ ਤਾਲਮੇਲ ਇੱਕਸਾਰ ਹੁੰਦਾ ਹੈ... ਮੁਲਤਵੀ ਦੇ ਨਾਲ।

ਗਿਣਤੀ ਅਤੇ for_each ਪੈਰਾਮੀਟਰਾਂ ਦੀਆਂ ਸੀਮਾਵਾਂ ਹਨ

ਇਸ ਅਧਿਆਇ ਦੀਆਂ ਉਦਾਹਰਨਾਂ ਲੂਪਸ ਅਤੇ ਕੰਡੀਸ਼ਨਲ ਤਰਕ ਵਿੱਚ ਗਿਣਤੀ ਪੈਰਾਮੀਟਰ ਅਤੇ for_each ਸਮੀਕਰਨ ਦੀ ਵਿਆਪਕ ਵਰਤੋਂ ਕਰਦੀਆਂ ਹਨ। ਉਹ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਕਰਦੇ ਹਨ, ਪਰ ਉਹਨਾਂ ਦੀਆਂ ਦੋ ਮਹੱਤਵਪੂਰਨ ਸੀਮਾਵਾਂ ਹਨ ਜਿਹਨਾਂ ਬਾਰੇ ਤੁਹਾਨੂੰ ਸੁਚੇਤ ਹੋਣ ਦੀ ਲੋੜ ਹੈ।

• Count and for_each ਕਿਸੇ ਵੀ ਸਰੋਤ ਆਉਟਪੁੱਟ ਵੇਰੀਏਬਲ ਦਾ ਹਵਾਲਾ ਨਹੀਂ ਦੇ ਸਕਦਾ ਹੈ।
• ਗਿਣਤੀ ਅਤੇ for_each ਨੂੰ ਮੋਡੀਊਲ ਸੰਰਚਨਾ ਵਿੱਚ ਵਰਤਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ ਹੈ।

count ਅਤੇ for_each ਕਿਸੇ ਵੀ ਸਰੋਤ ਆਉਟਪੁੱਟ ਵੇਰੀਏਬਲ ਦਾ ਹਵਾਲਾ ਨਹੀਂ ਦੇ ਸਕਦਾ ਹੈ

ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਹਾਨੂੰ ਕਈ EC2 ਸਰਵਰਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਤੁਸੀਂ ASG ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਨਾ ਚਾਹੁੰਦੇ। ਤੁਹਾਡਾ ਕੋਡ ਇਸ ਤਰ੍ਹਾਂ ਹੋ ਸਕਦਾ ਹੈ:

resource "aws_instance" "example_1" {
   count             = 3
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

ਆਓ ਉਨ੍ਹਾਂ ਨੂੰ ਇਕ-ਇਕ ਕਰਕੇ ਦੇਖੀਏ।

ਕਿਉਂਕਿ ਗਿਣਤੀ ਪੈਰਾਮੀਟਰ ਇੱਕ ਸਥਿਰ ਮੁੱਲ 'ਤੇ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ, ਇਹ ਕੋਡ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਕੰਮ ਕਰੇਗਾ: ਜਦੋਂ ਤੁਸੀਂ ਅਪਲਾਈ ਕਮਾਂਡ ਚਲਾਉਂਦੇ ਹੋ, ਇਹ ਤਿੰਨ EC2 ਸਰਵਰ ਬਣਾਏਗਾ। ਪਰ ਉਦੋਂ ਕੀ ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਮੌਜੂਦਾ AWS ਖੇਤਰ ਦੇ ਅੰਦਰ ਹਰੇਕ ਉਪਲਬਧਤਾ ਜ਼ੋਨ (AZ) ਵਿੱਚ ਇੱਕ ਸਰਵਰ ਤਾਇਨਾਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ? ਤੁਸੀਂ ਆਪਣੇ ਕੋਡ ਨੂੰ aws_availability_zones ਡੇਟਾ ਸਰੋਤ ਤੋਂ ਜ਼ੋਨਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਲੋਡ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਫਿਰ ਹਰੇਕ ਨੂੰ ਲੂਪ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਗਿਣਤੀ ਪੈਰਾਮੀਟਰ ਅਤੇ ਐਰੇ ਸੂਚਕਾਂਕ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸ ਵਿੱਚ ਇੱਕ EC2 ਸਰਵਰ ਬਣਾ ਸਕਦੇ ਹੋ:

resource "aws_instance" "example_2" {
   count                   = length(data.aws_availability_zones.all.names)
   availability_zone   = data.aws_availability_zones.all.names[count.index]
   ami                     = "ami-0c55b159cbfafe1f0"
   instance_type       = "t2.micro"
}

data "aws_availability_zones" "all" {}

ਇਹ ਕੋਡ ਵੀ ਵਧੀਆ ਕੰਮ ਕਰੇਗਾ, ਕਿਉਂਕਿ ਗਿਣਤੀ ਪੈਰਾਮੀਟਰ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਡੇਟਾ ਸਰੋਤਾਂ ਦਾ ਹਵਾਲਾ ਦੇ ਸਕਦਾ ਹੈ। ਪਰ ਕੀ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਸਰਵਰਾਂ ਦੀ ਸੰਖਿਆ ਤੁਹਾਨੂੰ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਕੁਝ ਸਰੋਤ ਦੇ ਆਉਟਪੁੱਟ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ? ਇਸ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਕਰਨ ਲਈ, ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਹੈ random_integer ਸਰੋਤ ਦੀ ਵਰਤੋਂ ਕਰਨਾ, ਜੋ ਕਿ, ਜਿਵੇਂ ਕਿ ਨਾਮ ਤੋਂ ਪਤਾ ਲੱਗਦਾ ਹੈ, ਇੱਕ ਬੇਤਰਤੀਬ ਪੂਰਨ ਅੰਕ ਵਾਪਸ ਕਰਦਾ ਹੈ:

resource "random_integer" "num_instances" {
  min = 1
  max = 3
}

ਇਹ ਕੋਡ 1 ਅਤੇ 3 ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਬੇਤਰਤੀਬ ਸੰਖਿਆ ਬਣਾਉਂਦਾ ਹੈ। ਆਓ ਦੇਖੀਏ ਕਿ ਕੀ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਅਸੀਂ aws_instance ਸਰੋਤ ਦੇ ਕਾਉਂਟ ਪੈਰਾਮੀਟਰ ਵਿੱਚ ਇਸ ਸਰੋਤ ਦੇ ਆਉਟਪੁੱਟ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ:

resource "aws_instance" "example_3" {
   count             = random_integer.num_instances.result
   ami                = "ami-0c55b159cbfafe1f0"
   instance_type = "t2.micro"
}

ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਕੋਡ 'ਤੇ ਟੈਰਾਫਾਰਮ ਪਲਾਨ ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਹੇਠ ਲਿਖੀ ਗਲਤੀ ਮਿਲੇਗੀ:

Error: Invalid count argument

   on main.tf line 30, in resource "aws_instance" "example_3":
   30: count = random_integer.num_instances.result

The "count" value depends on resource attributes that cannot be determined until apply, so Terraform cannot predict how many instances will be created. To work around this, use the -target argument to first apply only the resources that the count depends on.

ਟੈਰਾਫਾਰਮ ਲਈ ਲੋੜ ਹੈ ਕਿ ਕੋਈ ਵੀ ਸਰੋਤ ਬਣਾਉਣ ਜਾਂ ਸੋਧੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ, ਯੋਜਨਾਬੰਦੀ ਪੜਾਅ ਦੌਰਾਨ ਹਰੇਕ ਲਈ ਗਿਣਤੀ ਅਤੇ ਗਣਨਾ ਕੀਤੀ ਜਾਵੇ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਗਿਣਤੀ ਅਤੇ for_each ਸ਼ਾਬਦਿਕ, ਵੇਰੀਏਬਲਾਂ, ਡੇਟਾ ਸਰੋਤਾਂ, ਅਤੇ ਇੱਥੋਂ ਤੱਕ ਕਿ ਸਰੋਤ ਸੂਚੀਆਂ (ਜਿੰਨਾ ਚਿਰ ਉਹਨਾਂ ਦੀ ਲੰਬਾਈ ਨੂੰ ਸਮਾਂ-ਤਹਿ 'ਤੇ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ) ਦਾ ਹਵਾਲਾ ਦੇ ਸਕਦਾ ਹੈ, ਪਰ ਗਣਨਾ ਕੀਤੇ ਸਰੋਤ ਆਉਟਪੁੱਟ ਵੇਰੀਏਬਲਾਂ ਲਈ ਨਹੀਂ।

ਗਿਣਤੀ ਅਤੇ for_each ਨੂੰ ਮੋਡੀਊਲ ਸੰਰਚਨਾ ਵਿੱਚ ਵਰਤਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ ਹੈ

ਕਿਸੇ ਦਿਨ ਤੁਸੀਂ ਆਪਣੇ ਮੋਡੀਊਲ ਕੌਂਫਿਗਰੇਸ਼ਨ ਵਿੱਚ ਇੱਕ ਗਿਣਤੀ ਪੈਰਾਮੀਟਰ ਜੋੜਨ ਲਈ ਪਰਤਾਏ ਹੋ ਸਕਦੇ ਹੋ:

module "count_example" {
     source = "../../../../modules/services/webserver-cluster"

     count = 3

     cluster_name = "terraform-up-and-running-example"
     server_port = 8080
     instance_type = "t2.micro"
}

ਇਹ ਕੋਡ ਵੈਬਸਰਵਰ-ਕਲੱਸਟਰ ਸਰੋਤ ਦੀਆਂ ਤਿੰਨ ਕਾਪੀਆਂ ਬਣਾਉਣ ਲਈ ਇੱਕ ਮੋਡੀਊਲ ਦੇ ਅੰਦਰ ਗਿਣਤੀ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਜਾਂ ਤੁਸੀਂ ਕਿਸੇ ਬੂਲੀਅਨ ਸਥਿਤੀ ਦੇ ਆਧਾਰ 'ਤੇ ਇਸ ਦੇ ਕਾਊਂਟ ਪੈਰਾਮੀਟਰ ਨੂੰ 0 'ਤੇ ਸੈੱਟ ਕਰਕੇ ਕਿਸੇ ਮੋਡੀਊਲ ਨੂੰ ਕਨੈਕਟ ਕਰਨਾ ਵਿਕਲਪਿਕ ਬਣਾਉਣਾ ਚਾਹ ਸਕਦੇ ਹੋ। ਇਹ ਵਾਜਬ ਕੋਡ ਵਰਗਾ ਲੱਗ ਸਕਦਾ ਹੈ, ਪਰ ਟੈਰਾਫਾਰਮ ਪਲਾਨ ਚਲਾਉਣ ਵੇਲੇ ਤੁਹਾਨੂੰ ਇਹ ਗਲਤੀ ਮਿਲੇਗੀ:

Error: Reserved argument name in module block

   on main.tf line 13, in module "count_example":
   13: count = 3

The name "count" is reserved for use in a future version of Terraform.

ਬਦਕਿਸਮਤੀ ਨਾਲ, ਟੈਰਾਫਾਰਮ 0.12.6 ਦੇ ਅਨੁਸਾਰ, ਇੱਕ ਮੋਡੀਊਲ ਸਰੋਤ ਵਿੱਚ ਗਿਣਤੀ ਜਾਂ for_each ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ। ਟੈਰਾਫਾਰਮ 0.12 ਰੀਲੀਜ਼ ਨੋਟਸ (http://bit.ly/3257bv4) ਦੇ ਅਨੁਸਾਰ, HashiCorp ਭਵਿੱਖ ਵਿੱਚ ਇਸ ਸਮਰੱਥਾ ਨੂੰ ਜੋੜਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੀ ਹੈ, ਇਸ ਲਈ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਿਆਂ ਕਿ ਤੁਸੀਂ ਇਸ ਕਿਤਾਬ ਨੂੰ ਕਦੋਂ ਪੜ੍ਹਦੇ ਹੋ, ਇਹ ਪਹਿਲਾਂ ਹੀ ਉਪਲਬਧ ਹੋ ਸਕਦੀ ਹੈ। ਪੱਕਾ ਪਤਾ ਕਰਨ ਲਈ, ਇੱਥੇ ਟੈਰਾਫਾਰਮ ਚੇਂਜਲੌਗ ਪੜ੍ਹੋ.

ਜ਼ੀਰੋ ਡਾਊਨਟਾਈਮ ਤੈਨਾਤੀਆਂ ਦੀਆਂ ਸੀਮਾਵਾਂ

ASG ਦੇ ਨਾਲ ਮਿਲਾ ਕੇ create_before_destroy ਬਲਾਕ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਜ਼ੀਰੋ-ਡਾਊਨਟਾਈਮ ਡਿਪਲਾਇਮੈਂਟ ਬਣਾਉਣ ਲਈ ਇੱਕ ਵਧੀਆ ਹੱਲ ਹੈ, ਇੱਕ ਚੇਤਾਵਨੀ ਨੂੰ ਛੱਡ ਕੇ: ਆਟੋਸਕੇਲਿੰਗ ਨਿਯਮ ਸਮਰਥਿਤ ਨਹੀਂ ਹਨ। ਜਾਂ ਵਧੇਰੇ ਸਟੀਕ ਹੋਣ ਲਈ, ਇਹ ਹਰ ਤੈਨਾਤੀ 'ਤੇ ASG ਆਕਾਰ ਨੂੰ min_size 'ਤੇ ਰੀਸੈਟ ਕਰਦਾ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਸਮੱਸਿਆ ਹੋ ਸਕਦੀ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਚੱਲ ਰਹੇ ਸਰਵਰਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਵਧਾਉਣ ਲਈ ਆਟੋਸਕੇਲਿੰਗ ਨਿਯਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ।

ਉਦਾਹਰਨ ਲਈ, ਵੈਬਸਰਵਰ-ਕਲੱਸਟਰ ਮੋਡੀਊਲ ਵਿੱਚ aws_autoscaling_schedule ਸਰੋਤਾਂ ਦਾ ਇੱਕ ਜੋੜਾ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ, ਜੋ ਸਵੇਰੇ 9 ਵਜੇ ਕਲੱਸਟਰ ਵਿੱਚ ਸਰਵਰਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਦੋ ਤੋਂ ਦਸ ਤੱਕ ਵਧਾ ਦਿੰਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਸਵੇਰੇ 11 ਵਜੇ ਤੈਨਾਤ ਕਰਦੇ ਹੋ, ਤਾਂ ਨਵਾਂ ASG ਦਸ ਦੀ ਬਜਾਏ ਸਿਰਫ਼ ਦੋ ਸਰਵਰਾਂ ਨਾਲ ਬੂਟ ਹੋ ਜਾਵੇਗਾ ਅਤੇ ਅਗਲੇ ਦਿਨ ਸਵੇਰੇ 9 ਵਜੇ ਤੱਕ ਇਸੇ ਤਰ੍ਹਾਂ ਰਹੇਗਾ।

ਇਸ ਸੀਮਾ ਨੂੰ ਕਈ ਤਰੀਕਿਆਂ ਨਾਲ ਰੋਕਿਆ ਜਾ ਸਕਦਾ ਹੈ।

• aws_autoscaling_schedule ਵਿੱਚ ਆਵਰਤੀ ਪੈਰਾਮੀਟਰ ਨੂੰ 0 9 * * * ("ਸਵੇਰੇ 9 ਵਜੇ ਚਲਾਓ") ਤੋਂ 0-59 9-17 * * * ("ਸਵੇਰੇ 9 ਵਜੇ ਤੋਂ ਸ਼ਾਮ 5 ਵਜੇ ਤੱਕ ਹਰ ਮਿੰਟ ਚਲਾਓ") ਵਿੱਚ ਬਦਲੋ। ਜੇਕਰ ASG ਪਹਿਲਾਂ ਹੀ ਦਸ ਸਰਵਰ ਹਨ, ਤਾਂ ਇਸ ਆਟੋਸਕੇਲਿੰਗ ਨਿਯਮ ਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਣ ਨਾਲ ਕੁਝ ਵੀ ਨਹੀਂ ਬਦਲੇਗਾ, ਜੋ ਅਸੀਂ ਚਾਹੁੰਦੇ ਹਾਂ। ਪਰ ਜੇਕਰ ASG ਨੂੰ ਹਾਲ ਹੀ ਵਿੱਚ ਤਾਇਨਾਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਇਹ ਨਿਯਮ ਇਹ ਯਕੀਨੀ ਬਣਾਏਗਾ ਕਿ ਵੱਧ ਤੋਂ ਵੱਧ ਇੱਕ ਮਿੰਟ ਵਿੱਚ ਇਸਦੇ ਸਰਵਰਾਂ ਦੀ ਗਿਣਤੀ ਦਸ ਤੱਕ ਪਹੁੰਚ ਜਾਵੇਗੀ। ਇਹ ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸ਼ਾਨਦਾਰ ਪਹੁੰਚ ਨਹੀਂ ਹੈ, ਅਤੇ ਦਸ ਤੋਂ ਦੋ ਸਰਵਰਾਂ ਅਤੇ ਪਿੱਛੇ ਤੋਂ ਵੱਡੀ ਛਾਲ ਵੀ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ।
• ਇੱਕ ਕਸਟਮ ਸਕ੍ਰਿਪਟ ਬਣਾਓ ਜੋ ASG ਵਿੱਚ ਕਿਰਿਆਸ਼ੀਲ ਸਰਵਰਾਂ ਦੀ ਸੰਖਿਆ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ AWS API ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ, ਇਸਨੂੰ ਇੱਕ ਬਾਹਰੀ ਡੇਟਾ ਸਰੋਤ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕਾਲ ਕਰੋ (ਪੰਨਾ 249 'ਤੇ "ਬਾਹਰੀ ਡੇਟਾ ਸਰੋਤ" ਵੇਖੋ), ਅਤੇ ASG ਦੇ ਲੋੜੀਂਦੇ_ਸਮਰੱਥਾ ਪੈਰਾਮੀਟਰ ਨੂੰ ਵਾਪਸ ਕੀਤੇ ਮੁੱਲ 'ਤੇ ਸੈੱਟ ਕਰੋ। ਸਕ੍ਰਿਪਟ. ਇਸ ਤਰ੍ਹਾਂ, ਹਰੇਕ ਨਵੀਂ ASG ਉਦਾਹਰਨ ਹਮੇਸ਼ਾ ਮੌਜੂਦਾ ਟੈਰਾਫਾਰਮ ਕੋਡ ਦੀ ਸਮਰੱਥਾ 'ਤੇ ਚੱਲੇਗੀ ਅਤੇ ਇਸਨੂੰ ਬਰਕਰਾਰ ਰੱਖਣਾ ਵਧੇਰੇ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦਾ ਹੈ।

ਬੇਸ਼ੱਕ, ਟੈਰਾਫਾਰਮ ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ ਜ਼ੀਰੋ-ਡਾਊਨਟਾਈਮ ਤੈਨਾਤੀਆਂ ਲਈ ਬਿਲਟ-ਇਨ ਸਮਰਥਨ ਹੋਵੇਗਾ, ਪਰ ਮਈ 2019 ਤੱਕ, ਹੈਸ਼ੀਕਾਰਪ ਟੀਮ ਦੀ ਇਸ ਕਾਰਜਸ਼ੀਲਤਾ ਨੂੰ ਜੋੜਨ ਦੀ ਕੋਈ ਯੋਜਨਾ ਨਹੀਂ ਸੀ (ਵੇਰਵੇ - ਇੱਥੇ).

ਸਹੀ ਯੋਜਨਾ ਨੂੰ ਅਸਫਲਤਾ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ

ਕਈ ਵਾਰ ਯੋਜਨਾ ਕਮਾਂਡ ਇੱਕ ਬਿਲਕੁਲ ਸਹੀ ਤੈਨਾਤੀ ਯੋਜਨਾ ਤਿਆਰ ਕਰਦੀ ਹੈ, ਪਰ ਲਾਗੂ ਕਮਾਂਡ ਇੱਕ ਗਲਤੀ ਵਾਪਸ ਕਰਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, aws_iam_user ਸਰੋਤ ਨੂੰ ਉਸੇ ਨਾਮ ਨਾਲ ਜੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਜੋ ਤੁਸੀਂ ਪਹਿਲਾਂ ਅਧਿਆਇ 2 ਵਿੱਚ ਬਣਾਏ IAM ਉਪਭੋਗਤਾ ਲਈ ਵਰਤਿਆ ਸੀ:

resource "aws_iam_user" "existing_user" {
   # Подставьте сюда имя уже существующего пользователя IAM,
   # чтобы попрактиковаться в использовании команды terraform import
   name = "yevgeniy.brikman"
}

ਹੁਣ, ਜੇਕਰ ਤੁਸੀਂ ਯੋਜਨਾ ਕਮਾਂਡ ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਟੈਰਾਫਾਰਮ ਇੱਕ ਜਾਇਜ਼ ਜਾਪਦੀ ਤੈਨਾਤੀ ਯੋਜਨਾ ਨੂੰ ਆਉਟਪੁੱਟ ਕਰੇਗਾ:

Terraform will perform the following actions:

   # aws_iam_user.existing_user will be created
   + resource "aws_iam_user" "existing_user" {
         + arn                  = (known after apply)
         + force_destroy   = false
         + id                    = (known after apply)
         + name               = "yevgeniy.brikman"
         + path                 = "/"
         + unique_id         = (known after apply)
      }

Plan: 1 to add, 0 to change, 0 to destroy.

ਜੇਕਰ ਤੁਸੀਂ ਅਪਲਾਈ ਕਮਾਂਡ ਚਲਾਉਂਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ ਹੇਠ ਲਿਖੀ ਗਲਤੀ ਮਿਲੇਗੀ:

Error: Error creating IAM User yevgeniy.brikman: EntityAlreadyExists:
User with name yevgeniy.brikman already exists.

   on main.tf line 10, in resource "aws_iam_user" "existing_user":
   10: resource "aws_iam_user" "existing_user" {

ਸਮੱਸਿਆ, ਬੇਸ਼ਕ, ਇਹ ਹੈ ਕਿ ਉਸ ਨਾਮ ਵਾਲਾ ਇੱਕ IAM ਉਪਭੋਗਤਾ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੈ। ਅਤੇ ਇਹ ਨਾ ਸਿਰਫ਼ IAM ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਲਗਭਗ ਕਿਸੇ ਵੀ ਸਰੋਤ ਨਾਲ ਹੋ ਸਕਦਾ ਹੈ. ਇਹ ਸੰਭਵ ਹੈ ਕਿ ਕਿਸੇ ਨੇ ਇਸ ਸਰੋਤ ਨੂੰ ਹੱਥੀਂ ਬਣਾਇਆ ਹੋਵੇ ਜਾਂ ਕਮਾਂਡ ਲਾਈਨ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਹੋਵੇ, ਪਰ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ, ਮੇਲ ਖਾਂਦੀਆਂ ਆਈਡੀਜ਼ ਵਿਵਾਦਾਂ ਵੱਲ ਲੈ ਜਾਂਦੀਆਂ ਹਨ। ਇਸ ਗਲਤੀ ਦੀਆਂ ਬਹੁਤ ਸਾਰੀਆਂ ਭਿੰਨਤਾਵਾਂ ਹਨ ਜੋ ਅਕਸਰ ਟੈਰਾਫਾਰਮ ਵਿੱਚ ਨਵੇਂ ਆਉਣ ਵਾਲਿਆਂ ਨੂੰ ਹੈਰਾਨੀ ਨਾਲ ਫੜਦੀਆਂ ਹਨ।

ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਟੈਰਾਫਾਰਮ ਪਲਾਨ ਕਮਾਂਡ ਸਿਰਫ ਉਹਨਾਂ ਸਰੋਤਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੀ ਹੈ ਜੋ ਟੈਰਾਫਾਰਮ ਸਟੇਟ ਫਾਈਲ ਵਿੱਚ ਦਰਸਾਏ ਗਏ ਹਨ। ਜੇਕਰ ਸਰੋਤ ਕਿਸੇ ਹੋਰ ਤਰੀਕੇ ਨਾਲ ਬਣਾਏ ਗਏ ਹਨ (ਉਦਾਹਰਨ ਲਈ, AWS ਕੰਸੋਲ ਵਿੱਚ ਹੱਥੀਂ ਕਲਿੱਕ ਕਰਕੇ), ਉਹ ਸਟੇਟ ਫਾਈਲ ਵਿੱਚ ਖਤਮ ਨਹੀਂ ਹੋਣਗੇ ਅਤੇ ਇਸਲਈ ਪਲਾਨ ਕਮਾਂਡ ਨੂੰ ਚਲਾਉਣ ਵੇਲੇ ਟੈਰਾਫਾਰਮ ਉਹਨਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਨਹੀਂ ਰੱਖੇਗਾ। ਨਤੀਜੇ ਵਜੋਂ, ਇੱਕ ਯੋਜਨਾ ਜੋ ਪਹਿਲੀ ਨਜ਼ਰ ਵਿੱਚ ਸਹੀ ਜਾਪਦੀ ਹੈ, ਅਸਫਲ ਹੋ ਜਾਵੇਗੀ।

ਇਸ ਤੋਂ ਦੋ ਸਬਕ ਸਿੱਖਣ ਲਈ ਹਨ।

• ਜੇਕਰ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ Terraform ਨਾਲ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ ਹੈ, ਤਾਂ ਹੋਰ ਕਿਸੇ ਚੀਜ਼ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ। ਜੇਕਰ ਤੁਹਾਡੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਹਿੱਸੇ ਨੂੰ Terraform ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਬੰਧਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਹੁਣ ਇਸਨੂੰ ਹੱਥੀਂ ਨਹੀਂ ਬਦਲ ਸਕਦੇ ਹੋ। ਨਹੀਂ ਤਾਂ, ਤੁਸੀਂ ਨਾ ਸਿਰਫ ਅਜੀਬ ਟੈਰਾਫਾਰਮ ਗਲਤੀਆਂ ਨੂੰ ਖਤਰੇ ਵਿੱਚ ਪਾਉਂਦੇ ਹੋ, ਸਗੋਂ ਤੁਸੀਂ IaC ਦੇ ਬਹੁਤ ਸਾਰੇ ਲਾਭਾਂ ਨੂੰ ਵੀ ਨਕਾਰਦੇ ਹੋ ਕਿਉਂਕਿ ਕੋਡ ਹੁਣ ਤੁਹਾਡੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਸਹੀ ਪ੍ਰਤੀਨਿਧਤਾ ਨਹੀਂ ਕਰੇਗਾ।
• ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਕੁਝ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਹੈ, ਤਾਂ ਆਯਾਤ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਜੇਕਰ ਤੁਸੀਂ ਮੌਜੂਦਾ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਨਾਲ ਟੈਰਾਫਾਰਮ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਟੈਰਾਫਾਰਮ ਆਯਾਤ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸਨੂੰ ਸਟੇਟ ਫਾਈਲ ਵਿੱਚ ਜੋੜ ਸਕਦੇ ਹੋ। ਇਸ ਤਰ੍ਹਾਂ ਟੈਰਾਫਾਰਮ ਨੂੰ ਪਤਾ ਲੱਗ ਜਾਵੇਗਾ ਕਿ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਇੰਪੋਰਟ ਕਮਾਂਡ ਦੋ ਆਰਗੂਮੈਂਟ ਲੈਂਦੀ ਹੈ। ਪਹਿਲੀ ਤੁਹਾਡੀ ਸੰਰਚਨਾ ਫਾਇਲ ਵਿੱਚ ਸਰੋਤ ਪਤਾ ਹੈ. ਇੱਥੇ ਸੰਟੈਕਸ ਸਰੋਤ ਲਿੰਕਾਂ ਦੇ ਸਮਾਨ ਹੈ: _. (ਜਿਵੇਂ aws_iam_user.existing_user)। ਦੂਜੀ ਦਲੀਲ ਆਯਾਤ ਕੀਤੇ ਜਾਣ ਵਾਲੇ ਸਰੋਤ ਦੀ ID ਹੈ। ਮੰਨ ਲਓ ਕਿ ਸਰੋਤ ID aws_iam_user ਉਪਭੋਗਤਾ ਨਾਮ ਹੈ (ਉਦਾਹਰਨ ਲਈ, yevgeniy.brikman), ਅਤੇ ਸਰੋਤ ID aws_instance EC2 ਸਰਵਰ ID ਹੈ (ਜਿਵੇਂ i-190e22e5)। ਇੱਕ ਸਰੋਤ ਨੂੰ ਕਿਵੇਂ ਆਯਾਤ ਕਰਨਾ ਹੈ ਆਮ ਤੌਰ 'ਤੇ ਇਸਦੇ ਪੰਨੇ ਦੇ ਹੇਠਾਂ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਦਰਸਾਇਆ ਗਿਆ ਹੈ।

  ਹੇਠਾਂ ਇੱਕ ਆਯਾਤ ਕਮਾਂਡ ਹੈ ਜੋ aws_iam_user ਸਰੋਤ ਨੂੰ ਸਿੰਕ੍ਰੋਨਾਈਜ਼ ਕਰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਅਧਿਆਇ 2 ਵਿੱਚ IAM ਉਪਭੋਗਤਾ ਦੇ ਨਾਲ ਤੁਹਾਡੀ Terraform ਸੰਰਚਨਾ ਵਿੱਚ ਜੋੜਿਆ ਹੈ (ਬੇਸ਼ਕ, ਤੁਹਾਡੇ ਨਾਮ ਨੂੰ yevgeniy.brikman ਲਈ ਬਦਲਣਾ):

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Terraform ਤੁਹਾਡੇ IAM ਉਪਭੋਗਤਾ ਨੂੰ ਲੱਭਣ ਲਈ AWS API ਨੂੰ ਕਾਲ ਕਰੇਗਾ ਅਤੇ ਤੁਹਾਡੀ Terraform ਸੰਰਚਨਾ ਵਿੱਚ ਇਸ ਅਤੇ aws_iam_user.existing_user ਸਰੋਤ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਸਟੇਟ ਫਾਈਲ ਐਸੋਸੀਏਸ਼ਨ ਬਣਾਏਗਾ। ਹੁਣ ਤੋਂ, ਜਦੋਂ ਤੁਸੀਂ ਯੋਜਨਾ ਕਮਾਂਡ ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਟੈਰਾਫਾਰਮ ਨੂੰ ਪਤਾ ਲੱਗ ਜਾਵੇਗਾ ਕਿ IAM ਉਪਭੋਗਤਾ ਪਹਿਲਾਂ ਤੋਂ ਮੌਜੂਦ ਹੈ ਅਤੇ ਇਸਨੂੰ ਦੁਬਾਰਾ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰੇਗਾ।

  ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਬਹੁਤ ਸਾਰੇ ਸਰੋਤ ਹਨ ਜੋ ਤੁਸੀਂ ਟੈਰਾਫਾਰਮ ਵਿੱਚ ਆਯਾਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਹੱਥੀਂ ਕੋਡ ਲਿਖਣਾ ਅਤੇ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਹਰ ਇੱਕ ਨੂੰ ਆਯਾਤ ਕਰਨਾ ਇੱਕ ਮੁਸ਼ਕਲ ਹੋ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ ਇਹ ਟੈਰਾਫਾਰਮਿੰਗ (http://terraforming.dtan4.net/) ਵਰਗੇ ਟੂਲ ਨੂੰ ਦੇਖਣ ਦੇ ਯੋਗ ਹੈ, ਜੋ ਤੁਹਾਡੇ AWS ਖਾਤੇ ਤੋਂ ਆਪਣੇ ਆਪ ਕੋਡ ਅਤੇ ਸਟੇਟ ਨੂੰ ਆਯਾਤ ਕਰ ਸਕਦਾ ਹੈ।

  ਰੀਫੈਕਟਰਿੰਗ ਦੇ ਇਸ ਦੇ ਨੁਕਸਾਨ ਹੋ ਸਕਦੇ ਹਨ

  ਰੀਫੈਕਟਰਿੰਗ ਪ੍ਰੋਗਰਾਮਿੰਗ ਵਿੱਚ ਇੱਕ ਆਮ ਅਭਿਆਸ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਕੋਡ ਦੀ ਅੰਦਰੂਨੀ ਬਣਤਰ ਨੂੰ ਬਦਲਦੇ ਹੋ ਜਦੋਂ ਕਿ ਬਾਹਰੀ ਵਿਵਹਾਰ ਨੂੰ ਬਦਲਿਆ ਨਹੀਂ ਜਾਂਦਾ ਹੈ। ਇਹ ਕੋਡ ਨੂੰ ਸਾਫ਼, ਸਾਫ਼, ਅਤੇ ਬਣਾਈ ਰੱਖਣ ਲਈ ਆਸਾਨ ਬਣਾਉਣ ਲਈ ਹੈ। ਰੀਫੈਕਟਰਿੰਗ ਇੱਕ ਲਾਜ਼ਮੀ ਤਕਨੀਕ ਹੈ ਜੋ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਵਰਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਪਰ ਜਦੋਂ ਟੈਰਾਫਾਰਮ ਜਾਂ ਕਿਸੇ ਹੋਰ IaC ਟੂਲ ਦੀ ਗੱਲ ਆਉਂਦੀ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਕੋਡ ਦੇ ਟੁਕੜੇ ਦੇ "ਬਾਹਰੀ ਵਿਵਹਾਰ" ਤੋਂ ਤੁਹਾਡਾ ਕੀ ਮਤਲਬ ਹੈ, ਇਸ ਬਾਰੇ ਬਹੁਤ ਧਿਆਨ ਰੱਖਣਾ ਹੋਵੇਗਾ, ਨਹੀਂ ਤਾਂ ਅਚਾਨਕ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੋਣਗੀਆਂ।

  ਉਦਾਹਰਨ ਲਈ, ਰੀਫੈਕਟਰਿੰਗ ਦੀ ਇੱਕ ਆਮ ਕਿਸਮ ਵੇਰੀਏਬਲਾਂ ਜਾਂ ਫੰਕਸ਼ਨਾਂ ਦੇ ਨਾਵਾਂ ਨੂੰ ਵਧੇਰੇ ਸਮਝਣ ਯੋਗ ਲੋਕਾਂ ਨਾਲ ਬਦਲ ਰਹੀ ਹੈ। ਬਹੁਤ ਸਾਰੇ IDEs ਕੋਲ ਰੀਫੈਕਟਰਿੰਗ ਲਈ ਬਿਲਟ-ਇਨ ਸਮਰਥਨ ਹੁੰਦਾ ਹੈ ਅਤੇ ਪੂਰੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਵੇਰੀਏਬਲਾਂ ਅਤੇ ਫੰਕਸ਼ਨਾਂ ਦਾ ਆਪਣੇ ਆਪ ਨਾਮ ਬਦਲ ਸਕਦਾ ਹੈ। ਆਮ-ਉਦੇਸ਼ ਵਾਲੀਆਂ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ, ਇਹ ਇੱਕ ਮਾਮੂਲੀ ਪ੍ਰਕਿਰਿਆ ਹੈ ਜਿਸ ਬਾਰੇ ਤੁਸੀਂ ਸ਼ਾਇਦ ਨਾ ਸੋਚੋ, ਪਰ ਟੇਰਾਫਾਰਮ ਵਿੱਚ ਤੁਹਾਨੂੰ ਇਸ ਨਾਲ ਬਹੁਤ ਸਾਵਧਾਨ ਰਹਿਣਾ ਪਵੇਗਾ, ਨਹੀਂ ਤਾਂ ਤੁਹਾਨੂੰ ਆਊਟੇਜ ਦਾ ਅਨੁਭਵ ਹੋ ਸਕਦਾ ਹੈ।

  ਉਦਾਹਰਨ ਲਈ, ਵੈਬਸਰਵਰ-ਕਲੱਸਟਰ ਮੋਡੀਊਲ ਵਿੱਚ ਇੱਕ ਇਨਪੁਟ ਵੇਰੀਏਬਲ cluster_name ਹੈ:

  variable "cluster_name" {
     description = "The name to use for all the cluster resources"
     type          = string
  }

  ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਸੀਂ ਇਸ ਮੋਡੀਊਲ ਦੀ ਵਰਤੋਂ foo ਨਾਮਕ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਸ਼ੁਰੂ ਕੀਤੀ ਹੈ। ਬਾਅਦ ਵਿੱਚ, ਤੁਸੀਂ ਆਪਣੀ ਸੇਵਾ ਦਾ ਨਾਮ ਬਦਲ ਕੇ ਬਾਰ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਇਹ ਤਬਦੀਲੀ ਮਾਮੂਲੀ ਲੱਗ ਸਕਦੀ ਹੈ, ਪਰ ਅਸਲ ਵਿੱਚ ਇਹ ਸੇਵਾ ਵਿੱਚ ਵਿਘਨ ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ।

  ਤੱਥ ਇਹ ਹੈ ਕਿ ਵੈਬਸਰਵਰ-ਕਲੱਸਟਰ ਮੋਡੀਊਲ ਕਈ ਸਰੋਤਾਂ ਵਿੱਚ cluster_name ਵੇਰੀਏਬਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਦੋ ਸੁਰੱਖਿਆ ਸਮੂਹਾਂ ਦੇ ਨਾਮ ਪੈਰਾਮੀਟਰ ਅਤੇ ALB ਸ਼ਾਮਲ ਹਨ:

  resource "aws_lb" "example" {
     name                    = var.cluster_name
     load_balancer_type = "application"
     subnets = data.aws_subnet_ids.default.ids
     security_groups      = [aws_security_group.alb.id]
  }

  ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਸਰੋਤ 'ਤੇ ਨਾਮ ਪੈਰਾਮੀਟਰ ਬਦਲਦੇ ਹੋ, ਤਾਂ ਟੈਰਾਫਾਰਮ ਉਸ ਸਰੋਤ ਦੇ ਪੁਰਾਣੇ ਸੰਸਕਰਣ ਨੂੰ ਮਿਟਾ ਦੇਵੇਗਾ ਅਤੇ ਇਸਦੀ ਥਾਂ 'ਤੇ ਇੱਕ ਨਵਾਂ ਬਣਾ ਦੇਵੇਗਾ। ਪਰ ਜੇਕਰ ਉਹ ਸਰੋਤ ਇੱਕ ALB ਹੈ, ਤਾਂ ਇਸਨੂੰ ਮਿਟਾਉਣ ਅਤੇ ਇੱਕ ਨਵਾਂ ਸੰਸਕਰਣ ਡਾਉਨਲੋਡ ਕਰਨ ਦੇ ਵਿਚਕਾਰ, ਤੁਹਾਡੇ ਕੋਲ ਤੁਹਾਡੇ ਵੈਬ ਸਰਵਰ ਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੀਡਾਇਰੈਕਟ ਕਰਨ ਲਈ ਕੋਈ ਵਿਧੀ ਨਹੀਂ ਹੋਵੇਗੀ। ਇਸੇ ਤਰ੍ਹਾਂ, ਜੇਕਰ ਇੱਕ ਸੁਰੱਖਿਆ ਸਮੂਹ ਨੂੰ ਮਿਟਾਇਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਸਰਵਰ ਕਿਸੇ ਵੀ ਨੈੱਟਵਰਕ ਟ੍ਰੈਫਿਕ ਨੂੰ ਉਦੋਂ ਤੱਕ ਰੱਦ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦੇਣਗੇ ਜਦੋਂ ਤੱਕ ਇੱਕ ਨਵਾਂ ਸਮੂਹ ਨਹੀਂ ਬਣ ਜਾਂਦਾ।

  ਇੱਕ ਹੋਰ ਕਿਸਮ ਦੀ ਰੀਫੈਕਟਰਿੰਗ ਜਿਸ ਵਿੱਚ ਤੁਹਾਡੀ ਦਿਲਚਸਪੀ ਹੋ ਸਕਦੀ ਹੈ ਟੈਰਾਫਾਰਮ ਆਈਡੀ ਨੂੰ ਬਦਲਣਾ। ਆਉ ਇੱਕ ਉਦਾਹਰਣ ਵਜੋਂ ਵੈਬਸਰਵਰ-ਕਲੱਸਟਰ ਮੋਡੀਊਲ ਵਿੱਚ aws_security_group ਸਰੋਤ ਲੈਂਦੇ ਹਾਂ:

  resource "aws_security_group" "instance" {
    # (...)
  }

  ਇਸ ਸਰੋਤ ਦੇ ਪਛਾਣਕਰਤਾ ਨੂੰ ਉਦਾਹਰਨ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਕਲਪਨਾ ਕਰੋ ਕਿ ਰੀਫੈਕਟਰਿੰਗ ਦੇ ਦੌਰਾਨ ਤੁਸੀਂ ਇਸਨੂੰ ਵਧੇਰੇ ਸਮਝਣ ਯੋਗ (ਤੁਹਾਡੀ ਰਾਏ ਵਿੱਚ) ਨਾਮ ਕਲੱਸਟਰ_ਇਨਸਟੈਂਸ ਵਿੱਚ ਬਦਲਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ:

  resource "aws_security_group" "cluster_instance" {
     # (...)
  }

  ਅੰਤ ਵਿੱਚ ਕੀ ਹੋਵੇਗਾ? ਇਹ ਸਹੀ ਹੈ: ਇੱਕ ਰੁਕਾਵਟ।

  ਟੈਰਾਫਾਰਮ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ ID ਨਾਲ ਹਰੇਕ ਸਰੋਤ ID ਨੂੰ ਜੋੜਦਾ ਹੈ। ਉਦਾਹਰਨ ਲਈ, iam_user AWS IAM ਉਪਭੋਗਤਾ ID ਨਾਲ ਸਬੰਧਿਤ ਹੈ, ਅਤੇ aws_instance AWS EC2 ਸਰਵਰ ID ਨਾਲ ਸਬੰਧਿਤ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਸਰੋਤ ID ਨੂੰ ਬਦਲਦੇ ਹੋ (ਉਦਾਹਰਨ ਤੋਂ cluster_instance, ਜਿਵੇਂ ਕਿ aws_security_group ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਹੈ), ਟੈਰਾਫਾਰਮ ਵਿੱਚ ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗਾ ਜਿਵੇਂ ਤੁਸੀਂ ਪੁਰਾਣੇ ਸਰੋਤ ਨੂੰ ਮਿਟਾ ਦਿੱਤਾ ਹੈ ਅਤੇ ਇੱਕ ਨਵਾਂ ਜੋੜਿਆ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇਹਨਾਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਲਾਗੂ ਕਰਦੇ ਹੋ, ਤਾਂ ਟੈਰਾਫਾਰਮ ਪੁਰਾਣੇ ਸੁਰੱਖਿਆ ਸਮੂਹ ਨੂੰ ਮਿਟਾ ਦੇਵੇਗਾ ਅਤੇ ਇੱਕ ਨਵਾਂ ਬਣਾ ਦੇਵੇਗਾ, ਜਦੋਂ ਕਿ ਤੁਹਾਡੇ ਸਰਵਰ ਕਿਸੇ ਵੀ ਨੈੱਟਵਰਕ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੱਦ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਨ।

  ਇੱਥੇ ਚਾਰ ਮੁੱਖ ਸਬਕ ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਇਸ ਚਰਚਾ ਤੋਂ ਦੂਰ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ।

  • ਹਮੇਸ਼ਾ ਯੋਜਨਾ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਇਹ ਇਹਨਾਂ ਸਾਰੀਆਂ ਖੋਖਲੀਆਂ ​​ਗੱਲਾਂ ਨੂੰ ਉਜਾਗਰ ਕਰ ਸਕਦਾ ਹੈ। ਇਸਦੇ ਆਉਟਪੁੱਟ ਦੀ ਸਾਵਧਾਨੀ ਨਾਲ ਸਮੀਖਿਆ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਸਥਿਤੀਆਂ ਵੱਲ ਧਿਆਨ ਦਿਓ ਜਿੱਥੇ ਟੈਰਾਫਾਰਮ ਉਹਨਾਂ ਸਰੋਤਾਂ ਨੂੰ ਮਿਟਾਉਣ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦਾ ਹੈ ਜਿਹਨਾਂ ਨੂੰ ਮਿਟਾਇਆ ਨਹੀਂ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
  • ਮਿਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਬਣਾਓ। ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਸਰੋਤ ਨੂੰ ਬਦਲਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਇਸ ਬਾਰੇ ਧਿਆਨ ਨਾਲ ਸੋਚੋ ਕਿ ਕੀ ਤੁਹਾਨੂੰ ਅਸਲੀ ਨੂੰ ਮਿਟਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਰਿਪਲੇਸਮੈਂਟ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਜੇਕਰ ਜਵਾਬ ਹਾਂ ਹੈ, ਤਾਂ create_before_destroy ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ। ਉਹੀ ਨਤੀਜਾ ਦੋ ਕਦਮਾਂ ਨੂੰ ਚਲਾ ਕੇ ਹੱਥੀਂ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: ਪਹਿਲਾਂ ਸੰਰਚਨਾ ਵਿੱਚ ਇੱਕ ਨਵਾਂ ਸਰੋਤ ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ ਲਾਗੂ ਕਮਾਂਡ ਚਲਾਓ, ਅਤੇ ਫਿਰ ਸੰਰਚਨਾ ਤੋਂ ਪੁਰਾਣੇ ਸਰੋਤ ਨੂੰ ਹਟਾਓ ਅਤੇ ਲਾਗੂ ਕਮਾਂਡ ਦੀ ਦੁਬਾਰਾ ਵਰਤੋਂ ਕਰੋ।
  • ਪਛਾਣਕਰਤਾਵਾਂ ਨੂੰ ਬਦਲਣ ਲਈ ਸਥਿਤੀ ਬਦਲਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਕਿਸੇ ਸਰੋਤ ਨਾਲ ਸੰਬੰਧਿਤ ਆਈਡੀ ਨੂੰ ਬਦਲਣਾ ਚਾਹੁੰਦੇ ਹੋ (ਉਦਾਹਰਨ ਲਈ, aws_security_group ਦਾ ਨਾਮ ਬਦਲੋ instance ਤੋਂ cluster_instance) ਤਾਂ ਸਰੋਤ ਨੂੰ ਮਿਟਾਏ ਅਤੇ ਇਸਦਾ ਨਵਾਂ ਸੰਸਕਰਣ ਬਣਾਏ ਬਿਨਾਂ, ਤੁਹਾਨੂੰ ਉਸ ਅਨੁਸਾਰ ਟੈਰਾਫਾਰਮ ਸਟੇਟ ਫਾਈਲ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਸਨੂੰ ਕਦੇ ਵੀ ਹੱਥੀਂ ਨਾ ਕਰੋ - ਇਸਦੀ ਬਜਾਏ ਟੈਰਾਫਾਰਮ ਸਟੇਟ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਪਛਾਣਕਰਤਾਵਾਂ ਦਾ ਨਾਮ ਬਦਲਣ ਵੇਲੇ, ਤੁਹਾਨੂੰ ਟੈਰਾਫਾਰਮ ਸਟੇਟ mv ਕਮਾਂਡ ਚਲਾਉਣੀ ਚਾਹੀਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਹੇਠ ਲਿਖੇ ਸੰਟੈਕਸ ਹਨ:

    terraform state mv <ORIGINAL_REFERENCE> <NEW_REFERENCE>

    ORIGINAL_REFERENCE ਇੱਕ ਸਮੀਕਰਨ ਹੈ ਜੋ ਸਰੋਤ ਨੂੰ ਇਸਦੇ ਮੌਜੂਦਾ ਰੂਪ ਵਿੱਚ ਦਰਸਾਉਂਦਾ ਹੈ, ਅਤੇ NEW_REFERENCE ਉਹ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਇਸਨੂੰ ਤਬਦੀਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ। ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ aws_security_group ਗਰੁੱਪ ਦਾ ਨਾਮ ਬਦਲ ਕੇ instance ਤੋਂ cluster_instance ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਹੇਠ ਲਿਖੀ ਕਮਾਂਡ ਚਲਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ:

    $ terraform state mv 
       aws_security_group.instance 
       aws_security_group.cluster_instance

    ਇਹ ਟੈਰਾਫਾਰਮ ਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਰਾਜ ਜੋ ਪਹਿਲਾਂ aws_security_group.instance ਨਾਲ ਜੁੜਿਆ ਹੋਇਆ ਸੀ ਹੁਣ aws_security_group.cluster_instance ਨਾਲ ਜੁੜਿਆ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਇਸ ਕਮਾਂਡ ਦਾ ਨਾਂ ਬਦਲਣ ਅਤੇ ਚਲਾਉਣ ਤੋਂ ਬਾਅਦ ਟੈਰਾਫਾਰਮ ਪਲਾਨ ਕੋਈ ਬਦਲਾਅ ਨਹੀਂ ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਭ ਕੁਝ ਠੀਕ ਕੀਤਾ ਹੈ।

  • ਕੁਝ ਸੈਟਿੰਗਾਂ ਬਦਲੀਆਂ ਨਹੀਂ ਜਾ ਸਕਦੀਆਂ। ਬਹੁਤ ਸਾਰੇ ਸਰੋਤਾਂ ਦੇ ਮਾਪਦੰਡ ਬਦਲੇ ਨਹੀਂ ਜਾ ਸਕਦੇ ਹਨ। ਜੇਕਰ ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਬਦਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ, ਤਾਂ ਟੈਰਾਫਾਰਮ ਪੁਰਾਣੇ ਸਰੋਤ ਨੂੰ ਮਿਟਾ ਦੇਵੇਗਾ ਅਤੇ ਇਸਦੀ ਥਾਂ ਇੱਕ ਨਵਾਂ ਬਣਾ ਦੇਵੇਗਾ। ਹਰੇਕ ਸਰੋਤ ਪੰਨਾ ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਦਰਸਾਏਗਾ ਕਿ ਜਦੋਂ ਤੁਸੀਂ ਕਿਸੇ ਖਾਸ ਸੈਟਿੰਗ ਨੂੰ ਬਦਲਦੇ ਹੋ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਜਾਂਚ ਕਰਨਾ ਯਕੀਨੀ ਬਣਾਓ। ਹਮੇਸ਼ਾ ਯੋਜਨਾ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰੋ ਅਤੇ create_before_destroy ਰਣਨੀਤੀ ਦੀ ਵਰਤੋਂ ਕਰਨ 'ਤੇ ਵਿਚਾਰ ਕਰੋ।

  ਮੁਲਤਵੀ ਇਕਸਾਰਤਾ ਇਕਸਾਰ ਹੁੰਦੀ ਹੈ... ਮੁਲਤਵੀ ਦੇ ਨਾਲ

  ਕੁਝ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾਵਾਂ ਦੇ API, ਜਿਵੇਂ ਕਿ AWS, ਅਸਿੰਕਰੋਨਸ ਹੁੰਦੇ ਹਨ ਅਤੇ ਇੱਕਸਾਰਤਾ ਵਿੱਚ ਦੇਰੀ ਕਰਦੇ ਹਨ। ਅਸਿੰਕ੍ਰੋਨੀ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੰਟਰਫੇਸ ਬੇਨਤੀ ਕੀਤੀ ਕਾਰਵਾਈ ਦੇ ਪੂਰਾ ਹੋਣ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ ਤੁਰੰਤ ਜਵਾਬ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ। ਦੇਰੀ ਨਾਲ ਇਕਸਾਰਤਾ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤਬਦੀਲੀਆਂ ਨੂੰ ਪੂਰੇ ਸਿਸਟਮ ਵਿੱਚ ਫੈਲਣ ਵਿੱਚ ਸਮਾਂ ਲੱਗ ਸਕਦਾ ਹੈ; ਜਦੋਂ ਇਹ ਹੋ ਰਿਹਾ ਹੈ, ਤੁਹਾਡੇ ਜਵਾਬ ਅਸੰਗਤ ਹੋ ਸਕਦੇ ਹਨ ਅਤੇ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਹੋ ਸਕਦੇ ਹਨ ਕਿ ਕਿਹੜਾ ਡੇਟਾ ਸਰੋਤ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਤੁਹਾਡੀ API ਕਾਲਾਂ ਦਾ ਜਵਾਬ ਦੇ ਰਹੀ ਹੈ।

  ਉਦਾਹਰਨ ਲਈ, ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਸੀਂ AWS ਨੂੰ ਇੱਕ EC2 ਸਰਵਰ ਬਣਾਉਣ ਲਈ ਇੱਕ API ਕਾਲ ਕਰਦੇ ਹੋ। ਏਪੀਆਈ ਸਰਵਰ ਦੇ ਬਣਾਏ ਜਾਣ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ, ਲਗਭਗ ਤੁਰੰਤ ਇੱਕ "ਸਫਲ" ਜਵਾਬ (201 ਬਣਾਇਆ ਗਿਆ) ਵਾਪਸ ਕਰੇਗਾ। ਜੇਕਰ ਤੁਸੀਂ ਤੁਰੰਤ ਇਸ ਨਾਲ ਜੁੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਲਗਭਗ ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਅਸਫਲ ਹੋ ਜਾਵੇਗਾ ਕਿਉਂਕਿ ਉਸ ਸਮੇਂ AWS ਅਜੇ ਵੀ ਸਰੋਤਾਂ ਦੀ ਸ਼ੁਰੂਆਤ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ, ਵਿਕਲਪਕ ਤੌਰ 'ਤੇ, ਸਰਵਰ ਅਜੇ ਬੂਟ ਨਹੀਂ ਹੋਇਆ ਹੈ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਸਰਵਰ ਬਾਰੇ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਇੱਕ ਹੋਰ ਕਾਲ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ ਗਲਤੀ (404 ਨਹੀਂ ਮਿਲੀ) ਪ੍ਰਾਪਤ ਹੋ ਸਕਦੀ ਹੈ। ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਸ EC2 ਸਰਵਰ ਬਾਰੇ ਜਾਣਕਾਰੀ ਅਜੇ ਵੀ AWS ਵਿੱਚ ਹਰ ਜਗ੍ਹਾ ਉਪਲਬਧ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਫੈਲਾਈ ਜਾ ਸਕਦੀ ਹੈ, ਤੁਹਾਨੂੰ ਕੁਝ ਸਕਿੰਟ ਉਡੀਕ ਕਰਨੀ ਪਵੇਗੀ।

  ਜਦੋਂ ਵੀ ਤੁਸੀਂ ਆਲਸੀ ਇਕਸਾਰਤਾ ਦੇ ਨਾਲ ਇੱਕ ਅਸਿੰਕਰੋਨਸ API ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਆਪਣੀ ਬੇਨਤੀ ਨੂੰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ ਜਦੋਂ ਤੱਕ ਕਾਰਵਾਈ ਪੂਰੀ ਨਹੀਂ ਹੋ ਜਾਂਦੀ ਅਤੇ ਸਿਸਟਮ ਦੁਆਰਾ ਪ੍ਰਸਾਰਿਤ ਨਹੀਂ ਹੁੰਦੀ ਹੈ। ਬਦਕਿਸਮਤੀ ਨਾਲ, AWS SDK ਇਸਦੇ ਲਈ ਕੋਈ ਵਧੀਆ ਟੂਲ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ ਹੈ, ਅਤੇ Terraform ਪ੍ਰੋਜੈਕਟ 6813 (https://github.com/hashicorp/terraform/issues/6813) ਵਰਗੇ ਬਹੁਤ ਸਾਰੇ ਬੱਗਾਂ ਤੋਂ ਪੀੜਤ ਸੀ:

  $ terraform apply
  aws_subnet.private-persistence.2: InvalidSubnetID.NotFound:
  The subnet ID 'subnet-xxxxxxx' does not exist

  ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਤੁਸੀਂ ਇੱਕ ਸਰੋਤ ਬਣਾਉਂਦੇ ਹੋ (ਜਿਵੇਂ ਇੱਕ ਸਬਨੈੱਟ) ਅਤੇ ਫਿਰ ਇਸ ਬਾਰੇ ਕੁਝ ਜਾਣਕਾਰੀ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ (ਜਿਵੇਂ ਕਿ ਨਵੇਂ ਬਣੇ ਸਬਨੈੱਟ ਦੀ ID), ਅਤੇ ਟੈਰਾਫਾਰਮ ਇਸਨੂੰ ਨਹੀਂ ਲੱਭ ਸਕਦਾ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਬਹੁਤੇ ਬੱਗ (6813 ਸਮੇਤ) ਨੂੰ ਠੀਕ ਕੀਤਾ ਗਿਆ ਹੈ, ਪਰ ਇਹ ਅਜੇ ਵੀ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਪੈਦਾ ਹੁੰਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਟੈਰਾਫਾਰਮ ਇੱਕ ਨਵੇਂ ਸਰੋਤ ਕਿਸਮ ਲਈ ਸਮਰਥਨ ਜੋੜਦਾ ਹੈ। ਇਹ ਤੰਗ ਕਰਨ ਵਾਲਾ ਹੈ, ਪਰ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਕੋਈ ਨੁਕਸਾਨ ਨਹੀਂ ਹੁੰਦਾ. ਜਦੋਂ ਤੁਸੀਂ ਟੈਰਾਫਾਰਮ ਨੂੰ ਦੁਬਾਰਾ ਲਾਗੂ ਕਰਦੇ ਹੋ, ਤਾਂ ਸਭ ਕੁਝ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਇਸ ਸਮੇਂ ਤੱਕ ਜਾਣਕਾਰੀ ਪਹਿਲਾਂ ਹੀ ਪੂਰੇ ਸਿਸਟਮ ਵਿੱਚ ਫੈਲ ਚੁੱਕੀ ਹੋਵੇਗੀ।

  ਇਹ ਅੰਸ਼ Evgeniy Brikman ਦੀ ਕਿਤਾਬ ਵਿੱਚੋਂ ਪੇਸ਼ ਕੀਤਾ ਗਿਆ ਹੈ "ਟੇਰਾਫਾਰਮ: ਕੋਡ ਪੱਧਰ 'ਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚਾ".

ਸਰੋਤ: www.habr.com