ਭਵਿੱਖ ਲਈ ਟੈਰਾਫਾਰਮ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਵੇਰਵਾ। ਐਂਟਨ ਬਾਬੇਨਕੋ (2018)

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

ਤੁਹਾਡਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਲਗਭਗ ਨਿਸ਼ਚਿਤ ਤੌਰ 'ਤੇ ਸਧਾਰਨ ਤੋਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ: ਕੁਝ ਸਰੋਤ + ਕੁਝ ਡਿਵੈਲਪਰ। ਸਮੇਂ ਦੇ ਨਾਲ, ਇਹ ਹਰ ਕਿਸਮ ਦੀਆਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਵਧਦਾ ਹੈ. ਕੀ ਤੁਸੀਂ ਸਰੋਤਾਂ ਨੂੰ ਟੈਰਾਫਾਰਮ ਮੋਡੀਊਲ ਵਿੱਚ ਗਰੁੱਪ ਕਰਨ, ਕੋਡ ਨੂੰ ਫੋਲਡਰਾਂ ਵਿੱਚ ਸੰਗਠਿਤ ਕਰਨ ਦੇ ਤਰੀਕੇ ਲੱਭਦੇ ਹੋ, ਅਤੇ ਹੋਰ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ? (ਪ੍ਰਸਿੱਧ ਆਖਰੀ ਸ਼ਬਦ)

ਸਮਾਂ ਬੀਤਦਾ ਹੈ ਅਤੇ ਤੁਸੀਂ ਮਹਿਸੂਸ ਕਰਦੇ ਹੋ ਕਿ ਤੁਹਾਡਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਤੁਹਾਡਾ ਨਵਾਂ ਪਾਲਤੂ ਜਾਨਵਰ ਹੈ, ਪਰ ਕਿਉਂ? ਤੁਸੀਂ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਅਣਜਾਣ ਤਬਦੀਲੀਆਂ ਬਾਰੇ ਚਿੰਤਤ ਹੋ, ਤੁਸੀਂ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਅਤੇ ਕੋਡ ਨੂੰ ਛੂਹਣ ਤੋਂ ਡਰਦੇ ਹੋ - ਨਤੀਜੇ ਵਜੋਂ, ਤੁਸੀਂ ਨਵੀਂ ਕਾਰਜਸ਼ੀਲਤਾ ਵਿੱਚ ਦੇਰੀ ਕਰਦੇ ਹੋ ਜਾਂ ਗੁਣਵੱਤਾ ਘਟਾਉਂਦੇ ਹੋ...

Github 'ਤੇ AWS ਲਈ Terraform ਕਮਿਊਨਿਟੀ ਮੌਡਿਊਲਾਂ ਦੇ ਸੰਗ੍ਰਹਿ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਅਤੇ ਉਤਪਾਦਨ ਵਿੱਚ Terraform ਦੇ ਲੰਬੇ ਸਮੇਂ ਦੇ ਰੱਖ-ਰਖਾਅ ਦੇ ਤਿੰਨ ਸਾਲਾਂ ਬਾਅਦ, ਐਂਟਨ ਬਾਬੇਨਕੋ ਆਪਣਾ ਅਨੁਭਵ ਸਾਂਝਾ ਕਰਨ ਲਈ ਤਿਆਰ ਹੈ: TF ਮੋਡੀਊਲ ਕਿਵੇਂ ਲਿਖਣੇ ਹਨ ਤਾਂ ਜੋ ਭਵਿੱਖ ਵਿੱਚ ਨੁਕਸਾਨ ਨਾ ਹੋਵੇ।

ਗੱਲਬਾਤ ਦੇ ਅੰਤ ਤੱਕ, ਭਾਗੀਦਾਰ ਟੈਰਾਫਾਰਮ ਵਿੱਚ ਸਰੋਤ ਪ੍ਰਬੰਧਨ ਸਿਧਾਂਤਾਂ, ਟੈਰਾਫਾਰਮ ਵਿੱਚ ਮੋਡੀਊਲਾਂ ਨਾਲ ਜੁੜੇ ਵਧੀਆ ਅਭਿਆਸਾਂ, ਅਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਪ੍ਰਬੰਧਨ ਨਾਲ ਜੁੜੇ ਕੁਝ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਸਿਧਾਂਤਾਂ ਤੋਂ ਵਧੇਰੇ ਜਾਣੂ ਹੋਣਗੇ।

ਬੇਦਾਅਵਾ: ਮੈਂ ਨੋਟ ਕਰਦਾ ਹਾਂ ਕਿ ਇਹ ਰਿਪੋਰਟ ਨਵੰਬਰ 2018 ਦੀ ਹੈ—2 ਸਾਲ ਪਹਿਲਾਂ ਹੀ ਬੀਤ ਚੁੱਕੇ ਹਨ। ਰਿਪੋਰਟ ਵਿੱਚ ਚਰਚਾ ਕੀਤੀ ਗਈ Terraform 0.11 ਦਾ ਸੰਸਕਰਣ ਹੁਣ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ। ਪਿਛਲੇ 2 ਸਾਲਾਂ ਵਿੱਚ, 2 ਨਵੇਂ ਰੀਲੀਜ਼ ਜਾਰੀ ਕੀਤੇ ਗਏ ਹਨ, ਜਿਸ ਵਿੱਚ ਬਹੁਤ ਸਾਰੀਆਂ ਕਾਢਾਂ, ਸੁਧਾਰ ਅਤੇ ਬਦਲਾਅ ਸ਼ਾਮਲ ਹਨ। ਕਿਰਪਾ ਕਰਕੇ ਇਸ ਵੱਲ ਧਿਆਨ ਦਿਓ ਅਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਜਾਂਚ ਕਰੋ।

ਲਿੰਕ:

• ਟੈਰਾਫਾਰਮ-ਕਮਿਊਨਿਟੀ-ਮੋਡਿਊਲ + terraform-aws-modules
• antonbabenko/pre-commit-terraform - ਆਟੋ-ਫਾਰਮੈਟਿੰਗ ਕੋਡ ਅਤੇ ਦਸਤਾਵੇਜ਼
• antonbabenko/terrapin - ਟੈਰਾਫਾਰਮ ਮੋਡੀਊਲ (WIP) ਦਾ ਜਨਰੇਟਰ
• antonbabenko/modules.tf-lambda - ਵਿਜ਼ੂਅਲ ਡਾਇਗ੍ਰਾਮ (ਡਬਲਯੂਆਈਪੀ) ਤੋਂ ਟੈਰਾਫਾਰਮ ਕੋਡ ਜਨਰੇਟਰ
• www.terraform-best-practices.com
• medium.com/@anton.babenko (ਨਵੀਆਂ ਪੋਸਟਾਂ ਮੇਰੀ ਨਿੱਜੀ ਵੈੱਬਸਾਈਟ www.antonbabenko.com/ 'ਤੇ ਹਨ)
• @antonbabenko - ਟਵਿੱਟਰ, ਅਤੇ ਵੱਖ-ਵੱਖ ਸਲੈਕਾਂ ਦਾ ਇੱਕ ਸਮੂਹ

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

ਮੈਂ ਟੈਰਾਫਾਰਮ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹਾਂ ਅਤੇ 2015 ਤੋਂ ਟੈਰਾਫਾਰਮ ਅਤੇ ਐਮਾਜ਼ਾਨ ਨਾਲ ਸਬੰਧਤ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਇੱਕ ਸਰਗਰਮ ਭਾਗੀਦਾਰ ਅਤੇ ਯੋਗਦਾਨ ਪਾਉਣ ਵਾਲਾ ਰਿਹਾ ਹਾਂ।

ਉਦੋਂ ਤੋਂ ਮੈਂ ਇਸਨੂੰ ਦਿਲਚਸਪ ਤਰੀਕੇ ਨਾਲ ਪਾਉਣ ਲਈ ਕਾਫ਼ੀ ਕੋਡ ਲਿਖਿਆ ਹੈ। ਅਤੇ ਮੈਂ ਤੁਹਾਨੂੰ ਹੁਣ ਇਸ ਬਾਰੇ ਦੱਸਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਾਂਗਾ.

ਮੈਂ ਟੈਰਾਫਾਰਮ ਨਾਲ ਕੰਮ ਕਰਨ ਦੀਆਂ ਪੇਚੀਦਗੀਆਂ ਅਤੇ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗਾ। ਪਰ ਇਹ ਅਸਲ ਵਿੱਚ ਹਾਈਲੋਡ ਦਾ ਵਿਸ਼ਾ ਨਹੀਂ ਹੈ. ਅਤੇ ਹੁਣ ਤੁਸੀਂ ਸਮਝੋਗੇ ਕਿ ਕਿਉਂ.

ਸਮੇਂ ਦੇ ਨਾਲ, ਮੈਂ ਟੈਰਾਫਾਰਮ ਮੋਡੀਊਲ ਲਿਖਣਾ ਸ਼ੁਰੂ ਕੀਤਾ। ਉਪਭੋਗਤਾਵਾਂ ਨੇ ਸਵਾਲ ਲਿਖੇ, ਮੈਂ ਉਹਨਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਿਆ। ਫਿਰ ਮੈਂ ਪ੍ਰੀ-ਕਮਿਟ ਹੁੱਕ, ਆਦਿ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੋਡ ਨੂੰ ਫਾਰਮੈਟ ਕਰਨ ਲਈ ਕਈ ਉਪਯੋਗਤਾਵਾਂ ਲਿਖੀਆਂ।

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

ਮੈਂ ਯੂਕਰੇਨ ਤੋਂ ਹਾਂ। ਮੈਂ ਕਈ ਸਾਲਾਂ ਤੋਂ ਨਾਰਵੇ ਵਿੱਚ ਰਿਹਾ ਹਾਂ।

ਨਾਲ ਹੀ, ਇਸ ਰਿਪੋਰਟ ਲਈ ਜਾਣਕਾਰੀ ਉਹਨਾਂ ਲੋਕਾਂ ਤੋਂ ਇਕੱਠੀ ਕੀਤੀ ਗਈ ਸੀ ਜੋ ਮੇਰਾ ਨਾਮ ਜਾਣਦੇ ਹਨ ਅਤੇ ਮੈਨੂੰ ਸੋਸ਼ਲ ਨੈਟਵਰਕਸ 'ਤੇ ਲੱਭਦੇ ਹਨ। ਮੇਰੇ ਕੋਲ ਲਗਭਗ ਹਮੇਸ਼ਾ ਇੱਕੋ ਉਪਨਾਮ ਹੁੰਦਾ ਹੈ।

https://github.com/terraform-aws-modules
https://registry.terraform.io/namespaces/terraform-aws-modules

ਜਿਵੇਂ ਕਿ ਮੈਂ ਦੱਸਿਆ ਹੈ, ਮੈਂ Terraform AWS ਮੋਡੀਊਲ ਦਾ ਮੁੱਖ ਰੱਖਿਅਕ ਹਾਂ, ਜੋ ਕਿ GitHub 'ਤੇ ਸਭ ਤੋਂ ਵੱਡੇ ਭੰਡਾਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਜਿੱਥੇ ਅਸੀਂ ਸਭ ਤੋਂ ਆਮ ਕੰਮਾਂ ਲਈ ਮੋਡੀਊਲ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰਦੇ ਹਾਂ: VPC, ਆਟੋਸਕੇਲਿੰਗ, RDS।

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

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

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

ਇਹ ਇੱਕ ਰੈਗੂਲਰ ਟੈਰਾਫਾਰਮ ਕੌਂਫਿਗਰੇਸ਼ਨ ਫਾਈਲ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ, ਜਿੱਥੇ ਅਸੀਂ ਪਹਿਲਾਂ ਕੁਝ ਵੇਰੀਏਬਲਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਾਂ।

ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਅਸੀਂ "aws_region" ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹਾਂ।

ਫਿਰ ਅਸੀਂ ਵਰਣਨ ਕਰਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਕਿਹੜੇ ਸਰੋਤ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ।

ਅਸੀਂ ਕੁਝ ਕਮਾਂਡਾਂ ਚਲਾਉਂਦੇ ਹਾਂ, ਖਾਸ ਤੌਰ 'ਤੇ "terraform init" ਨਿਰਭਰਤਾਵਾਂ ਅਤੇ ਪ੍ਰਦਾਤਾਵਾਂ ਨੂੰ ਲੋਡ ਕਰਨ ਲਈ।

ਅਤੇ ਅਸੀਂ "terraform apply" ਕਮਾਂਡ ਚਲਾਉਂਦੇ ਹਾਂ ਤਾਂ ਜੋ ਇਹ ਪਤਾ ਲਗਾਇਆ ਜਾ ਸਕੇ ਕਿ ਕੀ ਨਿਰਧਾਰਤ ਸੰਰਚਨਾ ਸਾਡੇ ਦੁਆਰਾ ਬਣਾਏ ਸਰੋਤਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ ਜਾਂ ਨਹੀਂ। ਕਿਉਂਕਿ ਅਸੀਂ ਪਹਿਲਾਂ ਕੁਝ ਨਹੀਂ ਬਣਾਇਆ ਹੈ, ਟੈਰਾਫਾਰਮ ਸਾਨੂੰ ਇਹ ਸਰੋਤ ਬਣਾਉਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਦਾ ਹੈ।

ਅਸੀਂ ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਾਂ। ਇਸ ਤਰ੍ਹਾਂ ਅਸੀਂ ਇੱਕ ਬਾਲਟੀ ਬਣਾਉਂਦੇ ਹਾਂ ਜਿਸ ਨੂੰ ਸੀਸਨੈਲ ਕਿਹਾ ਜਾਂਦਾ ਹੈ।

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

ਉਹ ਟੀਚੇ ਜੋ ਟੈਰਾਫਾਰਮ ਨੇ ਸ਼ੁਰੂ ਤੋਂ ਹੀ ਅਪਣਾਏ ਹਨ:

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

2014 ਵਿੱਚ, ਸ਼ਬਦ "ਅਨੁਮਾਨਤ" ਇਸ ਸੰਦਰਭ ਵਿੱਚ ਬਹੁਤ ਅਸਾਧਾਰਨ ਲੱਗ ਰਿਹਾ ਸੀ।

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

• ਤੁਸੀਂ ਹਰ ਚੀਜ਼ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ 120 ਤੋਂ ਵੱਧ ਪ੍ਰਦਾਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ ਜੋ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ।
• ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ GitHub ਰਿਪੋਜ਼ਟਰੀਆਂ ਤੱਕ ਪਹੁੰਚ ਦਾ ਵਰਣਨ ਕਰਨ ਲਈ Terraform ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ।
• ਤੁਸੀਂ ਜੀਰਾ ਵਿੱਚ ਬੱਗ ਬਣਾ ਅਤੇ ਬੰਦ ਵੀ ਕਰ ਸਕਦੇ ਹੋ।
• ਤੁਸੀਂ ਨਵੀਂ ਰਿਲਿਕ ਮੈਟ੍ਰਿਕਸ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰ ਸਕਦੇ ਹੋ।
• ਜੇਕਰ ਤੁਸੀਂ ਸੱਚਮੁੱਚ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਤੁਸੀਂ ਡ੍ਰੌਪਬਾਕਸ ਵਿੱਚ ਫਾਈਲਾਂ ਵੀ ਬਣਾ ਸਕਦੇ ਹੋ।

ਇਹ ਸਭ ਟੈਰਾਫਾਰਮ ਪ੍ਰਦਾਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਾਪਤ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਿਸ ਕੋਲ ਇੱਕ ਓਪਨ API ਹੈ ਜਿਸਦਾ ਵਰਣਨ Go ਵਿੱਚ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਮੰਨ ਲਓ ਕਿ ਅਸੀਂ ਟੈਰਾਫਾਰਮ ਦੀ ਵਰਤੋਂ ਸ਼ੁਰੂ ਕੀਤੀ, ਸਾਈਟ 'ਤੇ ਕੁਝ ਦਸਤਾਵੇਜ਼ ਪੜ੍ਹੇ, ਕੁਝ ਵੀਡੀਓ ਦੇਖੇ, ਅਤੇ main.tf ਲਿਖਣਾ ਸ਼ੁਰੂ ਕੀਤਾ, ਜਿਵੇਂ ਕਿ ਮੈਂ ਪਿਛਲੀਆਂ ਸਲਾਈਡਾਂ 'ਤੇ ਦਿਖਾਇਆ ਸੀ।

ਅਤੇ ਸਭ ਕੁਝ ਬਹੁਤ ਵਧੀਆ ਹੈ, ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਫਾਈਲ ਹੈ ਜੋ ਇੱਕ VPC ਬਣਾਉਂਦਾ ਹੈ.

ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ VPC ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਲਗਭਗ ਇਹ 12 ਲਾਈਨਾਂ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹੋ। ਦੱਸੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਖੇਤਰ ਵਿੱਚ ਬਣਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, IP ਪਤਿਆਂ ਦਾ ਕਿਹੜਾ cidr_block ਵਰਤਣਾ ਹੈ। ਇਹ ਸਭ ਹੈ.

ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਪ੍ਰੋਜੈਕਟ ਹੌਲੀ ਹੌਲੀ ਵਧੇਗਾ.

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

ਆਓ ਹੇਠਾਂ ਦਿੱਤੀ ਉਦਾਹਰਣ ਨੂੰ ਵੇਖੀਏ.

ਤੁਸੀਂ ਹੌਲੀ-ਹੌਲੀ internet_gateway ਜੋੜਦੇ ਹੋ ਕਿਉਂਕਿ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਤੁਹਾਡੇ VPC ਤੋਂ ਸਰੋਤ ਇੰਟਰਨੈਟ ਦੀ ਪਹੁੰਚ ਹੋਵੇ। ਇਹ ਇੱਕ ਚੰਗਾ ਵਿਚਾਰ ਹੈ।

ਨਤੀਜਾ ਇਹ ਹੈ main.tf:

ਇਹ main.tf ਦਾ ਸਿਖਰਲਾ ਹਿੱਸਾ ਹੈ।

ਇਹ main.tf ਦਾ ਹੇਠਲਾ ਹਿੱਸਾ ਹੈ।

ਫਿਰ ਤੁਸੀਂ ਸਬਨੈੱਟ ਜੋੜਦੇ ਹੋ। ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ NAT ਗੇਟਵੇ, ਰੂਟ, ਰੂਟਿੰਗ ਟੇਬਲ ਅਤੇ ਹੋਰ ਸਬਨੈੱਟਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਜੋੜਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤੁਹਾਡੇ ਕੋਲ 38 ਲਾਈਨਾਂ ਨਹੀਂ ਹੋਣਗੀਆਂ, ਪਰ ਲਗਭਗ 200-300 ਲਾਈਨਾਂ ਹੋਣਗੀਆਂ।

ਯਾਨੀ ਤੁਹਾਡੀ main.tf ਫਾਈਲ ਹੌਲੀ-ਹੌਲੀ ਵਧ ਰਹੀ ਹੈ। ਅਤੇ ਅਕਸਰ ਲੋਕ ਸਭ ਕੁਝ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਪਾਉਂਦੇ ਹਨ. main.tf ਵਿੱਚ 10-20 Kb ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ। ਕਲਪਨਾ ਕਰੋ ਕਿ 10-20 Kb ਟੈਕਸਟ ਸਮੱਗਰੀ ਹੈ। ਅਤੇ ਹਰ ਚੀਜ਼ ਹਰ ਚੀਜ਼ ਨਾਲ ਜੁੜੀ ਹੋਈ ਹੈ. ਇਸ ਨਾਲ ਕੰਮ ਕਰਨਾ ਹੌਲੀ-ਹੌਲੀ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਜਾ ਰਿਹਾ ਹੈ। 10-20 Kb ਇੱਕ ਚੰਗਾ ਉਪਭੋਗਤਾ ਕੇਸ ਹੈ, ਕਈ ਵਾਰ ਹੋਰ। ਅਤੇ ਲੋਕ ਹਮੇਸ਼ਾ ਇਹ ਨਹੀਂ ਸੋਚਦੇ ਕਿ ਇਹ ਬੁਰਾ ਹੈ।

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

• ਕੋਡ ਵਧ ਰਿਹਾ ਹੈ।
• ਸਰੋਤਾਂ ਵਿਚਕਾਰ ਨਿਰਭਰਤਾ ਵੀ ਵਧ ਰਹੀ ਹੈ।

ਅਤੇ ਸਾਨੂੰ ਬਹੁਤ ਵੱਡੀ ਲੋੜ ਹੈ। ਅਸੀਂ ਸਮਝਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਹੁਣ ਇਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਰਹਿ ਸਕਦੇ। ਸਾਡਾ ਕੋਡ ਵਿਸ਼ਾਲ ਹੁੰਦਾ ਜਾ ਰਿਹਾ ਹੈ। 10-20 Kb, ਬੇਸ਼ੱਕ, ਬਹੁਤ ਵਿਸ਼ਾਲ ਨਹੀਂ ਹੈ, ਪਰ ਅਸੀਂ ਸਿਰਫ ਨੈੱਟਵਰਕ ਸਟੈਕ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ, ਭਾਵ ਤੁਸੀਂ ਸਿਰਫ ਨੈੱਟਵਰਕ ਸਰੋਤ ਸ਼ਾਮਲ ਕੀਤੇ ਹਨ। ਅਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਲੋਡ ਬੈਲੈਂਸਰ, ਤੈਨਾਤੀ ES ਕਲੱਸਟਰ, ਕੁਬਰਨੇਟਸ, ਆਦਿ ਬਾਰੇ ਗੱਲ ਨਹੀਂ ਕਰ ਰਹੇ ਹਾਂ, ਜਿੱਥੇ 100 Kb ਆਸਾਨੀ ਨਾਲ ਬੁਣਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਹ ਸਭ ਲਿਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਬਹੁਤ ਜਲਦੀ ਸਿੱਖੋਗੇ ਕਿ ਟੈਰਾਫਾਰਮ ਟੈਰਾਫਾਰਮ ਮੋਡੀਊਲ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

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

ਇਸ ਲਈ ਅਸੀਂ ਇਹ ਸਮਝਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ ਕਿ ਅਸੀਂ ਆਪਣੇ 10-20-30 Kb ਕੋਡ ਨੂੰ ਕਿਵੇਂ ਅਨੁਕੂਲ ਬਣਾਵਾਂਗੇ। ਅਸੀਂ ਹੌਲੀ-ਹੌਲੀ ਮਹਿਸੂਸ ਕਰ ਰਹੇ ਹਾਂ ਕਿ ਸਾਨੂੰ ਕੁਝ ਮੋਡੀਊਲ ਵਰਤਣ ਦੀ ਲੋੜ ਹੈ।

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

ਇੱਕ ਸਰੋਤ ਮੋਡੀਊਲ ਦੀ ਇੱਕ ਉਦਾਹਰਨ.

ਜਦੋਂ ਅਸੀਂ ਇੱਕ ਸਰੋਤ ਮੋਡੀਊਲ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਾਂ, ਅਸੀਂ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ ਕਿ ਸਾਨੂੰ ਇਸਦੀ ਸਮੱਗਰੀ ਨੂੰ ਕਿਸ ਮਾਰਗ ਤੋਂ ਲੋਡ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਅਸੀਂ ਦਰਸਾਉਂਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਕਿਹੜਾ ਸੰਸਕਰਣ ਡਾਊਨਲੋਡ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ।

ਅਸੀਂ ਉੱਥੇ ਦਲੀਲਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਪਾਸ ਕਰਦੇ ਹਾਂ। ਇਹ ਸਭ ਹੈ. ਜਦੋਂ ਅਸੀਂ ਇਸ ਮੋਡੀਊਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ ਤਾਂ ਸਾਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।

ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਸੋਚਦੇ ਹਨ ਕਿ ਜੇ ਉਹ ਨਵੀਨਤਮ ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਤਾਂ ਸਭ ਕੁਝ ਸਥਿਰ ਹੋ ਜਾਵੇਗਾ. ਪਰ ਨਹੀਂ। ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਸੰਸਕਰਣ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ; ਸਾਨੂੰ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ ਜਵਾਬ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇਹ ਜਾਂ ਉਹ ਕੰਪੋਨੈਂਟ ਕਿਸ ਸੰਸਕਰਣ 'ਤੇ ਤਾਇਨਾਤ ਕੀਤਾ ਗਿਆ ਸੀ।

ਇਹ ਕੋਡ ਹੈ ਜੋ ਇਸ ਮੋਡੀਊਲ ਦੇ ਅੰਦਰ ਹੈ। ਸੁਰੱਖਿਆ-ਸਮੂਹ ਮੋਡੀਊਲ। ਇੱਥੇ ਸਕ੍ਰੋਲ 640ਵੀਂ ਲਾਈਨ 'ਤੇ ਜਾਂਦਾ ਹੈ। ਹਰ ਸੰਭਵ ਸੰਰਚਨਾ ਵਿੱਚ ਐਮਾਜ਼ਾਨ ਵਿੱਚ ਇੱਕ ਸੁਰੱਖਿਆ-ਖਰਖਰੀ ਸਰੋਤ ਬਣਾਉਣਾ ਇੱਕ ਬਹੁਤ ਹੀ ਗੈਰ-ਮਾਮੂਲੀ ਕੰਮ ਹੈ। ਸਿਰਫ਼ ਇੱਕ ਸੁਰੱਖਿਆ ਸਮੂਹ ਬਣਾਉਣਾ ਅਤੇ ਇਹ ਦੱਸਣਾ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ ਕਿ ਇਸ ਨੂੰ ਕਿਹੜੇ ਨਿਯਮ ਪਾਸ ਕਰਨੇ ਹਨ। ਇਹ ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਹੋਵੇਗਾ. ਐਮਾਜ਼ਾਨ ਦੇ ਅੰਦਰ ਇੱਕ ਮਿਲੀਅਨ ਵੱਖ-ਵੱਖ ਪਾਬੰਦੀਆਂ ਹਨ. ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਤੁਸੀਂ ਵਰਤਦੇ ਹੋ VPC ਐਂਡਪੁਆਇੰਟ, ਪ੍ਰੀਫਿਕਸ ਸੂਚੀ, ਵੱਖ-ਵੱਖ APIs ਅਤੇ ਇਸ ਸਭ ਨੂੰ ਹਰ ਚੀਜ਼ ਨਾਲ ਜੋੜਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਫਿਰ ਟੈਰਾਫਾਰਮ ਤੁਹਾਨੂੰ ਅਜਿਹਾ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦਾ ਹੈ। ਅਤੇ ਐਮਾਜ਼ਾਨ API ਇਸਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦਾ ਹੈ। ਇਸ ਲਈ, ਸਾਨੂੰ ਇਸ ਸਾਰੇ ਭਿਆਨਕ ਤਰਕ ਨੂੰ ਇੱਕ ਮੋਡੀਊਲ ਵਿੱਚ ਛੁਪਾਉਣ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਉਪਭੋਗਤਾ ਨੂੰ ਕੋਡ ਦੇਣਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ.

ਉਪਭੋਗਤਾ ਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ ਹੁੰਦੀ ਕਿ ਇਹ ਅੰਦਰ ਕਿਵੇਂ ਬਣਿਆ ਹੈ।

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

ਅੱਗੇ ਮੈਂ ਇਸ ਦੀਆਂ ਕੁਝ ਉਦਾਹਰਣਾਂ ਦਿਖਾਵਾਂਗਾ।

ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਮੋਡੀਊਲ ਨੂੰ ਬਿਲਕੁਲ ਉਸੇ ਤਰ੍ਹਾਂ ਕਿਹਾ ਜਾਂਦਾ ਹੈ।

ਸਮੱਗਰੀ ਨੂੰ ਕਿੱਥੋਂ ਡਾਊਨਲੋਡ ਕਰਨਾ ਹੈ ਸਰੋਤ ਦਰਸਾਏ ਗਏ ਹਨ।

ਮੁੱਲਾਂ ਦਾ ਇੱਕ ਝੁੰਡ ਇਸ ਮੋਡੀਊਲ ਵਿੱਚ ਪਾਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਪਾਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

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

ਮੋਡੀਊਲ ਦੋ ਕਿਸਮ ਦੇ ਹੁੰਦੇ ਹਨ. ਇਹ ਸਮਝਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਜਾਣਕਾਰੀ ਜੋ ਮੈਂ ਇਸ ਰਿਪੋਰਟ ਵਿੱਚ ਸਮੂਹ ਕੀਤੀ ਹੈ ਉਹ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਨਹੀਂ ਲਿਖੀ ਗਈ ਹੈ।

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

ਆਉ ਅੱਗੇ ਦੇਖੀਏ ਕਿ ਇਹਨਾਂ ਮੋਡੀਊਲ ਨੂੰ ਕਿਵੇਂ ਲਿਖਣਾ ਹੈ। ਫਿਰ ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਕਾਲ ਕਰਨਾ ਹੈ ਅਤੇ ਕੋਡ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ।

ਟੈਰਾਫਾਰਮ ਰਜਿਸਟਰੀ - https://registry.terraform.io/

ਟਿਪ #0 ਸਰੋਤ ਮੋਡੀਊਲ ਨਾ ਲਿਖਣਾ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਮੈਡਿਊਲ ਤੁਹਾਡੇ ਲਈ ਪਹਿਲਾਂ ਹੀ ਲਿਖੇ ਗਏ ਹਨ। ਜਿਵੇਂ ਕਿ ਮੈਂ ਕਿਹਾ, ਉਹ ਓਪਨ ਸੋਰਸ ਹਨ, ਉਹਨਾਂ ਵਿੱਚ ਤੁਹਾਡਾ ਕੋਈ ਵੀ ਵਪਾਰਕ ਤਰਕ ਨਹੀਂ ਹੈ, ਉਹਨਾਂ ਕੋਲ IP ਪਤੇ, ਪਾਸਵਰਡ ਆਦਿ ਲਈ ਹਾਰਡਕੋਡ ਮੁੱਲ ਨਹੀਂ ਹਨ। ਮੋਡੀਊਲ ਬਹੁਤ ਲਚਕਦਾਰ ਹੈ। ਅਤੇ ਇਹ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਪਹਿਲਾਂ ਹੀ ਲਿਖਿਆ ਗਿਆ ਹੈ. ਐਮਾਜ਼ਾਨ ਤੋਂ ਸਰੋਤਾਂ ਲਈ ਬਹੁਤ ਸਾਰੇ ਮੋਡੀਊਲ ਹਨ. ਲਗਭਗ 650. ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਚੰਗੀ ਗੁਣਵੱਤਾ ਵਾਲੇ ਹਨ।

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

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

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

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

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

https://github.com/mbtproject/mbt

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

ਬੇਸ਼ੱਕ, ਬਹੁਤ ਸਾਰੀਆਂ ਕਮੀਆਂ ਹਨ. ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਸਕਦੇ ਹੋ। ਅਤੇ ਇਸ ਨਾਲ ਰਹਿਣਾ ਕਈ ਵਾਰ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ।

ਦੂਜਾ ਹੱਲ. ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਬਹੁਤ ਸਾਰੇ ਸਬਮੋਡਿਊਲ ਹਨ ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਕਿਸੇ ਕਿਸਮ ਦੀ ਸਥਾਪਤ ਪਾਈਪਲਾਈਨ ਹੈ, ਤਾਂ ਇੱਥੇ MBT ਪ੍ਰੋਜੈਕਟ ਹੈ, ਜੋ ਤੁਹਾਨੂੰ ਮੋਨੋਰੋਪੋਜ਼ਟਰੀ ਤੋਂ ਬਹੁਤ ਸਾਰੇ ਵੱਖ-ਵੱਖ ਪੈਕੇਜਾਂ ਨੂੰ ਇਕੱਤਰ ਕਰਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ S3 'ਤੇ ਅੱਪਲੋਡ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਇਹ ਬਹੁਤ ਵਧੀਆ ਤਰੀਕਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, iam-user-1.0.0.zip ਫਾਈਲ ਦਾ ਵਜ਼ਨ ਸਿਰਫ 1 Kb ਹੋਵੇਗਾ, ਕਿਉਂਕਿ ਇਸ ਸਰੋਤ ਨੂੰ ਬਣਾਉਣ ਲਈ ਕੋਡ ਬਹੁਤ ਛੋਟਾ ਹੈ। ਅਤੇ ਇਹ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰੇਗਾ.

ਆਉ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰੀਏ ਕਿ ਮੈਡਿਊਲਾਂ ਵਿੱਚ ਕੀ ਨਹੀਂ ਵਰਤਿਆ ਜਾ ਸਕਦਾ।

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

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

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

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

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

ਅਸਲ ਵਿੱਚ, ਹਾਂ, ਇਸ ਵਿੱਚ ਕੁਝ ਵੀ ਗਲਤ ਨਹੀਂ ਹੈ. ਪਰ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ ਜਲਦੀ ਹੀ ਤੁਹਾਨੂੰ ਇਹ ਅਹਿਸਾਸ ਹੋਵੇਗਾ ਕਿ ਇਹ ਲੋਕਲ-ਐਗਜ਼ੀਕੇਸ਼ਨ ਚੀਜ਼ ਮੌਜੂਦ ਨਹੀਂ ਹੈ, ਉਦਾਹਰਨ ਲਈ, launch_configuration ਵਿੱਚ।

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

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

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

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

ਲਿੰਕ ਨੂੰ http://bit.ly/common-traits-in-terraform-modules

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

ਜੇ ਤੁਸੀਂ ਕੁਝ ਲਿਖਣਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਜੋ ਲੋਕ ਇਸਦੀ ਵਰਤੋਂ ਕਰਨ, ਤਾਂ ਮੈਂ ਇਹਨਾਂ ਸੰਕੇਤਾਂ ਦੀ ਪਾਲਣਾ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ.

ਇਹ ਹੈ:

• ਦਸਤਾਵੇਜ਼ ਅਤੇ ਉਦਾਹਰਣ.
• ਪੂਰੀ ਕਾਰਜਕੁਸ਼ਲਤਾ.
• ਵਾਜਬ ਪੂਰਵ-ਨਿਰਧਾਰਤ।
• ਸਾਫ਼ ਕੋਡ.
• ਟੈਸਟ.

ਟੈਸਟ ਇੱਕ ਵੱਖਰੀ ਸਥਿਤੀ ਹਨ ਕਿਉਂਕਿ ਉਹਨਾਂ ਨੂੰ ਲਿਖਣਾ ਕਾਫ਼ੀ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ। ਮੈਂ ਦਸਤਾਵੇਜ਼ਾਂ ਅਤੇ ਉਦਾਹਰਣਾਂ ਵਿੱਚ ਵਧੇਰੇ ਵਿਸ਼ਵਾਸ ਕਰਦਾ ਹਾਂ।

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

ਇਹ ਦਸਤਾਵੇਜ਼ ਦਾ ਸਲੇਟੀ ਹਿੱਸਾ ਹੈ। ਤੁਸੀਂ ਹੁਣ ਸੋਚ ਰਹੇ ਹੋਵੋਗੇ: “ਕੁਝ ਅਸਪਸ਼ਟ ਹੈ। ਯਕੀਨ ਨਹੀਂ ਹੋਇਆ।" ਪਰ ਅਸੀਂ ਛੇ ਮਹੀਨਿਆਂ ਵਿੱਚ ਦੇਖਾਂਗੇ।

ਆਉ ਹੁਣ ਗੱਲ ਕਰਦੇ ਹਾਂ ਕਿ ਇਹਨਾਂ ਮੋਡਿਊਲਾਂ ਨੂੰ ਕਿਵੇਂ ਕਾਲ ਕਰਨਾ ਹੈ।

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

ਦੋ ਅਤਿ ਹਨ। ਪਹਿਲੀ ਅਤਿਅੰਤ ਸਭ ਇੱਕ ਵਿੱਚ ਹੈ. ਸਾਡੇ ਕੋਲ ਇੱਕ ਮਾਸਟਰ ਫਾਈਲ ਹੈ। ਫਿਲਹਾਲ, ਟੈਰਾਫਾਰਮ ਵੈੱਬਸਾਈਟ 'ਤੇ ਇਹ ਅਧਿਕਾਰਤ ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸ ਸੀ।

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

ਬਹੁਤ ਸਾਰਾ ਸਮਾਂ ਹੈ, ਉਦਾਹਰਨ ਲਈ, 5 ਮਿੰਟ। ਕੁਝ ਲਈ ਇਹ ਬਹੁਤ ਸਮਾਂ ਹੁੰਦਾ ਹੈ। ਮੈਂ ਅਜਿਹੇ ਕੇਸ ਦੇਖੇ ਹਨ ਜਿੱਥੇ 15 ਮਿੰਟ ਲੱਗੇ। AWS API ਨੇ ਇਹ ਪਤਾ ਲਗਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਵਿੱਚ 15 ਮਿੰਟ ਬਿਤਾਏ ਕਿ ਹਰੇਕ ਸਰੋਤ ਦੀ ਸਥਿਤੀ ਨਾਲ ਕੀ ਹੋ ਰਿਹਾ ਹੈ। ਇਹ ਬਹੁਤ ਵੱਡਾ ਇਲਾਕਾ ਹੈ।

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

ਦੂਸਰਾ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਇਸ ਖੇਤਰ ਨੂੰ ਘੱਟ ਕੀਤਾ ਜਾਵੇ, ਯਾਨੀ ਕਿ ਇੱਕ ਥਾਂ ਤੋਂ ਕਾਲਾਂ ਦੂਜੀ ਥਾਂ ਤੋਂ ਘੱਟ ਜੁੜ ਸਕਦੀਆਂ ਹਨ।

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

ਇਹ ਸਭ ਇੱਕ ਥਾਂ 'ਤੇ ਕਿਸ ਕੋਲ ਰਹਿੰਦਾ ਹੈ? ਇੱਕ, ਦੋ, ਤਿੰਨ ਲੋਕ, ਭਾਵ, ਕੋਈ ਇਸਨੂੰ ਵਰਤ ਰਿਹਾ ਹੈ।

ਅਤੇ ਕੌਣ ਇੱਕ ਖਾਸ ਹਿੱਸੇ, ਇੱਕ ਬਲਾਕ ਜਾਂ ਇੱਕ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਮੋਡੀਊਲ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ? ਪੰਜ ਸੱਤ ਜਣੇ। ਇਹ ਠੰਡਾ ਹੈ।

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

ਜੇ ਸਟੈਕ VPC ਵਿੱਚ ਕੁਝ ਬਦਲ ਗਿਆ ਹੈ ਅਤੇ ਤੁਸੀਂ ਇਹਨਾਂ ਤਬਦੀਲੀਆਂ ਨੂੰ EC2 ਵਿੱਚ ਲਾਗੂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਭਾਵ ਤੁਸੀਂ ਆਟੋਸਕੇਲਿੰਗ ਸਮੂਹ ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ ਕਿਉਂਕਿ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਨਵਾਂ ਸਬਨੈੱਟ ਸੀ, ਤਾਂ ਮੈਂ ਇਸ ਕਿਸਮ ਦੀ ਨਿਰਭਰਤਾ ਆਰਕੈਸਟਰੇਸ਼ਨ ਨੂੰ ਕਾਲ ਕਰਦਾ ਹਾਂ। ਕੁਝ ਹੱਲ ਹਨ: ਕੌਣ ਕੀ ਵਰਤਦਾ ਹੈ?

ਮੈਂ ਸੁਝਾਅ ਦੇ ਸਕਦਾ ਹਾਂ ਕਿ ਇੱਥੇ ਕਿਹੜੇ ਹੱਲ ਹਨ। ਤੁਸੀਂ ਜਾਦੂ ਕਰਨ ਲਈ ਟੈਰਾਫਾਰਮ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ, ਜਾਂ ਤੁਸੀਂ ਟੈਰਾਫਾਰਮ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਮੇਕਫਾਈਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ। ਅਤੇ ਦੇਖੋ ਕਿ ਕੀ ਉੱਥੇ ਕੁਝ ਬਦਲਿਆ ਹੈ, ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਥੇ ਲਾਂਚ ਕਰ ਸਕਦੇ ਹੋ।

ਤੁਸੀਂ ਇਹ ਫੈਸਲਾ ਕਿਵੇਂ ਪਸੰਦ ਕਰਦੇ ਹੋ? ਕੀ ਕੋਈ ਮੰਨਦਾ ਹੈ ਕਿ ਇਹ ਇੱਕ ਵਧੀਆ ਹੱਲ ਹੈ? ਮੈਂ ਇੱਕ ਮੁਸਕਰਾਹਟ ਵੇਖਦਾ ਹਾਂ, ਜ਼ਾਹਰ ਤੌਰ 'ਤੇ ਸ਼ੱਕ ਪੈਦਾ ਹੋ ਗਿਆ ਹੈ।

ਬੇਸ਼ੱਕ, ਘਰ ਵਿੱਚ ਇਸ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ. ਟੈਰਾਫਾਰਮ ਨੂੰ ਕਦੇ ਵੀ ਟੈਰਾਫਾਰਮ ਤੋਂ ਚਲਾਉਣ ਲਈ ਤਿਆਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ।

ਇੱਕ ਰਿਪੋਰਟ 'ਤੇ ਉਨ੍ਹਾਂ ਨੇ ਮੈਨੂੰ ਕਿਹਾ: "ਨਹੀਂ, ਇਹ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ।" ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਇਹ ਕੰਮ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ. ਹਾਲਾਂਕਿ ਇਹ ਬਹੁਤ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਲੱਗਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਟੈਰਾਫਾਰਮ ਤੋਂ ਟੈਰਾਫਾਰਮ ਲਾਂਚ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਫਿਰ ਟੈਰਾਫਾਰਮ, ਤੁਹਾਨੂੰ ਅਜਿਹਾ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ। ਟੈਰਾਫਾਰਮ ਹਮੇਸ਼ਾ ਬਹੁਤ ਆਸਾਨੀ ਨਾਲ ਸ਼ੁਰੂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

https://github.com/gruntwork-io/terragrunt/

ਜੇ ਤੁਹਾਨੂੰ ਇੱਕ ਥਾਂ 'ਤੇ ਕੁਝ ਬਦਲ ਜਾਣ 'ਤੇ ਕਾਲ ਆਰਕੈਸਟ੍ਰੇਸ਼ਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਟੈਰਾਗ੍ਰੰਟ ਹੈ।

Terragrunt ਇੱਕ ਉਪਯੋਗਤਾ ਹੈ, ਟੈਰਾਫਾਰਮ ਲਈ ਇੱਕ ਐਡ-ਆਨ, ਜੋ ਤੁਹਾਨੂੰ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਮੋਡੀਊਲਾਂ ਲਈ ਕਾਲਾਂ ਦਾ ਤਾਲਮੇਲ ਅਤੇ ਆਰਕੈਸਟ੍ਰੇਟ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ।

ਇੱਕ ਆਮ Terraform ਸੰਰਚਨਾ ਫਾਇਲ ਇਸ ਤਰ੍ਹਾਂ ਦਿਸਦੀ ਹੈ।

ਤੁਸੀਂ ਨਿਸ਼ਚਿਤ ਕਰਦੇ ਹੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਖਾਸ ਮੋਡੀਊਲ ਨੂੰ ਕਾਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।

ਮੋਡੀਊਲ ਵਿੱਚ ਕਿਹੜੀਆਂ ਨਿਰਭਰਤਾਵਾਂ ਹਨ?

ਅਤੇ ਇਹ ਮੋਡੀਊਲ ਕਿਹੜੀਆਂ ਦਲੀਲਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ। ਟੈਰਾਗ੍ਰੰਟ ਬਾਰੇ ਜਾਣਨ ਲਈ ਬੱਸ ਇਹੀ ਹੈ।

ਦਸਤਾਵੇਜ਼ ਉੱਥੇ ਹੈ, ਅਤੇ GitHub 'ਤੇ 1 ਤਾਰੇ ਹਨ। ਪਰ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇਹ ਉਹੀ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਜਾਣਨ ਦੀ ਲੋੜ ਹੈ। ਅਤੇ ਇਹ ਉਹਨਾਂ ਕੰਪਨੀਆਂ ਵਿੱਚ ਲਾਗੂ ਕਰਨਾ ਬਹੁਤ ਆਸਾਨ ਹੈ ਜੋ ਹੁਣੇ ਹੀ Terraform ਨਾਲ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਰਹੀਆਂ ਹਨ।

ਇਸ ਲਈ ਆਰਕੈਸਟਰੇਸ਼ਨ ਟੈਰਾਗ੍ਰੰਟ ਹੈ। ਹੋਰ ਵਿਕਲਪ ਹਨ.

ਹੁਣ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰੀਏ ਕਿ ਕੋਡ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ।

ਜੇਕਰ ਤੁਹਾਨੂੰ ਆਪਣੇ ਕੋਡ ਵਿੱਚ ਨਵੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇਹ ਆਸਾਨ ਹੁੰਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਨਵਾਂ ਸਰੋਤ ਲਿਖ ਰਹੇ ਹੋ, ਸਭ ਕੁਝ ਸਧਾਰਨ ਹੈ।

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

ਅਤੇ ਬਲਾਕ ਸਰੋਤ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਨਵੇਂ ਸਰੋਤਾਂ ਦੀ ਸਿਰਜਣਾ ਦਾ ਸਮਰਥਨ ਕੀਤਾ.

ਆਉਟਪੁੱਟ 'ਤੇ ਅਸੀਂ ਹਮੇਸ਼ਾ ਆਉਟਪੁੱਟ ਆਈਡੀ ਵਾਪਸ ਕਰਦੇ ਹਾਂ ਜੋ ਇਸ ਗੱਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਵਰਤਿਆ ਗਿਆ ਸੀ।

ਟੈਰਾਫਾਰਮ 0.11 ਵਿੱਚ ਦੂਜੀ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਸਮੱਸਿਆ ਸੂਚੀਆਂ ਨਾਲ ਕੰਮ ਕਰ ਰਹੀ ਹੈ।

ਮੁਸ਼ਕਲ ਇਹ ਹੈ ਕਿ ਜੇ ਸਾਡੇ ਕੋਲ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਅਜਿਹੀ ਸੂਚੀ ਹੈ.

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

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

ਇਹ ਹੱਲ ਹੈ। ਇਹ Jsonnet ਵਿੱਚ ਲਿਖਿਆ ਕੋਡ ਹੈ। Jsonnet ਗੂਗਲ ਦੀ ਇੱਕ ਟੈਂਪਲੇਟਿੰਗ ਭਾਸ਼ਾ ਹੈ।

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

ਟੈਂਪਲੇਟ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦਾ ਹੈ।

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

ਅਤੇ ਫਿਰ ਅਸੀਂ ਇਸ ਨਾਲ ਆਮ ਵਾਂਗ ਕੰਮ ਕਰਦੇ ਹਾਂ: ਟੈਰਾਫਾਰਮ ਇਨਿਟ, ਟੈਰਾਮੌਰਮ ਲਾਗੂ। ਅਤੇ ਅਸੀਂ ਦੋ ਉਪਭੋਗਤਾ ਬਣਾਉਂਦੇ ਹਾਂ.

ਹੁਣ ਸਾਨੂੰ ਡਰ ਨਹੀਂ ਜੇਕਰ ਕੋਈ ਟੀਮ ਛੱਡਦਾ ਹੈ। ਅਸੀਂ ਸਿਰਫ json ਫਾਈਲ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਾਂਗੇ। ਵਸਿਆ ਪੁਪਕਿਨ ਛੱਡ ਦਿੱਤਾ, ਪੇਟੀਆ ਪਾਇਟੋਚਿਨ ਰਿਹਾ. Petya Pyatochkin ਇੱਕ ਨਵੀਂ ਕੁੰਜੀ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰੇਗਾ.

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

ਪਰ ਹਾਲਾਤ ਉਦੋਂ ਪੈਦਾ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਅਸੀਂ ਟੈਰਾਫਾਰਮ ਨੂੰ ਵਧਾਉਣਾ ਚਾਹੁੰਦੇ ਹਾਂ ਅਤੇ ਕੁਝ ਪੂਰਾ ਹੋਣ ਤੋਂ ਬਾਅਦ ਕੁਝ ਕਮਾਂਡ ਨੂੰ ਕਾਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ।

ਪਹਿਲਾ ਤਰੀਕਾ। ਅਸੀਂ ਇੱਕ ਆਉਟਪੁੱਟ ਬਣਾਉਂਦੇ ਹਾਂ ਜਿੱਥੇ ਅਸੀਂ ਇਹ ਕਮਾਂਡ ਲਿਖਦੇ ਹਾਂ।

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

ਦੂਜਾ ਤਰੀਕਾ. ਇਹ ਸਾਡੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਦੇ ਅਧਾਰ ਤੇ null_resource ਦੀ ਵਰਤੋਂ ਹੈ। ਜਿਵੇਂ ਹੀ ਅਸੀਂ ਕੁਝ ਸਰੋਤਾਂ ਦੀ ਆਈਡੀ ਵਿੱਚ ਤਬਦੀਲੀ ਕਰਦੇ ਹਾਂ ਤਾਂ ਅਸੀਂ ਉਸੇ ਸਥਾਨਕ-ਐਕਸੀ ਨੂੰ ਕਾਲ ਕਰ ਸਕਦੇ ਹਾਂ।

ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, ਇਹ ਸਭ ਕਾਗਜ਼ 'ਤੇ ਨਿਰਵਿਘਨ ਹੈ, ਕਿਉਂਕਿ ਐਮਾਜ਼ਾਨ, ਹੋਰ ਸਾਰੇ ਜਨਤਕ ਪ੍ਰਦਾਤਾਵਾਂ ਵਾਂਗ, ਇਸਦੇ ਆਪਣੇ ਕਿਨਾਰੇ ਦੇ ਕੇਸਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਹੈ.

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

ਇੱਥੇ ਕੁਝ ਚੀਜ਼ਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਤੋਂ ਮੈਂ ਬਚਣ ਦੀ ਸਿਫ਼ਾਰਸ਼ ਕਰਦਾ ਹਾਂ।

ਸ਼ੁਰੂ ਕਰਨ ਲਈ, ਟੈਰਾਫਾਰਮ ਪਲਾਨ ਜਾਂ ਟੈਰਾਫਾਰਮ CLI ਦੇ ਅੰਦਰ ਸਾਰੀਆਂ ਗੈਰ-ਗੁਪਤ ਦਲੀਲਾਂ ਤੋਂ ਬਚੋ। ਇਹ ਸਭ ਜਾਂ ਤਾਂ ਇੱਕ tfvars ਫਾਈਲ ਵਿੱਚ ਜਾਂ ਇੱਕ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ ਵਿੱਚ ਰੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ।

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

ਨਾਲ ਹੀ, ਦਾਇਰੇ ਨੂੰ ਘਟਾਉਣ ਲਈ ਟਾਰਗੇਟ ਆਰਗੂਮੈਂਟਾਂ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ। ਇਸਦੇ ਲਈ ਛੋਟੇ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਮਾਡਿਊਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਬਹੁਤ ਸੌਖਾ ਹੈ।

ਨਾਲ ਹੀ, ਸਮਾਨਤਾ ਨੂੰ ਸੀਮਤ ਕਰਨ ਅਤੇ ਵਧਾਉਣ ਦੀ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ. ਜੇ ਮੇਰੇ ਕੋਲ 150 ਸਰੋਤ ਹਨ ਅਤੇ ਮੈਂ ਐਮਾਜ਼ਾਨ ਸਮਾਨਤਾ ਨੂੰ ਡਿਫਾਲਟ 10 ਤੋਂ 100 ਤੱਕ ਵਧਾਉਣਾ ਚਾਹੁੰਦਾ ਹਾਂ, ਤਾਂ ਸਭ ਤੋਂ ਵੱਧ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਕੁਝ ਗਲਤ ਹੋ ਜਾਵੇਗਾ. ਜਾਂ ਇਹ ਹੁਣ ਠੀਕ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਜਦੋਂ ਐਮਾਜ਼ਾਨ ਕਹਿੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਬਹੁਤ ਸਾਰੀਆਂ ਕਾਲਾਂ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਮੁਸੀਬਤ ਵਿੱਚ ਹੋਵੋਗੇ।

ਟੈਰਾਫਾਰਮ ਇਹਨਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ, ਪਰ ਤੁਸੀਂ ਲਗਭਗ ਕੁਝ ਵੀ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰ ਸਕੋਗੇ। Parallelism=1 ਵਰਤਣ ਲਈ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਚੀਜ਼ ਹੈ ਜੇਕਰ ਤੁਸੀਂ AWS API ਦੇ ਅੰਦਰ ਜਾਂ Terraform ਪ੍ਰਦਾਤਾ ਦੇ ਅੰਦਰ ਕੁਝ ਬੱਗ ਨੂੰ ਠੋਕਰ ਖਾਂਦੇ ਹੋ। ਅਤੇ ਫਿਰ ਤੁਹਾਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ: parallelism=1 ਅਤੇ ਟੇਰਾਫਾਰਮ ਇੱਕ ਕਾਲ, ਫਿਰ ਦੂਜੀ, ਫਿਰ ਤੀਜੀ ਕਾਲ ਪੂਰੀ ਹੋਣ ਤੱਕ ਉਡੀਕ ਕਰੋ। ਉਹ ਉਨ੍ਹਾਂ ਨੂੰ ਇਕ-ਇਕ ਕਰਕੇ ਲਾਂਚ ਕਰੇਗਾ।

ਲੋਕ ਅਕਸਰ ਮੈਨੂੰ ਪੁੱਛਦੇ ਹਨ, "ਮੈਨੂੰ ਕਿਉਂ ਲੱਗਦਾ ਹੈ ਕਿ ਟੈਰਾਫਾਰਮ ਵਰਕਸਪੇਸ ਬੁਰਾਈਆਂ ਹਨ?" ਮੇਰਾ ਮੰਨਣਾ ਹੈ ਕਿ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਸਿਧਾਂਤ ਇਹ ਦੇਖਣਾ ਹੈ ਕਿ ਕਿਹੜਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਬਣਾਇਆ ਗਿਆ ਹੈ ਅਤੇ ਕਿਹੜੇ ਮੁੱਲਾਂ ਦੇ ਨਾਲ.

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

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

ਰਿਪੋਰਟ ਦਾ ਵਿਸ਼ਾ "ਭਵਿੱਖ ਲਈ" ਲਿਖਿਆ ਗਿਆ ਸੀ। ਮੈਂ ਇਸ ਬਾਰੇ ਬਹੁਤ ਸੰਖੇਪ ਵਿੱਚ ਗੱਲ ਕਰਾਂਗਾ। ਭਵਿੱਖ ਲਈ, ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ 0.12 ਨੂੰ ਜਲਦੀ ਹੀ ਜਾਰੀ ਕੀਤਾ ਜਾਵੇਗਾ.

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

ਪਰ! ਜੇ ਤੁਸੀਂ ਤਿਆਰ-ਮੇਡ ਮੋਡੀਊਲ ਅਤੇ ਤੀਜੀ-ਧਿਰ ਦੇ ਹੱਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਘੱਟ ਅਤੇ ਵਧੇਰੇ ਅਸਾਨੀ ਨਾਲ ਲਿਖਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਉਡੀਕ ਨਹੀਂ ਕਰਨੀ ਪਵੇਗੀ ਅਤੇ ਉਮੀਦ ਹੈ ਕਿ 0.12 ਆਵੇਗਾ ਅਤੇ ਤੁਹਾਡੇ ਲਈ ਸਭ ਕੁਝ ਠੀਕ ਕਰ ਦੇਵੇਗਾ।

ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ! ਤੁਸੀਂ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਬਾਰੇ ਕੋਡ ਦੇ ਤੌਰ 'ਤੇ ਗੱਲ ਕੀਤੀ ਅਤੇ ਸ਼ਾਬਦਿਕ ਤੌਰ 'ਤੇ ਟੈਸਟਾਂ ਬਾਰੇ ਇੱਕ ਸ਼ਬਦ ਕਿਹਾ। ਕੀ ਮਾਡਿਊਲਾਂ ਵਿੱਚ ਟੈਸਟਾਂ ਦੀ ਲੋੜ ਹੈ? ਇਹ ਕਿਸਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ? ਕੀ ਮੈਨੂੰ ਇਸਨੂੰ ਖੁਦ ਲਿਖਣ ਦੀ ਲੋੜ ਹੈ ਜਾਂ ਕੀ ਇਹ ਮੋਡੀਊਲ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਹੈ?

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

ਮੈਂ ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਸਰਗਰਮੀ ਨਾਲ ਖੋਜ ਕਰ ਰਿਹਾ/ਰਹੀ ਹਾਂ, ਜਿਵੇਂ ਕਿ ਤੁਹਾਡੇ ਦੁਆਰਾ ਲਿਖੇ ਗਏ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਆਧਾਰ 'ਤੇ ਆਪਣੇ ਆਪ ਟੈਸਟ ਕਿਵੇਂ ਤਿਆਰ ਕੀਤੇ ਜਾਣ। ਭਾਵ, ਜੇਕਰ ਤੁਸੀਂ ਇਹ ਕੋਡ ਲਿਖਿਆ ਹੈ, ਤਾਂ ਮੈਨੂੰ ਇਸਨੂੰ ਚਲਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ, ਇਸਦੇ ਅਧਾਰ ਤੇ ਮੈਂ ਟੈਸਟ ਬਣਾ ਸਕਦਾ ਹਾਂ.

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

ਐਂਟਨ, ਰਿਪੋਰਟ ਲਈ ਧੰਨਵਾਦ! ਮੇਰਾ ਨਾਮ ਵੈਲੇਰੀ ਹੈ। ਮੈਨੂੰ ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਦਾਰਸ਼ਨਿਕ ਸਵਾਲ ਪੁੱਛਣ ਦਿਓ। ਉੱਥੇ, ਸ਼ਰਤ ਅਨੁਸਾਰ, ਵਿਵਸਥਾ ਹੈ, ਉੱਥੇ ਤਾਇਨਾਤੀ ਹੈ। ਪ੍ਰੋਵੀਜ਼ਨਿੰਗ ਮੇਰਾ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਬਣਾਉਂਦੀ ਹੈ, ਤੈਨਾਤੀ ਵਿੱਚ ਅਸੀਂ ਇਸਨੂੰ ਕੁਝ ਉਪਯੋਗੀ ਨਾਲ ਭਰਦੇ ਹਾਂ, ਉਦਾਹਰਨ ਲਈ, ਸਰਵਰ, ਐਪਲੀਕੇਸ਼ਨ, ਆਦਿ। ਅਤੇ ਇਹ ਮੇਰੇ ਦਿਮਾਗ ਵਿੱਚ ਹੈ ਕਿ ਟੈਰਾਫਾਰਮ ਪ੍ਰੋਵੀਜ਼ਨਿੰਗ ਲਈ ਵਧੇਰੇ ਹੈ, ਅਤੇ ਜਵਾਬਦੇਹ ਤੈਨਾਤੀ ਲਈ ਵਧੇਰੇ ਹੈ, ਕਿਉਂਕਿ ਜਵਾਬਦੇਹ ਭੌਤਿਕ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਲਈ ਵੀ ਹੈ। ਤੁਹਾਨੂੰ nginx, Postgres ਨੂੰ ਸਥਾਪਿਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ. ਪਰ ਇਸਦੇ ਨਾਲ ਹੀ, ਜਵਾਬਦੇਹੀ, ਉਦਾਹਰਨ ਲਈ, ਐਮਾਜ਼ਾਨ ਜਾਂ ਗੂਗਲ ਸਰੋਤਾਂ ਦੀ ਵਿਵਸਥਾ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਜਾਪਦੀ ਹੈ। ਪਰ ਟੈਰਾਫਾਰਮ ਤੁਹਾਨੂੰ ਇਸਦੇ ਮੋਡੀਊਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਕੁਝ ਸੌਫਟਵੇਅਰ ਤਾਇਨਾਤ ਕਰਨ ਦੀ ਵੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਤੁਹਾਡੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਕੀ ਕੋਈ ਅਜਿਹੀ ਸਰਹੱਦ ਹੈ ਜੋ ਟੈਰਾਫਾਰਮ ਅਤੇ ਜਵਾਬਦੇਹ ਦੇ ਵਿਚਕਾਰ ਚਲਦੀ ਹੈ, ਕਿੱਥੇ ਅਤੇ ਕੀ ਵਰਤਣਾ ਬਿਹਤਰ ਹੈ? ਜਾਂ, ਉਦਾਹਰਨ ਲਈ, ਕੀ ਤੁਸੀਂ ਸੋਚਦੇ ਹੋ ਕਿ Ansible ਪਹਿਲਾਂ ਹੀ ਕੂੜਾ ਹੈ, ਤੁਹਾਨੂੰ ਹਰ ਚੀਜ਼ ਲਈ Terraform ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ?

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

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

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

ਲੋਕ ਬਰਾਬਰ ਸਫਲਤਾ ਨਾਲ ਦੋਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ. ਇਹ ਮੈਨੂੰ ਜਾਪਦਾ ਹੈ ਕਿ Ansible ਵਿੱਚ ਗਤੀਸ਼ੀਲ ਵਸਤੂ ਇੱਕ ਸੁਵਿਧਾਜਨਕ ਚੀਜ਼ ਹੈ, ਜੇਕਰ ਅਸੀਂ ਆਟੋਸਕੇਲਿੰਗ ਸਮੂਹ ਬਾਰੇ ਗੱਲ ਨਹੀਂ ਕਰ ਰਹੇ ਹਾਂ. ਕਿਉਂਕਿ ਆਟੋਸਕੇਲਿੰਗ ਗਰੁੱਪ ਵਿੱਚ ਸਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਸਾਡੀ ਆਪਣੀ ਟੂਲਕਿੱਟ ਹੈ, ਜਿਸਨੂੰ launch_configuration ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਲਾਂਚ_ਸੰਰਚਨਾ ਵਿੱਚ ਅਸੀਂ ਉਹ ਸਭ ਕੁਝ ਰਿਕਾਰਡ ਕਰਦੇ ਹਾਂ ਜੋ ਲਾਂਚ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਅਸੀਂ ਇੱਕ ਨਵਾਂ ਸਰੋਤ ਬਣਾਉਂਦੇ ਹਾਂ। ਇਸ ਲਈ, ਐਮਾਜ਼ਾਨ ਦੇ ਨਾਲ, ਗਤੀਸ਼ੀਲ ਵਸਤੂ ਸੂਚੀ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਅਤੇ ਟੈਰਾਫਾਰਮ ਟੀਐਸ ਫਾਈਲ ਨੂੰ ਪੜ੍ਹਨਾ, ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਓਵਰਕਿਲ ਹੈ. ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ ਦੂਜੇ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ ਜਿੱਥੇ "ਆਟੋਸਕੇਲਿੰਗ ਗਰੁੱਪ" ਦੀ ਕੋਈ ਧਾਰਨਾ ਨਹੀਂ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਤੁਸੀਂ DigitalOcean ਜਾਂ ਕੋਈ ਹੋਰ ਪ੍ਰਦਾਤਾ ਵਰਤਦੇ ਹੋ ਜਿੱਥੇ ਕੋਈ ਆਟੋਸਕੇਲਿੰਗ ਗਰੁੱਪ ਨਹੀਂ ਹੈ, ਤਾਂ ਉੱਥੇ ਤੁਹਾਨੂੰ ਹੱਥੀਂ API ਨੂੰ ਖਿੱਚਣਾ ਪਵੇਗਾ, IP ਐਡਰੈੱਸ ਲੱਭਣਾ ਪਵੇਗਾ, ਬਣਾਉਣਾ ਹੋਵੇਗਾ। ਇੱਕ ਡਾਇਨਾਮਿਕ ਇਨਵੈਂਟਰੀ ਫਾਈਲ , ਅਤੇ Ansible ਪਹਿਲਾਂ ਹੀ ਇਸ ਵਿੱਚ ਭਟਕ ਜਾਵੇਗਾ। ਭਾਵ, ਐਮਾਜ਼ਾਨ ਲਈ ਲਾਂਚ_ਸੰਰਚਨਾ ਹੈ, ਅਤੇ ਹਰ ਚੀਜ਼ ਲਈ ਗਤੀਸ਼ੀਲ ਵਸਤੂ ਸੂਚੀ ਹੈ।

ਸਰੋਤ: www.habr.com