ਇੱਕ "ਸ਼ੁਰੂਆਤ" ਤੋਂ ਇੱਕ ਦਰਜਨ ਡੇਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ ਹਜ਼ਾਰਾਂ ਸਰਵਰਾਂ ਤੱਕ। ਅਸੀਂ ਕਿਵੇਂ ਲੀਨਕਸ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੇ ਵਿਕਾਸ ਦਾ ਪਿੱਛਾ ਕੀਤਾ

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

ਬੇਸ਼ੱਕ, NSPK ਇੱਕ ਸਟਾਰਟਅੱਪ ਨਹੀਂ ਹੈ, ਪਰ ਇਸਦੀ ਹੋਂਦ ਦੇ ਪਹਿਲੇ ਸਾਲਾਂ ਵਿੱਚ ਕੰਪਨੀ ਵਿੱਚ ਅਜਿਹਾ ਮਾਹੌਲ ਰਾਜ ਕੀਤਾ ਗਿਆ ਸੀ, ਅਤੇ ਉਹ ਸਾਲ ਬਹੁਤ ਦਿਲਚਸਪ ਸਨ। ਮੇਰਾ ਨਾਮ ਹੈ ਕੋਰਨੀਆਕੋਵ ਦਿਮਿਤਰੀ, ਮੈਂ 10 ਸਾਲਾਂ ਤੋਂ ਉੱਚ ਉਪਲਬਧਤਾ ਲੋੜਾਂ ਵਾਲੇ ਲੀਨਕਸ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦਾ ਸਮਰਥਨ ਕਰ ਰਿਹਾ ਹਾਂ। ਉਹ ਜਨਵਰੀ 2016 ਵਿੱਚ NSPK ਟੀਮ ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਇਆ ਅਤੇ, ਬਦਕਿਸਮਤੀ ਨਾਲ, ਕੰਪਨੀ ਦੀ ਹੋਂਦ ਦੀ ਸ਼ੁਰੂਆਤ ਨੂੰ ਨਹੀਂ ਦੇਖਿਆ, ਪਰ ਮਹਾਨ ਤਬਦੀਲੀਆਂ ਦੇ ਪੜਾਅ 'ਤੇ ਆਇਆ।

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

ਯਾਤਰਾ ਦੀ ਸ਼ੁਰੂਆਤ

ਸਾਡੀ ਯਾਤਰਾ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ, ਸਾਡਾ ਤਕਨਾਲੋਜੀ ਸਟੈਕ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ:
OS CentOS 7
FreeIPA ਡੋਮੇਨ ਕੰਟਰੋਲਰ
ਆਟੋਮੇਸ਼ਨ - ਜਵਾਬੀ (+ਟਾਵਰ), ਮੋਚੀ

ਇਹ ਸਭ 3 ਡੋਮੇਨਾਂ ਵਿੱਚ ਸਥਿਤ ਸੀ, ਕਈ ਡਾਟਾ ਸੈਂਟਰਾਂ ਵਿੱਚ ਫੈਲਿਆ ਹੋਇਆ ਸੀ। ਇੱਕ ਡੇਟਾ ਸੈਂਟਰ ਵਿੱਚ ਦਫਤਰੀ ਪ੍ਰਣਾਲੀਆਂ ਅਤੇ ਟੈਸਟ ਸਾਈਟਾਂ ਹਨ, ਬਾਕੀ ਵਿੱਚ PROD ਹੈ।

ਇੱਕ ਬਿੰਦੂ 'ਤੇ ਸਰਵਰ ਬਣਾਉਣਾ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

VM ਟੈਂਪਲੇਟ ਵਿੱਚ, CentOS ਨਿਊਨਤਮ ਹੈ ਅਤੇ ਲੋੜੀਂਦਾ ਘੱਟੋ-ਘੱਟ ਸਹੀ /etc/resolv.conf ਵਾਂਗ ਹੈ, ਬਾਕੀ ਜਵਾਬ Ansible ਰਾਹੀਂ ਆਉਂਦਾ ਹੈ।

CMDB - ਐਕਸਲ।

ਜੇਕਰ ਸਰਵਰ ਭੌਤਿਕ ਹੈ, ਤਾਂ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦੀ ਨਕਲ ਕਰਨ ਦੀ ਬਜਾਏ, ਕੋਬਲਰ ਦੀ ਵਰਤੋਂ ਕਰਕੇ OS ਨੂੰ ਇਸ 'ਤੇ ਸਥਾਪਿਤ ਕੀਤਾ ਗਿਆ ਸੀ - ਟਾਰਗੇਟ ਸਰਵਰ ਦੇ MAC ਐਡਰੈੱਸ ਨੂੰ ਕੋਬਲਰ ਕੌਂਫਿਗ ਵਿੱਚ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਸਰਵਰ ਨੂੰ DHCP ਦੁਆਰਾ ਇੱਕ IP ਪਤਾ ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਓ.ਐਸ. ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ।

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

ਉਸ ਸਮੇਂ, ਸਾਡੇ ਵਿੱਚੋਂ ਬਹੁਤਿਆਂ ਨੇ Ansible ਨੂੰ Bash ਦੇ ਇੱਕ ਸੁਵਿਧਾਜਨਕ ਐਕਸਟੈਂਸ਼ਨ ਵਜੋਂ ਸਮਝਿਆ ਅਤੇ ਸ਼ੈੱਲ ਅਤੇ sed ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਡਿਜ਼ਾਈਨਾਂ ਵਿੱਚ ਕਮੀ ਨਹੀਂ ਕੀਤੀ। ਸਮੁੱਚੇ ਤੌਰ 'ਤੇ Bashsible. ਇਹ ਆਖਰਕਾਰ ਇਸ ਤੱਥ ਵੱਲ ਲੈ ਗਿਆ ਕਿ ਜੇਕਰ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਪਲੇਬੁੱਕ ਸਰਵਰ 'ਤੇ ਕੰਮ ਨਹੀਂ ਕਰਦੀ ਹੈ, ਤਾਂ ਸਰਵਰ ਨੂੰ ਮਿਟਾਉਣਾ, ਪਲੇਬੁੱਕ ਨੂੰ ਠੀਕ ਕਰਨਾ ਅਤੇ ਇਸਨੂੰ ਦੁਬਾਰਾ ਚਲਾਉਣਾ ਆਸਾਨ ਸੀ। ਇੱਥੇ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਸਕ੍ਰਿਪਟਾਂ ਦਾ ਕੋਈ ਸੰਸਕਰਣ ਨਹੀਂ ਸੀ, ਸੰਰਚਨਾ ਦੀ ਕੋਈ ਪੋਰਟੇਬਿਲਟੀ ਨਹੀਂ ਸੀ।

ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ ਸਾਰੇ ਸਰਵਰਾਂ 'ਤੇ ਕੁਝ ਸੰਰਚਨਾ ਨੂੰ ਬਦਲਣਾ ਚਾਹੁੰਦੇ ਸੀ:

1. ਅਸੀਂ ਲਾਜ਼ੀਕਲ ਖੰਡ/ਡਾਟਾ ਕੇਂਦਰ ਵਿੱਚ ਮੌਜੂਦਾ ਸਰਵਰਾਂ 'ਤੇ ਸੰਰਚਨਾ ਨੂੰ ਬਦਲਦੇ ਹਾਂ। ਕਈ ਵਾਰ ਇੱਕ ਦਿਨ ਵਿੱਚ ਨਹੀਂ - ਪਹੁੰਚਯੋਗਤਾ ਲੋੜਾਂ ਅਤੇ ਵੱਡੀ ਗਿਣਤੀ ਦੇ ਕਾਨੂੰਨ ਸਾਰੇ ਬਦਲਾਅ ਇੱਕ ਵਾਰ ਵਿੱਚ ਲਾਗੂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੰਦੇ ਹਨ। ਅਤੇ ਕੁਝ ਬਦਲਾਅ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਵਿਨਾਸ਼ਕਾਰੀ ਹੁੰਦੇ ਹਨ ਅਤੇ ਕੁਝ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ - ਸੇਵਾਵਾਂ ਤੋਂ ਲੈ ਕੇ OS ਤੱਕ।
2. ਜਵਾਬ ਵਿੱਚ ਇਸ ਨੂੰ ਠੀਕ ਕਰਨਾ
3. ਅਸੀਂ ਇਸਨੂੰ ਮੋਚੀ ਵਿੱਚ ਠੀਕ ਕਰਦੇ ਹਾਂ
4. ਹਰੇਕ ਲਾਜ਼ੀਕਲ ਖੰਡ/ਡੇਟਾ ਕੇਂਦਰ ਲਈ N ਵਾਰ ਦੁਹਰਾਓ

ਸਾਰੀਆਂ ਤਬਦੀਲੀਆਂ ਨੂੰ ਸੁਚਾਰੂ ਢੰਗ ਨਾਲ ਚਲਾਉਣ ਲਈ, ਬਹੁਤ ਸਾਰੇ ਕਾਰਕਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਣਾ ਜ਼ਰੂਰੀ ਸੀ, ਅਤੇ ਤਬਦੀਲੀਆਂ ਲਗਾਤਾਰ ਹੁੰਦੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ।

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

ਬੁਨਿਆਦੀ ਢਾਂਚਾ ਵਿਕਾਸ ਅਤੇ ਯਾਤਰਾ ਦੀ ਸ਼ੁਰੂਆਤ

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

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

ਇਹ ਕੁਝ ਸਾਧਨਾਂ ਨੂੰ ਜੋੜਨਾ ਬਾਕੀ ਹੈ.

ਅਸੀਂ GitLab CE ਨੂੰ ਸਾਡੇ ਕੋਡ ਰਿਪੋਜ਼ਟਰੀ ਵਜੋਂ ਚੁਣਿਆ ਹੈ, ਘੱਟੋ ਘੱਟ ਇਸਦੇ ਬਿਲਟ-ਇਨ CI/CD ਮੋਡੀਊਲਾਂ ਲਈ ਨਹੀਂ।

ਭੇਦ ਦੀ ਵਾਲਟ - ਹੈਸ਼ੀਕੋਰਪ ਵਾਲਟ, ਸਮੇਤ। ਮਹਾਨ API ਲਈ.

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

ਸਾਡੀ ਪਸੰਦ:

ਅਣੂ + ਟੈਸਟਿਨਫ੍ਰਾ
ਜਵਾਬਦੇਹ + ਟਾਵਰ + AWX
ਸਰਵਰਾਂ ਦੀ ਦੁਨੀਆ + DITNET (ਆਪਣਾ ਵਿਕਾਸ)
ਮੋਚੀ
Gitlab + GitLab ਦੌੜਾਕ
ਹਾਸ਼ੀਕਾਰਪ ਵਾਲਟ

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

• "ਸੁਨਹਿਰੀ ਚਿੱਤਰ" ਤੋਂ ਸਰਵਰਾਂ ਦੀ ਨਕਲ ਕਰਨਾ ਬੁਰਾਈ ਹੈ!ਮੁੱਖ ਨੁਕਸਾਨ ਇਹ ਹੈ ਕਿ ਤੁਸੀਂ ਬਿਲਕੁਲ ਨਹੀਂ ਜਾਣਦੇ ਕਿ ਚਿੱਤਰ ਹੁਣ ਕਿਸ ਸਥਿਤੀ ਵਿੱਚ ਹਨ, ਅਤੇ ਇਹ ਕਿ ਸਾਰੇ ਬਦਲਾਅ ਸਾਰੇ ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਫਾਰਮਾਂ ਵਿੱਚ ਸਾਰੀਆਂ ਤਸਵੀਰਾਂ ਵਿੱਚ ਆਉਣਗੇ।
• ਡਿਫੌਲਟ ਕੌਂਫਿਗਰੇਸ਼ਨ ਫਾਈਲਾਂ ਦੀ ਘੱਟੋ ਘੱਟ ਵਰਤੋਂ ਕਰੋ ਅਤੇ ਦੂਜੇ ਵਿਭਾਗਾਂ ਨਾਲ ਸਹਿਮਤ ਹੋਵੋ ਕਿ ਤੁਸੀਂ ਮੁੱਖ ਸਿਸਟਮ ਫਾਈਲਾਂ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੋ, ਉਦਾਹਰਨ ਲਈ:
  1. /etc/sysctl.conf ਨੂੰ ਖਾਲੀ ਛੱਡੋ, ਸੈਟਿੰਗਾਂ ਸਿਰਫ /etc/sysctl.d/ ਵਿੱਚ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਤੁਹਾਡਾ ਡਿਫੌਲਟ, ਦੂਜੀ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਕਸਟਮ।
  2. ਸਿਸਟਮਡ ਯੂਨਿਟਾਂ ਨੂੰ ਸੰਪਾਦਿਤ ਕਰਨ ਲਈ ਓਵਰਰਾਈਡ ਫਾਈਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ।
• ਸਾਰੀਆਂ ਸੰਰਚਨਾਵਾਂ ਨੂੰ ਟੈਮਪਲੇਟ ਕਰੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸ਼ਾਮਲ ਕਰੋ; ਜੇ ਸੰਭਵ ਹੋਵੇ, ਪਲੇਬੁੱਕ ਵਿੱਚ ਕੋਈ ਸੈਡ ਜਾਂ ਇਸਦੇ ਐਨਾਲਾਗ ਨਹੀਂ
• ਸੰਰਚਨਾ ਪ੍ਰਬੰਧਨ ਸਿਸਟਮ ਕੋਡ ਨੂੰ ਰੀਫੈਕਟਰ ਕਰਨਾ:
  1. ਕਾਰਜਾਂ ਨੂੰ ਲਾਜ਼ੀਕਲ ਇਕਾਈਆਂ ਵਿੱਚ ਵੰਡੋ ਅਤੇ ਮੋਨੋਲਿਥ ਨੂੰ ਭੂਮਿਕਾਵਾਂ ਵਿੱਚ ਦੁਬਾਰਾ ਲਿਖੋ
  2. ਲਿੰਟਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ! ਉੱਤਰ-ਲਿੰਟ, ਯਾਮਲ-ਲਿੰਟ, ਆਦਿ
  3. ਆਪਣੀ ਪਹੁੰਚ ਬਦਲੋ! ਕੋਈ ਬੇਸ਼ੱਕ ਨਹੀਂ। ਸਿਸਟਮ ਦੀ ਸਥਿਤੀ ਦਾ ਵਰਣਨ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ
• ਸਾਰੀਆਂ ਜਵਾਬਦੇਹ ਭੂਮਿਕਾਵਾਂ ਲਈ ਤੁਹਾਨੂੰ ਅਣੂ ਵਿੱਚ ਟੈਸਟ ਲਿਖਣ ਅਤੇ ਦਿਨ ਵਿੱਚ ਇੱਕ ਵਾਰ ਰਿਪੋਰਟਾਂ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
• ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਟੈਸਟਾਂ ਨੂੰ ਤਿਆਰ ਕਰਨ ਤੋਂ ਬਾਅਦ (ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ 100 ਤੋਂ ਵੱਧ ਹਨ), ਲਗਭਗ 70000 ਗਲਤੀਆਂ ਪਾਈਆਂ ਗਈਆਂ ਸਨ। ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਵਿੱਚ ਕਈ ਮਹੀਨੇ ਲੱਗ ਗਏ।

ਸਾਡੇ ਲਾਗੂ

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

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

ਸਰਵਰ ਬਣਾਉਣ ਲਈ ਵੀ ਬਹੁਤ ਸਾਰੇ ਵਿਕਲਪ ਹਨ. ਅਸੀਂ ਕਸਟਮ ਪਾਈਥਨ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਚੁਣਨਾ ਸਮਾਪਤ ਕੀਤਾ। ਅਤੇ CI ਜਵਾਬਦੇਹ ਲਈ:

- name: create1.yml - Create a VM from a template
  vmware_guest:
    hostname: "{{datacenter}}".domain.ru
    username: "{{ username_vc }}"
    password: "{{ password_vc }}"
    validate_certs: no
    cluster: "{{cluster}}"
    datacenter: "{{datacenter}}"
    name: "{{ name }}"
    state: poweredon
    folder: "/{{folder}}"
    template: "{{template}}"
    customization:
      hostname: "{{ name }}"
      domain: domain.ru
      dns_servers:
        - "{{ ipa1_dns }}"
        - "{{ ipa2_dns }}"
    networks:
      - name: "{{ network }}"
        type: static
        ip: "{{ip}}"
        netmask: "{{netmask}}"
        gateway: "{{gateway}}"
        wake_on_lan: True
        start_connected: True
        allow_guest_control: True
    wait_for_ip_address: yes
    disk:
      - size_gb: 1
        type: thin
        datastore: "{{datastore}}"
      - size_gb: 20
        type: thin
        datastore: "{{datastore}}"

ਇਹ ਉਹ ਹੈ ਜੋ ਅਸੀਂ ਆਏ ਹਾਂ, ਸਿਸਟਮ ਜਿਉਂਦਾ ਹੈ ਅਤੇ ਵਿਕਾਸ ਕਰਦਾ ਹੈ.

• ਸਰਵਰ ਸਥਾਪਤ ਕਰਨ ਲਈ 17 ਜਵਾਬਦੇਹ ਭੂਮਿਕਾਵਾਂ। ਹਰ ਰੋਲ ਨੂੰ ਇੱਕ ਵੱਖਰੇ ਲਾਜ਼ੀਕਲ ਕੰਮ (ਲੌਗਿੰਗ, ਆਡਿਟਿੰਗ, ਉਪਭੋਗਤਾ ਅਧਿਕਾਰ, ਨਿਗਰਾਨੀ, ਆਦਿ) ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ।
• ਰੋਲ ਟੈਸਟਿੰਗ. ਅਣੂ + ਟੈਸਟਇਨਫਰਾ.
• ਆਪਣਾ ਵਿਕਾਸ: CMDB + ਆਰਕੈਸਟਰੇਟਰ।
• ਸਰਵਰ ਬਣਾਉਣ ਦਾ ਸਮਾਂ ~30 ਮਿੰਟ ਹੈ, ਸਵੈਚਲਿਤ ਅਤੇ ਕਾਰਜ ਕਤਾਰ ਤੋਂ ਅਮਲੀ ਤੌਰ 'ਤੇ ਸੁਤੰਤਰ।
• ਸਾਰੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਇੱਕੋ ਸਥਿਤੀ/ਨਾਮਕਰਨ - ਪਲੇਬੁੱਕ, ਰਿਪੋਜ਼ਟਰੀਆਂ, ਵਰਚੁਅਲਾਈਜੇਸ਼ਨ ਤੱਤ।
• ਸਟੈਂਡਰਡ ਦੇ ਨਾਲ ਅੰਤਰਾਂ 'ਤੇ ਰਿਪੋਰਟਾਂ ਦੇ ਉਤਪਾਦਨ ਦੇ ਨਾਲ ਸਰਵਰ ਸਥਿਤੀ ਦੀ ਰੋਜ਼ਾਨਾ ਜਾਂਚ।

ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਮੇਰੀ ਕਹਾਣੀ ਉਹਨਾਂ ਲਈ ਉਪਯੋਗੀ ਹੋਵੇਗੀ ਜੋ ਆਪਣੀ ਯਾਤਰਾ ਦੀ ਸ਼ੁਰੂਆਤ ਵਿੱਚ ਹਨ. ਤੁਸੀਂ ਕਿਹੜਾ ਆਟੋਮੇਸ਼ਨ ਸਟੈਕ ਵਰਤਦੇ ਹੋ?

ਸਰੋਤ: www.habr.com