by Devin Yang

建立于: 7年前 ( 更新: 7年前 )

D-Laravel的fpm image在php 7.2.1以前是使用docker php官方的dockerfile重build的,
所以我可以指定了fpm的默认的owner是dlaravel,
  --with-fpm-user=USER    Set the user for php-fpm to run as. (default: nobody)
  --with-fpm-group=GRP    Set the group for php-fpm to run as.

不过新版的D-Laravel已改采官方build好的image(而不是官方的Image的dockerfile改写后重build),
而官方默认的fpm运行使用者是www-data,这会造成D-Laravel在Linux的使用者在运行Laravel时出现,
无法写storage的情况,

因此,目前最新版的docker-compose-normal.yml及docker-ocmpose-random.yml默认已直接挂载www.conf罗,
方便大家依需求自行调整,安全考量,我们可以唯持www.conf的设置是www-data,
并且进入contianer中,将需要让php进程可上传或变更的数据夹owner都变更为www-data,
或是简单点,让fpm使用者为dlaravel即可正常运行Laravel在container上。

在Linux的环境中,如果您host端,运行container的使用者gid及uid不是1000,
我们可用D-Laravel的./console命令, ./console chowner 进行调整即可。
如果您是Linux的使用者,您可以输入 id 查看,您的uid及gid是否为1000,
当如下图都为1000时,您不需运行 ./console chowner 即可正常使用最新版本的d-laravel。

uid and gid

运行./console chowner,这样可调整FPM所运行与container内的使用者及Host端的使用者uid是一致的。
说白了,让fpm php有权限有权写文件到我们建的laravel的project
当然重点你的www.conf中运行的owner也需要设置为dlaravel。
https://github.com/DevinY/dlaravel/blob/master/etc/php-fpm.d/www.conf

直击 ./console chowner 干了什么事:
./console chowner

1.检测使用者的平台是否为Linux,是Linux才需进行。
2.取得目前使用者在Linux上的uid及gid。
3.透过 docker-compose 运行 container 内的命令,这里的( exec php )指的是运行 container 所运行的 php service
也就是说在 php fpm container 内运行了 usermod -u groupmod -g 的命令,
他用来将container内的dlaravel使用者的uid及gid调整成与Host端使用者的uid及guid一致。
4.最后chowner,将container内的/home/dlaravel目录,变更为新的使用者权限。

请记得,在 docker-compose 的环境, docker-compose down 时,
container 会被移除, up 时,依image为样版(只读)创建并运行 contaienr
也就是说每次的up都是一个全新的环境(image样版是只读的)。
./console down

因此确保我们下一次启动时,不用再做一次上面的 ./console chowner 动作,
我们应该将 container 的变更 commit 成一个新的 image ,并且使用该image,
这样下次启动时才会保留最新的设置。
docker-compose.yml
如果不想调整 docker-compose.yml image 的名称,我们可以直接把他 commit 成相同的名称即可,例如: deviny/fpm:7.2.1 (请依您所用的 image 调整)。

关於php的fpm短的container id,可以用如下命令查询
docker ps |grep php_1
例如:commint最新的设置到自己的image名称:
commit


Docker在Linux环境上是使用Linux核心内建的命名空间及cgroup用来限制,控制与分离一个行程群组的资源(如CPU、内存、磁盘输入输出等),相较於MacOS(Unix环境),他透过HyperKit虚拟化技术来运行Docker,
在Linux环境上,使用核心原生的功能,性能可以快很多(一个是内建在核心的一个是HyperKit虚拟的),

这也是为何D-Laravel的使用者在MacOs上运行都很正常,在Linux上可能需要进行额外的权限设置调整的原因。

最后,关於本文中,我指的安全考量是,我们通用的user帐号是有bash的权限,以Linux的服务来说,
不会有shell,因为不需让使用者登录shell,
所以www-data的服务,没有shell的权限,相对来说是较安全的。
我们可以简单的cat container内的etc/password来瞧瞧:
$ cat /etc/passwd|grep www
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin

如果您在MacOS或Linux上运行D-Laravel碰到什么困难,欢迎到D-Laravel的粉丝团评论哦,
我会尽可能帮您解决或解答的,如果您喜欢D-Laravel,请帮我在D-Laravel的repo压个Star,谢谢您。
https://github.com/DevinY/dlaravel

Tags: docker dlaravel

Devin Yang

文章内容无法一一说明,如果您有什么不了解处,欢印提问哦:)

No Comment

Post your comment

需要登入才可留言!

类似文章


docker, tinkerwell, tinker, laravel

Tinkerwell与docker环境运用

其实我最近不用Tinkerwell了,因为老是要我花钱更新。要测试直接ssh 主机不就搞定啦不是?

docker,cli

Docker容器格式化显示

我觉的如果要写一些自动化功能,或许能够格式化的输出容器内容还满有用的。以下一些Docker容器格式化显示命令的参考范例

linux,docker

如何在Container内运行X client及X Window简介(docker gui)

今天来跟大家谈谈X,不是iPhone X,也不是X战警哦 ,而是X Window System, 他是目前Linux系统主要的图形化界面显示组件。 由於他非常易於扩展及模块化,打从1986年创建,就一直使用至今。 X Window系统采用的为Client / Server的架构,把应用进程跟显示拆分为二, X Windows的应用进程通常我们称为X Client,而显示则是大家所熟知的X Server。 X client与X server透过X协议(X protocol)沟通,这是一个异步的网络通信协议。