GitLab对接OAuth2实现SSO

企业内部一般都会有多个业务、应用系统,为建立统一的用户管理、身份配给和身份认证体系,实现一个账号登录所有系统,需要建立一套统一身份认证服务平台。

统一身份认证服务平台一般包含以下几个部分:

  • 账号管理:常见有AD/LDAP或者使用关系型数据库
  • 认证管理:常见有OAuth,SAML,CAS等
  • 授权管理
  • 审计监控

而单点登录(SingleSignOn,SSO),不光可以实现一个账号登录所有系统,它通过用户的一次性登录认证,就可以访问多个应用。SSO一般会被包含在认证管理功能里。

GitLab支持多种身份认证和授权方式,可以与企业的统一身份认证服务平台集成。包括对接AD/LDAP实现统一账号,对接SAML、CAS、Auth0、OAuth2等实现SSO。GitLab对于AD/LDAP、SAML、CAS、Auth0的对接提供了详细的文档。而对接Generic OAuth2的文档较粗放,网络上也没有太多参考资料,所以整理了一篇GitLab对接OAuth2的实践文章。

阅读更多

如何安全使用GitLab CICD SSH部署

1. 背景

使用GitLab CICD,在部署方面,主要有两种方式:

  • 部署到K8S集群

    • Push模式:流水线通过kubectl执行命令部署,这需要把K8S的权限给流水线,存在安全风险

    • Pull模式:使用GitLab Agent for Kubernetes或ArgoCD,通过GitOps的方式“监听”GitLab的变化,触发部署

  • 部署到服务器

    目前仍有不少企业因为行业性质或者场景所限,没有使用K8S等云原生技术,还在采用传统的服务器方式进行部署。一般使用sshscprsync等命令部署到服务器。GitLab也提供了基于SSH keys的部署。详见:Using SSH keys with GitLab CI/CD | GitLab

    需要说明的是,如果是使用专用的编译机进行编译构建,然后部署到指定的服务器,只需要实现编译机和部署服务器的免密SSH登陆即可,相对简单。但如果使用容器进行编译构建,然后部署到服务器,就需要按照上面文档中提到的,配合GitLab CI/CD环境变量,将SSH_PRIVATE_KEY等变量存储到GitLab Project、Group或Instance中,实现复用。且可以通过GitLab CI/CD环境变量的Mask设置,掩藏这些变量在CICD日志中的显示。详见:GitLab CI/CD variables | GitLab

    但遗憾的是Mask功能目前是有限制的,对于SSH_PRIVATE_KEY这种多行的变量无法直接使用Mask功能。这样开发人员就可以在.gitlab-cti.yml文件的脚本中执行echo $SSH_PRIVATE_KEY,在流水线的日志中输出SSH Keys,存在密钥泄露风险。

    The value of the variable must:

    • Be a single line.
    • Be 8 characters or longer, consisting only of:
    • Not match the name of an existing predefined or custom CI/CD variable.

这个问题在GitLab的Issue上挂了有一年多 ,看样子短时间没法解决。有没有其他方式Mask SSH_PRIVATE_KEY?于是开始了各种折腾。

2. 方案

阅读更多

一段祖传代码引起的血案

WARNING:本文含有强烈的刺激性气味,请勿在进食期间阅读。如感到血压上升、眩晕、呼吸急促,请立即停止阅读。

1. 初识祖传代码

祖传代码(Legacy Code),就字面意思而言,就是无数的前任程序猿留给你的最后遗产。这些代码几乎没有可维护性,缺少注释、命名不规范、依赖错综复杂,你根本读不懂它,但神奇的是它们都能跑起来。不要试图修改它们,因为要么就无从下手,要么一改就出大问题。每家公司都会有那么些“历史遗留问题”。亚马逊的工程师亲切的形容他们的祖传代码为“屎山”:“每次你想修正一个bug,你的工作就是爬到屎山的正中心去”。

一家企业里,偶尔一两座屎山无伤大雅,毕竟每家企业都有很长的故事。但如果“你看那一座座山,一座座山川,一座座山川相连”,这种情况就很危险了。山路十八弯,难以持续的为企业快速增长提供高效支撑。企业发展的越快,屎山的债务积累就越多,形成恶性循环,最终企业员工只能望山兴叹,下山逃难去了。如何解决屎山问题?如何形成一个正向的发展循环?如何打造一个研发流程的最佳实践?如何加强质量内建?那我们就要先爬到屎山的正中心去一探究竟,明知山有屎,偏向屎山行。

阅读更多

自建RSS信息聚合服务

1. RSS现状

RSS介绍,摘自WIKI百科:

RSS(全称:RDF Site Summary;Really Simple Syndication),中文译作简易信息聚合,也称聚合内容,是一种消息来源格式规范,用以聚合经常发布更新资料的网站,例如博客文章、新闻、音频或视频的网摘。RSS文件(或称做摘要、网络摘要、或频更新,提供到频道)包含全文或是节录的文字,再加上发布者所订阅之网摘资料和授权的元数据。简单来说 RSS 能够让用户订阅个人网站个人博客,当订阅的网站有新文章时能够获得通知。

RSS摘要可以借由RSS阅读器、feed reader或是aggregator等网页或以桌面为架构的软件来阅读。标准的XML档式可允许信息在一次发布后透过不同的程序阅览。用户借由将网摘输入RSS阅读器或是用鼠标点取浏览器上指向订阅程序的RSS小图标之URI(非通常称为URL)来订阅网摘。RSS阅读器定期检阅是否有更新,然后下载给监看用户界面。

RSS的黄金年代早已随着2013年Google Reader的下线而逝去,随之而来的是各种聚合类新闻APP,它们利用实时推送提高了信息传递的速度,利用推荐算法实现了信息传递的精准度。然而在这个信息爆炸的时代,良莠不齐的内容、低俗偏激的评论,大数据+人工智能精心打造的信息茧房真的适合人们去阅读去思考吗?

对信息来源、信息内容、信息实时性有要求,希望操作界面简单、适合阅读、跨平台。在2021年,利用RSS打造这样一个信息聚合服务,依然是小众之选,但却可以获得更纯粹的阅读体验。

阅读更多

分布式事务知识小结

部分内容整理自:

面试必问:分布式事务六种解决方案 - 知乎 (zhihu.com)
10分钟说透Saga分布式事务 - 云+社区 - 腾讯云 (tencent.com)

1. 事务的ACID

  • 原子性(Atomicity),可以理解为一个事务内的所有操作要么都执行,要么都不执行。
  • 一致性(Consistency),可以理解为数据是满足完整性约束的,也就是不会存在中间状态的数据,比如你账上有400,我账上有100,你给我打200块,此时你账上的钱应该是200,我账上的钱应该是300,不会存在我账上钱加了,你账上钱没扣的中间状态。
  • 隔离性(Isolation),指的是多个事务并发执行的时候不会互相干扰,即一个事务内部的数据对于其他事务来说是隔离的。
  • 持久性(Durability),指的是一个事务完成了之后数据就被永远保存下来,之后的其他操作或故障都不会对事务的结果产生影响。

2. Redis的事务

阅读更多

Redis知识小结

部分内容整理自:

https://www.cnblogs.com/yiwangzhibujian/p/7047458.html
https://blog.csdn.net/striveb/article/details/95110502
https://mp.weixin.qq.com/s/2OTVJUTLOetYTD4Hpk-hFA
https://juejin.cn/post/6844903663224225806

1. Redis为啥这么快

  • 纯内存操作

    • Redis是一个KV内存数据库,它内部构建了一个哈希表,根据指定的KEY访问时,只需要O(1)的时间复杂度就可以找到对应的数据。同时,Redis提供了丰富的数据类型,并使用高效的操作方式进行操作,这些操作都在内存中进行,并不会大量消耗CPU资源,所以速度极快。image-20210929151720644

      image-20210929152137061

  • 单线程

    • Redis Server是多线程的,只是它的请求处理整个流程是单线程处理的
    • 单线程的方式是无法发挥多核CPU 性能,不过可以通过在单机开多个Redis 实例来完善
    • 优势
      • 没有了多线程上下文切换的性能损耗
      • 没有了访问共享资源加锁的性能损耗
      • 开发和调试非常友好,可维护性高
    • 缺点
      • 单线程处理最大的缺点就是,如果前一个请求发生耗时比较久的操作,那么整个Redis就会阻塞住,其他请求也无法进来,直到这个耗时久的操作处理完成并返回,其他请求才能被处理到。
  • 使用IO多路复用技术

    • 这里“多路”指的是多个网络连接,“复用”指的是复用同一个线程。
    • Redis采用了IO多路复用技术和非阻塞IO,这个技术由操作系统实现提供,Redis可以方便地操作系统的API即可。Redis可以在单线程中监听多个Socket的请求,在任意一个Socket可读/可写时,Redis去读取客户端请求,在内存中操作对应的数据,然后再写回到Socket中。
    • 多路I/O复用模型是利用select、poll、epoll 可以同时监察多个流的 I/O 事件的能力,在空闲的时候,会把当前线程阻塞掉,当有一个或多个流有 I/O 事件时,就从阻塞态中唤醒,于是程序就会轮询一遍所有的流(epoll是只轮询那些真正发出了事件的流),并且只依次顺序的处理就绪的流,这种做法就避免了大量的无用操作。
  • 非CPU密集型任务

    • 采用单线程的缺点很明显,无法使用多核CPU。Redis作者提到,由于Redis的大部分操作并不是CPU密集型任务,而Redis的瓶颈在于内存和网络带宽。
    • 如果你觉得单个Redis实例的性能不足以支撑业务,Redis作者推荐部署多个Redis节点,组成集群的方式来利用多核CPU的能力,而不是在单个实例上使用多线程来处理。

2. Redis架构

阅读更多

MySQL锁、索引、日志知识小结

1. myisam和innodb区别

  • myisam是MySQL 5.1以前的默认引擎,支持全文检索、压缩、空间函数等,但是不支持事务和行级锁,所以一般用于有大量查询少量插入的场景来使用,而且myisam不支持外键,并且索引和数据是分开存储的。
  • innodb是基于聚簇索引建立的,和myisam相反它支持事务、外键,并且通过MVCC来支持高并发,索引和数据存储在一起。

2. MySQL的索引

  • B+树和Hash索引

  • B+树是左小右大的顺序存储结构,节点只包含id索引列,而叶子节点包含索引列和数据,这种数据和索引在一起存储的索引方式叫做聚簇索引,一张表只能有一个聚簇索引。假设没有定义主键,InnoDB会选择一个唯一的非空索引代替,如果没有的话则会隐式定义一个主键作为聚簇索引

    image-20210929154403899

  • 非聚簇索引(二级索引)保存的是主键id值,这一点和myisam保存的是数据地址是不同的

    image-20210929154445643

  • 区别
    image-20210929154500925

3. 覆盖索引和回表

阅读更多

MQ消息队列知识小结

1. MQ解决的问题

  • 解耦
    • 不用MQ:要针对各业务方开发,要考虑中断、超时、重试
    • 使用MQ:消息中间件类似一个代理,各业务方的通讯协调均由MQ负责,MQ来实现超时、重试机制
  • 异步
    • 不用MQ:长活同步事务,高延时,体验极差
    • 使用MQ:分步异步执行,防止同步阻塞
  • 削峰
    • 不用MQ:请求并发,服务器或数据库压力过大,导致宕机
    • 使用MQ:请求并发转串行,MQ来承担压力,平缓输出给服务器或数据库

2. 引入MQ产生的问题

  • 可用性
    • MQ挂了,整个系统都不能用
  • 复杂性
    • 消息重复:多次生产、多次消费
    • 消息乱序:新数据被旧数据覆盖
    • 消息丢失:漏数据、磁盘满了丢数据
  • 一致性
    • 分布式一致性问题,异步的多个事务没有最终都执行或都不执行

3. 常用MQ对比

阅读更多

自建云相册PhotoPrism

前言

记得我是2016年开始用Office365,家庭版一年229,6个人拼车,人均40。除了可以畅享正版Office外,还有1T的OneDrive空间。从那时候开始,就把存放在电脑里10多年的老照片都放到了OneDrive里。此外使用OneDrive的APP,还可以把手机里面的照片同步到OneDrive上。最重要的是,OneDrive提供了基于AI的照片Tag,可以按地理位置或者Tag进行照片分类,极大方便了照片备份和管理。

然而,2020年不知道什么时间开始,OneDrive的Tag功能消失了。经过多方面了解,得知微软官方确实下线了Tag的功能,但理由众说纷纭。有说功能会被转移到Bing上,但目前没有任何进展;有说因为数据隐私的原因;还有说牵扯三星的相关专利问题。具体可以在Microsoft Community上查看 “Edit Tags” option missing in One Drive & existing tags not visible. 同时希望Tag功能回归的请愿已经放到了UserVoice上,里面有来自用户的各种吐槽,但官方没有任何表示。而在OneDrive的support页面,关于Tag的功能描述依然存在。

阅读更多

基于阿里云IoT平台的物联网解决方案

去年差不多也是这个时候,我写过一篇《阿里云IoT应用案例》,重点提到了我们对于阿里云IoT SDK的封装并实现自主注册、消息队列规则转发、双向通讯、远程升级和远程控制等功能的设计思路。

又经过一年的持续优化、打磨,我们也落地了一整套物联网解决方案,包括物联网中间件和物联网平台,实现从仪器研发人员快速接入,到运维人员扫码装机注册,到仪器自动数据回传,到运维人员远程升级,再到管理人员物联网卡充值续费,最后到面向经营决策人员的大数据分析应用,拉通了整个业务闭环。

1. 背景

再一次提到背景,在上一篇文章中,简单概述了我们的物联网项目背景和需求,是为了解决在不同操作系统、不同开发语言的仪器,不同通讯协议、不同运营商的平台服务的环境下做一站式解决方案。但这只是技术背景和技术需求,放大来说,促使我们做这件事的原因还是产业数字化升级转型的趋势。一方面通过物联网和大数据等新技术对现有产品的升级、改造、赋能,让机器活起来,让数据流动起来,起到降本增效,辅助决策的作用,这是短期价值;另一方面,通过新技术的结合,面向新的场景探索,完成产品和业务的重塑,实现业务模式的转型,这是长期价值。

引用三个大佬的话来说这件事:

阅读更多