ਇੱਕ ਕੰਟੇਨਰ ਵਿੱਚ ਸਿਸਟਮਡ ਚੱਲ ਰਿਹਾ ਹੈ

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

ਇਸ ਲੇਖ ਵਿਚ ਅਸੀਂ ਦਿਖਾਵਾਂਗੇ ਕਿ ਸਮੇਂ ਦੇ ਨਾਲ ਕੀ ਬਦਲਿਆ ਹੈ ਅਤੇ ਪੋਡਮੈਨ ਇਸ ਮਾਮਲੇ ਵਿਚ ਸਾਡੀ ਕਿਵੇਂ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ।

ਇੱਕ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ systemd ਚਲਾਉਣ ਦੇ ਬਹੁਤ ਸਾਰੇ ਕਾਰਨ ਹਨ, ਜਿਵੇਂ ਕਿ:

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

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

ਪੋਡਮੈਨ ਦਾ ਆਉਣਾ

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

ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਅਜਿਹਾ ਕਰਦੇ ਹਨ।

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

ਪੋਡਮੈਨ ਜਾਣਦਾ ਹੈ ਕਿ ਸਿਸਟਮਡ ਨੂੰ ਕੰਟੇਨਰ ਵਿੱਚ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ ਕੀ ਕਰਨਾ ਹੈ। ਇਸਨੂੰ /run ਅਤੇ /tmp ਉੱਤੇ tmpfs ਨੂੰ ਮਾਊਂਟ ਕਰਨ ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਦੀ ਲੋੜ ਹੈ। ਉਹ "ਕੰਟੇਨਰਾਈਜ਼ਡ" ਵਾਤਾਵਰਣ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਣਾ ਪਸੰਦ ਕਰਦੀ ਹੈ ਅਤੇ cgroup ਡਾਇਰੈਕਟਰੀ ਦੇ ਆਪਣੇ ਹਿੱਸੇ ਅਤੇ /var/log/journald ਫੋਲਡਰ ਵਿੱਚ ਲਿਖਣ ਦੀ ਇਜਾਜ਼ਤ ਦੀ ਉਮੀਦ ਕਰਦੀ ਹੈ।

ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਕੰਟੇਨਰ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ ਜਿਸ ਵਿੱਚ ਪਹਿਲੀ ਕਮਾਂਡ init ਜਾਂ systemd ਹੁੰਦੀ ਹੈ, ਤਾਂ Podman ਆਟੋਮੈਟਿਕ ਹੀ tmpfs ਅਤੇ Cgroups ਨੂੰ ਸੰਰਚਿਤ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਇਹ ਯਕੀਨੀ ਬਣਾਇਆ ਜਾ ਸਕੇ ਕਿ systemd ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਇਸ ਆਟੋ ਲਾਂਚ ਮੋਡ ਨੂੰ ਬਲਾਕ ਕਰਨ ਲਈ, --systemd=false ਚੋਣ ਵਰਤੋ। ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਉ ਕਿ ਪੋਡਮੈਨ ਸਿਰਫ਼ systemd ਮੋਡ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਜਦੋਂ ਇਹ ਵੇਖਦਾ ਹੈ ਕਿ ਇਸਨੂੰ ਇੱਕ systemd ਜਾਂ init ਕਮਾਂਡ ਚਲਾਉਣ ਦੀ ਲੋੜ ਹੈ।

ਇੱਥੇ ਮੈਨੂਅਲ ਤੋਂ ਇੱਕ ਅੰਸ਼ ਹੈ:

ਆਦਮੀ ਪੌਡਮੈਨ ਰਨ
...

-systemd=true|false

ਸਿਸਟਮਡ ਮੋਡ ਵਿੱਚ ਇੱਕ ਕੰਟੇਨਰ ਚੱਲ ਰਿਹਾ ਹੈ। ਪੂਰਵ-ਨਿਰਧਾਰਤ ਤੌਰ 'ਤੇ ਸਮਰਥਿਤ।

ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਕੰਟੇਨਰ ਦੇ ਅੰਦਰ ਇੱਕ systemd ਜਾਂ init ਕਮਾਂਡ ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ Podman ਹੇਠ ਲਿਖੀਆਂ ਡਾਇਰੈਕਟਰੀਆਂ ਵਿੱਚ tmpfs ਮਾਊਂਟ ਪੁਆਇੰਟਾਂ ਦੀ ਸੰਰਚਨਾ ਕਰੇਗਾ:

/run, /run/lock, /tmp, /sys/fs/cgroup/systemd, /var/lib/journal

ਨਾਲ ਹੀ ਡਿਫੌਲਟ ਸਟਾਪ ਸਿਗਨਲ SIGRTMIN+3 ਹੋਵੇਗਾ।

ਇਹ ਸਭ systemd ਨੂੰ ਬਿਨਾਂ ਕਿਸੇ ਸੋਧ ਦੇ ਇੱਕ ਬੰਦ ਕੰਟੇਨਰ ਵਿੱਚ ਚਲਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ।

ਸੂਚਨਾ: systemd cgroup ਫਾਇਲ ਸਿਸਟਮ ਨੂੰ ਲਿਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, SELinux ਕੰਟੇਨਰਾਂ ਨੂੰ ਮੂਲ ਰੂਪ ਵਿੱਚ ਅਜਿਹਾ ਕਰਨ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਲਿਖਣ ਨੂੰ ਸਮਰੱਥ ਕਰਨ ਲਈ, ਕੰਟੇਨਰ_ਮੈਨੇਜ_ਸੀਗਰੁੱਪ ਬੂਲੀਅਨ ਪੈਰਾਮੀਟਰ ਨੂੰ ਸਮਰੱਥ ਕਰੋ:

setsebool -P ਕੰਟੇਨਰ_ਮੈਨੇਜ_ਸੀਗਰੁੱਪ ਸਹੀ

ਹੁਣ ਦੇਖੋ ਕਿ ਪੋਡਮੈਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਕੰਟੇਨਰ ਵਿੱਚ ਸਿਸਟਮਡ ਚਲਾਉਣ ਲਈ ਡੌਕਰਫਾਈਲ ਕਿਹੋ ਜਿਹੀ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

# cat Dockerfile

FROM fedora

RUN dnf -y install httpd; dnf clean all; systemctl enable httpd

EXPOSE 80

CMD [ "/sbin/init" ]

ਇਹ ਸਭ ਹੈ.

ਹੁਣ ਅਸੀਂ ਕੰਟੇਨਰ ਨੂੰ ਇਕੱਠਾ ਕਰਦੇ ਹਾਂ:

# podman build -t systemd .

ਅਸੀਂ SELinux ਨੂੰ Cgroups ਸੰਰਚਨਾ ਨੂੰ ਸੋਧਣ ਲਈ systemd ਨੂੰ ਆਗਿਆ ਦੇਣ ਲਈ ਕਹਿੰਦੇ ਹਾਂ:

# setsebool -P container_manage_cgroup true

ਤਰੀਕੇ ਨਾਲ, ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਇਸ ਕਦਮ ਬਾਰੇ ਭੁੱਲ ਜਾਂਦੇ ਹਨ. ਖੁਸ਼ਕਿਸਮਤੀ ਨਾਲ, ਇਹ ਸਿਰਫ ਇੱਕ ਵਾਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਸਿਸਟਮ ਨੂੰ ਰੀਬੂਟ ਕਰਨ ਤੋਂ ਬਾਅਦ ਸੈਟਿੰਗ ਨੂੰ ਸੁਰੱਖਿਅਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਹੁਣ ਅਸੀਂ ਕੰਟੇਨਰ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ:

# podman run -ti -p 80:80 systemd

systemd 239 running in system mode. (+PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)

Detected virtualization container-other.

Detected architecture x86-64.

Welcome to Fedora 29 (Container Image)!

Set hostname to <1b51b684bc99>.

Failed to install release agent, ignoring: Read-only file system

File /usr/lib/systemd/system/systemd-journald.service:26 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling.

Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.)

[  OK ] Listening on initctl Compatibility Named Pipe.

[  OK ] Listening on Journal Socket (/dev/log).

[  OK ] Started Forward Password Requests to Wall Directory Watch.

[  OK ] Started Dispatch Password Requests to Console Directory Watch.

[  OK ] Reached target Slices.

…

[  OK ] Started The Apache HTTP Server.

ਬੱਸ, ਸੇਵਾ ਚਾਲੂ ਅਤੇ ਚੱਲ ਰਹੀ ਹੈ:

$ curl localhost

<html  xml_lang="en" lang="en">

…

</html>

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

ਪੋਡਮੈਨ ਅਤੇ ਸਿਸਟਮਡ ਬਾਰੇ ਕੁਝ ਹੋਰ ਵਧੀਆ ਚੀਜ਼ਾਂ

ਪੌਡਮੈਨ ਸਿਸਟਮਡ ਯੂਨਿਟ ਫਾਈਲਾਂ ਵਿੱਚ ਡੌਕਰ ਨਾਲੋਂ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ

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

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

ਸਾਕਟ ਦੁਆਰਾ systemd ਨੂੰ ਸਰਗਰਮ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

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

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

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ ਪੌਡਮੈਨ-ਰਿਮੋਟ ਨਾਮਕ ਇੱਕ ਹੋਰ ਪੋਡਮੈਨ ਕਲਾਇੰਟ ਵਿਕਸਿਤ ਕਰ ਰਹੇ ਹਾਂ, ਜੋ ਉਹੀ ਪੋਡਮੈਨ CLI ਲਾਗੂ ਕਰਦਾ ਹੈ ਪਰ ਕੰਟੇਨਰਾਂ ਨੂੰ ਚਲਾਉਣ ਲਈ varlink ਨੂੰ ਕਾਲ ਕਰਦਾ ਹੈ। ਪੋਡਮੈਨ-ਰਿਮੋਟ SSH ਸੈਸ਼ਨਾਂ ਦੇ ਸਿਖਰ 'ਤੇ ਚੱਲ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਮਸ਼ੀਨਾਂ 'ਤੇ ਕੰਟੇਨਰਾਂ ਨਾਲ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਇੰਟਰੈਕਟ ਕਰ ਸਕਦੇ ਹੋ। ਸਮੇਂ ਦੇ ਨਾਲ, ਅਸੀਂ Linux ਦੇ ਨਾਲ MacOS ਅਤੇ Windows ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ ਪੌਡਮੈਨ-ਰਿਮੋਟ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਣ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ, ਤਾਂ ਜੋ ਉਹਨਾਂ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਡਿਵੈਲਪਰ ਇੱਕ ਲੀਨਕਸ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਨੂੰ ਚਲਾ ਸਕਣ ਜਿਸ ਵਿੱਚ Podman varlink ਚੱਲ ਰਿਹਾ ਹੈ ਅਤੇ ਪੂਰਾ ਅਨੁਭਵ ਹੈ ਕਿ ਕੰਟੇਨਰ ਲੋਕਲ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲ ਰਹੇ ਹਨ।

SD_NOTIFY

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

ਯੋਜਨਾਵਾਂ ਵਿੱਚ

ਅਸੀਂ ਪੌਡਮੈਨ ਜਨਰੇਟ systemd CONTAINERID ਕਮਾਂਡ ਨੂੰ ਜੋੜਨ ਦੀ ਯੋਜਨਾ ਬਣਾ ਰਹੇ ਹਾਂ, ਜੋ ਕਿ ਇੱਕ ਖਾਸ ਕੰਟੇਨਰ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਲਈ ਇੱਕ systemd ਯੂਨਿਟ ਫਾਈਲ ਤਿਆਰ ਕਰੇਗੀ। ਇਹ ਗੈਰ-ਅਧਿਕਾਰਤ ਕੰਟੇਨਰਾਂ ਲਈ ਰੂਟ ਅਤੇ ਰੂਟ ਰਹਿਤ ਮੋਡਾਂ ਵਿੱਚ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਅਸੀਂ OCI-ਅਨੁਕੂਲ systemd-nspawn ਰਨਟਾਈਮ ਲਈ ਇੱਕ ਬੇਨਤੀ ਵੀ ਵੇਖੀ ਹੈ।

ਸਿੱਟਾ

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

ਸਰੋਤ: www.habr.com