Есть ли опция конфигурации в azds.yaml для увеличения тайм-аута при включении azds? - PullRequest
Новая
       13

Есть ли опция конфигурации в azds.yaml для увеличения тайм-аута при включении azds?

0 голосов
/ 23 января 2019

Время ожидания команды «azds up» истекло до выполнения всех шагов.У меня есть большое приложение Angular, которое обычно занимает 5 минут +, когда выполняется установка npm.Когда я выполняю azds up, это то, что я получаю: 

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...

и затем он возвращается в командную строку.

Есть ли в файле azds.yaml конфигурация, в которой я могу указать azds / helm ждать более продолжительное время?

Спасибо!

1 Ответ

0 голосов
/ 05 февраля 2019

Для начала приведу несколько примеров, которые могут быть полезны в вашем случае:

  1. Пример .yaml того, как обновляется 

spec:
  minReadySeconds: 60
  progressDeadlineSeconds: 600
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 50%
      maxUnavailable: 50%

  • minReadySeconds : время загрузки вашего приложения, Kubernetes ждет определенного времени до следующего создания модуля. За пример minReadySeconds равен 60, то после того, как Pod стал здоровым, Развертывание должно ждать 60 секунд для обновления следующего модуля.

  • progressDeadlineSeconds Значение времени ожидания для обновления одного модуля в этом примере 10 минут. Если развертывание не удается выполнить в 10 минут, затем развертывание помечается как неудачное и завершено, а также всю следующую работу никогда не вызывать.

  • maxSurge : параметр maxSurge определяет, сколько дополнительных ресурсов может быть создано во время развертывания. (Абсолютное значение или%)

  • maxUnavailable : параметр maxUnavailable устанавливает максимальное количество модулей, которые могут быть недоступны во время прокатки обновление. (Абсолютное значение или%)

  1. Пример .yaml Живучесть и Готовность 

livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 60
          timeoutSeconds: 1
          periodSeconds: 10
          failureThreshold: 3

Приведенный выше манифест сконфигурировал livenessProbes, которые подтверждают, правильно ли работает контейнер. Он проверяет работоспособность, используя HTTP-запрос GET к / healthz с портом 8080.

Зонд устанавливает initialDelaySeconds = 60, что означает, что он не будет вызываться до 60 секунд после того, как все контейнеры в контейнере создано. И timeoutSeconds = 1 было настроено, это означает, что зонд должен ответить в течение 1 секунды. periodSeconds = 10 было настроено, это означает, что зонд вызывается каждые 10 секунд. Если больше чем 3 зонда не удалось (failThreshold = 3), контейнер будет считается нездоровым и не удалось и перезагрузите. 

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

Вышеуказанный показатель готовности более важен, чем датчик живучести в производственная среда. ReadinessProbe является подтверждение того, является ли Сервис может быть приемлемым или нет. Если этот зонд не удался, внутренний loadbalancer никогда не отправляет трафик на этот модуль. Только удалось зонд, трафик к этому модулю начнется.

...