使用Cloudflare Workers自建完全免费Docker镜像

本方法 不需要服务器 也不需要域名

自月初docker镜像被封禁之后，国内的镜像源也同步都停掉了。国内服务器拉取镜像变得完全不方便。

目前有几种方法

1. 挂代理, 给配置文件增加代理proxy配置;
2. 自建转发服务器，配置文件增加registry-mirrors镜像源:
   1. 自建服务器，给nginx配置反向代理， 如crproxy;
   2. 蹭Cloudflare Workers免费资源，手动写请求转发代码，如cloudflare-docker-proxy

最终我选择了Cloudflare Workers方式，因为这个方法完全不需要服务器，甚至也不需要域名，只需要注册一个cloudflare帐号就能用。

我真的服了cloudflare也是太大方了，真的什么都给大家免费用。

基本原理是在cloudflare上建一个Worker，将代理转发的代码放进去执行就行了。平台会自动生成一个公网域名，在docker配置里将这个域名设置成镜像地址就行。如果有自己的域名，可以绑定就行。比如我绑定了域名 dhub.xjp.in。

大家可以随便用，反正免费。到配置里加registry-mirrors配置就可以了，然后重启docker服务

1
2
3
4
5

{
  "registry-mirrors": [
     "dhub.xjp.in"
  ]
}

具体配置文件在哪，不同系统不同安装方式不一样，大家自己看文档就行。

如果不想改配置，可以拉取镜像的时候加上这个域名，比如这样也行：

1

docker pull dhub.xjp.in/nginx:1-alpine

【后续更新】非常明显，Doprax 已经不再提供免费的容器，界面之前的菜单更新了

使用Doprax搭建免费的Shadowsocks服务。

有现成的V2ray for Doprax方案。但是我一直是用Shadowsocks的，也不想换客户端。而且一看v2ray，和Shadowsocks相比，真的太复杂了，配置一大堆，看了文档也非常混乱，一比较就完全放弃。于是想研究ss能不能也整一个。

先说结论：使用v2ray-plugin插件将shadowsocks流量伪装成http协议，穿透Cloudflare网关，使用隧道转发到服务端。客户端使用安装了对应插件的客户端连接到服务端。并且可以支持v2ray客户端例如V2rayU连接

本来想尝试使用simple-obfs，因为ios的免费客户端上基本上内置这个，后来在成功实现v2ray-plugin方式之后，又继续研究了很久，发现由于Cloudflare的影响，导致没办法实现这个方案。

使用后感受：不好用。

套了Cloudflare隧道之后也非常慢，巨慢无比，几乎没法用。另外iOS里也没找到支持V2ray-plugin的好用的Shadowsocks客户端（付费的除外。我现在用的是Potatso只支持simple-obfs插件。也没找到v2ray好用的客户端（付费版除外。 所以本文更多的是学习性质。

避免滥用Doprax，人人有责。

分享一个 前几天泄露出来的Facebook的AI语言模型，LLaMA，总共220G

运行

有官方和第三方的运行示例，里面没有模型下载地址，官方途径是需要邮箱申请。

官方例子: https://github.com/facebookresearch/llama
内存优化版: https://github.com/tloen/llama-int8 据说只要3090可以运行，作者4090测试完成
计算优化版: https://github.com/markasoftware/llama-cpu CPU可以运行，但是需要32G内存
C/C++版本，普通机器CPU可以执行，https://github.com/ggerganov/llama.cpp 这个版本非常厉害，树莓派3B+就能运行7B模型，运行速度比较慢

下载

下载的脚本地址来自这里, https://github.com/shawwn/llama-dl

已经被DMCA了，无法打开，文末已获取了下载地址，可以直接下载

下载速度还行，下了一个晚上， 我已经下载好了。下载链接导出来之后，百度云离线下载不了，迅雷离线可以秒下，非常厉害。

总共220G

老项目老项目了这些都是。大部分都是十年前就出现的工具。感叹真是经久不衰。

最近服务开发中，为了节约成本，弄了两个服务器，希望搭建一套数据分析平台，验证项目流程。

查了很多资料对这些平台的搭建都非常简略，过程也是复杂，对新人很不友好，我也算是整理了一下相关的内容。简化服务搭建流程。

得益于Docker的容器化，整个数据平台搭建起来非常方便

整个过程里面，包含以下工具的搭建：

• HDFS，主要是用来存储数据
• YARN，提供资源调度，实现MR计算
• Hive on MR，基于MR的SQL引擎, 性能堪忧。也有基于Spark的，但是没有找到版本对应的公共镜像，就放弃了
• Spark Standalone，分布式计算框架，有基于YARN或者HIVE的版本，为了依赖纯粹，使用了独立集群
• Kafka on Kraft，为了依赖纯粹，使用了Kraft版本，不依赖ZooKeeper
• ElasticSearch，集群版本
• Logstash，不算是数据平台组件，简单的用来把日志文件传输到kafka和hdfs，也有其他类似的工具，很多

最近参与一个项目，硬件设备从摄像头采集视频直播流程，分析结果，与画面一起展示在前端页面上。

环境: 硬件设备是一个集成了显卡的开发板，可以运行ubuntu，算法部分是用python写的，前端设备在同一个局域网。摄像头为海康威视的普通网络摄像头。

关于视频画面播放的问题， 查了一下，前端目前不能直接播放rtsp视频流。

调研了市面上有几种方案。

1. ffmpeg视频转格式为frag_keyframe的mp4视频流，也就是视频流切片, 使用websocket转发流，前端使用Media Source Extensions渲染

   • 普通的mp4格式无法播放，需要转成fragment mp4即分片的mp4, 目前这种格式浏览器支持度差，这个方案也没测试成功。

2. ffmpeg视频转格式为flv视频流, websocket转发流，前端使用flv.js渲染

   • 这个方案比较靠谱, 可以参考知乎这篇HTML5 播放 RTSP 视频，没有尝试。
   • 这个方案的底层也是使用Media Source Extensions渲染，只不过格式是使用flv

3. ffmpeg视频流切片成m3u8存成文件, 前端video标签直接播放文件地址或hls.js渲染

   • 这个方案严重的问题是延迟太高，至少会延迟一个切片文件的时间，可以播放成功。

4. 服务端视频流截图，保持连接，接口返回content-type: multipart/x-mixed-replace图片，前端使用img标签加载图片地址

   • 这个方案是意想不到的一个方案，很神奇，不清楚会不会造成内存泄露。

5. 转rtmp视频流，浏览器使用flash插件

   • flash不行，没有尝试

6. 使用webrtc，点对点直接播放视频

   • 方案没尝试，点对点应该是浏览器对浏览器之间，服务端这边需要启一个webrtc的客户端处理，

上述几个方案

m3u8是Apple主推的技术方案，目前录播用多，直播用的少，应该以后会发展。

flv.js是目前最好的直播解决方案，延迟也非常好。

这两种需要系统依赖ffmpeg。但是结合项目实际，最终采用了另外一种方式:

服务端视频流截图，使用websocket转发图片帧二进制内容, 前端渲染到canvas

不需要安装系统依赖

分享一个在云主机上的无桌面环境的Windows Server上，不安装Docker Desktop，运行Docker。

系统要求Windows2016及以上即可。

起因

前段时间，一朋友委托我研究一个技术方案。说他技术这边搞了一个分布式的Windows程序，依赖Docker环境，现在只能在电脑上安装，非常不方便维护，扩容起来也很麻烦。于是我也花了差不多花了一百多块钱，一个周末，买了一个云主机来研究研究。

前言

本文是随笔，记录了一次基于以太坊的抽奖服务的方案讨论。从常规的智能合约的实现方案，到最终改用不上链的实现，主要是分享一下思路，包含了一点不看也没事的技术细节，以及一点区块链相关的内容。

因为抽奖主题的区块链开发入门文章已经泛滥了，所以文章尽可能避免变成教程。

背景

之前一位做论坛的同学说他们那个论坛经常会做一些活动，抽奖什么的。如何让用户能感受到公平公正，让大家信任。之前一个的办法是在指定时间录视频，并且边上放个北京时间，表示这个是准时开奖没有作弊。这个和澳门最大线上赌场异曲同工，边上搞台电视放新闻的直播，令人信服。

但是总一直这样也不行，我们可是搞技术的，而且这种方式扩展性太弱。于是他们想做一个公正公开可信任，简单易用易理解的抽奖系统，选定的方案是区块链。我听了觉得很有意思，而且公正公开不可变，区块链太合适不过了，说就研究研究吧。不过为啥不找区块链团队帮忙，可以部门间合作合作。他说这个需求太简单了，就不麻烦其他部门的人了。

方案

虽然现在公链有很多了，而且性能一个比一个强，但是实际上有大量应用的目前也就两三个，我个人比较喜欢古典一些的ETH。

其实需求很简单，方案也预定了一下。基本的逻辑是，用指定eth地址将帖子id作为参数来执行合约函数，得到随机数结果。指定eth地址是用来做权限控制，私钥不公开，可以防止被无关人员开奖。因为合约是公开的，执行函数的时间也是公开的，执行结果也是公开的，所以开完奖之后，大家可以直接查询验证结果。

只要在活动开始时提前公布用来开奖的地址与开奖时间与帖子id，预定时间开奖之后，大家一查就有了，简直完美。 其实当时想了有一个缺点，就是得花钱，执行合约是要付费的，大概算了下按当前eth的价格开一次奖得花一块人民币，会不会太浪费，他说完全ojbk。

个人的程序的报警很多人都用的 server 酱 之前我也是用这个的 个人使用的时候确实非常方便 但是因为 server 酱是基于微信公众号的 所以如果要发送个多人 或者分组发送消息 还是不是很方便 于是自己开始准备用 wepy 来做这个工具

结果发现貌似itchat接口被封掉了 issues 不得不寻求其他的方法

最终找到了telegram 不得不说 虽然是聊天工具 但是对开发者还是相当友好的 各种接口都有提供 而且提供了一个非常强大的机器人系统 可以进行各种操作 而且流程非常简单

创建自己的机器人

搜索BotFather 这个帐号 然后发送/start开始对话 BotFather是telegram的一个机器人帐号 用来管理所有用户创建的机器人 开始对话之后 会提示你进行各种操作 来创建和管理自己的机器人 设置机器人的用户名 创建完成之后会得到一个机器人token 之后所有的操作都是使用这个token来做

创建频道

telegram和微信不同 除了组之外还有频道的概念 频道里只有管理员可以发送消息 其他人可以订阅这个频道 接受消息 非常符合报警这个使用场景 创建完了之后设置频道的名称 并且将你的机器人设置为频道的管理员

发送消息

然后就可以测试了 用的是python-telegram-bot这个库

1
2
3
4
5

from telegram import Bot

bot = Bot(token = "tokenofyourtelegrambot")
bot.send_message("@channelname", "测试内容测试内容")

是不是简单到爆炸。。。。 然后在使用flask之类的封装一下成http接口简直好用到不行

上篇讲了个如何使用gpu.js这个库来进行简单的gpu计算 虽然简单易用 但是本身的局限也很多 目前这个库也不是非常完善 有待改进 那咱就从原理开始 来自己搞一个吧 当然 并不是指实现一个这个的通用的库 而是使用相关原理 完成一个是用GPU计算的demo 当然还是矩阵的乘法

前端使用GPU的能力是通过webgl实现的 更加广泛的理解的可以认为是通过canvas来说实现的 canvas估计对大多数前端来说并不陌生 canvas有许多个像素组成 每个像素的颜色可以有RGBA四个维度表示 每个维度范围为0-255 既8位 把RGBA表示成数值的话 那每个像素可以存32位 这就是前端使用gpu计算最为核心的一点 每个像素可以存储一个32位的值, 刚刚好就是一个int或者uint

0.基本WebGL绘制

首先从最简单的绘制一个图像开始 webgl绘图的流程 最简单的就这样

其中两个vertex shader和fragment shader为两个GLSL代码片段 分别处理坐标数据和颜色数据 vertex shader和fragment shader的执行是以像素为单位

canvas开始绘制的时候 vertex shader中得到 每个需要绘制的像素的坐标 视需要可以对坐标进行各种转换 最终得到一个最终位置 这个过程中可以将数据作为输出传入fragment shader 参与下一步的计算

fragment shader接受各种输入 最终输出一个RGBA颜色数据作为该像素点的颜色值

当所有像素都绘制完成之后 画布绘制完成

前端是可以接触到GPU的 于是也是可以使用GPU的计算能力的 对于我这种没有很深入的GPU运算了解的程序员来说 完全从底层开始怕是也不太可能 好在已经有大神把相关的内容以及封装成库了 gpu.js 于是本文的初识的意思就是就从这个库开始 首先说明 这个库其实也还在开发当中的 也没有一个很稳定的正式版 所以很多功能都是有欠缺的 但是了解个GPU计算是啥来说 绰绰有余了

因为js是单线程的 所以并不适合处理CPU密集型的程序 但是GPU是有非常高的并行线程数 所以GPU计算的基本思想就是把计算任务分拆成N多个线程任务 每个线程返回一个结果 然后吧每个线程的结果再汇总 这个基本的思路不管是哪平台上的应该都是一样的

啥是线程的概念 咱先直接看一段代码来先感受一下

1
2
3
4
5
6

const gpu = new GPU();
const myFunc = gpu.createKernel(function() {
    return this.thread.x;
}, { output: { x: 100 } });

myFunc();  // [0,1,2,3,...98,99]

每个线程都会执行这个传入的函数 具体起多少个线程有参数output决定 可以有x,y,z三个维度 上面这个例子只取了x方向上数量100个

在函数里this.thread.x可以获取到当前执行这个函数的线程x维度上的地址 如果有多个方向的话 还有类似this.thread.y和this.thread.z的

函数接受的参数为外部调用的时候传入的参数 函数返回的值为当前线程返回的值 所有线程按照各个维度上的位置 向最外面返回一个最终的数组 就是上面那个执行的效果 每个线程直接返回了线程在x维度上的位置 最终吧所有线程按照维度的顺序合并起来 如果有两个维度 最终的值就是个二维数组 同理三个维度也是

要注意的是 这个执行的函数 最终会被库转化进入到GPU中执行 所以 所有外部js的参数和函数 还有该函数里的语句语法是有限制的 具体的解决方法可以参考文档 有向内部传入数据的方法