无需 sudo 使用 Podman 在 Linux 上运行容器
Podman 容器

> 
> 配置你的系统使用无根容器。
> 
> 
> 


![](/data/attachment/album/202201/18/033424l111pvcc1iy0a1a1.jpg "Command line prompt")


容器是现代计算的一个重要组成部分，随着围绕容器的基础设施的发展，新的和更好的工具开始浮出水面。过去，你只需用 [LXC](https://opensource.com/article/18/11/behind-scenes-linux-containers) 就可以运行容器，然而随着 Docker 得到了普及，它开始变得越来越复杂。最终，我们在 [Podman](http://podman.io) 得到了我们所期望的容器管理系统：一个无守护进程的容器引擎，它使容器和吊舱易于构建、运行和管理。


容器直接与 Linux 内核能力（如控制组和命名空间）交互，它们在这些命名空间中产生大量的新进程。简而言之，运行一个容器实际上就是在 Linux 系统内部运行一个 Linux 系统。从操作系统的角度来看，它看起来非常像一种管理和特权活动。普通用户通常不能像容器那样自由支配系统资源，所以默认情况下，运行 Podman 需要 root 或 `sudo` 权限。然而，这只是默认设置，而且这绝不是唯一可用的设置。本文演示了如何配置你的 Linux 系统，使普通用户可以在不使用 `sudo` 的情况下（“<ruby> 无根 <rt>  rootless </rt></ruby>”）运行 Podman。


### 命名空间的用户 ID


[内核命名空间](https://opensource.com/article/19/10/namespaces-and-containers-linux) 本质上是一种虚构的结构，可帮助 Linux 跟踪哪些进程属于同一类。这是 Linux 中的“队列护栏”。一个队列中的进程与另一个队列中的进程之间实际上没有区别，但可以将它们用“警戒线”彼此隔离。要声明一组进程为“容器”，而另一组进程为你的操作系统，将它们分开是关键。


Linux 通过用户 ID（UID）和组 ID（GID）来跟踪哪个用户或组拥有的进程。通常情况下，一个用户可以访问一千个左右的从属 UID，以分配给命名空间的子进程。由于 Podman 运行的是分配给启动容器的用户的整个从属操作系统，因此你需要的不仅仅是默认分配的从属 UID 和从属 GID。


你可以用 `usermod` 命令授予一个用户更多的从属 UID 和从属 GID。例如，要授予用户 `tux` 更多的从属 UID 和从属 GID，选择一个还没分配用户的适当的高 UID（如 200000），然后将其增加几千：



```
$ sudo usermod \
    --add-subuids 200000-265536 \
    --add-subgids 200000-265536 \
    tux

```

### 命名空间访问


对命名空间数量也有限制。这通常被设置得很高。你可以用 `systctl`，即内核参数工具来验证用户的命名空间分配：



```
$ sysctl --all --pattern user_namespaces
user.max_user_namespaces = 28633

```

这是很充足的命名空间，而且可能是你的发行版默认设置的。如果你的发行版没有这个属性或者设置得很低，那么你可以在文件 `/etc/sysctl.d/userns.conf` 中输入这样的文本来创建它：



```
user.max_user_namespaces=28633

```

加载该设置：



```
$ sudo sysctl -p /etc/sysctl.d/userns.conf

```

### 在没有 root 权限的情况下运行一个容器


当你设置好你的配置，重启你的计算机，以确保你的用户和内核参数的变化被加载和激活。


重启后，试着运行一个容器镜像：



```
$ podman run -it busybox echo "hello"
hello

```

### 容器像命令一样


如果你是第一次接触容器，可能会觉得很神秘，但实际上，它们与你现有的 Linux 系统没有什么不同。它们实际上是在你的系统上运行的进程，没有仿真环境或虚拟机的成本和障碍。容器和你的操作系统之间的区别只是内核命名空间，所以它们实际上只是带有不同标签的本地进程。Podman 使这一点比以往更加明显，当你将 Podman 配置为无根命令，容器感觉更像命令而不是虚拟环境。Podman 使容器和吊舱变得简单，所以请试一试。




---


via: <https://opensource.com/article/22/1/run-containers-without-sudo-podman>


作者：[Seth Kenlon](https://opensource.com/users/seth) 选题：[lujun9972](https://github.com/lujun9972) 译者：[geekpi](https://github.com/geekpi) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
Containers are an important part of modern computing, and as the infrastructure around containers evolves, new and better tools have started to surface. It used to be that you could run containers with just [LXC](https://opensource.com/article/18/11/behind-scenes-linux-containers), and then Docker gained popularity, and things started getting more complex. Eventually, we got the container management system we all deserved with [Podman](http://podman.io), a daemonless container engine that makes containers and pods easy to build, run, and manage.

Containers interface directly with Linux kernel abilities like cgroups and namespaces, and they spawn lots of new processes within those namespaces. In short, running a container is literally running a Linux system *inside* a Linux system. From the operating system's viewpoint, it looks very much like an administrative and privileged activity. Normal users don't usually get to have free reign over system resources the way containers demand, so by default, root or `sudo`

permissions are required to run Podman. However, that's only the default setting, and it's by no means the only setting available or intended. This article demonstrates how to configure your Linux system so that a normal user can run Podman without the use of `sudo`

("rootless").

## Namespace user IDs


A [kernel namespace](https://opensource.com/article/19/10/namespaces-and-containers-linux) is essentially an imaginary construct that helps Linux keep track of what processes belong together. It's the red queue ropes of Linux. There's not actually a difference between processes in one queue and another, but it's helpful to cordon them off from one another. Keeping them separate is the key to declaring one group of processes a "container" and the other group of processes your OS.

Linux tracks what user or group owns each process by User ID (UID) and Group ID (GID). Normally, a user has access to a thousand or so subordinate UIDs to assign to child processes in a namespace. Because Podman runs an entire subordinate operating system assigned to the user who started the container, you need a lot more than the default allotment of subuids and subgids.

You can grant a user more subuids and subgids with the `usermod`

command. For example, to grant more subuids and subgids to the user `tux`

, choose a suitably high UID that has no user assigned to it (such as 200,000) and increment it by several thousand:

```
$ sudo usermod \
--add-subuids 200000-265536 \
--add-subgids 200000-265536 \
tux
```


## Namespace access

There are limits on namespaces, too. This usually gets set very high, but you can verify the user allotment of namespaces with `systctl`

, the kernel parameter tool:

```
$ sysctl --all --pattern user_namespaces
user.max_user_namespaces = 28633
```


That's plenty of namespaces, and it's probably what your distribution has set by default. If your distribution doesn't have that property or has it set very low, then you can create it by entering this text into the file `/etc/sysctl.d/userns.conf`

:

`user.max_user_namespaces=28633`


Load that setting:

`$ sudo sysctl -p /etc/sysctl.d/userns.conf`


## Run a container without root

Once you've got your configuration set, reboot your computer to ensure that the changes to your user and kernel parameters are loaded and active.

After you reboot, try running a container image:

```
$ podman run -it busybox echo "hello"
hello
```


## Containers like commands

Containers may feel mysterious if you're new to them, but actually, they're no different than your existing Linux system. They are literally processes running on your system, without the cost or barrier of an emulated environment or virtual machine. All that separates a container from your OS are kernel namespaces, so they're really just native processes with different labels on them. Podman makes this more evident than ever, and once you configure Podman to be a rootless command, containers feel more like commands than virtual environments. Podman makes containers and pods easy, so give it a try.

## Comments are closed.