Jenkins中‘container’关键字的功能及使用疑问

Let me break down what's going on with the container() keyword you're using, and why your test didn't behave as expected.

What does container() actually do? #

The container() block is a feature from the Jenkins Kubernetes Plugin (which OpenShift Jenkins relies on for orchestrating pods). Its core purpose is to switch execution of subsequent pipeline steps (like sh, script, etc.) to a specific container within your multi-container Jenkins agent pod.

By default, all pipeline steps run in the pod's default container (usually the jnlp container that acts as the Jenkins agent). This default container is where your code repository gets mounted, which is why your ls command showed your repo files—you were still running commands in the default container, not the az-cli one you intended.

Why your test didn't work #

Your test pipeline likely missed a key detail: you need to explicitly define the multi-container pod configuration in your pipeline's agent block first. If Jenkins doesn't know the az-cli container exists in the pod it's using, the container() block won't switch contexts properly.

Correct Usage Example #

Here's how to properly set up a multi-container pod and use container() to target specific containers:

pipeline {
  agent {
    kubernetes {
      // Define your multi-container pod spec here
      yaml '''
        apiVersion: v1
        kind: Pod
        spec:
          containers:
          - name: az-cli
            image: mcr.microsoft.com/azure-cli:latest
            command: ["sleep", "999999"] # Keep container running
          - name: postgres
            image: postgres:14
            env:
            - name: POSTGRES_PASSWORD
              value: "test_db_pass"
            command: ["postgres"] # Default postgres startup command
      '''
    }
  }
  stages {
    stage('Test az-cli Container') {
      steps {
        container('az-cli') {
          // This runs *inside* the az-cli container
          sh 'az --version'
        }
      }
    }
    stage('Prepare Integration Test DB') {
      steps {
        container('postgres') {
          // This runs *inside* the postgres container
          sh '''
            psql -U postgres -c "CREATE DATABASE test_db;"
          '''
        }
      }
    }
    stage('Run in Default Container') {
      steps {
        // No container() block = runs in default jnlp container
        sh 'ls' # Shows your code repo files
      }
    }
  }
}

Key Notes for OpenShift Jenkins #

• Container Names are Case-Sensitive: Double-check that the name you pass to container() exactly matches the name defined in your pod's spec.
• Containers Must Stay Running: For containers that aren't long-running by default (like az-cli), add a command: ["sleep", "999999"] to keep them alive—Jenkins can't execute commands in a stopped container.
• Verify Pod Configuration: If you're using a pre-configured Jenkins agent pod in OpenShift, confirm that the target container (e.g., postgres, az-cli) is actually part of the pod's spec. You can check this in the OpenShift Console by inspecting the agent pod's details.

Fixing Your Original Test #

Modify your test to run a command that's unique to the az-cli container (like az --version) instead of ls. If the command succeeds and outputs Azure CLI version info, you know the container() block is working correctly. If it throws a "command not found" error, you're still in the default container—double-check your pod spec and container name.

内容的提问来源于stack exchange，提问作者melis