符十三郎

docker安装因为选型用了doker，第一步自然是安装docker。安装比较简单，参考文档如下：参考文档 服务docker化服务器上跑的项目主要四种： yum 安装的，比如 mysql ， redis 。 源码或者二进制文件部署的，比如 git 和 nginx 。 自己编写的 go 项目。 自己编写的 python 项目。针对不同的服务，做了不同的设想。后续展开细说。 yum安装的服务本身有两种部署方式。继续使用 yum 安装成系统服务，或者运行在容器里。目前选择的是继续运行成系统服务。原因是因为容器的持久化和链接终归没有直接运行在服务器方便。作为整个服务器的一个部分，个人认为已经通过yum把它模块化了。在需要迁移时，直接在目标服务器重新安装或者部署到容器中即可。 二进制部署的服务目前二进制部署的服务，主要是 gogs ， git 服务。其实是支持容器化的，但是他的存储文件依旧需要持久化在机器硬盘上，只是把服务放到 docker 里，意义不大。所以同样也不打算在这次做容器化。另外一个服务器是 nginx ，算是编译之后的二进制。有单独的 nginx 容器，但是因为现在用的这个 ...

分解示例1234567<!-- 可以下载ul标签 li标签里，用于选择 --><a class="nav-link h4 active" aria-current="page" href="http://127.0.0.1:5000/s1" target="test">链接1</a><a class="nav-link h4 active" aria-current="page" href="http://127.0.0.1:5000/s2" target="test">链接2</a><!-- 上边的a标签target要与iframe标签的name标签一致 --><iframe name="test" id="test" class="embed-responsive-item" src=&q ...

1. TOTP的概念TOTP 的全称是”基于时间的一次性密码”(Time-based One-time Password). 它是公认的可靠解决方案,已经写入国际标准 RFC6238. 它的步骤如下. 第一步,用户开启双因素认证后,服务器生成一个密钥. 第二步：服务器提示用户扫描二维码(或者使用其他方式),把密钥保存到用户的手机.也就是说,服务器和用户的手机,现在都有了同一把密钥. 第三步,用户登录时,手机客户端使用这个密钥和当前时间戳,生成一个哈希,有效期默认为30秒.用户在有效期内,把这个哈希提交给服务器.(注意,密钥必须跟手机绑定.一旦用户更换手机,就必须生成全新的密钥.) 第四步,服务器也使用密钥和当前时间戳,生成一个哈希,跟用户提交的哈希比对.只要两者不一致,就拒绝登录. 2. RFC6238根据RFC 6238标准,供参考的实现如下： 生成一个任意字节的字符串密钥K,与客户端安全地共享. 基于T0的协商后,Unix时间从时间间隔(TI)开始计数时间步骤,TI则用于计算计数器C(默认情况下TI的数值是T0和30秒)的数值 协商加密哈希算法(默认为SHA-1) 协商密码长 ...

软件各阶段测试 单元测试：指定并测试一个类的单一方法合约的一点。这应该具有非常狭窄且定义明确的范围。与外部世界的复杂依赖关系和交互行为被嘲笑或嘲笑。 集成测试：测试多个子系统之间的正确互操作。从两类之间的测试集成，到与生产环境的测试集成，整个过程都有。 冒烟测试（也称为健全性检查）：一种简单的集成测试，我们只检查被测系统被调用时，它会正常返回并且不会崩溃。 冒烟测试与电子设备都是类比，电子设备上电时会进行第一次测试（如果冒烟，那就很糟糕！）… …，而且显然是水暖管道，管道系统实际上是由烟雾填充，然后进行目视检查。如果有任何冒烟，则系统泄漏。 回归测试：修复错误后编写的测试。它确保不会再次发生此特定的错误。全名是“非回归测试”。也可以是在更改应用程序之前进行的测试，以确保应用程序提供相同的结果。 为此，我将添加： 验收测试：测试功能或用例是否正确实现。它类似于集成测试，但侧重于提供的用例，而不是所涉及的组件。 系统测试：将系统测试为黑匣子。在测试期间，通常会嘲笑或打断对其他系统的依赖关系（否则，它更像是一个集成测试）。 飞行前检查：在类似生产环境中重复进行的测试，以减轻 ...

个人服务器模块化部署实录-前言之前一直用的阿里云服务器作为自己的个人云服务器，用来部署自己的网站及业务。目前采取的是服务器上直接部署服务，通过supervisor的方式进行统一管理。在使用过程中遇到了以下几个问题： 服务的部署操作困难因为一直是在本地开发的，部署发布之前需要把代码推到git，再上服务器从git拉取代码然后进行发布。之所以不用自动发布工具，是因为一来自动化流程构建需要时间，而我每次写一个小程序之后，很少有改动。所以就会变成不停配置自动化步骤。二来自动化发布工具毕竟也是需要硬件资源的，云服务器资源并不是很富裕。两者综合考虑，就一直在用手动的方式进行开发，部署。 服务迁移起来很困难虽然都是自己写的东西，但是因为没有规范化的部署文档，也没有部署等级。一旦遇到需要迁移的场景，就很难受。目前我在更换云服务器的时候，都是采用的打包成快照，生成镜像，然后根据镜像部署服务的方式。这种方式的局限性在于，我只能在阿里云内部进行迁移，如果我以后想使用其他服务商的云服务器，迁移的成本将是巨大的。且这个成本是日间增加的。 服务管理困难之前遇见过服务被爆破，或者由于bug程序自己 ...