Kubernates InfluxDB 2 setup script

Really confused about why my setup script isn’t working. It appears to say it is running in the logs (just that it is executing them) but the changes are not shown in the system. I have the normal setup environment variables set and those work. I have confirmed the .sh script is executable and I even remoted into the pod to run it myself. I even ran the commands from influxdb entrypoint.sh script itself to see if I was missing something there. I am setting up a down sample bucket and apply the stack of tasks and alerts to the system. It is only a couple of commands. Oddly enough when editing the script to remove comments and running again I missed some line wrappers and the script failed when I ran it on the cli. These errors should have halted the program. So I am thinking that although run-parts is running it on the cli (on the pod) it is not doing it in entrypoint.sh.

Hi @kramik1,

Can you give us a little more detail about your setup? Are you using our helm-charts, or something else? Can you share your setup script?

1 Like

Sure. It is the same script that works in docker too. It is just a simple command to create another bucket for downsamples and to apply the tasks and alerts. What is your preferred way to support kubenates? Straight container or helm? My scripts are being loaded as configmap volumes. My env configmap has all of the setup data in it. I was using projection at first but that creates symlinks so I did individual mounts to see if it worked instead. It works when I get a cli session within the pod even using the same exact command that the entrypoint script uses. The entrypoint script just doesn’t seem to see it for some reason.

apiVersion: apps/v1
kind: Deployment
  namespace: crec
  name: influxdb2
    app: influxdb2
  replicas: 1
      app: influxdb2
        app: influxdb2
        - name: influxdb2
          image: docker.io/influxdb:2.0.6
          - configMapRef:
              name: influxdb2-env
          - secretRef:
              name: influxdb2-secrets
            - containerPort: 8086
              name: server
              protocol: TCP
            - mountPath: /var/lib/influxdb2
              name: var-lib-influxdb2
            - mountPath: /docker-entrypoint-initdb.d/init-stack.sh
              name: entry-initdb-init-sh
              subPath: init-stack.sh
            - mountPath: /docker-entrypoint-initdb.d/ds-tasks.yaml
              name: entry-initdb-init-ds
              subPath: ds-tasks.yaml
            - mountPath: /docker-entrypoint-initdb.d/check-tasks.yaml
              name: entry-initdb-init-checks
              subPath: check-tasks.yaml
        - name: var-lib-influxdb2
            claimName: influxdb2-pvc
        - name: entry-initdb-init-sh
            name: influxdb2-init
            defaultMode: 0544
        - name: entry-initdb-init-ds
            name: influxdb2-ds-tasks
        - name: entry-initdb-init-checks
            name: influxdb2-check-tasks
apiVersion: v1
kind: ConfigMap
  namespace: crec
  name: influxdb2-init
    app: influxdb2
  init-stack.sh: |-

    set -e

    influx bucket create -n crec_wte_ds -o crec -r 52w

    influx apply -o crec --quiet --force true \
    -f ./docker-entrypoint-initdb.d/ds-tasks.yaml \
    -f ./docker-entrypoint-initdb.d/check-tasks.yaml

Thanks for any help.

@mhall119 do you think I should open a bug report on this issue? Can someone there replicate this in Kubernates?

@kramik1 can you check:

  1. Does influxdb2-env or influxdb2-secrets set DOCKER_INFLUXDB_INIT_MODE=setup?
  2. When you look in /docker-entrypoint-initdb.d/ in the running pod, does your .sh script have executable permissions?

Yes it is set. The logs show it going into setup mode. It finds the script but will not run it. It works in docker-compose but not k8.

I have CLI into the container and it is marked as executable. I can run it without issue after the container is started. I had to adjust the k8 yaml so that it was not linked but directly mounted in the container.

It is really weird that it runs in docker without issue but not k8. It outputs the log message in the function that only runs if it sees the executable. I could work around it and do a container init script in k8s to get around it I think.