【发布时间】:2016-06-22 16:24:34
【问题描述】:
在 Docker 容器中运行 Composer 时,我有一个基本问题。
可以在容器内以用户root 的身份运行composer 吗?
我很困惑创建文件的所有者(例如使用composer require时)是root。
在容器内以root 的身份运行好吗?
【问题讨论】:
标签: docker composer-php root user-permissions
在 Docker 容器中运行 Composer 时,我有一个基本问题。
可以在容器内以用户root 的身份运行composer 吗?
我很困惑创建文件的所有者(例如使用composer require时)是root。
在容器内以root 的身份运行好吗?
【问题讨论】:
标签: docker composer-php root user-permissions
在容器内使用 root 是可以的,因为容器有很多被丢弃的权限。它无法访问硬件或安装路径。它本质上是一个非特权用户。
安装应用程序绝对应该在容器内完成。构建映像的Dockerfile 必须首先安装应用程序,这发生在容器内。如果您使用容器运行使用 node 等构建的自定义应用程序(例如 php7),执行安装的构建容器是将应用程序的更新和安装行为与主机系统隔离的正确方法。
在使用 Docker 部署应用程序时,基本上任何东西都不应该在容器之外运行。例如,任何cron 脚本都应运行docker exec container script.sh 或类似的脚本以在容器内运行定期作业。
一般来说,如果应用程序需要 root 权限来执行基于配置的更新模块之类的操作,我使用 docker-compose 建立一个 build 容器,该容器以 root 身份执行所有这些操作,然后退出。我对实际的应用程序容器使用cap-drop 部分,以删除尽可能多的功能。
许多应用程序需要setuid 或setgid 才能删除权限,例如nginx 需要这些,因此它可以从 root 更改为 www-data:www-data。如果nginx 以用户www-data 的身份出现,它将失败。应用程序应该在自己进行更改后放弃这些功能。
【讨论】:
docker 容器应该只用于运行应用程序。安装应用程序的任何事情都应该在容器之外完成。
您通常提供将容器指向存储在某处的生产文件的配置。这也是 Composer 安装的任何东西的入口点。容器本身应该在任何地方都没有写入权限,任何缓存目录除外。
【讨论】: