ਡੌਕਰ ਅਤੇ ਗਿਟਲਬ ਸੀਆਈ ਦੇ ਨਾਲ ਵਿਕਾਸ ਅਤੇ ਜਾਂਚ ਪ੍ਰਕਿਰਿਆ

ਮੈਂ ਸੁਝਾਅ ਦਿੰਦਾ ਹਾਂ ਕਿ ਤੁਸੀਂ ਇਨਵੈਂਟੋਸ ਤੋਂ ਅਲੈਗਜ਼ੈਂਡਰ ਸਿਗਾਚੇਵ ਦੁਆਰਾ ਰਿਪੋਰਟ ਦੀ ਪ੍ਰਤੀਲਿਪੀ ਨੂੰ ਪੜ੍ਹੋ “ਡੌਕਰ + ਗਿਟਲਬ ਸੀਆਈ ਦੇ ਨਾਲ ਵਿਕਾਸ ਅਤੇ ਜਾਂਚ ਪ੍ਰਕਿਰਿਆ”।

ਜਿਹੜੇ ਲੋਕ ਹੁਣੇ ਹੀ ਡੌਕਰ + ਗਿਟਲਬ ਸੀਆਈ ਦੇ ਅਧਾਰ ਤੇ ਵਿਕਾਸ ਅਤੇ ਟੈਸਟਿੰਗ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹਨ ਅਕਸਰ ਬੁਨਿਆਦੀ ਪ੍ਰਸ਼ਨ ਪੁੱਛਦੇ ਹਨ. ਕਿੱਥੇ ਸ਼ੁਰੂ ਕਰਨਾ ਹੈ? ਕਿਵੇਂ ਸੰਗਠਿਤ ਕਰਨਾ ਹੈ? ਟੈਸਟ ਕਿਵੇਂ ਕਰੀਏ?

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

ਕੌਣ ਪਰਵਾਹ ਕਰਦਾ ਹੈ, ਕਿਰਪਾ ਕਰਕੇ ਬਿੱਲੀ ਦੇ ਹੇਠਾਂ.

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

ਰਿਪੋਰਟ ਦਾ ਵਿਸ਼ਾ: ਡੌਕਰ ਅਤੇ ਗਿਟਲਬ ਸੀਆਈ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਵਿਕਾਸ ਪ੍ਰਕਿਰਿਆ।

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

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

ਸਾਡਾ ਮਨੋਰਥ: ਹਰ ਚੀਜ਼ ਨੂੰ ਡੌਕਰਾਈਜ਼ ਕਰੋ ਜਿਸ 'ਤੇ ਅਸੀਂ ਹੱਥ ਪਾਉਂਦੇ ਹਾਂ।

ਅਸੀਂ ਕਿਹੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਹੱਲ ਕਰ ਰਹੇ ਹਾਂ?

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

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

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

ਅਗਲਾ ਕਾਰਨ ਵਿਕਾਸ ਵਿੱਚ ਸੈਟਿੰਗਾਂ ਦਾ ਮਾਨਕੀਕਰਨ ਹੈ। ਮੇਰੇ ਅਨੁਭਵ ਵਿੱਚ, ਡਿਵੈਲਪਰ ਹਮੇਸ਼ਾ ਪਹਿਲ ਕਰਦੇ ਹਨ। ਹਰ ਪੰਜਵੇਂ ਕੇਸ ਵਿੱਚ, ਇੱਕ ਕਸਟਮ ਡੋਮੇਨ ਦਰਜ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ vasya.dev। ਮੇਰੇ ਕੋਲ ਬੈਠਾ ਮੇਰਾ ਗੁਆਂਢੀ ਪੇਟੀਆ ਹੈ, ਜਿਸਦਾ ਡੋਮੇਨ petya.dev ਹੈ। ਉਹ ਇਸ ਡੋਮੇਨ ਨਾਮ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਵੈਬਸਾਈਟ ਜਾਂ ਕੁਝ ਸਿਸਟਮ ਕੰਪੋਨੈਂਟ ਵਿਕਸਿਤ ਕਰਦੇ ਹਨ।

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

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

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

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

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

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

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

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

ਸੰਦ। ਅਸੀਂ ਕੀ ਵਰਤਦੇ ਹਾਂ?

• ਡੌਕਰ ਖੁਦ. ਇੱਕ ਡੌਕਰਫਾਈਲ ਇੱਕ ਸਿੰਗਲ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਨਿਰਭਰਤਾ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ।
• ਡੌਕਰ-ਕੰਪੋਜ਼ ਇੱਕ ਬੰਡਲ ਹੈ ਜੋ ਸਾਡੀਆਂ ਕਈ ਡੌਕਰ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਦਾ ਹੈ।
• ਅਸੀਂ ਸਰੋਤ ਕੋਡ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ GitLab ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।
• ਅਸੀਂ ਸਿਸਟਮ ਏਕੀਕਰਣ ਲਈ GitLab-CI ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।

ਰਿਪੋਰਟ ਦੇ ਦੋ ਭਾਗ ਹਨ।

ਪਹਿਲਾ ਭਾਗ ਤੁਹਾਨੂੰ ਦੱਸੇਗਾ ਕਿ ਡਿਵੈਲਪਰਾਂ ਦੀਆਂ ਮਸ਼ੀਨਾਂ 'ਤੇ ਡੌਕਰ ਨੂੰ ਕਿਵੇਂ ਚਲਾਉਣਾ ਹੈ।

ਦੂਜਾ ਭਾਗ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰੇਗਾ ਕਿ GitLab ਨਾਲ ਕਿਵੇਂ ਗੱਲਬਾਤ ਕਰਨੀ ਹੈ, ਅਸੀਂ ਟੈਸਟ ਕਿਵੇਂ ਚਲਾਉਂਦੇ ਹਾਂ ਅਤੇ ਅਸੀਂ ਸਟੇਜਿੰਗ ਲਈ ਕਿਵੇਂ ਰੋਲ ਆਊਟ ਕਰਦੇ ਹਾਂ।

ਡੌਕਰ ਇੱਕ ਤਕਨਾਲੋਜੀ ਹੈ ਜੋ ਲੋੜੀਂਦੇ ਭਾਗਾਂ ਦਾ ਵਰਣਨ ਕਰਨ ਲਈ (ਇੱਕ ਘੋਸ਼ਣਾਤਮਕ ਪਹੁੰਚ ਦੀ ਵਰਤੋਂ ਕਰਕੇ) ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ। ਇਹ ਇੱਕ ਉਦਾਹਰਣ ਹੈ ਡੌਕਰਫਾਈਲ. ਇੱਥੇ ਅਸੀਂ ਘੋਸ਼ਣਾ ਕਰਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਰੂਬੀ ਦੇ ਅਧਿਕਾਰਤ ਡੌਕਰ ਚਿੱਤਰ ਤੋਂ ਵਿਰਾਸਤ ਪ੍ਰਾਪਤ ਕਰ ਰਹੇ ਹਾਂ: 2.3.0. ਇਸ ਵਿੱਚ ਰੂਬੀ ਸੰਸਕਰਣ 2.3 ਸਥਾਪਿਤ ਹੈ। ਅਸੀਂ ਲੋੜੀਂਦੀਆਂ ਅਸੈਂਬਲੀ ਲਾਇਬ੍ਰੇਰੀਆਂ ਅਤੇ ਨੋਡਜੇਐਸ ਨੂੰ ਸਥਾਪਿਤ ਕਰਦੇ ਹਾਂ. ਅਸੀਂ ਵਰਣਨ ਕਰਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਇੱਕ ਡਾਇਰੈਕਟਰੀ ਬਣਾ ਰਹੇ ਹਾਂ /app. ਅਸੀਂ ਐਪ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਕਾਰਜਸ਼ੀਲ ਡਾਇਰੈਕਟਰੀ ਦੇ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ। ਇਸ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਅਸੀਂ ਲੋੜੀਂਦੀ ਘੱਟੋ-ਘੱਟ Gemfile ਅਤੇ Gemfile.lock ਰੱਖਦੇ ਹਾਂ। ਫਿਰ ਅਸੀਂ ਪ੍ਰੋਜੈਕਟ ਬਣਾਉਂਦੇ ਹਾਂ ਜੋ ਇਸ ਨਿਰਭਰਤਾ ਚਿੱਤਰ ਨੂੰ ਸਥਾਪਿਤ ਕਰਦੇ ਹਨ। ਅਸੀਂ ਸੰਕੇਤ ਦਿੰਦੇ ਹਾਂ ਕਿ ਕੰਟੇਨਰ ਬਾਹਰੀ ਪੋਰਟ 3000 'ਤੇ ਸੁਣਨ ਲਈ ਤਿਆਰ ਹੋਵੇਗਾ। ਆਖਰੀ ਕਮਾਂਡ ਉਹ ਕਮਾਂਡ ਹੈ ਜੋ ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸਿੱਧਾ ਲਾਂਚ ਕਰਦੀ ਹੈ। ਜੇਕਰ ਅਸੀਂ ਪ੍ਰੋਜੈਕਟ ਰਨ ਕਮਾਂਡ ਨੂੰ ਚਲਾਉਂਦੇ ਹਾਂ, ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਨਿਰਧਾਰਤ ਕਮਾਂਡ ਨੂੰ ਚਲਾਉਣ ਅਤੇ ਚਲਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗੀ।

ਇਹ ਇੱਕ ਡੌਕਰ-ਕੰਪੋਜ਼ ਫਾਈਲ ਦੀ ਇੱਕ ਘੱਟੋ-ਘੱਟ ਉਦਾਹਰਣ ਹੈ। ਇਸ ਕੇਸ ਵਿੱਚ, ਅਸੀਂ ਦਿਖਾਉਂਦੇ ਹਾਂ ਕਿ ਦੋ ਕੰਟੇਨਰਾਂ ਵਿਚਕਾਰ ਇੱਕ ਕੁਨੈਕਸ਼ਨ ਹੈ. ਇਹ ਸਿੱਧਾ ਡੇਟਾਬੇਸ ਸੇਵਾ ਅਤੇ ਵੈਬ ਸੇਵਾ ਵਿੱਚ ਹੈ। ਸਾਡੀਆਂ ਵੈਬ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਡਾਟਾ ਸਟੋਰ ਕਰਨ ਲਈ ਬੈਕਐਂਡ ਵਜੋਂ ਕਿਸੇ ਕਿਸਮ ਦੇ ਡੇਟਾਬੇਸ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਕਿਉਂਕਿ ਅਸੀਂ MySQL ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ, ਉਦਾਹਰਣ MySQL ਨਾਲ ਹੈ - ਪਰ ਕੁਝ ਵੀ ਸਾਨੂੰ ਕੁਝ ਹੋਰ ਡੇਟਾਬੇਸ (PostgreSQL, Redis) ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਨਹੀਂ ਰੋਕਦਾ।

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

ਅਸੀਂ ਇਹ ਵੀ ਵਰਣਨ ਕਰਦੇ ਹਾਂ ਕਿ ਸਾਨੂੰ ਆਪਣੀ ਡਿਵੈਲਪਰ ਹੋਸਟ ਮਸ਼ੀਨ 'ਤੇ ਪੋਰਟ ਨੂੰ 3000 ਤੋਂ 3000 ਕੰਟੇਨਰ ਪੋਰਟ ਤੱਕ ਅੱਗੇ ਭੇਜਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ. ਇਹ iptables ਅਤੇ ਇਸਦੀ ਆਪਣੀ ਵਿਧੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਆਪਣੇ ਆਪ ਹੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਡੌਕਰ ਵਿੱਚ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ।

ਡਿਵੈਲਪਰ, ਪਹਿਲਾਂ ਵਾਂਗ, ਕਿਸੇ ਵੀ ਉਪਲਬਧ IP ਐਡਰੈੱਸ ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ, ਮਸ਼ੀਨ ਦਾ 127.0.0.1 ਸਥਾਨਕ ਜਾਂ ਬਾਹਰੀ IP ਪਤਾ।

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

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

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

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

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

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

ਫਰੰਟਐਂਡ 'ਤੇ ਅਸੀਂ JavaScipt ਅਤੇ NodeJS ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।

ਹੁਣ ਸਾਡੇ ਕੋਲ ReacJS 'ਤੇ ਸਾਡਾ ਆਖਰੀ ਪ੍ਰੋਜੈਕਟ ਹੈ। ਡਿਵੈਲਪਰ ਨੇ ਹਰ ਚੀਜ਼ ਨੂੰ ਕੰਟੇਨਰ ਵਿੱਚ ਲਾਂਚ ਕੀਤਾ ਅਤੇ ਹੌਟ-ਰੀਲੋਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਵਿਕਸਤ ਕੀਤਾ।

ਅੱਗੇ, JavaScipt ਨੂੰ ਅਸੈਂਬਲ ਕਰਨ ਦਾ ਕੰਮ ਸ਼ੁਰੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸਟੈਟਿਕ ਤੌਰ 'ਤੇ ਅਸੈਂਬਲ ਕੀਤੇ ਕੋਡ ਨੂੰ nginx ਦੁਆਰਾ ਭੇਜਿਆ ਜਾਂਦਾ ਹੈ, ਸਰੋਤਾਂ ਨੂੰ ਬਚਾਉਂਦਾ ਹੈ।

ਇੱਥੇ ਮੈਂ ਸਾਡੇ ਨਵੀਨਤਮ ਪ੍ਰੋਜੈਕਟ ਦਾ ਇੱਕ ਚਿੱਤਰ ਪ੍ਰਦਾਨ ਕੀਤਾ ਹੈ।

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

ਅਸੀਂ ਇਸ ਲਈ ਕੀ ਕੀਤਾ ਹੈ?

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

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

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

ਪੁਸ਼ ਸੂਚਨਾਵਾਂ ਕਿਸੇ ਹੋਰ ਕੰਪੋਨੈਂਟ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਦੀਆਂ ਹਨ ਜੋ NodeJS ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ।

ਕਤਾਰਾਂ ਬਣਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ ਅਤੇ ਸੂਚਨਾਵਾਂ ਉਹਨਾਂ ਦੀ ਆਪਣੀ ਵਿਧੀ ਅਨੁਸਾਰ ਭੇਜੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

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

ਇੱਕੋ ਗੱਲ ਹੈ ਪਰ ਗਿਣਤੀ ਵਿੱਚ. ਕੋਡ ਦੀ ਮੁੜ ਵਰਤੋਂ ਇੱਥੇ ਮਹੱਤਵਪੂਰਨ ਹੈ।

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

ਉਸ ਸਮੇਂ ਅਸੀਂ NodeJS ਦਾ ਵਰਜਨ 4 ਵਰਤ ਰਹੇ ਸੀ। ਹੁਣ (2017 ਵਿੱਚ - ਸੰਪਾਦਕ ਦਾ ਨੋਟ) ਸਾਡੇ ਨਵੀਨਤਮ ਵਿਕਾਸ ਵਿੱਚ ਅਸੀਂ NodeJS ਦੇ ਸੰਸਕਰਣ 7 ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। ਲਾਇਬ੍ਰੇਰੀਆਂ ਦੇ ਨਵੇਂ ਸੰਸਕਰਣਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਲਈ ਨਵੇਂ ਭਾਗਾਂ ਵਿੱਚ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ.

ਜੇ ਜਰੂਰੀ ਹੋਵੇ, ਤਾਂ ਤੁਸੀਂ ਪੁਸ਼ ਸੂਚਨਾ ਸੇਵਾ ਦੇ NodeJS ਸੰਸਕਰਣ ਨੂੰ ਰੀਫੈਕਟਰ ਅਤੇ ਵਧਾ ਸਕਦੇ ਹੋ।

ਅਤੇ ਜੇਕਰ ਅਸੀਂ API ਅਨੁਕੂਲਤਾ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖ ਸਕਦੇ ਹਾਂ, ਤਾਂ ਇਸਨੂੰ ਹੋਰ ਪ੍ਰੋਜੈਕਟਾਂ ਨਾਲ ਬਦਲਣਾ ਸੰਭਵ ਹੋਵੇਗਾ ਜੋ ਪਹਿਲਾਂ ਵਰਤੇ ਗਏ ਸਨ.

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

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

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

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

ਅੱਗੇ ਸਾਡੇ ਕੋਲ ਕਈ ਭਾਗ ਹਨ: ਐਡਮਿਨ, ਜਾਣਕਾਰੀ-ਏਪੀਆਈ, ਪੁਸ਼ ਸੂਚਨਾਵਾਂ।

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

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

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

ਜੇਕਰ ਪੁਸ਼ ਸੂਚਨਾਵਾਂ ਦੇ ਨਾਲ ਏਕੀਕਰਣ ਦੀ ਲੋੜ ਹੈ, ਤਾਂ docker-compose.yaml ਅਤੇ docker-compose-push.yaml ਨੂੰ ਲਾਂਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਕਿਉਂਕਿ docker-compose.yaml ਅਤੇ docker-compose-push.yaml ਫੋਲਡਰ ਵਿੱਚ ਹਨ, ਇੱਕ ਸਿੰਗਲ ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਆਪਣੇ ਆਪ ਬਣ ਜਾਂਦਾ ਹੈ।

ਭਾਗਾਂ ਦਾ ਵੇਰਵਾ। ਇਹ ਇੱਕ ਵਧੇਰੇ ਉੱਨਤ ਫਾਈਲ ਹੈ ਜੋ ਭਾਗਾਂ ਨੂੰ ਇਕੱਠਾ ਕਰਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਇੱਥੇ ਕੀ ਕਮਾਲ ਹੈ? ਇੱਥੇ ਅਸੀਂ ਬੈਲੇਂਸਰ ਕੰਪੋਨੈਂਟ ਪੇਸ਼ ਕਰਦੇ ਹਾਂ।

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

ਵਿਕਾਸ ਵਾਤਾਵਰਨ ਲਈ ਅਸੀਂ .dev ਡੋਮੇਨ - api.informer.dev ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ। .dev ਡੋਮੇਨ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਡਿਵੈਲਪਰ ਦੀ ਸਥਾਨਕ ਮਸ਼ੀਨ 'ਤੇ ਉਪਲਬਧ ਹਨ।

ਫਿਰ ਕੌਂਫਿਗਸ ਨੂੰ ਹਰੇਕ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਟ੍ਰਾਂਸਫਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਸਾਰੇ ਪ੍ਰੋਜੈਕਟ ਇੱਕੋ ਸਮੇਂ ਇਕੱਠੇ ਲਾਂਚ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

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

ਬੈਲੇਂਸਰ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਡੋਮੇਨ ਨਾਮ ਦੇ ਆਧਾਰ 'ਤੇ ਕਿਹੜੇ ਕੰਟੇਨਰ ਨੂੰ ਐਕਸੈਸ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਇਹ nginx ਹੋ ਸਕਦਾ ਹੈ, ਜੋ ਐਡਮਿਨ ਪੈਨਲ ਨੂੰ JS ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਹ nginx ਦੁਆਰਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਜੋ API ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ, ਜਾਂ ਸਥਿਰ ਫਾਈਲਾਂ, ਜੋ ਕਿ ਲੋਡਿੰਗ ਚਿੱਤਰਾਂ ਦੇ ਰੂਪ ਵਿੱਚ nginx ਦੁਆਰਾ ਪ੍ਰਦਾਨ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

ਚਿੱਤਰ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕੰਟੇਨਰ ਇੱਕ ਵਰਚੁਅਲ ਨੈਟਵਰਕ ਨਾਲ ਜੁੜੇ ਹੋਏ ਹਨ ਅਤੇ ਇੱਕ ਪ੍ਰੌਕਸੀ ਦੇ ਪਿੱਛੇ ਲੁਕੇ ਹੋਏ ਹਨ।

ਡਿਵੈਲਪਰ ਦੀ ਮਸ਼ੀਨ 'ਤੇ, ਤੁਸੀਂ IP ਨੂੰ ਜਾਣਦੇ ਹੋਏ ਕੰਟੇਨਰ ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਸਿਧਾਂਤਕ ਤੌਰ 'ਤੇ ਅਸੀਂ ਇਸਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦੇ ਹਾਂ। ਸਿੱਧੇ ਸੰਪਰਕ ਦੀ ਅਮਲੀ ਤੌਰ 'ਤੇ ਕੋਈ ਲੋੜ ਨਹੀਂ ਹੈ।

ਆਪਣੀ ਅਰਜ਼ੀ ਨੂੰ ਡੌਕਰਾਈਜ਼ ਕਰਨ ਲਈ ਮੈਨੂੰ ਕਿਹੜੀ ਉਦਾਹਰਨ ਦੇਖਣੀ ਚਾਹੀਦੀ ਹੈ? ਮੇਰੀ ਰਾਏ ਵਿੱਚ, ਇੱਕ ਵਧੀਆ ਉਦਾਹਰਣ MySQL ਲਈ ਅਧਿਕਾਰਤ ਡੌਕਰ ਚਿੱਤਰ ਹੈ.

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

Hub.docker.com ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ github.com ਦੇ ਲਿੰਕ ਹੁੰਦੇ ਹਨ, ਜਿੱਥੇ ਕੱਚਾ ਡੇਟਾ ਸਿੱਧਾ ਪ੍ਰਦਾਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਿਸ ਤੋਂ ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਇੱਕ ਚਿੱਤਰ ਬਣਾ ਸਕਦੇ ਹੋ।

ਇਸ ਤੋਂ ਅੱਗੇ ਇਸ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਇੱਕ ਸਕ੍ਰਿਪਟ docker-endpoint.sh ਹੈ, ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਲਾਂਚ ਦੀ ਸ਼ੁਰੂਆਤੀ ਸ਼ੁਰੂਆਤ ਅਤੇ ਅੱਗੇ ਦੀ ਪ੍ਰਕਿਰਿਆ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ।

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

ਇੱਕ ਬੇਤਰਤੀਬ ਪਾਸਵਰਡ ਬਣਾਉਣ ਲਈ ਇੱਕ ਵਿਕਲਪ ਹੈ. ਅਸੀਂ ਕਹਿੰਦੇ ਹਾਂ ਕਿ ਸਾਨੂੰ ਇੱਕ ਉਪਭੋਗਤਾ ਦੀ ਲੋੜ ਹੈ, ਸਾਨੂੰ ਉਪਭੋਗਤਾ ਲਈ ਇੱਕ ਪਾਸਵਰਡ ਸੈੱਟ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ ਸਾਨੂੰ ਇੱਕ ਡੇਟਾਬੇਸ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ।

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

ਇਹ ਇੱਕ ਉਦਾਹਰਨ ਹੈ ਕਿ MySQL ਦਾ ਇੱਕ ਖਾਸ ਸੰਸਕਰਣ github.com 'ਤੇ ਕਿਵੇਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ. ਤੁਸੀਂ ਡੌਕਰਫਾਈਲ ਨੂੰ ਖੋਲ੍ਹ ਸਕਦੇ ਹੋ ਅਤੇ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਉੱਥੇ ਇੰਸਟਾਲੇਸ਼ਨ ਕਿਵੇਂ ਹੁੰਦੀ ਹੈ।

docker-endpoint.sh ਸਕ੍ਰਿਪਟ ਐਂਟਰੀ ਪੁਆਇੰਟ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ। ਸ਼ੁਰੂਆਤੀ ਸ਼ੁਰੂਆਤ ਦੇ ਦੌਰਾਨ, ਕੁਝ ਤਿਆਰੀ ਦੀਆਂ ਕਾਰਵਾਈਆਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਇਹ ਸਾਰੀਆਂ ਕਾਰਵਾਈਆਂ ਸ਼ੁਰੂਆਤੀ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

ਆਉ ਦੂਜੇ ਭਾਗ ਵੱਲ ਵਧੀਏ।

ਅਸੀਂ ਸਰੋਤ ਕੋਡਾਂ ਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ gitlab 'ਤੇ ਸਵਿਚ ਕੀਤਾ ਹੈ। ਇਹ ਇੱਕ ਕਾਫ਼ੀ ਸ਼ਕਤੀਸ਼ਾਲੀ ਸਿਸਟਮ ਹੈ ਜਿਸਦਾ ਇੱਕ ਵਿਜ਼ੂਅਲ ਇੰਟਰਫੇਸ ਹੈ।

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

Gitlab CI 2 'ਤੇ ਰਿਪੋਰਟ https://goo.gl/uohKjI — ਰੂਬੀ ਰੂਸ ਕਲੱਬ ਦੀ ਰਿਪੋਰਟ ਕਾਫ਼ੀ ਵਿਸਤ੍ਰਿਤ ਹੈ ਅਤੇ ਤੁਹਾਡੇ ਲਈ ਦਿਲਚਸਪ ਹੋ ਸਕਦੀ ਹੈ।

ਹੁਣ ਅਸੀਂ ਦੇਖਾਂਗੇ ਕਿ Gitlab CI ਨੂੰ ਸਰਗਰਮ ਕਰਨ ਲਈ ਕੀ ਜ਼ਰੂਰੀ ਹੈ। Gitlab CI ਨੂੰ ਲਾਂਚ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਸਿਰਫ਼ .gitlab-ci.yml ਫਾਈਲ ਨੂੰ ਪ੍ਰੋਜੈਕਟ ਦੇ ਰੂਟ ਵਿੱਚ ਪਾਉਣ ਦੀ ਲੋੜ ਹੈ।

ਇੱਥੇ ਅਸੀਂ ਵਰਣਨ ਕਰਦੇ ਹਾਂ ਕਿ ਅਸੀਂ ਟੈਸਟ, ਤੈਨਾਤੀ ਵਰਗੀਆਂ ਸਥਿਤੀਆਂ ਦਾ ਇੱਕ ਕ੍ਰਮ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ।

ਅਸੀਂ ਉਹਨਾਂ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਚਲਾਉਂਦੇ ਹਾਂ ਜੋ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਡੌਕਰ-ਕੰਪੋਜ਼ ਬਿਲਡ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਨ। ਇਹ ਸਿਰਫ਼ ਬੈਕਐਂਡ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਹੈ।

ਅੱਗੇ ਅਸੀਂ ਕਹਿੰਦੇ ਹਾਂ ਕਿ ਡੇਟਾਬੇਸ ਨੂੰ ਬਦਲਣ ਅਤੇ ਟੈਸਟ ਚਲਾਉਣ ਲਈ ਮਾਈਗ੍ਰੇਸ਼ਨ ਚਲਾਉਣਾ ਜ਼ਰੂਰੀ ਹੈ।

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

ਤੈਨਾਤੀ ਪੜਾਅ ਵਰਤਮਾਨ ਵਿੱਚ ਸਟੇਜਿੰਗ ਲਈ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ। ਅਸੀਂ ਨੋ-ਡਾਊਨਟਾਈਮ ਰੀਸਟਾਰਟ ਦਾ ਆਯੋਜਨ ਨਹੀਂ ਕੀਤਾ।

ਅਸੀਂ ਜ਼ਬਰਦਸਤੀ ਸਾਰੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਬੁਝਾ ਦਿੰਦੇ ਹਾਂ, ਅਤੇ ਫਿਰ ਅਸੀਂ ਟੈਸਟਿੰਗ ਦੌਰਾਨ ਪਹਿਲੇ ਪੜਾਅ 'ਤੇ ਇਕੱਠੇ ਕੀਤੇ ਸਾਰੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਦੁਬਾਰਾ ਚੁੱਕਦੇ ਹਾਂ।

ਆਉ ਮੌਜੂਦਾ ਵੇਰੀਏਬਲ ਵਾਤਾਵਰਨ ਲਈ ਡਿਵੈਲਪਰਾਂ ਦੁਆਰਾ ਲਿਖੇ ਗਏ ਡੇਟਾਬੇਸ ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਚਲਾਉਂਦੇ ਹਾਂ।

ਇੱਥੇ ਇੱਕ ਨੋਟ ਹੈ ਕਿ ਇਹ ਸਿਰਫ ਮਾਸਟਰ ਬ੍ਰਾਂਚ 'ਤੇ ਲਾਗੂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਦੂਜੀਆਂ ਸ਼ਾਖਾਵਾਂ ਨੂੰ ਬਦਲਣ ਵੇਲੇ ਕੰਮ ਨਹੀਂ ਕਰਦਾ।

ਸ਼ਾਖਾਵਾਂ ਦੇ ਨਾਲ ਰੋਲਆਉਟ ਨੂੰ ਸੰਗਠਿਤ ਕਰਨਾ ਸੰਭਵ ਹੈ।

ਇਸ ਨੂੰ ਹੋਰ ਸੰਗਠਿਤ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਗਿਟਲਬ ਰਨਰ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।

ਇਹ ਉਪਯੋਗਤਾ ਗੋਲੰਗ ਵਿੱਚ ਲਿਖੀ ਗਈ ਹੈ. ਇਹ ਇੱਕ ਸਿੰਗਲ ਫਾਈਲ ਹੈ ਜਿਵੇਂ ਕਿ ਗੋਲੰਗ ਸੰਸਾਰ ਵਿੱਚ ਆਮ ਹੈ, ਜਿਸ ਲਈ ਕਿਸੇ ਨਿਰਭਰਤਾ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ।

ਸ਼ੁਰੂਆਤ 'ਤੇ ਅਸੀਂ ਗਿਟਲਬ ਰਨਰ ਨੂੰ ਰਜਿਸਟਰ ਕਰਦੇ ਹਾਂ।

ਸਾਨੂੰ Gitlab ਵੈੱਬ ਇੰਟਰਫੇਸ ਵਿੱਚ ਕੁੰਜੀ ਪ੍ਰਾਪਤ ਹੁੰਦੀ ਹੈ।

ਫਿਰ ਅਸੀਂ ਕਮਾਂਡ ਲਾਈਨ 'ਤੇ ਸ਼ੁਰੂਆਤੀ ਕਮਾਂਡ ਨੂੰ ਕਾਲ ਕਰਦੇ ਹਾਂ।

ਡਾਇਲਾਗ ਮੋਡ (ਸ਼ੈਲ, ਡੌਕਰ, ਵਰਚੁਅਲਬੌਕਸ, SSH) ਵਿੱਚ ਗਿਟਲੈਬ ਰਨਰ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨਾ

Gitlab ਰਨਰ 'ਤੇ ਕੋਡ .gitlab-ci.yml ਸੈਟਿੰਗ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ ਹਰੇਕ ਪ੍ਰਤੀਬੱਧਤਾ 'ਤੇ ਚੱਲੇਗਾ।

ਇਹ ਵੈੱਬ ਇੰਟਰਫੇਸ ਵਿੱਚ ਗਿਟਲੈਬ ਵਿੱਚ ਕਿਵੇਂ ਦਿਸਦਾ ਹੈ। GItlab CI ਨਾਲ ਜੁੜਨ ਤੋਂ ਬਾਅਦ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਝੰਡਾ ਹੈ ਜੋ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਬਿਲਡ ਇਸ ਸਮੇਂ ਕਿਸ ਸਥਿਤੀ ਵਿੱਚ ਹੈ।

ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ 4 ਮਿੰਟ ਪਹਿਲਾਂ ਇੱਕ ਵਚਨਬੱਧਤਾ ਕੀਤੀ ਗਈ ਸੀ ਜਿਸ ਨੇ ਸਾਰੇ ਟੈਸਟ ਪਾਸ ਕੀਤੇ ਸਨ ਅਤੇ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਸੀ.

ਅਸੀਂ ਬਿਲਡਾਂ ਨੂੰ ਹੋਰ ਵਿਸਥਾਰ ਵਿੱਚ ਦੇਖ ਸਕਦੇ ਹਾਂ। ਇੱਥੇ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਦੋ ਰਾਜ ਪਹਿਲਾਂ ਹੀ ਲੰਘ ਚੁੱਕੇ ਹਨ। ਸਟੇਜਿੰਗ 'ਤੇ ਟੈਸਟਿੰਗ ਸਥਿਤੀ ਅਤੇ ਤੈਨਾਤੀ ਸਥਿਤੀ।

ਜੇਕਰ ਅਸੀਂ ਇੱਕ ਖਾਸ ਬਿਲਡ 'ਤੇ ਕਲਿੱਕ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਉੱਥੇ ਉਹਨਾਂ ਕਮਾਂਡਾਂ ਦਾ ਕੰਸੋਲ ਆਉਟਪੁੱਟ ਹੋਵੇਗਾ ਜੋ .gitlab-ci.yml ਦੇ ਅਨੁਸਾਰ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਲਾਂਚ ਕੀਤੇ ਗਏ ਸਨ।

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

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

ਅਜਿਹਾ ਕਰਨ ਲਈ, ਸਾਨੂੰ ਹਰ ਚੀਜ਼ ਨੂੰ ਵੱਖਰੇ ਫੋਲਡਰਾਂ ਵਿੱਚ ਵੱਖ ਕਰਨਾ ਪਿਆ.

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

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

ਇਸ ਤਰ੍ਹਾਂ, ਹਰੇਕ ਕੰਪੋਨੈਂਟ ਜੋ ਇਸ ਜਾਲ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਸਿਸਟਮ ਦੇ ਦੂਜੇ ਹਿੱਸਿਆਂ ਵਿੱਚ ਭਾਗ ਦੇਖਦਾ ਹੈ।

ਅਗਲੀ ਸਮੱਸਿਆ ਕਈ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿਚਕਾਰ ਸਟੇਜਿੰਗ ਨੂੰ ਵੰਡ ਰਹੀ ਹੈ।

ਕਿਉਂਕਿ ਇਹ ਸਭ ਸੁੰਦਰ ਦਿਖਣ ਲਈ ਅਤੇ ਉਤਪਾਦਨ ਦੇ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਨੇੜੇ ਹੋਣ ਲਈ, ਪੋਰਟ 80 ਜਾਂ 443 ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਚੰਗਾ ਹੈ, ਜੋ ਕਿ WEB ਵਿੱਚ ਹਰ ਥਾਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

ਅਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਹੱਲ ਕੀਤਾ? ਅਸੀਂ ਸਾਰੇ ਵੱਡੇ ਪ੍ਰੋਜੈਕਟਾਂ ਲਈ ਇੱਕ ਗਿਟਲਬ ਰਨਰ ਨਿਰਧਾਰਤ ਕੀਤਾ ਹੈ।

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

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

ਅਸੀਂ nginx-proxy ਨੂੰ ਇੱਕ ਵੱਖਰੀ ਲਾਂਚ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਤਬਦੀਲ ਕੀਤਾ ਅਤੇ ਇਸ ਵਿੱਚ ਸਾਰੇ ਪ੍ਰੋਜੈਕਟਾਂ ਦੇ ਗਰਿੱਡ ਲਿਖੇ।

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

ਸਾਡੀਆਂ ਬੇਨਤੀਆਂ ਪੋਰਟ 80 'ਤੇ ਡੋਮੇਨ ਰਾਹੀਂ ਆਉਂਦੀਆਂ ਹਨ ਅਤੇ ਇਸ ਡੋਮੇਨ ਦੀ ਸੇਵਾ ਕਰਨ ਵਾਲੇ ਕੰਟੇਨਰਾਂ ਦੇ ਸਮੂਹ ਨੂੰ ਹੱਲ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ।

ਹੋਰ ਕਿਹੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਸਨ? ਇਹ ਉਹ ਹੈ ਜੋ ਸਾਰੇ ਕੰਟੇਨਰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਰੂਟ ਵਜੋਂ ਚਲਦੇ ਹਨ। ਇਹ ਸਿਸਟਮ ਦਾ ਰੂਟ ਅਸਮਾਨ ਰੂਟ ਹੋਸਟ ਹੈ।

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

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

ਇਹ ਕਿਵੇਂ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ? ਤੁਸੀਂ ਉਹਨਾਂ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਜੋੜ ਸਕਦੇ ਹੋ ਜੋ ਕੰਟੇਨਰ ਵਿੱਚ ਹੋਣਗੇ।

ਜਦੋਂ ਅਸੀਂ ਉਪਭੋਗਤਾ ਨੂੰ ਜੋੜਿਆ ਤਾਂ ਕਿਹੜੀਆਂ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੋਈਆਂ?

ਇੱਕ ਉਪਭੋਗਤਾ ਬਣਾਉਣ ਵੇਲੇ, ਸਮੂਹ ID (UID) ਅਤੇ ਉਪਭੋਗਤਾ ID (GID) ਅਕਸਰ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ।

ਕੰਟੇਨਰ ਵਿੱਚ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਅਸੀਂ ID 1000 ਵਾਲੇ ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ।

ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਇਹ ਇਸ ਤੱਥ ਦੇ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਕਿ ਲਗਭਗ ਸਾਰੇ ਡਿਵੈਲਪਰ ਉਬੰਟੂ OS ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ. ਅਤੇ Ubuntu OS ਵਿੱਚ ਪਹਿਲੇ ਉਪਭੋਗਤਾ ਕੋਲ ID 1000 ਹੈ।

ਕੀ ਸਾਡੇ ਕੋਲ ਯੋਜਨਾਵਾਂ ਹਨ?

ਡੌਕਰ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਦੁਬਾਰਾ ਪੜ੍ਹੋ। ਪ੍ਰੋਜੈਕਟ ਸਰਗਰਮੀ ਨਾਲ ਵਿਕਾਸ ਕਰ ਰਿਹਾ ਹੈ, ਦਸਤਾਵੇਜ਼ ਬਦਲ ਰਿਹਾ ਹੈ. ਦੋ-ਤਿੰਨ ਮਹੀਨੇ ਪਹਿਲਾਂ ਪ੍ਰਾਪਤ ਕੀਤਾ ਡੇਟਾ ਹੌਲੀ-ਹੌਲੀ ਪੁਰਾਣਾ ਹੁੰਦਾ ਜਾ ਰਿਹਾ ਹੈ।

ਕੁਝ ਸਮੱਸਿਆਵਾਂ ਜੋ ਅਸੀਂ ਹੱਲ ਕੀਤੀਆਂ ਹਨ, ਸ਼ਾਇਦ ਪਹਿਲਾਂ ਹੀ ਮਿਆਰੀ ਤਰੀਕਿਆਂ ਨਾਲ ਹੱਲ ਹੋ ਚੁੱਕੀਆਂ ਹੋਣ।

ਮੈਂ ਅਸਲ ਵਿੱਚ ਅੱਗੇ ਵਧਣਾ ਚਾਹੁੰਦਾ ਹਾਂ ਅਤੇ ਸਿੱਧੇ ਆਰਕੈਸਟ੍ਰੇਸ਼ਨ ਵਿੱਚ ਜਾਣਾ ਚਾਹੁੰਦਾ ਹਾਂ।

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

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

ਸਰੋਤ: www.habr.com