为什么写这个
随便写点啥，看到了博客推荐编辑这玩意儿，我给出的回答是docker。
不知道写点啥，但是随便看了下一些论坛，有底了。
先写《安装Linux单机版流量统计的程序，记录通信的对端IP及请求端口》，然后再写个《无需zabbix部署一个Linux单机版本系统资源负载记录》。至于标题嘛，写的时候再琢磨琢磨。
实现效果
在docker中部署特定的镜像，然后通过浏览器或者vnc、rdp之类的远程方式，在浏览器或者其他远程桌面客户端中打开一个浏览器，用于访问云服务器所在的局域网web应用，或者是通过云服务器所在的网络访问对应的应用。
受限于云服务器普遍没有提供GPU能力，因此此浏览器无法进行视频播放之类的操作，且由于缺失GPU加速，复杂的h5页面对处理器资源的使用会比较高。如果是自建虚拟化底层，可以通过直通GPU，或者SR-IOV以及特定GPU厂商提供的专用拆分方案为容器或者虚拟机提供GPU。
应用场景
通过docker部署浏览器访问网页，最近算是比较热门，看到有up主提起。其实这玩意儿不算什么新鲜事物了，不过确实由于docker部署比较方便，通过docker快速创建临时的浏览器环境，或者创建大量的浏览器环境但是只需要比较少的系统资源也是不错的。
举个例子，大部分的网管交换机默认状态下是不可以配置网关的，或者即使支持配置网关，但是开发者也没有为交换机添加默认路由，导致交换机只能通过同网段访问。华三华为思科之类的普通网管交换机如果以静态地址添加vlan-if的IP，还需要添加0.0.0.0/0到网关的路由，以实现其他网段访问交换机，或者通过dhcp分配IP地址；而家用的web网管交换机本身就没有“静态路由”配置功能，而且在手动指定IP的时候也没有提供填写网关的功能除非通过DHCP。如果这个时候，在局域网的docker服务器或者虚拟机服务器起一个虚拟机仅运行浏览器，就可以直接在浏览器比较轻量的访问，不需要复杂的连接内网的虚拟机桌面进行操作了。如果让当前的计算机浏览器全屏显示网页，那么大概看起来好像就是直接访问的交换机管理页面。
上面只是举了个可能的例子，比较冷门，来说个比较有诱惑力的吧：通过合理的配置，为虚拟机提供了vGPU，或者将计算机的GPU直接共享给了docker容器，而且当前计算机性能比较强大。你手头可以以任何浏览器访问这个容器，让低配置的显示器只作为交互终端，带来了通过浏览器就能打开的云电脑、云浏览器。比如动不动就内存不足的atom Z3735F的国产Windows平板，或者10年前安卓2.3的平板电脑搭配型号专用的网线、vga输出的拓展坞，将画面输出到显示器、电视机上，极低的配置就可以访问比较复杂，需要较高配置才能访问的web页面，或者同时打开相当多的页面上网冲浪。而不会因为安卓系统版本过旧配置较低，许多网页无法加载；2G运行内存的Windows平板随便打开一个复杂的h5页面就提示内存不足。
局限性
跨境电商狂喜？租一堆云服务器然后就可以得到独立IP窗口的浏览器不会被关联？（相似的需求都是相同的建议，建议找别的方法）
NONONO，洗洗睡吧。
1、海外云服务器IP归属不正确，显然是IDC机房用途；以及海外宽带运营商一般会配置rdns，即使你的运营商可以重播更换得到的公网IP，但是公网IP一般都配置了RDNS解析，只要宽带账号不变，不同的公网IP仍然会查询到相同的rdns记录。海外的交易系统一般都会记录rdns就是这个原因。国内没有这个给了一些人便利，但是国内公网IP的宽带也越来越少了，也没有那么大的意义了。例如Windows可以通过rdns结果只允许特定的宽带的IP地址，Linux的ssh\telnet同理。
2、Windows的浏览器与Linux的浏览器“指纹”、“特性”是不一样的，有相当多的差异。对于电商web页面来说往往都有类似的分析，UA只是最基础的基础，大部分还会通过指纹进行分析，至于更难修改的特性。具体自行搜索，类似与反虚拟机检测技术一样，都是需要花大把时间的，而一旦站点有你没考虑到的检测手段，你的一切伪装就都会显得相当可笑。
另外通过虚拟机或者docker搭建的服务，本身文件系统并非本地，因此如果浏览器需要上传、下载文件，就需要额外的一些操作。以及如果站点需要调用本地的摄像头、麦克风，又需要额外的一些操作了，本文不做详细表述，但是给出本人的实现方式、解决方法：我通过RDP客户端访问，接入的时候允许声音在本地播放、使用本地麦克风、挂载本地路径到远程主机。
安装方法
我建议使用这个开源的容器，安装量较大、开源、代码简单，本人已做简单审计。请注意计算机卫生，不要随意引用、部署来路不明的容器，避免容器底层在执行你意料之外的操作，例如某UP主介绍的容器，底层会偷偷的运行一些比较明目张胆的滥用你的服务器资源的程序，更别提有没有可能这个容器会记录你在浏览器的输入并发送到作者的服务器。
https://github.com/ConSol/docker-headless-vnc-container/
This repository contains a collection of Docker images with headless VNC environments.
1、如果在国内使用从docker hub下载速度比较缓慢，建议先拉拉取镜像，便于第一次运行的时候一次成功。镜像GB级别体积，通过提供的Dockerfile在本地构建自己的镜像也是一个不错的主意，特别是有比较高的修改、自定义需求的时候，直接本地构建镜像更为高效。
docker pull consol/rocky-xfce-vnc也可以通过一些国内的加速源、镜像源拉取。微软的还行，其他的就不做推荐了。
docker run -d -p 5901:5901 -p 6901:6901 consol/rocky-xfce-vnc如果没有报错，你的第一个docker内运行的浏览器就可以正常使用了。
通过浏览器直接访问容器所在服务器的IP:6901端口。在浏览器就像这样：http://ip:6901。还可以通过http://ip:6901/?password=vncpassword这样的地址直接打开窗口无需再弹出的窗口输入密码。
如果本地有vnc客户端例如vncviewer，访问服务器IP以及5901或者1端口就能进入了。
默认的密码是vncpassword。如果服务器具有公网IP，那么默认密码开放服务显然相当不安全。
http本身可以通过nginx或者haproxy之类的反向代理服务器升级为https，如果你觉得有必要加密一下；而更重要的是默认密码更容易被其他人访问，因此相对于https，修改默认密码是必须的。同时默认的分辨率也可能太低了，也需要指定一个参数让浏览器所在的虚拟桌面以你需要的分辨率展开：
docker run -it -p 5901:5901 -p 6901:6901 -e VNC_PW="PaSsw0rd" -e VNC_RESOLUTION=1920x1080 consol/rocky-xfce-vnc受限于VNC的性能，且浏览器也没有GPU加速，分辨率不建议大于1080P，避免性能、带宽都浪费在页面传输了。没有显卡加速的浏览器需要更多的处理器资源，访问比较多的网页也需要更多的内存。如果遇到访问特定的网页崩溃，很可能就是内存不足。
由于CentOS结束支持，方案就转为了Rocky Linux 9。除了RH系方案，还有deb系方案供选择。
consol/rocky-xfce-vnc: Rocky 9 with Xfce4 UI session
consol/debian-xfce-vnc: Debian 11 with Xfce4 UI session
consol/rocky-icewm-vnc: Rocky 9 with IceWM UI session
consol/debian-icewm-vnc: Debian 11 with IceWM UI session
方案原理
此方案提供的原理相当简单，docker容器运行了比较常见的rocky、debian系统，并配置xfce或者icewm桌面，安装firefox以及chrome浏览器，运行vnc服务端，并通过websockify提供传说中的noVNC，让用户在浏览器能够直接访问VNC服务摆脱VNC客户端的依赖。
因此除了作为浏览器中的浏览器这样的玩法，还可以在网页上直接访问容器中的操作系统，或者以交互模式访问docker容器，对容器进行软件安装。
优化方向
没有GPU，性能较差。VNC访问性能较差、RDP方式的访问性能会提升不少。
如果需要浏览器长期使用，可以将浏览器的配置文件夹独立挂载到系统路径，便于容器升级版本仍然保留浏览历史、书签、记住密码之类的个人使用记录。作为比较重型的Linux发行版，即使是容器rootfs，软件也是比较多的，为了保证操作系统安全，需要注意保持系统软件更新，以及浏览器软件更新。可以在当前容器内执行升级，也可以在官方更新后重新拉取升级系统软件；更新更为频繁的浏览器本身通过浏览器内的升级操作直接升级就可以了。
