I've been looking for a way to create a persistent volume claim that has files pre-loaded into it from the host machine. I know this can be done using the hostPath parameter on a

volume

module, but since this not supported for real kubernetes clusters, I was trying to find a more portable approach. The use case is that we'd like to load some startup scripts for a containers from a

scripts

folder in our Git repo. Right now, we are using a

configmap

since mounting this as a volume will convert all of the key/values from the

data

section into mounted files - however, this approach forces us to in-line our bash script as yaml text, and this prevents our linters from being able to catch bash scripting issues. Additionally - while I know that this can also be done by specifying a custom Dockerfile which copies in files from the module build directory, we're trying to avoid the "pull image -> copy files/build new image -> republish" cycle that this causes since we have a very large number of containers that are built from a template and are working on reducing the deployment times. Here's a reference template for what I'm trying to do:

kind: ModuleTemplate
name: service-template
inputsSchemaPath: schema.json
modules:
  # We'd like to pre-load some scripts into the persistent volume created by this claim
  - name: "${inputs.serviceName}-scripts-pvc"
    type: persistentvolumeclaim
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi

  - type: container
    name: ${inputs.serviceName}-container
    image: "${inputs.imageName}"
    services:
      - name: "${inputs.serviceName}-http"
        command:
            - bash
            - /scripts/startup.sh
        volumes:
          - name: scripts-pvc
            containerPath: "/scripts"
            module: "${inputs.serviceName}-scripts-pvc"

Hi Brett! I am on vacation from today and delegating to @glamorous-caravan-26619

hello @quaint-librarian-55734

I had a suspicion that something like this would be the approach - thank you so much for the example, this is immensely helpful!

I'll make a nice readme tomorrow, but in the mean time: - clone -

garden deploy

-

garden test-lib

- you should see the output of the test script which is mounted on app - then edit

lib/src/scripts/test

-

garden update-lib

-

garden test-lib

(again) - you should now see the changed output with your edit

Yep - understood

hey @quaint-librarian-55734, I made another example if using artifacts, build dependencies and a build command on a exec module to just bake the scripts into a consuming container rather than using a volume to share them, in most cases this feels more like The Kubernetes Way (tm) as sharing the volume kinda breaks the idea of immutability