как получить доступ к содержимому изображения в init контейнера kubernetes - PullRequest
Новая
       16

как получить доступ к содержимому изображения в init контейнера kubernetes

0 голосов
/ 20 мая 2019

У меня есть изображение, которое содержит данные внутри / usr / data / webroot.Эти данные должны быть перемещены при инициализации контейнера в /var/www/html.

Теперь я наткнулся на InitContainers.Насколько я понимаю, его можно использовать для выполнения задач по инициализации контейнера.

Но я не знаю, выполняется ли задание после создания модулей amo-magento, или если запускается задача init, и после этого создаются модули magento.

IПредположим, что контейнер с изображением magento недоступен при запуске задачи initContainers, поэтому содержимое для перемещения в новый каталог недоступно. 

apiVersion: apps/v1
kind: Deployment
metadata:
  name: amo-magento
  labels:
    app: amo-magento
spec:
  replicas: 1
  selector:
    matchLabels:
      app: amo-magento
  template:
    metadata:
      labels:
        app: amo-magento
        tier: frontend
    spec:
      initContainers:
        - name: setup-magento
          image: busybox:1.28
          command: ["sh", "-c", "mv -r /magento/* /www"]

          volumeMounts:
            - mountPath: /www
              name: pvc-www

            - mountPath: /magento
              name: magento-src

      containers:
        - name: amo-magento
          image: amo-magento:0.7 # add google gcr.io path after upload
          imagePullPolicy: Never

          volumeMounts:
            - name: install-sh
              mountPath: /tmp/install.sh
              subPath: install.sh

            - name: mage-autoinstall
              mountPath: /tmp/mage-autoinstall.sh
              subPath: mage-autoinstall.sh

            - name: pvc-www
              mountPath: /var/www/html

            - name: magento-src
              mountPath: /usr/data/webroot

            # maybe as secret - can be used as configMap because it has not to be writable
            - name: auth-json
              mountPath: /var/www/html/auth.json
              subPath: auth.json

            - name: php-ini-prod
              mountPath: /usr/local/etc/php/php.ini
              subPath: php.ini

#            - name: php-memory-limit
#              mountPath: /usr/local/etc/php/conf.d/memory-limit.ini
#              subPath: memory-limit.ini

      volumes:
        - name: magento-src
          emptyDir: {}

        - name: pvc-www
          persistentVolumeClaim:
            claimName: magento2-volumeclaim

        - name: install-sh
          configMap:
            name: install-sh

        # kubectl create configmap mage-autoinstall --from-file=build/docker/mage-autoinstall.sh
        - name: mage-autoinstall
          configMap:
            name: mage-autoinstall

        - name: auth-json
          configMap:
            name: auth-json

        - name: php-ini-prod
          configMap:
            name: php-ini-prod

#        - name: php-memory-limit
#          configMap:
#            name: php-memory-limit

1 Ответ

1 голос
/ 20 мая 2019

Но я не знаю, выполняется ли задание после создания модулей amo-magento, или если запускается задача init, и после этого создаются модули magento.

Конечно, последнее, поэтому вы можете указать совершенно другое image: для вашей задачи initContainers: - они связаны друг с другом только в том, что они работают на одном узле и, как вы видели, делитесь объемами. Ну, я сказал «точно», но у вас есть небольшое неправильное значение: после этого создаются magneto контейнеры - Pod - это коллекция каждого контейнера с колокейшн initContainers: и container: контейнеры

Если я понимаю ваш вопрос, исправление для вашего Deployment состоит в том, чтобы просто обновить image: в вашем initContainer: до того, который содержит магию /usr/data/webroot, а затем обновить команду оболочки, указав правильную Путь внутри этого изображения: 

  initContainers:
    - name: setup-magento
      image: your-magic-image:its-magic-tag
      command: ["sh", "-c", "mv -r /usr/data/webroot/* /www"]
      volumeMounts:
        - mountPath: /www
          name: pvc-www
        # but **removing** the reference to the emptyDir volume

и затем к моменту запуска container[0] PVC будет содержать ожидаемые вами данные

Тем не менее, я на самом деле почти уверен , что вы хотите удалить PVC из этой истории, поскольку - по определению - он постоянен при перезагрузке Pod и, таким образом, со временем будет накапливать файлы ( поскольку ваша команда sh в настоящее время не очищает /www перед перемещением туда файлов). Если вы замените все эти pvc ссылки на emptyDir: {} ссылки, то эти каталоги всегда будут «свежими» и всегда будут содержать только содержимое тегового изображения, объявленного в вашем initContainer:

...