Answers: <p>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 :)</p>
  <p>See <a href="https://kubernetes.io/docs/concepts/workloads/controllers/job/" rel="nofollow noreferrer">this doc</a>.</p>
  <p>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) :</p>
  <pre><code>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
  
  </code></pre>
  <p>And the job :</p>
  <pre><code>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
              - &quot;-c&quot;
              - |
                sleep 15
                influx setup --host http://influxdb-nodeport.influxdb.svc.cluster.local:8086 --org organistation1 --bucket dummy --username user --password user --token token --force &amp;&amp; exit
    backoffLimit: 0
  </code></pre>
  
Answers: CC BY-SA 4.0
Answers: 2021-06-15T16:16:17.097Z
Answers: This does not answer you question - running the two in the same Pod. This answers run the two in different Pods.
Answers: Jonas
Answers: CC BY-SA 4.0
Answers: 2021-06-16T21:44:15.313Z
Answers: 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
Answers: Pier
Answers: CC BY-SA 4.0
Answers: 2021-06-14T13:08:21.387Z
Answers: 2021-06-14T13:08:21.387Z
Answers: Pier
Answers: <p>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'</p>
  <pre><code>  command:
          - sh
          - &quot;-c&quot;
          - |
            /bin/bash &lt;&lt;'EOF'
            influxd&amp;
            sleep 15
            influx setup --org org1 --bucket dummy --username user --password passwd --force
            fg 1
            EOF
  </code></pre>
  
Answers: CC BY-SA 4.0
Answers: 2021-06-14T07:37:50.877Z
Answers: 2023-07-12T19:09:55.047Z
Answers: 2023-07-12T19:09:55.047Z
Answers: Serve Laurijssen
Answers: <p>I think your current approach is probably the correct one. You are just missing a sleep to allow <code>influxd</code> time to actually get running. See <a href="https://devops.stackexchange.com/users/28033/serve-laurijssen">Serve Laurijssen</a> anwser.</p>
  <p>You also could instead run some kind of process manager to handle this like <a href="https://github.com/just-containers/s6-overlay" rel="nofollow noreferrer">s6-overlay</a> but I wouldn't really use it for this example but it is handy in some other situations.</p>
  <p>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.</p>
  <p><a href="https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/" rel="nofollow noreferrer">Container Lifecycle Hooks</a> would probably also work here but its just more complexity then needed. To use <code>PostStart</code> hook you would need to curl <code>http://localhost:8086/api/v2/setup</code> in a loop until you got a good reply and then run your command.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-06-14T07:19:25.933Z
Answers: 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 :)
Answers: Pier
Answers: CC BY-SA 4.0
Answers: 2021-06-14T07:31:36.003Z
Answers: 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.
Answers: Tensibai
Answers: CC BY-SA 4.0
Answers: 2021-06-14T07:44:15.900Z
Answers: 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
Answers: Pier
Answers: CC BY-SA 4.0
Answers: 2021-06-14T20:03:39.603Z
Answers: Thanks, I updated my answer.
Answers: Levi
Answers: CC BY-SA 4.0
Answers: 2021-06-13T07:17:05.777Z
Answers: 2021-06-14T20:02:26.850Z
Answers: 2021-06-14T20:02:26.850Z
Answers: Levi
Answers: <p>Another option is to have multiple entrypoints in a Dockerfile. Example with setting up an nginx reverse proxy.</p>
  <p>First create the script that does the configuring.</p>
  <pre><code>envsubst '${NODE_NAME}' &lt; /etc/nginx/conf.d/default.conf.template &gt; /etc/nginx/conf.d/default.conf
  
  exec &quot;$@&quot;
  </code></pre>
  <p>Add the script to the container in the Dockerfile.</p>
  <pre><code>FROM nginx
  ADD docker-entrypoint.sh /
  ENTRYPOINT [&quot;/docker-entrypoint.sh&quot;]
  CMD [&quot;nginx&quot;, &quot;-g&quot;, &quot;daemon off;&quot;]
  </code></pre>
  <p>Set script as ENTRYPOINT, which will create the config inside the container. Afterwards nginx is started with desired config.</p>
  <p>Maybe it does not work for influx but it's a clean option for a &quot;config and run&quot; container.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-06-15T09:35:41.737Z
Answers: 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...
Answers: Tensibai
Answers: CC BY-SA 4.0
Answers: 2021-06-15T05:54:40.877Z
Answers: 2021-06-15T05:54:40.877Z
Answers: Serve Laurijssen
Body: <p>I am trying to setup an automated influxdb instance using kubernetes, nothing too exotic I thought, but :
  I need to run the &quot;influx setup ....&quot; command for the initial setup, and this needs to be ran after the daemon is started (obviously).</p>
  <p>I tried multiple syntax inside the deploy yaml, here is one attempt:</p>
  <pre><code>    spec:
        containers:
          - name: influxdb-test
            image: influxdb:2.0.7
            command:
              - sh
              - &quot;-c&quot;
              - |
                /bin/bash &lt;&lt;'EOF'
                influxd&amp;
                influx setup --org ORG --bucket dummy --username USER --password USER --force
                EOF
  </code></pre>
  <p>But this gives me the following error :</p>
  <pre><code>Error: failed to determine if instance has been configured: Get &quot;http://localhost:8086/api/v2/setup&quot;: dial tcp 127.0.0.1:8086: connect: connection refused
  See 'influx setup -h' for help 
  </code></pre>
  <p>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.</p>
  <p>I first thought that adding the simple &quot;influx setup&quot; 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.</p>
  <p>Of course I am a k8s newbie.</p>
  <p>I am looking at &quot;init container&quot; as this sounds close to fixing my issue ....</p>
  
Comments: CC BY-SA 4.0
Comments: 2021-06-14T07:32:26.290Z
Comments: Yes you'd need an init container, something 'one-off' starting alongside the daemon container.
Comments: Tensibai
Tags: <kubernetes>
Title: How to run a daemon AND another command in a kubernetes pod
UserDisplayName: Pier
ThreadText: # How to run a daemon AND another command in a kubernetes pod
  
  (Asked by: username_0 on 2021-06-11)
  
  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 ....
  
  **Tags:** kubernetes
  
  > **Comments:**
  > **username_1**: Yes you'd need an init container, something 'one-off' starting alongside the daemon container.  
  
  ---
  
  ## 4 answers
  
  ### Answer by username_0 on 2021-06-14. Score: 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](https://kubernetes.io/docs/concepts/workloads/controllers/job/).
  
  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
  
  ```
  
  > **Comments:**
  > **username_2**: This does not answer you question - running the two in the same Pod. This answers run the two in different Pods.  
  > **username_0**: 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  
  
  ---
  
  ### Answer by username_3 on 2021-06-14. Score: 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 org1 --bucket dummy --username user --password passwd --force
            fg 1
            EOF
  
  ```
  
  
  ---
  
  ### Answer by username_4 on 2021-06-13. Score: 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 [username_3](https://devops.stackexchange.com/users/28033/username_3) anwser.
  
  You also could instead run some kind of process manager to handle this like [s6-overlay](https://github.com/just-containers/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](https://kubernetes.io/docs/concepts/containers/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.
  
  > **Comments:**
  > **username_0**: 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 :)  
  > **username_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.  
  > **username_0**: 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  
  > **username_4**: Thanks, I updated my answer.  
  
  ---
  
  ### Answer by username_3 on 2021-06-15. Score: 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.
  
  > **Comments:**
  > **username_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...  
  
  ---
  
  