Задание GitLab Задание выполнено успешно, но не завершено (создать / удалить Azure AKS) - PullRequest
1 голос
/ 06 октября 2019

Я использую бегун для создания AKS на лету, а также для удаления предыдущего.

к сожалению, эти задания занимают некоторое время, и теперь я уже более чем часто сталкиваюсь с тем, что работа внезапно останавливается (в диапазоне 5+ минут после того, как az aks delete или az aks create call.

Ситуация происходит в GitLab, и после нескольких повторных попыток она обычно работает один раз.

При некоторых поисках в Google обнаружил, что сценарии до и после могут оказывать влияние ... но даже при их удалении различий не было.

Существуют ли какие-либо правила Runner или что-то конкретное, что может потребоваться изменить? Было бы более понятно, если бы он остановился с ошибкой TImeout, но он обрабатывает его по мере успешного выполнения задания, даже если он даже не завершил работу в течение этого периода. все линии. Ниже находится сегмент, вызывающий колебания, вызывающий проблему:

create-kubernetes-az:
  stage: create-kubernetes-az
  image: microsoft/azure-cli:latest
#  when: manual
  script:
    # REQUIRE CREATED SERVICE PRINCIPAL
    - az login --service-principal -u ${AZ_PRINC_USER} -p ${AZ_PRINC_PASSWORD} --tenant ${AZ_PRINC_TENANT}
    # Create Resource Group
    - az group create --name ${AZ_RESOURCE_GROUP} --location ${AZ_RESOURCE_LOCATION}
# ERROR HAPPENS HERE # Delete Kubernetes Cluster // SOMETIMES STOPS AFTER THIS
    - az aks delete --resource-group ${AZ_RESOURCE_GROUP} --name ${AZ_AKS_TEST_CLUSTER} --yes
#// OR HERE # Create Kubernetes Cluster // SOMETIMES STOPS AFTER THIS
    - az aks create --name ${AZ_AKS_TEST_CLUSTER} --resource-group ${AZ_RESOURCE_GROUP} --node-count ${AZ_AKS_TEST_NODECOUNT} --service-principal ${AZ_PRINC_USER} --client-secret ${AZ_PRINC_PASSWORD} --generate-ssh-keys 
    # Get cubectl
    - az aks install-cli
    # Get Login Credentials
    - az aks get-credentials --name ${AZ_AKS_TEST_CLUSTER} --resource-group ${AZ_RESOURCE_GROUP}
    # Install Helm and Tiller on Azure Cloud Shell
    - curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > get_helm.sh
    - chmod 700 get_helm.sh
    - ./get_helm.sh
    - helm init
    - kubectl create serviceaccount --namespace kube-system tiller
    - kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
    - kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
    # Create a namespace for your ingress resources
    - kubectl create namespace ingress-basic
    # Wait 1 minutes
    - sleep 60
    # Use Helm to deploy an NGINX ingress controller
    - helm install stable/nginx-ingress --namespace ingress-basic --set controller.replicaCount=2 --set controller.nodeSelector."beta\.kubernetes\.io/os"=linux --set defaultBackend.nodeSelector."beta\.kubernetes\.io/os"=linux
    # Test by get public IP
    - kubectl get service
    - kubectl get service -l app=nginx-ingress --namespace ingress-basic
    #- while [ "$(kubectl get service -l app=nginx-ingress --namespace ingress-basic | grep pending)" == "pending" ]; do echo "Updating"; sleep 1 ; done && echo "Finished"
    - while [ "$(kubectl get service -l app=nginx-ingress --namespace ingress-basic -o jsonpath='{.items[*].status.loadBalancer.ingress[*].ip}')" == "" ]; do echo "Updating"; sleep 10 ; done && echo "Finished"
    # Add Ingress Ext IP / Alternative
    - KUBip=$(kubectl get service -l app=nginx-ingress --namespace ingress-basic -o jsonpath='{.items[*].status.loadBalancer.ingress[*].ip}')
    - echo $KUBip
    # Add DNS Name - TODO - GITLAB ENV VARIABELEN KLAPPEN NICHT
    - DNSNAME="bl-test"
    # Get the resource-id of the public ip
    - PUBLICIPID=$(az network public-ip list --query "[?ipAddress!=null]|[?contains(ipAddress, '$KUBip')].[id]" --output tsv)
    - echo $PUBLICIPID
    - az network public-ip update --ids $PUBLICIPID --dns-name $DNSNAME
    #Install CertManager Console
    # Install the CustomResourceDefinition resources separately
    - kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.8/deploy/manifests/00-crds.yaml
    # Create the namespace for cert-manager
    - kubectl create namespace cert-manager
    # Label the cert-manager namespace to disable resource validation
    - kubectl label namespace cert-manager certmanager.k8s.io/disable-validation=true
    # Add the Jetstack Helm repository
    - helm repo add jetstack https://charts.jetstack.io
    # Update your local Helm chart repository cache
    - helm repo update
    # Install the cert-manager Helm chart
    - helm install --name cert-manager --namespace cert-manager --version v0.8.0 jetstack/cert-manager
    # Run Command issuer.yaml  
    - sed 's/_AZ_AKS_ISSUER_NAME_/'"${AZ_AKS_ISSUER_NAME}"'/g; s/_BL_DEV_E_MAIL_/'"${BL_DEV_E_MAIL}"'/g' infrastructure/kubernetes/cluster-issuer.yaml > cluster-issuer.yaml;
    - kubectl apply -f cluster-issuer.yaml
    # Run Command ingress.yaml  
    - sed 's/_BL_AZ_HOST_/'"beautylivery-test.${AZ_RESOURCE_LOCATION}.${AZ_AKS_HOST}"'/g; s/_AZ_AKS_ISSUER_NAME_/'"${AZ_AKS_ISSUER_NAME}"'/g' infrastructure/kubernetes/ingress.yaml > ingress.yaml;
    - kubectl apply -f ingress.yaml 

И результат

Running with gitlab-runner 12.3.0 (a8a019e0)
  on runner-gitlab-runner-676b494b6b-b5q6h gzi97H3Q
Using Kubernetes namespace: gitlab-managed-apps
Using Kubernetes executor with image microsoft/azure-cli:latest ...
Waiting for pod gitlab-managed-apps/runner-gzi97h3q-project-14628452-concurrent-0l8wsx to be running, status is Pending
Waiting for pod gitlab-managed-apps/runner-gzi97h3q-project-14628452-concurrent-0l8wsx to be running, status is Pending
Running on runner-gzi97h3q-project-14628452-concurrent-0l8wsx via runner-gitlab-runner-676b494b6b-b5q6h...
Fetching changes with git depth set to 50...
Initialized empty Git repository in /builds/****/*******/.git/
Created fresh repository.
From https://gitlab.com/****/********
 * [new branch]      Setup-Kubernetes -> origin/Setup-Kubernetes
Checking out d2ca489b as Setup-Kubernetes...

Skipping Git submodules setup
$ function create_secret() { # collapsed multi-line command
$ echo "current time $(TZ=Europe/Berlin date +"%F %T")"
current time 2019-10-06 09:00:50
$ az login --service-principal -u ${AZ_PRINC_USER} -p ${AZ_PRINC_PASSWORD} --tenant ${AZ_PRINC_TENANT}
[
  {
    "cloudName": "AzureCloud",
    "id": "******",
    "isDefault": true,
    "name": "Nutzungsbasierte Bezahlung",
    "state": "Enabled",
    "tenantId": "*******",
    "user": {
      "name": "http://*****",
      "type": "servicePrincipal"
    }
  }
]
$ az group create --name ${AZ_RESOURCE_GROUP} --location ${AZ_RESOURCE_LOCATION}
{
  "id": "/subscriptions/*********/resourceGroups/*****",
  "location": "francecentral",
  "managedBy": null,
  "name": "******",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": "Microsoft.Resources/resourceGroups"
}
$ az aks delete --resource-group ${AZ_RESOURCE_GROUP} --name ${AZ_AKS_TEST_CLUSTER} --yes
Running after script...
$ echo "current time $(TZ=Europe/Berlin date +"%F %T")"
current time 2019-10-06 09:05:55
Job succeeded

Есть ли способы полностью запустить бег? И он успешен в лучшем случае?

ОБНОВЛЕНИЕ: В чем идея: я пытаюсь автоматизировать процесс создания полного кластера kubernetes с помощью SУправление SL и DNS. В будущем все будет готово для разных вариантов использования и для разных сред. Я также хочу научиться делать что-то лучше :)

NEW_UPDATE:

Добавлено решение

1 Ответ

0 голосов
/ 08 октября 2019

Я добавил небольшую работу вокруг, так как ожидал, что время от времени требуется выполнение .....

Кажется, команда az aks wait на данный момент добилась цели. и предыдущая команда требует --no-wait для продолжения.

# Delete Kubernetes Cluster 
  - az aks delete --resource-group ${AZ_RESOURCE_GROUP} --name ${AZ_AKS_TEST_CLUSTER} --no-wait --yes
  - az aks wait --deleted -g ${AZ_RESOURCE_GROUP} -n ${AZ_AKS_TEST_CLUSTER} --updated --interval 60 --timeout 1800
  # Create Kubernetes Cluster  
  - az aks create --name ${AZ_AKS_TEST_CLUSTER} --resource-group ${AZ_RESOURCE_GROUP} --node-count ${AZ_AKS_TEST_NODECOUNT} --service-principal ${AZ_PRINC_USER} --client-secret ${AZ_PRINC_PASSWORD} --generate-ssh-keys --no-wait
  - az aks wait --created -g ${AZ_RESOURCE_GROUP} -n ${AZ_AKS_TEST_CLUSTER} --updated --interval 60 --timeout 1800
...