Terraform ਤੋਂ CloudFormation ਵਿੱਚ ਬਦਲਿਆ - ਅਤੇ ਇਸ 'ਤੇ ਅਫਸੋਸ ਪ੍ਰਗਟ ਕੀਤਾ

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

Terraform ਅਤੇ CloudFormation ਦੇ ਨਾਲ ਅਨੁਭਵ ਦੀ ਤੁਲਨਾ ਕਰਨਾ

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

ਟੈਰਾਫਾਰਮ ਭਿਆਨਕ

ਬੀਟਾ ਸਾਫਟਵੇਅਰ

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

ਦੂਜੇ ਪਾਸੇ, AWS ਨੇ ਪਿਛੜੇ ਅਨੁਕੂਲਤਾ ਨੂੰ ਕਾਇਮ ਰੱਖਣ ਲਈ ਵਧੀਆ ਕੰਮ ਕੀਤਾ ਹੈ। ਇਹ ਸ਼ਾਇਦ ਇਸ ਲਈ ਹੈ ਕਿਉਂਕਿ ਉਹਨਾਂ ਦੀਆਂ ਸੇਵਾਵਾਂ ਦੀ ਅਕਸਰ ਸੰਸਥਾ ਦੇ ਅੰਦਰ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਂਚ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਕੇਵਲ ਤਦ ਹੀ, ਨਾਮ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ, ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਲਈ "ਉਨ੍ਹਾਂ ਨੇ ਸਖ਼ਤ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ" ਇੱਕ ਛੋਟੀ ਗੱਲ ਹੈ। AWS ਵਾਂਗ ਵਿਭਿੰਨ ਅਤੇ ਗੁੰਝਲਦਾਰ ਸਿਸਟਮ ਲਈ APIs ਦੇ ਨਾਲ ਪਿਛੜੇ ਅਨੁਕੂਲਤਾ ਨੂੰ ਬਣਾਈ ਰੱਖਣਾ ਬਹੁਤ ਹੀ ਮੁਸ਼ਕਲ ਹੈ। ਕਿਸੇ ਵੀ ਵਿਅਕਤੀ ਨੂੰ ਜਿਸਨੂੰ ਜਨਤਕ APIs ਨੂੰ ਕਾਇਮ ਰੱਖਣਾ ਪਿਆ ਹੈ ਜੋ ਉਹਨਾਂ ਦੀ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਵਰਤੇ ਜਾਂਦੇ ਹਨ, ਨੂੰ ਸਮਝਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਇੰਨੇ ਸਾਲਾਂ ਲਈ ਅਜਿਹਾ ਕਰਨਾ ਕਿੰਨਾ ਮੁਸ਼ਕਲ ਹੈ. ਪਰ CloudFormation ਦਾ ਵਿਵਹਾਰ, ਮੇਰੀ ਯਾਦ ਵਿੱਚ, ਸਾਲਾਂ ਵਿੱਚ ਕਦੇ ਨਹੀਂ ਬਦਲਿਆ ਹੈ.

ਲੱਤ ਨੂੰ ਮਿਲੋ... ਇਹ ਗੋਲੀ ਹੈ

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

ਟੈਰਾਫਾਰਮ ਮਹਾਨ

ਅਧੂਰੇ ਰਾਜਾਂ ਤੋਂ ਰਿਕਵਰੀ

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

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

ਦਸਤਾਵੇਜ਼ ਸਥਿਤੀ ਵਿੱਚ ਸਪੱਸ਼ਟ ਤਬਦੀਲੀਆਂ

“ਠੀਕ ਹੈ, ਲੋਡ ਬੈਲੇਂਸਰ, ਤੁਸੀਂ ਬਦਲ ਰਹੇ ਹੋ। ਪਰ ਕਿਦਾ?"

-ਚਿੰਤਤ ਇੰਜੀਨੀਅਰ, "ਸਵੀਕਾਰ ਕਰੋ" ਬਟਨ ਨੂੰ ਦਬਾਉਣ ਲਈ ਤਿਆਰ।

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

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

ਲਚਕੀਲਾਪਨ

ਸਾਫਟਵੇਅਰ ਨੂੰ ਪਿੱਛੇ ਵੱਲ ਲਿਖੋ।

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

git ਵਿੱਚ ਮੋਡੀਊਲ

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

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

ਕੋਡ ਦੇ ਤੌਰ 'ਤੇ ਕਾਰਵਾਈਆਂ

"ਆਓ ਇਸਨੂੰ ਸਕ੍ਰਿਪਟ ਕਰੀਏ ਅਤੇ ਠੀਕ ਹੈ।"

- ਟੈਰਾਫਾਰਮ ਸਾਈਕਲ ਦੀ ਖੋਜ ਕਰਨ ਤੋਂ 3 ਸਾਲ ਪਹਿਲਾਂ ਇੱਕ ਇੰਜੀਨੀਅਰ।

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

ਕੋਡ ਦੇ ਤੌਰ ਤੇ ਕੋਡ

ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਵੀ ਹੈ ਜਿਸ 'ਤੇ ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ।

ਕੋਡ ਦੇ ਤੌਰ 'ਤੇ ਬੁਨਿਆਦੀ ਢਾਂਚਾ

ਪਰ ਉਹ ਕਿੱਥੋਂ ਦੀ ਹੈ? ਇਸ ਦੀ ਨਿਗਰਾਨੀ ਕਿਵੇਂ ਕਰੀਏ? ਤੁਹਾਡਾ ਕੋਡ ਕਿੱਥੇ ਰਹਿੰਦਾ ਹੈ? ਕੀ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਪਹੁੰਚ ਅਨੁਮਤੀ ਦੀ ਲੋੜ ਹੈ?

ਕੋਡ ਦੇ ਤੌਰ 'ਤੇ ਕਾਰਵਾਈਆਂ

ਇੱਕ ਸਾਫਟਵੇਅਰ ਡਿਵੈਲਪਰ ਹੋਣ ਦਾ ਮਤਲਬ ਸਿਰਫ਼ ਕੋਡ ਲਿਖਣਾ ਨਹੀਂ ਹੈ।

AWS ਸਿਰਫ਼ ਇੱਕ ਨਹੀਂ ਹੈ: ਤੁਸੀਂ ਸ਼ਾਇਦ ਦੂਜੇ ਪ੍ਰਦਾਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ। SignalFx, PagerDuty ਜਾਂ Github. ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਸੀਆਈ/ਸੀਡੀ ਲਈ ਇੱਕ ਅੰਦਰੂਨੀ ਜੇਨਕਿੰਸ ਸਰਵਰ ਹੋਵੇ ਜਾਂ ਨਿਗਰਾਨੀ ਲਈ ਇੱਕ ਅੰਦਰੂਨੀ ਗ੍ਰਾਫਾਨਾ ਡੈਸ਼ਬੋਰਡ ਹੋਵੇ। ਕੋਡ ਦੇ ਤੌਰ 'ਤੇ ਇਨਫਰਾ ਨੂੰ ਵੱਖ-ਵੱਖ ਕਾਰਨਾਂ ਕਰਕੇ ਚੁਣਿਆ ਗਿਆ ਹੈ, ਅਤੇ ਹਰੇਕ ਸਾਫਟਵੇਅਰ ਨਾਲ ਸਬੰਧਤ ਹਰ ਚੀਜ਼ ਲਈ ਬਰਾਬਰ ਮਹੱਤਵਪੂਰਨ ਹੈ।

ਜਦੋਂ ਮੈਂ ਟਵਿਚ 'ਤੇ ਕੰਮ ਕੀਤਾ, ਅਸੀਂ ਐਮਾਜ਼ਾਨ ਦੇ ਮਿਕਸਡ ਏਮਬੇਡਡ ਅਤੇ AWS ਸਿਸਟਮਾਂ ਦੇ ਅੰਦਰ ਸੇਵਾਵਾਂ ਨੂੰ ਤੇਜ਼ ਕੀਤਾ। ਅਸੀਂ ਸੰਚਾਲਨ ਲਾਗਤਾਂ ਨੂੰ ਵਧਾਉਂਦੇ ਹੋਏ, ਬਹੁਤ ਸਾਰੀਆਂ ਮਾਈਕਰੋਸੇਵਾਵਾਂ ਦਾ ਸਮਰਥਨ ਕੀਤਾ ਅਤੇ ਸਮਰਥਨ ਕੀਤਾ। ਚਰਚਾ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਹੋਈ:

• Я: ਹਾਏ, ਇਹ ਇੱਕ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਨੂੰ ਓਵਰਕਲੌਕ ਕਰਨ ਲਈ ਬਹੁਤ ਸਾਰੇ ਸੰਕੇਤ ਹਨ। ਮੈਨੂੰ ਇੱਕ AWS ਖਾਤਾ ਬਣਾਉਣ ਲਈ ਇਸ ਕੂੜੇ ਦੀ ਵਰਤੋਂ ਕਰਨੀ ਪਵੇਗੀ (ਅਸੀਂ 2 ਖਾਤਿਆਂ 'ਤੇ ਗਏ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸ), ਫਿਰ ਇਹ ਅਲਰਟ ਸਥਾਪਤ ਕਰਨ ਲਈ, ਇਹ ਇੱਕ ਕੋਡ ਰਿਪੋਜ਼ਟਰੀ ਲਈ, ਅਤੇ ਇਹ ਇੱਕ ਈਮੇਲ ਸੂਚੀ ਲਈ, ਅਤੇ ਫਿਰ ਇਹ ਇੱਕ...
• ਲੀਡ: ਚਲੋ ਇਸਨੂੰ ਸਕ੍ਰਿਪਟ ਕਰੀਏ ਅਤੇ ਠੀਕ ਹੈ।
• Я: ਠੀਕ ਹੈ, ਪਰ ਸਕ੍ਰਿਪਟ ਆਪਣੇ ਆਪ ਬਦਲ ਜਾਵੇਗੀ। ਸਾਨੂੰ ਇਹ ਜਾਂਚ ਕਰਨ ਲਈ ਇੱਕ ਤਰੀਕੇ ਦੀ ਲੋੜ ਹੋਵੇਗੀ ਕਿ ਇਹ ਸਾਰੇ ਬਿਲਟ-ਇਨ ਐਮਾਜ਼ਾਨ ਗਿਜ਼ਮੋਸ ਅੱਪ ਟੂ ਡੇਟ ਹਨ।
• ਲੀਡ: ਇਹ ਵਧੀਆ ਜਾਪਦਾ ਹੈ. ਅਤੇ ਅਸੀਂ ਇਸਦੇ ਲਈ ਇੱਕ ਸਕ੍ਰਿਪਟ ਲਿਖਾਂਗੇ।
• Я: ਬਹੁਤ ਵਧੀਆ! ਅਤੇ ਸਕ੍ਰਿਪਟ ਨੂੰ ਅਜੇ ਵੀ ਪੈਰਾਮੀਟਰ ਸੈੱਟ ਕਰਨ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਕੀ ਉਹ ਉਨ੍ਹਾਂ ਨੂੰ ਸਵੀਕਾਰ ਕਰੇਗਾ?
• ਲੀਡ: ਉਸਨੂੰ ਲੈ ਜਾਣ ਦਿਓ ਜਿੱਥੇ ਉਹ ਜਾਂਦਾ ਹੈ!
• Я: ਪ੍ਰਕਿਰਿਆ ਬਦਲ ਸਕਦੀ ਹੈ ਅਤੇ ਪਿਛੜੇ ਅਨੁਕੂਲਤਾ ਖਤਮ ਹੋ ਜਾਵੇਗੀ। ਕਿਸੇ ਕਿਸਮ ਦੇ ਅਰਥ ਸੰਸਕਰਣ ਨਿਯੰਤਰਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।
• ਲੀਡ: ਉੱਤਮ ਵਿਚਾਰ!
• Я: ਟੂਲਸ ਨੂੰ ਯੂਜ਼ਰ ਇੰਟਰਫੇਸ ਦੇ ਅੰਦਰ, ਹੱਥੀਂ ਬਦਲਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਸਾਨੂੰ ਇਸਦੀ ਜਾਂਚ ਕਰਨ ਅਤੇ ਠੀਕ ਕਰਨ ਲਈ ਇੱਕ ਤਰੀਕੇ ਦੀ ਲੋੜ ਪਵੇਗੀ।

…3 ਸਾਲ ਬਾਅਦ:

• ਲੀਡ: ਅਤੇ ਸਾਨੂੰ ਟੈਰਾਫਾਰਮ ਮਿਲਿਆ।

ਕਹਾਣੀ ਦਾ ਨੈਤਿਕ ਹੈ: ਭਾਵੇਂ ਤੁਸੀਂ ਹਰ ਚੀਜ਼ ਐਮਾਜ਼ਾਨ ਵਿੱਚ ਏੜੀ ਉੱਤੇ ਸਿਰ, ਤੁਸੀਂ ਅਜੇ ਵੀ ਅਜਿਹੀ ਕੋਈ ਚੀਜ਼ ਵਰਤ ਰਹੇ ਹੋ ਜੋ AWS ਤੋਂ ਨਹੀਂ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਸੇਵਾਵਾਂ ਦੀ ਇੱਕ ਅਵਸਥਾ ਹੈ ਜੋ ਉਸ ਸਥਿਤੀ ਨੂੰ ਸਮਕਾਲੀ ਰੱਖਣ ਲਈ ਇੱਕ ਸੰਰਚਨਾ ਭਾਸ਼ਾ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ।

CloudFormation lambda ਬਨਾਮ git ਮੋਡੀਊਲ ਟੈਰਾਫਾਰਮ

lambda CloudFormation ਦਾ ਕਸਟਮ ਤਰਕ ਮੁੱਦੇ ਦਾ ਹੱਲ ਹੈ। ਲਾਂਬਡਾ ਨਾਲ ਤੁਸੀਂ ਕਰ ਸਕਦੇ ਹੋ ਮੈਕਰੋ ਬਣਾਓ ਜ ਉਪਭੋਗਤਾ ਸਰੋਤ. ਇਹ ਪਹੁੰਚ ਵਾਧੂ ਜਟਿਲਤਾਵਾਂ ਨੂੰ ਪੇਸ਼ ਕਰਦੀ ਹੈ ਜੋ ਟੇਰਾਫਾਰਮ ਦੇ ਗਿੱਟ ਮੋਡੀਊਲ ਦੇ ਅਰਥ ਸੰਸਕਰਣ ਵਿੱਚ ਮੌਜੂਦ ਨਹੀਂ ਹਨ। ਮੇਰੇ ਲਈ, ਸਭ ਤੋਂ ਵੱਧ ਦਬਾਉਣ ਵਾਲੀ ਸਮੱਸਿਆ ਇਹਨਾਂ ਸਾਰੇ ਉਪਭੋਗਤਾ ਲੈਂਬਡਾਸ ਲਈ ਅਨੁਮਤੀਆਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰ ਰਹੀ ਸੀ (ਅਤੇ ਇਹ ਦਰਜਨਾਂ AWS ਖਾਤੇ ਹਨ). ਇੱਕ ਹੋਰ ਮਹੱਤਵਪੂਰਨ ਸਮੱਸਿਆ ਸੀ "ਪਹਿਲਾਂ ਕੀ ਆਇਆ, ਚਿਕਨ ਜਾਂ ਆਂਡਾ?" ਸਮੱਸਿਆ: ਇਹ ਲਾਂਬਡਾ ਕੋਡ ਨਾਲ ਸਬੰਧਤ ਸੀ। ਇਹ ਫੰਕਸ਼ਨ ਆਪਣੇ ਆਪ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਅਤੇ ਕੋਡ ਹੈ, ਅਤੇ ਇਸਨੂੰ ਖੁਦ ਨਿਗਰਾਨੀ ਅਤੇ ਅੱਪਡੇਟ ਦੀ ਲੋੜ ਹੈ। ਤਾਬੂਤ ਵਿੱਚ ਅੰਤਮ ਮੇਖ ਲਾਂਬਡਾ ਕੋਡ ਤਬਦੀਲੀਆਂ ਨੂੰ ਅਰਥਪੂਰਨ ਰੂਪ ਵਿੱਚ ਅਪਡੇਟ ਕਰਨ ਵਿੱਚ ਮੁਸ਼ਕਲ ਸੀ; ਸਾਨੂੰ ਇਹ ਵੀ ਯਕੀਨੀ ਬਣਾਉਣਾ ਪਿਆ ਕਿ ਸਿੱਧੀ ਕਮਾਂਡ ਤੋਂ ਬਿਨਾਂ ਸਟੈਕ ਐਕਸ਼ਨ ਦੌੜਾਂ ਦੇ ਵਿਚਕਾਰ ਨਹੀਂ ਬਦਲੇ।

ਮੈਨੂੰ ਯਾਦ ਹੈ ਕਿ ਇੱਕ ਵਾਰ ਮੈਂ ਇੱਕ ਕਲਾਸਿਕ ਲੋਡ ਬੈਲੈਂਸਰ ਦੇ ਨਾਲ ਲਚਕੀਲੇ ਬੀਨਸਟਾਲ ਵਾਤਾਵਰਣ ਲਈ ਇੱਕ ਕੈਨਰੀ ਤੈਨਾਤੀ ਬਣਾਉਣਾ ਚਾਹੁੰਦਾ ਸੀ। ਸਭ ਤੋਂ ਆਸਾਨ ਕੰਮ ਇਹ ਹੋਵੇਗਾ ਕਿ ਉਤਪਾਦਨ ਵਾਤਾਵਰਨ ਦੇ ਅੱਗੇ EB ਲਈ ਦੂਜੀ ਤੈਨਾਤੀ ਕੀਤੀ ਜਾਵੇ, ਇਸਨੂੰ ਇੱਕ ਕਦਮ ਹੋਰ ਅੱਗੇ ਲੈ ਕੇ: ਆਟੋ-ਸਕੇਲਿੰਗ ਕੈਨਰੀ ਡਿਪਲਾਇਮੈਂਟ ਗਰੁੱਪ ਨੂੰ ਉਤਪਾਦਨ ਵਾਤਾਵਰਣ ਵਿੱਚ ਤੈਨਾਤੀ LB ਦੇ ਨਾਲ ਜੋੜਨਾ। ਅਤੇ ਕਿਉਂਕਿ Terraform ਵਰਤਦਾ ਹੈ ASG beantalk ਇੱਕ ਸਿੱਟੇ ਵਜੋਂ, ਇਸ ਲਈ ਟੈਰਾਫਾਰਮ ਵਿੱਚ ਕੋਡ ਦੀਆਂ 4 ਵਾਧੂ ਲਾਈਨਾਂ ਦੀ ਲੋੜ ਹੋਵੇਗੀ। ਜਦੋਂ ਮੈਂ ਪੁੱਛਿਆ ਕਿ ਕੀ ਕਲਾਉਡਫੋਰਮੇਸ਼ਨ ਵਿੱਚ ਇੱਕ ਤੁਲਨਾਤਮਕ ਹੱਲ ਹੈ, ਤਾਂ ਉਨ੍ਹਾਂ ਨੇ ਮੈਨੂੰ ਇੱਕ ਤੈਨਾਤੀ ਪਾਈਪਲਾਈਨ ਅਤੇ ਹਰ ਚੀਜ਼ ਦੇ ਨਾਲ ਇੱਕ ਪੂਰੀ ਗਿੱਟ ਰਿਪੋਜ਼ਟਰੀ ਵੱਲ ਇਸ਼ਾਰਾ ਕੀਤਾ, ਸਭ ਕੁਝ ਉਸ ਚੀਜ਼ ਲਈ ਜੋ ਟੈਰਾਫਾਰਮ ਕੋਡ ਦੀਆਂ ਮਾੜੀਆਂ 4 ਲਾਈਨਾਂ ਕਰ ਸਕਦੀਆਂ ਹਨ।

ਇਹ ਵਹਿਣ ਨੂੰ ਬਿਹਤਰ ਢੰਗ ਨਾਲ ਖੋਜਦਾ ਹੈ

ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਅਸਲੀਅਤ ਉਮੀਦਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦੀ ਹੈ।

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

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

CDK ਅਤੇ CloudFormation ਦਾ ਭਵਿੱਖ

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

ਤਾਂ ਜੋ ਟੈਰਾਫਾਰਮ ਨਿਰਾਸ਼ ਨਾ ਹੋਵੇ

ਇਹ "ਇੱਕ ਕੋਡ ਦੇ ਰੂਪ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚਾ" ਹੈ, ਨਾ ਕਿ "ਇੱਕ ਟੈਕਸਟ ਦੇ ਰੂਪ ਵਿੱਚ"।

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

ਚੰਗੇ ਸਾਫਟਵੇਅਰ ਡਿਵੈਲਪਮੈਂਟ ਦੇ ਸਿਧਾਂਤ ਟੈਰਾਫਾਰਮ 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦੇ ਹਨ।

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

ਕੋਡ ਨੂੰ ਦਸਤਾਵੇਜ਼ੀ ਕਿਵੇਂ ਨਹੀਂ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ?

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

ਅਸੀਂ ਉਹਨਾਂ ਸੇਵਾਵਾਂ ਨੂੰ ਕਿਵੇਂ ਤੈਨਾਤ ਕਰ ਸਕਦੇ ਹਾਂ ਜੋ ਪਹਿਲਾਂ ਇੱਕ ਵੱਡਾ ਮੁੱਖ() ਫੰਕਸ਼ਨ ਸੀ?

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

ਕੀ ਤੁਹਾਡੀ ਕੰਪਨੀ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੀ?

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

ਕੀ ਤੁਸੀਂ PEP8 ਜਾਂ gofmt ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰ ਰਹੇ ਹੋ?

ਜ਼ਿਆਦਾਤਰ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਇੱਕ ਮਿਆਰੀ, ਪ੍ਰਵਾਨਿਤ ਫਾਰਮੈਟਿੰਗ ਸਕੀਮ ਹੁੰਦੀ ਹੈ। ਪਾਈਥਨ ਵਿੱਚ ਇਹ PEP8 ਹੈ। ਗੋ ਵਿੱਚ - gofmt. ਟੈਰਾਫਾਰਮ ਦਾ ਆਪਣਾ ਹੈ: terraform fmt. ਆਪਣੀ ਸਿਹਤ ਲਈ ਇਸਦਾ ਅਨੰਦ ਲਓ!

ਕੀ ਤੁਸੀਂ JavaScript ਨੂੰ ਜਾਣੇ ਬਿਨਾਂ ਰੀਐਕਟ ਦੀ ਵਰਤੋਂ ਕਰੋਗੇ?

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

ਕੀ ਤੁਸੀਂ ਸਿੰਗਲਟਨ ਜਾਂ ਨਿਰਭਰਤਾ ਇੰਜੈਕਸ਼ਨ ਨਾਲ ਕੋਡਿੰਗ ਕਰ ਰਹੇ ਹੋ?

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

ਕੀ ਤੁਹਾਡੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਦਸ ਚੀਜ਼ਾਂ ਚੰਗੀਆਂ ਕਰਦੀਆਂ ਹਨ ਜਾਂ ਇੱਕ ਚੀਜ਼ ਵਧੀਆ?

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

ਤੁਸੀਂ ਬੈਕਵਰਡ ਅਨੁਕੂਲਤਾ ਤੋਂ ਬਿਨਾਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਕਿਵੇਂ ਕਰਦੇ ਹੋ?

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

ਕੀ ਤੁਹਾਡੀ ਉਤਪਾਦਨ ਸੇਵਾ ਤੁਹਾਡੇ ਲੈਪਟਾਪ ਜਾਂ ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ ਚੱਲ ਰਹੀ ਹੈ?

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

ਕੀ ਤੁਸੀਂ ਟੈਸਟ ਨਹੀਂ ਲਿਖਦੇ?

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

ਟੈਰਾਫਾਰਮ ਅਤੇ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼

ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਕੰਪਨੀਆਂ ਦੀ ਜ਼ਿੰਦਗੀ ਅਤੇ ਮੌਤ ਨਵੇਂ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਵਰਕਸਟੈਕਸ ਦੀ ਗਤੀ, ਨਵੀਨਤਾ ਅਤੇ ਵਿਘਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ।

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

ਸਰੋਤ: www.habr.com