本文发自 http://www.binss.me/blog/binsite-3.2-release/,转载请注明出处。

从3.1起,功能和界面都不会进行大改了,也没什么TODO日程了,主要是对日常使用中发现的bug进行修补,然后每年更新下release。

基于3.1,改进了以下问题:

  1. 全站HTTPS

    Letsencpty + Cloudflare Full SSL

    因为贫穷付不起500刀每月的自定义证书,前段还是用共享的证书。

  2. HTTP/2

    全站HTTPS的原因。

  3. 界面调整

    • 更新友链
    • 更新年份
    • 调整tag颜色
    • 解决文章数超过100导致修改页表格拉伸的问题
  4. 功能调整

    • 实现回复时引用文本框
    • 支持emoji
    • 文章中链接改为在新页面(tab)中打开
    • markdown代码块支持旁注式指定高亮语言
    • 框架和依赖模块升级到最新,好像没啥大变化
  5. CI调整

    原来的架构是这样子的:push代码后,触发git的hook,于是docker hub进行build,完成后通过hook触发服务器,服务器pull image后通过docker-compose移除并重新创建拉起nginx+mysql+binsite server。

    但随着使用,该方式的问题逐渐暴露出来:每次服务器通过docker-compose移除原有容器时往往会失败,然后不得不手动登录进行移除,说好的CI呢。

    其次是每次push代码docker hub都会花费若干分钟重新build,然后服务器重新pull image,但大多数情况下只是代码变了而运行环境没变,这种做法实在是浪费时间和流量。

    实际上,将nginx、mysql和binsite server捆在一起也是不合理的,虽然binsite server依赖于mysql,需要nginx作为反代,但并不意味着后两者要被binsite server所“独占”。这个问题直到我上次在该机器上部署一个依赖于mysql的签到服务时才发现,此后一直耿耿于怀。

    这两天对部署方案进行了一番思考,决定还是打破三者之间的耦合,将mysql和nginx作为独立的服务,新架构如下:

    mysql和nginx独立存在,其中binsite通过link连接mysql,nginx通过ip和port连接binsite。为了固定binsite的ip来保障nginx能够反代,因此新建了bridge,写死binsite的ip。

    当binsite代码变化时,只触发git去pull代码,然后restart容器。

    当binsite环境变化时,需要手动pull镜像,然后重新创建容器。