ಟೆರಾಫಾರ್ಮ್ ಕೋಡ್ ರಚನೆಗೆ ಸಂಬಂಧಿಸಿದ ಪ್ರಶ್ನೆಗಳು ಸಮುದಾಯದಲ್ಲಿ ಆಗಾಗ್ಗೆ ಕಂಡುಬರುತ್ತವೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ಯಾವುದಾದರು ಹಂತದಲ್ಲಿ project ನ ಉತ್ತಮ ಕೋಡ್ ರಚನೆಯ ಬಗ್ಗೆ ಯೋಚಿಸಿರುತ್ತಾರೆ.

ಟೆರಾಫಾರ್ಮ್ ಕಾಂಫಿಗುರೇಶನ್ಗಳನ್ನು ನಾನು ಹೇಗೆ ರಚಿಸಬೇಕು?

ಸಾಕಷ್ಟು ಪರಿಹಾರಗಳು ಇರುವ ಪ್ರಶ್ನೆಗಳಲ್ಲಿ ಇದೂ ಒಂದು, ಆದ್ದರಿಂದ ಸಾರ್ವತ್ರಿಕ ಸಲಹೆಯನ್ನು ನೀಡುವುದು ತುಂಬಾ ಕಷ್ಟ. ಹೀಗಾಗಿ ನಾವು ಏನು ವ್ಯವಹರಿಸುತ್ತಿದ್ದೇವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸೋಣ.

• ನಿಮ್ಮ ಪ್ರಾಜೆಕ್ಟ್ complexity ಏನು?

  • ಸಂಬಂಧಿತ ಸಂಪನ್ಮೂಲಗಳ ಸಂಖ್ಯೆ

  • ಟೆರಾಫಾರ್ಮ್ ಪೂರೈಕೆದಾರರ ಸಂಖ್ಯೆ ("ತಾರ್ಕಿಕ ಪೂರೈಕೆದಾರರ" ಕುರಿತು ಕೆಳಗಿನ ಟಿಪ್ಪಣಿಯನ್ನು ನೋಡಿ)

• ನಿಮ್ಮ infrastructure ಎಷ್ಟು ಬಾರಿ ಬದಲಾಗುತ್ತದೆ?

  • ತಿಂಗಳಿಗೆ/ವಾರಕ್ಕೆ/ದಿನಕ್ಕೊಮ್ಮೆ

  • ನಿರಂತರವಾಗಿ (ಹೊಸ ಬದ್ಧತೆ ಇದ್ದಾಗಲೆಲ್ಲಾ)

• ಕೋಡ್ ಬದಲಾವಣೆಯ initiator ಗಳು ? ಹೊಸ artifact ಅನ್ನು ನಿರ್ಮಿಸುವಾಗ CI ಸರ್ವರ್ ರೆಪೊಸಿಟೋರಿಯನ್ನು ನವೀಕರಿಸಲು ನೀವು ಅನುಮತಿಸುತ್ತೀರಾ?

  • ಡೆವಲಪರ್‌ಗಳು ಮಾತ್ರ infrastructure ರೆಪೊಸಿಟೋರಿಗೆ ತಳ್ಳಬಹುದು

  • PR ಅನ್ನು ತೆರೆಯುವ ಮೂಲಕ ಪ್ರತಿಯೊಬ್ಬರೂ ಯಾವುದಕ್ಕೂ ಬದಲಾವಣೆಯನ್ನು ಪ್ರಸ್ತಾಪಿಸಬಹುದು (CI ಸರ್ವರ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಸ್ವಯಂಚಾಲಿತ ಕಾರ್ಯಗಳು ಸೇರಿದಂತೆ)

• ನೀವು ಯಾವ deployment ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅಥವಾ deployment ಸೇವೆಯನ್ನು ಬಳಸುತ್ತೀರಿ?

  • AWS CodeDeploy, Kubernetes, ಅಥವಾ OpenShiftಗೆ ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾದ ವಿಧಾನದ ಅಗತ್ಯವಿದೆ

• ಪರಿಸರಗಳನ್ನು ಹೇಗೆ ಗುಂಪು ಮಾಡಲಾಗಿದೆ?

  • ಪರಿಸರ, ಪ್ರದೇಶ, ಪ್ರಾಜೆಕ್ಟ್ ಮೂಲಕ

ಟೆರಾಫಾರ್ಮ್ ಕಾಂಫಿಗುರೇಶನ್ಗಳ ಬಗೆಗೆ

ನೀವು ಪ್ರಾರಂಭಿಸುತ್ತಿರುವಾಗ ಅಥವಾ ಉದಾಹರಣೆ ಕೋಡ್ ಬರೆಯುವಾಗ ಎಲ್ಲಾ ಕೋಡ್ ಅನ್ನುmain.tfನಲ್ಲಿ ಹಾಕುವುದು ಒಳ್ಳೆಯದು. ಇತರ ಎಲ್ಲಾ ಸಂದರ್ಭಗಳಲ್ಲಿ ನೀವು ಹಲವಾರು ಫೈಲ್‌ಗಳನ್ನು ತಾರ್ಕಿಕವಾಗಿ ಈ ರೀತಿ ವಿಭಜಿಸಿದರೆ ಉತ್ತಮವಾಗಿರುತ್ತದೆ:

• main.tf - ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು ರಚಿಸಲು ಮಾಡ್ಯೂಲ್‌ಗಳು, locals ಮತ್ತು ಮಾಹಿತಿ ಮೂಲಗಳನ್ನು ಕರೆ ಮಾಡಿ

• variables.tf - main.tfನಲ್ಲಿ ಬಳಸಲಾದ variable ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ.

• outputs.tf - main.tfನಲ್ಲಿ ರಚಿಸಲಾದ ಸಂಪನ್ಮೂಲಗಳ ಔಟ್‌ಪುಟ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ

• versions.tf -ಟೆರಾಫಾರ್ಮ್ ಮತ್ತು ಪೂರೈಕೆದಾರರಿಗೆ version ಅವಶ್ಯಕತೆಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ

terraform.tfvars ಅನ್ನುcomposition ಹೊರತುಪಡಿಸಿ ಎಲ್ಲಿಯೂ ಬಳಸಬಾರದು.

ಟೆರಾಫಾರ್ಮ್ ಕಾಂಫಿಗುರೇಶನ್ ರಚನೆಯ ಬಗ್ಗೆ ಯೋಚಿಸುವುದು ಹೇಗೆ?

ಕೋಡ್ ರಚನೆಗೆ ಸಾಮಾನ್ಯ ಶಿಫಾರಸುಗಳು

• ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ಸಂಪನ್ಮೂಲಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವುದು ಸುಲಭ ಮತ್ತು ವೇಗವಾಗಿರುತ್ತದೆ

  • ಸಂಪನ್ಮೂಲಗಳ ಸ್ಥಿತಿಯನ್ನು ಪರಿಶೀಲಿಸಲುterraform plan ಮತ್ತು terraform apply ಎರಡೂ ಕ್ಲೌಡ್ API ಕರೆಗಳನ್ನು ಮಾಡುತ್ತವೆ

  • ನಿಮ್ಮ ಸಂಪೂರ್ಣ infrastructure ಅನ್ನು ನೀವು ಒಂದೇ ಸಂಯೋಜನೆಯಲ್ಲಿ ಹೊಂದಿದ್ದರೆ ಇದು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳಬಹುದು

• ಬ್ಲಾಸ್ಟ್ ರೇಡಿಯಸ್ (ಭದ್ರತಾ ಉಲ್ಲಂಘನೆಯ ಸಂದರ್ಭದಲ್ಲಿ) ಕಡಿಮೆ ಸಂಪನ್ಮೂಲಗಳಿದ್ದರೆ ಚಿಕ್ಕದಾಗಿರುತ್ತದೆ

  • ಪರಸ್ಪರ ಸಂಬಂಧವಿಲ್ಲದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಕಂಪೋಸಿಷನ್ಸ್ ಗಳಲ್ಲಿ ಇರಿಸುವ ಮೂಲಕ ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡಬಹುದು.

• ರಿಮೋಟ್ ಸ್ಥಿತಿಯನ್ನು ಬಳಸಿಕೊಂಡು ನಿಮ್ಮ ಯೋಜನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿ ಏಕೆಂದರೆ:

  • ನಿಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್ infrastructure ಮೂಲಕ್ಕೆ ಸ್ಥಳವಲ್ಲ

  • git ನಲ್ಲಿ tfstate ಫೈಲ್ ಅನ್ನು ನಿರ್ವಹಿಸುವುದು ಒಂದು ದುಃಸ್ವಪ್ನವಾಗಿದೆ

  • ಮುಂದೆ infrastructure ಲೇಯರ್ ಗಳು ಅನೇಕ ದಿಕ್ಕುಗಳಲ್ಲಿ ಬೆಳೆಯಲು ಪ್ರಾರಂಭಿಸಿದಾಗ (ಅವಲಂಬನೆಗಳು ಅಥವಾ ಸಂಪನ್ಮೂಲಗಳ ಸಂಖ್ಯೆ) ವಿಷಯಗಳನ್ನು ನಿಯಂತ್ರಣದಲ್ಲಿಡಲು ಸುಲಭವಾಗುತ್ತದೆ

• ಸ್ಥಿರವಾದ ಸ್ಟ್ರಕ್ಚರ್ ಮತ್ತು ನೇಮಿಂಗ್ conventionಗಳನ್ನು ಅಭ್ಯಾಸ ಮಾಡಿ:

  • ಪ್ರೊಸೀಜರ್ ಕೋಡ್‌ನಂತೆ, ಮೊದಲು ಓದಲು ಟೆರಾಫಾರ್ಮ್ ಕೋಡ್ ಅನ್ನು ಬರೆಯಬೇಕು, ಆರು ತಿಂಗಳ ನಂತರ ಬದಲಾವಣೆಗಳು ಸಂಭವಿಸಿದಾಗ ಸ್ಥಿರತೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ

  • ಟೆರಾಫಾರ್ಮ್ ಸ್ಟೇಟ್ ಫೈಲ್‌ನಿಂದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸರಿಸಲು ಸಾಧ್ಯವಿದೆ ಆದರೆ ನೀವು ಅಸಮಂಜಸವಾದ ಸ್ಟ್ರಕ್ಚರ್ ಮತ್ತು ನೇಮಿಂಗ್ conventionಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಅದನ್ನು ಮಾಡಲು ಕಷ್ಟವಾಗಬಹುದು

• ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಸರಳವಾಗಿ ಇರಿಸಿ

• ವೇರಿಯೇಬಲ್‌ಗಳಾಗಿ ರವಾನಿಸಬಹುದಾದ ಅಥವಾ ಡೇಟಾ ಮೂಲಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಕಂಡುಹಿಡಿಯಬಹುದಾದ ಮೌಲ್ಯಗಳನ್ನು ಹಾರ್ಡ್‌ಕೋಡ್ ಮಾಡಬೇಡಿ

• ಕಾಂಪೊಸಿಷನ್ ಒಳಗಿನ infrastructure ಮಾಡ್ಯೂಲ್‌ಗಳ ನಡುವೆ ನಿರ್ದಿಷ್ಟವಾಗಿ ಡೇಟಾ ಮೂಲಗಳು ಮತ್ತು terraform_remote_state ಅನ್ನು ಸೇತುವೆಯಂತೆ ಬಳಸಿ

ಈ ಪುಸ್ತಕದಲ್ಲಿ, ಉದಾಹರಣೆ ಪ್ರಾಜೆಕ್ಟ್ ಗಳನ್ನು complexity ಅಡಿಯಲ್ಲಿ ವರ್ಗೀಕರಿಸಲಾಗಿದೆ - ಸಣ್ಣದಿಂದ ಅತಿ ದೊಡ್ಡ ಮೂಲಸೌಕರ್ಯಗಳವರೆಗೆ. ಈ ಪ್ರತ್ಯೇಕತೆಯು ಕಟ್ಟುನಿಟ್ಟಾಗಿಲ್ಲ, ಆದ್ದರಿಂದ ಇತರ ಸ್ಟ್ರಕ್ಚರ್ ಗಳನ್ನು ಸಹ ಪರಿಶೀಲಿಸಬಹುದು.

Infrastructure ಮಾಡ್ಯೂಲ್‌ಗಳು ಮತ್ತು ಕಾಂಪೊಸಿಷನ್ ಗಳ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್

ಸಣ್ಣ infrastructureಅನ್ನು ಹೊಂದಿರುವುದು ಎಂದರೆ ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ಅವಲಂಬನೆಗಳು ಮತ್ತು ಸ್ವಲ್ಪವೇ ಸಂಪನ್ಮೂಲಗಳು. ಪ್ರಾಜೆಕ್ಟ್ ಬೆಳೆದಂತೆ ಟೆರಾಫಾರ್ಮ್ ಕಾಂಫಿಗುರೇಶನ್ ಗಳ ಕಾರ್ಯಗತಗೊಳಿಸುವಿಕೆ, ವಿಭಿನ್ನ infrastructure ಮಾಡ್ಯೂಲ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸುವುದು ಮತ್ತು ಕಾಂಪೊಸಿಷನ್ ಒಳಗೆ value ಗಳನ್ನು ಪಾಸ್ ಮಾಡುವ ಅಗತ್ಯವು ಸ್ಪಷ್ಟವಾಗುತ್ತದೆ.

ಡೆವಲಪರ್‌ಗಳು ಬಳಸುವ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಸೊಲ್ಯೂಷನ್ ಗಳು ಕನಿಷ್ಠ 5 ವಿಭಿನ್ನ ಗುಂಪುಗಳಿವೆ:

1. ಟೆರಾಫಾರ್ಮ್ ಮಾತ್ರ. ತುಂಬಾ ಸರಳವಾದದ್ದು, ಡೆವಲಪರ್‌ಗಳು ಕೆಲಸವನ್ನು ಪೂರ್ಣಗೊಳಿಸಲು ಟೆರಾಫಾರ್ಮ್ ಅನ್ನು ಮಾತ್ರ ತಿಳಿದಿರಬೇಕು.

2. ಟೆರಾಗ್ರಂಟ್. ಸಂಪೂರ್ಣ infrastructureಅನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಟ್ ಮಾಡಲು ಮತ್ತು ಅವಲಂಬನೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಬಳಸಬಹುದಾದ ಶುದ್ಧ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಸಾಧನ. Terragrunt ಲೋಕಲ್ infrastructure ಮಾಡ್ಯೂಲ್‌ಗಳು ಮತ್ತು ಕಾಂಪೊಸಿಷನ್ ಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಇದು ಕೋಡ್‌ನ ನಕಲು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.

3. ಇನ್-ಹೌಸ್ ಸ್ಕ್ರಿಪ್ಟ್‌ಗಳು. ಸಾಮಾನ್ಯವಾಗಿ ಇದು ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ಕಡೆಗೆ ಆರಂಭಿಕ ಹಂತವಾಗಿ ಮತ್ತು ಟೆರಾಗ್ರಂಟ್ ಅನ್ನು ಕಂಡುಹಿಡಿಯುವ ಮೊದಲು ಸಂಭವಿಸುತ್ತದೆ.

4. ಅನ್ಸಿಬಲ್ ಅಥವಾ ಅಂತಹುದೇ ಜನರಲ್ ಸಾಧನ. Ansible ನಂತರ Terraform ಅನ್ನು ಅಳವಡಿಸಿಕೊಂಡಾಗ ಅಥವಾ Ansible UI ಅನ್ನು ಸಕ್ರಿಯವಾಗಿ ಬಳಸಿದಾಗ ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ.

5. Crossplane ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್-ಪ್ರೇರಿತ ಸೊಲ್ಯೂಷನ್ ಗಳು. ಕೆಲವೊಮ್ಮೆ, ನಿಮ್ಮ ಟೆರಾಫಾರ್ಮ್ ಕಾಂಫಿಗುರೇಶನ್ ಗಳ ಅಪೇಕ್ಷಿತ ಸ್ಥಿತಿಯನ್ನು ಸಾಧಿಸಲು ಕುಬರ್ನೆಟ್ಸ್ ಪರಿಸರ ವ್ಯವಸ್ಥೆಯನ್ನು ಬಳಸಿಕೊಳ್ಳುವುದು ಮತ್ತು reconciliation ಲೂಪ್ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಬಳಸಿಕೊಳ್ಳುವುದು ಅರ್ಥಪೂರ್ಣವಾಗಿರುತ್ತದೆ. ಹೆಚ್ಚಿನ ಮಾಹಿತಿಗಾಗಿ Crossplane vs Terraform ವೀಡಿಯೊವನ್ನು ವೀಕ್ಷಿಸಿ.

ಅದನ್ನು ಮನಸ್ಸಿನಲ್ಲಿಟ್ಟುಕೊಂಡು, ಈ ಪುಸ್ತಕವು ಈ ಪ್ರಾಜೆಕ್ಟ್ ಗಳ ಮೊದಲ ಎರಡು ಬಿಲ್ಡ್ ಗಳನ್ನು ವಿಮರ್ಶಿಸುತ್ತದೆ, ಟೆರಾಫಾರ್ಮ್ ಮಾತ್ರ ಮತ್ತು ಟೆರಾಗ್ರಂಟ್.

ಮುಂದಿನ ಅಧ್ಯಾಯದಲ್ಲಿ Terraform ಅಥವಾ Terragrunt ಕೋಡ್ ರಚನೆಗಳ ಉದಾಹರಣೆಗಳನ್ನು ನೋಡಿ

ಜನರಲ್ conventionಗಳು

1. ಎಲ್ಲೆಡೆ - (ಡ್ಯಾಶ್) ಬದಲಿಗೆ _ (ಅಂಡರ್ಸ್ಕೋರ್) ಬಳಸಿ (ಸಂಪನ್ಮೂಲ ಹೆಸರುಗಳು, ಡೇಟಾ ಮೂಲ ಹೆಸರುಗಳು, ವೇರಿಯಬಲ್ ಹೆಸರುಗಳು, ಔಟ್ಪುಟ್ಗಳು, ಇತ್ಯಾದಿ).

2. Lowercase ಅಕ್ಷರಗಳು ಮತ್ತು ಸಂಖ್ಯೆಗಳನ್ನು ಬಳಸಲು ಆದ್ಯತೆ ನೀಡಿ (UTF-8 ಅನ್ನು ಬೆಂಬಲಿಸಿದರೂ ಸಹ).

ಸಂಪನ್ಮೂಲ ಮತ್ತು ಡೇಟಾ ಮೂಲ ಅರ್ಗುಮೆಂಟ್ ಗಳು (arguments)

1. ಸಂಪನ್ಮೂಲದ ಹೆಸರಿನಲ್ಲಿ ಸಂಪನ್ಮೂಲ ಪ್ರಕಾರವನ್ನು ಪುನರಾವರ್ತಿಸಬೇಡಿ (ಭಾಗಶಃವಾಗಿಯೂ ಅಲ್ಲ ಅಥವಾ ಸಂಪೂರ್ಣವಾಗಿಯೂ ಅಲ್ಲ):

`resource "aws_route_table" "public" {}`

`resource "aws_route_table" "public_route_table" {}`

`resource "aws_route_table" "public_aws_route_table" {}`

1. ಹೆಚ್ಚಿನ ವಿವರಣಾತ್ಮಕ ಮತ್ತು ಸಾಮಾನ್ಯ ಹೆಸರು ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ ಅಥವಾ ಸಂಪನ್ಮೂಲ ಮಾಡ್ಯೂಲ್ ಈ ಪ್ರಕಾರದ ಒಂದೇ ಸಂಪನ್ಮೂಲವನ್ನು ರಚಿಸಿದರೆ ಸಂಪನ್ಮೂಲ ಹೆಸರನ್ನುthis ಎಂದು ಹೆಸರಿಸಬೇಕು. (ಉದಾ, AWS VPC ಮಾಡ್ಯೂಲ್‌ನಲ್ಲಿ aws_nat_gateway ಪ್ರಕಾರದ ಒಂದೇ ಸಂಪನ್ಮೂಲವಿದೆ ಮತ್ತು type aws_route_table ನ ಬಹು ಸಂಪನ್ಮೂಲಗಳು ಇವೆ . ಆದ್ದರಿಂದ aws_nat_gateway ಅನ್ನು this ಎಂದು ಹೆಸರಿಸಬೇಕು ಮತ್ತು aws_route_table ಹೆಚ್ಚು ವಿವರಣಾತ್ಮಕ ಹೆಸರುಗಳನ್ನು ಹೊಂದಿರಬೇಕು -(private, public, database).

2. ಹೆಸರುಗಳಿಗೆ ಯಾವಾಗಲೂ ಏಕವಚನ ನಾಮಪದಗಳನ್ನು ಬಳಸಿ.

3. ಬಳಕೆ: ಆರ್ಗ್ಯುಮೆಂಟ್‌ valueಗಳ ಒಳಗೆ. value ಮಾನವನಿಗೆ ಕಾಣುವ ಸ್ಥಳಗಳಲ್ಲಿಇರಬೇಕು(ಉದಾ, RDS ನಿದರ್ಶನದ DNS ಹೆಸರಿನ ಒಳಗೆ).

4. ಆರ್ಗ್ಯುಮೆಂಟ್ count / for_eachನ ಇನ್‌ಸೈಡ್ ರಿಸೋರ್ಸ್ ಅಥವಾ ಡೇಟಾ ಸೋರ್ಸ್ ಬ್ಲಾಕ್ ಅನ್ನು ಮೇಲ್ಭಾಗದಲ್ಲಿ ಮೊದಲ ಆರ್ಗ್ಯುಮೆಂಟ್ ಆಗಿ ಸೇರಿಸಿ, ಮತ್ತು ಅದರ ನಂತರ ಹೊಸ ಸಾಲಿನ ಮೂಲಕ ಪ್ರತ್ಯೇಕಿಸಿ.

5. ಆರ್ಗ್ಯುಮೆಂಟ್ tagsಗಳನ್ನು ಸೇರಿಸಿ, ಸಂಪನ್ಮೂಲದಿಂದ ಬೆಂಬಲಿಸಿದರೆ, ಕೊನೆಯ ನೈಜ ಆರ್ಗ್ಯುಮೆಂಟ್ ಆಗಿ, ಅವಶ್ಯವಿದ್ದಲ್ಲಿ depends_on ಮತ್ತು lifecycle ಅನ್ನು ಅನುಸರಿಸಿ. ಇವೆಲ್ಲವನ್ನೂ ಒಂದೇ ಖಾಲಿ ಲೈನ್ ನಿಂದ ಬೇರ್ಪಡಿಸಬೇಕು.

6. count / for_each ಆರ್ಗ್ಯುಮೆಂಟ್‌ನಲ್ಲಿ ಷರತ್ತುಗಳನ್ನು ಬಳಸುವಾಗ length ಅಥವಾ ಇತರ ಅಭಿವ್ಯಕ್ತಿಗಳನ್ನು ಬಳಸುವ ಬದಲು, ಬೂಲಿಯನ್ ಮೌಲ್ಯಗಳಿಗೆ ಆದ್ಯತೆ ನೀಡಿ.

resource ಕೋಡ್ ಉದಾಹರಣೆಗಳು

count / for_eachನ ಬಳಕೆ

resource "aws_route_table" "public" {
  count = 2

  vpc_id = "vpc-12345678"
  # ... remaining arguments omitted
}

resource "aws_route_table" "private" {
  for_each = toset(["one", "two"])

  vpc_id = "vpc-12345678"
  # ... remaining arguments omitted
}

resource "aws_route_table" "public" {
  vpc_id = "vpc-12345678"
  count  = 2

  # ... remaining arguments omitted
}

tagsನಿಯೋಜನೆ

resource "aws_nat_gateway" "this" {
  count = 2

  allocation_id = "..."
  subnet_id     = "..."

  tags = {
    Name = "..."
  }

  depends_on = [aws_internet_gateway.this]

  lifecycle {
    create_before_destroy = true
  }
}   

resource "aws_nat_gateway" "this" {
  count = 2

  tags = "..."

  depends_on = [aws_internet_gateway.this]

  lifecycle {
    create_before_destroy = true
  }

  allocation_id = "..."
  subnet_id     = "..."
}