ਇਨਸਾਈਡ ਪਲੇਬੁੱਕ। ਨਵੇਂ Ansible ਇੰਜਣ 2.9 ਵਿੱਚ ਨੈੱਟਵਰਕਿੰਗ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ

Red Hat Ansible Engine 2.9 ਦੀ ਆਗਾਮੀ ਰੀਲੀਜ਼ ਦਿਲਚਸਪ ਸੁਧਾਰ ਲਿਆਉਂਦੀ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੁਝ ਦੀ ਚਰਚਾ ਇਸ ਲੇਖ ਵਿੱਚ ਕੀਤੀ ਗਈ ਹੈ। ਹਮੇਸ਼ਾ ਵਾਂਗ, ਅਸੀਂ ਭਾਈਚਾਰਕ ਸਹਾਇਤਾ ਨਾਲ, ਖੁੱਲ੍ਹੇ ਤੌਰ 'ਤੇ ਜਵਾਬਦੇਹ ਨੈੱਟਵਰਕ ਸੁਧਾਰਾਂ ਦਾ ਵਿਕਾਸ ਕਰ ਰਹੇ ਹਾਂ। ਸਾਡੇ ਨਾਲ ਜੁੜੋ - 'ਤੇ ਇੱਕ ਨਜ਼ਰ ਮਾਰੋ GitHub 'ਤੇ ਜਾਰੀ ਬੋਰਡ ਅਤੇ ਲਈ ਵਿਕਾਸ ਯੋਜਨਾ ਦਾ ਅਧਿਐਨ ਕਰੋ Red Hat Ansible ਇੰਜਣ ਦੀ ਰੀਲਿਜ਼ 2.9 ਲਈ ਵਿਕੀ ਪੰਨੇ 'ਤੇ ਜਵਾਬਦੇਹ ਨੈੱਟਵਰਕ.

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

• Arista EOS
• ਸਿਸਕੋ ਆਈ.ਓ.ਐਸ
• ਸਿਸਕੋ ਆਈਓਐਸ ਐਕਸਆਰ
• Cisco NX-OS
• ਜੂਨੀਪਰ ਜੂਨੋਸ
• VyOS

ਪਲੇਟਫਾਰਮਾਂ ਦੀ ਪੂਰੀ ਸੂਚੀ ਲਈ ਜੋ Red Hat ਦੁਆਰਾ ਜਵਾਬਦੇਹ ਆਟੋਮੇਸ਼ਨ ਸਦੱਸਤਾ ਦੁਆਰਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਹਿਯੋਗੀ ਹਨ, ਇੱਥੇ ਪ੍ਰਕਾਸ਼ਿਤ.

ਅਸੀਂ ਕੀ ਸਿੱਖਿਆ ਹੈ

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

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

ਜਦੋਂ ਅਸੀਂ ਇੱਕ ਸਾਲ ਪਹਿਲਾਂ ਆਪਣੀਆਂ ਲੰਬੀ-ਅਵਧੀ ਦੀਆਂ ਵਿਕਾਸ ਯੋਜਨਾਵਾਂ 'ਤੇ ਚਰਚਾ ਕੀਤੀ ਸੀ, ਤਾਂ ਸਾਡੇ ਕਾਰਪੋਰੇਟ ਗਾਹਕਾਂ ਨੇ ਹੇਠਾਂ ਦਿੱਤੇ ਲਈ ਕਿਹਾ:

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

ਤੱਥ ਸੁਧਾਰ

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

ਤੁਸੀਂ ਸਾਨੂੰ ਜਵਾਬਦੇਹ ਨੈੱਟਵਰਕ ਇੰਜਣ ਦੀ ਭੂਮਿਕਾ 'ਤੇ ਕੰਮ ਕਰਦੇ ਦੇਖਿਆ ਹੋਵੇਗਾ। ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ, 24K ਡਾਉਨਲੋਡਸ ਬਾਅਦ ਵਿੱਚ, ਨੈੱਟਵਰਕ ਇੰਜਣ ਦੀ ਭੂਮਿਕਾ ਤੇਜ਼ੀ ਨਾਲ ਨੈੱਟਵਰਕ ਆਟੋਮੇਸ਼ਨ ਦ੍ਰਿਸ਼ਾਂ ਲਈ Ansible Galaxy ਵਿੱਚ ਸਭ ਤੋਂ ਪ੍ਰਸਿੱਧ Ansible ਭੂਮਿਕਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਬਣ ਗਈ ਹੈ। ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਅਸੀਂ ਜਵਾਬ 2.8 ਵਿੱਚ ਕੀ ਲੋੜ ਪਵੇਗੀ, ਇਸਦੀ ਤਿਆਰੀ ਕਰਨ ਲਈ ਜਵਾਬਦੇਹ 2.9 ਵਿੱਚ ਇਸ ਵਿੱਚੋਂ ਬਹੁਤ ਕੁਝ ਤਬਦੀਲ ਕਰਦੇ, ਇਸ ਜਵਾਬਦੇਹੀ ਭੂਮਿਕਾ ਨੇ ਕਮਾਂਡਾਂ ਨੂੰ ਪਾਰਸ ਕਰਨ, ਕਮਾਂਡਾਂ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ, ਅਤੇ ਨੈੱਟਵਰਕ ਡਿਵਾਈਸਾਂ ਲਈ ਡਾਟਾ ਇਕੱਠਾ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਨ ਲਈ ਟੂਲਾਂ ਦਾ ਪਹਿਲਾ ਸੈੱਟ ਪ੍ਰਦਾਨ ਕੀਤਾ।

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

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

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

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

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

ਤੱਥ ਇਕੱਠੇ ਕਰਦੇ ਸਮੇਂ:

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

- hosts: arista
  module_defaults:
    eos_facts:
      gather_subset: min
      gather_network_resources:
      - interfaces
  gather_facts: True

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

ਸਿੱਧੇ ਨੈੱਟਵਰਕ ਤੱਥ ਮੋਡੀਊਲ ਦੀ ਵਰਤੋਂ ਕਰਨਾ:

- name: collect interface configuration facts
  eos_facts:
    gather_subset: min
    gather_network_resources:
    - interfaces

ਪਲੇਬੁੱਕ ਇੰਟਰਫੇਸ ਬਾਰੇ ਹੇਠਾਂ ਦਿੱਤੇ ਤੱਥ ਵਾਪਸ ਕਰਦੀ ਹੈ:

ansible_facts:
   ansible_network_resources:
      interfaces:
      - enabled: true
        name: Ethernet1
        mtu: '1476'
      - enabled: true
        name: Loopback0
      - enabled: true
        name: Loopback1
      - enabled: true
        mtu: '1476'
        name: Tunnel0
      - enabled: true
        name: Ethernet1
      - enabled: true
        name: Tunnel1
      - enabled: true
        name: Ethernet1

ਧਿਆਨ ਦਿਓ ਕਿ ਕਿਵੇਂ Ansible Arista ਡਿਵਾਈਸ ਤੋਂ ਨੇਟਿਵ ਕੌਂਫਿਗਰੇਸ਼ਨ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਡਾਊਨਸਟ੍ਰੀਮ ਕਾਰਜਾਂ ਅਤੇ ਓਪਰੇਸ਼ਨਾਂ ਲਈ ਸਟੈਂਡਰਡ ਕੀ-ਵੈਲਯੂ ਜੋੜਿਆਂ ਵਜੋਂ ਵਰਤਣ ਲਈ ਇਸਨੂੰ ਢਾਂਚਾਗਤ ਡੇਟਾ ਵਿੱਚ ਬਦਲਦਾ ਹੈ।

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

ਸਰੋਤ ਮੋਡੀਊਲ

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

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

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

- name: example of facts being pushed right back to device.
  hosts: arista
  gather_facts: false
  tasks:
  - name: grab arista eos facts
    eos_facts:
      gather_subset: min
      gather_network_resources: l3_interfaces

  - name: ensure that the IP address information is accurate
    eos_l3_interfaces:
      config: "{{ ansible_network_resources['l3_interfaces'] }}"
      register: result

  - name: ensure config did not change
    assert:
      that: not result.changed

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

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

ਨਵੇਂ ਸਰੋਤ ਮੋਡੀਊਲ ਪਿਛਲੇ ਲੋਕਾਂ ਨਾਲੋਂ ਕਿਵੇਂ ਵੱਖਰੇ ਹਨ?

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

1) ਦਿੱਤੇ ਗਏ ਨੈੱਟਵਰਕ ਸਰੋਤ ਲਈ (ਜਿਸ ਨੂੰ ਸੰਰਚਨਾ ਭਾਗ ਵਜੋਂ ਵੀ ਸੋਚਿਆ ਜਾ ਸਕਦਾ ਹੈ), ਮੋਡਿਊਲ ਅਤੇ ਤੱਥ ਇੱਕੋ ਸਮੇਂ ਸਾਰੇ ਸਮਰਥਿਤ ਨੈੱਟਵਰਕ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ ਵਿੱਚ ਵਿਕਸਤ ਹੋਣਗੇ। ਅਸੀਂ ਸੋਚਦੇ ਹਾਂ ਕਿ ਜੇਕਰ Ansible ਇੱਕ ਨੈੱਟਵਰਕ ਪਲੇਟਫਾਰਮ 'ਤੇ ਸਰੋਤ ਸੰਰਚਨਾ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਤਾਂ ਸਾਨੂੰ ਹਰ ਜਗ੍ਹਾ ਇਸਦਾ ਸਮਰਥਨ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਸਰੋਤ ਮੌਡਿਊਲਾਂ ਦੀ ਵਰਤੋਂ ਨੂੰ ਸਰਲ ਬਣਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇੱਕ ਨੈੱਟਵਰਕ ਆਟੋਮੇਸ਼ਨ ਇੰਜੀਨੀਅਰ ਹੁਣ ਮੂਲ ਅਤੇ ਸਮਰਥਿਤ ਮੋਡੀਊਲਾਂ ਵਾਲੇ ਸਾਰੇ ਨੈੱਟਵਰਕ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ 'ਤੇ ਇੱਕ ਸਰੋਤ (ਜਿਵੇਂ ਕਿ LLDP) ਨੂੰ ਕੌਂਫਿਗਰ ਕਰ ਸਕਦਾ ਹੈ।

2) ਸਰੋਤ ਮੋਡੀਊਲ ਵਿੱਚ ਹੁਣ ਇੱਕ ਰਾਜ ਮੁੱਲ ਸ਼ਾਮਲ ਹੈ।

• merged: ਸੰਰਚਨਾ ਨੂੰ ਪ੍ਰਦਾਨ ਕੀਤੀ ਸੰਰਚਨਾ (ਡਿਫਾਲਟ) ਨਾਲ ਮਿਲਾਇਆ ਜਾਂਦਾ ਹੈ;
• replaced: ਸਰੋਤ ਸੰਰਚਨਾ ਨੂੰ ਪ੍ਰਦਾਨ ਕੀਤੀ ਸੰਰਚਨਾ ਨਾਲ ਬਦਲਿਆ ਜਾਵੇਗਾ;
• overridden: ਸਰੋਤ ਸੰਰਚਨਾ ਨੂੰ ਪ੍ਰਦਾਨ ਕੀਤੀ ਸੰਰਚਨਾ ਨਾਲ ਬਦਲਿਆ ਜਾਵੇਗਾ; ਬੇਲੋੜੇ ਸਰੋਤ ਉਦਾਹਰਨਾਂ ਨੂੰ ਮਿਟਾ ਦਿੱਤਾ ਜਾਵੇਗਾ;
• deleted: ਸਰੋਤ ਸੰਰਚਨਾ ਨੂੰ ਡਿਫੌਲਟ 'ਤੇ ਮਿਟਾ ਦਿੱਤਾ/ਬਹਾਲ ਕੀਤਾ ਜਾਵੇਗਾ।

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

• before: ਕਾਰਜ ਤੋਂ ਪਹਿਲਾਂ ਢਾਂਚਾਗਤ ਡੇਟਾ ਦੇ ਰੂਪ ਵਿੱਚ ਡਿਵਾਈਸ ਤੇ ਸੰਰਚਨਾ;
• after: ਜੇਕਰ ਡਿਵਾਈਸ ਬਦਲ ਗਈ ਹੈ (ਜਾਂ ਜੇਕਰ ਟੈਸਟ ਮੋਡ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਤਾਂ ਬਦਲ ਸਕਦਾ ਹੈ), ਨਤੀਜੇ ਵਜੋਂ ਸੰਰਚਨਾ ਨੂੰ ਢਾਂਚਾਗਤ ਡੇਟਾ ਦੇ ਰੂਪ ਵਿੱਚ ਵਾਪਸ ਕਰ ਦਿੱਤਾ ਜਾਵੇਗਾ;
• commands: ਕੋਈ ਵੀ ਸੰਰਚਨਾ ਕਮਾਂਡ ਇਸ ਨੂੰ ਲੋੜੀਂਦੀ ਸਥਿਤੀ ਵਿੱਚ ਲਿਆਉਣ ਲਈ ਡਿਵਾਈਸ 'ਤੇ ਚੱਲਦੀ ਹੈ।

ਇਸ ਸਭ ਦਾ ਕੀ ਮਤਲਬ ਹੈ? ਇਹ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ?

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

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

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

Ansible Engine 2.9 ਵਿੱਚ ਕਿਹੜੇ ਸਰੋਤ ਮਾਡਿਊਲ ਆਉਣਗੇ?

ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਅਸੀਂ ਤੁਹਾਨੂੰ ਵਿਸਥਾਰ ਵਿੱਚ ਦੱਸੀਏ ਕਿ ਜਵਾਬ 2.9 ਵਿੱਚ ਕੀ ਹੋਵੇਗਾ, ਆਓ ਯਾਦ ਕਰੀਏ ਕਿ ਅਸੀਂ ਕੰਮ ਦੇ ਪੂਰੇ ਦਾਇਰੇ ਨੂੰ ਕਿਵੇਂ ਵੰਡਿਆ ਹੈ।

ਅਸੀਂ 7 ਸ਼੍ਰੇਣੀਆਂ ਦੀ ਪਛਾਣ ਕੀਤੀ ਹੈ ਅਤੇ ਹਰੇਕ ਨੂੰ ਖਾਸ ਨੈੱਟਵਰਕ ਸਰੋਤ ਨਿਰਧਾਰਤ ਕੀਤੇ ਹਨ:

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

ਹੇਠਾਂ ਦਿੱਤੇ ਮੋਡੀਊਲ ਜਵਾਬਦੇਹ ਭਾਈਚਾਰੇ ਦੁਆਰਾ ਵਿਕਸਤ ਕੀਤੇ ਗਏ ਹਨ:

• exos_lldp_global - ਐਕਸਟ੍ਰੀਮ ਨੈਟਵਰਕਸ ਤੋਂ।
• nxos_bfd_interfaces - ਸਿਸਕੋ ਤੋਂ
• nxos_telemetry - ਸਿਸਕੋ ਤੋਂ

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

ਜਵਾਬਦੇਹ 2.10 ਅਤੇ ਇਸ ਤੋਂ ਬਾਅਦ ਦੀਆਂ ਯੋਜਨਾਵਾਂ

ਇੱਕ ਵਾਰ Ansible 2.9 ਜਾਰੀ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਅਸੀਂ Ansible 2.10 ਲਈ ਸਰੋਤ ਮਾਡਿਊਲਾਂ ਦੇ ਅਗਲੇ ਸੈੱਟ 'ਤੇ ਕੰਮ ਕਰਾਂਗੇ, ਜਿਸਦੀ ਵਰਤੋਂ ਨੈੱਟਵਰਕ ਟੋਪੋਲੋਜੀ ਅਤੇ ਨੀਤੀ ਨੂੰ ਹੋਰ ਸੰਰਚਿਤ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ। ACL, OSPF ਅਤੇ BGP. ਵਿਕਾਸ ਯੋਜਨਾ ਨੂੰ ਅਜੇ ਵੀ ਐਡਜਸਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਜੇਕਰ ਤੁਹਾਡੀ ਕੋਈ ਟਿੱਪਣੀ ਹੈ, ਤਾਂ ਕਿਰਪਾ ਕਰਕੇ ਇਸਦੀ ਰਿਪੋਰਟ ਕਰੋ ਜਵਾਬਦੇਹ ਨੈੱਟਵਰਕ ਕਮਿਊਨਿਟੀ.

ਸਰੋਤ ਅਤੇ ਸ਼ੁਰੂਆਤ ਕਰਨਾ

ਜਵਾਬਦੇਹ ਆਟੋਮੇਸ਼ਨ ਪਲੇਟਫਾਰਮ ਬਾਰੇ ਪ੍ਰੈਸ ਰਿਲੀਜ਼
ਜਵਾਬਦੇਹ ਆਟੋਮੇਸ਼ਨ ਪਲੇਟਫਾਰਮ ਬਲੌਗ
ਜਵਾਬ ਵਿੱਚ ਸਮੱਗਰੀ ਡਿਲੀਵਰੀ ਦਾ ਭਵਿੱਖ
ਜਵਾਬਦੇਹ ਪ੍ਰੋਜੈਕਟ ਢਾਂਚੇ ਨੂੰ ਬਦਲਣ 'ਤੇ ਪ੍ਰਤੀਬਿੰਬ

ਸਰੋਤ: www.habr.com