2

I am trying to setup an automated influxdb instance using kubernetes, nothing too exotic I thought, but : I need to run the "influx setup ...." command for the initial setup, and this needs to be ran after the daemon is started (obviously).

I tried multiple syntax inside the deploy yaml, here is one attempt:

    spec:
      containers:
        - name: influxdb-test
          image: influxdb:2.0.7
          command:
            - sh
            - "-c"
            - |
              /bin/bash <<'EOF'
              influxd&
              influx setup --org ORG --bucket dummy --username USER --password USER --force
              EOF

But this gives me the following error :

Error: failed to determine if instance has been configured: Get "http://localhost:8086/api/v2/setup": dial tcp 127.0.0.1:8086: connect: connection refused
See 'influx setup -h' for help 

Well I do not need a solution for this specific error, but more a solution about how can I have a daemon running (influxd) and run some command after this daemon (influx setup) and then keep the container up.

I first thought that adding the simple "influx setup" command would be enough, but any command given inside a yaml deploy file overwrite the container initial command (influxd in this case) so I tried to reproduce the whole stuff manually : start the daemon, then run the setup then I am done, but no luck.

Of course I am a k8s newbie.

I am looking at "init container" as this sounds close to fixing my issue ....

1
  • Yes you'd need an init container, something 'one-off' starting alongside the daemon container. – Tensibai Jun 14 at 7:32
2

I finally found some way to achieve this kind of task: Creating a container only for a single and ephemeral job can be achieved through the .... Job API :)

See this doc.

So I now have a deployment for my long living task (influxdb) + a Job definition for my on-time job (influxdb initial setup). Here is an example (I thought that could be useful for someone) :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: influxdb
  namespace: influxdb
spec:
  selector:
    matchLabels:
      app: influxdb
  replicas: 1
  template:
    metadata:
      labels:
        app: influxdb

    spec:
      volumes:
        - name: influxdb-data
          persistentVolumeClaim:
            claimName: nfs-pvc-influx

      containers:
        - name: influxdb-daemon
          image: influxdb:2.0.7
          volumeMounts:
            - mountPath: /home/influxdb/
              name: influxdb-data
          env: 
            - name: INFLUXD_CONFIG_PATH
              value: /etc/influxdb2/
          ports:       
          - containerPort: 8086
            name: pbe
            protocol: TCP

And the job :

apiVersion: batch/v1
kind: Job
metadata:
  name: influxdb-init
  namespace: influxdb
spec:
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: influxdb-init
          image: influxdb:2.0.7
          command:
            - sh
            - "-c"
            - |
              sleep 15
              influx setup --host http://influxdb-nodeport.influxdb.svc.cluster.local:8086 --org organistation1 --bucket dummy --username user --password user --token token --force && exit
  backoffLimit: 0
2
  • This does not answer you question - running the two in the same Pod. This answers run the two in different Pods. – Jonas Jun 15 at 16:16
  • Yes you are correct, but this is, at least, a possible way to run this somewhat classic use case. Please fell free to give a better answer and I will very happily select it as the correct answer – Pier Jun 16 at 21:44
1

Since influxd is running background it will have a job id of 1 (check with the command 'jobs') So I think all you need to do is bring back influxd to the foregroud after the setup with 'fg 1'

  command:
        - sh
        - "-c"
        - |
          /bin/bash <<'EOF'
          influxd&
          sleep 15
          influx setup --org aryballe --bucket dummy --username aryadmin --password aryadmin --force
          fg 1
          EOF
0

I think your current approach is probably the correct one. You are just missing a sleep to allow influxd time to actually get running. See Serve Laurijssen anwser.

You also could instead run some kind of process manager to handle this like s6-overlay but I wouldn't really use it for this example but it is handy in some other situations.

I don't think init container would work for you because it runs before the main container and is supposed to be a short lived command.

Container Lifecycle Hooks would probably also work here but its just more complexity then needed. To use PostStart hook you would need to curl http://localhost:8086/api/v2/setup in a loop until you got a good reply and then run your command.

4
  • 1
    Hi Levy, and thanks for your answer, unfortunately this does not work, the container enters a crashLoopBackOff state (I actually tried this already but I forgot to add it to my initial post). I didn't tried your other solution as I'd really want to keep this simple. Any other ideas would be great :) – Pier Jun 14 at 7:19
  • 1
    This can't work as it detach the daemon process from the shell, so once the setup is done the container just stops, because the shell close. – Tensibai Jun 14 at 7:31
  • 1
    Yep, I just found a different approach (not tested yet) by using another container to run the initial setup, this might work eventhough i'd love to find a generic solution for running command into a daemon-driven conatiner, if anyone knows that i'd take it – Pier Jun 14 at 7:44
  • Thanks, I updated my answer. – Levi Jun 14 at 20:03
0

Another option is to have multiple entrypoints in a Dockerfile. Example with setting up an nginx reverse proxy.

First create the script that does the configuring.

envsubst '${NODE_NAME}' < /etc/nginx/conf.d/default.conf.template > /etc/nginx/conf.d/default.conf

exec "$@"

Add the script to the container in the Dockerfile.

FROM nginx
ADD docker-entrypoint.sh /
ENTRYPOINT ["/docker-entrypoint.sh"]
CMD ["nginx", "-g", "daemon off;"]

Set script as ENTRYPOINT, which will create the config inside the container. Afterwards nginx is started with desired config.

Maybe it does not work for influx but it's a clean option for a "config and run" container.

1
  • That won't work, here the daemon has to be started before the script is executed. You're answering another question than the one asked here... – Tensibai Jun 15 at 9:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.