Added flux2 controller images based on task 353490 #27

Open
kaf wants to merge 2 commits from add-flux2-images into master
6 changed files with 102 additions and 0 deletions

View File

@ -0,0 +1,17 @@
FROM {{ registry }}{{ alt_image }}:{{ branch }}
MAINTAINER alt-cloud
LABEL org.opencontainers.image.title="flux2-helm-controller"
LABEL org.opencontainers.image.description="Kubernetes operator, allowing one to declaratively manage Helm chart releases."
LABEL org.opencontainers.image.source="https://github.com/fluxcd/helm-controller"
LABEL org.opencontainers.image.licenses="Apache-2.0"
LABEL org.opencontainers.image.vendor="ALT Linux Team"
RUN echo "rpm http://git.altlinux.org repo/353490/x86_64 task" > /etc/apt/sources.list
Review

Вот это не пойдет. Нужно дождаться пока пакет попадет в ветку. Смысла лить это в репозитеорий нет, так как потом надо удалять. Тем более что сборка у нас идет для разных архитектур, а тут ссылка на х86.

Вот это не пойдет. Нужно дождаться пока пакет попадет в ветку. Смысла лить это в репозитеорий нет, так как потом надо удалять. Тем более что сборка у нас идет для разных архитектур, а тут ссылка на х86.
Review

Вот тут у меня deadlock
Чтобы команда попала в бранч sisyphus ее надо оттестировать в качестве образа
Чтобы оттестировать в качестве образы надо чтобы она попала в какое-то репо
Я считал, что gitea как раз то репо, которое можно использовать для тестирования
Если это не так, то какой в нем смысл?

Вот тут у меня deadlock Чтобы команда попала в бранч sisyphus ее надо оттестировать в качестве образа Чтобы оттестировать в качестве образы надо чтобы она попала в какое-то репо Я считал, что gitea как раз то репо, которое можно использовать для тестирования Если это не так, то какой в нем смысл?
Review

Тем более что сборка у нас идет для разных архитектур, а тут ссылка на х86.
Дело в том, что другие архитектуры как я понимаю для программ на go у нас просто недоступны
Выше я уже об этом писал

Команды в образах написаны на go и собраны для платформ aarch64 i586 ppc64le x86_64 ( https://git.altlinux.org/tasks/353490/)

build.py начиная с мая месяца поддерживает только amd64 386 arm64
Следовательно образы можно собирать только для архитектуры amd64 под sisyphus

Если коллеги подскажет, как собрать в сборочнице пакет на go под платформы
386 arm64, которые поддерживает на build.py, то я это обязательно сделаю

И кстати - почему в мае исключили в build.py сборку образов под платформы aarch64 i586 ppc64le ?

> Тем более что сборка у нас идет для разных архитектур, а тут ссылка на х86. Дело в том, что другие архитектуры как я понимаю для программ на go у нас просто недоступны Выше я уже об этом писал Команды в образах написаны на go и собраны для платформ aarch64 i586 ppc64le x86_64 ( https://git.altlinux.org/tasks/353490/) build.py начиная с мая месяца поддерживает только amd64 386 arm64 Следовательно образы можно собирать только для архитектуры amd64 под sisyphus Если коллеги подскажет, как собрать в сборочнице пакет на go под платформы 386 arm64, которые поддерживает на build.py, то я это обязательно сделаю И кстати - почему в мае исключили в build.py сборку образов под платформы aarch64 i586 ppc64le ?
Review

Вот тут у меня deadlock
Чтобы команда попала в бранч sisyphus ее надо оттестировать в качестве образа
Чтобы оттестировать в качестве образы надо чтобы она попала в какое-то репо
Я считал, что gitea как раз то репо, которое можно использовать для тестирования
Если это не так, то какой в нем смысл?

Никакого дэдлока нет. Тестируем сами свои пакеты для х86-64. Варианты:

  1. Оттестировать своими руками сборку и запуск контейнера через этот же докерфайл который запушен с подключением такси в репо пакетов, запустить в контейнере нужную утилиту\программу для теста.
  2. Собрать и запустить контейнер, в который затащить собранный успешно файл rpm пакета и установить его, запустить в контейнере установленную утилиту\программу для теста.

Гитея тут не при чем. Автосборка в гитее сделана для самой сборки и посчледующей публикации образов, а тестирование добававлено для перестраховки. Работоспособность написанного сначала проверяем сами вручную, это этап разработки. Далее собранный пакет идет в сизиф. Далее в гитею.

> Вот тут у меня deadlock > Чтобы команда попала в бранч sisyphus ее надо оттестировать в качестве образа > Чтобы оттестировать в качестве образы надо чтобы она попала в какое-то репо > Я считал, что gitea как раз то репо, которое можно использовать для тестирования > Если это не так, то какой в нем смысл? Никакого дэдлока нет. Тестируем сами свои пакеты для х86-64. Варианты: 1. Оттестировать своими руками сборку и запуск контейнера через этот же докерфайл который запушен с подключением такси в репо пакетов, запустить в контейнере нужную утилиту\программу для теста. 2. Собрать и запустить контейнер, в который затащить собранный успешно файл rpm пакета и установить его, запустить в контейнере установленную утилиту\программу для теста. Гитея тут не при чем. Автосборка в гитее сделана для самой сборки и посчледующей публикации образов, а тестирование добававлено для перестраховки. Работоспособность написанного сначала проверяем сами вручную, это этап разработки. Далее собранный пакет идет в сизиф. Далее в гитею.
Review

Тем более что сборка у нас идет для разных архитектур, а тут ссылка на х86.
Дело в том, что другие архитектуры как я понимаю для программ на go у нас просто недоступны
Выше я уже об этом писал

Команды в образах написаны на go и собраны для платформ aarch64 i586 ppc64le x86_64 ( https://git.altlinux.org/tasks/353490/)

build.py начиная с мая месяца поддерживает только amd64 386 arm64
Следовательно образы можно собирать только для архитектуры amd64 под sisyphus

Если коллеги подскажет, как собрать в сборочнице пакет на go под платформы
386 arm64, которые поддерживает на build.py, то я это обязательно сделаю

И кстати - почему в мае исключили в build.py сборку образов под платформы aarch64 i586 ppc64le ?

Отвечу кратко. 1. сборка образов теперь только для архитектур "amd64", "386", "arm64", такое решение было принято Алексеем Шабалиным. 2. Сборка пакетов для го идет с макросом ExclusiveArch: %go_arches. Если на уровне сборки пакетов все нормально, считаем что все ок, кому надо - будет использовать. Если где то падает сборка пакета - чиним сборку пакета, либо исключаем архитектуру. Тестируем сами как писала выше для х86-64. 3. Образы мы собираем только для "amd64", "386", "arm64". Не связано с пакетами. Тестируем сами как писала выше для х86-64. Далее работет автосборка для всех архитектур и если вознукнут проблемы будем как то чинить.

> > Тем более что сборка у нас идет для разных архитектур, а тут ссылка на х86. > Дело в том, что другие архитектуры как я понимаю для программ на go у нас просто недоступны > Выше я уже об этом писал > > Команды в образах написаны на go и собраны для платформ aarch64 i586 ppc64le x86_64 ( https://git.altlinux.org/tasks/353490/) > > build.py начиная с мая месяца поддерживает только amd64 386 arm64 > Следовательно образы можно собирать только для архитектуры amd64 под sisyphus > > Если коллеги подскажет, как собрать в сборочнице пакет на go под платформы > 386 arm64, которые поддерживает на build.py, то я это обязательно сделаю > > И кстати - почему в мае исключили в build.py сборку образов под платформы aarch64 i586 ppc64le ? Отвечу кратко. 1. сборка образов теперь только для архитектур "amd64", "386", "arm64", такое решение было принято Алексеем Шабалиным. 2. Сборка пакетов для го идет с макросом ExclusiveArch: %go_arches. Если на уровне сборки пакетов все нормально, считаем что все ок, кому надо - будет использовать. Если где то падает сборка пакета - чиним сборку пакета, либо исключаем архитектуру. Тестируем сами как писала выше для х86-64. 3. Образы мы собираем только для "amd64", "386", "arm64". Не связано с пакетами. Тестируем сами как писала выше для х86-64. Далее работет автосборка для всех архитектур и если вознукнут проблемы будем как то чинить.
{{ install_packages("flux2-helm-controller") }}
USER 65534:65534
Review

Юзеру и группе с этими айди должны быть доступны ресурсы установленных пакетов. В пакетах нет никаких конфигов или директорий для данных приложений которые должны быть доступны данному юзеру и должны монтироваться?
Еще у нас есть договоренность что используем айди 10001 и далее для таких групп и юзеров.

Юзеру и группе с этими айди должны быть доступны ресурсы установленных пакетов. В пакетах нет никаких конфигов или директорий для данных приложений которые должны быть доступны данному юзеру и должны монтироваться? Еще у нас есть договоренность что используем айди 10001 и далее для таких групп и юзеров.
Review

Пользователь с UID=65534 GID=65534 это пользователь nobody. Он исходно есть в /etc/passwd, /etc/group после установки системы (как в нашем дистрибутиве, так и в других Linux-дистрибутивах)
То есть создавать этого пользователя не надо
Монтировать какие-то файлы или каталоги из основной системы нет необходимости

Пользователь с UID=65534 GID=65534 это пользователь nobody. Он исходно есть в /etc/passwd, /etc/group после установки системы (как в нашем дистрибутиве, так и в других Linux-дистрибутивах) То есть создавать этого пользователя не надо Монтировать какие-то файлы или каталоги из основной системы нет необходимости
Review

Алексей много раз говорил что пользователь ноубади не должен использвоаться нигде (За подробностями к нему.), поэтому тем более надо убирать. Если пользователю не нужны доп права на какие то общие директории\ресурсы то просто его надо заменить на 10001. Ну а вообще это будет понятно после тестирования

Алексей много раз говорил что пользователь ноубади не должен использвоаться нигде (За подробностями к нему.), поэтому тем более надо убирать. Если пользователю не нужны доп права на какие то общие директории\ресурсы то просто его надо заменить на 10001. Ну а вообще это будет понятно после тестирования
Review

Спасибо
Уточню у Алексея Шабалина

Спасибо Уточню у Алексея Шабалина
ENTRYPOINT [ "helm-controller" ]

View File

@ -0,0 +1,17 @@
FROM {{ registry }}{{ alt_image }}:{{ branch }}
MAINTAINER alt-cloud
LABEL org.opencontainers.image.title="flux2-image-automation-controller"
LABEL org.opencontainers.image.description="This controller automates updates to YAML when new container images are available."
LABEL org.opencontainers.image.source="https://github.com/fluxcd/image-automation-controller"
LABEL org.opencontainers.image.licenses="Apache-2.0"
LABEL org.opencontainers.image.vendor="ALT Linux Team"
RUN echo "rpm http://git.altlinux.org repo/353490/x86_64 task" > /etc/apt/sources.list
{{ install_packages("flux2-image-automation-controller") }}
USER 65534:65534
ENTRYPOINT [ "image-automation-controller" ]

View File

@ -0,0 +1,17 @@
FROM {{ registry }}{{ alt_image }}:{{ branch }}
MAINTAINER alt-cloud
LABEL org.opencontainers.image.title="flux2-image-reflector-controller"
LABEL org.opencontainers.image.description="This is a controller that reflects container image metadata into a Kubernetes cluster"
LABEL org.opencontainers.image.source="https://github.com/fluxcd/image-reflector-controller"
LABEL org.opencontainers.image.licenses="Apache-2.0"
LABEL org.opencontainers.image.vendor="ALT Linux Team"
RUN echo "rpm http://git.altlinux.org repo/353490/x86_64 task" > /etc/apt/sources.list
{{ install_packages("flux2-image-reflector-controller") }}
USER 65534:65534
ENTRYPOINT [ "image-reflector-controller" ]

View File

@ -0,0 +1,17 @@
FROM {{ registry }}{{ alt_image }}:{{ branch }}
MAINTAINER alt-cloud
LABEL org.opencontainers.image.title="flux2-kustomize-controller"
LABEL org.opencontainers.image.description="Kubernetes operator, allowing one to declaratively manage Helm chart releases."
LABEL org.opencontainers.image.source="https://github.com/fluxcd/kustomize-controller"
LABEL org.opencontainers.image.licenses="Apache-2.0"
LABEL org.opencontainers.image.vendor="ALT Linux Team"
RUN echo "rpm http://git.altlinux.org repo/353490/x86_64 task" > /etc/apt/sources.list
{{ install_packages("flux2-kustomize-controller") }}
USER 65534:65534
ENTRYPOINT [ "kustomize-controller" ]

View File

@ -0,0 +1,17 @@
FROM {{ registry }}{{ alt_image }}:{{ branch }}
MAINTAINER alt-cloud
LABEL org.opencontainers.image.title="flux2-notification-controller"
LABEL org.opencontainers.image.description="Event forwarder and notification dispatcher for the GitOps Toolkit controllers"
LABEL org.opencontainers.image.source="https://github.com/fluxcd/notification-controller"
LABEL org.opencontainers.image.licenses="Apache-2.0"
LABEL org.opencontainers.image.vendor="ALT Linux Team"
RUN echo "rpm http://git.altlinux.org repo/353490/x86_64 task" > /etc/apt/sources.list
{{ install_packages("flux2-notification-controller") }}
USER 65534:65534
ENTRYPOINT [ "notification-controller" ]

View File

@ -0,0 +1,17 @@
FROM {{ registry }}{{ alt_image }}:{{ branch }}
MAINTAINER alt-cloud
LABEL org.opencontainers.image.title="flux2-source-controller"
LABEL org.opencontainers.image.description="Kubernetes operator, specialised in artifacts acquisition from external sources such as Git, OCI, Helm repositories and S3-compatible buckets."
LABEL org.opencontainers.image.source="https://github.com/fluxcd/source-controller"
LABEL org.opencontainers.image.licenses="Apache-2.0"
LABEL org.opencontainers.image.vendor="ALT Linux Team"
RUN echo "rpm http://git.altlinux.org repo/353490/x86_64 task" > /etc/apt/sources.list
{{ install_packages("flux2-source-controller") }}
USER 65534:65534
ENTRYPOINT [ "source-controller" ]