ਆਪਣੇ ਨੈੱਟਵਰਕ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਨਿਯੰਤਰਣ ਕਿਵੇਂ ਲੈਣਾ ਹੈ। ਅਧਿਆਇ ਚਾਰ. ਆਟੋਮੇਸ਼ਨ। ਟੈਂਪਲੇਟਸ

ਇਹ ਲੇਖ "ਤੁਹਾਡੇ ਨੈੱਟਵਰਕ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਨਿਯੰਤਰਣ ਕਿਵੇਂ ਲੈਣਾ ਹੈ" ਦੀ ਲੜੀ ਵਿੱਚ ਛੇਵਾਂ ਹੈ। ਲੜੀ ਦੇ ਸਾਰੇ ਲੇਖਾਂ ਦੀ ਸਮੱਗਰੀ ਅਤੇ ਲਿੰਕ ਲੱਭੇ ਜਾ ਸਕਦੇ ਹਨ ਇੱਥੇ.

ਕਈ ਵਿਸ਼ਿਆਂ ਨੂੰ ਪਿੱਛੇ ਛੱਡ ਕੇ, ਮੈਂ ਇੱਕ ਨਵਾਂ ਅਧਿਆਏ ਸ਼ੁਰੂ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ।

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

ਨੈੱਟਵਰਕ ਲਈ DevOps

ਇੱਕ ਸਕ੍ਰਿਪਟ ਦੇ ਨਾਲ ਇੱਕ ਸੰਰਚਨਾ ਬਣਾਉਣਾ, IT ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਤਬਦੀਲੀਆਂ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਲਈ GIT ਦੀ ਵਰਤੋਂ ਕਰਨਾ, ਰਿਮੋਟ "ਅੱਪਲੋਡਿੰਗ" - ਇਹ ਵਿਚਾਰ ਪਹਿਲਾਂ ਆਉਂਦੇ ਹਨ ਜਦੋਂ ਤੁਸੀਂ DevOps ਪਹੁੰਚ ਦੇ ਤਕਨੀਕੀ ਲਾਗੂਕਰਨ ਬਾਰੇ ਸੋਚਦੇ ਹੋ। ਫਾਇਦੇ ਸਪੱਸ਼ਟ ਹਨ. ਪਰ, ਬਦਕਿਸਮਤੀ ਨਾਲ, ਨੁਕਸਾਨ ਵੀ ਹਨ.

ਜਦੋਂ 5 ਸਾਲ ਤੋਂ ਵੱਧ ਸਮਾਂ ਪਹਿਲਾਂ, ਸਾਡੇ ਡਿਵੈਲਪਰ ਸਾਡੇ ਕੋਲ ਆਏ, ਨੈਟਵਰਕਰ, ਇਹਨਾਂ ਪ੍ਰਸਤਾਵਾਂ ਨਾਲ, ਅਸੀਂ ਖੁਸ਼ ਨਹੀਂ ਹੋਏ.

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

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

ਜਾਂ, ਇਹ ਕਿਵੇਂ ਸਮਝਣਾ ਹੈ ਕਿ ਸੰਰਚਨਾ ਕਮਾਂਡਾਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਗਲਤੀ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਕੀ ਕਰਨਾ ਹੈ?

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

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

ਪ੍ਰੋਜੈਕਟ

ਪਿਛਲੇ ਦੋ ਸਾਲਾਂ ਤੋਂ ਮੈਂ ਇੱਕ ਵੱਡੇ ਪ੍ਰਦਾਤਾ ਲਈ ਇੱਕ ਡੇਟਾ ਸੈਂਟਰ ਬਣਾਉਣ ਲਈ ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਹਿੱਸਾ ਲੈ ਰਿਹਾ ਹਾਂ। ਮੈਂ ਇਸ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ F5 ਅਤੇ ਪਾਲੋ ਆਲਟੋ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹਾਂ। ਸਿਸਕੋ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਇਹ "ਤੀਜੀ ਧਿਰ ਦਾ ਉਪਕਰਣ" ਹੈ।

ਮੇਰੇ ਲਈ ਨਿੱਜੀ ਤੌਰ 'ਤੇ, ਇਸ ਪ੍ਰੋਜੈਕਟ ਦੇ ਦੋ ਵੱਖਰੇ ਪੜਾਅ ਹਨ.

ਪਹਿਲੇ ਪੜਾਅ

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

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

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

ਹੁਣ ਅਸੀਂ ਥੋੜਾ ਜਿਹਾ ਆਲੇ ਦੁਆਲੇ ਦੇਖ ਸਕਦੇ ਹਾਂ.
ਅਤੇ ਇਹ ਦੂਜੇ ਪੜਾਅ ਦੀ ਸ਼ੁਰੂਆਤ ਸੀ.

ਦੂਜਾ ਪੜਾਅ

ਮੈਂ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਆਟੋਮੈਟਿਕ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ.

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

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

ਇਸ ਲਈ, YAML ਅਤੇ Jinja2 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ, IP ਐਡਰੈੱਸ, BGP AS ਨੰਬਰ, ... ਵਰਗੇ ਸੰਰਚਨਾ ਮਾਪਦੰਡਾਂ ਵਾਲੀ YAML ਫਾਈਲ ਪੂਰੀ ਤਰ੍ਹਾਂ NIP ਦੀ ਭੂਮਿਕਾ ਨੂੰ ਪੂਰਾ ਕਰਦੀ ਹੈ, ਜਦੋਂ ਕਿ Jinja2 ਟੈਂਪਲੇਟਾਂ ਵਿੱਚ ਡਿਜ਼ਾਈਨ ਦੇ ਅਨੁਸਾਰੀ ਸੰਟੈਕਸ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ, ਯਾਨੀ ਇਹ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਇੱਕ LLD ਦਾ ਪ੍ਰਤੀਬਿੰਬ.

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

ਹੁਣ ਤਬਦੀਲੀ ਦੀ ਪ੍ਰਕਿਰਿਆ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

• YAML ਫਾਈਲ ਨੂੰ ਬਦਲਿਆ
• ਇੱਕ ਟੈਪਲੇਟ (ਜਿਨਜਾ2) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਸੰਰਚਨਾ ਫਾਈਲ ਬਣਾਈ
• ਇੱਕ ਰਿਮੋਟ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਸੰਭਾਲਿਆ
• ਸਾਜ਼-ਸਾਮਾਨ 'ਤੇ ਬਣਾਈ ਗਈ ਸੰਰਚਨਾ ਨੂੰ ਅੱਪਲੋਡ ਕੀਤਾ
• ਮੈਂ ਇੱਕ ਗਲਤੀ ਦੇਖੀ
• YAML ਫਾਈਲ ਜਾਂ Jinja2 ਟੈਂਪਲੇਟ ਨੂੰ ਬਦਲਿਆ
• ਇੱਕ ਟੈਪਲੇਟ (ਜਿਨਜਾ2) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਸੰਰਚਨਾ ਫਾਈਲ ਬਣਾਈ
• ...

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

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

ਦੇਵ ਅਤੇ ਸਟੇਜਿੰਗ

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

ਆਓ ਸੰਖੇਪ ਕਰੀਏ

ਇਸ ਲਈ, ਮੇਰੇ ਕੋਲ ਤਲ ਲਾਈਨ ਵਿੱਚ ਕੀ ਹੈ?

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

ਇਹ ਸਭ ਇਸ ਤੱਥ ਵੱਲ ਅਗਵਾਈ ਕਰਦਾ ਹੈ ਕਿ

• ਗਲਤੀ ਦਰ ਲਗਭਗ 0 ਤੱਕ ਘੱਟ ਗਈ ਹੈ
• 90 ਫੀਸਦੀ ਰੁਟੀਨ ਖਤਮ ਹੋ ਚੁੱਕੀ ਹੈ
• ਲਾਗੂ ਕਰਨ ਦੀ ਗਤੀ ਵਿੱਚ ਕਾਫ਼ੀ ਵਾਧਾ ਹੋਇਆ ਹੈ

ਪੇ, F5Y, ACY

ਮੈਂ ਕਿਹਾ ਕਿ ਇਹ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ ਇਹ ਸਮਝਣ ਲਈ ਕੁਝ ਉਦਾਹਰਣਾਂ ਹੀ ਕਾਫੀ ਹਨ।
ਮੇਰੇ ਕੰਮ ਦੇ ਦੌਰਾਨ ਜੋ ਬਣਾਇਆ ਗਿਆ ਸੀ ਉਸਦਾ ਇੱਕ ਛੋਟਾ (ਅਤੇ ਬੇਸ਼ੱਕ ਸੰਸ਼ੋਧਿਤ) ਸੰਸਕਰਣ ਇੱਥੇ ਹੈ।

ਪੇ = ਤੈਨਾਤੀ Pਆਲੋ Aਤੋਂ Yaml = Yaml ਤੋਂ ਪਾਲੋ ਆਲਟੋ
F5Y = ਤੈਨਾਤੀ F5 ਤੱਕ Yaml = F5 ਤੱਕ Yaml (ਜਲਦੀ ਆ ਰਿਹਾ ਹੈ)
ਏ.ਸੀ.ਵਾਈ = ਤੈਨਾਤੀ ACਮੈਂ ਤੋਂ Yaml = F5 ਤੱਕ Yaml

ਮੈਂ ACY ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ ਜੋੜਾਂਗਾ (ACI ਨਾਲ ਉਲਝਣ ਵਿੱਚ ਨਹੀਂ ਹੋਣਾ)।

ਜਿਨ੍ਹਾਂ ਨੇ ਏਸੀਆਈ ਨਾਲ ਕੰਮ ਕੀਤਾ ਹੈ ਉਹ ਜਾਣਦੇ ਹਨ ਕਿ ਇਹ ਚਮਤਕਾਰ (ਅਤੇ ਇੱਕ ਚੰਗੇ ਤਰੀਕੇ ਨਾਲ) ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਨੈੱਟਵਰਕਰਾਂ ਦੁਆਰਾ ਨਹੀਂ ਬਣਾਇਆ ਗਿਆ ਸੀ :). ਉਹ ਸਭ ਕੁਝ ਭੁੱਲ ਜਾਓ ਜੋ ਤੁਸੀਂ ਨੈੱਟਵਰਕ ਬਾਰੇ ਜਾਣਦੇ ਸੀ - ਇਹ ਤੁਹਾਡੇ ਲਈ ਲਾਭਦਾਇਕ ਨਹੀਂ ਹੋਵੇਗਾ!
ਇਹ ਥੋੜਾ ਅਤਿਕਥਨੀ ਹੈ, ਪਰ ਇਹ ਮੋਟੇ ਤੌਰ 'ਤੇ ਇਸ ਭਾਵਨਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਮੈਂ ਪਿਛਲੇ 3 ਸਾਲਾਂ ਤੋਂ, ACI ਨਾਲ ਕੰਮ ਕਰਦਿਆਂ, ਲਗਾਤਾਰ ਅਨੁਭਵ ਕਰ ਰਿਹਾ ਹਾਂ।

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

ਇਸ ਪ੍ਰੋਜੈਕਟ ਦੇ ਇੰਜੀਨੀਅਰ ਬਿਲਕੁਲ ਉਸੇ ਉਦੇਸ਼ਾਂ ਲਈ YAML ਦੀ ਬਜਾਏ ACI ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਲਈ ਐਕਸਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਬੇਸ਼ਕ, ਐਕਸਲ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਫਾਇਦੇ ਹਨ:

• ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਤੁਹਾਡੀ NIP
• ਸੁੰਦਰ ਚਿੰਨ੍ਹ ਜੋ ਗਾਹਕ ਲਈ ਦੇਖਣ ਲਈ ਸੁਹਾਵਣੇ ਹਨ
• ਤੁਸੀਂ ਕੁਝ ਐਕਸਲ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ

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

ACY ਅਸਲ ਵਿੱਚ ਉਹੀ ਪਹੁੰਚਾਂ ਦੀ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਹੈ ਜੋ ਮੈਂ ACI ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਲਈ ਤੀਜੀ ਧਿਰ ਲਈ ਵਰਤੀ ਸੀ।

ਸਰੋਤ: www.habr.com