K
Q

Is there a configuration option in azds.yaml to increase the timeout during azds up?

1/23/2019

The "azds up" command times out before all the steps are done. I have a large Angular app that typically takes 5 minutes+ when npm install is executed. When I execute azds up this is what I get:

Step 1/9 : FROM node
Step 2/9 : ENV PORT 80
Step 3/9 : WORKDIR /app
Step 4/9 : COPY package*.json ./
Step 5/9 : RUN npm install --silent
Waiting for container...

and then it returns to the command line.

Is there a configuration in the azds.yaml where I can tell azds/helm to wait for a longer period of time?

Thanks!

-- MrTouya
azure-aks
azure-kubernetes

Similar Questions

kubelet saying node "master01" not found
Converting a yaml sequence to a yaml map in a helm chart (Kubernetes)
Jenkins + Kubernetes + Docker
Kubernetes ExternalName Services
Promotheus: discrepancy in sum vs avg

1 Answer

2/5/2019

To begin with i will give some examples that might be helpful in your case:

  1. An example of .yaml of how to rolling upgrade
spec:
  minReadySeconds: 60
  progressDeadlineSeconds: 600
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 50%
      maxUnavailable: 50%

  • minReadySeconds: The bootup time of your application, Kubernetes waits specific time until the next pod creation. For example minReadySeconds is 60 then after the Pod become healthy the Deployment must wait for 60 seconds to update the next Pod.

  • progressDeadlineSeconds Timeout value for updating one pod in this example 10 minutes. If the rollout fails to progress in 10 minutes, then the Deployment is marked as failed and finished, also all of next job never invoke.

  • maxSurge: The maxSurge parameter controls how many extra resources can be created during the rollout.(Absolute value or %)

  • maxUnavailable: The maxUnavailable parameter sets the maximum number of Pods that can be unavailable during a rolling update.(Absolute value or %)

  1. An example of .yaml Liveness & Readiness
livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 60
          timeoutSeconds: 1
          periodSeconds: 10
          failureThreshold: 3

The above manifest configured livenessProbes which confirm whether an container is running properly or not. It probe the health check by using HTTP GET request to /healthz with port 8080.

The probe sets an initialDelaySeconds\=60 which means that it will not be called until 60 seconds after all the containers in the Pod are created. And timeoutSeconds\=1 was configured it means that the probe must respond with in the 1 second timeout. The periodSeconds\=10 was configured, it means that the probe invoke every 10 seconds. If more than 3 probe failed(failureThreshold=3), the container will be considerd un-healthy and failed and restart.

  readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 120
          timeoutSeconds: 5
          periodSeconds: 10
          failureThreshold: 3

The above readinessProbe is more important than liveness probe in production environment. the readinessProbe is confirm whether the service can acceptable or not. If this probe failed, the internal loadbalancer never send the traffic to this pod. Only successed the probe, the traffic to this pod will start.

-- Panagiotis Drakatos
Source: StackOverflow