ಕೋಡ್ ರಚನೆ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ತಾರ್ಕಿಕ ಪೂರೈಕೆದಾರರು ಸಂಪೂರ್ಣವಾಗಿ ಟೆರ್ರಾಫಾರ್ಮ್‌ನ ತರ್ಕದೊಳಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಆಗಾಗ್ಗೆ ಯಾವುದೇ ಇತರ ಸೇವೆಗಳೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾವು ಅವರ ಸಂಕೀರ್ಣತೆಯನ್ನು O(1) ಎಂದು ಯೋಚಿಸಬಹುದು. ಸಾಮಾನ್ಯವಾದ ತಾರ್ಕಿಕ ಪೂರೈಕೆದಾರರು ಎಂದರೆ random, local, terraform, null, time.

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

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

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

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

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

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

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

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

ದಯವಿಟ್ಟು ನೀವು ಕೀ -ಕಾನ್ಸೆಪ್ಟ್ ಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೀರಿ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ - resource module, infrastructure module, ಮತ್ತು 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 ಕೋಡ್ ರಚನೆಗಳ ಉದಾಹರಣೆಗಳನ್ನು ನೋಡಿ