在本文,我将介绍腾讯云如何和Azure AD集成。
在Azure Active Directory中找到Enterprise applications(企业应用)创建一个新的应用,参考下图,在本文中将会使用Tencent Cloud SSO作为应用名称。
完成创建之后,进入应用之后,按照下图创建基于SAML的SSO。
需要配置的内容下图,总共五部分
我们需要配置的主要是前两个部分。
参考下图进行设置,标识符(实体 ID)和回复 URL(断言使用者服务 URL)参考下表
所在站点 | 标识符(实体 ID) | 回复 URL(断言使用者服务 URL) |
---|---|---|
中国站 | cloud.tencent.com | https://cloud.tencent.com/login/saml |
国际站 | intl.cloud.tencent.com | https://intl.cloud.tencent.com/login/saml |
在配置中,主要增加了下图中标出的两条配置。
Name(名称) | Namespace(命名空间) | Source(来源) | Source attribute(来源属性) |
---|---|---|---|
Role | https://cloud.tencent.com/SAML/Attributes | Attribute | user.assignedroles |
RoleSessionName | https://cloud.tencent.com/SAML/Attributes | Attribute | user.userprincipalname |
添加过程如下:
在第三部分中下载元数据文件。
在访问管理->身份提供商->角色SSO中新建一个提供商。
参考下图创建一个新的提供商, 其中元数据文档为Azure AD中下载的元数据文件。打开创建完成的提供商,将登录链接保存下来。
在访问管理->角色中新建角色,可以根据需求创建一个或者多个角色。在本文中,创建了两个角色,具备管理员权限的Administrator和只读权限的ReadOnly。
创建角色的过程如下:
点击“新建角色”后,在弹出框中选择“身份提供商”
身份提供商类型选择SAML,身份提供商选择之前创建的身份提供商,在本文中为aad
角色策略可以根据角色需求设置,比如现在创建的是Administrator,因此选中了AdministratorAccess
然后下一步配置角色标签,根据需求自行添加。在审阅中设置角色名称。
完成之后会自动跳转会角色列表,在角色列表中找到刚刚创建的角色并打开。参考下图找到两个重要信息:RoleArn和ProviderArn
返回Azure Portal页面,在在Azure Active Directory -> App registrations(应用注册)中选择All Applications,然后找到与企业应用同名的应用并打开,如下图。
在Manifest中修改appRoles
, 添加新的Role如下图所示。
内容可参考如下设置
1 | { |
需要注意的是:
RoleArn,ProviderArn
返回到创建的企业应用中,找到“用户和组”,根据需求添加用户和组即可。
打开角色SSO中的登录链接,得到如下界面。
]]>Jenkins等这一类的应用,我会选在部署在k8s集群上,主要原因如下:
为了保持环境干净,我会重新创建一个 namespace
,并把Jenkins部署到该namespace
之中。
使用如下命令创建 namespace
,
1 | kubectl create ns jenkins-lab |
注意: 我使用了命令式命令(Imperative commands)创建 namespace
, 这种方式不推荐在生产环境使用。具体参考Kubernetes Object Management.
推荐使用helm部署Jenkins,Jenkins官方也提供了chart。
1 | helm repo add jenkins https://charts.jenkins.io |
需要提供自定义一下values
文件,这次部署过程中,我会使用如下配置:
1 | controller: |
需要注意的是,因为AAD App的reply url需要安全的通信方式,此处即Https。我配置了一个带用tls的ingress,之后会写一篇博客介绍如何自动申请SSL证书。
如果你需要更多的自定义配置,可以参考Jenkins Chart默认的values.yaml。
到这里Jenkins部署完成,下一步注册AAD应用。
注册Azure AD应用可以使用如下方式:
通过web页面注册,交互比较容易,但是过程很难自动化,也没啥意思。因此我将采用CLI的方式,之后可以将其自动化。
注册一个名为 jenkins-lab
的AAD应用
1 | appName="jenkins-lab" |
此处有坑: 查询Azure CLI的官网和使用azure --help
的结果可能有较大区别。建议直接使用 --help
获取帮助信息。
因为要使用的Group进行权限管理,因此需要将groupMembershipClaims
改为SecurityGroup
。
1 | appId=$(az ad app list --display-name $appName | jq -r -c ".[0].appId") |
接下来,需要AAD应用授予User.Read.All
, Group.Read.All
, People.Read.All
应用权限,使用如下命令:
1 | microsoftGraphAppId=$(az ad sp list --query "[?appDisplayName=='Microsoft Graph'].appId" --all | jq -r -c ".[]") |
第一步: 登录Jenkins,默认用户名为admin
,密码使用下面的命令查询:
1 | kubectl exec --namespace jenkins-lab -it svc/jenkins -c jenkins -- /bin/cat /run/secrets/chart-admin-password && echo |
第二步: 进入Manage Jenkins
-> Security
-> Configure Global Security
第三步: 执行下面的命令,获取Azure AD应用的密钥。
1 | az ad app credential reset --id $appId |
得到如下结果,
该密钥有效时长为1年
第四步: 配置Security Realm
并保存
Client ID:使用第三步返回的结果中的appId
Client Secret:使用第三步返回的结果中的password
Tenant: 使用第三步返回的结果中的tenant
第五步: 保存之后,注销登录
第六步: 重新进入Jenkins,会自动跳转到Microsoft登录页面。
第七步: 配置权限,并保存
在Start typing a name
处,输入用户名或者组名,然后添加,授予合适的权限。
在集成的过程中仍然有大量的手动工作,之后计划使用JCasC
改进,为什么现在不用?因为之前尝试过,没有成功。
我采用的解决方案是:Azure AD + Windows Server AD
Azure Active Directory,简称Azure AD或者AAD,是一种基于云的标识和访问管理服务。 此服务可帮助员工访问外部资源,例如 Microsoft 365、Azure 门户和数以千计的其他 SaaS 应用程序。
该部分内容来自其技术文档,更多内容请访问什么是 Azure Active Directory?
获取Azure Active Directory的方法有两种:
方法一:注册Azure账号即可使用Azure Active Directory Free版本。该方法是最简单,也是长期可用的。但是部分功能无法使用,比如使用本地写回进行自助式密码重置/更改/解锁。
方法二:通过Microsoft 365 Developer Program获取Azure AD Premium P2。该方式可以解锁所有Azure AD功能,但是通过该方式申请到Microsoft 365 E5订阅有效期只有120天,之后微软会根据规则决定是否自动续期。目前,可以在网上找到如何自动续期的方案。
Active Directory 存储有关网络上对象的信息,并使管理员和用户可以轻松查找和使用这些信息。 Active Directory 使用结构化数据存储作为目录信息的逻辑分层组织的基础。
获取AD有两种方式:
方法一,使用Azure Active Directory Domain Services。对于个人用户而言,价格有点高,比如在East Asia一个月至少需要109美元。其好处也是不言而喻的,可靠性是有保障的。
方法二,在本地Windows Server上安装AD。与我而言,我会选择这种方案,因为其成本相对而言会低很多,可靠性的优先级并不是很高。
Azure 提供了现成的工具,只需要在Windows Server上安装Azure AD Connect sync。详细内容可以参考:https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sync-whatis
如果AAD的license是P1或者P2,可以开启密码回写,这样就可以通过微软提供的服务进行密码修改。可以参考: https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-password-hash-synchronization
如果只是free license,还想通过web页面修改密码,需要借助Remote Desktop Services来实现,可以参考:https://www.devopsage.com/how-to-setup-web-page-to-change-users-password/
我采用的方案如下:
Azure AD可以与很多种身份验证和同步协议集成。通过身份验证集成,只需对使用旧式身份验证方法的应用程序进行少量更改(或无需更改),即可使用 Azure AD 及其安全和管理功能。 利用同步集成,可以将用户和组数据同步到 Azure AD,然后使用用户 Azure AD 管理功能。 某些同步模式还支持自动预配。
支持的旧式身份验证方式:
支持的同步模式
更多详细的内容可以看Azure Active Directory 身份验证和同步协议概述 - Microsoft Entra | Microsoft Docs,毕竟是官方文档。
用一张图总结一下。在我的Homelab环境中,AD之间的同步,以及用户如何使用Azure AD登录到Jenkins上。
接下来我会分享几篇实践性的博客,讲讲Azure AD与Synology NAS, Jenkins, Gitlab等的集成。
]]>在本文中,我将尝试着为介绍一下如何写README。
写README可以按照5W1H(what, why, when, how, where, who)的思路去写,主要还是使用What, Why, How, Who。
What 主要是以下两方面:
比如在 Kubernetes 的README中,
Kubernetes, also known as K8s, is an open source system for managing containerized applications across multiple hosts. It provides basic mechanisms for deployment, maintenance, and scaling of applications.
通过这段话,我们知道了如下信息:
除了是什么和能干什么,还可能会有起源,License等
Why 主要是说明动机:
比如在Hashicorp Vault 中,
A modern system requires access to a multitude of secrets: database credentials, API keys for external services, credentials for service-oriented architecture communication, etc. Understanding who is accessing what secrets is already very difficult and platform-specific. Adding on key rolling, secure storage, and detailed audit logs is almost impossible without a custom solution. This is where Vault steps in.
第一句话介绍了背景,第二句话说明在该背景之下,所面对的困难。最后一句告诉大家Vault这个工具就是解决这些问题的。
关于带来了哪些好处,这部分通常而言是和What中能干什么(功能)有重合的。
Who 有如下内容:
关于谁维护该项目,在开源项目中会默认是社区或者repo的拥有者维护。但是在内部项目,随着人员的流动,还是很有必要注明该项目当前是谁/哪个团队负责维护的。
有哪些贡献者,在开源项目中经常会在README中看见很多提交代码人的头像,这样可以激励大家去提交代码。
比如在Vue中Contribution部分就做了这件事情。
沟通方式和下面的部分内容有一定的重复,提供一个或者多个平台,发布信息,让大家交流,提供反馈等。
这部分重点关注两类人:使用者和开发者。
使用者,也就是用户。对于用户,我们需要告诉用户如下内容:
这部分内容通常会集中在Documentation或者Getting Started这一类的标题之下。
比如在Hashicorp Vault 中,Documentation, Getting Started, and Certification Exams就是用来告诉用户如何使用。
再比如在Vue中,Documentation就是指向一些案例和文档,Issues就是告诉用户遇到问题如何创建一个issue。
开发者,可能对你项目感兴趣的人,想在你的基础上添加一些功能,或者发现了bug帮助你修复。我们需要提供给开发者Contributing Guide,包含如下内容:
以上的每一项不一定都需要,以上的内容也不是全部内容。通常这部分内容会出现在Development,contribution等这一类的标题之下。
比如在Hashicorp Vault 中,有一个小节Developing Vault来告诉开发者如何开发。
在Vue中,并不是将如何贡献代码写到了contribution之下,而是将其内容放到了另外一个页面,这是非常好的做法。在写README的时候,如果某个部分内容太长了就应该将其移到另外一个文件中。保持README完整,简洁,有条理是很重要的。不要尝试着增加用户(使用者/开发者)的阅读负担。
]]>当下最流行的Git是一个不错的选择,作为合格的软件开发人员你应该熟练的使用它。你可以构造一些场景去练习git命令,比如:
这里只列举了一些场景,你也可以根据你的需求再写一些场景用来练习。建议使用命令行练习,也建议以后的开发过程中使用命令行,最好不要使用IDE提供的UI。
当你了解了Git之后,也需要学习一下常见的git工作流:
学习资料:
我当前是使用的WSL配置如下:
1 | NAME STATE VERSION |
我习惯使用大量的CLI来提升自己的工作效率以及使用体验,因此一个好用的Terminal和一系列高效率的CLI工具对我是十分重要的。
文件的权限问题,解决方法参考[长期更新] WSL使用记录
配置git,执行下面命令之后,使用https clone的代码就不用经常输入用户名密码了。
1 | git config --global credential.helper store |
WSL中Git的默认编辑器对于我来说不咋好用,我比较喜欢使用vim。可以使用下面的命令更改默认编辑器:
1 | git config --global core.editor vim |
在Windows上面,我推荐使用 Windows Terminal (下载链接)。推荐理由:
ubuntu 里面默认提供的是Bash,不是特别适合日常使用。相较于Bash,Zsh更加适合交互,比如如下功能:
cd
也可以切换目录,在Bash需要使用 cd projects
,在Zsh下直接 projects
就行了。/u/loc
然后Tab,就会变成 /usr/local/
。如何安装Zsh
1 | sudo apt-get install zsh -y |
如果想知道更多有关Zsh的知识,请阅读官方文档。
Oh My Zsh 是一个开源的管理Zsh配置的框架。在其GitHub的Readme中有一句很有意思的话,Oh My Zsh will not make you a 10x developer…but you may feel like one.
如何安装Oh My Zsh:
1 | sudo apt-get install wget -y |
我使用的是Oh My Zsh的默认主题,如果想更改主题,请阅读 Readme.
插件是一个重头戏,利用插件可以提升我们的工作效率。
autojump
是一个小工具,可以帮助我们快速导航到一个目录中,支持模糊匹配。比如有一个目录名称我记得其中包含了 hexo
而且我曾经进入过,那么我就可以使用 j hexo
尝试进入。强烈推荐。
安装方式:
1 | sudo apt-get install autojump -y |
安装完之后,修改 ~/.zshrc
1 | plugins=(git autojump) |
git
支持git的插件时oh-my-zsh 默认添加了的,提供了很多简写的别名。比如我常用的 gst
就是 git status
的别名。更多别名,请参考 ohmyzsh/plugins/git。
Oh My Zsh还支持很多插件,详情请参考Plugins。
Homebrew 是一个包管理器。Homebrew也提供了很多有用的cli工具,我使用Homebrew 的原因是我公司配置的电脑是Macbook,在WSL中继续使用该工具,可以给我带来一致性的体验。而且Homebrew自己开发CLI工具,安装等相比于apt更加方便。
安装方式:
1 | /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" |
更多使用方式,请参考The Missing Package Manager for macOS (or Linux) — Homebrew
在使用git的过程中,本地看提交记录,或者reset的时候找起点等等情况下,如果使用 git log
就会很难受,tig完美地解决了这个问题,还能快速浏览每一个提交的内容等。
安装方式:
1 | sudo apt-get install tig -y |
这里只是列举了一些,我使用过的管理工具,其它语言请自行探索。
语言 | 管理工具 | 安装方式 | 文档 |
---|---|---|---|
Java | jenv | brew install jenv | jenv/jenv: Manage your Java environment |
Node.js | nvm | wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.1/install.sh | bash | nvm-sh/nvm: Node Version Manager - POSIX-compliant bash script to manage multiple active node.js versions |
Ruby | rbenv | brew install rbenv | rbenv/rbenv: Manage your app’s Ruby environment |
Python | pyenv | brew install pyenv | Simple Python version management (from pyenv) |
与JetBrains IDE集成,需要做两件事情。
Settings
→ Tools
→ Terminal
, 在 Application Settings
中 Shell path
改成 wsl
.
Remote Development
Ctrl + Shift + P
, 输入 shell command
, 执行 Install 'code' command in PATH command
code .
在vscode中打开当前目录。21年的时候做桌面改造的时候,想给自己加一个时钟。看了一圈之后,最终入手了AWTRIX Pro mini。
在AWTRIX App Store中有很多有趣的App,比如GithubFollowers, Bilibili等,并且安装了GithubFollowers,一段时间之后,发现那个数字一直卡在7,尴尴尬尬,内心毫无波澜,于是卸掉。
于是就想看看自己自己博客有多少有效阅读量(每篇博客的阅读量之和)。
这是我第一次开发AWTRIX App,我也是极其懵逼。阅读官方文档是最快捷的方法,如果有兴趣可以参考Programming (blueforcer.de)
我的博客是使用Hexo搭建的,阅读计数使用的是LeanCloud。
LeanCloud是提供了API接口,文档参见 存储 REST API 使用指南 - LeanCloud 文档
1 | Sub App_startDownload(jobNr As Int) |
这一步需要注意的是 App.get()
中key的大小写,我在这里栽倒了。
1 | Sub App_evalJobResponse(Resp As JobResponse) |
total_view
是一个全局变量,记得清零。
1 | Sub App_genFrame |
代码详见:https://github.com/chengqing-su/awtrix-hexo-leancloud-counter
如果你需要编译号的Jar包,请自取:https://github.com/chengqing-su/awtrix-hexo-leancloud-counter/releases/download/v1.0.0/HexoLeanCloud.tar.gz
最近几天看着数字不对地变化,感觉自己更加有动力去写博客,去维护博客。
]]>在大学的期间,我们会以团队的方式完成一项大作业,比如写一个小编译器,基本上大作业都会要求写一份报告。
团队成员:A、B、C、D
报告结构:介绍、原理分析、设计、实现、总结和展望
分工:
A:完成介绍、总结和展望两部分,合并报告
B:完成原理分析部分
C:完成设计部分
D:完成实现部分
为了统一风格,比如标题字体、正文字体,以及大家各自完成各自的部分不用等待别人,因此我们会先做一个模版。之后A、B、C、D都会基于改模版去填充各自的内容。这时候我们就有了一个Word文件,我们姑且取名为 homework-v0.docx
.
当B在开始写原理分析的时候,他需要先从A那边拿到, 然后复制一份homework-v0.docx
并命名为homework-v0.1.docx
。在新文件中开始自己的工作,写完之后保存。检查一遍之后,他发现有些小问题要改一下,因此复制homework-v0.1.docx
并命名为homework-v0.2.docx
。
当B完成了自己的部分,这个时候需要将B完成的部分合并到模版中。复制homework-v0.docx
为homework-v1.docx
,在新文件中插入B完成的内容然后保存,这个时候就形成了v1版本的报告。
这个时候,我们有了两份文件:
1 | homework-v0.docx |
v0和v1之间的区别是什么?v1在v0的基础上新增了内容,而上文中v0.1和v0.2是更改了一些内容,我们称这些内容为变更。上文中,我们通过复制文件方式实现了版本的管理和追踪,实现了对变更的管理和追踪。
这只是版本控制的一种实现方式,一种最简单的实现方式。接下来再聊聊版本控制系统。
什么是版本控制系统,用于管理和追踪变更的工具。这里面的变更不仅仅是针对代码的,也可以是文档或者其他的工程文件等。
使用复制文件这种方式,很容易犯错,一不小心就会写错文件或者覆盖到意料之外的文件。
因此就有了本地版本控制系统,通常是采用数据库来记录文件的历次更新差异。本地版本控制系统是第一代版本控制系统,其代表是Revision Control System(RCS)。RCS的工作原理是将补丁(文件之间的差异)以一种特殊的方式保存在磁盘上,然后添加补丁的方式重新创建任何时间点的文件。
在本地版本控制系统的使用过程,不可避免的问题就是如何与其他开发者协同工作。
因此就有了集中版本控制系统,也就是第二代版本控制系统。相对于本地VCS,其提供了如下优点:
当然也是有缺点的,最大的缺点就是单点故障。日常的开发协作是严重依赖于中心服务器,如果服务器挂了,项目成员将不能进行协作,如果服务器的磁盘损坏且无备份,有可能会损失整个历史记录。
其代表工具有CVS,Subversion(SVN)
分布式版本控制系统中,每一个客户端不是提取了最新的快照,而是镜像了整个代码仓库,包括历史记录等,如果某个服务器挂,可以使用任何客户端的存储库复制回服务器中以将其还原。
分布式版本控制系统,又称为第三代版本控制系统,其代表有BitKeeper、Git、Monotone、darcs、Mercurial。目前Git是主流的选择。
以上部分,关于本地版本控制系统,集中版本控制系统,分布式版本控制系统 主要来自于Git的官网,只有部分内容,详细内容请阅读官方资料。
还完了贷款。
换了一份工作。离开了ThoughtWorks,加入了SAP。
完成了第一场纯英语Session(2021年10月28日)。
学会了游泳。
做了一次桌面改造。
接种了新冠疫苗。这是我小学几年级之后第一次接种疫苗,小学接种完疫苗之后没多久就得了脑膜炎,虽然二者没有啥相关性,但是还是怕。
入手了一个扫地机器人。
组装了一台电脑。6月组装电脑,年底发12代,有一种49年入国军的感觉。
新入手了一台NAS。目前总存储应该超过了30T了。
……
刚跑路,前东家就上市了。
今年不适合理财,或者说我不适合理财。
在坡县觉得没地方可去,回国后是啥地方也没有去(就回了一趟家,然后去了一趟深圳)。
至今买不起显卡,现在的显卡连帝国时代都带不动。
2022年,要有规律。早睡早起好身体。
2022年,要有朝气。
2022年,要多出去走走。
说出来其实很简单,如下所示:
1 | waiting-for-approval: |
这里面有两个关键字段: when
和 allow_failure
。
when
该字段指示在什么条件下执行该Job。可以使用如下值,
on_success
(默认): 当上一个stage中的所有Job成功执行之后才能执行或者上一个stage中所有的Job 配置有字段allow_failure: true
。manual
: 手动触发该Job。always
: 无论之前的stage是否成功,总是执行该Job。on_failure
: 当上一个stage中有Job失败的情况下,执行该Job。delayed
: 延迟一段时间执行该Job。never
: 不执行该Job.allow_failure
该字段决定了当前Job执行失败的情况下,是否继续执行pipeline。值可以是true
或者false
。
注意其默认值,这是比较坑的一点
when: true
时,默认值为 true
when: true
并且配置了 rules
,默认值为 falsetrue
我想实现如所示pipeline
.gitlab-ci.yml
如下:
1 | image: alpine |
得到执行结果如下:
我还没有点approval,怎么就执行 deploy-to-prod
了?又看了一眼pipeline的状态是 passed
,怎么就 passed
了?
又去看看了文档Keyword reference for the .gitlab-ci.yml
file | GitLab ,在 Additional details
中发现 了下面这段话
The default behavior of
allow_failure
changes totrue
withwhen: manual
. However, if you usewhen: manual
with[rules](https://docs.gitlab.com/ee/ci/yaml/#rules)
,allow_failure
defaults tofalse
.
谜题解开了!
之后又找到另外一篇文档 Choose when to run jobs | GitLab ,创建一个必须被手动触发的Job。
修改.gitlab-ci.yml
,如下所示:
1 | image: alpine |
其执行结果如下:
虽然不推荐使用动态pipeline,但是在某些场景之下,使用动态pipeline会帮助我们在保证可读性不变甚至提高的情况下,同时提高了可维护性,这个时候我们推荐使用动态pipeline。
比如,我们需要在CI上对同一个项目跑100个测试,这一个测试唯一的区别就是传入参数不一样,这些参数会随着我们产品的演进而进行更新,比如如下一个片段重复100次,是不是会很痛苦?
1 | test-with-arg-100: |
在Gitlab CI/CD 中,父子pipeline就是在一个pipeline中嵌套执行另外一个pipeline配置文件,即子pipeline。
子管道类型:
更多内容可以参考官方文档
在我的Homelab环境中,有一个Infrastructure的Kubernetes集群,集群中需要部署一系列的基础应用,比如:
每一个应用都有一个对应的部署脚本,如下所示。
1 | ├── auto |
上面的部署脚本,我都是使用 auto/deploy-*
这样的模式命名部署脚本的。这样根据部署脚本规律生成子pipeline的YAML配置文件,生成脚本如下。
1 |
|
部分pipeline配置文件 .gitlab-ci.yml
如下:
1 | stages: |
pipeline执行图如下所示:
在当时,可以预见的是,下一份工作可以长期在家办公(WFH),因此桌面还是需要改造一下,让自己在未来的生活和工作满意,取悦自己。
先看一下之前的桌面,
主要部件如下:
主要问题:
选择显示器最重要的是解决第一个问题,让我可以开心地码字。
第一步,确定确定尺寸。我桌面宽度是75cm,之前的是显示器是23.8寸,感觉还是比较舒适的,因此尺寸范围是23.8-27。
第二步,确定分辨率。之前的显示器是2560*1440dpi,文字显示的细腻度虽然比1080p好很多,但是依然有点糊以及有锯齿。我使用显示器的主要场景是写代码,所以文字显示细腻度对我来说是很重要的,因此选择分辨率为4K。
第三步,确定其他功能。我长期面对屏幕,因此护眼对我比较重要。
第四步,显示器品牌。我个人更加倾向于DELL,LG这一类的大厂,也包括之前使用过的AOC。
最终的选择是DELL P2721Q。
最开始的时候购入的并不是DELL P2721Q,而是AOC U27U2D。从参数上来说AOC U27U2D完全满足我的需求,但是使用了一天之后,有一丢丢眩晕,然后7天无理由退货,重新购入DELL P2721Q。选择显示器的时候,重要的还是自己的眼睛舒服。
之前的屏幕挂灯使用的是倍思的,其开关和调节按钮均在挂灯,每次开关都需要站起来,很不方便。
更换成小米的显示器挂灯。这款挂灯最大的优势就是够用而且便宜。
之前使用的罗技C310摄像头是2017年购入,但是主要使用还是在2020年。主要的使用场景就是Zoom视频会议,除此之外没啥太大功能。
更换摄像头最主要的理由还是想使用Windows Hello。我使用1Password管理自己几乎所有的密码,使用了Windows Hello之后,我就不用每次输入PIN码或者密码了。
Windows Hello摄像头可选项特别少,当然淘宝上也还是有不少自行改装的。下面是几款我知道的支持Windows hello 的摄像头
我购入的是联想500(购入时价格399)。理由就是相较于罗技C1000e(京东报价1499)便宜,而且当时没发现Intel RealSense F200(淘宝200多)。
2021年6月,第一部分改造到这里就结束,主要是对一部分硬件进行了升级和更换。
2021年6月21日,加入我现在的公司,开始了长期的在家办公。
第二部分改造起因如下:
改造目标:
为什么选择电动升降桌?
久坐的危害是非常大的,比如人脑供血不足,全身肌肉酸痛,脖子僵硬,痔疮,肥胖等等。坐站交替可以有效的缓解这些问题,电动升降桌就提供了站着办公的可能性。
如何选购可参考如下链接:
2021年电动升降桌选购攻略及高性价比电动升降桌推荐(20210628更) - 知乎 (zhihu.com)
电动升降桌推荐|电动升降桌选购指南 - 知乎 (zhihu.com)
我最终购入的是Brateck北弧 K33。桌面大小,我个人还是倾向于选择150*75的。使用了快一个月了,够用但是并不优秀,比如:
综合其价格和配置,总体上还是满意的。
我购入的电脑椅是黑白调的电竞椅,入手这款椅子的原因:
我比较喜欢在疲惫的时候小憩一会儿或者单纯闭着眼睛躺着思考,这款电脑椅支持后躺,但是并不完美。当坐着的时候靠背有一定的支持作用,比较合适。但是躺下的时候,颈部是悬空的,很难受,加一个颈枕可以缓解这个痛点。
电脑椅和电动升降桌,每一个拎出来看,都还行。但是1+1 < 2啊,两个之间的高度不契合,因此我加了一个网易严选的乳胶坐垫。
选择入手显示增高架的原因如下:
最终是在淘宝上购入的一款120cm的实木增高架。
在增高架上可以摆放一些小物价,比如书签、蓝牙温湿度传感器、便利贴等等。增高架最右边放着两个控制屏幕挂灯的旋转按钮。旁边是两个叠在一起的收纳盒,用于收纳数据线。将小米USB充电器使用3M魔术贴粘在了增高架上,可以进一步利用空间。这样剩下的空间就可以收纳键盘和鼠标。比如在看书或者吃饭的时候就可以把,键鼠收纳起来,桌面空间就足够大了。
收纳桌下的各种线,是桌底下变得整洁。之前总是不小心踢掉某根线啥的。
在长81cm的收纳槽可以放下很多东西,一个10孔插排,一个KVM切换器,一个4空插排。可以使用束线带将多余的线收纳起来,这样线就不会特别乱。
洞洞板可以灵活地收纳一些物品,比如将剪刀、手工刀、卷尺等挂在上面使用起来更加方便。
我选择的这一款带有一个托盘,托盘下面的空间放下扫地机器人,托盘上放打印机,这样可以更加有效率地利用空间。
简单介绍一下我的使用场景,我有两台电脑,一台是公司的macbook pro,一台是自己组装的台式机。每天我都需要在这两个设备之间切换使用,工作的时候使用公司的电脑,非工作时间就使用自己的电脑。
之前的解决方案是使用了两个切换器,一个HDMI切换器用于切换其中一个屏幕,另外一个便宜的KVM的切换器用于切换屏幕和键鼠等外接设备。主要问题是,每次切换需要手动按两次按钮。
购入新的KVM切换器之后,可以使用鼠标在两个设备之间快速切换。而且因为不需要手动在切换器上操作,可以将其收纳到桌下理线槽上,进一步节省桌面空间。
到这里,第二部分改造就完成了。
主要部件:
通过这次改造之后,我能够更好地利用桌面空间,在不同的任务之间更好地切换。比如在看书的时候,可以把键鼠收纳到增高架下。利用增高架可以有效地将线缆隐藏起来,使用收纳槽可以更好地收纳线缆。
我也曾尝试使用磁吸模块将线缆固定在桌子侧边,这样桌面虽然看起来很整洁但是桌下依旧乱,因此暂时放弃了这种方案。即时收纳,物归原处才能够保持桌面的整洁。
到此刻位置,其实还有很多事情没有做,比如:
这些会在桌面改造2.0中慢慢来做,在未来的部分我更加倾向于自己DIY。
]]>大致思路就是,在Homelab环境中,利用Synology套件Active Backup for Business进行Vmware vSphere虚拟机备份。
数据的灾备是很重要的,就像是开车系安全带,骑小摩托戴头盔,都是为了安全。在这篇博客中,将带着大家一起看看在利用群晖NAS备份vsphere中的虚拟机。
Active Backup for Business
是群晖NAS的一个套件。
主要功能:
详细信息参考 Active Backup for Business技术规范
在套件中心中安装Active Backup for Business,该套件是免费的,很实在。
安装完成之后,打开它。
Hypervisor,也称为虚拟机器监视器或 VMM,是创建和运行虚拟计算机 (VM) 的软件。
按照下图添加你的esxi或者vCenter:
添加完成之后,就可以在界面上看到Esxi或者vCenter的机器了,如下图所示。
在创建过程中,我们通常会指定一个备份名称(上图中是vSphere-Task-1), 然后可以选择是备份一台虚拟机还是多台虚拟机(上图中选中了openvpn-access-server),然后点击下一步。
在列表中,选中一个共享文件夹用来存放备份数据。安装套件的时候会默认创建一个叫ActiveBackupforBusiness的共享文件夹。然后点击下一步。
继续点击下一步。
在这一步中是配置备份任务。可以使用默认配置,或者根据自己需求配置。然后点击下一步。
这是一个检查页面,没问题就直接点击下一步。
这一步就是很重要的一步,默认情况下是手动备份。这里推荐使用定时备份,这就不需要人为干预了。这样的备份也就更有意义了。然后下一步。
这一块儿是设置保留策略,推荐使用。可以根据自己的情况进行选择,然后下一步。
这一块儿是设置恢复权限,然后下一步。
整个备份任务的总结,检查一下,没有问题就点击完成。这时候会有弹窗弹出,讯问是否现在备份,可根据自己的实际情况进行选择。
到任务列表中,我们就可以看到刚才创建的备份任务以及上一次备份状态和下一次备份时间。
定时备份任务会定时被触发,而手动备份就需要自己手动触发。
在虚拟机列表中选中已经备份了的虚拟机,然后点击恢复
从版本列表中选择一个备份版本,然后下一步。
选择恢复到VMware vSphere,然后下一步
选择快速恢复还是完全恢复。
快速恢复:将NAS的磁盘挂载到Esxi上作为Datastore。
完全恢复:将备份数据复制到Esxi的Datastore中。
根据自己的实际情况选择,然后下一步。
选择虚拟机恢复到哪里,支持原路径恢复,也可以更改到新的位置。然后下一步。
检查一下,没有问题就点击完成,开始恢复。
在Homelab环境中,利用NAS对数据备份可以有效地保证数据安全。
重要的数据一定要多备份。
]]>DevOps 是一系列文化理念、实践和工具的集合。其目的是:
DevOps文化的核心目的打破团队(Dev和Ops)之间的“墙”,提高团队之间的透明度、沟通和协作。DevOps的核心理念可以理解为如下四点:
狭义上,Dev和Ops应当共同对产品的成败负责。在敏捷软件开发的实践前提下,团队中的所有角色(包括但不限于BA、Dev、QA、Ops)共同对产品的成败负责。在整个产品的生命周期内,团队应当共同承担维护系统的责任,确保可以更快可靠地交付产品。
反馈对于DevOps是非常重要的。通过反馈,我们可以不断地改进团队不同角色之间的协同工作方式以及系统。
反馈不仅仅包括团队角色之间的反馈,还应该包含系统与团队的反馈。比如:
在DevOps的实践过程中,我们要将反馈这个核心理念铭记于心。在增强反馈的过程中,也要注意不要过度,应当避免团队成员陷入过多工具和消息中。
自动化是整个DevOps的基石,有助于团队协作。自动化测试、自动化部署等可以让团队各种关注于业务本身,减少人为错误的机会。自动化可以让团队更快、更可靠地构建、测试、发布产品。
在实践DevOps的过程中,我们应当尽可能地减少手动操作。实现自动化的过程中,我们需要不同角色之间的协作和沟通。建议有一套统一的自动化脚本来增强团队不同角色之间的协作,建立统一的上下文。
质在开发过程中,要求软件生命周期之间参与的各个角色都需要实时的对软件的质量负责。确保软件在交付到下一环节前已经有了基础的质量保证。从而减少因为质量问题导致的返工,避免浪费大量人力成本。
为更快更可靠地交付应用和服务,在源头上对质量进行把控是必不可少的。
DevOps的常见实践如下:
DevOps实践的具体解释,不在此文中赘述,为有另外的文章单独解释。
协作工具:Jira, Mural, Slack, Microsoft Teams等
版本控制工具:Github, Gitlab, Bitbucket等
持续集成工具:Jenkins, TeamCity, Travis CI等
部署工具:Terraform, AWS CloudFormation, Ansible, Helm等
监控工具:Zabbix, AWS CloudWatch等
DevOps的工具极其种类非常多,上述不过是其一小部分。
租住的地方是一个一室一厅带厨房和阳台的回迁房,这也基本上就是我的活动范围。白天不是在沙发上窝着,就是书桌前坐着,晚上当然是躺床上了。
先从最简单的地方说起,卧室。卧室里面最主要的两个东西,空调和床。这个空调是一个我之前从未听说过的品牌—志高,当然也有点老旧了,也自然是不可能联网的。成都的夏天还是比较热的,在客厅书桌前干活的我感觉到了热了之后,需要回到卧室找到遥控器打开空调,略微有点麻烦,也容易打断自己的思路。
这个时候就需要引入一个设备—米家空调伴侣2。这个小东西可以将普通空调智能化,说人话,就是遥控器可以做的事情它都可以做,还不需要你在它面前操作。你把它插在空调插座上,再把空调插头插在它身上,让它蹭上你家WiFi,然后就可以通过米家APP操作空调了。这是第一步,我们可以把遥控器扔到某个不用的角落里面了。
在炎热的夏天,我在电脑前面敲着键盘,码着字,机柜里面几台服务器呼呼地跑着,温度逐渐上升,感受到了温度的残忍,于是我拿出手机,通过米家APP将空调打开并调至16度,慢慢感觉到了一丝凉爽。简而言之,当我坐在书桌前且周围的温度让我感到炎热时,开启空调,调整为制冷模式,设定温度为16度。如果我知道具体温度是多少,我就可以将“让我感到炎热时”量化为一个具体数值。因此我们需要一个传感器来测量温度---小米温湿度传感器。再来一个小米人体传感器来检测是否有人移动,这个比较鸡肋,一分钟检测一次,假设第一分钟检测到了你,然后你保持不动,那么后续就不会检测到有人移动。然后在米家APP中添加一条智能:
1 | 同时满足 小米人体传感器有人移动 和 小米温湿度传感器温度高于30度时 执行开启空调到指定状态 |
添加之后需要一段时间之后才会生效,大概几分钟吧,没有具体测试。当你感受到炎热时,站起来再坐下就可以触发上述规则了。有点智障了。。。。人体传感器就不能判断有没有人吗?
有一段时间,尝试着不把手机带入卧室,这个时候就需要一个闹钟叫醒我起床,还有如果半夜醒来了看个时间。小爱触屏音响就完美的满足了我的需求,在工作日和非工作日可以在不同的时间叫醒我。懒到极致的我,在之前总是被迫起床关灯以及抹黑找床(经常撞伤),因为卧室只有一个开关且在门口,直到有一天看到米家床头灯2代,及时购入。之后的生活就是进卧室时,“小爱同学,开灯”,躺下睡觉时,“小爱同学,关灯”。
一朝被盗,终身防贼。2018年9月7日凌晨(具体我也不知道),在我回成都的第三个月,我家被入室盗窃了,当天报案,至今没有结果,估摸着没有结果了。当天入手了门窗传感器,人体传感器,小米摄像头等,所有有可能的进入的家里的窗户和门都安装了门窗传感器,阳台安装了小米摄像头和红外传感器。同时小米摄像头的数据也会传输到NAS中,多NAS备份,异地备份。租房的一个小Tips,不要租低楼层的,临街的以及外面有可能进入的。
一个人住总是怕钥匙忘带或者不小心把钥匙丢了,没有备份就没有安全感。小米智能门锁完美解决了这个问题。并且在我回家的时候,可以自动触发关闭摄像头并开启小米网关在家模式。
使用过程中,有哪些痛点?
1. 我会经常更换自己家里的WiFi密码,看心情可能一周一换,也可能一月一换。在更新的过程中,需要把这些智能家居设备重新联网,工作量巨大。
2. 上述的那个问题,小米给出了解决方案,使用小米路由器的一个新功能畅快连。经过本人试验,并没有什么用途,因为我家所有的设备的最新固件都不支持。并且小米路由器对于我不适用,重度网络使用者很容易就感受到了断流的痛。
3. 米家APP在设备多的时候,极其难用。没有一个很好的控制中心。未来打算尝试一下Home Assistant,自己收集数据,自己做dashboard,不让数据离开局域网。
4. 如果你的小米网关坏掉了,那我只能表示恭喜你了。你需要重新添加设备,然后重新命名极其麻烦的过程。
5. 核心模块(比如小米网关)不是高可用的。
在这个野蛮的互联网时代,谁又不是在裸奔呢?
如果不是一个公众人物,选择一个某个智能家居平台的时候,只需要问自己信任与否。在使用的过程中,尽量减少对云存储的使用,在家的时候尽量关闭摄像头等等。没有什么事比健康安全地活着更重要。
如果你是一个公众人物,能不用就不用,攻击你的收益远远高于成本。
]]>大致而言,我会遵循三个原则:
什么是手动操作?任何没有被代码化(as code)的资源或者操作都可以被认为是手动操作。
常见的手动操作:
当你需要做任何手动操作之前,先问自己一系列问题:
The Boy Scout Rule: Always leave the campground cleaner than you found it.
干净,可以从两方面说,代码整洁和环境干净。童子军军规:让营地比你来时更干净。这是一条非常适用的规则。
代码整洁中的“代码”不仅仅指业务代码,还应当包含测试代码,基础设施代码等一切代码。我见过一些业务代码很整洁,非业务代码很糟糕的项目,为什么会这样呢?我大胆地猜测一下,团队没有把基础设施代码当成代码,而是在战略上忽视了它。
所有的代码享有平等的地位。无论是否是业务代码,在应用的生命周期中,我们都需要去维护。
关于这部分的内容,强烈推荐学习一下《代码整洁之道》和《重构》。
在开发阶段,保持开发环境的干净。
在CI/CD 环境中,保持构建、测试、部署环境干净。通常而言,一个CI/CD 的Agent会被不止一个应用使用,因此保持环境的干净就显得尤为重要。
在生产环境中,保持运行环境干净。
Entities should not be multiplied unnecessarily
在写这篇的博客的时候,我也一直在纠结是不是要把干净和简单合并在一起写。在提到干净的时候,它和脏是对立的,往往是指代码是否整洁。而简单和复杂是相对应的,通常是和业务,架构,技术栈等相关的。
业务复杂与否是来自于功能需求,这一块儿没有深入研究过,暂且不谈。
架构和技术栈的复杂度来自于非功能性需求。一个项目总会有人员的变动,在人员变动的过程中,复杂的东西在传递的过程中很容易失真。在引入一项新的技术或者语言时,需要仔细考虑是否真的需要,如果不是必须的就不要引入。简而言之,遵循奥卡姆剃刀原理:如无必要,勿增实体(Entities should not be multiplied unnecessarily)。
]]>如果项目是一个大型的单体应用,通常而言会有前端和后端开发工程师,以后端开发工程师为例,在后端开发工程师的电脑中会装有以下环境:
如果该项目只有一个后端开发工程师,可能会有以下问题:
如果该项目有多个后端开发工程师,在基于一个后端开发工程师可能会遇到的问题的基础上,可能还会遇到如下问题:
如果该项目上线之后,转移给另外的一个运维团队去维护,可能会遇到如下问题:
如果微服务应用是一个团队开发的,那么可能会遇到如下问题:
如果是微服务应用多个团队开发的,基于上面情况遇到问题,可能还会出现如下问题:
如果之后转移给一个独立的运维团队维护,会遇到如下问题:
可能还有诸多问题是我所未考虑到的。
大致总结一下上述问题:
基于上面的诸多问题,只能对一些问题提供解决一些解决思路。
在所有的问题中,运行环境不一样是最普遍也是做容易解决的一个问题。在这一类问题中,最简单的解决方案就是容器化。
需要做到两个容器化:
我相信绝大多数团队都可以做到线上运行环境的容器化,因为这并不是一件很难的事情。而本地开发环境的容器化确实最容易被忽略的。
本地开发环境的容器化,可以很好地确保开发工程师之间的环境一致以及开发环境和线上环境的一致。同时,也可以很好地解决不同服务之间所采用的运行环境版版本不一致而导致开发出现的各种奇奇怪怪的问题。
技术栈的多样性是我们所推崇和所追求的,其本身并不是问题,但是技术栈的多样性不可避免的会引入一定的副作用。而隐性上下文就是其中最明显的而又不容易被关注的。
什么是隐性上下文?简单举个例子,
node.js
开发,使用 npm
对包进行管理,可能会把单元测试脚本命令放在 package.json
中,也可能不会。node.js
开发,但是使用 yarn
进行包管理,同样单元测试脚本可能放到 package.json
, 也可能不会。Java
开发,使用 gradle
进行包管理。Kotlin
开发,使用 maven
进行包管理。对于A团队而言,A团队知道如何把自己团队的本地环境运行起来,如何运行单元测试,可能会忘记这些内容写入到readme中或者package.json中。突然有一天,B团队的成员需要去更改一个A团队的实现,这个时候基于B团队的成员使用的技术栈而言,虽然会花点时间去阅读代码,或者基于已有的技术背景做出一些探索性的尝试,也是比较容易了解到如何本地启动A团队的服务,如何进行单元测试。
如果是C团队的程序需要更改A团队的一个实现,那么会是如何的呢?
如果有一天这个微服务应用完全交给了一个独立的运维团队运维,那么又会是什么样的呢?
这一类团队内部默认都知道的,没有通过脚本或者文档呈现出来的上下文可以被理解为隐性上下文。
如何解决隐性上下文?基于本地开发环境容器化的基础上,自动化脚本是一个比较好的实践方案。比如在每个服务代码库中,都写一个 auto/test
脚本,这脚本是负责跑单元测试,这样在不同团队之间是否会更好的管理这些隐性上下文?再比如代码风格检查也可以有一个脚本叫做 auto/check-style
。
服务与服务之间的代码风格不一致,这是正常的,不同的技术栈必然会导致风格不一致。
那什么是问题?
如何解决?我们所遵循的所有代码风格都应该被工具管理起来,都可以配置化。
上述几个问题,解决方案就是 本地开发环境容器化以及自动化脚本。
]]>CI/CD中涉及到三个概念:持续集成(Continuous Integration)、持续交付(Continuous Delivery)、持续部署(Continuous Deployment)。
持续集成是指代码push到代码库后,通过运行构建和测试的过程来减少引入错误的可能,这个过程是自动被触发的。持续集成并不会消除bug,但是能够让我们更加容易地发现和修复bug。
持续集成主要运行构建、单元测试以及代码风格检查等这一类运行较快的测试和验证。
持续集成会运行在开发分支和master分支上,通常情况下,在开发分支上通过了持续集成的代码才能被合并到master分支。
持续交付是持续集成的扩展,确保可以以一种可持续的方式将新的变更快速发布到生成环境。持续交付主要是确保应用可部署,可以随时发布到生产环境。
持续交付相比较持续集成,增加了验收测试,自动部署到staging环境等。可能会在staging环境做一些人工验证工作,验证工作完成之后再部署到生产环境。
持续交付主要运行在master分支,但是验收测试有时也会在开发分支上运行。
持续部署也是基于持续集成的,与持续交付相似,比持续交付更进一步。持续部署会将每一个主线上的改变自动部署到生产环境。
相较于持续交付,它需要更加完备的测试。
图片来源:www.atlassian.com
下面将列举一些引入CI/CD带来的好处。
频繁部署: CI/CD会加速应用构建和部署过程。能够帮助我们一天多次部署。
降低风险:通过不断发布尽可能小的功能,可以减少生产出现Bug的风险。同时也会让QA和客户对于发布不会感到很痛苦。
降低成本:引入CI/CD意味着需要覆盖更全的单元测试,更加完善的验收测试,看起来是引入更多的工作量。其实不尽然,没有很好的单元测试和验收测试,意味需要花费大量的时间去手工测试,同时有可能导致已有功能被破坏。当出现bug的时候(bug一定会出现的),没有测试,就意味着可能需要大量去查找和修复问题。
提高质量:通过一系列可靠的测试,可以及时地发现和修复bug。
提高团队协作:通过一系列的测试,能够帮助我们确认,我们的改动没有破坏到已有功能。
WSL
期间踩过的坑,小工具,优化等等。在WSL中挂载Windows的磁盘时,文件的权限会变成777,在ls
的时候会发现绿油油的一片。
第一步:执行sudo vim /etc/wsl.conf
1 | [automount] |
第二步:重启wsl
对于WSL2可以在PowerShell或者CMD中执行wsl --shutdown
对于WSL1可以以管理员身份在PowerShell或者CMD中,执行net stop LxssManager
和net start LxssManager
更多WSL的配置参考wsl-config
如果在WSL中遇到了 Error: EPERM: operation not permitted, symlink
或者说和symlin
有关的错误的时候,可以先检查一个磁盘的格式是否是NTFS或者ReFS 。
更多内容,请阅读WSL踩坑之硬盘格式问题
在使用WSL
的过程中,有时候会出现时间同步问题,通常是WSL
时间比Windows 10
的时间晚。
如何解决?
如果是Ubuntu的话,可以使用以下命令:
1 | sudo apt install ntpdate |
Microsoft PowerToys是一组小工具,用户可以利用该工具调整和简化其Windows 10体验,以提高工作效率。
目前支持的功能:
Win + Shift + C
。没咋使用过,我对这个工具没啥需求。Alt + Space
Windows
键时,可以给你一些快捷键的提示。下载地址:https://github.com/microsoft/PowerToys/releases/
方案一:Windows 自带的 Snip & Sketch
和 Print Screen
。Snip & Sketch
可以使用快捷键 Win + Shift + S
,如果截图使用不多的话,可以使用该工具。
方案二:一个第三方工具snipaste,很强大的一个截图工具,易用性高于Windows 10 自带的工具。下载地址:https://www.snipaste.com/
这是目前我自己最喜欢用的一款解压工具,没有发现明显的痛点。最开始使用的时候,该工具免费版本还没有内嵌广告,现在已经有广告了。
下载地址:https://en.bandisoft.com/bandizip/
虽然在Windows 10
上可以使用Alt + Tab
切换窗口,但是这个快捷键是跨多个应用的。于我而言,很多时候需要的是在同一个应用之间切换,比如多个Microsoft Word之间切换。
如果需要在多个应用之间切换窗口,可以使用Alt + Tab
。
如果需要在同一个应用直接切换窗口可以使用EasySwitch
,快捷键 Alt + `
下载地址: https://neosmart.net/EasySwitch/
该工具在Windows 10 上实现了macOS Mojave的动态壁纸功能。
下载地址:https://github.com/t1m0thyj/WinDynamicDesktop
Visual Studio Code,一个很强大的IDE。
下载地址:https://code.visualstudio.com/
我有一个小小的内网,里面有很多的服务,目前阶段没有时间做DNS服务器,所以就需要一个随时切换Hosts,因此一款够用的Hosts工具就显得很重要。
Hozz就是这样一款工具,可以帮助我更快捷地访问自己服务。
]]>