php ਅਤੇ ਡੌਕਰ ਉਦਾਹਰਨਾਂ ਦੇ ਨਾਲ ਬਾਰ੍ਹਾਂ-ਫੈਕਟਰ ਐਪ ਵਿਧੀ 'ਤੇ ਆਧਾਰਿਤ ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਮੈਂਟ ਅਤੇ ਬਲੂ-ਗ੍ਰੀਨ ਡਿਪਲਾਇਮੈਂਟ

ਆਉ ਇੱਕ ਛੋਟੇ ਸਿਧਾਂਤ ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ. ਕੀ ਹੋਇਆ ਹੈ ਬਾਰ੍ਹਾਂ ਫੈਕਟਰ ਐਪ?

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

ਦਸਤਾਵੇਜ਼ Heroku ਪਲੇਟਫਾਰਮ ਦੇ ਡਿਵੈਲਪਰਾਂ ਦੁਆਰਾ ਬਣਾਇਆ ਗਿਆ ਸੀ।

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

ਉਹਨਾਂ ਕਾਰਕਾਂ ਬਾਰੇ ਸੰਖੇਪ ਵਿੱਚ ਜਿਹਨਾਂ ਉੱਤੇ ਇਹ ਕਾਰਜਪ੍ਰਣਾਲੀ ਅਧਾਰਤ ਹੈ:

1. ਕੋਡਬੇਸ - ਇੱਕ ਸਰੋਤ-ਟਰੈਕ ਕੀਤਾ ਕੋਡਬੇਸ - ਕਈ ਤੈਨਾਤੀਆਂ
2. ਨਿਰਭਰਤਾਵਾਂ - ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਨਿਰਭਰਤਾਵਾਂ ਦਾ ਐਲਾਨ ਕਰੋ ਅਤੇ ਅਲੱਗ-ਥਲੱਗ ਕਰੋ
3. ਕੌਨਫਿਗਰੇਸ਼ਨ - ਰਨਟਾਈਮ 'ਤੇ ਸੰਰਚਨਾ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕਰੋ
4. ਤੀਜੀ ਧਿਰ ਦੀਆਂ ਸੇਵਾਵਾਂ (ਬੈਕਿੰਗ ਸੇਵਾਵਾਂ) - ਬੈਕਿੰਗ ਸੇਵਾਵਾਂ ਨੂੰ ਪਲੱਗੇਬਲ ਸਰੋਤਾਂ ਵਜੋਂ ਮੰਨੋ
5. ਬਣਾਓ, ਜਾਰੀ ਕਰੋ, ਚਲਾਓ - ਬਿਲਡ ਅਤੇ ਰਨ ਪੜਾਵਾਂ ਨੂੰ ਸਖਤੀ ਨਾਲ ਵੱਖ ਕਰੋ
6. ਪ੍ਰਕਿਰਿਆਵਾਂ - ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇੱਕ ਜਾਂ ਇੱਕ ਤੋਂ ਵੱਧ ਰਾਜ ਰਹਿਤ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਜੋਂ ਚਲਾਓ
7. ਪੋਰਟ ਬਾਈਡਿੰਗ - ਪੋਰਟ ਬਾਈਡਿੰਗ ਦੁਆਰਾ ਸੇਵਾਵਾਂ ਨਿਰਯਾਤ ਕਰੋ
8. ਸੰਜੋਗ - ਪ੍ਰਕਿਰਿਆਵਾਂ ਨਾਲ ਆਪਣੀ ਐਪ ਨੂੰ ਸਕੇਲ ਕਰੋ
9. ਡਿਸਪੋਸੇਬਿਲਟੀ - ਤੇਜ਼ ਸ਼ੁਰੂਆਤ ਅਤੇ ਸ਼ਾਨਦਾਰ ਬੰਦ ਨਾਲ ਭਰੋਸੇਯੋਗਤਾ ਨੂੰ ਵੱਧ ਤੋਂ ਵੱਧ ਕਰੋ
10. ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਮੈਂਟ/ਓਪਰੇਸ਼ਨ ਸਮਾਨਤਾ - ਵਿਕਾਸ, ਸਟੇਜਿੰਗ, ਅਤੇ ਉਤਪਾਦਨ ਦੇ ਵਾਤਾਵਰਣ ਨੂੰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਸਮਾਨ ਰੱਖੋ
11. ਲਾਗਿੰਗ - ਲੌਗ ਨੂੰ ਇਵੈਂਟਸ ਦੀ ਇੱਕ ਧਾਰਾ ਦੇ ਰੂਪ ਵਿੱਚ ਮੰਨੋ
12. ਪ੍ਰਸ਼ਾਸਨ ਦੇ ਕੰਮ - ਇੱਕ ਸਮੇਂ ਦੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨਾਲ ਪ੍ਰਸ਼ਾਸਨ/ਪ੍ਰਬੰਧਨ ਕਾਰਜ ਕਰੋ

12 ਕਾਰਕਾਂ ਬਾਰੇ ਵਧੇਰੇ ਜਾਣਕਾਰੀ ਲਈ, ਹੇਠਾਂ ਦਿੱਤੇ ਸਰੋਤ ਵੇਖੋ:

• ਅਧਿਕਾਰਤ ਸਰੋਤ - ਪੜ੍ਹਨਾ ਚਾਹੀਦਾ ਹੈ
• habr 'ਤੇ ਲੇਖ. ਬਾਰਾਂ-ਫੈਕਟਰ ਐਪ - ਬਾਰਾਂ-ਫੈਕਟਰ ਐਪ - ਅਧਿਕਾਰਤ ਅਨੁਵਾਦ
• habr 'ਤੇ ਲੇਖ. 7 ਫੈਕਟਰ ਐਪ ਵਿੱਚ 12 ​​ਲਾਪਤਾ ਕਾਰਕ - ਉਹਨਾਂ ਨੂੰ ਸੁਧਾਰਨ ਲਈ 12 ਕਾਰਕਾਂ 'ਤੇ ਇੱਕ ਤਾਜ਼ਾ ਨਜ਼ਰ.

ਬਲੂ-ਗਰੀਨ ਡਿਪਲਾਇਮੈਂਟ ਕੀ ਹੈ?

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

ਕਲਾਸਿਕ ਬੀਜੀ ਡਿਪਲੋਏ ਸਕੀਮ ਹੇਠਾਂ ਦਿੱਤੀ ਤਸਵੀਰ ਦੀ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ।

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

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

ਮਾੜੀ ਅਤੇ ਚੰਗੀ ਸਲਾਹ

ਬੇਦਾਅਵਾ: ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਉਦਾਹਰਣਾਂ ਉਪਯੋਗਤਾਵਾਂ / ਵਿਧੀਆਂ ਨੂੰ ਦਰਸਾਉਂਦੀਆਂ ਹਨ ਜੋ ਮੈਂ ਵਰਤਦਾ ਹਾਂ, ਤੁਸੀਂ ਸਮਾਨ ਫੰਕਸ਼ਨਾਂ ਦੇ ਨਾਲ ਬਿਲਕੁਲ ਕਿਸੇ ਵੀ ਵਿਕਲਪ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ।

ਜ਼ਿਆਦਾਤਰ ਉਦਾਹਰਣਾਂ PHP ਅਤੇ ਡੌਕਰ ਦੇ ਨਾਲ ਵੈਬ ਡਿਵੈਲਪਮੈਂਟ (ਕੀ ਹੈਰਾਨੀ ਦੀ ਗੱਲ ਹੈ) ਦੇ ਨਾਲ ਕਿਸੇ ਤਰ੍ਹਾਂ ਇਕ ਦੂਜੇ ਨੂੰ ਕੱਟਣਗੀਆਂ.

ਹੇਠਾਂ ਦਿੱਤੇ ਪੈਰਿਆਂ ਵਿੱਚ ਕੁਝ ਉਦਾਹਰਣਾਂ 'ਤੇ ਕਾਰਕਾਂ ਦੀ ਵਰਤੋਂ ਦਾ ਇੱਕ ਸਧਾਰਨ ਵਿਹਾਰਕ ਵਰਣਨ ਹੈ, ਜੇਕਰ ਤੁਸੀਂ ਇਸ ਵਿਸ਼ੇ 'ਤੇ ਹੋਰ ਸਿਧਾਂਤ ਪ੍ਰਾਪਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਮੂਲ ਸਰੋਤ ਦੇ ਉੱਪਰ ਦਿੱਤੇ ਲਿੰਕ ਵੇਖੋ।

1. ਕੋਡਬੇਸ

ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਇੱਕ ਸਰਵਰ ਤੇ ਫਾਈਲਾਂ ਅਪਲੋਡ ਕਰਨ ਲਈ FTP ਅਤੇ FileZilla ਦੀ ਵਰਤੋਂ ਕਰੋ, ਇੱਕ ਉਤਪਾਦਨ ਸਰਵਰ ਤੋਂ ਇਲਾਵਾ ਕਿਤੇ ਵੀ ਕੋਡ ਸਟੋਰ ਨਾ ਕਰੋ।

ਇੱਕ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਹਮੇਸ਼ਾਂ ਇੱਕ ਸਿੰਗਲ ਕੋਡ ਅਧਾਰ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਯਾਨੀ ਸਾਰੇ ਕੋਡ ਇੱਕ ਤੋਂ ਆਉਂਦੇ ਹਨ ਗਿੱਟ ਰਿਪੋਜ਼ਟਰੀ. ਸਰਵਰ (ਉਤਪਾਦਨ, ਸਟੇਜਿੰਗ, ਟੈਸਟ1, ਟੈਸਟ2 ...) ਇੱਕ ਸ਼ੇਅਰਡ ਰਿਪੋਜ਼ਟਰੀ ਦੀਆਂ ਸ਼ਾਖਾਵਾਂ ਤੋਂ ਕੋਡ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਇਸ ਤਰ੍ਹਾਂ, ਅਸੀਂ ਕੋਡ ਦੀ ਇਕਸਾਰਤਾ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ।

2. ਨਿਰਭਰਤਾ

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

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

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

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

3. ਸੰਰਚਨਾ

ਸੰਰਚਨਾਵਾਂ ਨੂੰ ਕੋਡ ਵਿੱਚ ਸਥਿਰਾਂਕ ਵਜੋਂ ਸਟੋਰ ਕਰੋ। ਟੈਸਟ ਸਰਵਰ ਲਈ ਵੱਖਰੇ ਸਥਿਰਾਂਕ, ਉਤਪਾਦਨ ਲਈ ਵੱਖਰੇ। if else constructs ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਪ੍ਰੋਜੈਕਟ ਦੇ ਵਪਾਰਕ ਤਰਕ ਵਿੱਚ ਵਾਤਾਵਰਣ ਦੇ ਅਧਾਰ ਤੇ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਕੰਮ ਨੂੰ ਸਿੱਧਾ ਬੰਨ੍ਹੋ।

ਸੰਰਚਨਾਵਾਂ - ਇਹ ਉਹੀ ਚੀਜ਼ ਹੈ ਜੋ ਪ੍ਰੋਜੈਕਟ (ਤੈਨਾਤੀ) ਦੀ ਤੈਨਾਤੀ ਵਿੱਚ ਵੱਖਰੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ, ਸੰਰਚਨਾ ਨੂੰ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲ (env vars) ਦੁਆਰਾ ਪਾਸ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਭਾਵ, ਭਾਵੇਂ ਤੁਸੀਂ ਕਈ ਸੰਰਚਨਾ ਫਾਈਲਾਂ .config.prod .config.local ਸਟੋਰ ਕਰਦੇ ਹੋ ਅਤੇ ਤੈਨਾਤੀ ਦੇ ਸਮੇਂ ਉਹਨਾਂ ਦਾ ਨਾਮ .config (ਮੁੱਖ ਸੰਰਚਨਾ ਜਿਸ ਤੋਂ ਐਪਲੀਕੇਸ਼ਨ ਡੇਟਾ ਪੜ੍ਹਦੀ ਹੈ) ਵਿੱਚ ਬਦਲਦੇ ਹੋ - ਇਹ ਸਹੀ ਪਹੁੰਚ ਨਹੀਂ ਹੋਵੇਗੀ, ਕਿਉਂਕਿ ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਸੰਰਚਨਾਵਾਂ ਤੋਂ ਜਾਣਕਾਰੀ ਸਾਰੇ ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਰਾਂ ਲਈ ਜਨਤਕ ਤੌਰ 'ਤੇ ਉਪਲਬਧ ਹੋਵੇਗੀ ਅਤੇ ਉਤਪਾਦਨ ਸਰਵਰ ਦੇ ਡੇਟਾ ਨਾਲ ਸਮਝੌਤਾ ਕੀਤਾ ਜਾਵੇਗਾ। ਸਾਰੀਆਂ ਸੰਰਚਨਾਵਾਂ ਨੂੰ ਡਿਪਲਾਇਮੈਂਟ ਸਿਸਟਮ (CI/CD) ਵਿੱਚ ਸਿੱਧਾ ਸਟੋਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਤੈਨਾਤੀ ਦੇ ਸਮੇਂ ਇੱਕ ਖਾਸ ਵਾਤਾਵਰਣ ਲਈ ਲੋੜੀਂਦੇ ਵੱਖ-ਵੱਖ ਮੁੱਲਾਂ ਦੇ ਨਾਲ ਵੱਖ-ਵੱਖ ਵਾਤਾਵਰਣਾਂ ਲਈ ਤਿਆਰ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

4. ਤੀਜੀ ਧਿਰ ਦੀਆਂ ਸੇਵਾਵਾਂ (ਬੈਕਿੰਗ ਸੇਵਾਵਾਂ)

ਵਾਤਾਵਰਣ 'ਤੇ ਸਖਤੀ ਨਾਲ ਬੰਨ੍ਹੋ, ਕੁਝ ਖਾਸ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਇੱਕੋ ਸੇਵਾਵਾਂ ਲਈ ਵੱਖ-ਵੱਖ ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ।

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

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

5. ਬਣਾਓ, ਜਾਰੀ ਕਰੋ, ਚਲਾਓ

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

ਸਾਰੇ ਤੈਨਾਤੀ ਪੜਾਅ ਇੱਕ ਦੂਜੇ ਤੋਂ ਵੱਖ ਕੀਤੇ ਜਾਣੇ ਚਾਹੀਦੇ ਹਨ.

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

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

6. ਪ੍ਰਕਿਰਿਆਵਾਂ

ਐਪਲੀਕੇਸ਼ਨ ਸਟੇਟ ਡੇਟਾ ਨੂੰ ਸਿੱਧਾ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਸਟੋਰ ਕਰੋ। ਐਪਲੀਕੇਸ਼ਨ ਦੀ RAM ਵਿੱਚ ਹੀ ਸੈਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਤੀਜੀ ਧਿਰ ਦੀਆਂ ਸੇਵਾਵਾਂ ਵਿਚਕਾਰ ਜਿੰਨਾ ਸੰਭਵ ਹੋ ਸਕੇ ਸਾਂਝਾ ਕਰੋ। ਇਸ ਤੱਥ 'ਤੇ ਬੰਨ੍ਹੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਸਿਰਫ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਸਕੇਲਿੰਗ ਦੀ ਆਗਿਆ ਨਾ ਦਿਓ।

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

7. ਪੋਰਟ ਬਾਈਡਿੰਗ

ਸਿਰਫ਼ ਵੈਬ ਸਰਵਰ ਨੂੰ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਤੀਜੀ-ਧਿਰ ਦੀਆਂ ਸੇਵਾਵਾਂ ਨਾਲ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਹੈ। ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਵੈਬ ਸਰਵਰ ਦੇ ਅੰਦਰ ਤੀਜੀ-ਧਿਰ ਦੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਵਧਾਉਣਾ ਬਿਹਤਰ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਅਪਾਚੇ ਵਿੱਚ ਇੱਕ PHP ਮੋਡੀਊਲ ਦੇ ਰੂਪ ਵਿੱਚ.
ਤੁਹਾਡੀਆਂ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਕਿਸੇ ਪਤੇ ਅਤੇ ਪੋਰਟ (ਲੋਕਲਗੋਸਟ:5432, ਲੋਕਲਹੋਸਟ:3000, nginx:80, php-fpm:9000) 'ਤੇ ਇੱਕ ਕਾਲ ਦੁਆਰਾ ਇੱਕ ਦੂਜੇ ਤੱਕ ਪਹੁੰਚਯੋਗ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਯਾਨੀ ਕਿ, nginx ਤੋਂ ਮੈਂ php-fpm ਅਤੇ ਦੋਵਾਂ ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦਾ ਹਾਂ। postgres, ਅਤੇ php-fpm ਤੋਂ postgres ਅਤੇ nginx ਤੱਕ, ਅਤੇ ਹਰੇਕ ਸੇਵਾ ਤੋਂ ਹੀ, ਮੈਂ ਕਿਸੇ ਹੋਰ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚ ਕਰ ਸਕਦਾ ਹਾਂ। ਇਸ ਤਰ੍ਹਾਂ, ਇੱਕ ਸੇਵਾ ਦੀ ਸਿਹਤ ਦੂਜੀ ਸੇਵਾ ਦੀ ਸਿਹਤ ਨਾਲ ਨਹੀਂ ਜੁੜੀ ਹੋਈ ਹੈ।

8. ਸਮਾਨਤਾ

ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਕੰਮ ਕਰੋ, ਅਤੇ ਫਿਰ ਅਚਾਨਕ ਕਈ ਪ੍ਰਕਿਰਿਆਵਾਂ ਇੱਕ ਦੂਜੇ ਦੇ ਨਾਲ ਪ੍ਰਾਪਤ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਣਗੀਆਂ!

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

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

9. ਡਿਸਪੋਸੇਬਿਲਟੀ

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

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

10. ਐਪਲੀਕੇਸ਼ਨ ਡਿਵੈਲਪਮੈਂਟ/ਓਪਰੇਸ਼ਨ ਸਮਾਨਤਾ

ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਉਤਪਾਦਨ, ਸਟੇਜਿੰਗ ਅਤੇ ਸਥਾਨਕ ਸੰਸਕਰਣ ਵੱਖਰਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਉਤਪਾਦਨ ਵਿੱਚ, ਸਾਡੇ ਕੋਲ Yii Lite ਫਰੇਮਵਰਕ ਹੈ, ਅਤੇ ਸਥਾਨਕ ਤੌਰ 'ਤੇ Yii, ਤਾਂ ਜੋ ਇਹ ਉਤਪਾਦਨ ਵਿੱਚ ਤੇਜ਼ੀ ਨਾਲ ਕੰਮ ਕਰੇ!

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

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

11. ਲੌਗਿੰਗ (ਲੌਗ)

ਅਸੀਂ ਫਾਈਲਾਂ ਅਤੇ ਡੇਟਾਬੇਸ ਨੂੰ ਲੌਗ ਲਿਖਦੇ ਹਾਂ! ਅਸੀਂ ਲੌਗਸ ਤੋਂ ਫਾਈਲਾਂ ਅਤੇ ਡੇਟਾਬੇਸ ਨੂੰ ਸਾਫ਼ ਨਹੀਂ ਕਰਦੇ ਹਾਂ। ਆਓ ਹੁਣੇ 9000 ਪੇਟਾ ਬਾਈਟਸ ਅਤੇ ਨਿਯਮਾਂ ਲਈ ਇੱਕ ਹਾਰਡ ਡਰਾਈਵ ਖਰੀਦੀਏ।

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

12. ਪ੍ਰਸ਼ਾਸਨ ਦੇ ਕੰਮ

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

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

PHP, Laravel, Laradock, Docker-Compose ਵਿੱਚ ਲਾਗੂ ਕਰਨ ਦੀ ਉਦਾਹਰਨ

PS ਸਾਰੀਆਂ ਉਦਾਹਰਣਾਂ MacOS 'ਤੇ ਬਣਾਈਆਂ ਗਈਆਂ ਸਨ। ਜ਼ਿਆਦਾਤਰ ਲੀਨਕਸ ਲਈ ਵੀ ਕੰਮ ਕਰਨਗੇ। ਮਾਫ਼ ਕਰਨਾ, ਵਿੰਡੋਜ਼ ਉਪਭੋਗਤਾ, ਪਰ ਮੈਂ ਲੰਬੇ ਸਮੇਂ ਤੋਂ ਵਿੰਡੋਜ਼ ਨਾਲ ਕੰਮ ਨਹੀਂ ਕੀਤਾ ਹੈ।

ਅਜਿਹੀ ਸਥਿਤੀ ਦੀ ਕਲਪਨਾ ਕਰੋ ਕਿ ਸਾਡੇ ਕੋਲ ਸਾਡੇ ਪੀਸੀ ਤੇ PHP ਦਾ ਕੋਈ ਸੰਸਕਰਣ ਸਥਾਪਤ ਨਹੀਂ ਹੈ ਅਤੇ ਕੁਝ ਵੀ ਨਹੀਂ ਹੈ.
ਡੌਕਰ ਅਤੇ ਡੌਕਰ-ਕੰਪੋਜ਼ ਦੇ ਨਵੀਨਤਮ ਸੰਸਕਰਣਾਂ ਨੂੰ ਸਥਾਪਿਤ ਕਰੋ। (ਇਹ ਔਨਲਾਈਨ ਲੱਭਿਆ ਜਾ ਸਕਦਾ ਹੈ)

docker -v && 
docker-compose -v

1. ਅਸੀਂ ਪਾਉਂਦੇ ਹਾਂ ਲਾਰਾਡੌਕ

git clone https://github.com/Laradock/laradock.git && 
ls

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

2. ਸਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕੰਮ ਕਰਨ ਲਈ ਲਾਰਾਡੌਕ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨਾ।

cd laradock && 
cp env-example .env

2.1 ਕਿਸੇ ਵੀ ਸੰਪਾਦਕ ਵਿੱਚ habr ਡਾਇਰੈਕਟਰੀ (ਪੇਰੈਂਟ ਫੋਲਡਰ ਜਿਸ ਵਿੱਚ laradock ਕਲੋਨ ਕੀਤਾ ਗਿਆ ਹੈ) ਨੂੰ ਖੋਲ੍ਹੋ। (ਮੇਰੇ PHPStorm ਕੇਸ ਵਿੱਚ)

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

2.2 ਅਸੀਂ ਵਰਕਸਪੇਸ ਚਿੱਤਰ ਨੂੰ ਲਾਂਚ ਕਰਦੇ ਹਾਂ। (ਤੁਹਾਡੇ ਕੇਸ ਵਿੱਚ, ਚਿੱਤਰ ਕੁਝ ਸਮੇਂ ਲਈ ਬਣਾਏ ਜਾਣਗੇ)
ਵਰਕਸਪੇਸ ਡਿਵੈਲਪਰ ਦੀ ਤਰਫੋਂ ਫਰੇਮਵਰਕ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ ਤਿਆਰ ਕੀਤੀ ਗਈ ਤਸਵੀਰ ਹੈ।

ਨਾਲ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਜਾਓ

docker-compose up -d workspace && 
docker-compose exec workspace bash

2.3 ਲਾਰਵੇਲ ਸਥਾਪਤ ਕਰਨਾ

composer create-project --prefer-dist laravel/laravel application

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

ls
exit
docker-compose down

2.5 ਅਸੀਂ PHPStorm ਤੇ ਵਾਪਸ ਆਉਂਦੇ ਹਾਂ ਅਤੇ .env ਫਾਈਲ ਵਿੱਚ ਸਾਡੀ ਲਾਰਵੇਲ ਐਪਲੀਕੇਸ਼ਨ ਲਈ ਸਹੀ ਮਾਰਗ ਸੈਟ ਕਰਦੇ ਹਾਂ।

3. Git ਵਿੱਚ ਸਾਰੇ ਕੋਡ ਸ਼ਾਮਲ ਕਰੋ।

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

echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin [email protected]:nzulfigarov/habr-12factor.git # здесь будет ссылка на ваш репо
git push -u origin master
git status

ਅਸੀਂ ਜਾਂਚ ਕਰਦੇ ਹਾਂ ਕਿ ਕੀ ਸਭ ਕੁਝ ਕ੍ਰਮ ਵਿੱਚ ਹੈ.

ਸਹੂਲਤ ਲਈ, ਮੈਂ ਗਿੱਟ ਲਈ ਕਿਸੇ ਕਿਸਮ ਦੇ ਵਿਜ਼ੂਅਲ ਇੰਟਰਫੇਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦਾ ਹਾਂ, ਮੇਰੇ ਕੇਸ ਵਿੱਚ ਇਹ ਹੈ ਗਿੱਟਕ੍ਰੇਕਨ. (ਇੱਥੇ ਰੈਫਰਲ ਲਿੰਕ)

4. ਲਾਂਚ ਕਰੋ!

ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਪੋਰਟ 80 ਅਤੇ 443 'ਤੇ ਕੁਝ ਵੀ ਲਟਕਿਆ ਨਹੀਂ ਹੈ।

docker-compose up -d nginx php-fpm

ਇਸ ਤਰ੍ਹਾਂ, ਸਾਡੇ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ 3 ਵੱਖਰੀਆਂ ਸੇਵਾਵਾਂ ਸ਼ਾਮਲ ਹਨ:

• nginx - ਵੈੱਬ ਸਰਵਰ
• php-fpm - ਵੈੱਬ ਸਰਵਰ ਤੋਂ ਬੇਨਤੀਆਂ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ php
• ਵਰਕਸਪੇਸ - ਡਿਵੈਲਪਰ ਲਈ php

ਇਸ ਸਮੇਂ, ਅਸੀਂ ਇਹ ਪ੍ਰਾਪਤ ਕੀਤਾ ਹੈ ਕਿ ਅਸੀਂ 4 ਵਿੱਚੋਂ 12 ਅੰਕਾਂ ਦੇ ਅਨੁਸਾਰੀ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਈ ਹੈ, ਅਰਥਾਤ:

1. ਕੋਡਬੇਸ - ਸਾਰਾ ਕੋਡ ਇੱਕ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਹੈ (ਇੱਕ ਛੋਟਾ ਜਿਹਾ ਨੋਟ: ਲਾਰਵੇਲ ਪ੍ਰੋਜੈਕਟ ਦੇ ਅੰਦਰ ਡੌਕਰ ਲਿਆਉਣਾ ਸਹੀ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹੈ)।

2. ਨਿਰਭਰਤਾਵਾਂ - ਸਾਡੀਆਂ ਸਾਰੀਆਂ ਨਿਰਭਰਤਾਵਾਂ ਸਪਸ਼ਟ ਤੌਰ 'ਤੇ application/composer.json ਵਿੱਚ ਅਤੇ ਹਰੇਕ ਕੰਟੇਨਰ ਦੀ ਹਰੇਕ ਡੌਕਰਫਾਈਲ ਵਿੱਚ ਲਿਖੀਆਂ ਗਈਆਂ ਹਨ।

3. ਤੀਜੀ ਧਿਰ ਦੀਆਂ ਸੇਵਾਵਾਂ (ਬੈਕਿੰਗ ਸੇਵਾਵਾਂ) - ਹਰੇਕ ਸੇਵਾ (php-fom, nignx, ਵਰਕਸਪੇਸ) ਆਪਣੀ ਖੁਦ ਦੀ ਜ਼ਿੰਦਗੀ ਜੀਉਂਦੀ ਹੈ ਅਤੇ ਬਾਹਰੋਂ ਜੁੜੀ ਹੁੰਦੀ ਹੈ ਅਤੇ ਇੱਕ ਸੇਵਾ ਨਾਲ ਕੰਮ ਕਰਦੇ ਸਮੇਂ, ਦੂਜੀ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਹੋਵੇਗੀ।

4. ਪ੍ਰਕਿਰਿਆਵਾਂ ਹਰ ਸੇਵਾ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਹੈ। ਹਰੇਕ ਸੇਵਾ ਅੰਦਰੂਨੀ ਸਥਿਤੀ ਨੂੰ ਸਟੋਰ ਨਹੀਂ ਕਰਦੀ ਹੈ।

5. ਪੋਰਟ ਬਾਈਡਿੰਗ

docker ps

ਜਿਵੇਂ ਕਿ ਅਸੀਂ ਦੇਖ ਸਕਦੇ ਹਾਂ, ਹਰੇਕ ਸੇਵਾ ਆਪਣੇ ਪੋਰਟ 'ਤੇ ਚੱਲ ਰਹੀ ਹੈ ਅਤੇ ਹੋਰ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਲਈ ਉਪਲਬਧ ਹੈ।

6. ਸੰਜੋਗ

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

ਕੰਟੇਨਰਾਂ ਨੂੰ ਰੋਕੋ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਝੰਡੇ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ -- ਸਕੇਲ

docker-compose down && 
docker-compose up -d --scale php-fpm=3 nginx php-fpm

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

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

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

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

 docker-compose logs -f

ਪਰ, ਇਸ ਵਿੱਚ ਇੱਕ ਕੈਚ ਹੈ ਕਿ PHP ਅਤੇ Nginx ਵਿੱਚ ਡਿਫਾਲਟ ਮੁੱਲ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਲੌਗ ਵੀ ਲਿਖਦੇ ਹਨ. 12 ਕਾਰਕਾਂ ਨੂੰ ਪੂਰਾ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਲੋੜ ਹੈ ਅਸਮਰੱਥ ਕਰੋ ਹਰੇਕ ਕੰਟੇਨਰ ਦੀ ਸੰਰਚਨਾ ਵਿੱਚ ਇੱਕ ਫਾਈਲ ਵਿੱਚ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਲੌਗ ਲਿਖਣਾ।

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

10. ਪ੍ਰਸ਼ਾਸਨ ਦੇ ਕੰਮ - ਸਾਰੇ ਪ੍ਰਸ਼ਾਸਨਿਕ ਕੰਮ ਕਾਰੀਗਰ ਟੂਲ ਦੇ ਧੰਨਵਾਦ ਨਾਲ ਲਾਰਵੇਲ ਦੁਆਰਾ ਹੱਲ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਜਿਵੇਂ ਕਿ 12 ਫੈਕਟਰ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਨਿਰਮਾਤਾ ਚਾਹੁੰਦੇ ਹਨ।

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

 
docker-compose exec workspace bash
php artisan list

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

11. ਸੰਰਚਨਾਵਾਂ ਅਤੇ 12. ਬਣਾਓ, ਜਾਰੀ ਕਰੋ, ਚਲਾਓ

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

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

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

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

ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਚਾਲੂ ਹੈ GitHub.
ਇਸ ਰਿਪੋਜ਼ਟਰੀ ਨੂੰ ਕਲੋਨ ਕਰਨ ਵੇਲੇ ਸਬਮੋਡਿਊਲ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨਾ ਨਾ ਭੁੱਲੋ।

PS: ਇਹ ਸਾਰੇ ਪਹੁੰਚ ਕਿਸੇ ਹੋਰ ਉਪਯੋਗਤਾਵਾਂ ਅਤੇ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਨਾਲ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ। ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਤੱਤ ਵੱਖਰਾ ਨਹੀਂ ਹੈ.

ਸਰੋਤ: www.habr.com