前言

有些时候的巧合让人匪夷所思，前两周刚刚尝试了一遍Docker操作，紧接着就收到好朋友说要学习k8s容器部署的建议，最近两周抽空看了一些关于k8s的知识，相关概念真的是太多了，概念本身是枯燥的，但是当概念运行起来就有意思多了，这时候取出费曼学习大法，尝试着用自己的话来描述这些概念，看看自己是不是真的学会了。本文k8s相关概念均来自个人理解，后续随着学习深入可能会有改正，勿喷。

@[toc]

前言

还记得上一篇《借助ChatGPT使用Python搭建一个工具网站》总结中我利用ChatGPT写了一个网站，最终它运行良好，就在昨天我看到了Github Packages，不久前刚刚使用了GitHub Actions，我发现Github在被微软收购后，并没有变的更“闭源”，之前广大网友还在调侃，最大的闭源软件公司收购了最大的开源平台，看来一切还在向好的方向发展，简单介绍下前面提到的这两个都是什么东西。

前言

不知不觉ChatGPT已经风靡一年多了，现在基本每天工作时都会用到，相比于传统的搜索引擎它究竟强在哪呢？我觉得以往的搜索引擎是一个机器，你给它关键信息它能返回匹配关键词的内容数据，而ChatGPT更像是一个机器“人”，它同样可以返回给你匹配关键信息的数据，同时可以按照你的指令进行加工，更优秀的是它还记得你跟它说过的每一句话，就像拥有一个可以存储交流记录的大脑一样，你可以赋予它一些性格和规则，让它来帮你做事情，交流的多了它就能变成一个性格鲜明的“生物”，并且可以无条件接受你的命令，所以最近突发奇想让它帮我搭一个网站怎么样，说干就干起来了。

前言

Protobuf，全称Protocol Buffers，是一种由Google开发的用于序列化结构化数据的开源数据交换格式，Golang作为一种后端语言，免不了使用protobuf这种数据交换格式，本来打算写个小例子展示一下怎样在go语言中使用protobuf，结果遇到的问题到不少，特别是这个go_package的要求，也是之前在项目开发过程中遇到的，这次就查找一下具体原因以及怎么使用吧。

前言

如果你接触go语言比较早，一定有过当年所有go源码全部放入 GOPATH 下的混乱经历，不过发展到今天，go的包管理使用 go.mod 和 go.work 已经能得心应手，满足绝大多数的开发不成问题，其实在 go.mod 引入之后，go的包管理就有了明显的改善，再也不像原来那样好似闹着玩一样了，关于go.mod使用和管理我也是一知半解，想要教程可去官网或者查找各种详解资料，只是最近有点疑惑，这个go.mod以及go.sum要不要自己手动管理，带着这个疑问我做了一些测试可以得出，go.mod 的最初不需要手动管理，如果后来需要调整引入包的版本，可以手动调整。

前言

这个命令出现在与运维同学沟通过程中，在此之前要是问我一个域名对应的服务器是IP地址是什么，我肯定优先想到的是 ping 这个命令，这个命令确实可以在回复的信息中看到IP地址，但是不全面，有时一个域名对应不止一个IP地址，这时就要用到 nslookup 命令了，这也是在沟通中学到的新知识点。

前言

先交代一下背景，距离正式接触golang这门语言已经有5年时间，平时偶尔也会用go写写工具和功能，但其实充其量就是语言小白，基本上就是按照教程配置好环境，按照需求写写逻辑，能跑起来就行了。golang随着这几年的变化，这门语言的变化还是非常大的，之前写过一篇《Go环境配置时遇到的GOPATH路径以及包管理问题》，可以看出之前配置的变量很像Java早期的配置环境，从1.11 版本之后go工程不必放到 GOPATH 路径中了，通过go.mod文件来标记并跟踪每个软件包的版本，灵活度大大提高，从此 GOPATH 概念逐渐淡化，在1.18版本新引入一个新功能go.work，它被设计为解决在同一工作空间中处理多个模块的问题，使得go工程的模块管理更加方便。

前言

工作一入门便是游戏服务器开发，所以常常有连接Linux服务器的需求，之前用的最多的是Xshell，最近这个软件个人版只能免费使用一个月了，超过时间会提示更新无法正常使用，工作当中用的最多的是SecureCRT，不过这个软件是收费的，公司买了授权，可以正常用，但是在家时就不行了，最近我找到了WindTerm这个软件，用起来还不错，记录一下。

不断追求利益的经济冲动，不停侵蚀人们的生活，压垮、吞噬并统治生活本身，无法言喻的不安和看不到明天的混沌感，让我们在现有社会经济条件下，沦为被金钱和物质所统治的行尸走肉~

前言

最近在看一本叫《饱食穷民》的书，讲述的是泡沫经济年代的日本社会，宛如梦幻泡影一样变化无常，又像断梗浮萍一样飘忽不定，到处充斥着不安的色彩，我试图从中寻找一些当前现实问题的解决方案，上段文字也是出自此书之中，阅读之后我大受震撼，其中描述的有关软件工程师的篇章，简直就是我的复刻版，无论是心境、情感、还是所面临的问题都如出一辙，读完觉得背后隐隐发凉，因为最终那些令人无法接受的结局，确实是我不想看到的。

前言

就在半月之前，负责打包更新的服务器突然登录不上去了，赶紧找来运维的同事帮忙解决，发现系统日志中有很多 systemd-journald[424]: Failed to open runtime journal: No space left on device 字样的错误，被告知磁盘满了需要清理，但是我当时登录不上去，只能让他们帮忙重启后利用单用户模式上去删除临时文件试试，但重启后发现问题解决了，很是诧异，查询服务器后台监控平台，发现磁盘空间还有50%，inode只占用了0.02%，这怎么会磁盘满了呢？