ਤੁਸੀਂ ਹੁਣ ਇੱਕ ਨਿਯਮਤ ਡੌਕਰਫਾਈਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਡੌਕਰ ਚਿੱਤਰਾਂ ਨੂੰ ਵਰਫ ਵਿੱਚ ਬਣਾ ਸਕਦੇ ਹੋ

ਕਦੇ ਨਾਲੋਂ ਦੇਰ ਨਾਲੋਂ ਬਿਹਤਰ। ਜਾਂ ਅਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਚਿੱਤਰ ਬਣਾਉਣ ਲਈ ਨਿਯਮਤ ਡੌਕਰਫਾਈਲਾਂ ਲਈ ਸਮਰਥਨ ਨਾ ਕਰਕੇ ਲਗਭਗ ਇੱਕ ਗੰਭੀਰ ਗਲਤੀ ਕਿਵੇਂ ਕੀਤੀ ਹੈ।

ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ werf — GitOps ਉਪਯੋਗਤਾ ਜੋ ਕਿਸੇ ਵੀ CI/CD ਸਿਸਟਮ ਨਾਲ ਏਕੀਕ੍ਰਿਤ ਹੁੰਦੀ ਹੈ ਅਤੇ ਪੂਰੇ ਐਪਲੀਕੇਸ਼ਨ ਲਾਈਫਸਾਈਕਲ ਦਾ ਪ੍ਰਬੰਧਨ ਪ੍ਰਦਾਨ ਕਰਦੀ ਹੈ, ਜਿਸ ਨਾਲ:

• ਚਿੱਤਰ ਇਕੱਠੇ ਕਰੋ ਅਤੇ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ,
• ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰੋ,
• ਵਿਸ਼ੇਸ਼ ਨੀਤੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਣਵਰਤੀਆਂ ਤਸਵੀਰਾਂ ਨੂੰ ਮਿਟਾਓ।

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

ਪਿਛੋਕੜ: ਤੁਹਾਡਾ ਆਪਣਾ ਚਿੱਤਰ ਕੁਲੈਕਟਰ

ਵਰਫ ਵਿੱਚ ਚਿੱਤਰ ਕੁਲੈਕਟਰ ਨਾਲ ਇਹੀ ਵਾਪਰਿਆ: ਆਮ ਡੌਕਰਫਾਈਲ ਸਾਡੇ ਲਈ ਕਾਫ਼ੀ ਨਹੀਂ ਸੀ। ਜੇ ਤੁਸੀਂ ਪ੍ਰੋਜੈਕਟ ਦੇ ਇਤਿਹਾਸ 'ਤੇ ਇੱਕ ਝਾਤ ਮਾਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਸਮੱਸਿਆ ਪਹਿਲਾਂ ਹੀ werf ਦੇ ਪਹਿਲੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਈ ਸੀ (ਫਿਰ ਅਜੇ ਵੀ dapp ਵਜੋਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ).

ਡੌਕਰ ਚਿੱਤਰਾਂ ਵਿੱਚ ਐਪਲੀਕੇਸ਼ਨ ਬਣਾਉਣ ਲਈ ਇੱਕ ਟੂਲ ਬਣਾਉਂਦੇ ਹੋਏ, ਅਸੀਂ ਜਲਦੀ ਹੀ ਮਹਿਸੂਸ ਕੀਤਾ ਕਿ ਡੌਕਰਫਾਈਲ ਕੁਝ ਖਾਸ ਕੰਮਾਂ ਲਈ ਸਾਡੇ ਲਈ ਢੁਕਵਾਂ ਨਹੀਂ ਸੀ:

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

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

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

ਰੂਬੀ ਵਿੱਚ ਡੈਪ ਲਈ ਪੁਰਾਣੀ ਸੰਰਚਨਾ

YAML 'ਤੇ werf ਲਈ ਮੌਜੂਦਾ ਸੰਰਚਨਾ

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

NB: ਇਸ ਸਮੇਂ, ਸਾਡਾ ਕੁਲੈਕਟਰ, ਜੋ ਆਪਣੀ ਖੁਦ ਦੀ ਸੰਰਚਨਾ (YAML ਵਿੱਚ) ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ ਸਟੈਪਲ ਕੁਲੈਕਟਰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਕਾਫ਼ੀ ਸ਼ਕਤੀਸ਼ਾਲੀ ਟੂਲ ਵਿੱਚ ਵਿਕਸਤ ਹੋ ਚੁੱਕਾ ਹੈ। ਇਸਦਾ ਵਿਸਤ੍ਰਿਤ ਵਰਣਨ ਵੱਖਰੇ ਲੇਖਾਂ ਦਾ ਹੱਕਦਾਰ ਹੈ, ਅਤੇ ਬੁਨਿਆਦੀ ਵੇਰਵੇ ਇਸ ਵਿੱਚ ਪਾਏ ਜਾ ਸਕਦੇ ਹਨ ਦਸਤਾਵੇਜ਼.

ਸਮੱਸਿਆ ਬਾਰੇ ਜਾਗਰੂਕਤਾ

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

ਇਸ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦੇਣ ਦੀ ਬਜਾਏ, ਅਸੀਂ ਇੱਕ ਹੱਲ ਪੇਸ਼ ਕਰਦੇ ਹਾਂ. ਉਦੋਂ ਕੀ ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਡੌਕਰਫਾਈਲ (ਜਾਂ ਡੌਕਰਫਾਈਲਾਂ ਦਾ ਇੱਕ ਸਮੂਹ) ਹੈ ਅਤੇ ਤੁਸੀਂ ਵਰਫ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ?

NB: ਵੈਸੇ, ਤੁਸੀਂ ਵਰਫ ਦੀ ਵਰਤੋਂ ਕਿਉਂ ਕਰਨਾ ਚਾਹੋਗੇ? ਮੁੱਖ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਗਈਆਂ ਹਨ:

• ਚਿੱਤਰ ਦੀ ਸਫਾਈ ਸਮੇਤ ਪੂਰਾ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰਬੰਧਨ ਚੱਕਰ;
• ਇੱਕ ਸਿੰਗਲ ਸੰਰਚਨਾ ਤੋਂ ਇੱਕ ਵਾਰ ਵਿੱਚ ਕਈ ਚਿੱਤਰਾਂ ਦੀ ਅਸੈਂਬਲੀ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦੀ ਯੋਗਤਾ;
• ਹੈਲਮ-ਅਨੁਕੂਲ ਚਾਰਟਾਂ ਲਈ ਸੁਧਾਰੀ ਤੈਨਾਤੀ ਪ੍ਰਕਿਰਿਆ।

ਉਹਨਾਂ ਦੀ ਇੱਕ ਹੋਰ ਪੂਰੀ ਸੂਚੀ ਇੱਥੇ ਲੱਭੀ ਜਾ ਸਕਦੀ ਹੈ ਪ੍ਰੋਜੈਕਟ ਪੰਨਾ.

ਇਸ ਲਈ, ਜੇ ਪਹਿਲਾਂ ਅਸੀਂ ਆਪਣੀ ਸੰਰਚਨਾ ਵਿੱਚ ਡੌਕਰਫਾਈਲ ਨੂੰ ਦੁਬਾਰਾ ਲਿਖਣ ਦੀ ਪੇਸ਼ਕਸ਼ ਕੀਤੀ ਹੁੰਦੀ, ਤਾਂ ਹੁਣ ਅਸੀਂ ਖੁਸ਼ੀ ਨਾਲ ਕਹਾਂਗੇ: "ਵਰਫ ਨੂੰ ਤੁਹਾਡੀਆਂ ਡੌਕਰਫਾਈਲਾਂ ਬਣਾਉਣ ਦਿਓ!"

ਕਿਸ ਨੂੰ ਵਰਤਣ ਲਈ?

ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਦਾ ਪੂਰਾ ਅਮਲ ਰੀਲੀਜ਼ ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਇਆ werf v1.0.3-beta.1. ਆਮ ਸਿਧਾਂਤ ਸਧਾਰਨ ਹੈ: ਉਪਭੋਗਤਾ werf ਸੰਰਚਨਾ ਵਿੱਚ ਇੱਕ ਮੌਜੂਦਾ ਡੌਕਰਫਾਈਲ ਦਾ ਮਾਰਗ ਦਰਸਾਉਂਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਕਮਾਂਡ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ werf build... ਅਤੇ ਇਹ ਹੀ ਹੈ - werf ਚਿੱਤਰ ਨੂੰ ਇਕੱਠਾ ਕਰੇਗਾ. ਆਓ ਇੱਕ ਅਮੂਰਤ ਉਦਾਹਰਨ ਵੇਖੀਏ।

ਆਓ ਅਗਲੇ ਦਾ ਐਲਾਨ ਕਰੀਏ Dockerfile ਪ੍ਰੋਜੈਕਟ ਰੂਟ ਵਿੱਚ:

FROM ubuntu:18.04
RUN echo Building ...

ਅਤੇ ਅਸੀਂ ਘੋਸ਼ਣਾ ਕਰਾਂਗੇ werf.yamlਜੋ ਇਸਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ Dockerfile:

configVersion: 1
project: dockerfile-example
---
image: ~
dockerfile: ./Dockerfile

ਸਾਰੇ! ਖੱਬੇ ਰਨ werf build:

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਤੁਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਐਲਾਨ ਕਰ ਸਕਦੇ ਹੋ werf.yaml ਇੱਕੋ ਸਮੇਂ ਵੱਖ-ਵੱਖ ਡੌਕਰਫਾਈਲਾਂ ਤੋਂ ਕਈ ਚਿੱਤਰ ਬਣਾਉਣ ਲਈ:

configVersion: 1
project: dockerfile-example
---
image: backend
dockerfile: ./dockerfiles/Dockerfile-backend
---
image: frontend
dockerfile: ./dockerfiles/Dockerfile-frontend

ਅੰਤ ਵਿੱਚ, ਇਹ ਵਾਧੂ ਬਿਲਡ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਪਾਸ ਕਰਨ ਦਾ ਵੀ ਸਮਰਥਨ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ --build-arg и --add-host - werf ਸੰਰਚਨਾ ਦੁਆਰਾ. ਡੌਕਰਫਾਈਲ ਚਿੱਤਰ ਸੰਰਚਨਾ ਦਾ ਪੂਰਾ ਵੇਰਵਾ ਇੱਥੇ ਉਪਲਬਧ ਹੈ ਦਸਤਾਵੇਜ਼ ਸਫ਼ਾ.

ਇਸ ਨੂੰ ਕੰਮ ਕਰਦਾ ਹੈ?

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

1. ਇੱਕ ਡੌਕਰਫਾਈਲ ਤੋਂ ਬਣਾਈ ਗਈ ਹਰੇਕ ਚਿੱਤਰ ਵਿੱਚ ਇੱਕ ਪੜਾਅ ਹੁੰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ dockerfile (ਤੁਸੀਂ ਇਸ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਕਿ werf ਵਿੱਚ ਕਿਹੜੇ ਪੜਾਅ ਹਨ ਇੱਥੇ).
2. ਸਟੇਜ ਲਈ dockerfile werf ਇੱਕ ਦਸਤਖਤ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ ਜੋ ਡੌਕਰਫਾਈਲ ਸੰਰਚਨਾ ਦੀ ਸਮੱਗਰੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਡੌਕਰਫਾਈਲ ਕੌਂਫਿਗਰੇਸ਼ਨ ਬਦਲਦੀ ਹੈ, ਤਾਂ ਪੜਾਅ ਦੇ ਦਸਤਖਤ ਬਦਲ ਜਾਂਦੇ ਹਨ dockerfile ਅਤੇ werf ਇੱਕ ਨਵੀਂ ਡੌਕਰਫਾਈਲ ਸੰਰਚਨਾ ਨਾਲ ਇਸ ਪੜਾਅ ਦੇ ਮੁੜ ਨਿਰਮਾਣ ਦੀ ਸ਼ੁਰੂਆਤ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਦਸਤਖਤ ਨਹੀਂ ਬਦਲਦੇ ਹਨ, ਤਾਂ werf ਕੈਸ਼ ਤੋਂ ਚਿੱਤਰ ਲੈਂਦਾ ਹੈ (werf ਵਿੱਚ ਦਸਤਖਤਾਂ ਦੀ ਵਰਤੋਂ ਬਾਰੇ ਵਧੇਰੇ ਵੇਰਵੇ ਵਿੱਚ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਸੀ ਇਸ ਰਿਪੋਰਟ).
3. ਅੱਗੇ, ਇਕੱਠੀਆਂ ਕੀਤੀਆਂ ਤਸਵੀਰਾਂ ਕਮਾਂਡ ਨਾਲ ਪ੍ਰਕਾਸ਼ਿਤ ਕੀਤੀਆਂ ਜਾ ਸਕਦੀਆਂ ਹਨ werf publish (ਜ werf build-and-publish) ਅਤੇ ਇਸਦੀ ਵਰਤੋਂ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਤੈਨਾਤੀ ਲਈ ਕਰੋ। ਡੌਕਰ ਰਜਿਸਟਰੀ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਚਿੱਤਰਾਂ ਨੂੰ ਸਟੈਂਡਰਡ ਵਰਫ ਕਲੀਨਅਪ ਟੂਲਸ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸਾਫ਼ ਕੀਤਾ ਜਾਵੇਗਾ, ਜਿਵੇਂ ਕਿ ਪੁਰਾਣੀਆਂ ਤਸਵੀਰਾਂ (N ਦਿਨਾਂ ਤੋਂ ਵੱਧ ਪੁਰਾਣੀਆਂ), ਗੈਰ-ਮੌਜੂਦ ਗਿਟ ਸ਼ਾਖਾਵਾਂ ਨਾਲ ਸਬੰਧਿਤ ਚਿੱਤਰ ਅਤੇ ਹੋਰ ਨੀਤੀਆਂ ਆਪਣੇ ਆਪ ਸਾਫ਼ ਹੋ ਜਾਣਗੀਆਂ।

ਇੱਥੇ ਵਰਣਿਤ ਬਿੰਦੂਆਂ ਬਾਰੇ ਹੋਰ ਵੇਰਵੇ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਲੱਭੇ ਜਾ ਸਕਦੇ ਹਨ:

• ਪਬਲਿਸ਼ਿੰਗ ਪ੍ਰਕਿਰਿਆ;
• ਕੁਬਰਨੇਟਸ ਤੈਨਾਤੀ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਏਕੀਕਰਣ;
• ਸਫਾਈ ਪ੍ਰਕਿਰਿਆ.

ਨੋਟਸ ਅਤੇ ਸਾਵਧਾਨੀਆਂ

1. ਬਾਹਰੀ URL ADD ਵਿੱਚ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ

ਵਰਤਮਾਨ ਵਿੱਚ ਇਹ ਇੱਕ ਨਿਰਦੇਸ਼ ਵਿੱਚ ਇੱਕ ਬਾਹਰੀ URL ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ ADD. ਜਦੋਂ ਨਿਸ਼ਚਿਤ URL 'ਤੇ ਸਰੋਤ ਬਦਲਦਾ ਹੈ ਤਾਂ Werf ਮੁੜ ਨਿਰਮਾਣ ਸ਼ੁਰੂ ਨਹੀਂ ਕਰੇਗਾ। ਅਸੀਂ ਜਲਦੀ ਹੀ ਇਸ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਜੋੜਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ।

2. ਤੁਸੀਂ ਚਿੱਤਰ ਵਿੱਚ .git ਸ਼ਾਮਲ ਨਹੀਂ ਕਰ ਸਕਦੇ

ਆਮ ਤੌਰ 'ਤੇ, ਇੱਕ ਡਾਇਰੈਕਟਰੀ ਜੋੜਨਾ .git ਚਿੱਤਰ ਵਿੱਚ - ਇੱਕ ਬੁਰਾ ਭੈੜਾ ਅਭਿਆਸ ਅਤੇ ਇੱਥੇ ਕਿਉਂ ਹੈ:

1. ਜੇ .git ਅੰਤਮ ਚਿੱਤਰ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਇਹ ਸਿਧਾਂਤਾਂ ਦੀ ਉਲੰਘਣਾ ਕਰਦਾ ਹੈ 12 ਫੈਕਟਰ ਐਪ: ਕਿਉਂਕਿ ਅੰਤਿਮ ਚਿੱਤਰ ਨੂੰ ਇੱਕ ਸਿੰਗਲ ਕਮਿਟ ਨਾਲ ਜੋੜਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਸ ਲਈ ਅਜਿਹਾ ਕਰਨਾ ਸੰਭਵ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ git checkout ਆਪਹੁਦਰੀ ਵਚਨਬੱਧਤਾ.
2. .git ਚਿੱਤਰ ਦਾ ਆਕਾਰ ਵਧਾਉਂਦਾ ਹੈ (ਰਿਪੋਜ਼ਟਰੀ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਵੱਡੀ ਹੋ ਸਕਦੀ ਹੈ ਕਿ ਵੱਡੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਇੱਕ ਵਾਰ ਇਸ ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਸੀ ਅਤੇ ਫਿਰ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਸੀ)। ਸਿਰਫ ਇੱਕ ਖਾਸ ਵਚਨਬੱਧਤਾ ਨਾਲ ਜੁੜੇ ਇੱਕ ਵਰਕ-ਟਰੀ ਦਾ ਆਕਾਰ ਗਿੱਟ ਵਿੱਚ ਸੰਚਾਲਨ ਦੇ ਇਤਿਹਾਸ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰੇਗਾ। ਇਸ ਕੇਸ ਵਿੱਚ, ਜੋੜ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਹਟਾਉਣਾ .git ਅੰਤਮ ਚਿੱਤਰ ਤੋਂ ਕੰਮ ਨਹੀਂ ਕਰੇਗਾ: ਚਿੱਤਰ ਅਜੇ ਵੀ ਇੱਕ ਵਾਧੂ ਪਰਤ ਪ੍ਰਾਪਤ ਕਰੇਗਾ - ਇਸ ਤਰ੍ਹਾਂ ਡੌਕਰ ਕੰਮ ਕਰਦਾ ਹੈ.
3. ਡੌਕਰ ਇੱਕ ਬੇਲੋੜੀ ਪੁਨਰ-ਨਿਰਮਾਣ ਦੀ ਸ਼ੁਰੂਆਤ ਕਰ ਸਕਦਾ ਹੈ, ਭਾਵੇਂ ਉਹੀ ਕਮਿਟ ਬਣਾਇਆ ਜਾ ਰਿਹਾ ਹੋਵੇ, ਪਰ ਵੱਖ-ਵੱਖ ਵਰਕ-ਟਰੀ ਤੋਂ। ਉਦਾਹਰਨ ਲਈ, GitLab ਵੱਖ-ਵੱਖ ਕਲੋਨ ਡਾਇਰੈਕਟਰੀਆਂ ਬਣਾਉਂਦਾ ਹੈ /home/gitlab-runner/builds/HASH/[0-N]/yourproject ਜਦੋਂ ਸਮਾਨਾਂਤਰ ਅਸੈਂਬਲੀ ਸਮਰੱਥ ਹੁੰਦੀ ਹੈ। ਵਾਧੂ reassembly ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਹੋਵੇਗਾ ਕਿ ਡਾਇਰੈਕਟਰੀ .git ਇੱਕੋ ਰਿਪੋਜ਼ਟਰੀ ਦੇ ਵੱਖ-ਵੱਖ ਕਲੋਨ ਕੀਤੇ ਸੰਸਕਰਣਾਂ ਵਿੱਚ ਵੱਖਰਾ ਹੈ, ਭਾਵੇਂ ਉਹੀ ਕਮਿਟ ਬਣਾਇਆ ਗਿਆ ਹੋਵੇ।

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

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

ਨਤੀਜਾ

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

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

ਇਸ ਲਈ, ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਅਚਾਨਕ ਕੁਝ ਡੌਕਰਫਾਈਲਾਂ ਪਈਆਂ ਹਨ ... ਕੋਸ਼ਿਸ਼ ਕਰੋ werf!

PS ਵਿਸ਼ੇ 'ਤੇ ਦਸਤਾਵੇਜ਼ਾਂ ਦੀ ਸੂਚੀ

• ਇੱਕ ਤੇਜ਼ ਸ਼ੁਰੂਆਤ ਲਈ ਗਾਈਡ;
• dockerfile ਬਿਲਡਰ ਸੰਰਚਨਾ;
• werf ਵਿੱਚ ਪੜਾਅ ਜੰਤਰ;
• ਚਿੱਤਰ ਪ੍ਰਕਾਸ਼ਨ ਪ੍ਰਕਿਰਿਆ;
• ਕੁਬਰਨੇਟਸ ਤੈਨਾਤੀ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਏਕੀਕਰਣ;
• ਸਫਾਈ ਪ੍ਰਕਿਰਿਆ;
• ਡੌਕਰਫਾਈਲ ਦੇ ਵਿਕਲਪ ਵਜੋਂ ਸਟੈਪਲ ਬਿਲਡਰ.

ਸਾਡੇ ਬਲੌਗ ਵਿੱਚ ਵੀ ਪੜ੍ਹੋ: "werf - ਕੁਬਰਨੇਟਸ ਵਿੱਚ CI / CD ਲਈ ਸਾਡਾ ਟੂਲ (ਸੰਖੇਪ ਅਤੇ ਵੀਡੀਓ ਰਿਪੋਰਟ)".

ਸਰੋਤ: www.habr.com