Truenas Scale 容器的使用 0x1 其他 容器的用法基本上都是大同小异，这里只根据界面和注意事项简单的说明一下： 拉取镜像在设置 'Manage Container Images' 中即可 容器支持的环境变量在创建中 'Container Environment Variables' 设置 如果需要最大权限则勾选 'Privileged Mode' 容器需要的一些特殊的 CAP 可以在 'Capabilities' 中添加 最后重点说一下网络： 如果是想使用默认的映射端口，那么网络中就选择默认的接口就行了，本机网络也不需要做设置，然后在 'Port Forwarding' 中设置端口映射关系 如果想给容器一个本网段的IP，有些服务是需要这样的，比如FTP，NFS等具有多个端口、多次建立链接的服务，或者其他对NAT容忍性低的服务，这样最好直接暴露容器到外部。所以需要在本机新建一个桥接网络，桥接默认的接口，之后网络中选择这个桥接，选择设置静态ip，设置一个宿主机同网段的ip了，最后我们可以进入容器中进行确认

Truenas Jail和容器的选择 0x1 问题背景 考虑使用这些的原因是NFS的问题，在Truenas Core某个时间后，NFS的挂载经常报IO错误，但是文件实际上在NAS上是可以正常读写的，详细的排查见其他帖子，并且这个问题最终也没有结论。但规避方法是，采用虚拟机、jail、容器等方式拆分整个NFS，使得每个NFS server只需要负责一部分的文件，减小互相影响 0x2 优劣势 虚拟机：占用资源比较多，如果后续需要多个NFS或者其他服务，那么势必会占用一部分当前的 zfs arc 的空间 jail：这个是freebds的一个虚拟化工具，在性能、功能上貌似比较强大，本想尝试一下，但是资料太小，并且到底能否是否NFS server也没有找到可靠的资料 容器：基本上平衡了性能，功能的问题，最终还是选择使用它了 0x3 Truenas容器 查询了一些资料，发现Truenas Core是基于freebds的类unix系统，不支持docker或者其他容器，如果要使用容器则需要换成Truenas Scale，这是前几年基于Linux发行的版本，相对于Core版本有更多的应用扩展了，还好我们目前没有在Truenas上有过多的应用，所以按照升级方案处理即可 在升级后可以看到Truenas Scale是自带容器的，不过貌似是精简版的k3s，更多详细的功能参考其他文档

tomcat返回403禁止跨域问题 问题现象 tomcat返回403跨域主要是Origin值问题，从浏览器F12可以看到报错的请求是存在Origin头部的，浏览器这一部分可能Origin和host是一样的，不会有问题， 但是通过中间nginx抓包可以看到转发至tomcat这一段，可能出现不一致的情况。这个问题最主要的是中间某个nginx没有正确的设置Host值，解决方式有如下几种： 设置Origin的值为空，绕过跨域 proxy_set_header Origin ""; 使用more_headers 移除 Origin头部 使用proxy_set_header Host xxxx; 设置Origin所需的Host，如果有多层nginx，可以只在最后一个设置。但是这样也有局限性，如果外部多个出口的情况，面对用户有多个地址，那就仍然受限，需要每个host都配置一个server

多版本nfs挂载的问题 nfs挂载不上的问题 这个配置可能客户端挂载不上: /data 192.168.1.100(rw,no_root_squash) 使用 nfsv3和v4都提示错误，要么是没权限，要么是目录不存在。其实权限和目录在server上都是存在的 增加参数，配置如下: /data 192.168.1.1(rw,no_root_squash,fsid=0) 在增加此目录后， nfsv4就把 /data 作为根目录导出了，所以 v3和v4分别挂载如下: v4挂载 192.168.10.17:/ on /docker v3挂载 # 与之前一致 192.168.10.17:/data on /opt/data 挂载子目录 nfs默认只能挂载父目录，可以增加参数，使得客户端可以挂载子目录，配置如下: /data 192.168.1.1(rw,no_root_squash,fsid=0,crossmnt) 尝试挂载子目录 # 使用nfsv3挂载，v4未测试未知 192.168.10.17:/data/services/xxxx/workdir on /opt/docker/workdir

docker swarm架构更改 当前架构 目前整个docker swarm架构是: 节点数量： 3管理节点，4工作节点 keepalived 自动配置 VIP 到任意管理节点 WEB 服务由 3副本 NGINX （HOST模式）代理其服务名 使用 VIP 对外提供服务, 只访问到此 NGINX 当 VIP 管理节点故障时候，由 keepalived 切换 VIP 到其他管理节点 问题现状 上面的架构实现了一部分的高可用、也存在一定的问题： docker swarm 高可用，挂1-2个管理、工作节点能够保证环境正常 比较依赖于VIP和管理节点的联动，VIP+keepalived+docker swarn全部集中在一起 存在一定的网络问题，比如bind服务容器化后，VIP所在的机器中的容器可能无法访问到VIP地址提供的bind解析，可见之前分析的dns问题 目前的问题在于各个部件耦合的太紧，当发生故障的时候，keepalived、nginx、VIP等都需要切换，还要考虑VIP切换到了哪个nginx节点，这样维护比较麻烦。所以希望解耦服务之间的关系，让每个服务只关心自己的部分，并且解决 dns 解析的 nat 问题 架构变更 架构的变更需要考虑服务解耦，并且每个部分实现一定的高可用： 分离出当前的7层nginx，变成4层代理，部署到2-3个节点到其他物理机上，VIP部署在此nginx，stream代理所有的docker节点，实现高可用 nginx、bind等服务改成replicate模式，副本1，设置故障自动恢复 （可选）nginx可以考虑替换为 treafik等微服务网关，可以实现7层会话保持以及自动发现、failover等 tomcat镜像设置健康检查，使得多副本情况下，只是服务挂了也可以被docker正确的识别到，不再让ipvs转发到此节点 HEALTHCHECK --interval=5s --timeout=3s --retries=3 \ CMD curl -fs http://localhost/ || exit 1 经过以上调整后多副本的服务高可用： 如果某个副本宕机，可以马上识别到并且移除，时间应该在几秒内 如果是副本内服务挂掉，健康检测可以在20秒内判断，并且不再转发 如果docker物理机宕机，重要容器failover，nginx不再转发到此节点