ਕਲਾਉਡ ਸੇਵਾ ਦੀ ਸਿਰਜਣਾ ਦਾ ਇਤਿਹਾਸ, ਸਾਈਬਰਪੰਕ ਨਾਲ ਸੁਆਦਲਾ

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

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

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

ਬਿੱਲੀ ਵਿੱਚ ਤੁਹਾਡਾ ਸੁਆਗਤ ਹੈ।

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

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

ਕਈ ਲੋੜਾਂ ਵੀ ਸਨ:

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

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

• Python + Flask + Swagger + SQLAlchemy - ਇੱਕ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮਿਆਰੀ ਪਾਈਥਨ ਸੈੱਟ;
• ਫਰੰਟਐਂਡ ਲਈ Vue.js;
• ਅਸੀਂ AMQP ਉੱਤੇ ਸੈਲਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਕੰਪੋਨੈਂਟਸ ਅਤੇ ਸੇਵਾਵਾਂ ਵਿਚਕਾਰ ਆਪਸੀ ਤਾਲਮੇਲ ਕਰਨ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ।

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

ਇਸ ਲਈ, ਆਓ ਆਪਣੀ ਜਾਣ-ਪਛਾਣ ਸ਼ੁਰੂ ਕਰੀਏ.

ਚੁੱਪ ਬਿੱਲ - ਬਿਲਿੰਗ

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

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

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

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

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

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

ਇਕ ਹੋਰ ਸਮੱਸਿਆ ਚੁੱਪ ਹੈ.

ਬਿਲੀ ਚੁੱਪਚਾਪ ਕੁਝ API ਬੇਨਤੀਆਂ ਦਾ ਜਵਾਬ "ਠੀਕ ਹੈ" ਦਿੰਦਾ ਹੈ। ਇਹ ਮਾਮਲਾ ਸੀ, ਉਦਾਹਰਨ ਲਈ, ਜਦੋਂ ਅਸੀਂ ਟੈਸਟ ਦੌਰਾਨ ਵਾਅਦਾ ਕੀਤੇ ਭੁਗਤਾਨਾਂ ਦੇ ਭੁਗਤਾਨ ਕੀਤੇ (ਇਸ ਬਾਰੇ ਹੋਰ ਬਾਅਦ ਵਿੱਚ)। ਬੇਨਤੀਆਂ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਸਾਨੂੰ ਕੋਈ ਗਲਤੀ ਨਹੀਂ ਦਿਖਾਈ ਦਿੱਤੀ।

ਮੈਨੂੰ UI ਦੁਆਰਾ ਸਿਸਟਮ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਲੌਗਸ ਦਾ ਅਧਿਐਨ ਕਰਨਾ ਪਿਆ। ਇਹ ਪਤਾ ਚਲਿਆ ਕਿ ਬਿਲਿੰਗ ਖੁਦ ਸਮਾਨ ਬੇਨਤੀਆਂ ਕਰਦੀ ਹੈ, ਕਿਸੇ ਖਾਸ ਉਪਭੋਗਤਾ ਲਈ ਸਕੋਪ ਨੂੰ ਬਦਲਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਐਡਮਿਨ, ਇਸਨੂੰ su ਪੈਰਾਮੀਟਰ ਵਿੱਚ ਪਾਸ ਕਰਨਾ.

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

ਇਸ ਲਈ, ਸੰਖੇਪ ਕਰਨ ਲਈ, ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਦੇ ਪੜਾਅ 'ਤੇ ਸਾਨੂੰ ਆਈਆਂ ਮੁੱਖ ਸਮੱਸਿਆਵਾਂ ਇੱਕ ਖਾਸ ਪ੍ਰਣਾਲੀ ਦੇ ਲਾਗੂ ਕਰਨ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨਾਲ ਸਬੰਧਤ ਹਨ:

• ਗੈਰ-ਦਸਤਾਵੇਜ਼ੀ "ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ" ਜੋ ਸਾਨੂੰ ਕਿਸੇ ਨਾ ਕਿਸੇ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀਆਂ ਹਨ;
• ਬੰਦ ਸਰੋਤ (ਬਿਲਿੰਗ ਨੂੰ C++ ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ), ਨਤੀਜੇ ਵਜੋਂ - "ਅਜ਼ਮਾਇਸ਼ ਅਤੇ ਗਲਤੀ" ਤੋਂ ਇਲਾਵਾ ਕਿਸੇ ਹੋਰ ਤਰੀਕੇ ਨਾਲ ਸਮੱਸਿਆ 1 ਨੂੰ ਹੱਲ ਕਰਨਾ ਅਸੰਭਵ ਹੈ।

ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਉਤਪਾਦ ਵਿੱਚ ਕਾਫ਼ੀ ਵਿਆਪਕ API ਹੈ ਅਤੇ ਅਸੀਂ ਆਪਣੇ ਨਿੱਜੀ ਖਾਤੇ ਵਿੱਚ ਹੇਠਾਂ ਦਿੱਤੇ ਉਪ-ਪ੍ਰਣਾਲੀਆਂ ਨੂੰ ਏਕੀਕ੍ਰਿਤ ਕੀਤਾ ਹੈ:

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

ਟੰਗਸਟਨ ਖੇਤਾਂ ਵਿੱਚੋਂ ਲੰਘਣਾ - ਟੰਗਸਟਨ ਫੈਬਰਿਕ

ਟੰਗਸਟਨ ਫੀਲਡ ਸੈਂਕੜੇ ਤਾਰਾਂ ਨਾਲ ਬਿੰਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਦੁਆਰਾ ਹਜ਼ਾਰਾਂ ਬਿੱਟ ਜਾਣਕਾਰੀ ਪਾਸ ਕਰਦੇ ਹਨ। ਜਾਣਕਾਰੀ ਨੂੰ "ਪੈਕੇਟਾਂ" ਵਿੱਚ ਇਕੱਠਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪਾਰਸ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਗੁੰਝਲਦਾਰ ਰੂਟਾਂ ਦਾ ਨਿਰਮਾਣ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ ਜਾਦੂ ਦੁਆਰਾ।

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

ਸਿਸਟਮ ਨੂੰ ਓਪਨਸਟੈਕ (ਹੇਠਾਂ ਚਰਚਾ ਕੀਤੀ ਗਈ) ਨਾਲ ਨਿਊਟ੍ਰੌਨ ਪਲੱਗਇਨ ਰਾਹੀਂ ਏਕੀਕ੍ਰਿਤ ਕੀਤਾ ਗਿਆ ਹੈ।

ਓਪਨਸਟੈਕ ਸੇਵਾਵਾਂ ਦਾ ਪਰਸਪਰ ਪ੍ਰਭਾਵ।

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

ਪਹਿਲਾਂ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਸੀ: ਕਮਾਂਡਾਂ ਜਿਹਨਾਂ ਨੂੰ SSH ਦੁਆਰਾ ਕਨੈਕਟ ਕਰਨ ਵੇਲੇ ਇੰਸਟੈਂਸ ਕੰਸੋਲ ਵਿੱਚ ਵੱਡੀ ਮਾਤਰਾ ਵਿੱਚ ਡੇਟਾ ਆਉਟਪੁੱਟ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜਦੋਂ ਕਿ VNC ਦੁਆਰਾ ਸਭ ਕੁਝ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦਾ ਸੀ।

ਉਹਨਾਂ ਲਈ ਜੋ ਸਮੱਸਿਆ ਤੋਂ ਜਾਣੂ ਨਹੀਂ ਹਨ, ਇਹ ਕਾਫ਼ੀ ਮਜ਼ਾਕੀਆ ਲੱਗਦਾ ਹੈ: ls /root ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਦੋਂ ਕਿ, ਉਦਾਹਰਨ ਲਈ, ਚੋਟੀ ਦੇ "ਫ੍ਰੀਜ਼" ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ. ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਸਾਨੂੰ ਪਹਿਲਾਂ ਵੀ ਅਜਿਹੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ ਹੈ। ਇਹ ਕੰਪਿਊਟ ਨੋਡਸ ਤੋਂ ਰਾਊਟਰਾਂ ਤੱਕ ਦੇ ਰੂਟ 'ਤੇ MTU ਨੂੰ ਟਿਊਨ ਕਰਕੇ ਫੈਸਲਾ ਕੀਤਾ ਗਿਆ ਸੀ। ਤਰੀਕੇ ਨਾਲ, ਇਹ ਕੋਈ TF ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ।

ਅਗਲੀ ਸਮੱਸਿਆ ਬਿਲਕੁਲ ਕੋਨੇ ਦੇ ਦੁਆਲੇ ਸੀ. ਇੱਕ "ਸੁੰਦਰ" ਪਲ ਵਿੱਚ, ਰੂਟਿੰਗ ਦਾ ਜਾਦੂ ਅਲੋਪ ਹੋ ਗਿਆ, ਬਿਲਕੁਲ ਉਸੇ ਤਰ੍ਹਾਂ. TF ਨੇ ਸਾਜ਼-ਸਾਮਾਨ 'ਤੇ ਰੂਟਿੰਗ ਦਾ ਪ੍ਰਬੰਧਨ ਬੰਦ ਕਰ ਦਿੱਤਾ ਹੈ.

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

ਸਿਲੀਕਾਨ ਲਾਈਫਫਾਰਮਸ - ਓਪਨਸਟੈਕ

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

ਓਪਨਸਟੈਕ ਸਾਡੇ ਪਲੇਟਫਾਰਮ ਦਾ ਧੁਰਾ ਹੈ।

ਓਪਨਸਟੈਕ ਦੇ ਕਈ ਉਪ-ਸਿਸਟਮ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਅਸੀਂ ਵਰਤਮਾਨ ਵਿੱਚ ਨੋਵਾ, ਗਲੇਂਸ ਅਤੇ ਸਿੰਡਰ ਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਸਰਗਰਮੀ ਨਾਲ ਵਰਤਦੇ ਹਾਂ। ਉਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਦਾ ਆਪਣਾ API ਹੈ। ਨੋਵਾ ਗਣਨਾ ਸਰੋਤਾਂ ਅਤੇ ਉਦਾਹਰਣਾਂ ਦੀ ਸਿਰਜਣਾ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ, Cinder ਵਾਲੀਅਮ ਅਤੇ ਉਹਨਾਂ ਦੇ ਸਨੈਪਸ਼ਾਟ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ, Glance ਇੱਕ ਚਿੱਤਰ ਸੇਵਾ ਹੈ ਜੋ OS ਟੈਂਪਲੇਟਾਂ ਅਤੇ ਉਹਨਾਂ 'ਤੇ ਮੇਟੇਨਫਾਰਮੇਸ਼ਨ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦੀ ਹੈ।

ਹਰੇਕ ਸੇਵਾ ਇੱਕ ਕੰਟੇਨਰ ਵਿੱਚ ਚਲਦੀ ਹੈ, ਅਤੇ ਸੁਨੇਹਾ ਦਲਾਲ "ਚਿੱਟਾ ਖਰਗੋਸ਼" ਹੈ - RabbitMQ।

ਇਸ ਪ੍ਰਣਾਲੀ ਨੇ ਸਾਨੂੰ ਸਭ ਤੋਂ ਅਚਾਨਕ ਮੁਸੀਬਤ ਦਿੱਤੀ।

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

ਅਸੀਂ ਇੱਕ ਚੱਕਰ ਲਗਾਉਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਅਤੇ Nova API ਤੋਂ ਉਹੀ ਕਾਰਵਾਈ ਦੀ ਬੇਨਤੀ ਕੀਤੀ। ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਡਿਵਾਈਸ ਸਹੀ ਢੰਗ ਨਾਲ ਜੁੜਦੀ ਹੈ ਅਤੇ ਸਰਵਰ ਦੇ ਅੰਦਰ ਪਹੁੰਚਯੋਗ ਹੈ। ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਸਮੱਸਿਆ ਉਦੋਂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਬਲਾਕ-ਸਟੋਰੇਜ ਸਿੰਡਰ ਨੂੰ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦੀ।

ਡਿਸਕਾਂ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ ਇੱਕ ਹੋਰ ਮੁਸ਼ਕਲ ਸਾਡੀ ਉਡੀਕ ਕਰ ਰਹੀ ਸੀ. ਸਿਸਟਮ ਵਾਲੀਅਮ ਨੂੰ ਸਰਵਰ ਤੋਂ ਡਿਸਕਨੈਕਟ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

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

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

ਓਪਨਸਟੈਕ ਸਿਸਟਮਾਂ ਦਾ ਇੱਕ ਬਹੁਤ ਹੀ ਗੁੰਝਲਦਾਰ ਸਮੂਹ ਹੈ ਜਿਸਦੇ ਆਪਣੇ ਇੰਟਰਐਕਸ਼ਨ ਤਰਕ ਅਤੇ ਅਲੰਕਾਰਿਤ API ਹਨ। ਸਾਨੂੰ ਕਾਫ਼ੀ ਵਿਸਤ੍ਰਿਤ ਦਸਤਾਵੇਜ਼ਾਂ ਅਤੇ, ਬੇਸ਼ਕ, ਅਜ਼ਮਾਇਸ਼ ਅਤੇ ਗਲਤੀ (ਅਸੀਂ ਇਸ ਤੋਂ ਬਿਨਾਂ ਕਿੱਥੇ ਹੋਵਾਂਗੇ) ਦੁਆਰਾ ਮਦਦ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਟੈਸਟ ਰਨ

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

ਟੈਸਟ ਆਪਣੇ ਆਪ ਵਿੱਚ, ਬੇਸ਼ਕ, ਇਸਦੇ ਮਜ਼ਾਕੀਆ ਪਲਾਂ ਤੋਂ ਬਿਨਾਂ ਨਹੀਂ ਸੀ, ਕਿਉਂਕਿ ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਸਾਡੇ ਸਾਹਸ ਦੀ ਸ਼ੁਰੂਆਤ ਹੋ ਰਹੀ ਹੈ.

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

ਇੱਕ ਹੋਰ ਉਤਸੁਕਤਾ ਤੁਹਾਡੇ ਨਿੱਜੀ ਖਾਤੇ ਵਿੱਚ "ਪਾਸਵਰਡ ਬਦਲੋ" ਬਟਨ ਦੀ ਕਾਰਜਸ਼ੀਲਤਾ ਨਾਲ ਸਬੰਧਤ ਹੈ।

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

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

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

ਨੂੰ ਜਾਰੀ ਰੱਖਿਆ ਜਾਵੇਗਾ

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

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

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

ਅਸੀਂ ਹਾਲ ਹੀ ਵਿੱਚ ਸੇਵਾ ਸ਼ੁਰੂ ਕੀਤੀ ਹੈ।
ਤੁਸੀਂ ਸਾਡੇ 'ਤੇ ਸਾਰੇ ਵੇਰਵੇ ਲੱਭ ਸਕਦੇ ਹੋ ਸਾਈਟ.

CLO ਵਿਕਾਸ ਟੀਮ

ਉਪਯੋਗੀ ਲਿੰਕ

ਓਪਨਸਟੈਕ

• https://docs.openstack.org/nova/latest/
• https://docs.openstack.org/keystone/latest/
• https://docs.openstack.org/cinder/latest/
• https://docs.openstack.org/glance/latest/

ਟੰਗਸਟਨ ਫੈਬਰਿਕ

• http://docs.tungsten.io/en/latest/user/getting-started/index.html
• https://www.juniper.net/documentation/en_US/contrail-cloud10.0/topics/concept/contrail-cloud-openstack-integration-overview.html

ਸਰੋਤ: www.habr.com