Nginx WordPress FPM EFS图片404解决方法

本文针对Kubernetes环境下，Nginx与WordPress FPM共用Pod，图片存储于EFS并通过符号链接至wp-content/uploads时出现404错误的问题，提供解决方案。核心在于确保Nginx容器能够访问EFS存储，避免因符号链接导致的文件访问权限问题。通过正确配置容器挂载点，保证两个容器均可访问EFS，从而解决图片无法加载的问题。

在使用Nginx和WordPress FPM在Kubernetes中部署WordPress，并将图片存储在EFS（Elastic File System）并通过符号链接将EFS目录链接到wp-content/uploads目录时，可能会遇到图片404错误。 这种问题通常发生在Nginx容器无法正确解析或访问符号链接指向的EFS存储时。

问题分析

问题的根本原因在于Nginx容器无法访问到App容器中创建的符号链接所指向的EFS存储。 虽然App容器可以正常访问EFS，但Nginx容器作为独立的进程，需要直接访问EFS存储，而不是通过App容器中的符号链接。 符号链接仅在创建它的文件系统上下文中有效。

解决方案

解决此问题的关键是确保两个容器（App容器和Nginx容器）都直接挂载EFS存储到相同的路径。 这样，Nginx容器就可以直接访问EFS上的图片，而无需依赖App容器中的符号链接。

具体步骤

1. 修改Deployment文件：

   确保在Deployment文件中，EFS存储卷被挂载到两个容器的相同路径。 以下是一个修改后的Deployment文件示例：

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: -deployment
     labels:
       app: MASSEDIT
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: MASSEDIT
     template:
       metadata:
         labels:
           app: MASSEDIT
       spec:
         volumes:
           - name: efs-pvc
             persistentVolumeClaim:
               claimName: -efs-storage-claim
           - name: shared-files
             emptyDir: {}
           - name: nginx-config
             configMap:
               name: -nginx-configmap
         containers:
           - image: DONTTOUCH-replace-me-kustomization
             name: app
             ports:
             - containerPort: 9000
               protocol: TCP
             volumeMounts:
             - mountPath: /var/www/html
               name: shared-files
             - mountPath: /shared  # 修改：挂载EFS到/shared
               name: efs-pvc
           - image: nginx
             name: nginx
             ports:
             - containerPort: 80
               protocol: TCP
             volumeMounts:
             - mountPath: /var/www/html
               name: shared-files
             - mountPath: /etc/nginx/conf.d/default.conf
               name: nginx-config
               subPath: nginx.conf
             - mountPath: /shared  # 修改：挂载EFS到/shared
               name: efs-pvc

   关键在于两个容器都挂载了名为 efs-pvc 的volume到相同的路径 /shared。

2. 修改WordPress配置：

   确保WordPress配置中wp-content/uploads目录指向正确的EFS挂载路径。通常，你需要修改wp-config.php文件或者通过WordPress后台的媒体设置来更改上传目录。 确保WordPress的上传目录配置正确，指向/shared/wp-content/uploads（假设EFS存储中的wp-content/uploads目录位于/shared）。 如果没有wp-content/uploads，需要手动创建。

3. Nginx配置检查:

   确保Nginx配置正确处理静态资源，并允许访问/shared目录。 检查nginx配置，确保没有禁止访问/shared目录的规则。

   location /wp-content/uploads/ {
       alias /shared/wp-content/uploads/;
       try_files $uri $uri/ =404;
   }

   上面的配置片段将任何对/wp-content/uploads/的请求映射到EFS存储的实际路径/shared/wp-content/uploads/。

注意事项

• 权限问题： 确保Nginx进程有读取EFS存储中文件的权限。 如果Nginx以非root用户运行，需要确保该用户具有访问EFS存储的权限。 建议使用相同的用户和组（例如 www-data:www-data）来运行App和Nginx容器，并确保EFS上的文件也属于该用户和组。
• 存储一致性： 确保EFS存储的一致性。 如果多个Pod同时写入EFS，可能会出现数据竞争问题。
• 符号链接移除： 在完成上述配置后，可以移除App容器中创建的符号链接，因为不再需要它。

总结

通过将EFS存储挂载到两个容器的相同路径，可以解决Nginx无法访问通过符号链接链接到EFS存储的图片的问题。 这种方法确保了两个容器都可以直接访问EFS存储，从而避免了符号链接带来的问题。 此外，还需要注意权限问题，并确保Nginx进程具有读取EFS存储中文件的权限。 正确的配置和权限设置是解决此类问题的关键。