ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਵਿੱਚ ਇੱਕ ਪੁਰਾਣੀ ਵਿਸ਼ੇਸ਼ਤਾ ਸ਼ਾਖਾ ਨੂੰ ਹਟਾਉਣਾ

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

ਵਿਸ਼ੇਸ਼ਤਾ ਸ਼ਾਖਾਵਾਂ ਬਾਰੇ ਹੋਰ

ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਵਿਸ਼ੇਸ਼ਤਾ ਸ਼ਾਖਾਵਾਂ ਬਣਾਉਣ ਦਾ ਇੱਕ ਤਰੀਕਾ ਹੈ ਨਾਮ-ਸਥਾਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ। ਸੰਖੇਪ ਵਿੱਚ, ਉਤਪਾਦਨ ਸੰਰਚਨਾ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ:

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end
spec:
  replicas: 3
...

ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਸ਼ਾਖਾ ਲਈ, ਇੱਕ ਨੇਮਸਪੇਸ ਇਸਦੇ ਪਛਾਣਕਰਤਾ (ਉਦਾਹਰਨ ਲਈ, ਪੁੱਲ ਬੇਨਤੀ ਨੰਬਰ) ਅਤੇ ਕਿਸੇ ਕਿਸਮ ਦਾ ਅਗੇਤਰ/ਪੋਸਟਫਿਕਸ (ਉਦਾਹਰਨ ਲਈ, -ਪੀਆਰ-):

kind: Namespace
apiVersion: v1
metadata:
  name: habr-back-end-pr-17
...

kind: Deployment
apiVersion: apps/v1
metadata:
  namespace: habr-back-end-pr-17
spec:
  replicas: 1
...

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

$ kubectl get pods --all-namespaces | grep -e "-pr-"
NAMESPACE            ... AGE
habr-back-end-pr-264 ... 4d8h
habr-back-end-pr-265 ... 5d7h

ਤੁਸੀਂ ਇਸ ਬਾਰੇ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਕਿ ਵਿਸ਼ੇਸ਼ਤਾ ਸ਼ਾਖਾਵਾਂ ਨੂੰ ਇੱਕ ਕਲੱਸਟਰ ਵਿੱਚ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ ਇੱਥੇ и ਇੱਥੇ.

ਪ੍ਰੇਰਣਾ

ਚਲੋ ਨਿਰੰਤਰ ਏਕੀਕਰਣ (continuous integration):

1. ਅਸੀਂ ਬ੍ਰਾਂਚ ਲਈ ਇੱਕ ਨਵੀਂ ਵਚਨਬੱਧਤਾ ਨੂੰ ਧੱਕਦੇ ਹਾਂ.
2. ਬਿਲਡ 'ਤੇ, ਲਿੰਟਰ ਅਤੇ/ਜਾਂ ਟੈਸਟ ਚਲਾਏ ਜਾਂਦੇ ਹਨ।
3. ਕੁਬਰਨੇਟਸ ਪੁੱਲ ਬੇਨਤੀ ਸੰਰਚਨਾ ਫਲਾਈ 'ਤੇ ਤਿਆਰ ਕੀਤੀ ਜਾਂਦੀ ਹੈ (ਉਦਾਹਰਣ ਲਈ, ਇਸਦਾ ਨੰਬਰ ਤਿਆਰ ਟੈਮਪਲੇਟ ਵਿੱਚ ਪਾਇਆ ਜਾਂਦਾ ਹੈ)।
4. kubectl apply ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਸੰਰਚਨਾ ਨੂੰ ਕਲੱਸਟਰ (ਡਿਪਲਾਇ) ਵਿੱਚ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ।
5. ਪੁੱਲ ਬੇਨਤੀ ਨੂੰ ਮਾਸਟਰ ਬ੍ਰਾਂਚ ਵਿੱਚ ਮਿਲਾਇਆ ਜਾਂਦਾ ਹੈ।

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

ਕਿਵੇਂ ਵਰਤਣਾ ਹੈ

ਹੇਠ ਦਿੱਤੀ ਕਮਾਂਡ ਨਾਲ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਸਥਾਪਿਤ ਕਰੋ:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml

ਹੇਠ ਦਿੱਤੀ ਸਮੱਗਰੀ ਦੇ ਨਾਲ ਇੱਕ ਫਾਈਲ ਬਣਾਓ ਅਤੇ ਦੁਆਰਾ ਸਥਾਪਿਤ ਕਰੋ kubectl apply -f:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 3

ਪੈਰਾਮੀਟਰ ਨੇਮਸਪੇਸ ਸਬਸਟ੍ਰਿੰਗ ਹੋਰ ਨੇਮਸਪੇਸਾਂ ਤੋਂ ਪੁੱਲ ਬੇਨਤੀਆਂ ਲਈ ਨੇਮਸਪੇਸ ਫਿਲਟਰ ਕਰਨ ਦੀ ਲੋੜ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਕਲੱਸਟਰ ਵਿੱਚ ਹੇਠਾਂ ਦਿੱਤੇ ਨਾਮ-ਸਥਾਨਾਂ ਹਨ: habr-back-end, habr-front-end, habr-back-end-pr-17, habr-back-end-pr-33, ਫਿਰ ਹਟਾਉਣ ਲਈ ਉਮੀਦਵਾਰ ਹੋਣਗੇ habr-back-end-pr-17, habr-back-end-pr-33.

ਪੈਰਾਮੀਟਰ afterDaysWithoutDeploy ਪੁਰਾਣੇ ਨੇਮਸਪੇਸ ਨੂੰ ਮਿਟਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਜੇਕਰ ਨੇਮਸਪੇਸ ਬਣਾਇਆ ਗਿਆ ਹੈ 3 дня 1 час ਵਾਪਸ, ਅਤੇ ਪੈਰਾਮੀਟਰ ਦਰਸਾਉਂਦਾ ਹੈ 3 дня, ਇਸ ਨੇਮਸਪੇਸ ਨੂੰ ਮਿਟਾ ਦਿੱਤਾ ਜਾਵੇਗਾ। ਇਹ ਉਲਟ ਦਿਸ਼ਾ ਵਿੱਚ ਵੀ ਕੰਮ ਕਰਦਾ ਹੈ ਜੇਕਰ ਨੇਮਸਪੇਸ ਬਣਾਇਆ ਗਿਆ ਹੈ 2 дня 23 часа ਵਾਪਸ, ਅਤੇ ਪੈਰਾਮੀਟਰ ਦਰਸਾਉਂਦਾ ਹੈ 3 дня, ਇਸ ਨੇਮਸਪੇਸ ਨੂੰ ਮਿਟਾਇਆ ਨਹੀਂ ਜਾਵੇਗਾ।

ਇੱਕ ਹੋਰ ਪੈਰਾਮੀਟਰ ਹੈ, ਇਹ ਇਸ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ ਕਿ ਕਿੰਨੀ ਵਾਰ ਸਾਰੇ ਨਾਮ-ਸਥਾਨਾਂ ਨੂੰ ਸਕੈਨ ਕਰਨਾ ਹੈ ਅਤੇ ਬਿਨਾਂ ਤੈਨਾਤੀ ਦੇ ਦਿਨਾਂ ਦੀ ਜਾਂਚ ਕਰਨੀ ਹੈ - ਹਰ ਮਿੰਟ ਦੀ ਜਾਂਚ ਕਰੋ. ਮੂਲ ਰੂਪ ਵਿੱਚ ਇਹ ਬਰਾਬਰ ਹੈ 30 минутам.

ਇਹ ਕੰਮ ਕਰਦਾ ਹੈ

ਅਭਿਆਸ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਲੋੜ ਹੋਵੇਗੀ:

1. ਡੌਕਰ ਇੱਕ ਅਲੱਗ-ਥਲੱਗ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕੰਮ ਕਰਨ ਲਈ।
2. ਮਿਨੀਕੂਬੇ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਨੂੰ ਵਧਾਏਗਾ।
3. kubectl - ਕਲੱਸਟਰ ਪ੍ਰਬੰਧਨ ਲਈ ਕਮਾਂਡ ਲਾਈਨ ਇੰਟਰਫੇਸ।

ਅਸੀਂ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਨੂੰ ਵਧਾਉਂਦੇ ਹਾਂ:

$ minikube start --vm-driver=docker
minikube v1.11.0 on Darwin 10.15.5
Using the docker driver based on existing profile.
Starting control plane node minikube in cluster minikube.

ਸੰਕੇਤ kubectl ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਥਾਨਕ ਕਲੱਸਟਰ ਦੀ ਵਰਤੋਂ ਕਰੋ:

$ kubectl config use-context minikube
Switched to context "minikube".

ਉਤਪਾਦਨ ਵਾਤਾਵਰਣ ਲਈ ਸੰਰਚਨਾ ਡਾਊਨਲੋਡ ਕਰੋ:

$ curl https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/configs/production.yml > stale-feature-branch-production-configs.yml

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

ਜੇਕਰ ਤੁਸੀਂ 'ਤੇ ਹੋ Linux:

$ sed -i 's|false|true|g' stale-feature-branch-production-configs.yml

ਜੇਕਰ ਤੁਸੀਂ 'ਤੇ ਹੋ macOS:

$ sed -i "" 's|false|true|g' stale-feature-branch-production-configs.yml

ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਸਥਾਪਿਤ ਕਰਨਾ:

$ kubectl apply -f stale-feature-branch-production-configs.yml

ਜਾਂਚ ਕਰ ਰਿਹਾ ਹੈ ਕਿ ਕਲੱਸਟਰ ਵਿੱਚ ਇੱਕ ਸਰੋਤ ਪ੍ਰਗਟ ਹੋਇਆ ਹੈ StaleFeatureBranch:

$ kubectl api-resources | grep stalefeaturebranches
NAME                 ... APIGROUP                             ... KIND
stalefeaturebranches ... feature-branch.dmytrostriletskyi.com ... StaleFeatureBranch

ਅਸੀਂ ਜਾਂਚ ਕਰਦੇ ਹਾਂ ਕਿ ਇੱਕ ਆਪਰੇਟਰ ਕਲੱਸਟਰ ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਇਆ ਹੈ:

$ kubectl get pods --namespace stale-feature-branch-operator
NAME                                           ... STATUS  ... AGE
stale-feature-branch-operator-6bfbfd4df8-m7sch ... Running ... 38s

ਜੇ ਤੁਸੀਂ ਇਸਦੇ ਲੌਗਸ ਨੂੰ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਇਹ ਸਰੋਤਾਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਕਰਨ ਲਈ ਤਿਆਰ ਹੈ StaleFeatureBranch:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Operator Version: 0.0.1"}
...
... "msg":"Starting EventSource", ... , "source":"kind source: /, Kind="}
... "msg":"Starting Controller", ...}
... "msg":"Starting workers", ..., "worker count":1}

ਅਸੀਂ ਰੈਡੀਮੇਡ ਇੰਸਟਾਲ ਕਰਦੇ ਹਾਂ fixtures (ਕਲੱਸਟਰ ਸਰੋਤਾਂ ਦੇ ਮਾਡਲਿੰਗ ਲਈ ਤਿਆਰ-ਕੀਤੀ ਸੰਰਚਨਾ) ਇੱਕ ਸਰੋਤ ਲਈ StaleFeatureBranch:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/stale-feature-branch.yml

ਸੰਰਚਨਾ ਸਬਸਟਰਿੰਗ ਨਾਲ ਨੇਮਸਪੇਸ ਖੋਜਣ ਲਈ ਦਰਸਾਉਂਦੀ ਹੈ -pr- ਇੱਕ ਵਾਰ ਅੰਦਰ 1 минуту.:

apiVersion: feature-branch.dmytrostriletskyi.com/v1
kind: StaleFeatureBranch
metadata:
  name: stale-feature-branch
spec:
  namespaceSubstring: -pr-
  afterDaysWithoutDeploy: 1 
  checkEveryMinutes: 1

ਆਪਰੇਟਰ ਨੇ ਜਵਾਬ ਦਿੱਤਾ ਹੈ ਅਤੇ ਨਾਮ-ਸਥਾਨਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਤਿਆਰ ਹੈ:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Stale feature branch is being processing.","namespaceSubstring":"-pr-","afterDaysWithoutDeploy":1,"checkEveryMinutes":1,"isDebug":"true"}

ਸਥਾਪਿਤ ਕਰੋ fixtures, ਜਿਸ ਵਿੱਚ ਦੋ ਨੇਮ-ਸਪੇਸ (project-pr-1, project-pr-2) ਅਤੇ ਉਹ deployments, services, ingress, ਇਤਆਦਿ:

$ kubectl apply -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/first-feature-branch.yml -f https://raw.githubusercontent.com/dmytrostriletskyi/stale-feature-branch-operator/master/fixtures/second-feature-branch.yml
...
namespace/project-pr-1 created
deployment.apps/project-pr-1 created
service/project-pr-1 created
horizontalpodautoscaler.autoscaling/project-pr-1 created
secret/project-pr-1 created
configmap/project-pr-1 created
ingress.extensions/project-pr-1 created
namespace/project-pr-2 created
deployment.apps/project-pr-2 created
service/project-pr-2 created
horizontalpodautoscaler.autoscaling/project-pr-2 created
secret/project-pr-2 created
configmap/project-pr-2 created
ingress.extensions/project-pr-2 created

ਅਸੀਂ ਜਾਂਚ ਕਰਦੇ ਹਾਂ ਕਿ ਉਪਰੋਕਤ ਸਾਰੇ ਸਰੋਤ ਸਫਲਤਾਪੂਰਵਕ ਬਣਾਏ ਗਏ ਹਨ:

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...
NAME                              ... READY ... STATUS  ... AGE
pod/project-pr-1-848d5fdff6-rpmzw ... 1/1   ... Running ... 67s

NAME                         ... READY ... AVAILABLE ... AGE
deployment.apps/project-pr-1 ... 1/1   ... 1         ... 67s
...

ਕਿਉਂਕਿ ਅਸੀਂ ਸ਼ਾਮਲ ਕੀਤਾ ਹੈ debug, ਨੇਮਸਪੇਸ project-pr-1 и project-pr-2, ਇਸਲਈ ਹੋਰ ਸਾਰੇ ਸਰੋਤਾਂ ਨੂੰ ਪੈਰਾਮੀਟਰ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਲਏ ਬਿਨਾਂ ਤੁਰੰਤ ਮਿਟਾਉਣਾ ਹੋਵੇਗਾ afterDaysWithoutDeploy. ਇਸਨੂੰ ਆਪਰੇਟਰ ਲੌਗਸ ਵਿੱਚ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ:

$ kubectl logs stale-feature-branch-operator-6bfbfd4df8-m7sch -n stale-feature-branch-operator
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-1"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-1","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-1"}
... "msg":"Namespace should be deleted due to debug mode is enabled.","namespaceName":"project-pr-2"}
... "msg":"Namespace is being processing.","namespaceName":"project-pr-2","namespaceCreationTimestamp":"2020-06-16 18:43:58 +0300 EEST"}
... "msg":"Namespace has been deleted.","namespaceName":"project-pr-2"}

ਜੇਕਰ ਤੁਸੀਂ ਸਰੋਤਾਂ ਦੀ ਉਪਲਬਧਤਾ ਦੀ ਜਾਂਚ ਕਰਦੇ ਹੋ, ਤਾਂ ਉਹ ਸਥਿਤੀ ਵਿੱਚ ਹੋਣਗੇ Terminating (ਮਿਟਾਉਣ ਦੀ ਪ੍ਰਕਿਰਿਆ) ਜਾਂ ਪਹਿਲਾਂ ਹੀ ਮਿਟਾਇਆ ਗਿਆ (ਕਮਾਂਡ ਆਉਟਪੁੱਟ ਖਾਲੀ ਹੈ)।

$ kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-1 && kubectl get namespace,pods,deployment,service,horizontalpodautoscaler,configmap,ingress -n project-pr-2
...

ਤੁਸੀਂ ਰਚਨਾ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਦੁਹਰਾ ਸਕਦੇ ਹੋ fixtures ਕਈ ਵਾਰ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਉਹ ਇੱਕ ਮਿੰਟ ਦੇ ਅੰਦਰ ਹਟਾ ਦਿੱਤੇ ਗਏ ਹਨ।

ਬਦਲ

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

1. ਮਾਸਟਰ ਬ੍ਰਾਂਚ ਦੇ ਨਿਰੰਤਰ ਏਕੀਕਰਣ ਦੇ ਦੌਰਾਨ ਵਿਸ਼ੇਸ਼ਤਾ ਸ਼ਾਖਾ ਨੂੰ ਮਿਟਾਓ।

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

2. ਵੈਬਹੁੱਕ ਦੀ ਵਰਤੋਂ ਕਰਨਾ (ਉਦਾਹਰਨ).

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

3. ਲਿਖੋ ਕ੍ਰੋਨਜੌਬ ਅਤੇ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਸ਼ਾਮਲ ਕਰੋ।

   • ਲਿਖਣ ਅਤੇ ਸਹਾਇਤਾ 'ਤੇ ਸਮਾਂ ਬਿਤਾਉਣਾ.
   • ਓਪਰੇਟਰ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਸਮਾਨ ਸ਼ੈਲੀ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ, ਦਸਤਾਵੇਜ਼ੀ ਅਤੇ ਸਮਰਥਿਤ ਹੈ।

ਲੇਖ ਵੱਲ ਤੁਹਾਡਾ ਧਿਆਨ ਦੇਣ ਲਈ ਤੁਹਾਡਾ ਧੰਨਵਾਦ। Github 'ਤੇ ਪ੍ਰੋਜੈਕਟ ਨਾਲ ਲਿੰਕ ਕਰੋ.

ਸਰੋਤ: www.habr.com