2015-10-09 3 views
0

При использовании тома gitRepo в Kubernetes репо клонируется в каталог mountPath. Для следующей спецификации стручок, например:Указание пути монтирования gitRepo в Kubernetes

apiVersion: v1 
kind: Pod 
metadata: 
    name: server 
spec: 
    containers: 
    - image: nginx 
    name: nginx 
    volumeMounts: 
    - mountPath: /usr/share/docroot 
     name: docroot-volume 
    volumes: 
    - name: docroot-volume 
    gitRepo: 
     repository: "[email protected]:me/my-git-repository.git" 

каталог появится в контейнере в/USR/доли/DOCROOT/My-ГИТ-хранилище. Это означает, что мой контейнер должен знать мое имя репозитория. Я не хочу, чтобы мой контейнер знал что-либо о имени репозитория. Он должен просто знать, что есть «docroot», однако инициализированный. Единственное место, где должно отображаться имя репозитория git, указано в спецификации pod.

Есть ли в Kubernetes, чтобы указать полный внутренний путь к монтированию тома git repo?

ответ

0

В настоящее время нет никакого способа для этого, но я подал вам issue.

Under the hood kuberetes просто выполняет git clone $source над томом emptyDir, но поскольку источник передается как один аргумент, невозможно указать имя получателя.

Fri, 09 Oct 2015 18:35:01 -0700 Fri, 09 Oct 2015 18:49:52 -0700 90 {kubelet stclair-minion-nwpu}  FailedSync Error syncing pod, skipping: failed to exec 'git clone https://github.com/kubernetes/kubernetes.git k8s': Cloning into 'kubernetes.git k8s'... 
error: The requested URL returned error: 400 while accessing https://github.com/kubernetes/kubernetes.git k8s/info/refs 
fatal: HTTP request failed 
: exit status 128 

В то же время, я могу думать о 2-х вариантов, чтобы избежать зависимости от имени репозитория:

  1. Поставка имени репозитория в качестве environment variable, который затем можно использовать из вашего контейнера
  2. Измените containers command, чтобы переместить хранилище в нужное место до продолжения
+0

Спасибо. Я предпочитаю второй метод, так как это сохраняет изображение, не знающее, как данные вставляются. Это означает, что я должен выяснить и скопировать существующую команду контейнера в свою собственную команду. Было бы удобно иметь контейнер инициализации контейнера, который будет запускаться один раз между инициализацией pod и обычными контейнерами контейнера, чтобы следить за всей необходимой инициализацией (например, исправлениями прав и т. Д.). На самом деле массив инициализаторов будет еще лучше. – Bradley

+0

Я верю, что вы просите о «предзапуске», описанном здесь (http://kubernetes.io/v1.0/docs/user-guide/container-environment.html#hook-details). К сожалению, перехваты - это незавершенная работа, и дозапуск еще не реализован. –

Смежные вопросы