Bash ਅਤੇ shell ਸਕ੍ਰਿਪਟ ਅਜੇ ਵੀ CI ਨੌਕਰੀਆਂ, ਸਰਵਰ ਅਤੇ ਤੁਰੰਤ ਫਿਕਸ ਚਲਾਉਂਦੇ ਹਨ। ਜਾਣੋ ਇਹ ਕਿੱਥੇ ਚਮਕਦੇ ਹਨ, ਸੁਰੱਖਿਅਤ ਸਕ੍ਰਿਪਟ ਕਿਵੇਂ ਲਿਖਣੇ, ਅਤੇ ਕਦੋਂ ਹੋਰ ਟੂਲ ਵਰਤਣੇ ਚਾਹੀਦੇ ਹਨ।
ਜਦੋਂ ਲੋਕ “shell scripting” ਕਹਿਂਦੇ ਹਨ, ਤਾਂ ਉਹ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਛੋਟਾ ਪ੍ਰੋਗਰਾਮ ਲਿਖਣ ਨੂੰ ਦਰਸਾਉਂਦੇ ਹਨ ਜੋ ਆਮ ਆਰਡਰ-ਲਾਈਨ shell ਵਿੱਚ chalਦਾ ਹੈ। shell ਤੁਹਾਡੇ ਕਮਾਂਡਾਂ ਪੜ੍ਹਦਾ ਹੈ ਅਤੇ ਹੋਰ ਪ੍ਰੋਗਰਾਮ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। ਜ਼ਿਆਦਾਤਰ Linux ਸਰਵਰਾਂ 'ਤੇ, ਉਹ shell ਜਾਂ ਤਾਂ POSIX sh (ਇੱਕ ਸਟੈਂਡਰਡਾਈਜ਼ਡ ਬੇਸਲਾਈਨ) ਜਾਂ Bash (ਸਭ ਤੋਂ ਆਮ “sh-ਜੈਸੀ” shell ਸਹਿਯੋਗੀ ਫੀਚਰਾਂ ਨਾਲ) ਹੁੰਦਾ ਹੈ。
DevOps ਸ਼ਬਦ-ਭੰਡਾਰ ਵਿੱਚ, shell ਸਕ੍ਰਿਪਟਸ ਓS ਟੂਲਜ਼, ਕਲਾਉਡ CLI, ਬਿਲਡ ਟੂਲ ਅਤੇ ਕੰਫਿਗ ਫਾਈਲਾਂ ਨੂੰ ਜੋੜਨ ਵਾਲੀ patli glue ਪਰਤ ਹੁੰਦੇ ਹਨ।
Linux ਮਸ਼ੀਨਾਂ ਪਹਿਲਾਂ ਹੀ ਕੋਰ ਯੂਟਿਲਿਟੀਜ਼ ਨਾਲ ਆਉਂਦੀਆਂ ਹਨ (ਜਿਵੇਂ grep, sed, awk, tar, curl, systemctl). ਇੱਕ shell ਸਕ੍ਰਿਪਟ ਇਹਨਾਂ ਟੂਲਾਂ ਨੂੰ ਸਿੱਧਾ ਕਾਲ ਕਰ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਹੋਰ ਰਨਟਾਈਮ, ਪੈਕੇਜਾਂ ਜਾਂ ਨਿਰਭਰਤਾ ਜੋੜੇ—ਜੋ ਕਿ ਘੱਟ-ਇਮੇਜ, ਰਿਕਵਰੀ ਸ਼ੈੱਲ ਜਾਂ ਲੌਕਡ-ਡਾਉਨ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਬਹੁਤ ਲਾਭਦਾਇਕ ਹੈ।
Shell ਸਕ੍ਰਿਪਟਿੰਗ ਚਮਕਦੀ ਹੈ ਕਿਉਂਕਿ ਜ਼ਿਆਦਾਤਰ ਟੂਲ ਸਧਾਰਨ 컨ਟਰੈਕਟਫਾਲੋ ਕਰਦੇ ਹਨ:
cmd1 | cmd2).0 ਸਫਲਤਾ ਦਾ ਮਤਲਬ; ਨਾਨ-ਜ਼ੀਰੋ ਕਦੇ ਨਾਕਾਮੀ—ਆਟੋਮੇਸ਼ਨ ਲਈ ਬਹੁਤ ਅਹੰਕਾਰਪੂਰਨ।ਅਸੀਂ ਧਿਆਨ ਦੇਂਦੇ ਹਾਂ ਕਿ Bash/shell DevOps ਆਟੋਮੇਸ਼ਨ, CI/CD, ਕੰਟੇਨਰ, ਟ੍ਰਬਲਸ਼ੂਟਿੰਗ, ਪੋਰਟੇਬਿਲਿਟੀ ਅਤੇ ਸੁਰੱਖਿਆ ਅਭਿਆਸਾਂ 'ਚ ਕਿਵੇਂ ਫਿੱਟ ਹੁੰਦੇ ਹਨ। ਅਸੀਂ shell ਨੂੰ ਇੱਕ ਪੂਰੇ ਐਪ ਫਰੇਮਵਰਕ ਵਿੱਚ ਬਦਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਹੀਂ ਕਰਾਂਗੇ—ਜਦੋਂ ਉਸ ਦੀ ਲੋੜ ਹੋਵੇ ਅਸੀਂ ਹੋਰ ਬਿਹਤਰ ਵਿਕਲਪ ਚਿੱਠੀ ਵਿੱਚ ਦਰਸਾਊਂਗੇ (ਅਤੇ ਕਿਵੇਂ shell ਫਿਰ ਵੀ ਉਹਨਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਮਦਦ ਕਰਦਾ ਹੈ)।
Shell ਸਕ੍ਰਿਪਟਿੰਗ ਸਿਰਫ "ਲੇਗਸੀ ਗਲੂ" ਨਹੀਂ ਹੈ। ਇਹ ਇੱਕ ਛੋਟੀ, ਭਰੋਸੇਯੋਗ ਪਰਤ ਹੈ ਜੋ ਮੈਨੂਅਲ ਕਮਾਂਡ ਸਿੱਕੈਂਸਾਂ ਨੂੰ ਦੁਹਰਾਯੋਗ ਕਾਰਵਾਈਆਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦੀ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ ਸਰਵਰਾਂ, ਵਾਤਾਵਰਣਾਂ ਅਤੇ ਟੂਲਾਂ 'ਤੇ ਤੇਜ਼ੀ ਨਾਲ ਘੁੰਮ ਰਹੇ ਹੋ।
ਭਾਵੇਂ ਤੁਹਾਡਾ ਲੰਬੇ ਸਮੇਂ ਦਾ ਲੱਖ fully managed ਇਨਫਰਾਸਟ੍ਰੱਕਚਰ ਹੋਵੇ, ਅਕਸਰ ਇੱਕ ਮੁਹਿਰਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਇੱਕ ਹੋਸਟ ਤਿਆਰ ਕਰਨ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ: ਪੈਕੇਜ ਇੰਸਟਾਲ ਕਰਨਾ, ਕਨਫਿਗ ਡਰੌਪ ਕਰਨਾ, ਪਰਮੀਸ਼ਨ ਸੈੱਟ ਕਰਨਾ, ਯੂਜ਼ਰ ਬਣਾਉਣਾ, ਜਾਂ ਸੁਰੱਖਿਅਤ ਸੋਰਸ ਤੋਂ ਸੀਕ੍ਰੇਟ ਲੈ ਕੇ ਆਉਣਾ। ਇਹਨਾਂ ਇੱਕ-ਵਾਰੀ ਕੰਮਾਂ ਲਈ ਇੱਕ ਛੋਟਾ shell ਸਕ੍ਰਿਪਟ ਬਹਤਰੀਨ ਹੈ ਕਿਉਂਕਿ ਇਹ ਥਾਂ-ਕਿਸੇ ਵੀ ਥਾਂ ਚੱਲ ਸਕਦਾ ਹੈ ਜਿੱਥੇ shell ਅਤੇ SSH ਮੌਜੂਦ ਹਨ।
ਕਈ ਟੀਮਾਂ ਰਨਬੁੱਕ ਨੂੰ ਦਸਤਾਵੇਜ਼ ਵਜੋਂ ਰੱਖਦੀਆਂ ਹਨ, ਪਰ ਸਭ ਤੋਂ ਵਧੀਆ ਰਨਬੁੱਕ ਉਹ ਹਨ ਜੋ ਸਕ੍ਰਿਪਟਾਂ ਦੀ ਸ਼ਕਲ ਵਿੱਚ ਹੁੰਦੇ ਹਨ:
ਰਨਬੁੱਕ ਨੂੰ ਸਕ੍ਰਿਪਟ ਬਣਾਉਣ ਨਾਲ ਮਨੁੱਖੀ ਗਲਤੀ ਘਟਦੀ ਹੈ, ਨਤੀਜੇ ਜ਼ਿਆਦਾ ਲਗਾਤਾਰ ਹੋ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਹੈਂਡਆਫ ਸੁਧਰ ਜਾਂਦੇ ਹਨ।
ਜਦੋਂ ਇਨਸੀਡੈਂਟ ਆਉਂਦਾ ਹੈ, ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ ਪੂਰਾ ਐਪ ਜਾਂ ਡੈਸ਼ਬੋਰਡ ਨਹੀਂ ਚਾਹੁੰਦੇ—ਤੁਹਾਨੂੰ ਸਪਸ਼ਟਤਾ ਚਾਹੀਦੀ ਹੈ। grep, sed, awk, ਅਤੇ jq ਵਰਗੇ ਟੂਲਾਂ ਨਾਲ shell ਪਾਈਪਲਾਈਨ ਲਾਗਾਂ ਨੂੰ ਕੱਟਣ, ਆਉਟਪੁੱਟ ਤੁਲਨਾ ਕਰਨ ਅਤੇ ਨੋਡਾਂ 'ਤੇ ਪੈਟਰਨ ਵੇਖਣ ਲਈ ਹੁਣ ਵੀ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹਨ।
ਰੋਜ਼ਾਨਾ ਕੰਮ ਅਕਸਰ ਇਕੋ ਹੀ CLI ਕਦਮਾਂ ਨੂੰ dev, staging ਅਤੇ prod 'ਚ ਚਲਾਉਣ ਤੇ ਆਧਾਰਿਤ ਹੁੰਦਾ ਹੈ: artifacts ਨੂੰ ਟੈਗ ਕਰਨਾ, ਫਾਈਲਾਂ sync ਕਰਨਾ, ਸਥਿਤੀ ਜਾਂਚਣਾ, ਜਾਂ ਸੇਫ਼ ਰੋਲਆਊਟ ਕਰਨਾ। Shell ਸਕ੍ਰਿਪਟ ਇਹਨਾਂ ਵਰਕਫਲੋਜ਼ ਨੂੰ ਕੈਪਚਰ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਉਹ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਕਨਸਿਸਟੈਂਟ ਰਹਿਣ।
ਹਰ ਚੀਜ਼ ਸਾਫ਼-ਸੁਥਰੀ ਤਰੀਕੇ ਨਾਲ ਇੰਟੇਗਰੇਟ ਨਹੀਂ ਹੁੰਦੀ। Shell ਸਕ੍ਰਿਪਟ “ਟੂਲ A JSON ਨਿਕਲਦਾ ਹੈ” ਨੂੰ “ਟੂਲ B environment variables ਦੀ ਉਮੀਦ ਕਰਦਾ ਹੈ” ਨਾਲ ਜੋੜ ਸਕਦਾ ਹੈ, ਕਾਲਾਂ ਨੂੰ కొనసాగਾ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਗੁੰਮ ਹੋਏ ਚੈੱਕ ਅਤੇ ਰੀਟਰਾIES ਸ਼ਾਮਲ ਕਰ ਸਕਦਾ ਹੈ—ਇਹ ਸਭ ਨਵੀਆਂ ਇੰਟੇਗ੍ਰੇਸ਼ਨਾਂ ਜਾਂ ਪਲੱਗਇਨਾਂ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ।
Shell ਸਕ੍ਰਿਪਟਿੰਗ ਅਤੇ Terraform, Ansible, Chef, Puppet ਵਰਗੇ ਟੂਲ ਮਿਲਦੇ-ਜੁਲਦੇ ਸਮੱਸਿਆਵਾਂ ਹੱਲ ਕਰਦੇ ਹਨ, ਪਰ ਇਹ ਇਕ-ਜੈਸੇ ਨਹੀਂ ਹਨ।
IaC/ਕਨਫਿਗ ਮੈਨੇਜਮੈਂਟ ਨੂੰ ਸੋਚੋ ਜਿਵੇਂ ਕਿ ਸਿਸਟਮ ਆਫ ਰਿਕਾਰਡ: ਉਹ ਥਾਂ ਜਿੱਥੇ ਚਾਹੀਦਾ ਰਾਜ਼ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਸਮੀਖਿਆ ਹੁੰਦੀ ਹੈ, ਵਰਜ਼ਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਲਗਾਤਾਰ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। Terraform ਇਨਫਰਾਸਟ੍ਰੱਕਚਰ ਨੂੰ ਘੋਸ਼ਿਤ ਕਰਦਾ ਹੈ (ਨੈਟਵਰਕ, ਲੋਡ ਬੈਲੈਂਸਰ, ਡੇਟਾਬੇਸ)। Ansible/Chef/Puppet ਮਸ਼ੀਨ ਕੰਫਿਗਰੇਸ਼ਨ ਅਤੇ ਚੱਲ ਰਹੀ convergence ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਨ।
Shell ਸਕ੍ਰਿਪਟ ਆਮ ਤੌਰ 'ਤੇ ਗਲੂ ਕੋਡ ਹੁੰਦੇ ਹਨ: ਉਹ ਕਦਮਾਂ, ਟੂਲਾਂ ਅਤੇ ਵਾਤਾਵਰਣਾਂ ਨੂੰ ਜੋੜਨ ਵਾਲੀ patli ਪਰਤ ਹੈ। ਇੱਕ ਸਕ੍ਰਿਪਟ ਅੰਤੀਮ ਰਾਜ਼ ਨੂੰ “ਮਾਲਕ” ਨਹੀਂ ਕਰ ਸਕਦੀ, ਪਰ ਇਹ ਕਾਰਵਾਈਆਂ ਨੂੰ ਕੋਆਰਡੀਨੇਟ ਕਰਕੇ ਆਟੋਮੇਸ਼ਨ ਕਾਰਗਰ ਬਣਾਉਂਦੀ ਹੈ।
Shell ਬਹੁਤ ਵਧੀਆ ਸਾਥੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਇਹ ਚਾਹੀਦਾ ਹੈ:
ਉਦਾਹਰਨ: Terraform ਰਿਸੋਰਸ ਬਣਾਉਂਦਾ ਹੈ, ਪਰ ਇੱਕ Bash ਸਕ੍ਰਿਪਟ ਇੰਪੁੱਟਾਂ ਦੀ ਵੈਲੀਡੇਸ਼ਨ ਕਰਦਾ ਹੈ, ਸਹੀ ਬੈਕਐਂਡ ਮੌਜੂਦ ਹੋਣ ਦੀ ਯਕੀਨੀਤਾ ਕਰਦਾ ਹੈ, ਅਤੇ terraform plan + ਨੀਤੀ-ਚੈੱਕ ਚਲਾਉਂਦਾ ਹੈ ਪਹਿਲਾਂ ਕਿ apply ਕੀਤਾ ਜਾਵੇ।
Shell ਤੇਜ਼ ਤੌਰ 'ਤੇ ਲਾਗੂ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਘੱਟ ਨਿਰਭਰਤਾ ਰੱਖਦਾ ਹੈ—ਇਮਰਜੰਸੀ ਆਟੋਮੇਸ਼ਨ ਅਤੇ ਛੋਟੇ ਕੋਆਰਡੀਨੇਸ਼ਨ ਕੰਮਾਂ ਲਈ ਆਦਰਸ਼। ਘਟਕਾ ਇਹ ਹੈ ਕਿ ਲੰਬੀ ਮਿਆਦ ਦੀ ਗਵਰਨੈਂਸ ਉੱਤੇ: ਸਕ੍ਰਿਪਟ "ਮਿਨੀ ਪਲੇਟਫਾਰਮ" ਵਿੱਚ ਬਦਲ ਸਕਦੇ ਹਨ ਜਿੱਥੇ ਨਿਰੰਤਰ ਡਿੱਪਲੋਏਮੈਂਟ, ਘੱਟ idempotency ਅਤੇ ਸੀਮਿਤ ਆਡਿਟਿੰਗ ਹੁੰਦੀ ਹੈ।
ਵਿਆਵਹਾਰਿਕ ਨਿਯਮ: stateful, ਦੁਹਰਾਏ ਜਾਣ ਯੋਗ ਇਨਫਰਾਸਟ੍ਰੱਕਚਰ ਅਤੇ ਕੰਫਿਗਰੇਸ਼ਨ ਲਈ IaC/ਕਨਫਿਗ ਟੂਲ ਵਰਤੋ; ਉਹਨਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਛੋਟੇ, ਜੋੜਨਯੋਗ ਵਰਕਫਲੋਜ਼ ਲਈ shell ਵਰਤੋਂ। ਜਦੋਂ ਸਕ੍ਰਿਪਟ ਕਾਰੋਬਾਰੀ-ਆਧਾਰਿਕ ਬਣ ਜਾਵੇ, ਤਾਂ ਮੁੱਖ ਲੌਜਿਕ ਨੂੰ system-of-record ਟੂਲ ਵਿੱਚ ਮਾਈਗਰੇਟ ਕਰੋ ਅਤੇ shell ਨੂੰ ਰੈੱਪਰ ਹੀ ਰੱਖੋ।
CI/CD ਸਿਸਟਮ ਕਦਮਾਂ ਨੂੰ ਆਰਕੀਸਟਰੇਟ ਕਰਦੇ ਹਨ, ਪਰ ਉਹਨਾਂ ਨੂੰ ਅਜੇ ਵੀ ਕੁਝ ਚਾਹੀਦਾ ਹੈ ਜੋ ਅਸਲ ਕੰਮ ਕਰੇ। Bash (ਜਾਂ POSIX sh) ਡੀਫਾਲਟ ਗਲੂ ਰਹਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਜ਼ਿਆਦਾਤਰ ਰਨਰਾਂ 'ਤੇ ਉਪਲਬਧ ਹੁੰਦਾ ਹੈ, ਆਸਾਨੀ ਨਾਲ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਬਿਨਾਂ ਹੋਰ ਰਨਟਾਈਮ ਨਿਰਭਰਤਾਵਾਂ ਦੇ ਟੂਲਾਂ ਨੂੰ ਚੇਨ ਕਰ ਸਕਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ_PIPELINES shell ਕਦਮਾਂ ਨੂੰ ਅਨਗਣਿਤ ਪਰ ਅਹਿਮ ਕੰਮਾਂ ਲਈ ਵਰਤਦੇ ਹਨ: ਡਿਪੈਂਡੈਂਸੀਜ਼ ਇੰਸਟਾਲ ਕਰਨਾ, ਬਿਲਡ ਚਲਾਉਣਾ, ਆਉਟਪੁੱਟ ਪੈਕੇਜ ਕਰਨਾ, ਅਤੇ ਆਰਟੀਫੈਕਟ ਅਪਲੋਡ ਕਰਨਾ।
ਆਮ ਉਦਾਹਰਣ:
ਪਾਈਪਲਾਈਨ ਕਨਫਿਗਰੇਸ਼ਨ ਨੂੰ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲਾਂ ਰਾਹੀਂ ਪਾਸ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ shell ਸਕ੍ਰਿਪਟ ਕੁਦਰਤੀ ਤੌਰ 'ਤੇ ਉਹ ਮੁੱਲ ਰੂਟਰ ਬਣ ਜਾਂਦੇ ਹਨ। ਸੁਰੱਖਿਅਤ ਪੈਟਰਨ ਹੈ: ਸੀਕ੍ਰੇਟ env ਤੋਂ ਪੜ੍ਹੋ, ਕਦੇ ਵੀ echo ਨਾ ਕਰੋ, ਅਤੇ ਡਿਸ্ক 'ਤੇ ਉਹਨਾਂ ਨੂੰ ਨਾ ਲਿਖੋ।
ਪਸੰਦ ਕਰੋ:
set +x (ਤਾਂ ਜੋ ਕਮਾਂਡ ਪ੍ਰਿੰਟ ਨਾ ਹੋਵਣ)CI ਨੂੰ ਪੇਸ਼ਗੀ ਵਿਹਾਰ ਚਾਹੀਦਾ ਹੈ। ਚੰਗੀਆਂ ਪਾਈਪਲਾਈਨ ਸਕ੍ਰਿਪਟਾਂ:
ਕੈਸ਼ਿੰਗ ਅਤੇ ਪੈਰਲੇਲ ਕਦਮ ਆਮ ਤੌਰ 'ਤੇ CI ਸਿਸਟਮ ਦੁਆਰਾ ਨਿਯੰਤਰਿਤ ਹੁੰਦੇ ਹਨ, ਸਕ੍ਰਿਪਟ ਨਹੀਂ—Bash ਸਾਂਝੇ ਕੈਸ਼ਜ਼ ਨੂੰ ਜੋੜਕੇ ਭਰੋਸੇਯੋਗ ਤਰੀਕੇ ਨਾਲ ਸੰਭਾਲ ਨਹੀਂ ਸਕਦਾ। ਜੋ ਇਹ ਕਰ ਸਕਦਾ ਹੈ ਉਹ ਕੈਸ਼ ਕੀਜ਼ ਅਤੇ ਡਾਇਰੈਕਟਰੀਜ਼ ਨੂੰ ਸਥਿਰ ਬਨਾਉਣਾ ਹੈ।
ਟੀਂਮਾਂ ਵਿਚ ਸਕ੍ਰਿਪਟਸ ਪੜ੍ਹਨਯੋਗ ਰੱਖਣ ਲਈ, ਉਨ੍ਹਾਂ ਨੂੰ ਉਤਪਾਦੀ ਕੋਡ ਵਾਂਗ ਰੱਖੋ: ਛੋਟੇ ਫੰਕਸ਼ਨ, ਲਘੂ ਨਾਮਕਰਨ, ਅਤੇ ਇੱਕ ਛੋਟਾ ਯੂਜ਼ੇਜ ਹੈਡਰ। ਸਾਂਝੇ ਸਕ੍ਰਿਪਟਸ ਨੂੰ ਰੇਪੋ ਵਿੱਚ ਰੱਖੋ (ਉਦਾਹਰਨ ਲਈ /ci/) ਤਾਂ ਜੋ ਬਦਲਾਅ ਉਸ ਕੋਡ ਦੇ ਨਾਲ ਸਮੀਖਿਆ ਹੋਵੇ ਜਿਸਨੂੰ ਉਹ ਬਣਾਉਂਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡੀ ਟੀਮ ਲਗਾਤਾਰ "ਹੋਰ ਇੱਕ CI ਸਕ੍ਰਿਪਟ" ਲਿਖ ਰਹੀ ਹੈ, ਤਾਂ AI-ਸਹਾਇਤ ਵਰਕਫਲੋ ਲਾਭਦਾਇਕ ਹੋ ਸਕਦੀ ਹੈ—ਖਾਸ ਕਰਕੇ ਬੋਇਲਰਪਲੇਟ ਲਈ ਜਿਵੇਂ ਆਰਗਪਾਰਸਿੰਗ, retries, ਸੁਰੱਖਿਅਤ ਲੋਗਿੰਗ, ਅਤੇ ਗਾਰਡਰੇਲ। Koder.ai 'ਤੇ, ਤੁਸੀਂ pipeline ਕੰਮ ਨੂੰ ਸਧਾਰਨ ਭਾਸ਼ਾ ਵਿੱਚ ਵੇਰਵਾ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇੱਕ ਸ਼ੁਰੂਆਤੀ Bash/sh ਸਕ੍ਰਿਪਟ ਜਨਰੇਟ ਕਰ ਸਕਦੇ ਹੋ, ਫਿਰ planning mode ਵਿੱਚ ਇਟਰੇਟ ਕਰ ਸਕਦੇ ਹੋ ਪਹਿਲਾਂ ਕਿ ਤੁਸੀਂ ਚਲਾਓ। Koder.ai source code export, snapshots ਅਤੇ rollback ਨੂੰ ਸਪੋਰਟ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਸਕ੍ਰਿਪਟਸ ਨੂੰ ad-hoc ਨੁਕਸਾਨਾਂ ਦੀ ਜਗ੍ਹਾ ਸਮੀਖਿਆਯੋਗ ਆਰਟਿਫੈਕਟ ਵਜੋਂ ਰੱਖਣਾ ਆਸਾਨ ਹੋ ਜਾਂਦਾ ਹੈ।
Shell ਸਕ੍ਰਿਪਟਿੰਗ ਕੰਟੇਨਰ ਅਤੇ ਕਲਾਉਡ ਵਰਕਫਲੋਜ਼ ਵਿੱਚ ਇੱਕ ਵਿਆਵਹਾਰਿਕ ਗਲੂ ਪਰਤ ਰਹਿੰਦੀ ਹੈ ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੇ ਟੂਲ ਪਹਿਲਾਂ CLI ਪ੍ਰਦਾਨ ਕਰਦੇ ਹਨ। ਚਾਹੇ ਤੁਹਾਡੀ ਇਨਫਰਾ ਹੋਰ ਥਾਂ ਇਨ੍ਹਾਂ ਦੁਆਰਾ ਪਰਿਭਾਸ਼ਿਤ ਹੋਵੇ, ਤੁਸੀਂ ਅਜੇ ਵੀ ਛੋਟੇ, ਨਿਰਭਰਯੋਗ ਆਟੋਮੇਸ਼ਨ ਦੀ ਲੋੜ ਰੱਖਦੇ ਹੋ ਜੋ ਲਾਂਚ, ਵੈਰੀਫਾਈ, ਇਕੱਤਰ ਅਤੇ ਰਿਕਵਰ ਕਰਨ ਲਈ ਵਰਤੇ ਜਾਣ।
ਕੰਟੇਨਰ ਐਂਟਰੀਪੌਇੰਟ ਇੱਕ ਆਮ ਥਾਂ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ shell ਦੇਖੋਗੇ। ਛੋਟੇ ਸਕ੍ਰਿਪਟ:
ਕੀ ਕਰਨ ਦੀ ਚੀਜ਼ ਇਹ ਹੈ ਕਿ ਐਂਟਰੀਪੌਇੰਟ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਛੋਟੀ ਅਤੇ ਪੇਸ਼ਗੀ ਰੱਖੋ—ਸੈਟਅਪ ਕਰੋ, ਫਿਰ exec ਨਾਲ ਮੁੱਖ ਪ੍ਰਕਿਰਿਆ ਚਲਾਓ ਤਾਂ ਜੋ ਸਿਗਨਲ ਅਤੇ ਐਗਜ਼ਿਟ ਕੋਡ ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਵਰਤਣ।
ਦੈਨਿਕ Kubernetes ਕੰਮਾਂ ਲਈ ਅਕਸਰ ਹਲਕੇ ਸਹਾਇਕਾਂ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ: kubectl ਰੈੱਪਰ ਜੋ ਇਹ ਪੁਸ਼ਟੀ ਕਰਦੇ ਹਨ ਕਿ ਤੁਸੀਂ ਸਹੀ context/namespace 'ਤੇ ਹੋ, ਬਹੁਤ ਸਾਰੀਆਂ ਪੋਡਾਂ ਤੋਂ ਲਾਗ ਇਕੱਠੇ ਕਰਦੇ ਹਨ, ਜਾਂ ਇਨਸੀਡੈਂਟ ਦੌਰਾਨ ਹਾਲੀਆ ਘਟਨਾਵਾਂ ਲਿਆਉਂਦੇ ਹਨ।
ਉਦਾਹਰਣ ਵਜੋਂ, ਇੱਕ ਸਕ੍ਰਿਪਟ ਰਨ ਨਹੀਂ ਕਰੇਗਾ ਜੇ ਤੁਸੀਂ production 'ਤੇ pointed ਹੋ, ਜਾਂ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਲਾਗ ਨੂੰ ਇਕ ਇਕਾਈ ਆਰਟੀਫੈਕਟ ਵਿੱਚ ਬੰਡਲ ਕਰਕੇ ਟਿਕਟ ਲਈ ਦੇਵੇਗਾ।
AWS/Azure/GCP CLIs ਬੈਚ ਟਾਸਕਾਂ ਲਈ ਉਚਿਤ ਹਨ: ਰਿਸੋਰਸਾਂ ਨੂੰ ਟੈਗ ਕਰਨਾ, ਸੀਕ੍ਰੇਟ ਰੋਟੇਟ ਕਰਨਾ, ਇਨਵੈਂਟਰੀ ਨਿਰਯਾਤ ਕਰਨਾ, ਜਾਂ ਰਾਤ ਨੂੰ non-prod ਵਾਤਾਵਰਣ ਬੰਦ ਕਰਨਾ। Shell ਅਕਸਰ ਉਹਨਾਂ ਕਦਮਾਂ ਨੂੰ ਚੇਨ ਕਰਕੇ ਇਕ ਦੁਹਰਾਯੋਗ ਕਮਾਂਡ ਬਣਾਉਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੁੰਦਾ ਹੈ।
ਦੋ ਆਮ ਫੇਲ-ਪੁਆਇੰਟ brittle parsing ਅਤੇ ਅਣਵਿਸ਼ਵਾਸਨੀਯ APIs ਹਨ। ਸੰਭਾਵਿਤ ਤੌਰ 'ਤੇ ਸਟਰੱਕਚਰਡ ਆਉਟਪੁੱਟ ਨੂੰ ਤਰਜੀਹ ਦਿਓ:
--output json) ਅਤੇ jq ਨਾਲ ਪਰਸ ਕਰੋ, ਮਨੁੱਖ-ਪਾਠਯ ਫਾਰਮੈੱਟਡ ਟੇਬਲਾਂ ਤੇ grep ਕਰਨ ਦੀ ਬਜਾਏ।ਇੱਕ ਛੋਟੀ ਬਦਲੀ—JSON + jq, ਨਾਲ ਸਧਾਰਨ retry ਲੌਜਿਕ—"ਮੇਰੇ ਲੈਪਟੌਪ 'ਤੇ ਚਲਦਾ ਹੈ" ਸਕ੍ਰਿਪਟ ਨੂੰ ਇਕ ਦੋਹਰਾਯੋਗ ਆਟੋਮੇਸ਼ਨ ਵਿੱਚ ਬਦਲ ਦੇਂਦੀ ਹੈ।
ਜਦੋਂ ਕੁਝ ਟੁੱਟਦਾ ਹੈ, ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ ਨਵਾਂ ਟੂਲਚੇਨ ਨਹੀਂ ਚਾਹੀਦਾ—ਤੁਹਾਨੂੰ ਮਿੰਟਾਂ ਵਿੱਚ ਜਵਾਬ ਚਾਹੀਦਾ ਹੈ। Shell ਇਨਸੀਡੈਂਟ ਰਿਸਪਾਂਸ ਲਈ ਪਰਫੈਕਟ ਹੈ ਕਿਉਂਕਿ ਇਹ ਹੋਸਟ 'ਤੇ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੈ, ਚਲਾਉਣ ਵਿੱਚ ਤੇਜ਼ ਹੈ, ਅਤੇ ਛੋਟੇ, ਭਰੋਸੇਯੋਗ ਕਮਾਂਡਾਂ ਨੂੰ ਜੋੜ ਕੇ ਸਪਸ਼ਟ ਤਸਵੀਰ ਦਿਖਾ ਸਕਦਾ ਹੈ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਹੈ।
ਆਉਟੇਜ਼ ਦੌਰਾਨ, ਤੁਸੀਂ ਅਕਸਰ ਕੁਝ ਬੁਨਿਆਦੀ ਚੀਜ਼ਾਂ ਦੀ ਜਾਂਚ ਕਰ ਰਹੇ होते ਹੋ:
df -h, df -i)free -m, vmstat 1 5, uptime)ss -lntp, ps aux | grep ...)getent hosts name, dig +short name)curl -fsS -m 2 -w '%{http_code} %{time_total}\n' URL)Shell ਸਕ੍ਰਿਪਟ ਇਥੇ ਚਮਕਦੇ ਹਨ ਕਿਉਂਕਿ ਤੁਸੀਂ ਇਹ ਚੈੱਕ standardize ਕਰ ਸਕਦੇ ਹੋ, ਮਸ਼ੀਨਾਂ 'ਤੇ ਇਕਸਾਰਤਾ ਨਾਲ ਚਲਾ ਸਕਦੇ ਹੋ, ਅਤੇ ਨਤੀਜੇ ਆਪਣੇ ਇਨਸੀਡੈਂਟ ਚੈਨਲ ਵਿੱਚ ਬਿਨਾਂ ਹੱਥ-ਹਥਿਆਰ ਫਾਰਮੈਟਿੰਗ ਦੇ ਪੇਸਟ ਕਰ ਸਕਦੇ ਹੋ।
ਇੱਕ ਚੰਗਾ ਇਨਸੀਡੈਂਟ ਸਕ੍ਰਿਪਟ ਇੱਕ ਸਨੈਪਸ਼ਾਟ ਇਕੱਤਰ ਕਰਦਾ ਹੈ: ਟਾਈਮਸਟੈਂਪ, ਹੋਸਟਨੇਮ, kernel ਵਰਜ਼ਨ, ਹਾਲੀਆ ਲਾਗ, ਮੌਜੂਦਾ ਕਨੈਕਸ਼ਨ ਅਤੇ ਰਿਸੋਰਸ ਉਪਯੋਗ। ਉਹ "ਸਟੇਟ ਬੰਡਲ" ਫਾਇਰ ਬੁਝਣ ਤੋਂ ਬਾਅਦ ਰੂਟ-ਕਾਰਨ ਵਿਸਲੇਸ਼ਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
#!/usr/bin/env bash
set -euo pipefail
out="incident_$(hostname)_$(date -u +%Y%m%dT%H%M%SZ).log"
{
date -u
hostname
uname -a
df -h
free -m
ss -lntp
journalctl -n 200 --no-pager 2>/dev/null || true
} | tee "$out"
ਇਨਸੀਡੈਂਟ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਪਹਿਲਾਂ read-only ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ। “ਫਿਕਸ” ਕਾਰਵਾਈਆਂ ਨੂੰ explicit ਰੱਖੋ, ਪੁਸ਼ਟੀ-ਪ੍ਰੋੰਪਟ (ਜਾਂ --yes ਫਲੈਗ) ਨਾਲ ਅਤੇ ਇਹ ਸਪਸ਼ਟ ਦੱਸੋ ਕਿ ਕੀ ਬਦਲਣ ਵਾਲਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਸਕ੍ਰਿਪਟ ਰਿਸਪਾਂਡਰਾਂ ਨੂੰ ਤੇਜ਼ ਰਿਹਾ ਦਾ ਮਦਦ ਕਰਦਾ ਹੈ—ਬਿਨਾਂ ਇੱਕ ਦੂਜੇ ਇਨਸੀਡੈਂਟ ਪੈਦਾ ਕੀਤੇ।
ਪੋਰਟੇਬਿਲਿਟੀ ਉਸ ਸਮੇਂ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਹਾਡੀ ਆਟੋਮੇਸ਼ਨ "ਜੋ ਵੀ ਰਨਰ ਹੋਵੇ ਉਸ 'ਤੇ ਚਲਣੀ ਹੈ": ਘੱਟ-ਇਮੇਜ (Alpine/BusyBox), ਵੱਖ-ਵੱਖ Linux ਡਿਸਟਰੋਜ਼, CI ਇਮੇਜ, ਜਾਂ ਡੈਵਲਪਰ ਲੈਪਟੌਪ (macOS). ਸਭ ਤੋਂ ਵੱਡੀ ਤਕਲੀਫ਼ ਇਹ ਮੰਨਣਾ ਹੈ ਕਿ ਹਰ ਮਸ਼ੀਨ ਤੇ ਇੱਕੋ shell ਹੋਵੇ।
POSIX sh ਸਭ ਤੋਂ ਨੀਚਲਾ ਆਮ ਘੱਟਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ: ਬੇਸਿਕ ਵੇਰੀਏਬਲ, case, for, if, ਪਾਈਪਲਾਈਨਾਂ, ਅਤੇ ਸਧਾਰਨ ਫੰਕਸ਼ਨ। ਜਦੋਂ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਸਕ੍ਰਿਪਟ ਲਗਭਗ ਹਰ ਥਾਂ ਚੱਲੇ, ਤਾਂ ਤੁਸੀਂ ਇਹ ਚੁਣਦੇ ਹੋ।
Bash ਇੱਕ ਫੀਚਰ-ਰਿਚ ਸ਼ੈੱਲ ਹੈ ਜਿਸ ਵਿੱਚ ਸੁਵਿਧਾਵਾਂ ਹਨ ਜਿਵੇਂ ਐਰੇਜ਼, [[ ... ]] ਟੈਸਟ, process substitution (<(...)), set -o pipefail, ਵਿਸਤ੍ਰਿਤ globbing, ਅਤੇ ਬਿਹਤਰ ਸਟਰਿੰਗ ਹੈਂਡਲਿੰਗ। ਇਹ ਫੀਚਰ DevOps ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਤੇਜ਼ ਕਰਦੇ ਹਨ—ਪਰ ਜੇ /bin/sh Bash ਨਾ ਹੋਵੇ ਤਾਂ ਇਹ ਟੁੱਟ ਸਕਦੇ ਹਨ।
sh ਟਾਰਗੇਟ ਕਰੋ (Alpine ਦੀ ash, Debian dash, BusyBox)macOS 'ਤੇ ਵਰਤੋਂਕਾਰਾਂ ਕੋਲ ਡਿਫਾਲਟ Bash 3.2 ਹੋ ਸਕਦਾ ਹੈ, ਜਦਕਿ Linux CI ਇਮੇਜਾਂ ਵਿੱਚ Bash 5.x ਹੋਵੇ—ਇਸ ਲਈ “Bash ਸਕ੍ਰਿਪਟਸ” ਵੀ ਵਰਜ਼ਨ ਅੰਤਰਾਂ ਨਾਲ ਮੁਸ਼ਕਲ ਵਿੱਚ ਪਾ ਸਕਦੇ ਹਨ।
ਆਮ bashisms ਵਿੱਚ [[ ... ]], ਐਰੇਜ਼, source (. ਵਰਤੋਂ), ਅਤੇ echo -e ਵਿਵਹਾਰ ਅੰਤਰ ਸ਼ਾਮਲ ਹਨ। ਜੇ ਤੁਸੀਂ POSIX ਮਤਲਬ ਲੈ ਰਹੇ ਹੋ, ਤਾਂ ਇੱਕ ਅਸਲ POSIX shell (ਉਦਾਹਰਨ ਲਈ dash ਜਾਂ BusyBox sh) ਨਾਲ ਲਿੱਖੋ ਅਤੇ ਟੈਸਟ ਕਰੋ।
ਉਦੇਹਰਣ shebang:
#!/bin/sh
ਜਾਂ:
#!/usr/bin/env bash
ਫਿਰ ਰੇਪੋ ਵਿੱਚ ਮੰਗਾਂ (ਜਿਵੇਂ “requires Bash ≥ 4.0”) ਦੱਸੋ ਤਾਂ ਕਿ CI, ਕੰਟੇਨਰ ਅਤੇ ਟੀਮ ਮੈਂਬਰ aligned ਰਹਿਣ।
CI ਵਿੱਚ shellcheck ਚਲਾਓ ਤਾਂ ਜੋ bashisms, quoting ਗ਼ਲਤੀਆਂ, ਅਤੇ ਅਸੁਰੱਖਿਅਤ ਪੈਟਰਨ ਫਲੈਗ ਹੋ ਜਾਣ। ਇਹ “ਮੇਰੇ ਮਸ਼ੀਨ 'ਤੇ ਚੱਲਦਾ ਹੈ” ਫੇਲਿਆਨ ਨੂੰ ਰੋਕਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ। For setup ideas, link your team to a simple internal guide like /blog/shellcheck-in-ci.
Shell ਸਕ੍ਰਿਪਟ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰੋਡਕਸ਼ਨ ਸਿਸਟਮਾਂ, ਕਰੈਡੇੰਸ਼ਲ ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਲਾਗਾਂ ਤੱਕ ਪਹੁੰਚ ਰੱਖਦੇ ਹਨ। ਕੁਝ ਰੱਖਿਆਵਾਂ ਦੀ ਆਦਤ ਬਣਾਉਣਾ ਇਹ ਫ਼ਰਕ ਪੈਦਾ ਕਰਦੀ ਹੈ ਕਿ "ਹੱਥ-ਜੋੜੀ ਆਟੋਮੇਸ਼ਨ" ਇਕ ਇਨਸੀਡੈਂਟ ਬਣਨ ਨਾਲ ਪਹਿਲਾਂ।
ਕਈ ਟੀਮ ਸਕ੍ਰਿਪਟ ਨੂੰ ਇਹਨਾਂ ਨਾਲ ਸ਼ੁਰੂ ਕਰਦੀਆਂ ਹਨ:
set -euo pipefail
-e ਗਲਤੀਆਂ ਤੇ ਰੁਕਦਾ ਹੈ, ਪਰ if ਸ਼ਰਤਾਂ, while ਟੈਸਟਾਂ, ਅਤੇ ਕੁਝ ਪਾਈਪਲਾਈਨਾਂ ਵਿੱਚ ਤੁਹਾਨੂੰ ਹੈਰਾਨ ਕਰ ਸਕਦਾ ਹੈ। ਉਮੀਦਸ਼ੁਦਾ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਸਪਸ਼ਟ ਤਰੀਕੇ ਨਾਲ ਹੈਂਡਲ ਕਰੋ।-u unset ਵੇਰੀਏਬਲਾਂ ਨੂੰ ਗਲਤੀ ਮੰਨਦਾ ਹੈ—ਟਾਇਪੋ ਫੜਨ ਲਈ ਵਧੀਆ।pipefail ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਪਾਈਪਲਾਈਨ ਦੇ ਅੰਦਰ ਫੇਲ ਹੁੰਦੀ ਕਮਾਂਡ ਪੂਰੇ ਪਾਈਪਲਾਈਨ ਨੂੰ ਫੇਲ ਕਰਵੇ।ਜਦੋਂ ਤੁਸੀਂ ਇਰਾਦੇ ਨਾਲ ਕਿਸੇ ਕਮਾਂਡ ਨੂੰ ਅਸਫਲ ਹੋਣ ਦੇਣੇ ਹੋ, ਤਾਂ ਇਸਨੂੰ ਸਪਸ਼ਟ ਕਰੋ: command || true, ਜਾਂ ਬਿਹਤਰ, ਗਲਤੀ ਦੀ ਜਾਂਚ ਅਤੇ ਹੈਂਡਲ ਕਰੋ।
Unquoted ਵੇਰੀਏਬਲ word-splitting ਅਤੇ wildcard expansion ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ:
rm -rf $TARGET # ਖਤਰਨਾਕ
rm -rf -- "$TARGET" # ਸੁਰੱਖਿਅਤ
ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਖਾਸ ਤੌਰ 'ਤੇ splitting ਚਾਹੁੰਦੇ ਨਹੀਂ ਹੋ, ਹਮੇਸ਼ਾ ਵੇਰੀਏਬਲ ਨੂੰ quote ਕਰੋ। ਕਮਾਂਡ ਅਰਗੋਲ ਬਨਾਉਣ ਵੇਲੇ Bash ਵਿੱਚ ਐਰੇਜ਼ ਵਰਤਣਾ ਪਸੰਦ ਕਰੋ।
eval ਤੋਂ ਬਚੋ, ਘੱਟ ਤੋਂ ਘੱਟ ਅਧਿਕਾਰਪੈਰਾਮ, env vars, ਫਾਈਲ-ਨਾਮ ਅਤੇ ਕਮਾਂਡ ਆਉਟਪੁੱਟ ਨੂੰ ਅਣ-ਭਰੋਸੇਯੋਗ ਮਾਨੋ।
eval ਅਤੇ ਸਟਰਿੰਗ-ਰਚਿਤ ਕੋਡ ਤੋਂ ਬਚੋsudo ਦੀ ਥਾਂ ਇਕਲਾ ਕਮਾਂਡ ਲਈ sudo ਵਰਤੋecho, ਡੀਬਗ ਟ੍ਰੇਸ)set -x ਨਾਲ ਸੰਵੇਦਨਸ਼ੀਲ ਕਮਾਂਡਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਟਰੇਸ ਨੂੰ ਅਣਯੋਗ ਕਰੋਟੈਂਪ ਫਾਈਲਾਂ ਲਈ mktemp ਵਰਤੋ ਅਤੇ trap ਨਾਲ ਸਾਫ਼ਾਈ ਕਰੋ:
tmp="$(mktemp)"
trap 'rm -f "$tmp"' EXIT
-- ਨਾਲ option parsing ਖਤਮ ਕਰੋ (rm -- "$file") ਅਤੇ ਸੰਵੇਦਨਸ਼ੀਲ ਡੇਟਾ ਵਾਲੀਆਂ ਫਾਈਲਾਂ ਬਣਾਉਣ ਵੇਲੇ restrictive umask ਸੈੱਟ ਕਰੋ।
Shell ਸਕ੍ਰਿਪਟ ਅਕਸਰ ਇੱਕ ਤੁਰੰਤ ਫਿਕਸ ਵਜੋਂ ਸ਼ੁਰੂ ਹੁੰਦੇ ਹਨ, ਫਿਰ ਚੁਪਚਾਪ "ਪ੍ਰੋਡਕਸ਼ਨ" ਬਣ ਜਾਂਦੇ ਹਨ। Maintainability ਉਹ ਗੱਲ ਹੈ ਜੋ ਇਸਨੂੰ ਉਸੇ ਪ੍ਰੋਡਕਸ਼ਨ ਤੋਂ ਇੱਕ ਰਾਜ਼ਦਾਰ ਫਾਈਲ ਬਣਨ ਤੋਂ ਬਚਾਉਂਦੀ ਹੈ।
ਛੋਟੀ ਜਿਹੀ ਸੰਰਚਨਾ ਜ਼ਰੂਰੀ ਲਾਭ ਦਿੰਦੀ ਹੈ:
scripts/ (ਜਾਂ ops/) ਫੋਲਡਰ ਵਿੱਚ ਰੱਖੋ ਤਾਂ ਜੋ ਉਹ ਪਹੁੰਚਯੋਗ ਹੋਣbackup-db.sh, rotate-logs.sh, release-tag.sh) - ਅੰਦਰੂਨੀ ਜੋਕ ਨਾਂਸਕ੍ਰਿਪਟ ਦੇ ਅੰਦਰ, ਪਸੰਦ ਕਰੋ ਪਾਠਯੋਗ ਫੰਕਸ਼ਨ (ਛੋਟੇ, ਇੱਕ-ਉਦੇਸ਼) ਅਤੇ ਲਗਾਤਾਰ ਲੌਗਿੰਗ। ਇੱਕ ਸਧਾਰਨ log_info / log_warn / log_error ਪੈਟਰਨ ਟਰਬਲਸ਼ੂਟਿੰਗ ਤੇਜ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਅਣਸੰਯਮਿਤ echo ਸਪੈਮ ਤੋਂ ਬਚਾਉਂਦਾ ਹੈ।
ਇਕ -h/--help ਸਹਾਇਤਾ ਦਿਓ। ਇੱਕ ਮਿਨੀਮਲ ਯੂਸੇਜ ਸੁਨੇਹਾ ਵੀ ਸਕ੍ਰਿਪਟ ਨੂੰ ਸਮਰੱਥ ਕਰਦਾ ਹੈ ਜੋ ਟੀਮਮੇਟ ਭਰੋਸੇ ਨਾਲ ਚਲਾ ਸਕਦੇ ਹਨ।
Shell ਟੈਸਟ ਕਰਨਾ ਮੁਸ਼ਕਲ ਨਹੀਂ ਹੈ—ਸਿਰਫ਼ ਛੱਡਣਾ ਆਸਾਨ ਹੈ। ਹਲਕੇ-ਫੁਲਕੇ ਤਰੀਕੇ ਸ਼ੁਰੂ ਕਰੋ:
--dry-run) ਨਾਲ ਚਲਾ ਕੇ ਆਉਟਪੁੱਟ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹਨਟੈਸਟ ਨੂੰ ਇਨਪੁੱਟ/ਆਉਟਪੁੱਟ ਤੇ ਧਿਆਨ ਦਿਓ: ਆਰਗਜ਼, ਐਗਜ਼ਿਟ ਸਥਿਤੀ, ਲਾਗ ਪੰਗਤੀਆਂ, ਅਤੇ ਸਾਈਡ-ਇਫੈਕਟ (ਬਣੀ ਫਾਈਲਾਂ, ਕਮਾਂਡਾਂ ਜੋ ਚਲਾਈਆਂ ਗਈਆਂ)।
ਦੋ ਟੂਲ ਬਹੁਤ ਸਾਰੀਆਂ ਸਮੱਸਿਆਵਾਂ PR ਤੋਂ ਪਹਿਲਾਂ ਫੜ ਲੈਂਦੇ ਹਨ:
ਦੋਹਾਂ ਨੂੰ CI ਵਿੱਚ ਚਲਾਓ ਤਾਂ ਕਿ ਮਿਆਰ ਤੇ ਆਧਾਰ ਨਿਰਭਰ ਨਾ ਰਹੇ ਕਿ ਕੌਣ ਕੀ ਯਾਦ ਰੱਖਦਾ ਹੈ।
ਆਪਰੇਸ਼ਨਲ ਸਕ੍ਰਿਪਟ ਨੂੰ ਵਰਜ਼ਨਿੰਗ, ਕੋਡ-ਰੀਵਿਊ, ਅਤੇ ਚੇਂਜ-ਮੈਨੇਜਮੈਂਟ ਵਿਚ ਉਹੀ ਤਰੀਕੇ ਨਾਲ ਰੱਖੋ ਜਿਵੇਂ ਐਪ ਕੋਡ। ਬਦਲਾਅ ਲਈ PR ਲਾਜ਼ਮੀ ਕਰੋ, ਚੇਂਜਜ਼ ਨੂੰ ਕਮਿਟ ਸੰਦੇਸ਼ਾਂ ਵਿੱਚ ਦੱਸੋ, ਅਤੇ ਜਦੋਂ ਸਕ੍ਰਿਪਟ ਕਈ ਰਿਪੋ/ਟੀਮਾਂ ਦੁਆਰਾ ਵਰਤੀ ਜਾਂਦੀ ਹੋਵੇ ਤਾਂ ਸਧਾਰਨ ਵਰਜ਼ਨ ਟੈਗ ਸੋਚੋ।
ਭਰੋਸੇਯੋਗ ਇਨਫਰਾਸਟ੍ਰੱਕਚਰ ਸਕ੍ਰਿਪਟ predictable, safe to re-run, ਅਤੇ pressure 'ਤੇ ਪੜ੍ਹਨਯੋਗ ਹੁੰਦੇ ਹਨ। ਕੁਝ ਪੈਟਰਨ "ਮੇਰੇ ਮਸ਼ੀਨ 'ਤੇ ਚਲਦਾ ਹੈ" ਨੂੰ ਟੀਮ-ਪਸੰਦ ਆਟੋਮੇਸ਼ਨ ਵਿੱਚ ਬਦਲ ਦਿੰਦੇ ਹਨ।
ਮੰਨੋ ਕਿ ਸਕ੍ਰਿਪਟ ਦੁਬਾਰਾ ਚਲਾਈ ਜਾਵੇਗੀ—ਮਾਨਵ, cron, ਜਾਂ retrying CI job ਕਰਕੇ। "ensure state" ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਬਜਾਏ "action ਕਰੋ" ਦੇ।
mkdir -p ਨਾਲ ਡਾਇਰੈਕਟਰੀ ਬਣਾਓ, ਨਾ ਕਿ ਸਧਾਰਨ mkdirਸਰਲ ਨਿਯਮ: ਜੇ ਚਾਹੀਦਾ ਅੰਤ ਵਾਲਾ ਰਾਜ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੈ, ਤਾਂ ਸਕ੍ਰਿਪਟ ਸਫਲਤਾਪੂਰਵਕ ਬਿਨਾਂ ਵਾਧੂ ਕੰਮ ਤੋਂ ਬਾਹਰ ਨਿਕਲ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।
ਨੈਟਵਰਕ ਫੇਲ ਹੁੰਦੇ ਹਨ। ਰੇਜਿਸਟਰੀਜ਼ rate-limit ਕਰਦੀਆਂ ਹਨ। APIs ਟਾਇਮਆਉਟ ਹੁੰਦੇ ਹਨ। ਫਲੇਕੀ ਓਪਰੇਸ਼ਨਾਂ ਨੂੰ retries ਅਤੇ ਵਧ ਰਹੀ ਦੇਰੀਆਂ ਨਾਲ ਰੈਪ ਕਰੋ।
retry() {
n=0; max=5; delay=1
while :; do
"$@" && break
n=$((n+1))
[ "$n" -ge "$max" ] && return 1
sleep "$delay"; delay=$((delay*2))
done
}
ਆਟੋਮੇਸ਼ਨ ਲਈ, HTTP ਸਥਿਤੀ ਨੂੰ ਡੇਟਾ ਵਜੋਂ ਲਓ। curl -fsS (non-2xx 'ਤੇ fail, errors ਦਿਖਾਓ) ਨੂੰ ਤਰਜੀਹ ਦਿਓ ਅਤੇ ਲੋੜ ਹੋਵੇ ਤਾਂ ਸਥਿਤੀ ਨਹੀਂ ਰੱਖੋ।
resp=$(curl -sS -w "\n%{http_code}" -H "Authorization: Bearer $TOKEN" "$URL")
body=${resp%$'\n'*}; code=${resp##*$'\n'}
[ "$code" = "200" ] || { echo "API failed: $code" >&2; exit 1; }
ਜੇ ਤੁਹਾਨੂੰ JSON ਪਰਸ ਕਰਨੀ ਲੋੜ ਹੋਵੇ ਤਾਂ jq ਵਰਤੋਂ, fragile grep ਪਾਈਪਲਾਈਨਾਂ ਤੋਂ ਬਚੋ।
ਇੱਕੋ ਰਿਸੋਰਸ 'ਤੇ ਦੋ ਕਾਪੀਆਂ ਸਕ੍ਰਿਪਟਾਂ ਲੜ ਰਹੀਆਂ ਹੋਣ ਇੱਕ ਆਮ ਆਉਟੇਜ ਪੈਟਰਨ ਹੈ। ਜਦੋਂ ਉਪਲਬਧ ਹੋਵੇ flock ਵਰਤੋਂ, ਨਹੀਂ ਤਾਂ PID ਚੈੱਕ ਵਾਲੇ ਲੌਕਫ਼ਾਇਲ ਵਰਤੋ।
ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਲੌਗ ਕਰੋ (ਟਾਈਮਸਟੈਂਪ, ਕੁੰਜੀ ਕਾਰਵਾਈਆਂ), ਪਰ ਮਸ਼ੀਨ-ਰੀਡਏਬਲ ਮੋਡ (--json) ਵੀ ਦਿਓ। ਛੋਟਾ --json ਫਲੈਗ ਅਕਸਰ ਪਹਿਲੀ ਵਾਰੀ ਵਿੱਚ ਹੀ ਦਾ ਮੁੱਲ ਦਰਸਾਉਂਦਾ ਹੈ।
Shell ਗਲੂ ਭਾਸ਼ਾ ਲਈ ਬਹੁਤ ਵਧੀਆ ਹੈ: ਇਹ ਕਮਾਂਡਾਂ ਨੂੰ ਚੇਨ ਕਰਦਾ ਹੈ, ਫਾਈਲਾਂ ਹਿਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਮੌਜੂਦ ਟੂਲਾਂ ਨੂੰ ਕੋਆਰਡੀਨੇਟ ਕਰਦਾ ਹੈ। ਪਰ ਹਰ ਕਿਸਮ ਦੀ ਆਟੋਮੇਸ਼ਨ ਲਈ ਇਹ ਸਭ ਤੋਂ ਵਧੀਆ ਚੋਣ ਨਹੀਂ ਹੈ।
Shell ਤੋਂ ਅੱਗੇ ਜਾਓ ਜਦੋਂ ਸਕ੍ਰਿਪਟ ਲਗਦਾ ਹੋਵੇ ਕਿ ਉਹ ਇੱਕ ਛੋਟੇ ਐਪਲੀਕੇਸ਼ਨ ਵਾਂਗ ਤਬਦੀਲ ਹੋ ਰਿਹਾ ਹੈ:
if, ਅਸਥਾਇੀ ਫਲੈਗ, ਖਾਸ ਕੇਸ)Python ਵਧੀਆ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ APIs ਨਾਲ ਇੰਟੇਗ੍ਰੇਟ ਕਰ ਰਹੇ ਹੋ (ਕਲਾਉਡ ਪ੍ਰੋਵਾਈਡਰ, ਟਿਕਟਿੰਗ ਸਿਸਟਮ), JSON/YAML ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਹੋ, ਜਾਂ ਅਡਵਾਂਸਡ ਯੂਨਿਟ ਟੈਸਟ ਅਤੇ ਰੀਯੂਜ਼ੇਬਲ ਮੋਡੀਊਲ ਚਾਹੀਦੇ ਹਨ। ਜੇ ਤੁਹਾਡੇ “ਸਕ੍ਰਿਪਟ” ਨੂੰ ਅਸਲ error handling, ਰਿਚ ਲੌਗਿੰਗ ਅਤੇ ਸਟ੍ਰਕਚਰਡ configuration ਦੀ ਲੋੜ ਹੈ, ਤਾਂ Python ਆਮ ਤੌਰ 'ਤੇ fragile parsing ਨੂੰ ਘਟਾ ਦਿੰਦੀ ਹੈ।
Go single static binary, ਪ੍ਰਿਡਿਕਟੇਬਲ ਪਰਫਾਰਮੈਂਸ, ਅਤੇ ਮਜ਼ਬੂਤ ਟਾਈਪਿੰਗ ਲਈ ਵਧੀਆ ਹੈ। ਇਹ ਅੰਦਰੂਨੀ CLI ਟੂਲਾਂ ਲਈ ਆਦਰਸ਼ ਹੈ ਜੋ ਤੁਸੀਂ ਘੱਟ ਰਨਟਾਈਮ ਵਾਲੇ ਕੰਟੇਨਰਾਂ ਜਾਂ ਲੌਕਡ-ਡਾਊਨ ਹੋਸਟਾਂ 'ਤੇ ਚਲਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ।
ਪ੍ਰਾਇਗਮੈਟਿਕ ਪੈਟਰਨ shell ਨੂੰ ਇੱਕ ਰੈੱਪਰ ਵਜੋਂ ਵਰਤਣਾ ਹੈ:
ਇਹੀ ਥਾਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ਚੰਗੇ ਹੋ ਸਕਦੇ ਹਨ: ਤੁਸੀਂ workflow ਨੂੰ ਪਤਲੈ Bash ਰੈੱਪਰ ਵਜੋਂ ਪ੍ਰੋਟੋਟਾਈਪ ਕਰਦੇ ਹੋ, ਫਿਰ ਭਾਰੀ ਸੇਵਾ/ਟੂਲ (web, backend, mobile) ਲਈ scaffold ਜਾਂ ਜਨਰੇਟ ਕਰਦੇ ਹੋ। ਜਦੋਂ ਲੌਜਿਕ "ops script" ਤੋਂ "internal product" ਬਣੇ, ਤਾਂ source export ਕਰਕੇ ਅਤੇ ਆਪਣੇ ਨਾਰਮਲ ਰੇਪੋ/CI ਵਿੱਚ ਲਿਆਉਂਦੇ ਹੋ ਤਾਂ ਗਵਰਨੈਂਸ ਬਣੀ ਰਹਿੰਦੀ ਹੈ।
Shell ਚੁਣੋ ਜੇ ਇਹ ਮੁੱਖ ਤੌਰ 'ਤੇ: ਕਮਾਂਡਾਂ ਨੂੰ ਆਰਕੀਸਟਰੇਟ ਕਰਨਾ, ਛੋਟਾ-ਅਰਸਾ ਵਾਲਾ, ਅਤੇ ਟਰਮੀਨਲ ਵਿੱਚ ਟੈਸਟ ਕਰਨ ਲਈ ਆਸਾਨ ਹੈ।
ਕਿਸੇ ਹੋਰ ਭਾਸ਼ਾ ਨੂੰ ਚੁਣੋ ਜੇ ਤੁਹਾਨੂੰ: ਲਾਇਬ੍ਰੇਰੀਆਂ, ਸੰਰਚਿਤ ਡੇਟਾ, ਕ੍ਰਾਸ-ਪਲੇਟਫਾਰਮ ਸਹਾਇਤਾ, ਜਾਂ ਟੈਸਟਾਂ ਵਾਲਾ ਮੈਂਟੇਨੇਬਲ ਕੋਡ ਚਾਹੀਦਾ ਹੈ ਜੋ ਵਧੇਗਾ ਸਮੇਂ ਦੇ ਨਾਲ।
DevOps ਲਈ Bash ਸਿੱਖਣਾ ਸਭ ਤੋਂ ਵਧੀਆ ਉਸ ਸਮੇਂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਟੂਲਬੈਲਟ ਵਾਂਗ ਸੋਚੋ, ਨਾ ਕਿ ਇੱਕ ਭਾਸ਼ਾ ਜਿਸਨੂੰ ਤੁਸੀਂ ਇਕੱਤਰ ਰੂਪ ਵਿੱਚ "ਮਾਸਟਰ" ਕਰਨ ਵਾਲੇ ਹੋ। ਉਹ 20% ਚੀਜ਼ਾਂ 'ਤੇ ਧਿਆਨ ਦਿਓ ਜੋ ਤੁਸੀਂ ਹਫ਼ਤੇ ਵਿੱਚ ਵਰਤਦੇ ਹੋ, ਫਿਰ ਜਦੋਂ ਅਸਲੀ ਦੁਕ਼ਰ ਹੋਵੇ ਤਾਂ ਹੋਰ ਫੀਚਰ ਜੋੜੋ।
ਬੁਨਿਆਦੀ ਆਦੇਸ਼ ਅਤੇ ਉਹ ਨਿਯਮ ਜੋ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਪ੍ਰਭਾਸ਼ਿਤ ਬਣਾਉਂਦੇ ਹਨ:
ls, find, grep, sed, awk, tar, curl, jq (ਹਾਂ, ਇਹ shell ਨਹੀਂ—ਪਰ ਲਾਜ਼ਮੀ)|, >, >>, 2>, 2>&1, here-strings$?, set -e ਦੇ tradeoffs, ਅਤੇ explicit checks ਜਿਵੇਂ cmd || exit 1"$var", ਐਰੇਜ਼, ਅਤੇ ਜਦੋਂ word-splitting ਨੁਕਸਾਨ ਕਰਦਾ ਹੈfoo() { ... }, $1, $@, ਡਿਫ਼ਾਲਟ ਮੁੱਲਛੋਟੇ ਸਕ੍ਰਿਪਟ ਲਿਖੋ ਜੋ ਟੂਲਾਂ ਨੂੰ ਜੋੜਦੇ ਹਨ—ਵੱਡੇ ਐਪ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ।
ਹਰ ਹਫਤੇ ਇੱਕ ਛੋਟਾ ਪ੍ਰੋਜੈਕਟ ਚੁਣੋ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇਹ ਇੱਕ ਤਾਜ਼ਾ ਟਰਮੀਨਲ ਤੋਂ ਚੱਲਦਾ ਹੈ:
ਸ਼ੁਰੂ ਵਿੱਚ ਹਰ ਸਕ੍ਰਿਪਟ ~100 ਲਾਈਨਾਂ ਤੱਕ ਰੱਖੋ। ਜੇ ਇਹ ਵਧਦਾ ਹੈ, ਫੰਕਸ਼ਨਾਂ ਵਿੱਚ ਵੰਡੋ।
ਬੇਕਾਰ snippets ਦੀ ਥਾਂ ਪ੍ਰਾਇਮਰੀ ਸਰੋਤ ਵਰਤੋਂ:
man bash, help set, ਅਤੇ man testਇੱਕ ਸਧਾਰਣ starter template ਅਤੇ ਇੱਕ ਰੀਵਿਊ ਚੈੱਕਲਿਸਟ ਬਣਾਓ:
set -euo pipefail (ਜਾਂ ਦਸਤਾਵੇਜ਼ੀਕೃತ ਵਿਕਲਪ)trap ਲਈ cleanupਜਦੋਂ ਤੁਹਾਨੂੰ ਤੇਜ਼, ਪੋਰਟੇਬਲ ਗਲੂ ਦੀ ਲੋੜ ਹੋਵੇ—ਬਿਲਡ ਚਲਾਉਣ, ਸਿਸਟਮਾਂ ਦੀ ਜਾਂਚ ਕਰਨ, ਅਤੇ ਘੱਟ ਨਿਰਭਰਤਾਵਾਂ ਨਾਲ ਦੁਹਰਾਯੋਗ ਐਡਮਿਨ ਟਾਸਕ—ਤਦ shell ਸਕ੍ਰਿਪਟਿੰਗ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ।
ਜੇ ਤੁਸੀਂ ਕੁਝ ਸੁਰੱਖਿਆ ਡੀਫਾਲਟ (quoting, ਇਨਪੁੱਟ ਵੈਧਤਾ, retries, linting) ਕੇ ਰੂਪ ਵਿੱਚ ਸਥਾਪਿਤ ਕਰੋ, ਤਾਂ shell ਤੁਹਾਡੀ ਆਟੋਮੇਸ਼ਨ ਸਟੈਕ ਦਾ ਇੱਕ ਭਰੋਸੇਯੋਗ ਹਿੱਸਾ ਬਣ ਜਾਏਗਾ—ਨਾ ਕਿ ਨਾਜੁਕ ਨੁਕਤੇ-दਾਰ ਇਕ ਸੰਗ੍ਰਹਿ। ਅਤੇ ਜਦੋਂ ਤੁਸੀਂ “ਸਕ੍ਰਿਪਟ” ਨੂੰ “ਉਤਪਾਦ” ਵਿੱਚ ਬਦਲਣਾ ਚਾਹੋ, ਤਾਂ Koder.ai ਵਰਗੇ ਟੂਲ ਤੁਹਾਡੀ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ ਕਿ ਤੁਹਾਡੀ ਆਟੋਮੇਸ਼ਨ ਨੂੰ ਇੱਕ ਸੰਭਾਲਯੋਗ app ਜਾਂ ਅੰਦਰੂਨੀ ਟੂਲ ਵਿੱਚ ਵਿਕਸਤ ਕੀਤਾ ਜਾਵੇ, ਜਦੋਂ ਦੀ ਇਸਦਾ ਸਰੋਤ ਨਿਯੰਤਰਣ, ਸਮੀਖਿਆ ਅਤੇ rollback ਰੱਖਦੇ ਹੋ।
DevOps ਵਿੱਚ, ਇੱਕ shell ਸਕ੍ਰਿਪਟ ਆਮ ਤੌਰ 'ਤੇ ਗਲੂ ਕੋਡ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਛੋਟੀ ਪ੍ਰੋਗਰਾਮ ਜੋ ਮੌਜੂਦ ਟੂਲਾਂ ਨੂੰ (Linux ਯੂਟਿਲਿਟੀਆਂ, cloud CLIs, CI ਕਦਮ) ਪਾਈਪ, ਐਗਜ਼ਿਟ ਕੋਡ ਅਤੇ ਵਾਤਾਵਰਣ ਵੇਰੀਏਬਲਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਜੋੜਦਾ ਹੈ.
ਇਹ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ ਜਦੋਂ ਤੁਹਾਨੂੰ ਸਰਵਰਾਂ ਜਾਂ ਰਨਰਾਂ ਤੇ ਤੇਜ਼, ਘੱਟ-ਨਿਰਭਰਤਾ ਵਾਲੀ ਆਟੋਮੇਸ਼ਨ ਦੀ ਲੋੜ ਹੋਵੇ।
ਜਦੋਂ ਸਕ੍ਰਿਪਟ ਵੱਖ-ਵੱਖ ਵਾਤਾਵਰਣਾਂ 'ਤੇ ਚਲਣੀ ਚਾਹੀਦੀ ਹੈ (BusyBox/Alpine, ਘੱਟ-ਇਮੇਜ, ਅਣਜਾਣ CI ਰਨਰ), ਤਾਂ POSIX sh ਵਰਤੋ.
ਜਦੋਂ ਤੁਸੀਂ ਰਨਟਾਈਮ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਦੇ ਹੋ (ਆਪਣਾ CI ਇਮੇਜ, ops ਹੋਸਟ) ਜਾਂ ਤੁਹਾਨੂੰ ਉਹ ਫੀਚਰ ਚਾਹੀਦੇ ਹਨ ਜੋ Bash ਦਿੰਦਾ ਹੈ—ਜਿਵੇਂ [[ ... ]], ਐਰੇ, pipefail, ਜਾਂ ਪ੍ਰੋਸੈੱਸ ਸਬਸਟੀਟਿਊਸ਼ਨ—ਤਾਂ Bash ਵਰਤੋ.
ਇੰਟਰਪ੍ਰੀਟਰ ਨੂੰ shebang ਨਾਲ ਪਿਨ ਕਰੋ (ਉਦਾਹਰਨ: #!/bin/sh ਜਾਂ #!/usr/bin/env bash) ਅਤੇ ਲੋੜੀਂਦੇ ਵਰਜ਼ਨ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਦੱਸੋ।
ਕਿਉਂਕਿ ਇਹ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਹੈ: ਜ਼ਿਆਦਾਤਰ Linux ਇਮੇਜਾਂ ਵਿੱਚ ਇੱਕ shell ਅਤੇ ਕੋਰ ਯੂਟਿਲਿਟੀਆਂ (grep, sed, awk, tar, curl, systemctl) ਹੋਂਦੀਆਂ ਹਨ.
ਇਸ ਨਾਲ shell ਉਹਨਾਂ ਕੰਮਾਂ ਲਈ ਆਦਰਸ਼ ਬਣਦਾ ਹੈ:
IaC/ਕਨਫਿਗ ਟੂਲ ਅਕਸਰ ਸਿਸਟਮ ਆਫ ਰਿਕਾਰਡ ਹੁੰਦੇ ਹਨ (ਚਾਹੀਦਾ ਰਾਜ਼, ਸਮੀਖਿਆਯੋਗ ਬਦਲਾਅ, ਦੁਹਰਾਏ ਜਾ ਸਕਦੇ ਐਪਲਾਈ). Shell ਸਕ੍ਰਿਪਟ ਆਮ ਤੌਰ 'ਤੇ ਇਕ ਰੈੱਪਰ ਹੁੰਦੇ ਹਨ ਜੋ ਆਰਕੀਸਟਰੇਸ਼ਨ ਅਤੇ ਗਾਰਡਰੇਲ ਸ਼ਾਮਲ ਕਰਦੇ ਹਨ.
ਕੁਝ ਉਦਾਹਰਣ ਜਿੱਥੇ shell IaC ਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ:
plan/apply ਤੋਂ ਪਹਿਲਾਂ ਲੁੜੀਵਾਂ ਵੇਰੀਏਬਲ/ਕਰੈਡੇੰਸ਼ਲ ਦੀ ਜਾਂਚਉਨ੍ਹਾਂ ਨੂੰ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਪਰਿਭਾਸ਼ਿਤ ਵਿਹਾਰ ਭਰੋਸੇਮੰਦ ਹੈ:
set +x ਵਰਤੋjq ਨਾਲ JSON ਪਰਸ ਕਰੋ ਟੈਕਸਟ grep ਕਰਨ ਦੀ ਬਜੇਜੇ ਕੋਈ ਕਦਮ ਫਲੇਕੀ ਹੈ (ਨੈਟਵਰਕ/API), ਤਾਂ ਬੈਕਆਫ ਨਾਲ retries ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ ਹਾਰਡ ਫੇਲ ਕਰੋ ਜਦੋਂ ਥਕ ਜਾਏ।
ਐਂਟਰੀਪੌਇੰਟ ਸਕ੍ਰਿਪਟ ਛੋਟੇ ਅਤੇ ਨਿਰਭਰਯੋਗ ਰੱਖੋ:
exec ਕਰੋ ਤਾਂ ਜੋ ਸਿਗਨਲ ਅਤੇ ਐਗਜ਼ਿਟ ਕੋਡ ਠੀਕ ਮਿਲਨਲੰਬੇ-ਚੱਲਣ ਵਾਲੇ ਬੈਕਗ੍ਰਾਊਂਡ ਪ੍ਰੋਸੈੱਸ ਐਂਟਰੀਪੌਇੰਟ ਵਿੱਚ ਨਾਂ ਰੱਖੋ ਜਦ ਤੱਕ ਤੁਹਾਡੇ ਕੋਲ ਪ੍ਰਚਾਲਨ ਵਧੀਆਂ ਨਿਗਰਾਨੀ ਨਹੀਂ ਹੈ; ਨਹੀਂ ਤਾਂ ਸ਼ਟਡਾਊਨ ਅਤੇ ਰੀਸਟਾਰਟ ਬੇਹਦ ਅਣਵਿਸ਼ਵਾਸਨੀਯ ਹੋ ਸਕਦੇ ਹਨ।
ਆਮ ਗਲਤੀਆਂ:
/bin/sh ਹਰ ਜਗ੍ਹਾ Bash ਨਹੀਂ ਹੁੰਦਾ (dash, BusyBox)echo -e, sed -i, ਅਤੇ ਟੈਸਟ ਸਿੰਟੈਕਸ ਵੱਖ-ਵੱਖ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਕਿਵੇਂ ਵਰਤਦੇ ਹਨ ਵੱਖਰੇ ਹੋ ਸਕਦੇ ਹਨਜੇ ਪੋਰਟੇਬਿਲਿਟੀ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਤਾਂ ਨਿਸ਼ਚਿਤ ਟਾਰਗੇਟ ਸ਼ੈੱਲ (dash/BusyBox) ਨਾਲ ਟੈਸਟ ਕਰੋ ਅਤੇ CI ਵਿੱਚ ShellCheck ਚਲਾਓ ਤਾਂ ਜੋ “bashisms” ਪਹਿਲਾਂ ਹੀ ਫਸਲਣ।
ਇੱਕ ਮਜ਼ਬੂਤ ਬੇਸਲਾਇਨ ਇਹ ਹੈ:
set -euo pipefail
ਫਿਰ ਇਹ ਆਦਤਾਂ ਅਪਣਾਓ:
ਫਾਸਟ, ਇਕਸਾਰਤ ਨਿਰਣਿਆਂ ਲਈ ਛੋਟੇ ਸੈੱਟ ਨੂੰ ਮਿਆਰੀਕ੍ਰਿਤ ਕਰੋ ਅਤੇ ਆਉਟਪੁਟ ਨੂੰ ਟਾਈਮਸਟੈਂਪਸ ਦੇ ਨਾਲ ਰਿਕਾਰਡ ਕਰੋ.
ਆਮ ਚੈਕਸ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
ਦੋ ਟੂਲ ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਦੀਆਂ ਲੋੜਾਂ ਪੂਰੀ ਕਰ ਲੈਂਦੇ ਹਨ:
ਕੁਝ ਹਲਕੇ ਟੈਸਟ ਸ਼ਾਮਲ ਕਰੋ:
"$var" (word-splitting/globbing ਨੂੰ ਰੋਕਣ ਲਈ)eval ਤੋਂ ਬਚੋ ਅਤੇ ਸਟਰਿੰਗ-ਬਿਲਟ ਕਮਾਂਡਸ ਨੂੰ ਟਾਲੋ-- ਵਰਤੋਂ ਤਾਂ ਕਿ ਓਪਸ਼ਨ ਪਾਰਸਿੰਗ ਖਤਮ ਹੋ ਜਾਵੇ (ਜਿਵੇਂ rm -- "$file")mktemp + trap ਨਾਲ ਸੁਰੱਖਿਅਤ ਟੈਂਪ ਫਾਈਲਾਂ ਅਤੇ ਸੁੱਫਾਈ ਕਰੋset -e ਨਾਲ ਸਾਵਧਾਨ ਰਹੋ: ਉਮੀਦਸ਼ੁਦਾ ਫੇਲਿਆਨੂ cmd || true ਜਾਂ ਸਥਿਰ ਚੈੱਕ ਨਾਲ ਸਪਸ਼ਟ ਕਰੋ।
df -h, df -iuptime, free -m, vmstat 1 5ss -lntpjournalctl -n 200 --no-pagercurl -fsS -m 2 URL“ਪਹਿਲਾਂ read-only” ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਤਰਜੀਹ ਦਿਓ, ਅਤੇ ਕਿਸੇ ਵੀ ਲਿਖਣ-ਸਬੰਧੀ ਕਾਰਵਾਈ ਨੂੰ ਸਪਸ਼ਟ ਬਣਾਓ (ਪ੍ਰੋੰਪਟ ਜਾਂ --yes).
--dry-run ਮੋਡ)bats ਨਾਲ ਆਸਰਸ਼ਨਜ਼ਸਕ੍ਰਿਪਟਸ ਨੂੰ ਪਛਾਣਯੋਗ ਥਾਂ (ਜਿਵੇਂ scripts/ ਜਾਂ ops/) ਵਿੱਚ ਰੱਖੋ ਅਤੇ ਇਕ ਛੋਟੀ --help ਯੂਸੇਜ ਬਲਾਕ ਸ਼ਾਮਲ ਕਰੋ।