ಟೆರಾಫಾರ್ಮ್ ಮೋಸಗಳು

ಲೂಪ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತಹ ಕೆಲವು ಮೋಸಗಳನ್ನು ಹೈಲೈಟ್ ಮಾಡೋಣ, ಹೇಳಿಕೆಗಳು ಮತ್ತು ನಿಯೋಜನೆ ತಂತ್ರಗಳು, ಹಾಗೆಯೇ ಸಾಮಾನ್ಯವಾಗಿ ಟೆರ್ರಾಫಾರ್ಮ್ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವ ಹೆಚ್ಚು ಸಾಮಾನ್ಯ ಸಮಸ್ಯೆಗಳು:

• ಎಣಿಕೆ ಮತ್ತು for_each ನಿಯತಾಂಕಗಳು ಮಿತಿಗಳನ್ನು ಹೊಂದಿವೆ;
• ಶೂನ್ಯ ಅಲಭ್ಯತೆಯ ನಿಯೋಜನೆಗಳನ್ನು ಮಿತಿಗೊಳಿಸಿ;
• ಒಳ್ಳೆಯ ಯೋಜನೆಯೂ ವಿಫಲವಾಗಬಹುದು;
• ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಅದರ ಮೋಸಗಳನ್ನು ಹೊಂದಬಹುದು;
• ಮುಂದೂಡಲ್ಪಟ್ಟ ಸುಸಂಬದ್ಧತೆ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ... ಮುಂದೂಡಿಕೆಯೊಂದಿಗೆ.

ಎಣಿಕೆ ಮತ್ತು for_each ನಿಯತಾಂಕಗಳು ಮಿತಿಗಳನ್ನು ಹೊಂದಿವೆ

ಈ ಅಧ್ಯಾಯದಲ್ಲಿನ ಉದಾಹರಣೆಗಳು ಎಣಿಕೆ ನಿಯತಾಂಕವನ್ನು ವ್ಯಾಪಕವಾಗಿ ಬಳಸುತ್ತವೆ ಮತ್ತು ಲೂಪ್‌ಗಳು ಮತ್ತು ಷರತ್ತುಬದ್ಧ ತರ್ಕದಲ್ಲಿ for_each ಅಭಿವ್ಯಕ್ತಿ. ಅವರು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾರೆ, ಆದರೆ ನೀವು ತಿಳಿದಿರಬೇಕಾದ ಎರಡು ಪ್ರಮುಖ ಮಿತಿಗಳನ್ನು ಅವರು ಹೊಂದಿದ್ದಾರೆ.

• ಎಣಿಕೆ ಮತ್ತು for_each ಯಾವುದೇ ಸಂಪನ್ಮೂಲ ಔಟ್‌ಪುಟ್ ವೇರಿಯೇಬಲ್‌ಗಳನ್ನು ಉಲ್ಲೇಖಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
• ಎಣಿಕೆ ಮತ್ತು for_each ಅನ್ನು ಮಾಡ್ಯೂಲ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಬಳಸಲಾಗುವುದಿಲ್ಲ.

ಎಣಿಕೆ ಮತ್ತು 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.

ಯಾವುದೇ ಸಂಪನ್ಮೂಲಗಳನ್ನು ರಚಿಸುವ ಅಥವಾ ಮಾರ್ಪಡಿಸುವ ಮೊದಲು, ಯೋಜನಾ ಹಂತದಲ್ಲಿ ಎಣಿಕೆ ಮತ್ತು ಫಾರ್_ಎಚ್ ಅನ್ನು ಲೆಕ್ಕಹಾಕಲು Terraform ಅಗತ್ಯವಿದೆ. ಇದರರ್ಥ ಎಣಿಕೆ ಮತ್ತು 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.

ದುರದೃಷ್ಟವಶಾತ್, Terraform 0.12.6 ರಂತೆ, ಮಾಡ್ಯೂಲ್ ಸಂಪನ್ಮೂಲದಲ್ಲಿ ಎಣಿಕೆ ಅಥವಾ for_each ಅನ್ನು ಬಳಸುವುದು ಬೆಂಬಲಿತವಾಗಿಲ್ಲ. Terraform 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 ರಂತೆ, ಹ್ಯಾಶಿಕಾರ್ಪ್ ತಂಡವು ಈ ಕಾರ್ಯವನ್ನು ಸೇರಿಸಲು ಯಾವುದೇ ಯೋಜನೆಯನ್ನು ಹೊಂದಿರಲಿಲ್ಲ (ವಿವರಗಳು - ಇಲ್ಲಿ).

ಸರಿಯಾದ ಯೋಜನೆಯು ವಿಫಲಗೊಳ್ಳಬಹುದು

ಕೆಲವೊಮ್ಮೆ ಯೋಜನೆ ಆಜ್ಞೆಯು ಸಂಪೂರ್ಣವಾಗಿ ಸರಿಯಾದ ನಿಯೋಜನೆ ಯೋಜನೆಯನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ಆದರೆ ಅನ್ವಯಿಸು ಆಜ್ಞೆಯು ದೋಷವನ್ನು ನೀಡುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಅಧ್ಯಾಯ 2 ರಲ್ಲಿ ನೀವು ಮೊದಲು ರಚಿಸಿದ IAM ಬಳಕೆದಾರರಿಗೆ ನೀವು ಬಳಸಿದ ಅದೇ ಹೆಸರಿನೊಂದಿಗೆ aws_iam_user ಸಂಪನ್ಮೂಲವನ್ನು ಸೇರಿಸಲು ಪ್ರಯತ್ನಿಸಿ:

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 ಬಳಕೆದಾರರಿಗೆ ಮಾತ್ರವಲ್ಲ, ಯಾವುದೇ ಸಂಪನ್ಮೂಲಕ್ಕೂ ಸಂಭವಿಸಬಹುದು. ಯಾರಾದರೂ ಈ ಸಂಪನ್ಮೂಲವನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಅಥವಾ ಕಮಾಂಡ್ ಲೈನ್ ಬಳಸಿ ರಚಿಸಿರುವ ಸಾಧ್ಯತೆಯಿದೆ, ಆದರೆ ಎರಡೂ ರೀತಿಯಲ್ಲಿ, ಹೊಂದಾಣಿಕೆಯ ID ಗಳು ಸಂಘರ್ಷಗಳಿಗೆ ಕಾರಣವಾಗುತ್ತದೆ. ಟೆರ್ರಾಫಾರ್ಮ್‌ಗೆ ಹೊಸಬರನ್ನು ಆಶ್ಚರ್ಯದಿಂದ ಸೆಳೆಯುವ ಈ ದೋಷದ ಹಲವು ಮಾರ್ಪಾಡುಗಳಿವೆ.

ಪ್ರಮುಖ ಅಂಶವೆಂದರೆ ಟೆರಾಫಾರ್ಮ್ ಪ್ಲಾನ್ ಆಜ್ಞೆಯು ಟೆರಾಫಾರ್ಮ್ ಸ್ಟೇಟ್ ಫೈಲ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಮಾತ್ರ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ರಚಿಸಿದರೆ (ಉದಾಹರಣೆಗೆ, AWS ಕನ್ಸೋಲ್‌ನಲ್ಲಿ ಹಸ್ತಚಾಲಿತವಾಗಿ ಕ್ಲಿಕ್ ಮಾಡುವ ಮೂಲಕ), ಅವು ರಾಜ್ಯ ಫೈಲ್‌ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುವುದಿಲ್ಲ ಮತ್ತು ಆದ್ದರಿಂದ ಯೋಜನೆ ಆಜ್ಞೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ Terraform ಅವುಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ. ಪರಿಣಾಮವಾಗಿ, ಮೊದಲ ನೋಟದಲ್ಲಿ ಸರಿಯಾಗಿ ತೋರುವ ಯೋಜನೆಯು ವಿಫಲಗೊಳ್ಳುತ್ತದೆ.

ಇದರಿಂದ ಎರಡು ಪಾಠಗಳನ್ನು ಕಲಿಯಬೇಕಿದೆ.

• ನೀವು ಈಗಾಗಲೇ ಟೆರ್ರಾಫಾರ್ಮ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದ್ದರೆ, ಬೇರೆ ಯಾವುದನ್ನೂ ಬಳಸಬೇಡಿ. ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯದ ಭಾಗವನ್ನು ಟೆರಾಫಾರ್ಮ್ ಬಳಸಿ ನಿರ್ವಹಿಸಿದರೆ, ನೀವು ಇನ್ನು ಮುಂದೆ ಅದನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಮಾರ್ಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಇಲ್ಲದಿದ್ದರೆ, ನೀವು ವಿಲಕ್ಷಣವಾದ ಟೆರಾಫಾರ್ಮ್ ದೋಷಗಳನ್ನು ಮಾತ್ರ ಅಪಾಯಕ್ಕೆ ತೆಗೆದುಕೊಳ್ಳುವುದಿಲ್ಲ, ಆದರೆ ಕೋಡ್ ಇನ್ನು ಮುಂದೆ ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯದ ನಿಖರವಾದ ಪ್ರಾತಿನಿಧ್ಯವಾಗದ ಕಾರಣ ನೀವು IaC ಯ ಅನೇಕ ಪ್ರಯೋಜನಗಳನ್ನು ಸಹ ನಿರಾಕರಿಸುತ್ತೀರಿ.
• ನೀವು ಈಗಾಗಲೇ ಕೆಲವು ಮೂಲಸೌಕರ್ಯಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಆಮದು ಆಜ್ಞೆಯನ್ನು ಬಳಸಿ. ನೀವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಮೂಲಸೌಕರ್ಯದೊಂದಿಗೆ ಟೆರ್ರಾಫಾರ್ಮ್ ಅನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದರೆ, ನೀವು ಅದನ್ನು ಟೆರಾಫಾರ್ಮ್ ಆಮದು ಆಜ್ಞೆಯನ್ನು ಬಳಸಿಕೊಂಡು ರಾಜ್ಯ ಫೈಲ್‌ಗೆ ಸೇರಿಸಬಹುದು. ಈ ಮೂಲಕ ಟೆರ್ರಾಫಾರ್ಮ್ ಯಾವ ಮೂಲಸೌಕರ್ಯವನ್ನು ನಿರ್ವಹಿಸಬೇಕು ಎಂದು ತಿಳಿಯುತ್ತದೆ. ಆಮದು ಆಜ್ಞೆಯು ಎರಡು ವಾದಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಮೊದಲನೆಯದು ನಿಮ್ಮ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್‌ಗಳಲ್ಲಿನ ಸಂಪನ್ಮೂಲ ವಿಳಾಸವಾಗಿದೆ. ಇಲ್ಲಿ ಸಿಂಟ್ಯಾಕ್ಸ್ ಸಂಪನ್ಮೂಲ ಲಿಂಕ್‌ಗಳಂತೆಯೇ ಇರುತ್ತದೆ: _. (aws_iam_user.existing_user ನಂತೆ). ಎರಡನೆಯ ಆರ್ಗ್ಯುಮೆಂಟ್ ಆಮದು ಮಾಡಬೇಕಾದ ಸಂಪನ್ಮೂಲದ ID ಆಗಿದೆ. ಸಂಪನ್ಮೂಲ ID aws_iam_user ಬಳಕೆದಾರರ ಹೆಸರು (ಉದಾಹರಣೆಗೆ, yevgeniy.brikman), ಮತ್ತು ಸಂಪನ್ಮೂಲ ID aws_instance EC2 ಸರ್ವರ್ ID (i-190e22e5 ನಂತಹ) ಎಂದು ಹೇಳೋಣ. ಸಂಪನ್ಮೂಲವನ್ನು ಹೇಗೆ ಆಮದು ಮಾಡಿಕೊಳ್ಳುವುದು ಎಂಬುದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಅದರ ಪುಟದ ಕೆಳಭಾಗದಲ್ಲಿರುವ ದಾಖಲಾತಿಯಲ್ಲಿ ಸೂಚಿಸಲಾಗುತ್ತದೆ.

  ಅಧ್ಯಾಯ 2 ರಲ್ಲಿ IAM ಬಳಕೆದಾರರೊಂದಿಗೆ ನಿಮ್ಮ Terraform ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ನೀವು ಸೇರಿಸಿದ aws_iam_user ಸಂಪನ್ಮೂಲವನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುವ ಆಮದು ಆಜ್ಞೆಯನ್ನು ಕೆಳಗೆ ನೀಡಲಾಗಿದೆ (ನಿಮ್ಮ ಹೆಸರನ್ನು yevgeniy.brikman ಗೆ ಬದಲಿಸಿ, ಸಹಜವಾಗಿ):

  $ terraform import aws_iam_user.existing_user yevgeniy.brikman

  Terraform ನಿಮ್ಮ IAM ಬಳಕೆದಾರರನ್ನು ಹುಡುಕಲು AWS API ಗೆ ಕರೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಿಮ್ಮ Terraform ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ aws_iam_user.existing_user ಸಂಪನ್ಮೂಲದ ನಡುವೆ ಸ್ಟೇಟ್ ಫೈಲ್ ಅಸೋಸಿಯೇಷನ್ ​​ಅನ್ನು ರಚಿಸುತ್ತದೆ. ಇಂದಿನಿಂದ, ನೀವು ಯೋಜನೆ ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಿದಾಗ, IAM ಬಳಕೆದಾರರು ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿದ್ದಾರೆ ಮತ್ತು ಅದನ್ನು ಮತ್ತೆ ರಚಿಸಲು ಪ್ರಯತ್ನಿಸುವುದಿಲ್ಲ ಎಂದು Terraform ತಿಳಿಯುತ್ತದೆ.

  ನೀವು ಈಗಾಗಲೇ ಟೆರಾಫಾರ್ಮ್‌ಗೆ ಆಮದು ಮಾಡಿಕೊಳ್ಳಲು ಬಯಸುವ ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಕೋಡ್ ಅನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಬರೆಯುವುದು ಮತ್ತು ಪ್ರತಿಯೊಂದನ್ನು ಆಮದು ಮಾಡಿಕೊಳ್ಳುವುದು ತೊಂದರೆಯಾಗಬಹುದು ಎಂಬುದು ಗಮನಿಸಬೇಕಾದ ಸಂಗತಿ. ಆದ್ದರಿಂದ ನಿಮ್ಮ AWS ಖಾತೆಯಿಂದ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕೋಡ್ ಮತ್ತು ಸ್ಥಿತಿಯನ್ನು ಆಮದು ಮಾಡಿಕೊಳ್ಳಬಹುದಾದ Terraforming (http://terraforming.dtan4.net/) ನಂತಹ ಸಾಧನವನ್ನು ನೋಡುವುದು ಯೋಗ್ಯವಾಗಿದೆ.

  ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಅದರ ಮೋಸಗಳನ್ನು ಹೊಂದಬಹುದು

  ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್‌ನಲ್ಲಿ ಒಂದು ಸಾಮಾನ್ಯ ಅಭ್ಯಾಸವಾಗಿದೆ, ಅಲ್ಲಿ ನೀವು ಬಾಹ್ಯ ನಡವಳಿಕೆಯನ್ನು ಬದಲಾಯಿಸದೆಯೇ ಕೋಡ್‌ನ ಆಂತರಿಕ ರಚನೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತೀರಿ. ಇದು ಕೋಡ್ ಅನ್ನು ಸ್ಪಷ್ಟವಾಗಿ, ಅಚ್ಚುಕಟ್ಟಾಗಿ ಮತ್ತು ನಿರ್ವಹಿಸಲು ಸುಲಭವಾಗಿದೆ. ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಒಂದು ಅನಿವಾರ್ಯ ತಂತ್ರವಾಗಿದ್ದು ಅದನ್ನು ನಿಯಮಿತವಾಗಿ ಬಳಸಬೇಕು. ಆದರೆ ಟೆರಾಫಾರ್ಮ್ ಅಥವಾ ಇತರ ಯಾವುದೇ ಐಎಸಿ ಉಪಕರಣಕ್ಕೆ ಬಂದಾಗ, ಕೋಡ್‌ನ ತುಣುಕಿನ "ಬಾಹ್ಯ ನಡವಳಿಕೆ" ಯಿಂದ ನೀವು ಏನು ಅರ್ಥೈಸುತ್ತೀರಿ ಎಂಬುದರ ಕುರಿತು ನೀವು ಅತ್ಯಂತ ಜಾಗರೂಕರಾಗಿರಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಅನಿರೀಕ್ಷಿತ ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸುತ್ತವೆ.

  ಉದಾಹರಣೆಗೆ, ವೇರಿಯಬಲ್ ಅಥವಾ ಫಂಕ್ಷನ್ ಹೆಸರುಗಳನ್ನು ಹೆಚ್ಚು ಅರ್ಥವಾಗುವಂತಹವುಗಳೊಂದಿಗೆ ಬದಲಾಯಿಸುವುದು ಸಾಮಾನ್ಯ ರೀತಿಯ ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಆಗಿದೆ. ಅನೇಕ IDEಗಳು ರಿಫ್ಯಾಕ್ಟರಿಂಗ್‌ಗೆ ಅಂತರ್ನಿರ್ಮಿತ ಬೆಂಬಲವನ್ನು ಹೊಂದಿವೆ ಮತ್ತು ಯೋಜನೆಯ ಉದ್ದಕ್ಕೂ ವೇರಿಯಬಲ್‌ಗಳು ಮತ್ತು ಕಾರ್ಯಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮರುಹೆಸರಿಸಬಹುದು. ಸಾಮಾನ್ಯ-ಉದ್ದೇಶದ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳಲ್ಲಿ, ಇದು ನೀವು ಯೋಚಿಸದಿರುವ ಕ್ಷುಲ್ಲಕ ವಿಧಾನವಾಗಿದೆ, ಆದರೆ ಟೆರ್ರಾಫಾರ್ಮ್‌ನಲ್ಲಿ ನೀವು ಇದರೊಂದಿಗೆ ಅತ್ಯಂತ ಜಾಗರೂಕರಾಗಿರಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ನೀವು ಅಡಚಣೆಗಳನ್ನು ಅನುಭವಿಸಬಹುದು.

  ಉದಾಹರಣೆಗೆ, ವೆಬ್‌ಸರ್ವರ್-ಕ್ಲಸ್ಟರ್ ಮಾಡ್ಯೂಲ್ ಇನ್‌ಪುಟ್ ವೇರಿಯಬಲ್ cluster_name ಅನ್ನು ಹೊಂದಿದೆ:

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

  foo ಎಂಬ ಮೈಕ್ರೋಸರ್ವಿಸ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ನೀವು ಈ ಮಾಡ್ಯೂಲ್ ಅನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೀರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ನಂತರ, ನಿಮ್ಮ ಸೇವೆಯನ್ನು ಬಾರ್‌ಗೆ ಮರುಹೆಸರಿಸಲು ನೀವು ಬಯಸುತ್ತೀರಿ. ಈ ಬದಲಾವಣೆಯು ಕ್ಷುಲ್ಲಕವೆಂದು ತೋರುತ್ತದೆ, ಆದರೆ ವಾಸ್ತವದಲ್ಲಿ ಇದು ಸೇವೆಯ ಅಡೆತಡೆಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು.

  ಸತ್ಯವೆಂದರೆ ವೆಬ್‌ಸರ್ವರ್-ಕ್ಲಸ್ಟರ್ ಮಾಡ್ಯೂಲ್ ಎರಡು ಭದ್ರತಾ ಗುಂಪುಗಳ ಹೆಸರು ಪ್ಯಾರಾಮೀಟರ್ ಮತ್ತು ALB ಸೇರಿದಂತೆ ಹಲವಾರು ಸಂಪನ್ಮೂಲಗಳಲ್ಲಿ cluster_name ವೇರಿಯೇಬಲ್ ಅನ್ನು ಬಳಸುತ್ತದೆ:

  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]
  }

  ನೀವು ಸಂಪನ್ಮೂಲದಲ್ಲಿ ಹೆಸರಿನ ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಬದಲಾಯಿಸಿದರೆ, ಆ ಸಂಪನ್ಮೂಲದ ಹಳೆಯ ಆವೃತ್ತಿಯನ್ನು Terraform ಅಳಿಸುತ್ತದೆ ಮತ್ತು ಅದರ ಸ್ಥಳದಲ್ಲಿ ಹೊಸದನ್ನು ರಚಿಸುತ್ತದೆ. ಆದರೆ ಆ ಸಂಪನ್ಮೂಲವು ALB ಆಗಿದ್ದರೆ, ಅದನ್ನು ಅಳಿಸುವ ಮತ್ತು ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡುವ ನಡುವೆ, ನಿಮ್ಮ ವೆಬ್ ಸರ್ವರ್‌ಗೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮರುನಿರ್ದೇಶಿಸುವ ಕಾರ್ಯವಿಧಾನವನ್ನು ನೀವು ಹೊಂದಿರುವುದಿಲ್ಲ. ಅಂತೆಯೇ, ಭದ್ರತಾ ಗುಂಪನ್ನು ಅಳಿಸಿದರೆ, ಹೊಸ ಗುಂಪನ್ನು ರಚಿಸುವವರೆಗೆ ನಿಮ್ಮ ಸರ್ವರ್‌ಗಳು ಯಾವುದೇ ನೆಟ್‌ವರ್ಕ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ತಿರಸ್ಕರಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ.

  ಟೆರಾಫಾರ್ಮ್ ಐಡಿಯನ್ನು ಬದಲಾಯಿಸುವುದು ನಿಮಗೆ ಆಸಕ್ತಿಯಿರುವ ಇನ್ನೊಂದು ರೀತಿಯ ರಿಫ್ಯಾಕ್ಟರಿಂಗ್. ವೆಬ್‌ಸರ್ವರ್-ಕ್ಲಸ್ಟರ್ ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿನ aws_security_group ಸಂಪನ್ಮೂಲವನ್ನು ಉದಾಹರಣೆಯಾಗಿ ತೆಗೆದುಕೊಳ್ಳೋಣ:

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

  ಈ ಸಂಪನ್ಮೂಲದ ಗುರುತಿಸುವಿಕೆಯನ್ನು ನಿದರ್ಶನ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ರಿಫ್ಯಾಕ್ಟರಿಂಗ್ ಸಮಯದಲ್ಲಿ ನೀವು ಅದನ್ನು ಹೆಚ್ಚು ಅರ್ಥವಾಗುವ (ನಿಮ್ಮ ಅಭಿಪ್ರಾಯದಲ್ಲಿ) ಹೆಸರು cluster_instance ಗೆ ಬದಲಾಯಿಸಲು ನಿರ್ಧರಿಸಿದ್ದೀರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ:

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

  ಕೊನೆಗೆ ಏನಾಗುತ್ತದೆ? ಅದು ಸರಿ: ಒಂದು ಅಡ್ಡಿ.

  ಟೆರಾಫಾರ್ಮ್ ಪ್ರತಿ ಸಂಪನ್ಮೂಲ ಐಡಿಯನ್ನು ಕ್ಲೌಡ್ ಪ್ರೊವೈಡರ್ ಐಡಿಯೊಂದಿಗೆ ಸಂಯೋಜಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, iam_user ಅನ್ನು AWS IAM ಬಳಕೆದಾರ ID ಯೊಂದಿಗೆ ಸಂಯೋಜಿಸಲಾಗಿದೆ ಮತ್ತು aws_instance AWS EC2 ಸರ್ವರ್ ID ಯೊಂದಿಗೆ ಸಂಯೋಜಿಸಲ್ಪಟ್ಟಿದೆ. ನೀವು ಸಂಪನ್ಮೂಲ ID ಅನ್ನು ಬದಲಾಯಿಸಿದರೆ (ಉದಾಹರಣೆಗೆ cluster_instance ಎಂದು ಹೇಳಿ, aws_security_group ನಲ್ಲಿರುವಂತೆ), Terraform ಗೆ ನೀವು ಹಳೆಯ ಸಂಪನ್ಮೂಲವನ್ನು ಅಳಿಸಿದಂತೆ ಮತ್ತು ಹೊಸದನ್ನು ಸೇರಿಸಿದಂತೆ ಗೋಚರಿಸುತ್ತದೆ. ನೀವು ಈ ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸಿದರೆ, ನಿಮ್ಮ ಸರ್ವರ್‌ಗಳು ಯಾವುದೇ ನೆಟ್‌ವರ್ಕ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ತಿರಸ್ಕರಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಟೆರ್ರಾಫಾರ್ಮ್ ಹಳೆಯ ಭದ್ರತಾ ಗುಂಪನ್ನು ಅಳಿಸುತ್ತದೆ ಮತ್ತು ಹೊಸದನ್ನು ರಚಿಸುತ್ತದೆ.

  ಈ ಚರ್ಚೆಯಿಂದ ನೀವು ತೆಗೆದುಕೊಳ್ಳಬೇಕಾದ ನಾಲ್ಕು ಪ್ರಮುಖ ಪಾಠಗಳು ಇಲ್ಲಿವೆ.

  • ಯಾವಾಗಲೂ ಯೋಜನೆ ಆಜ್ಞೆಯನ್ನು ಬಳಸಿ. ಇದು ಈ ಎಲ್ಲಾ ಸ್ನ್ಯಾಗ್‌ಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸಬಹುದು. ಅದರ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಟೆರ್ರಾಫಾರ್ಮ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಅಳಿಸಲು ಯೋಜಿಸಿರುವ ಸಂದರ್ಭಗಳಿಗೆ ಗಮನ ಕೊಡಿ.
  • ನೀವು ಅಳಿಸುವ ಮೊದಲು ರಚಿಸಿ. ನೀವು ಸಂಪನ್ಮೂಲವನ್ನು ಬದಲಾಯಿಸಲು ಬಯಸಿದರೆ, ಮೂಲವನ್ನು ಅಳಿಸುವ ಮೊದಲು ನೀವು ಬದಲಿಯನ್ನು ರಚಿಸಬೇಕೆ ಎಂದು ಎಚ್ಚರಿಕೆಯಿಂದ ಯೋಚಿಸಿ. ಉತ್ತರ ಹೌದು ಎಂದಾದರೆ, create_before_destroy ಸಹಾಯ ಮಾಡಬಹುದು. ಎರಡು ಹಂತಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಮೂಲಕ ಅದೇ ಫಲಿತಾಂಶವನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಸಾಧಿಸಬಹುದು: ಮೊದಲು ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ಹೊಸ ಸಂಪನ್ಮೂಲವನ್ನು ಸೇರಿಸಿ ಮತ್ತು ಅನ್ವಯಿಸು ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಿ, ತದನಂತರ ಹಳೆಯ ಸಂಪನ್ಮೂಲವನ್ನು ಕಾನ್ಫಿಗರೇಶನ್‌ನಿಂದ ತೆಗೆದುಹಾಕಿ ಮತ್ತು ಅನ್ವಯಿಸು ಆಜ್ಞೆಯನ್ನು ಮತ್ತೆ ಬಳಸಿ.
  • ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ಬದಲಾಯಿಸಲು ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸುವ ಅಗತ್ಯವಿದೆ. ಸಂಪನ್ಮೂಲವನ್ನು ಅಳಿಸದೆ ಮತ್ತು ಅದರ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ರಚಿಸದೆಯೇ (ಉದಾಹರಣೆಗೆ, aws_security_group ಅನ್ನು ಇನ್‌ಸ್ಟಾನ್ಸ್‌ನಿಂದ cluster_instance ಗೆ ಮರುಹೆಸರಿಸಿ) ನೀವು ಸಂಪನ್ಮೂಲದೊಂದಿಗೆ ಸಂಯೋಜಿತವಾಗಿರುವ ID ಅನ್ನು ಬದಲಾಯಿಸಲು ಬಯಸಿದರೆ, ನೀವು ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ Terraform ಸ್ಟೇಟ್ ಫೈಲ್ ಅನ್ನು ನವೀಕರಿಸಬೇಕು. ಇದನ್ನು ಎಂದಿಗೂ ಕೈಯಾರೆ ಮಾಡಬೇಡಿ - ಬದಲಿಗೆ ಟೆರಾಫಾರ್ಮ್ ಸ್ಟೇಟ್ ಆಜ್ಞೆಯನ್ನು ಬಳಸಿ. ಗುರುತಿಸುವಿಕೆಗಳನ್ನು ಮರುಹೆಸರಿಸುವಾಗ, ನೀವು ಈ ಕೆಳಗಿನ ಸಿಂಟ್ಯಾಕ್ಸ್ ಹೊಂದಿರುವ ಟೆರಾಫಾರ್ಮ್ ಸ್ಟೇಟ್ ಎಮ್ವಿ ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಬೇಕು:

    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 ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಬೇಕು ಎಂದು ಇದು Terraform ಗೆ ಹೇಳುತ್ತದೆ. ಈ ಆಜ್ಞೆಯನ್ನು ಮರುಹೆಸರಿಸಿದ ಮತ್ತು ಚಲಾಯಿಸಿದ ನಂತರ ಟೆರಾಫಾರ್ಮ್ ಯೋಜನೆಯು ಯಾವುದೇ ಬದಲಾವಣೆಗಳನ್ನು ತೋರಿಸದಿದ್ದರೆ, ನೀವು ಎಲ್ಲವನ್ನೂ ಸರಿಯಾಗಿ ಮಾಡಿದ್ದೀರಿ.

  • ಕೆಲವು ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬದಲಾಯಿಸಲಾಗುವುದಿಲ್ಲ. ಅನೇಕ ಸಂಪನ್ಮೂಲಗಳ ನಿಯತಾಂಕಗಳು ಬದಲಾಗುವುದಿಲ್ಲ. ನೀವು ಅವುಗಳನ್ನು ಬದಲಾಯಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ಟೆರ್ರಾಫಾರ್ಮ್ ಹಳೆಯ ಸಂಪನ್ಮೂಲವನ್ನು ಅಳಿಸುತ್ತದೆ ಮತ್ತು ಅದರ ಸ್ಥಳದಲ್ಲಿ ಹೊಸದನ್ನು ರಚಿಸುತ್ತದೆ. ಪ್ರತಿಯೊಂದು ಸಂಪನ್ಮೂಲ ಪುಟವು ಸಾಮಾನ್ಯವಾಗಿ ನೀವು ನಿರ್ದಿಷ್ಟ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಬದಲಾಯಿಸಿದಾಗ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಸೂಚಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ದಸ್ತಾವೇಜನ್ನು ಪರೀಕ್ಷಿಸಲು ಮರೆಯದಿರಿ. ಯಾವಾಗಲೂ ಪ್ಲಾನ್ ಆಜ್ಞೆಯನ್ನು ಬಳಸಿ ಮತ್ತು create_before_destroy ತಂತ್ರವನ್ನು ಬಳಸುವುದನ್ನು ಪರಿಗಣಿಸಿ.

  ಮುಂದೂಡಲ್ಪಟ್ಟ ಸ್ಥಿರತೆ ಸ್ಥಿರವಾಗಿರುತ್ತದೆ... ಮುಂದೂಡಿಕೆಯೊಂದಿಗೆ

  AWS ನಂತಹ ಕೆಲವು ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರ API ಗಳು ಅಸಮಕಾಲಿಕವಾಗಿವೆ ಮತ್ತು ವಿಳಂಬವಾದ ಸ್ಥಿರತೆಯನ್ನು ಹೊಂದಿವೆ. ಅಸಿಂಕ್ರೊನಿ ಎಂದರೆ ಇಂಟರ್ಫೇಸ್ ವಿನಂತಿಸಿದ ಕ್ರಿಯೆಯು ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಕಾಯದೆ ತಕ್ಷಣವೇ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ವಿಳಂಬವಾದ ಸ್ಥಿರತೆ ಎಂದರೆ ಬದಲಾವಣೆಗಳು ವ್ಯವಸ್ಥೆಯಾದ್ಯಂತ ಹರಡಲು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳಬಹುದು; ಇದು ಸಂಭವಿಸುತ್ತಿರುವಾಗ, ನಿಮ್ಮ ಪ್ರತಿಕ್ರಿಯೆಗಳು ಅಸಮಂಜಸವಾಗಿರಬಹುದು ಮತ್ತು ನಿಮ್ಮ API ಕರೆಗಳಿಗೆ ಯಾವ ಡೇಟಾ ಮೂಲ ಪ್ರತಿಕೃತಿಯು ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತಿದೆ ಎಂಬುದರ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತದೆ.

  ಉದಾಹರಣೆಗೆ, ನೀವು EC2 ಸರ್ವರ್ ಅನ್ನು ರಚಿಸಲು AWS ಗೆ API ಕರೆಯನ್ನು ಮಾಡುತ್ತೀರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. 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 ಯಂತೆ), ಮತ್ತು Terraform ಅದನ್ನು ಹುಡುಕಲು ಸಾಧ್ಯವಿಲ್ಲ. ಈ ಹೆಚ್ಚಿನ ದೋಷಗಳನ್ನು (6813 ಸೇರಿದಂತೆ) ಸರಿಪಡಿಸಲಾಗಿದೆ, ಆದರೆ ಅವು ಇನ್ನೂ ಕಾಲಕಾಲಕ್ಕೆ ಬೆಳೆಯುತ್ತವೆ, ವಿಶೇಷವಾಗಿ ಟೆರ್ರಾಫಾರ್ಮ್ ಹೊಸ ಸಂಪನ್ಮೂಲ ಪ್ರಕಾರಕ್ಕೆ ಬೆಂಬಲವನ್ನು ಸೇರಿಸಿದಾಗ. ಇದು ಕಿರಿಕಿರಿ ಉಂಟುಮಾಡುತ್ತದೆ, ಆದರೆ ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಯಾವುದೇ ಹಾನಿ ಉಂಟುಮಾಡುವುದಿಲ್ಲ. ನೀವು ಟೆರಾಫಾರ್ಮ್ ಅನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಿದಾಗ, ಎಲ್ಲವೂ ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು, ಏಕೆಂದರೆ ಈ ಹೊತ್ತಿಗೆ ಮಾಹಿತಿಯು ಈಗಾಗಲೇ ಸಿಸ್ಟಮ್‌ನಾದ್ಯಂತ ಹರಡುತ್ತದೆ.

  ಈ ಆಯ್ದ ಭಾಗವನ್ನು ಎವ್ಗೆನಿ ಬ್ರಿಕ್ಮನ್ ಪುಸ್ತಕದಿಂದ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿದೆ "ಟೆರಾಫಾರ್ಮ್: ಕೋಡ್ ಮಟ್ಟದಲ್ಲಿ ಮೂಲಸೌಕರ್ಯ".

ಮೂಲ: www.habr.com