Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-54427

Support sidecar containers

    XMLWordPrintable

Details

    Description

      When using jenkinsfile-runner inside Kubernetes such as with Prow/Knative Build in Jenkins X it would be awesome to be able to replicate the kubernetes-plugin style execution of commands in sidecars all from within the exact same pod. e.g.

       

      sh "echo this runs in the same container as the jenkinsfile runner"
      container("selenium") {
         sh "echo this runs in the selenium container"
      } 

      When using pure knative build steps this stuff all works already; but its not yet supported in a Jenkinsfile.

      I understand that the jenkinsfile runner is just 1 container that runs & isn't gonna be able to grok the sidecar containers - but thats fine - we can configure that stuff outside of the jenkisnfile + jenksinfile-runner - but it'd be nice to be able to execute commands in sidecar containers (e.g. via the shell command:

      kubectl exec -it $HOSTNAME -c selenium -- echo "this runs in the selenium continaer" 

       

       

      Attachments

        Issue Links

          Activity

            oleg_nenashev Oleg Nenashev added a comment - https://github.com/jenkinsci/remoting/pull/286   is probably a prerequisite
            jglick Jesse Glick added a comment -

            Or we could improve the kubernetes plugin to use a different launch method, say based on the WebSocket underlying kubectl exec, rather than using the JNLP connector. Then there is no need for the jenkinsfile-runner container to expose any ports at all.

            At any rate, jstrachan should understand that in the currently working versions of this, it does not look like the example given in the issue description. Rather, no sh steps may be run in the jenkinsfile-runner container (we set the numExecutors: 0 to emphasize this), and to do any work you use the podTemplate step which launches a separate pod, inside of which you may use node with a label to select the container for the slave.jar, and then container to actually use the desired container. The resulting Pipeline script is rather cumbersome, and the scheduling is inefficient, which is why I would like to deprecate this whole system and introduce an alternative direct-launch step akin to dockerNode in docker-plugin but creating a single-container pod instead.

            jglick Jesse Glick added a comment - Or we could improve the kubernetes plugin to use a different launch method, say based on the WebSocket underlying kubectl exec , rather than using the JNLP connector. Then there is no need for the jenkinsfile-runner container to expose any ports at all. At any rate, jstrachan should understand that in the currently working versions of this, it does not look like the example given in the issue description. Rather, no sh steps may be run in the jenkinsfile-runner container (we set the numExecutors: 0 to emphasize this), and to do any work you use the podTemplate step which launches a separate pod, inside of which you may use node with a label to select the container for the slave.jar , and then container to actually use the desired container. The resulting Pipeline script is rather cumbersome, and the scheduling is inefficient, which is why I would like to deprecate this whole system and introduce an alternative direct-launch step akin to dockerNode in docker-plugin but creating a single-container pod instead.
            oleg_nenashev Oleg Nenashev added a comment -

            vilacides FYI there are JFR issues outside JENKINS-54342. Somebody needs to scrub them

            oleg_nenashev Oleg Nenashev added a comment - vilacides FYI there are JFR issues outside JENKINS-54342 . Somebody needs to scrub them

            People

              Unassigned Unassigned
              jstrachan James Strachan
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated: