# How do build agent containers work together?

**URL:** <https://community.jenkins.io/t/how-do-build-agent-containers-work-together/29033>\
**Category:** Using Jenkins\
**Tags:** docker\
**Created:** [March 28, 2025, 12:55pm UTC](https://community.jenkins.io/t/how-do-build-agent-containers-work-together/29033 "2025-03-28T12:55:55Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![jeremyinfries](https://dub1.discourse-cdn.com/flex013/user_avatar/community.jenkins.io/jeremyinfries/32/13985_2.png) [@jeremyinfries](https://community.jenkins.io/u/jeremyinfries)\
**Post date:** [March 28, 2025, 12:55pm UTC](https://community.jenkins.io/t/how-do-build-agent-containers-work-together/29033/1 "2025-03-28T12:55:55Z")

</div>

Jenkins setup:  
Jenkins is running on an EKS cluster and has several agents defined. I am building a Java jar, testing it and then building a container which gets pushed to ECR. Here is my agent setup:

```auto
kind: Pod
spec:
  containers:
    - name: maven
      image: maven:3.9.9-amazoncorretto-21-alpine
      command:
        - cat
      tty: true
    - name: kaniko
      image: gcr.io/kaniko-project/executor:debug
      command:
        - /busybox/cat
      tty: true

```

I am trying to understand how the containers work together - for instance I need to authenticate to ECR to be able to push the container.

What is the best practice here and how do I make sure the jar created in the “maven” container is available for the kaniko container so it can build the docker image?

---

<div class="post-metadata">

**Author:** ![markbosire](https://dub1.discourse-cdn.com/flex013/user_avatar/community.jenkins.io/markbosire/32/13445_2.png) [@markbosire](https://community.jenkins.io/u/markbosire)\
**Post date:** [March 28, 2025, 2:33pm UTC](https://community.jenkins.io/t/how-do-build-agent-containers-work-together/29033/2 "2025-03-28T14:33:21Z")

</div>

You could use a dynamically provisioned PVC this way you can still follow best practices by having fungible agents and having a persistent volume that will be provisioned dynamically with little manual configuration and those persistent volumes are independent of the pods:

> **[Dynamically Provisioning Persistent Volumes with Kubernetes | Rafay](https://rafay.co/the-kubernetes-current/dynamically-provisioning-persistent-volumes-with-kubernetes/)**
>
> Explore our recent post Dynamically Provisioning Persistent Volumes with Kubernetes from the Kubernetes Current blog. Read our thoughts on all things Kubernetes and stay current on the latest news from Rafay.

> **[Persistent storage for Kubernetes  | Amazon Web Services](https://aws.amazon.com/blogs/storage/persistent-storage-for-kubernetes/)**
>
> Stateful applications rely on data being persisted and retrieved to run properly. When running stateful applications using Kubernetes, state needs to be persisted regardless of container, pod, or node crashes or terminations. This requires persistent...

---

<div class="post-metadata">

**Author:** ![jeremyinfries](https://dub1.discourse-cdn.com/flex013/user_avatar/community.jenkins.io/jeremyinfries/32/13985_2.png) [@jeremyinfries](https://community.jenkins.io/u/jeremyinfries)\
**Post date:** [March 28, 2025, 9:10pm UTC](https://community.jenkins.io/t/how-do-build-agent-containers-work-together/29033/3 "2025-03-28T21:10:18Z")

</div>

My issue is not with the artifacts (although I like the idea of passing them via a volume), it’s with the config.

For instance, Kaniko uses busybox so I can’t install the AWS CLI so how do I push the container I create to ECR? There are some ugly workarounds I’ve seen but this shouldn’t be that difficult since the whole reason for Kaniko to exist is to create containers.

---

<div class="post-metadata">

**Author:** ![markbosire](https://dub1.discourse-cdn.com/flex013/user_avatar/community.jenkins.io/markbosire/32/13445_2.png) [@markbosire](https://community.jenkins.io/u/markbosire)\
**Post date:** [March 29, 2025, 12:54am UTC](https://community.jenkins.io/t/how-do-build-agent-containers-work-together/29033/4 "2025-03-29T00:54:34Z")

</div>

In terms of artifact sharing you can use the pvc we discussed or a shared volume(to retreive the jar file). In terms of pushing to ecr you do not need to install aws cli kaniko has a built in way to build and push to ecr.  
Refer to this:

> **[GitHub - GoogleContainerTools/kaniko: Build Container Images In Kubernetes](https://github.com/GoogleContainerTools/kaniko?tab=readme-ov-file#pushing-to-amazon-ecr)**
>
> Build Container Images In Kubernetes

and this:

> **[Kaniko | Jenkins | Kubernetes | How To Build Docker Image Using Kaniko](https://rainoraphel.medium.com/kaniko-jenkins-kubernetes-how-to-build-docker-image-using-kaniko-2d6712e0458f)**
>
> In this demo we will be using Kaniko for building container images and using Jenkins we will push to AWS ECR (Container Registry)

For Kaniko to push to ECR, it needs to authenticate. There are two approaches:

Using Instance Roles :

Configure your EKS node with appropriate IAM roles that have ECR permissions  
Set the AWS\_SDK\_LOAD\_CONFIG=true environment variable in your Kaniko container

Using AWS Credentials:

Create a Kubernetes secret with your AWS credentials  
Mount the secret to the Kaniko container

The --context=dir://. tells Kaniko to use the current directory as the build context  
This allows it to access the JAR file built by Maven.

So by using a shared volume you get to retreive the jar from maven container and if you configure your dockerfile and kaniko context the jar file will be available during build. You can push it to ecr using the recommended kaniko executor referenced in the documentation.

Check out the docs and article above and update me on whether this would work