Docker supports ADDing and COPYing files to an image with different from root user, but there is no way do it through jib

[tjupi-gh]

Environment: Ubuntu, jdk11, maven, skaffold (spring's devtools for live reloading), k8s

• Jib version: 2.8.0
• Build tool: maven
• OS: Ubuntu 20.04.2

Description of the issue:

Direct: Docker supports ADDing and COPYing files to an image with different from root user, but there is no way do it through jib. I would like to specify uid:gid as 1000:3000 for files of my exploded Java application.

Setting container.user does something different.

Indirectc: Skaffold enables dev command which monitors for changes and copy it to running container on Kubernetes. Containers in a pod are configured and running as not root (1000:3000). So skaffold fails copying changes.

WARN[0187] Skipping deploy due to sync error: copying files: running [kubectl REDUCTED -i -- tar xmf - -C / --no-same-owner]

• stdout: ""
• stderr: "tar: removing leading '/' from member names\ntar: can't remove old file app/classes/com/tjupi/workshop/k8sjava/Application.class: Permission denied\ncommand terminated with exit code 1\n"
• cause: exit status 1

Expected behavior:
There is a way add files as not root user.

Steps to reproduce:

1. Build any application image
2. Come in to container and verify uid:gid /app directory owner

jib-maven-plugin Configuration:

PASTE YOUR pom.xml CONFIGURATION HERE

jib-gradle-plugin Configuration:

PASTE YOUR build.gradle CONFIGURATION HERE

Log output:

Additional Information:

[chanseokoh]

Hi @tjupi-gh! We do recognize this Skaffold use case justifies changing file ownership: #1257 (comment)

however, we'd want Jib to be seamlessly integrated with Skaffold, so your argument below is very compelling.

I am trying to combine jib with skaffold's file sync capability so that when a Java file is changed during the dev cycle, the whole image doesn't need to be rebuilt. I can do a mvn compile and then the changed class file will be synced into the running container and live reloaded by the Tomcat server.

The way we support this use case is through an extension. Check out the linked issue to find out how to use it.

Closing as a dup of #1257.

[tjupi-gh]

If this is (immutability -> root ownership) best practices then nothing to change.

btw. for sure the issue could be worked around by templating with kustomize or helm so if started by skaffold then securityContext.privileged is set accordingly