docker 映象中的uid
在Docker映象中，UID（使用者識別符號）的具體數值並不是固定的，它取決於映象的構建方式和構建時指定的使用者配置。以下是對Docker映象中UID的詳細解釋：
UID的分配
- 基礎映象：當從一個基礎映象（如Ubuntu、CentOS等）構建新的Docker映象時，該基礎映象中已經存在的使用者和組會被繼承到新映象中。這些使用者和組的UID和GID（組識別符號）與基礎映象中的設定保持一致。
- 自定義使用者：在Dockerfile中，可以使用
useradd或adduser命令新增新使用者，並透過-u選項指定該使用者的UID。如果沒有明確指定，系統會自動為該使用者分配一個未被使用的UID。UID的作用
- 許可權控制：在Linux系統中，UID用於確定使用者的許可權。不同的UID對應不同的使用者許可權，從而實現對檔案和目錄的訪問控制。
- 程序標識：在Docker容器中執行的程序也會有一個UID。這個UID決定了程序在容器內部和主機系統上的許可權。
UID的修改
- 構建時修改：在Dockerfile中，可以使用
usermod命令修改已有使用者的UID。例如，RUN usermod -u new_uid old_username命令將把名為old_username的使用者的UID修改為new_uid。- 執行時修改：在執行中的容器中，也可以透過
usermod命令修改使用者的UID。但需要注意的是，這種修改只會在當前執行的容器中生效，不會影響映象本身。注意事項
- 避免衝突：在不同的容器中，不應使用相同的UID分配給不同的使用者。因為Linux核心統一管理UID和GID空間，相同的UID在不同容器中會對映到相同的使用者許可權。
- 安全性：為了增強容器的安全性，建議避免以root使用者身份執行容器中的程序。可以透過在Dockerfile中指定非root使用者或使用
--user選項在執行時指定使用者來實現這一點。綜上所述，Docker映象中的UID是一個可變值，它取決於映象的構建方式和構建時指定的使用者配置。因此，無法給出一個固定的UID值來代表所有Docker映象中的使用者。
在Docker中使用自定義UID/GID執行Jenkins
https://bestsrc.com/?p=3625
FROM jenkins/jenkins:latest ARG uid=1003 ARG gid=1003 USER root RUN groupmod -g $gid jenkins && usermod -u $uid -g $gid jenkins USER jenkins
理解 docker 容器中的 uid 和 gid
https://www.cnblogs.com/sparkdev/p/9614164.html
https://www.cnblogs.com/rongfengliang/p/10544093.html
To start, let’s review how uids and gids are implemented. The linux kernel is responsible for managing the uid and gid space, and it’s kernel-level syscalls that are used to determine if requested privileges should be granted. For example, when a process attempts to write to a file, the uid and gid that created the process are examined by the kernel to determine if it has enough privileges to modify the file. The username isn’t used here, the uid is used.
When running Docker containers on a server, there’s still a single kernel. A huge part of the value that containerization brings is that all of these separate processes can continue to share a single kernel. This means that even on a server that is running Docker containers, the entire world of uids and gids is controlled by a single kernel.
So you can’t have different users with the same uid inside different containers. That’s because the username (and group names) that show up in common linux tools aren’t part of the kernel, but are managed by external tools (/etc/passwd, LDAP, Kerberos, etc). So, you might see different usernames, but you can’t have different privileges for the same uid/gid, even inside different containers. This can seem pretty confusing at first, so let’s illustrate it with a few examples:
https://www.elephdev.com/cDocker/294.html?lang=en&ref=addtabs
What does it mean
Now that we have discussed this, it makes sense that all methods of running a container with limited permissions use the host's user system:
If the process in the container is executing a known uid, then it may be as simple as restricting access to the host system so that the uid from the container has limited access.
A better solution is to use --user to start the container with a known uid (you can also use the username, but remember, this is just a more friendly way to provide the uid from the host's username system), Then restrict access to the uid on the host you decide to run the container on.
Because of how the uid and user name (and gid and group name) are mapped from the container to the host, specifying the user under which the containerized process runs can make the process appear to be owned by different users inside and outside the container.
https://cloud.tencent.com/developer/ask/sof/116089540
cannot change
docker build -t my-jenkins --build-arg uid=1003 --build-arg gid=1003 .