Как разделить большой набор файлов между капсулами Kuberntes - PullRequest
1 голос
/ 28 мая 2020

У меня есть большой набор файлов конфигурации только для чтения (около 4 КБ), которые используются микросервисом для обработки некоторых файлов XML и должны быть прочитаны через Apache Commons Конфигурация .

Эти файлы бывают следующих типов:

  • Файл свойств
  • XML
  • dtd
  • xfo
  • xslt

5 из этих файлов потребуют замены некоторых переменных среды в их содержимом, таких как расположение стороннего программного обеспечения или URL-адреса различных служб в зависимости от среды файлы развернуты в.

Теперь мне нужно сделать эти файлы доступными для 4 микросервисов во время выполнения.

Я использую fabric8.io maven docker плагин с файлом dockerfile для изображения поколение. Kubernetes, helm, Jenkinsfile и ArgoCD для компакт-диска с микросервисами с весенней загрузкой / CI.

Две проблемы, с которыми я столкнулся: как заменить переменные внутри этих c файлов stati и как сделать эти файлы доступными для каждого модуля.

У меня есть три решения, но я хотел бы знать, какой 12-факторный подход является наилучшим / оптимальным для этой проблемы.

Решение 1: развернуть файлы как отдельный модуль и разрешить другим модулям доступ к некоторому монтированию тома, которое он обеспечивает.

Решение 2. Добавьте файлы в образ микросервиса во время образа docker build.

Решение 3. Добавьте файлы в качестве контейнера каждого модуля микросервисов.

Ответы [ 2 ]

1 голос
/ 28 мая 2020

Вы можете загрузить этот файл в kubernetes ConfigMap.

https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/

apiVersion: v1
kind: ConfigMap
data:
  haproxy.cfg: "complete file contents" 

Он может содержать весь файл и смонтировать этот файл в каталоге пода

    volumeMounts:
      - mountPath: /usr/local/etc/haproxy
        name: config
  volumes:
    - name: config
      configMap:
        name: env-config-haproxy
        items:
          - key: haproxy.cfg
            path: haproxy.cfg
0 голосов
/ 28 мая 2020

Есть еще одно решение: монтировать файлы как том (с поддержкой облачного хранилища) и подставлять значения при доступе внутри службы, и это решение, которое я бы использовал go по умолчанию.

Решения 1 и особенно 3 добавляют много сложности. Решение 2 тоже может быть хорошим выбором, однако, чтобы выбрать лучший вариант, вам действительно нужно ответить на другой вопрос - как меняются файлы конфигурации и подстановки env по отношению к версиям контейнера приложения?

т.е. когда вы меняете файлы, должны ли все службы получить новые версии?

...