kompose - docker remove tag

Cómo imitar ''--volumes-from'' en Kubernetes

Question

Estoy buscando un patrón que permita compartir volúmenes entre dos contenedores que se ejecutan en el mismo pod en Kubernetes.

Mi caso de uso es: Tengo una aplicación Ruby on Rails que se ejecuta dentro de un contenedor acoplable. La imagen de la ventana acoplable contiene elementos estáticos en /app/<app-name>/public directorio /app/<app-name>/public , y necesito acceder a esos elementos desde el contenedor nginx que se ejecuta en paralelo en el mismo contenedor.

En la --volumes-from acoplable "vainilla", habría utilizado --volumes-from flag para compartir este directorio:

docker run --name app -v /app/<app-dir>/public <app-image>
docker run --volumes-from app nginx

Después de leer este documento: https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/volumes.md Intenté esto (solo se presentaron las entradas relevantes):

spec:
  containers:
    - image: <app-image>
      name: <app-name>
      volumeMounts:
        - mountPath: /app/<app-name>/public
          name: assets
    - image: nginx
      name: nginx
      volumeMounts:
        - mountPath: /var/www/html
          name: assets
          readOnly: true
    volumes:
      - name: assets
        hostPath:
          path: /tmp/assets

Pero:

• Aunque /tmp/assets en el nodo existe, está vacío
• /app/<app-name>/public dentro del contenedor de la aplicación también está vacío

Como solución alternativa voy a tratar de completar el directorio compartido cuando el contenedor de la aplicación esté activo (simplemente cp /app/<app-name>/public/* en el directorio compartido), pero realmente no me gusta esta idea.

Pregunta: cómo imitar --volumes-from en Kubernetes, o si no hay una contraparte directa, ¿cómo puedo compartir archivos de un contenedor a otro que se ejecutan en el mismo pod?

apiVersion: v1beta3

Client Version: version.Info{Major:"0", Minor:"17", GitVersion:"v0.17.0", GitCommit:"82f8bdac06ddfacf493a9ed0fedc85f5ea62ebd5", GitTreeState:"clean"}
Server Version: version.Info{Major:"0", Minor:"17", GitVersion:"v0.17.0", GitCommit:"82f8bdac06ddfacf493a9ed0fedc85f5ea62ebd5", GitTreeState:"clean"}

Answer 1

Actualización adicional del futuro :

Ahora hay un complemento de FlexVol para los volúmenes de Docker: https://github.com/dims/docker-flexvol

En el momento de escribir esto, FlexVol sigue siendo una característica alfa, por lo que es una advertencia.

Answer 2

La respuesta es, por ahora, no puedes. Aquí hay un par de temas de discusión de los problemas de Kubernetes:

• https://github.com/GoogleCloudPlatform/kubernetes/issues/6120
• https://github.com/GoogleCloudPlatform/kubernetes/issues/831

Sin embargo, ¿puedo sugerirle que tenga un diseño alternativo que pueda funcionar mejor?

1. Si sus activos están bloqueados en el momento en que el contenedor está en funcionamiento, podría usar algo como el volumen gitRepo que lo copiaría en un emptyDir en el momento de la emptyDir , y significaría que no tendría que mover el contenido en absoluto. , simplemente descárguelo directamente al directorio compartido.
2. Si sus activos están bloqueados en el punto del contenedor que se está construyendo, probablemente sea mejor copiarlos en ese punto, utilizando el comando Docker COPY.
3. Si realmente quieres seguir con la forma en que lo haces, tendrías que copiar el contenido al volumen emptyDir , que está diseñado para exactamente lo que estás buscando (sin la necesidad de tener que copiarlo).

Los volúmenes NFS [1] también podrían resolver su problema, pero pueden ser demasiado complejos.

Además, recomiendo que estos dos servicios existan en diferentes módulos, por lo que puede escalarlos por separado. Puede crear un punto final de servicio para comunicarse entre ellos si lo necesita.

[1] https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/nfs/nfs-web-pod.yaml

Answer 3

[update-2016-8] En la última versión de Kubernetes, puede usar una característica muy bonita llamada init-container para reemplazar la parte postStart en mi respuesta a continuación, que garantizará el orden de los contenedores.

NOTA : initContainer sigue siendo una función beta, por lo que la versión de trabajo de este yaml es realmente así: http://kubernetes.io/docs/user-guide/production-pods/#handling-initialization , por favor, tenga en cuenta el pod.beta.kubernetes.io/init-containers parte.

--- respuesta original comienza ---

En realidad, puedes. Debe usar el controlador de ciclo de vida del contenedor para controlar qué archivos / directorios desea compartir con otros contenedores. Me gusta:

---
apiVersion: v1
kind: Pod
metadata:
    name: server
spec:
    restartPolicy: OnFailure
    containers:
    - image: resouer/sample:v2
      name: war
      lifecycle:
        postStart:
          exec:
            command:
              - "cp"
              - "/sample.war"
              - "/app"
      volumeMounts:
      - mountPath: /app
        name: hostv1 
    - name: peer
      image: busybox
      command: ["tail", "-f", "/dev/null"]
      volumeMounts:
      - name: hostv2
        mountPath: /app/sample.war
    volumes:
    - name: hostv1
      hostPath:
          path: /tmp
    - name: hostv2
      hostPath:
          path: /tmp/sample.war

Por favor revisa mi esencia para más detalles:

https://gist.github.com/resouer/378bcdaef1d9601ed6aa

Y, por supuesto, puedes usar emptyDir. Por lo tanto, el contenedor de guerra puede compartir su /sample.war con el contenedor par sin el directorio / app de Mess Peer.

Si podemos tolerar / app ha sido anulada, será mucho más simple:

---
apiVersion: v1
kind: Pod
metadata:
  name: javaweb-2
spec:
  restartPolicy: OnFailure
  containers:
  - image: resouer/sample:v2
    name: war
    lifecycle:
      postStart:
        exec:
          command:
            - "cp"
            - "/sample.war"
            - "/app"
    volumeMounts:
    - mountPath: /app
      name: app-volume
  - image: resouer/mytomcat:7.0
    name: tomcat
    command: ["sh","-c","/root/apache-tomcat-7.0.42-v2/bin/start.sh"]
    volumeMounts:
    - mountPath: /root/apache-tomcat-7.0.42-v2/webapps
      name: app-volume
    ports:
    - containerPort: 8080
      hostPort: 8001 
  volumes:
  - name: app-volume
    emptyDir: {}