Как использовать обновленный образ докера из ACR в AKS - PullRequest
Новая
       12

Как использовать обновленный образ докера из ACR в AKS

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

У меня есть локальный образ докера, который был помещен в личный реестр контейнеров Azure.Затем в Azure Kubernetes Service у меня есть кластер, в котором я использую этот образ - из ACR.

Теперь я хотел обновить образ (понял, что мне нужно установить zip и распаковать).Я запустил локальный контейнер, внес изменения, зафиксировал их и отправил новый образ в ACR.К сожалению, этого недостаточно.Мои стручки все еще используют предыдущую версию изображения, без почтового индекса.

Немного подробнее и то, что я пробовал:

  • Внутри рулевой диаграммы, которую я использую "последняя""tag;

  • Сравнил дайджест моего локального" последнего "изображения с тем, что у меня есть в ACR - они одинаковые;

  • Локально запустил «последний» контейнер (docker run -it --rm -p 8080:80 My-REPO.azurecr.io/MY-IMAGE:latest) - на нем установлен zip

  • Удалены существующие модули в kubernetes;вновь созданные все еще отсутствуют zip

  • Удалил релиз и пересоздал его - все еще ничего.

  • Я нажимаю на ACR, используя docker push MY-REPO.azurecr.io/MY-IMAGE:latest

Итак, мой вопрос - что мне не хватает?Как правильно обновить эту настройку?

1 Ответ

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

Вы должны искать такую ​​настройку:

  1. Ваши изображения Docker имеют какой-то уникальный тег, а не latest;отметка даты, как правило, будет работать нормально.

  2. Ваша диаграмма Хелма должна принимать тег в качестве параметра в файле values.yaml.

  3. Выследует использовать Kubernetes Deployment (не пустой стручок);в части спецификации pod укажите изображение как image: MY-REPO.azurecr.io/MY-IMAGE:{{ .Values.tag }}.

  4. Когда у вас новая сборка, вы можете helm update --set tag=20190214;это подтолкнет обновленную спецификацию развертывания к Kubernetes;и это заставит его создавать новые модули с новым изображением, а затем уничтожать старые модули со старым изображением.

Существенная проблема, с которой вы сталкиваетесь, заключается в том, что некоторые текстовые различияв файле YAML важно, чтобы Kubernetes предпринял какие-то действия.Если у него уже есть MY-IMAGE:latest, и вы попытаетесь kubectl apply или эквиваленту той же спецификации модуля или развертывания с точно такой же строкой образа, он решит, что ничего не изменилось, и ему ничего не нужно делать.Точно так же, когда вы удаляете и воссоздаете модуль, узел решает, что у него уже есть изображение MY-IMAGE:latest, и ему не нужно ничего выключать и тянуть;он просто использует то же (устаревшее) изображение, которое у него уже есть.

Некоторые рекомендации, относящиеся к описанному вами рабочему процессу:

  • Не используйте ...:latest изображениетег (или любая другая фиксированная строка);вместо этого используйте какое-то уникальное значение, такое как отметка времени, идентификатор фиксации контроля версий или версия выпуска, где каждый раз, когда вы выполняете развертывание, у вас будет другой тег.

  • Не использоватьголые стручки;Вместо этого используйте контроллер более высокого уровня, чаще всего Deployment.

  • Никогда не используйте docker commit.(Если ваше изображение потерпело крах в процессе производства, как бы вы объяснили: «О, я изменил некоторые вещи вручную, переписал используемое ими производство изображений и принудительно перезапустил все, но у меня нет записей о том, что я на самом деле сделал»?)Dockerfile, проверьте его в системе контроля версий и используйте docker build для создания изображений.(Более того, настройте систему CI, чтобы создавать их для вас каждый раз, когда вы регистрируетесь.)

...