21 ਜੁਲਾ 2025·8 ਮਿੰਟ
Terraform ਅਤੇ Vagrant: ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਅਤੇ ਡਿਲਿਵਰੀ ਨੂੰ ਜੋੜਨਾ
ਜਾਣੋ ਕਿ Mitchell Hashimoto ਦੇ HashiCorp ਟੂਲ—Terraform ਅਤੇ Vagrant—ਟੀਮਾਂ ਨੂੰ ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਸਟੈਂਡਰਡ ਕਰਨ ਅਤੇ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਡਿਲਿਵਰੀ ਵਰਕਫਲੋ ਬਣਾਉਣ ਵਿੱਚ ਕਿਵੇਂ ਮਦਦ ਕਰਦੇ ਹਨ।
ਜਾਣੋ ਕਿ Mitchell Hashimoto ਦੇ HashiCorp ਟੂਲ—Terraform ਅਤੇ Vagrant—ਟੀਮਾਂ ਨੂੰ ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਸਟੈਂਡਰਡ ਕਰਨ ਅਤੇ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਡਿਲਿਵਰੀ ਵਰਕਫਲੋ ਬਣਾਉਣ ਵਿੱਚ ਕਿਵੇਂ ਮਦਦ ਕਰਦੇ ਹਨ।
ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਡਿਲਿਵਰੀ صرف ਕੋਡ ਭੇਜਣ ਦੀ ਗੱਲ ਨਹੀਂ। ਇਹ ਇਸ ਗੱਲ ਨੂੰ ਭਰੋਸੇ ਨਾਲ ਜਵਾਬ ਦੇਣ ਯੋਗ ਹੋਣ ਬਾਰੇ ਹੈ: ਕੀ ਬਦਲੇਗਾ? ਕਿਉਂ ਬਦਲੇਗਾ? ਅਤੇ ਕੀ ਅਸੀਂ ਇਹ ਕੱਲ੍ਹ ਦੁਬਾਰਾ ਕਰ ਸਕਦੇ ਹਾਂ? ਜਦੋਂ ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਹੱਥੋਂ-ਹੱਥ ਬਣਾਈ ਜਾਂਦੀ ਹੈ—ਜਾਂ ਡੈਵਲਪਰ ਮਸ਼ੀਨਾਂ ਸਮੇਂ ਦੇ ਨਾਲ ਡ੍ਰਿਫਟ ਹੋ ਜਾਂਦੀਆਂ ਹਨ—ਡਿਲਿਵਰੀ ਇੱਕ ਅਨੁਮਾਨ ਖੇਡ ਬਣ ਜਾਂਦੀ ਹੈ: ਵੱਖ-ਵੱਖ ਵਾਤਾਵਰਣ, ਵੱਖ-ਵੱਖ ਨਤੀਜੇ, ਅਤੇ ਬਹੁਤ ਸਾਰਾ “ਮੇਰੇ ਲੈਪਟਾਪ 'ਤੇ ਚੱਲਦਾ ਹੈ।”
Terraform ਅਤੇ Vagrant ਦੋ ਦਿਸ਼ਾਵਾਂ ਤੋਂ ਇਸ ਅਣਨਿਸ਼ਚਿਤਤਾ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ: ਸਾਂਝੀ ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਅਤੇ ਸਾਂਝੇ ਡੈਵਲਪਮੈਂਟ ਵਾਤਾਵਰਣ।
Terraform ਇਨਫ੍ਰਾਸਟਰਕਚਰ (ਕਲਾਊਡ ਰਿਸੋਰਸ, ਨੈਟਵਰਕਿੰਗ, ਮੈਨੇਜਡ ਸਰਵਿਸਾਂ, ਅਤੇ ਕਈ ਵਾਰੀ SaaS ਕਨਫਿਗਰੇਸ਼ਨ) ਨੂੰ ਕੋਡ ਵਜੋਂ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਕਨਸੋਲ 'ਤੇ ਕਲਿੱਕ ਕਰਨ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਜੋ ਚਾਹੁੰਦੇ ਹੋ ਉਸਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦੇ ਹੋ, ਇੱਕ ਯੋਜਨਾ ਸਮੀਖਿਆ ਕਰਦੇ ਹੋ, ਅਤੇ ਬਦਲਾਅ ਲਗਾਤਾਰ ਲਾਗੂ ਕਰਦੇ ਹੋ।
ਮਕਸਦ “ਨਵਾਂਪਣ” ਨਹੀਂ—ਇਹ ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਬਦਲਾਅਾਂ ਨੂੰ ਵਿਜ਼ੀਬਲ, ਸਮੀਖਿਆਯੋਗ ਅਤੇ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਬਣਾਉਣਾ ਹੈ।
Vagrant ਇਕਸਾਰ ਡੈਵਲਪਮੈਂਟ ਵਾਤਾਵਰਣ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਟੀਮਾਂ ਨੂੰ ਇੱਕੋ ਬੇਸ ਸੈਟਅਪ—OS, ਪੈਕੇਜ ਅਤੇ ਕਨਫਿਗਰੇਸ਼ਨ—ਚਲਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਚਾਹੇ ਉਹ macOS, Windows, ਜਾਂ Linux ਉੱਤੇ ਹੋਣ।
ਜੇਕਰ ਤੁਸੀਂ ਹਰ ਰੋਜ਼ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਨਹੀਂ ਵਰਤ ਰਹੇ, ਫਿਰ ਵੀ Vagrant ਦਾ ਮੁੱਢਲਾ ਵਿਚਾਰ ਮਹੱਤਵਪੂਰਨ ਰਹਿੰਦਾ ਹੈ: ਡੈਵਲਪਰਾਂ ਨੂੰ ਇੱਕ ਜਾਣਿਆ-ਪਛਾਣਿਆ ਵਾਤਾਵਰਣ ਤੋਂ ਸ਼ੁਰੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜੋ ਸਾਫਟਵੇਅਰ ਦੇ ਅਸਲ ਚਲਣ ਨਾਲ ਮਿਲਦਾ ਜੁਲਦਾ ਹੋਵੇ।
ਇਹ ਇੱਕ ਪ੍ਰਯੋਗਕਰਣੀ ਵਾਕ-ਥਰੂ ਹੈ ਜੋ ਗੈਰ-ਮਾਹਿਰਾਂ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਘੱਟ ਜ਼ਿਆਦਾ ਬਜ਼ਵਰਡ ਅਤੇ ਜ਼ਿਆਦਾ ਸਪਸ਼ਟਤਾ ਚਾਹੀਦੀ ਹੈ। ਅਸੀਂ ਢੱਕਾਂਗੇ:
ਅੰਤ ਤੱਕ, ਤੁਸੀਂ ਅੰਦਾਜ਼ਾ ਲਗਾ ਸਕੋਗੇ ਕਿ Terraform, Vagrant, ਜਾਂ ਦੋਹਾਂ ਤੁਹਾਡੇ ਟੀਮ ਲਈ ਫਿੱਟ ਹਨ—ਅਤੇ ਕਿਸ ਤਰੀਕੇ ਨਾਲ ਉਹਨਾਂ ਨੂੰ ਗੁੰਝਲਦਾਰਤਾ ਵਧਾਏ ਬਿਨਾਂ ਅਪਨਾਇਆ ਜਾ ਸਕਦਾ ਹੈ।
Mitchell Hashimoto Vagrant ਬਣਾਉਣ ਅਤੇ HashiCorp ਨੂੰ ਕੋ-ਫਾਊਂਡ ਕਰਨ ਲਈ ਮਸ਼ਹੂਰ ਹਨ। ਲੰਬੇ ਸਮੇਂ ਲਈ ਯੋਗਦਾਨ ਸਿਰਫ਼ ਇਕ ਪ੍ਰੋਡਕਟ ਨਹੀਂ—ਇਹ ਇਹ ਵਿਚਾਰ ਹੈ ਕਿ ਟੂਲਿੰਗ ਟੀਮ ਦੇ ਵਰਕਫਲੋ ਨੂੰ ਕਿਸੇ ਐਸੇ ਚੀਜ਼ ਵਿੱਚ ਐਨਕੋਡ ਕਰ ਸਕਦੀ ਹੈ ਜੋ ਸਾਂਝਾ, ਸਮੀਖਿਆਯੋਗ ਅਤੇ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਹੋਵੇ।
ਜਦੋਂ ਲੋਕ ਕਹਿੰਦੇ ਹਨ “ਟੂਲਿੰਗ ਇੱਕ ਪੁਲ ਹੈ,” ਉਹ ਦੋ ਗਰੁੱਪਾਂ ਦੇ ਵਿਚਕਾਰ ਦੀ ਖਾਈ ਬੰਦ ਕਰਨ ਦੀ ਗੱਲ ਕਰਦੇ ਹਨ ਜੋ ਇੱਕੋ ਨਤੀਜੇ ਚਾਹੁੰਦੇ ਹਨ ਪਰ ਦਿਨ-ਪ੍ਰਤੀਦਿਨ ਵੱਖ-ਵੱਖ ਭਾਸ਼ਾ ਬੋਲਦੇ ਹਨ:
Hashimoto ਦਾ ਨਜ਼ਰੀਆ—ਜੋ HashiCorp ਟੂਲਜ਼ ਵਿੱਚ ਲਗਭਗ ਹਰ ਜਗ੍ਹਾ ਸੁਣਨ ਨੂੰ ਮਿਲਦਾ ਹੈ—ਇਹ ਹੈ ਕਿ ਪੁਲ ਇੱਕ ਵਰਕਫਲੋ ਜੋ ਹਰ ਕੋਈ ਦੇਖ ਸਕੇ ਹੈ। ਟੀਮਾਂ ਟਿਕਟਾਂ ਜਾਂ ਟ੍ਰਾਈਬਲ ਨੋਲੈਜ ਰਾਹੀਂ ਹੁਕਮ-ਹidearn ਨਾ ਭੇਜਣ ਦੀ ਥਾਂ, ਫੈਸਲੇ ਕੰਫਿਗਰੇਸ਼ਨ ਫਾਇਲਾਂ ਵਿੱਚ ਕੈਪਚਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਜ਼ਨ ਕੰਟਰੋਲ ਵਿੱਚ ਚੈੱਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇੱਕੋ ਹੁਕਮ ਹੁਕਮ ਦੇ ਅਨੁਸਾਰ ਚਲਾਏ ਜਾਂਦੇ ਹਨ।
ਟੂਲ ਇੱਕ ਰੈਫਰੀ ਬਣ ਜਾਂਦਾ ਹੈ: ਇਹ ਕਦਮਾਂ ਨੂੰ ਸਟੈਂਡਰਡ ਕਰਦਾ ਹੈ, ਕੀ ਬਦਲਿਆ ਇਹ ਦਰਜ ਕਰਦਾ ਹੈ, ਅਤੇ “ਮੇਰੇ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਦਾ ਹੈ” ਵਾਲੀਆਂ ਗੱਲਾਂ ਘਟਾਉਂਦਾ ਹੈ।
ਸਾਂਝੇ ਵਰਕਫਲੋ ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਅਤੇ ਵਾਤਾਵਰਣ ਨੂੰ ਇੱਕ ਪ੍ਰੋਡਕਟ-ਜਿਹੇ ਇੰਟਰਫੇਸ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ:
ਇਹ ਫਰੇਮਿੰਗ ਡਿਲਿਵਰੀ 'ਤੇ ਧਿਆਨ ਰੱਖਦੀ ਹੈ: ਟੂਲ صرف ਆਟੋਮੇਸ਼ਨ ਲਈ ਨਹੀਂ, ਉਹ ਸਹਿਮਤੀ ਲਈ ਵੀ ਹਨ। Terraform ਅਤੇ Vagrant ਇਸ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਵਿੱਚ ਫਿੱਟ ਬੈਠਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਇਰਾਦੇ ਵਾਲੀ ਸਥਿਤੀ ਨੂੰ ਸਪਸ਼ਟ ਕਰਦੇ ਹਨ ਅਤੇ ਉਹ ਅਭਿਆਸਾਂ ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦੇ ਹਨ (ਵਰਜ਼ਨਿੰਗ, ਸਮੀਖਿਆ, ਦੁਹਰਾਏ ਜਾਣ ਵਾਲੇ ਰਨ) ਜੋ ਕਿਸੇ ਇੱਕ ਵਿਅਕਤੀ ਦੀ ਯਾਦ ਤੋਂ ਬਾਹਰ ਸਕੇਲ ਕਰਦੇ ਹਨ।
ਜ਼ਿਆਦਾਤਰ ਡਿਲਿਵਰੀ ਦਰਦ “ਖਰਾਬ ਕੋਡ” ਕਰਕੇ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਵੱਖ-ਵੱਖ ਵਾਤਾਵਰਣ ਅਤੇ ਉਹਨਾਂ ਅਦ੍ਰਿਸ਼ਟ, ਹੱਥ-ਨਾਲ ਕਦਮਾਂ ਕਰਕੇ ਹੁੰਦਾ ਹੈ ਜੋ ਕੋਈ ਪੂਰੀ ਤਰ੍ਹਾਂ ਵਰਣਣ ਨਹੀਂ ਕਰ ਸਕਦਾ—ਜਦ ਤੱਕ ਕੁਝ ਟੁੱਟਦਾ ਨਹੀਂ।
ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਕੰਮ ਕਰਦਾ ਸੈਟਅਪ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਫਿਰ ਛੋਟੇ, ਸਮਝਦਾਰ ਬਦਲਾਅ ਕਰਦੀਆਂ ਹਨ: ਇੱਥੇ ਇੱਕ ਪੈਕੇਜ ਅੱਪਗਰੇਡ, ਉੱਥੇ ਇੱਕ ਫਾਇਰਵਾਲ ਟਵੀਕ, ਇੱਕ ਸਰਵਰ 'ਤੇ ਇਕ-ਵਾਰ ਦਾ ਹੌਟਫਿਕਸ ਕਿਉਂਕਿ “ਜਰੂਰੀ ਸੀ।” ਹਫ਼ਤਿਆਂ ਬਾਅਦ, ਡੈਵ ਲੈਪਟਾਪ, ਸਟੇਜਿੰਗ VM, ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਥੋੜ੍ਹੇ-ਥੋੜ੍ਹੇ ਵੱਖ-ਵੱਖ ਹੋ ਜਾਂਦੇ ਹਨ।
ਉਹ ਫਰਕ ਉਸ ਤਰ੍ਹਾਂ ਅਸਫਲਤਾਵਾਂ ਵਜੋਂ ਸਾਹਮਣੇ ਆਉਂਦੇ ਹਨ ਜੋ ਦੁਹਰਾਏ ਨਹੀੰ ਜਾ ਸਕਦੀਆਂ: ਟੈਸਟ ਲੋਕਲ ਤੌਰ 'ਤੇ ਪਾਸ ਹੁੰਦੇ ਹਨ ਪਰ CI ਵਿੱਚ ਫੇਲ; ਸਟੇਜਿੰਗ ਚੰਗਾ ਹੈ ਪਰ ਪ੍ਰੋਡਕਸ਼ਨ 500 ਦਿੰਦਾ ਹੈ; ਇੱਕ ਰੋਲਬੈਕ ਪਹਿਲਾ ਵਿਹਾਰ ਰੀਸਟਰ ਨੀੰ ਕਰਦਾ ਕਿਉਂਕਿ ਅਧਾਰਭੂਤ ਸਿਸਟਮ ਬਦਲ ਗਿਆ।
ਜਦੋਂ ਵਾਤਾਵਰਣ ਹੱਥੋਂ-ਹੱਥ ਬਣਾਏ ਜਾਂਦੇ ਹਨ, ਅਸਲ ਪ੍ਰਕਿਰਿਆ ਟ੍ਰਾਈਬਲ ਯਾਦ ਵਿੱਚ ਰਿਹੈ ਹੁੰਦੀ ਹੈ: ਕਿਹੜੇ OS ਪੈਕੇਜ ਇੰਸਟਾਲ ਕਰਨ, ਕਿਹੜੀਆਂ ਸਰਵਿਸਾਂ ਚਾਲੂ ਕਰਨ, ਕਿਹੜੇ ਕਰਨੇਲ ਸੈਟਿੰਗਸ ਟਵੀਕ ਕਰਨ, ਕਿਹੜੇ ਪੋਰਟ ਖੋਲ੍ਹਣ—ਅਤੇ ਕਿਸ ਕ੍ਰਮ ਵਿੱਚ।
ਨਵੇਂ ਆਏ ਲੋਕ "ਕੱਟ-ਕੱਟ" ਮਸ਼ੀਨ ਬਣਾਉਣ ਵਿੱਚ ਦਿਨ ਗੁਆ ਚੁੱਕਦੇ ਹਨ। ਸੀਨੀਅਰ ਇੰਜੀਨੀਅਰ ਬੇਸਿਕ ਸੈਟਅਪ ਪ੍ਰਸ਼ਨਾਂ ਲਈ ਬਾਟਲਨੈਕ ਬਣ ਜਾਂਦੇ ਹਨ।
ਨੁਕਸਾਨ ਮੁਮਕਿਨਤਾਂ ਆਮ ਹਨ:
.env ਵਿੱਚ ਨਕਲ ਕੀਤੇ ਜਾਂਦੇ, ਪਰ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਖਿੱਚੇ ਜਾਂਦੇ—ਡਿਪਲੌਇ ਫੇਲ ਜਾਂ, ਵੱਡੀ ਗੱਲ, ਸੀਕ੍ਰੇਟ ਲੀਕ ਹੋ ਜਾਂਦੇ।ਇਹ ਮੁੱਦੇ ਢਿੱਲੀ ਓਨਬੋਰਡਿੰਗ, ਲੰਮੇ ਲੀਡ ਟਾਈਮ, ਅਚਾਨਕ ਆਊਟੇਜ, ਅਤੇ ਦਰਦਨਾਕ ਰੋਲਬੈਕ ਵਿੱਚ ਬਦਲ ਜਾਂਦੇ ਹਨ। ਟੀਮ ਘੱਟ ਵਾਰ ਭੇਜਦੀ ਹੈ, ਘੱਟ ਭਰੋਸੇ ਨਾਲ, ਅਤੇ “ਇਹ ਵਾਤਾਵਰਣ ਕਿਉਂ ਵੱਖਰਾ ਹੈ” ਦਾ ਨਿਰਣੇ ਕਰਨ ਵਿੱਚ ਵਧੇਰੇ ਸਮਾਂ ਖ਼ਰਚਦੀ ਹੈ, ਨਾ ਕਿ ਪ੍ਰੋਡਕਟ ਸੁਧਾਰਣ ਵਿੱਚ।
Terraform Infrastructure as Code (IaC) ਹੈ: ਕਲਾਊਡ ਕੰਸੋਲ 'ਤੇ ਕਲਿੱਕ ਕਰਨ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਹਰ ਸੈਟਿੰਗ ਯਾਦ ਰੱਖਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਆਪਣੀ ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਨੂੰ ਫਾਇਲਾਂ ਵਿੱਚ ਵਰਣਨ ਕਰਦੇ ਹੋ।
ਇਹ ਫਾਇਲਾਂ ਆਮ ਤੌਰ 'ਤੇ Git ਵਿੱਚ ਰਹਿੰਦੀਆਂ ਹਨ, ਤਾਂ ਜੋ ਬਦਲਾਅ ਵਿਜ਼ੀਬਲ, ਸਮੀਖਿਆਯੋਗ, ਅਤੇ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਹੋਣ।
Terraform ਕਨਫਿਗਰੇਸ਼ਨ ਨੂੰ ਇਕ “ਬਿਲਡ ਨੁਸਖਾ” ਸਮਝੋ: ਨੈੱਟਵਰਕ, ਡੇਟਾਬੇਸ, ਲੋਡ ਬੈਲੈਂਸਰ, DNS ਰਿਕਾਰਡ, ਅਤੇ ਪੇਰਮਿਸ਼ਨ। ਤੁਸੀਂ ਪਿੱਛੇ ਤੋਂ ਡਾਕਯੂਮੈਂਟ ਨਹੀਂ ਕਰ ਰਹੇ—ਤੁਸੀਂ ਜੋ ਮੌਜੂਦ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਉਹ ਪਰਿਭਾਸ਼ਿਤ ਕਰ ਰਹੇ ਹੋ।
ਇਹ ਪਰਿਭਾਸ਼ਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਸਪਸ਼ਟ ਹੈ। ਜੇਕਰ ਕਿਸੇ ਟੀਮੀਮੇਟ ਨੂੰ ਇੱਕੋ ਵਾਤਾਵਰਣ ਚਾਹੀਦਾ ਹੈ, ਉਹ ਇਕੋ ਕਨਫਿਗਰੇਸ਼ਨ ਵਰਤ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਨੂੰ ਹਾਦਸੇ ਤੋਂ ਬਾਅਦ ਵਾਤਾਵਰਣ ਮੁੜ ਬਣਾਉਣੀ ਪਵੇ, ਤੁਸੀਂ ਉਹਨਾਂ ਹੀ ਸਰੋਤਾਂ ਤੋਂ ਕਰ ਸਕਦੇ ਹੋ।
Terraform ਚਾਹੀਦੀ ਸਥਿਤੀ ਦੇ ਆਸਪਾਸ ਕੰਮ ਕਰਦਾ ਹੈ: ਤੁਸੀਂ ਜੋ ਚਾਹੁੰਦੇ ਹੋ ਉਹ ਘੋਸ਼ਿਤ ਕਰਦੇ ਹੋ, ਅਤੇ Terraform ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਉੱਥੇ ਪਹੁੰਚਣ ਲਈ ਕਿਹੜੇ ਬਦਲਾਅ ਲੋੜੀਂਦੇ ਹਨ।
ਇੱਕ ਆਮ ਲੂਪ ਇਸ ਤਰ੍ਹਾਂ ਹੈ:
ਇਹ “ਪ੍ਰੀਵਿਊ ਫਿਰ ਲਾਗੂ” ਅਭਿਗਮ ਟੀਮਾਂ ਲਈ Terraform ਨੂੰ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਬਣਾਉਂਦਾ ਹੈ: ਇਹ ਕੋਡ ਸਮੀਖਿਆ, ਮਨਜ਼ੂਰੀਆਂ, ਅਤੇ ਅਨੁਮਾਨਯੋਗ ਰੋਲਆਉਟ ਸਹਾਇਕ ਹੈ।
“IaC ਦਾ ਮਤਲਬ ਪੂਰੀ ਤਰ੍ਹਾਂ ਆਟੋਮੇਟੇਡ ਹੋਣਾ ਹੈ।” ਜ਼ਰੂਰੀ ਨਹੀਂ। ਤੁਸੀਂ (ਅਤੇ ਅਕਸਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ) ਪ੍ਰੋਡਕਸ਼ਨ ਬਦਲਾਅ ਲਈ ਮਨੁੱਖੀ ਚੈਕਪੌਇੰਟ ਰੱਖ ਸਕਦੇ ਹੋ। IaC ਦੁਹਰਾਏ ਜਾਣਯੋਗਤਾ ਅਤੇ ਸਪਸ਼ਟਤਾ ਬਾਰੇ ਹੈ, ਲੋਕਾਂ ਨੂੰ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਹਟਾਉਣ ਬਾਰੇ ਨਹੀਂ।
“ਇੱਕ ਟੂਲ ਸਭ ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਅਤੇ ਡਿਲਿਵਰੀ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰ ਦੇਵੇਗਾ।” Terraform ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਅਤੇ ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਬਦਲਣ ਵਿੱਚ ਉਤਮ ਹੈ, ਪਰ ਇਹ ਚੰਗੀ ਆਰਕੀਟੈਕਚਰ, ਮੋਨਿਟਰਿੰਗ, ਜਾਂ ਆਪਰੇਸ਼ਨਲ ਅਨੁਸ਼ਾਸਨ ਦੀ ਜਗ੍ਹਾ ਨਹੀਂ ਲਵੇਗਾ। ਕੁਝ ਰਿਸੋਰਸ ਹੋਰ ਸਿਸਟਮਾਂ ਨਾਲ ਵਧੀਆ ਢੰਗ ਨਾਲ ਹੈਂਡਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਇਹ ਇੱਕ ਵੱਡੇ ਵਰਕਫਲੋ ਦਾ ਹਿੱਸਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।
Vagrant ਦਾ ਕੰਮ ਸਿੱਧਾ ਹੈ: ਹਰ ਡੈਵਲਪਰ ਨੂੰ ਇੱਕੋ ਵਰਕਿੰਗ ਵਾਤਾਵਰਣ ਦਿੱਤਾ ਜਾਵੇ, ਇੱਕੇ ਕਨਫਿਗਰੇਸ਼ਨ ਫਾਇਲ ਤੋਂ ਤੇ ਤੁਰੰਤ।
ਕੇਂਦਰ ਵਿੱਚ Vagrantfile ਹੈ, ਜਿੱਥੇ ਤੁਸੀਂ ਬੇਸ ਇਮੇਜ (ਇੱਕ “ਬਾਕਸ”), CPU/RAM, ਨੈਟਵਰਕਿੰਗ, ਸਾਂਝੇ ਫੋਲਡਰ, ਅਤੇ ਮਸ਼ੀਨ ਨੂੰ ਕਿਵੇਂ ਕਨਫਿਗਰ ਕਰਨਾ ਹੈ, ਵੇਰਵਾ ਕਰਦੇ ਹੋ।
ਕਿਉਂਕਿ ਇਹ ਕੋਡ ਹੈ, ਵਾਤਾਵਰਣ ਸਮੀਖਿਆਯੋਗ, ਵਰਜ਼ਨ ਕੀਤਾ ਗਿਆ, ਅਤੇ ਸਾਂਝਾ ਕਰਨਾ ਆਸਾਨ ਹੈ। ਨਵਾਂ ਜੁੜਨ ਵਾਲਾ ਟੀਮਮੈਟ ਰੀਪੋ ਕਲੋਨ ਕਰਦਾ, ਇੱਕ ਕਮਾਂਡ ਚਲਾਉਂਦਾ, ਤੇ ਇੱਕ ਭਰੋਸੇਯੋਗ ਸੈਟਅਪ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਜਿਸ ਵਿੱਚ ਠੀਕ OS ਵਰਜਨ, ਪੈਕੇਜ, ਸਰਵਿਸਾਂ, ਅਤੇ ਡਿਫਾਲਟ ਸ਼ਾਮਲ ਹਨ।
ਕੰਟੇਨਰ ਐਪ ਅਤੇ ਇਸ ਦੀਆਂ ਡਿਪੈਂਡੈਂਸੀਜ਼ ਪੈਕੇਜ ਕਰਨ ਲਈ ਵਧੀਆ ਹਨ, ਪਰ ਉਹ ਹੋਸਟ ਕਰਨਲ ਸਾਂਝੇ ਕਰਦੇ ਹਨ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਫਿਰ ਵੀ ਨੈਟਵਰਕਿੰਗ, ਫਾਇਲਸਿਸਟਮ ਵਿਹਾਰ, ਬੈਕਗ੍ਰਾਊਂਡ ਸਰਵਿਸ, ਜਾਂ OS ਸਤਰ ਦੇ ਟੂਲਿੰਗ ਵਿੱਚ ਫਰਕ ਨੂੰ ਮਿਲ ਸਕਦੇ ਹੋ—ਖ਼ਾਸ ਤੌਰ 'ਤੇ ਜਦੋਂ ਪ੍ਰੋਡਕਸ਼ਨ ਇੱਕ ਫੁੱਲ Linux VM ਵਾਂਗ ਹੋਵੇ ਨਾ ਕਿ ਇੱਕ ਕੰਟੇਨਰ ਰਨਟਾਈਮ।
Vagrant ਆਮ ਤੌਰ 'ਤੇ ਵਰਚੁਅਲ ਮਸ਼ੀਨਾਂ ਵਰਤਦਾ ਹੈ (VirtualBox, VMware, ਜਾਂ Hyper-V ਵਰਗੇ ਪ੍ਰੋਵਾਈਡਰਾਂ ਰਾਹੀਂ)। ਇੱਕ VM ਆਪਣਾ kernel ਅਤੇ init ਸਿਸਟਮ ਰੱਖਦੀ ਹੈ। ਇਹ ਉਨ੍ਹਾਂ ਮਾਮਲਿਆਂ ਵਿੱਚ ਬਿਹਤਰ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਅਜਿਹੀਆਂ ਚੀਜ਼ਾਂ ਟੈਸਟ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇ ਜੋ ਕੰਟੇਨਰ ਵਧੀਆ ਮਾਡਲ ਨਹੀਂ ਕਰਦੇ: ਸਿਸਟਮ ਸਰਵਿਸਾਂ, kernel ਸੈਟਿੰਗਾਂ, iptables ਨਿਯਮ, ਬਹੁ-ਨਿਕ ਨੈਟਵਰਕਿੰਗ, ਜਾਂ “ਇਹ ਸਿਰਫ़ Ubuntu 22.04 'ਤੇ ਟੁੱਟਦਾ ਹੈ” ਵਾਂਗ Issues।
ਇਹ ਕਿਸੇ ਪ੍ਰਤੀਯੋਗਤਾ ਦੀ ਗੱਲ ਨਹੀਂ: ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਕੰਟੇਨਰਾਂ ਨੂੰ ਐਪ ਪੈਕੇਜਿੰਗ ਲਈ ਅਤੇ Vagrant ਨੂੰ ਹਕੀਕਤੀ, ਫੁੱਲ-ਸਿਸਟਮ ਵਿਕਾਸ ਅਤੇ ਟੈਸਟਿੰਗ ਲਈ ਵਰਤਦੀਆਂ ਹਨ।
ਸੰਖੇਪ ਵਿੱਚ, Vagrant "ਵਰਚੁਅਲਾਈਜ਼ੇਸ਼ਨ ਆਪਣੀ ਥਾਂ" ਬਾਰੇ ਘੱਟ ਹੈ ਅਤੇ ਜ਼ਿਆਦਾ ਇਸ ਗੱਲ ਬਾਰੇ ਹੈ ਕਿ ਡੈਵ ਵਾਤਾਵਰਣ ਇੱਕ ਸਾਂਝਾ ਵਰਕਫਲੋ ਬਣੇ ਜਿਸ 'ਤੇ ਪੂਰੀ ਟੀਮ ਭਰੋਸਾ ਕਰ ਸਕੇ।
Terraform ਅਤੇ Vagrant ਵੱਖ-ਵੱਖ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰਦੇ ਹਨ, ਪਰ ਇਕੱਠੇ ਉਹ “ਮੇਰੇ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਦਾ ਹੈ” ਤੋਂ “ਸਭ ਲਈ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਚੱਲਦਾ ਹੈ” ਦੀ ਸਪਸ਼ਟ ਰਾਹਦਾਰੀ ਬਣਾਉਂਦੇ ਹਨ। ਪੁਲ parity ਹੈ: ਐਪ ਦੀਆਂ ਅਨੁਮਾਨਾਂ ਨੂੰ ਇਕਸਾਰ ਰੱਖਣਾ ਜਦੋਂ ਟਾਰਗੇਟ ਵਾਤਾਵਰਣ ਬਦਲਦੇ ਹਨ।
Vagrant ਮੂੰਹ ਦਾ ਦਰਵਾਜਾ ਹੈ। ਇਹ ਹਰ ਡੈਵਲਪਰ ਨੂੰ ਇਕ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਲੋਕਲ ਵਾਤਾਵਰਣ ਦਿੰਦਾ—ਉਹੀ OS, ਉਹੀ ਪੈਕੇਜ, ਉਹੀ ਸਰਵਿਸ ਵਰਜਨ—ਤਾਂ ਜੋ ਤੁਹਾਡਾ ਐਪ ਇੱਕ ਜਾਣਿਆ ਬੇਸਲਾਈਨ ਤੋਂ ਸ਼ੁਰੂ ਹੋਵੇ।
Terraform ਸਾਂਝਾ ਨੀਂਹ ਹੈ। ਇਹ ਉਹ ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਜਿਸ 'ਤੇ ਟੀਮਾਂ ਸਾਥ ਮਿਲ ਕੇ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ: ਨੈੱਟਵਰਕ, ਡੇਟਾਬੇਸ, ਕੰਪਿਊਟ, DNS, ਲੋਡ ਬੈਲੈਂਸਰ, ਅਤੇ ਐਕਸੈਸ ਨਿਯਮ। ਉਹ ਪਰਿਭਾਸ਼ਾ ਟੇਸਟ ਅਤੇ ਪ੍ਰੋਡ ਲਈ ਸਚਾਈ ਦਾ ਸਰੋਤ ਬਣ ਜਾਂਦੀ ਹੈ।
ਜੋੜ ਸਧਾਰਨ ਹੈ: Vagrant ਤੁਹਾਨੂੰ ਐਪ ਬਣਾਉਣ ਅਤੇ ਵੈਰੀਫਾਈ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਇਕ ਐਸੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਜੋ ਹਕੀਕਤ ਦੇ ਨਜ਼ਦੀਕ ਹੋਵੇ, ਅਤੇ Terraform ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਹਕੀਕਤ (ਟੈਸਟ/ਪ੍ਰੋਡ) ਕੰਸਿਸਟੈਂਟ, ਸਮੀਖਿਆਯੋਗ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰੋਵਿਜ਼ਨ ਅਤੇ ਬਦਲ ਰਹੀ ਹੈ।
ਤੁਸੀਂ ਹਰ ਟਾਰਗੇਟ ਲਈ ਇਕੋ ਟੂਲ ਨਹੀਂ ਵਰਤਦੇ—ਤੁਸੀਂ ਇਕੋ ਕੋਂਟਰੈਕਟ ਵਰਤਦੇ ਹੋ।
DATABASE_URL ਅਤੇ REDIS_URL।Vagrant ਲੋਕਲ ਰੂਪ ਵਿੱਚ ਉਸ ਕੋਂਟਰੈਕਟ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ। Terraform ਸਾਂਝੇ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਇਸਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਐਪ ਇੱਕੋ ਰਹਿੰਦੀ ਹੈ; ਸਿਰਫ਼ "ਕਿੱਥੇ" ਬਦਲਦਾ ਹੈ।
ਲੇਪਟਾਪ (Vagrant): ਡੈਵਲਪਰ vagrant up ਚਲਾਉਂਦਾ ਹੈ, ਇੱਕ VM ਮਿਲਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਐਪ ਰਨਟਾਈਮ ਨਾਲ Postgres ਅਤੇ Redis ਹਨ। ਉਹ ਤੇਜ਼ੀ ਨਾਲ ਇਟਰੈਟ ਕਰਦਾ ਹੈ ਅਤੇ “ਲੋਕਲ ਤੇ ਚੱਲਦਾ ਹੈ” ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਜਲਦੀ ਪਕੜ ਲੈਂਦਾ ਹੈ।
ਟੈਸਟ (Terraform): ਇੱਕ pull request Terraform ਅਪਡੇਟ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਟੈਸਟ ਡੇਟਾਬੇਸ ਅਤੇ ਐਪ ਇੰਸਟੈਂਸਾਂ ਨੂੰ ਪ੍ਰੋਵਿਜ਼ਨ ਕੀਤਾ ਜਾਵੇ। ਟੀਮ ਹਕੀਕਤੀ ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਸੀਮਾਵਾਂ ਦੇ ਖਿਲਾਫ ਦੇਰਖੋਚਾਈ ਨੂੰ ਵੈਰੀਫਾਈ ਕਰਦੀ ਹੈ।
ਪ੍ਰੋਡਕਸ਼ਨ (Terraform): ਉਨ੍ਹਾਂ ਹੀ Terraform ਪੈਟਰਨਾਂ ਨੂੰ ਪ੍ਰੋਡ ਸੈਟਿੰਗਾਂ ਨਾਲ ਲਗਾਇਆ ਜਾਂਦਾ ਹੈ—ਵੱਡੀ ਕੈਪੇਸਿਟੀ, ਕੜੀ ਪਹੁੰਚ, ਉੱਚ ਉਪਲਬਧਤਾ—ਬਿਨਾਂ ਸੈਟਅਪ ਦੁਬਾਰਾ ਬਣਾਉਣ ਤੋਂ।
ਇਹੋ ਪੁਲ ਹੈ: ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਲੋਕਲ ਪੈਰਟੀ ਸਾਂਝੇ ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਨੂੰ ਫੀਡ ਕਰਦੀ ਹੈ, ਤਾਂ ਜੋ ਡਿਲਿਵਰੀ ਇੱਕ ਨਿਯੰਤਰਿਤ ਅਗਵਾਈ ਬਣੇ ਨਾ ਕਿ ਹਰ ਮੰਚ 'ਤੇ ਦੁਬਾਰਾ ਉਦਯੋਗ।
ਇੱਕ ਮਜ਼ਬੂਤ Terraform/Vagrant ਵਰਕਫਲੋ ਕਮਾਂਡਾਂ ਯਾਦ ਕਰਨ ਬਾਰੇ ਘੱਟ ਹੈ ਅਤੇ ਬਦਲਾਅ ਨੂੰ ਆਸਾਨੀ ਨਾਲ ਸਮੀਖਿਆ, ਦੁਹਰਾਉਣ ਅਤੇ ਰੋਲਬੈਕ ਕਰਨਯੋਗ ਬਣਾਉਣ ਬਾਰੇ ਜ਼ਿਆਦਾ।
ਮਕਸਦ: ਇਕ ਡੈਵਲਪਰ ਲੋਕਲ ਤੌਰ 'ਤੇ ਸ਼ੁਰੂ ਕਰੇ, ਐਪ ਬਦਲਾਅ ਦੇ ਨਾਲ ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਬਦਲਾਅ ਸੁਝਾਏ, ਅਤੇ ਉਹ ਬਦਲਾਅ ਘੱਟ ਅਨੁਮਾਨਾਂ ਨਾਲ ਵਾਤਾਵਰਣਾਂ ਰਾਹੀਂ ਪ੍ਰਮੋਟ ਕਰ ਸਕੇ।
ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਐਪ ਅਤੇ ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਨੂੰ ਇਕੋ ਰੀਪੋ ਵਿੱਚ ਰੱਖਦੀਆਂ ਹਨ ਤਾਂ ਜੋ ਡਿਲਿਵਰੀ ਕਹਾਣੀ ਸੰਗਤ ਰਹੇ:
/app — ਐਪ ਕੋਡ, ਟੈਸਟ, ਬਿਲਡ ਐਸੇਟ/infra/modules — ਰੀਯੂਜ਼ੇਬਲ Terraform ਮੋਡੀਊਲ (ਨੈੱਟਵਰਕ, ਡੇਟਾਬੇਸ, ਐਪ ਸਰਵਿਸ)/infra/envs/dev, /infra/envs/test, /infra/envs/prod — ਪਤਲੀ ਵਾਤਾਵਰਣ ਲੇਅਰਸ/vagrant — Vagrantfile ਅਤੇ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਸਕ੍ਰਿਪਟ ਜਿਸ ਨਾਲ “ਅਸਲੀ” ਡੀਪੈਂਡੈਂਸੀਜ਼ ਮਿਰਰ ਹੁੰਦੀਆਂ ਹਨਜ਼ਰੂਰੀ ਪੈਟਰਨ "ਪਤਲੇ envs, ਮੋਟੇ ਮੋਡੀਊਲ": ਵਾਤਾਵਰਣ ਮੁੱਖਤੌਰ 'ਤੇ ਇਨਪੁਟ (ਸਾਈਜ਼, ਗਿਣਤੀ, DNS ਨਾਮ) ਚੁਣਦੇ ਹਨ, ਜਦਕਿ ਸਾਂਝੇ ਮੋਡੀਊਲ ਅਸਲ ਰਿਸੋਰਸ ਪਰਿਭਾਸ਼ਾਵਾਂ ਰੱਖਦੇ ਹਨ।
ਇੱਕ ਸਧਾਰਣ trunk-based ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਚੰਗਾ ਕੰਮ ਕਰਦਾ ਹੈ: ਛੋਟੇ-ਅवਧੀ ਫੀਚਰ برਾਂਚ, pull request ਰਾਹੀਂ ਮਰਜ਼।
ਸਮੀਖਿਆ ਵਿੱਚ, ਦੋ ਆਰਟਿਫੈਕਟਾਂ ਦੀ ਮੰਗ ਕਰੋ:
terraform fmt, validate ਚਲਾਉਂਦਾ ਹੈ ਅਤੇ PR ਲਈ terraform plan ਆਉਟਪੁੱਟ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।ਰਿਵਿਊਅਰਾਂ ਨੂੰ ਮੁਝੱਬ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ “ਕੀ ਬਦਲਿਆ?” ਅਤੇ “ਕੀ ਇਹ ਸੁਰੱਖਿਅਤ ਹੈ?” ਬਿਨਾਂ ਕੁਝ ਮੁੜ ਬਣਾਉਣ ਦੇ।
ਇਸੇ ਮੋਡੀਊਲ ਸੈਟ ਨੂੰ dev → test → prod ਤੋਂ ਪ੍ਰੋਮੋਟ ਕਰੋ, ਫਰਕਾਂ ਨੂੰ ਸਪਸ਼ਟ ਅਤੇ ਛੋਟਾ ਰੱਖਦੇ ਹੋਏ:
ਪੂਰੇ ਡਾਇਰੈਕਟਰੀਆਂ ਦੀ ਨਕਲ ਕਰਨ ਤੋਂ ਬਚੋ। ਵੈਰੀਏਬਲ ਬਦਲ ਕੇ ਪ੍ਰਮੋਟ ਕਰਨ ਪਸੰਦ ਕਰੋ, ਨਾਕਿ ਰਿਸੋਰਸ ਪਰਿਭਾਸ਼ਾਵਾਂ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖੋ।
ਜਦੋਂ ਇੱਕ ਐਪ ਬਦਲਾਅ ਨੂੰ ਨਵੀਂ ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਕਿਊ ਜਾ ਨਵਾਂ ਕਨਫਿਗ), ਉਹਨਾਂ ਨੂੰ ਇਕੇ PR ਵਿੱਚ ਭੇਜੋ ਤਾਂ ਜੋ ਉਹ ਇੱਕ ਇਕਾਈ ਵਜੋਂ ਸਮੀਖਿਆ ਕੀਤੇ ਜਾ ਸਕਣ।
ਜੇ ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਕਈ ਸੇਵਾਵਾਂ ਨਾਲ ਸਾਂਝਾ ਹੈ, ਤਾਂ ਮੋਡੀਊਲਾਂ ਨੂੰ ਉਤਪਾਦ ਵਾਂਗ ਦਰਜ ਕਰੋ: ਉਨ੍ਹਾਂ ਨੂੰ ਵਰਜ਼ਨ ਦਿਓ (ਟੈਗ/ਰੀਲੀਜ਼) ਅਤੇ ਇਨਪੁਟ/ਆਉਟਪੁਟ ਨੂੰ ਇੱਕ ਕਾਂਟ੍ਰੈਕਟ ਵਜੋਂ ਦਸਤਾਵੇਜ਼ ਕਰੋ। ਇਸ ਤਰ੍ਹਾਂ ਟੀਮਾਂ ਜਾਣ-ਬੂਝ ਕੇ ਅਪਗਰੇਡ ਕਰ ਸਕਦੀਆਂ ਹਨ ਨਾ ਕਿ ਅਣਜਾਣੇ ਤੌਰ 'ਤੇ "ਜੋ ਵੀ ਨਵਾਂ ਹੈ"।
Terraform ਦੀ ਸ਼ਕਤੀ صرف ਇਹ ਨਹੀਂ ਕਿ ਇਹ ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਬਣਾ ਸਕਦਾ ਹੈ—ਇਹ ਹੈ ਕਿ ਇਹ ਸਮੇਂ ਦੇ ਨਾਲ ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਬਦਲ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ, ਇਸਨੂੰ ਯਾਦ ਰੱਖਣਾ ਪੈਂਦਾ ਹੈ ਕਿ ਉਸਨੇ ਕੀ ਬਣਾਇਆ ਅਤੇ ਉਹ ਕੀ ਸੋਚਦਾ ਹੈ ਮੌਜੂਦ ਹੈ।
Terraform state ਇੱਕ ਫਾਇਲ (ਜਾਂ ਸਟੋਰ ਕੀਤੀ ਡਾਟਾ) ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਹਾਡੀ ਕਨਫਿਗ ਨੂੰ ਅਸਲੀ ਦੁਨੀਆ ਦੇ ਰਿਸੋਰਸਾਂ ਨਾਲ ਮੈਪ ਕਰਦੀ ਹੈ: ਕਿਸ database instance ਦਾ ਕਿਹੜਾ aws_db_instance ਨਾਲ ਸੰਬੰਧ ਹੈ, ਉਸਦੀ ID ਕੀ ਹੈ, ਅਤੇ ਕਿਸ ਸੈਟਿੰਗ ਨੂੰ ਆਖਰੀ ਵਾਰ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਸੀ।
State ਦੇ ਬਿਨਾਂ, Terraform ਨੂੰ ਇਹ ਅਨੁਮਾਨ ਲਗਾਉਣਾ ਪਵੇਗਾ ਕਿ ਕੀ ਮੌਜੂਦ ਹੈ, ਜੋ ধੀਮਾ, ਅਨਿਸ਼ਚਿਤ, ਅਤੇ ਕਈ ਵਾਰੀ ਅਯੋਗਯ ਹੁੰਦਾ। State ਨਾਲ, Terraform ਇੱਕ ਯੋਜਨਾ ਨਿਕਾਲ ਸਕਦਾ ਹੈ: ਕੀ ਜੋੜਿਆ ਜਾਵੇਗਾ, ਕੀ ਬਦਲਿਆ ਜਾਵੇਗਾ, ਜਾਂ ਕੀ ਹਟਾਇਆ ਜਾਵੇਗਾ।
ਕਿਉਂਕਿ state ਵਿੱਚ ਰਿਸੋਰਸ ਆਈਡੀਜ਼—ਅਤੇ ਕਈ ਵਾਰ ਉਹ ਮੁੱਲ ਹੋ ਸਕਦੇ ਹਨ jinhanūṁ ਤੁਸੀਂ ਉਘਾੜਨਾ ਨਹੀਂ ਚਾਹੁੰਦੇ—ਇਸਨੂੰ ਇੱਕ ਕਰੈਡੈਂਸ਼ਿਆਲ ਵਾਂਗ ਵਰਤਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇ ਕੋਈ ਇਸਨੂੰ ਪੜ੍ਹ ਸਕਦਾ ਜਾਂ ਸੋਧ ਸਕਦਾ ਹੈ, ਉਹ Terraform ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ।
ਡ੍ਰਿਫਟ ਉਹ ਹੈ ਜਦੋਂ ਇਨਫ੍ਰਾਸਟਰਕਚਰ Terraform ਤੋਂ ਬਾਹਰ ਬਦਲਦਾ ਹੈ: ਕਨਸੋਲ ਸੰਪਾਦਨ, ਰਾਤ ਦਾ ਹੌਟਫਿਕਸ, ਜਾਂ ਕੋਈ ਆਟੋਮੈਟਿਕ ਪ੍ਰੋਸੈਸ।
ਡ੍ਰਿਫਟ ਭਵਿੱਖ ਦੀਆਂ ਯੋਜਨਾਵਾਂ ਨੂੰ ਹੈਰਾਨ ਕਰ ਦਿੰਦੀ ਹੈ: Terraform ਮੈਨੂਅਲ ਬਦਲਾਅ ਨੂੰ "ਵਾਪਸ" ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਸਕਦਾ ਹੈ, ਜਾਂ fail ਕਰ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਅਨੁਮਾਨ ਹੁਣ ਹਕੀਕਤ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ।
ਟੀਮਾਂ ਆਮ ਤੌਰ 'ਤੇ state ਨੂੰ ਰਿਮੋਟ ਉੱਤੇ ਸਟੋਰ ਕਰਦੀਆਂ ਹਨ (ਇੱਕ ਲੈਪਟਾਪ 'ਤੇ ਨਹੀਂ) ਤਾਂ ਕਿ ਹਰ ਕੋਈ ਇੱਕੋ ਸਰੋਤ-ਸਚਾਈ ਖਿਲਾਫ ਯੋਜਨਾ ਅਤੇ ਲਾਗੂ ਕਰੇ। ਇੱਕ ਚੰਗੀ ਰਿਮੋਟ ਸੈਟਅਪ ਇਹ ਵੀ ਸਪੋਰਟ ਕਰਦੀ ਹੈ:
ਸੁਰੱਖਿਅਤ ਡਿਲਿਵਰੀ ਜ਼ਿਆਦਾਤਰ ਨਿਰਸ ਹੈ: ਇੱਕ state, ਨਿਯੰਤਰਿਤ ਪਹੁੰਚ, ਅਤੇ ਬਦਲਾਅ ਜੋ ਸਮੀਖਿਆਯੋਗ ਯੋਜਨਾਵਾਂ ਰਾਹੀ ਹੋਕੇ ਜਾ ਰਹੇ ਹਨ।
Terraform ਅਸਲੀ ਤਾਕਤ ਤਦ ਆਉਂਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇੱਕੋ კoda ਬਲਾਕਾਂ ਨੂੰ ਨਕਲ ਕਰਨਾ ਛੱਡਦੇ ਹੋ ਅਤੇ ਆਮ ਪੈਨਾਲਾਂ ਨੂੰ ਮੋਡੀਊਲਾਂ ਵਿੱਚ ਪੈਕੇਜ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ।
ਮੋਡੀਊਲ ਇੱਕ ਰੀਯੂਜ਼ੇਬਲ Terraform ਕੋਡ ਬੰਡਲ ਹੁੰਦਾ ਹੈ ਜੋ ਇਨਪੁਟ ਲੈਂਦਾ ਹੈ (ਜਿਵੇਂ VPC CIDR ਰੇਂਜ ਜਾਂ instance size) ਅਤੇ ਆਉਟਪੁੱਟ ਦਿੰਦਾ ਹੈ (ਜਿਵੇਂ subnet IDs ਜਾਂ database endpoint)। ਨਤੀਜਾ ਘੱਟ ਨਕਲ, ਘੱਟ “ਸਨੋਫਲੇਕ” ਸੈਟਅਪ, ਅਤੇ ਤੇਜ਼ੀ ਨਾਲ ਡਿਲਿਵਰੀ ਹੈ ਕਿਉਂਕਿ ਟੀਮਾਂ ਇੱਕ ਜਾਣਿਆ-ਪਛਾਣਿਆ ਬਿਲਡਿੰਗ ਬਲਾਕ ਤੋਂ ਸ਼ੁਰੂ ਕਰ ਸਕਦੀਆਂ ਹਨ।
ਬਿਨਾਂ ਮੋਡੀਊਲਾਂ ਦੇ, ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਕੋਡ ਅਕਸਰ ਕਾਪੀ/ਪੇਸਟ ਵੈਰੀਅੰਟਾਂ ਵਿੱਚ ਡਿੱਗ ਜਾਂਦਾ ਹੈ: ਇੱਕ ਰੀਪੋ ਸੁਰੱਖਿਆ ਗਰੁੱਪ ਨਿਯਮ ਭੁੱਲ ਜਾਂਦਾ, ਦੂਜਾ encryption ਸੈਟਿੰਗ ਭੁੱਲ ਜਾਂਦਾ, ਤੀਜਾ ਵੱਖ-ਵੱਖ provider ਵਰਜ਼ਨ ਪਿੰਨ ਕਰਦਾ।
ਮੋਡੀਊਲ ਇੱਕ ਥਾਂ ਬਣਾਉਂਦਾ ਹੈ ਜਿੱਥੇ ਇੱਕ ਫੈਸਲਾ ਏਨਕੋਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਸੁਧਾਰਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਸਮੀਖਿਆਆਂ ਵੀ ਆਸਾਨ ਹੁੰਦੀਆਂ ਹਨ: ਹਰ ਵਾਰ 200 ਲਾਈਨਾਂ ਨੈੱਟਵਰਕਿੰਗ ਨੂੰ ਮੁੜ ਆਡਿਟ ਕਰਨ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਇੱਕ ਛੋਟਾ ਮੋਡੀਊਲ ਇੰਟਰਫੇਸ (ਇੰਪੁਟ/ਆਉਟਪੁੱਟ) ਦੀ ਸਮੀਖਿਆ ਕਰਦੇ ਹੋ ਅਤੇ ਜਦੋਂ ਮੋਡੀਊਲ ਵਿਕਸਤ ਹੁੰਦਾ ਹੈ ਤਾਂ ਮੋਡੀਊਲ ਬਦਲਦਾ ਹੈ।
ਚੰਗੇ ਮੋਡੀਊਲ ਇੱਕ ਹੱਲ ਦੇ ਆਕਾਰ ਨੂੰ ਮਿਆਰਬੱਧ ਕਰਦੇ ਹਨ ਪਰ ਅਹਮ ਤਫ਼ਾਵਤਾਂ ਲਈ ਜਗ੍ਹਾ ਛੱਡਦੇ ਹਨ।
ਮੋਡੀਊਲ ਲਾਇਕ ਪੈਟਰਨਾਂ ਦੇ ਉਦਾਹਰਣ:
ਹਰ ਸੰਭਵ ਵਿਕਲਪ ਨੂੰ ਕੋਡ ਕਰਨ ਤੋਂ ਬਚੋ। ਜੇ ਮੋਡੀਊਲ ਨੂੰ ਵਰਤਣਯੋਗ ਬਣਾਉਣ ਲਈ 40 ਇੰਪੁਟਾਂ ਦੀ ਲੋੜ ਹੈ, ਉਹ ਸ਼ਾਇਦ ਬਹੁਤ ਜ਼ਿਆਦਾ ਕੈਸੇਜ਼ ਨੂੰ ਸੇਵਾ ਦੇ ਰਹਿਆ ਹੈ। ਸਮਝਦਾਰ ਡਿਫਾਲਟ ਅਤੇ ਕੰਨੂੰਨੀ ਨੀਤੀਆਂ (encrypt on, required tags, approved instance families) ਪਸੰਦ ਕਰੋ, ਅਤੇ ਐਸਕੇਪ ਹੈਚਜ਼ ਦੁਰਲਭ ਅਤੇ ਸਪਸ਼ਟ ਰੱਖੋ।
ਜੇ ਹਰ ਕੋਈ ਥੋੜ੍ਹਾ-ਥੋੜ੍ਹਾ ਵੱਖ-ਵੱਖ ਵਰਜ਼ਨ ਪਬਲਿਸ਼ ਕਰਦਾ ਹੈ (“vpc-basic”, “vpc-basic2”, “vpc-new”) ਤਾਂ ਮੋਡੀਊਲ ਇੱਕ ਭੁੱਲ-ਭੁੱਲੈ ਬਣ ਸਕਦੇ ਹਨ। ਸਪ੍ਰਾਲ ਆਮ ਤੌਰ 'ਤੇ ਉਸ ਵੇਲੇ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਕੋਈ ਸਾਫ਼ ਮਾਲਕੀਅਤ ਨਹੀਂ ਹੈ, ਕੋਈ ਵਰਜ਼ਨਿੰਗ ਅਨੁਸ਼ਾਸਨ ਨਹੀਂ, ਅਤੇ ਇਹ ਗਾਈਡ ਨਹੀਂ ਕਿ ਨਵਾਂ ਮੋਡੀਊਲ ਕਦੋਂ ਬਣਾਉਣਾ ਹੈ ਬਨਾਮ ਮੌਜੂਦਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰਨਾ।
ਵਿਆਵਹਾਰਿਕ ਗਾਰਡਰੇਲ:
ਚੰਗੀ ਤਰ੍ਹਾਂ ਹੋਣ 'ਤੇ, ਮੋਡੀਊਲ Terraform ਨੂੰ ਇੱਕ ਸਾਂਝਾ ਵਰਕਫਲੋ ਬਣਾਉਂਦੇ ਹਨ: ਟੀਮਾਂ ਤੇਜ਼ੀ ਨਾਲ ਅੱਗੇ ਵਧਦੀਆਂ ਹਨ ਕਿਉਂਕਿ “ਸਹੀ ਤਰੀਕਾ” ਪੈਕੇਜ, ਖੋਜਯੋਗ, ਅਤੇ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਹੁੰਦਾ ਹੈ।
Terraform ਅਤੇ Vagrant ਵਾਤਾਵਰਣਾਂ ਨੂੰ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਬਣਾਉਂਦੇ ਹਨ—ਪਰ ਉਹ ਵੀ ਗਲਤੀਆਂ ਨੂੰ ਦੁਹਰਾਉਣਗੇ। ਇੱਕ ਹੀ ਲੀਕ ਕੀਤਾ ਟੋਕਨ ਰੀਪੋ ਵਿੱਚ ਫੈਲ ਕੇ ਲੈਪਟਾਪਾਂ, CI ਜੌਬਾਂ, ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਬਦਲਾਅ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ।
ਕੁਝ ਸਧਾਰਨ ਆਦਤਾਂ ਜ਼ਿਆਦਾਤਰ ਆਮ ਗਲਤੀਆਂ ਰੋਕ ਲੈਂਦੀਆਂ ਹਨ।
"ਕੀ ਬਣਾਉਣਾ ਹੈ" (ਕਨਫিগ) ਅਤੇ "ਕਿਵੇਂ ਪ੍ਰਮਾਣਿਤ ਕਰਨਾ ਹੈ" (ਸੀਕ੍ਰੇਟਸ) ਨੂੰ ਵੱਖ ਸਲਾੜੋ।
Infrastructure definitions, Vagrantfiles, ਅਤੇ module inputs ਨੂੰ ਰਿਸੋਰਸ ਅਤੇ ਸੈਟਿੰਗਸ ਬਿਆਨ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ—ਨਾ ਕਿ ਪਾਸਵਰਡ, API ਕੀਜ਼, ਜਾਂ ਪ੍ਰਾਈਵੇਟ ਸਰਟੀਫਿਕੇਟ। ਬਦਲੇ ਵਿੱਚ, ਸੀਕ੍ਰੇਟਸ ਨੂੰ ਰਨਟਾਈਮ 'ਤੇ ਕਿਸੇ ਪ੍ਰਮਾਣਤ ਸੀਕ੍ਰੇਟ ਸਟੋਰ (ਇੱਕ ਸਮਰਪਿਤ vault ਸਰਵਿਸ, ਤੁਹਾਡੇ ਕਲਾਊਡ ਦਾ ਸੀਕ੍ਰੇਟ ਮੈਨੇਜਰ, ਜਾਂ ਟਾਈਟਲੀ ਨਿਯੰਤਰਿਤ CI ਸੀਕ੍ਰੇਟ ਸਟੋਰ) ਤੋਂ ਫੈਚ ਕਰੋ। ਇਹ ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਸਮੀਖਿਆਯੋਗ ਰਖਦਾ ਹੈ ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਮੁੱਲਾਂ ਨੂੰ ਆਡਿਟ ਕਰਨ ਯੋਗ ਬਣਾਉਂਦਾ ਹੈ।
ਹਰ ਐਕਟਰ ਨੂੰ ਸਿਰਫ਼ ਉਹੀ ਅਧਿਕਾਰ ਦਿਓ ਜੋ ਉਸਨੂੰ ਲੋੜ ਹੈ:
terraform plan ਚਲਾ ਸਕਦਾ ਹੈ, ਉਸਨੂੰ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਪ੍ਰੋਡ apply ਕਰਨ ਦੀ ਲੋੜ ਨੀੰ ਹੋਣੀ ਚਾਹੀਦੀ। ਮਨਜ਼ੂਰੀ ਅਤੇ ਐਕਜ਼ਿਕਿਊਸ਼ਨ ਨੂੰ ਵੱਖ ਕੀਤਾ ਜਾਵੇ ਤਾਂ ਕਿ ਮਨਜ਼ੂਰੀ ਕਰਨ ਵਾਲਾ ਅਤੇ ਲਾਗੂ ਕਰਨ ਵਾਲਾ ਇਕੋ ਵਿਅਕਤੀ ਨਾ ਹੋਵੇ।ਕੋਡ ਵਿੱਚ ਕ੍ਰੈਡੈਂਸ਼ਿਆਲ, ਲੋਕਲ ਡਾਟਫ਼ਾਈਲ ਜੋ ਨਕਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਜਾਂ ਸਾਂਝੇ "ਟੀਮ ਕੀਜ਼" ਨਾ embed ਕਰੋ। ਸਾਂਝੇ ਸੀਕ੍ਰੇਟ ختم ਕਰ ਦਿੰਦੇ ਹਨ ਜਿੰਨ੍ਹਾਂ ਵਿੱਚ ਜਵਾਬਦੇਹੀ ਨਹੀਂ ਰਹਿੰਦੀ।
ਇਹ ਗਾਰਡਰੇਲ ਡਿਲਿਵਰੀ ਨੂੰ ਹੌਂਸਲਾ ਨਹੀਂ ਰੋਕਦੀਆਂ—ਉਹ ਗਲਤੀਆਂ ਹੋਣ 'ਤੇ ਪ੍ਰਭਾਵਦੇ ਹਿੱਸੇ ਨੂੰ ਘਟਾਉਂਦੀਆਂ ਹਨ।
CI/CD ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ Terraform "ਕੋਈ ਚੀਜ਼ ਜੋ ਇਕ ਵਿਅਕਤੀ ਚਲਾਂਦਾ ਹੈ" ਤੋਂ ਇੱਕ ਟੀਮ ਵਰਕਫਲੋ ਬਣ ਜਾਂਦਾ ਹੈ: ਹਰ ਬਦਲਾਅ ਵਿਜ਼ੀਬਲ, ਸਮੀਖਿਆਯੋਗ, ਅਤੇ ਹਰ ਵਾਰੀ ਇੱਕੋ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।
ਇੱਕ ਪ੍ਰਯੋਗਕਰਣੀ ਬੇਸਲਾਈਨ ਤਿੰਨ ਕਦਮਾਂ ਤੋਂ ਬਣੀ ਹੋ ਸਕਦੀ ਹੈ, ਜੋ ਤੁਹਾਡੇ pull request ਅਤੇ ਡਿਪਲੌਇ ਮਨਜ਼ੂਰੀਆਂ ਨਾਲ ਜੁੜੀ ਹੋਵੇ:
terraform fmt -check ਅਤੇ terraform validate ਚਲਾਉ, ਤਾ ਕਿ ਆਮ ਗਲਤੀਆਂ ਪਹਿਲਾਂ ਹੀ ਮਿਲ ਜਾਣ।terraform plan ਜਨਰੇਟ ਕਰੋ ਅਤੇ ਆਉਟਪੁੱਟ PR 'ਤੇ ਪਬਲਿਸ਼ ਕਰੋ (ਆਰਟਿਫੈਕਟ ਜਾਂ ਟਿੱਪਣੀ ਦੇ ਰੂਪ ਵਿੱਚ)। ਰਿਵਿਊਅਰਾਂ ਨੂੰ ਇਹ ਸਵਾਲ ਜਵਾਬ ਦੇ ਸਕਣਾ ਚਾਹੀਦਾ ਹੈ: ਕੀ ਬਦਲਾਅ ਹੋਵੇਗਾ? ਕਿੱਥੇ? ਕਿਉਂ?terraform apply ਚਲਾਓ ਜਿਸ ਨੇ plan ਬਣਾਇਆ ਸੀ।# Example (GitHub Actions-style) outline
# - fmt/validate on PR
# - plan on PR
# - apply on manual approval
ਮੁੱਖ ਚੀਜ਼ ਵੱਖਰੀ ਕਰਨੀ: PRs ਸਬੂਤ (plans) ਪੈਦਾ ਕਰਦੇ ਹਨ, ਮਨਜ਼ੂਰੀਆਂ ਬਦਲਾਅ (applies) ਨੂੰ ਅਥਾਰਾਈਜ਼ ਕਰਦੀਆਂ ਹਨ।
Vagrant CI ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ, ਪਰ ਇਹ ਲੋਕਲ ਟੈਸਟਿੰਗ ਨੂੰ CI-ਗਰੇਡ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ। ਜਦੋਂ ਕੋਈ ਬੱਗ ਰਿਪੋਰਟ ਕਹੇ "ਮੇਰੇ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਦਾ ਹੈ", ਇੱਕ ਸਾਂਝਾ Vagrantfile ਕਿਸੇ ਨੂੰ ਵੀ ਉੱਠਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਤਾਂ ਜੋ ਉਹੀ OS, ਪੈਕੇਜ, ਅਤੇ ਸਰਵਿਸ ਵਰਜਨ ਉਤੇ VM ਬੂਟ ਕਰਕੇ ਮੁੱਦੇ ਨੂੰ ਦੁਹਰਾਇਆ ਜਾ ਸਕੇ।
ਇਹ ਖਾਸ ਤੌਰ 'ਤੇ ਲਾਭਦਾਇਕ ਹੈ:
ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਡਿਲਿਵਰੀ ਵਰਕਫਲੋਜ਼ ਨੂੰ ਸਟੈਂਡਰਡ ਕਰ ਰਹੀ ਹੈ, Terraform ਅਤੇ Vagrant ਤਦੋ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਸਥਿਰ ਐਪ ਸਕੈਫੋਲਡਿੰਗ ਅਤੇ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਰਿਲੀਜ਼ ਕਦਮਾਂ ਨਾਲ ਜੋੜੇ ਜਾਂ।
Koder.ai ਇਸ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ ਇਕ vibe-coding ਪਲੇਟਫਾਰਮ ਵਜੋਂ: ਟੀਮਾਂ ਚੈਟ ਤੋਂ ਕੰਮ ਕਰਦਾ ਵੈਬ/ਬੈਕਐਂਡ/ਮੋਬਾਇਲ ਬੇਸਲਾਈਨ ਜਨਰੇਟ ਕਰ ਸਕਦੀਆਂ ਹਨ, ਫਿਰ ਸੋਰਸ ਕੋਡ ਨਿਖਾਲ ਕੇ ਉਸੇ Git-ਅਧਾਰਿਤ ਵਰਕਫਲੋ ਵਿੱਚ ਪਲੱਗ ਕਰ ਸਕਦੀਆਂ ਹਨ (Terraform ਮੋਡੀਊਲ ਅਤੇ CI plan/apply ਗੇਟਸ ਸਮੇਤ)। ਇਹ Terraform ਜਾਂ Vagrant ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦਾ; ਇਹ ਪਹਿਲੇ ਕਮਿਟ ਤੱਕ ਦਾ ਸਮਾਂ ਘਟਾਉਂਦਾ ਹੈ ਜਦੋਂ ਕਿ ਤੁਹਾਡੀਆਂ ਇਨਫ੍ਰਾ ਅਤੇ ਵਾਤਾਵਰਣ ਅਭਿਆਸਾਂ ਸਪਸ਼ਟ ਅਤੇ ਸਮੀਖਿਆਯੋਗ ਰਹਿੰਦੇ ਹਨ।
ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਅਕਸਮਾਤ ਆਟੋਮੇਸ਼ਨ ਬਣਨ ਤੋਂ ਰੋਕਣ ਲਈ:
ਇਹ ਗਾਰਡਰੇਲ Terraform ਅਤੇ Vagrant ਨੂੰ ਇੱਕੋ ਲਕੜੀ ਦੇ ਹੱਦ ਤੱਕ ਸਹਾਇਕ ਬਣਾਉਂਦੀਆਂ ਹਨ: ਬਦਲਾਅਾਂ ਜੋ ਤੁਸੀਂ ਸਮਝਾ ਸਕਦੇ, ਦੁਹਰਾ ਸਕਦੇ, ਅਤੇ ਭਰੋਸਾ ਕਰ ਸਕਦੇ ਹੋ।
ਚੰਗੇ ਟੂਲ ਵੀ ਨਵੇਂ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ ਜਦੋਂ ਉਹ "ਸੈੱਟ ਅਤੇ ਭੁੱਲ ਜਾਓ" ਵਾਂਗ ਵਰਤੇ ਜਾਂ। Terraform ਅਤੇ Vagrant ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ ਦਾਇਰਾ ਸਾਫ਼ ਰਖਦੇ ਹੋ, ਕੁਝ ਗਾਰਡਰੇਲ ਲਗਾਉਂਦੇ ਹੋ, ਅਤੇ ਹਰ ਇੱਕ ਚੀਜ਼ ਨੂੰ ਹਰ ਇੱਕ ਡਿਟੇਲ ਤੱਕ ਮਾਡਲ ਕਰਨ ਦੀ ਲਲਚ ਤੋਂ ਬਚਦੇ ਹੋ।
ਲੰਬੇ ਸਮੇਂ ਵਾਲੀ ਡ੍ਰਿਫਟ: ਕਸੂਸੀ ਤੌਰ 'ਤੇ ਕਲਾਊਡ ਕਨਸੋਲ ਵਿੱਚ ਕੀਤਾ ਗਿਆ "ਸਿਰਫ਼ ਇਸ ਵਾਰ" ਬਦਲਾਅ Terraform ਤੋਂ ਚੁਪਚਾਪ ਵੱਖਰਾ ਹੋ ਸਕਦਾ ਹੈ। ਮਹੀਨਿਆਂ ਬਾਅਦ, ਅਗਲਾ apply ਖਤਰਨਾਕ ਹੋ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ Terraform ਹੁਣ ਹਕੀਕਤ ਦਾ ਵਰਣਨ ਨਹੀਂ ਕਰਦਾ।
ਬਹੁਤ ਜਿਆਦਾ ਜਟਿਲ ਮੋਡੀਊਲ: ਮੋਡੀਊਲ ਰੀਯੂਜ਼ ਲਈ ਭਲੇ ਹਨ, ਪਰ ਉਹ ਇੱਕ ਭੁੱਲ-ਭੁੱਲੈ ਬਣ ਸਕਦੇ ਹਨ—ਦਹਾਡਾਂ ਵੈਰੀਏਬਲ, ਨੇਸਟਡ ਮੋਡੀਊਲ, ਅਤੇ "ਜਾਦੂ" ਡਿਫਾਲਟ ਜੋ ਸਿਰਫ਼ ਇੱਕ ਵਿਅਕਤੀ ਸਮਝਦਾ ਹੈ। ਨਤੀਜਾ: ਡਿਲਿਵਰੀ ਸਲੇਦੀ ਨਹੀੰ, ਤੇਜ਼।
ਧੀਮੇ ਲੋਕਲ VMs: Vagrant ਬਾਕਸ ਸਮੇਂ ਦੇ ਨਾਲ ਭਾਰੀ ਹੋ ਸਕਦੇ ਹਨ (ਵੱਡੇ ਇਮੇਜ, ਬਹੁਤ ਸਾਰੀਆਂ ਸਰਵਿਸਾਂ, ਧੀਮਾ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ)। ਡੈਵਲਪਰ VM ਛੱਡ ਦੇਂਦੇ ਹਨ, ਅਤੇ "ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਵਾਤਾਵਰਣ" ਵਿਕਲਪਿਕ ਹੋ ਜਾਂਦਾ ਹੈ—ਜਦ ਤੱਕ ਕੁਝ ਪ੍ਰੋਡਕਸ਼ਨ 'ਚ ਟੁੱਟਦਾ ਨਹੀਂ।
Vagrant ਰੱਖੋ ਜਦੋਂ ਤੁਹਾਨੂੰ ਇੱਕ ਪੂਰਾ OS-ਸਤਰ ਵਾਤਾਵਰਣ ਚਾਹੀਦਾ ਹੈ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿਹਾਰ ਨੂੰ ਮਿਲਦਾ-ਜੁਲਦਾ ਹੋਵੇ (system services, kernel-ਸਤਰ ਅੰਤਰ) ਅਤੇ ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਇੱਕ ਸਥਿਰ "ਜਾਣਿਆ-ਪਛਾਣਿਆ" ਬੇਸਲਾਈਨ ਤੋਂ ਫਾਇਦਾ ਹੋਵੇ।
ਕੰਟੇਨਰਾਂ ਵੱਲ ਜਾਓ ਜਦੋਂ ਤੁਹਾਡਾ ਐਪ Docker ਵਿੱਚ ਚੰਗੀ ਤਰ੍ਹਾਂ ਚੱਲਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਤੇਜ਼ ਸਟਾਰਟਪ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਤੁਹਾਨੂੰ VM-ਲੇਵਲ ਸਹਾਇਤਾ ਦੀ ਲੋੜ ਨਹੀਂ। ਕੰਟੇਨਰ ਅਕਸਰ "ਮੇਰਾ VM ਧੀਮਾ ਹੈ" ਸਮੱਸਿਆ ਨੂੰ ਘਟਾਉਂਦੇ ਹਨ।
ਦੋਹਾਂ ਵਰਤੋ ਜਦੋਂ ਤੁਹਾਨੂੰ VM ਚਾਹੀਦਾ ਹੈ ਹੋਸਟ ਦੀ ਨਕਲ ਕਰਨ ਲਈ (ਜਾਂ ਸਹਾਇਕ ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਚਲਾਉਣ ਲਈ), ਪਰ ਐਪ ਨੂੰ ਕੰਟੇਨਰਾਂ ਵਿੱਚ ਦੌਰਾਉਂਦੇ ਹੋ। ਇਹ ਵਾਸ്തਵਿਕਤਾ ਨਾਲ ਗਤੀ ਦਾ ਸੰਤੁਲਨ ਕਰ ਸਕਦਾ ਹੈ।
Suggested links: /blog/terraform-workflow-checklist, /docs, /pricing
Terraform ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਬਦਲਾਅਾਂ ਨੂੰ ਸਪਸ਼ਟ, ਰਿਵਿਊਯੋਗ ਅਤੇ ਦੁਹਰਾਏ ਜਾਣਯੋਗ ਬਣਾਉਂਦਾ ਹੈ। ਕਨਸੋਲ ਕਲਿੱਕਾਂ ਜਾਂ ਰਨਬੁੱਕਸ 'ਤੇ ਨਿਰਭਰ ਹੋਣ ਦੀ ਥਾਂ, ਤੁਸੀਂ ਕਨਫਿਗਰੇਸ਼ਨ ਨੂੰ ਵਰਜ਼ਨ ਕੰਟਰੋਲ ਵਿੱਚ ਕਮਿਟ ਕਰਦੇ ਹੋ, terraform plan ਨਾਲ ਪ੍ਰਭਾਵ ਦਾ ਪੂਰਵ ਦਰਸ਼ਨ ਦੇਖਦੇ ਹੋ, ਅਤੇ ਹਰ ਵਾਤਾਵਰਣ ਵਿੱਚ ਲਗਾਤਾਰ ਬਦਲਾਅ ਲਾਗੂ ਕਰਦੇ ਹੋ।
ਇਹ ਸਭ ਤੋਂ ਵੱਧ ਕੀਮਤੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਕਈ ਲੋਕਾਂ ਨੂੰ ਸਾਂਝੀ ਇਨਫ੍ਰਾਸਟਰਕਚਰ ਬਦਲਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਉਹਨਾਂ ਲਈ ਇਹ ਕੰਮ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
Vagrant ਡੈਵਲਪਰਾਂ ਨੂੰ ਇੱਕ ਹੀ Vagrantfile ਤੋਂ ਲਿਆ ਗਿਆ ਜਾਣਿਆ-ਪਛਾਣਿਆ, ਇਕਸਾਰ OS-ਸਤਰ ਵਾਤਾਵਰਣ ਦਿੰਦਾ ਹੈ। ਇਹ ਓਨਬੋਰਡਿੰਗ ਸਮਾਂ ਘਟਾਉਂਦਾ ਹੈ, “ਮੇਰੇ ਲੈਪਟਾਪ 'ਤੇ ਚੱਲਦਾ ਹੈ” ਵਾਲੀ ਡ੍ਰਿਫਟ ਨੂੰ ਰੋਕਦਾ ਹੈ, ਅਤੇ ਉਹ ਬੱਗ ਪੁਨਰਉਤਪੱਤੀਯੋਗ ਬਣਾਉਂਦਾ ਹੈ ਜੋ OS ਪੈਕੇਜਾਂ, ਸਰਵਿਸਾਂ, ਜਾਂ ਨੈਟਵਰਕਿੰਗ ਨਾਲ ਜੁੜੇ ਹੋਣ।
ਇਹ ਖਾਸ ਤੌਰ 'ਤੇ ਲਾਭਦায়ক ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡੇ ਪ੍ਰੋਡਕਸ਼ਨ ਅਨੁਮਾਨ ਇੱਕ VM ਵਾਂਗ ਹੋਣ।
ਉਪਯੋਗ ਕਰੋ Vagrant ਲੋਕਲ ਵਾਤਾਵਰਣ (OS, ਸਰਵਿਸਾਂ, ਡਿਫ਼ਾਲਟ) ਨੂੰ ਸਟੈਂਡਰਡ ਕਰਣ ਲਈ। ਉਪਯੋਗ ਕਰੋ Terraform ਸਾਂਝੇ ਵਾਤਾਵਰਣ (ਨੈੱਟਵਰਕ, ਡੇਟਾਬੇਸ, ਕੰਪਿਊਟ, DNS, permissions) ਨੂੰ ਸਟੈਂਡਰਡ ਕਰਨ ਲਈ।
ਜੋੜਨ ਵਾਲਾ ਸੋਚ ਇੱਕ ਸਥਿਰ “ਕੋਂਟਰੈਕਟ” ਹੈ (ਪੋਰਟਸ, ਇenv vars ਜਿਵੇਂ DATABASE_URL, ਸਰਵਿਸ ਉਪਲਬਧਤਾ) ਜੋ ਲੈਪਟਾਪ → ਟੈਸਟ → ਪ੍ਰੋਡਕਸ਼ਨ ਦੌਰਾਨ ਇੱਕੋ ਜਿਹੀ ਰਹਿੰਦੀ ਹੈ।
ਇੱਕ ਸਟ੍ਰਕਚਰ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ ਜੋ ਰੀਯੂਜ਼ੇਬਲ ਬਿਲਡਿੰਗ ਬਲਾਕਾਂ ਨੂੰ ਵਾਤਾਵਰਣ-ਵਿਸ਼ੇਸ਼ ਸੈਟਿੰਗਾਂ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ:
/infra/modules ਵਿੱਚ ਰੱਖੋ/infra/envs/dev, /infra/envs/prod)/vagrant ਵਿੱਚ ਰੱਖੋਇਸ ਨਾਲ ਵਾਤਾਵਰਣਾਂ ਵਿਚ ਪ੍ਰੋਮੋਸ਼ਨ ਜ਼ਿਆਦਾ ਤਰ «ਵੈਰੀਏਬਲ ਬਦਲਾਅ» ਬਣ ਜਾਂਦਾ ਹੈ, ਨਾਕਿ ਕਾਪੀ/ਪੇਸਟ ਦੁਹਰਾਈ।
Terraform “state” ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿ Terraform ਯਾਦ ਰੱਖ ਸਕੇ ਕਿ ਤੁਹਾਡੀ ਕਨਫਿਗਰੇਸ਼ਨ ਕਿਸ ਅਸਲੀ ਰਿਸੋਰਸ ਨਾਲ ਮਿਲਦੀ ਹੈ। ਬਿਨਾਂ state ਦੇ, Terraform ਸਾਰੀਆਂ ਚੀਜ਼ਾਂ ਨੂੰ ਮੁੜ-ਸਕੈਨ ਕਰਨਾ ਪਵੇਗਾ, ਜੋ ਧੀਮਾ, ਅਨਿਸ਼ਚਿਤ ਅਤੇ ਕਈ ਵਾਰੀ ਅਸੰਭਵ ਹੈ।
State ਵਿੱਚ ਰਿਸੋਰਸ ਆਈਡੀਜ਼ ਅਤੇ ਕਈ ਵਾਰੀ ਅਹੰਕਾਰੀ ਵੈਲਯੂਜ਼ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਇਹ ਇੱਕ ਕਰੈਡੈਂਸ਼િયલ ਵਾਂਗ ਟ੍ਰੀਟ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ:
ਡ੍ਰਿਫਟ ਉਹ ਹੈ ਜਦੋਂ ਅਸਲ ਇਨਫ੍ਰਾਸਟਰਕਚਰ Terraform ਤੋਂ ਬਾਹਰ ਬਦਲਦਾ ਹੈ: ਕੰਸੋਲ ਸੰਪਾਦਨ, ਰਾਤ ਦੇ 2 ਵਜੇ ਹੌਟਫਿਕਸ, ਜਾਂ ਕੋਈ ਆਟੋਮੇਟਿਕ ਪ੍ਰੋਸੈਸ।
ਇਸ ਨੂੰ ਰੋਕਣ ਦੇ ਤਰੀਕੇ:
ਮੋਡੀਊਲ ਖਾਸ ਪੈਟਰਨਾਂ (ਨੈੱਟਵਰਕਿੰਗ, ਡੇਟਾਬੇਸ, ਸਰਵਿਸ ਡਿਪਲੋਇਮੈਂਟ) ਨੂੰ ਸਟੈਂਡਰਡ ਕਰਨ ਲਈ ਬਣਾਓ ਤਾਂ ਜੋ ਕੋਡ ਦੀ ਕਾਪੀ-ਪੇਸਟ ਨਾ ਹੋਵੇ। ਚੰਗੇ ਮੋਡੀਊਲਾਂ ਦੀਆਂ ਖਾਸੀਅਤਾਂ:
ਅਤੇ ਮੋਡੀਊਲ ਸਪ੍ਰਾਲ ਨੂੰ ਰੋਕਣ ਲਈ ਮਾਲਕੀਅਤ ਨਿਰਧਾਰਤ ਕਰੋ, README ਨਾਲ ਇਰਾਦਾ ਡਾਕਯੂਮੈਂਟ ਕਰੋ ਅਤੇ ਉਦਾਹਰਣ ਪ੍ਰਦਾਨ ਕਰੋ।
ਕਨਫਿਗਰੇਸ਼ਨ ਅਤੇ ਸੀਕ੍ਰੇਟਾਂ ਨੂੰ ਵੱਖ ਰੱਖੋ:
Vagrantfile ਵਿੱਚ ਪਾਸਵਰਡ, API ਕੀਜ਼ ਜਾਂ ਪ੍ਰਾਈਵੇਟ ਸਰਟੀਫਿਕੇਟ ਕਮਿਟ ਨਾ ਕਰੋplan ਅਤੇ apply ਲਈ ਵੱਖ-ਵੱਖ ਅਧਿਕਾਰ ਦਿਓ, ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਲਈ ਜ਼ਿਆਦਾ ਕਸ퇴ਰ ਨੀਤੀ ਰੱਖੋਇਸਦੇ ਨਾਲ-ਨਾਲ assume ਕਰੋ ਕਿ state ਵਿੱਚ ਸੰਵੇਦਨਸ਼ੀਲ ਆਈਡੀਜ਼ ਹੋ ਸਕਦੀਆਂ ਹਨ ਅਤੇ ਇਸਨੂੰ ਸੁਰੱਖਿਅਤ ਰੱਖੋ।
ਇੱਕ ਮਿਨੀਮਲ ਪਰ ਸਕੇਲ ਕਰਨ ਵਾਲਾ ਪਾਈਪਲਾਈਨ:
terraform fmt -check ਅਤੇ terraform validateterraform plan ਜਨਰੇਟ ਕਰੋ ਅਤੇ ਆਉਟਪੁੱਟ PR 'ਤੇ ਪਬਲਿਸ਼ ਕਰੋ, ਤਾਂ ਕਿ ਰਿਵਿਊਅਰ ਪੁੱਛ ਸਕਣ ਕਿ ਕੀ ਬਦਲੇਗਾ? ਕਿੱਥੇ? ਕਿਉਂ?Vagrant CI ਦੀ ਥਾਂ ਨਹੀਂ ਲੈ ਸਕਦਾ, ਪਰ ਇਹ ਲੋਕਲ ਟੈਸਟਿੰਗ ਨੂੰ CI-ਗਰੇਡ ਮਹਿਸੂਸ ਕਰਵਾ ਸਕਦਾ ਹੈ। ਸਾਂਝੇ Vagrantfile ਨਾਲ ਕੋਈ ਵੀ ਵਿਅਕਤੀ ਇੱਕੋ OS, ਪੈਕੇਜ ਅਤੇ ਸਰਵਿਸ ਵਰਜਨ ਉਤੇ VM ਬੂਟ ਕਰਕੇ ਬੱਗ ਦੀ ਪੁਨਰਉਤਪੱਤੀ ਕਰ ਸਕਦਾ ਹੈ।
ਇਹ ਖਾਸ ਤੌਰ 'ਤੇ ਉਦਾਹਰਣਾਂ ਲਈ ਲਾਭਦਾਇਕ ਹੈ:
ਜਦੋਂ ਤੁਸੀਂ VM-ਸਤਰ ਦਾ ਪੂਰਾ ਵਿਹਾਰ (systemd ਸਰਵਿਸਾਂ, kernel-ਸਤਰ ਫਰਕਾਂ), ਨੈਟਵਰਕ ਟੋਪੋਲੋਜੀ ਜਾਂ ਵਿਸ਼ੇਸ਼ ਡਿਸਟਰੋ-ਬੱਧ ਬੱਗਾਂ ਦੀ ਲੋੜ ਹੋਵੇ ਤਾਂ Vagrant ਰੱਖੋ।
ਜਦੋਂ ਤੁਹਾਡਾ ਐਪ Docker ਵਿੱਚ ਚੰਗੀ ਤਰ੍ਹਾਂ ਦੌੜਦਾ ਹੈ, ਤੁਹਾਨੂੰ ਤੇਜ਼ ਸਟਾਰਟਪ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ VM-ਲੇਵਲ ਵਿਵਹਾਰ ਦੀ ਲੋੜ ਨਹੀਂ, ਤਾਂ ਕੰਟੇਨਰਾਂ ਵੱਲ ਸੋਚੋ।
ਕਈ ਟੀਮ ਦੋਹਾਂ ਵਰਤਦੀਆਂ ਹਨ: ਐਪ ਲਈ ਕੰਟੇਨਰ ਅਤੇ ਪ੍ਰੋਡਕਸ਼ਨ-ਜਿਹੇ ਹੋਸਟ ਵਾਤਾਵਰਣ ਲਈ Vagrant VM।
terraform applyਇਸ ਤਰ੍ਹਾਂ PRs ਸਬੂਤ (plans) ਪੈਦਾ ਕਰਦੇ ਹਨ ਅਤੇ ਮਨਜ਼ੂਰੀ ਬਦਲਾਅ ਨੂੰ ਅਥਾਰਾਈਜ਼ ਕਰਦੀ ਹੈ।