Каков наилучший подход для загрузки папки конфигурации (200+ МБ) в контейнер

Question

Я развертываю контейнер в кластере AKS.

Я хочу смонтировать папку конфигурации (размер 200+ МБ) в этот контейнер. Папка конфигурации присутствует в git-репо. У каждого клиента есть его собственные данные конфигурации и хранятся в отдельной ветке в том же репо.

Я думаю о следующих параметрах загрузки папки конфигурации в контейнер:

1. Постоянные претензии по объему - ПВХ Я создам общий файловый ресурс и скопирую в него папку config. Смонтируйте общий файловый ресурс в контейнер, используя PVC. При таком подходе мне нужно добавить ключ доступа к хранилищу / токен sas к секретам kubernetes.
2. Заархивируйте папку конфигурации и скопируйте ее в хранилище BLOB-объектов. В скрипте запуска контейнера загрузите zio из хранилища BLOB-объектов и установите его в нужное место. При таком подходе я должен использовать токен SAS для доступа к учетной записи хранения. (Этот токен будет сохранен как секретный в kubernetes)
3. В скрипте запуска контейнера git клонирует репозиторий, содержащий папку config, загружает его и копирует в нужное место. В этом подходе мне нужно использовать токен PAT для клонирования git.
4. Скопируйте папку конфигурации в сам образ докера. При таком подходе мне не нужно беспокоиться о том, как загрузить папку config в контейнер. Однако, поскольку папка конфигурации является индивидуальной для каждого клиента и более 100 клиентов, в результате получается более 100+ теги изображений. (Мы добавили теги для клиента)

Можете ли вы указать мне, какой вариант лучше? Есть ли другой лучший подход.

Я прочитал, что существуют проблемы безопасности при использовании общих томов PVC, которые могут предоставить злоумышленнику корневые разрешения на узле. А также есть проблемы безопасности при использовании git внутри контейнера. Можете ли вы предоставить больше информации о том, почему / как эти проблемы безопасности?

Answer 1

использовать контейнер init для загрузки папки конфигурации из git repo в общий том между контейнером init и основным контейнером

Answer 2

Если вы используете AKS, для создания конфигурации вы можете использовать заявку на постоянный том Azure File, вы можете использовать общий доступ к файлам только для чтения, что повысит безопасность.

По-моему, все остальныеварианты намного менее удобны (и, возможно, менее безопасны)

Answer 3

Я бы предложил использовать какое-то хранилище, а затем использовать какой-нибудь диск NFS.

Есть несколько соображений, которые вы должны принять во внимание: - сколько записей - сколько записей - каков обычно размер файла

Я бы не советовал использовать сценарий запуска дляскачайте его, так как это сделает ваш контейнер намного медленнее, в общем, контейнер должен быть готов к обслуживанию трафика при запуске.Вы можете сделать что-то подобное в Azure https://docs.microsoft.com/en-us/azure/storage/blobs/storage-how-to-mount-container-linux

Answer 4

Я бы использовал git sync image (их довольно много).Таким образом, вы должны использовать доступ только для чтения (упомянутый вами токен PAT не должен предоставлять права на запись в репо).Он поддерживает чтение из разных веток, просто нужно передать ему значение (легко через диаграмму рулевого управления).И хорошо, что вы можете дополнительно синхронизировать конфигурацию (если ваша микросервис поддерживает это).

Я вижу все другие решения более сложными.

Answer 5

Я думаю, что мы можем сделать это простым способом. Вы можете использовать helm с hookScript Моя идея

1. при развертывании с пустым PVC с квотой укажите
2. затем применить URL через Configmap или переменную окружения или Переменная Helm
3. после этого, когда зацепите, просто используйте git clone от вас FILE_DOWNLOAD_GIT_REPO до вашего крепления ПВХ. что это:)

избавит от лишних шагов и может многоразово использовать. право ? :) Извините, я так сонный, что не могу написать образец шлема для вас . Но надеюсь, у вас есть идея. :)