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

Question

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

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

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

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

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

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

• Удалены существующие стручки в кубернетес; недавно созданные из них до сих пор не хватает zip

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

• Я подталкиваю к ACR, используя docker push MY-REPO.azurecr.io/MY-IMAGE:latest

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

Answer 1

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

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

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

3. Вы должны использовать Kubernetes Deployment (не пустой Pod); в части спецификации 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 тег изображения (или любая другая фиксированная строка); вместо этого используйте какое-то уникальное значение, такое как метка времени, идентификатор фиксации контроля версий или версия выпуска, где каждый раз, когда вы выполняете развертывание, у вас будет другой тег.

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

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