Welcome to Lework's Blog!
这里记录着我的运维学习之路-
使用kubeadm安装Kubernetes v15.4 ha集群
本次使用全手工的方式以kubeadm形式部署kubernetes的ha集群，ha方式选择node节点代理apiserver的方式。
-
使用kubeadm更新k8s集群
本次我们将实际利用Kubeadm工具来更新集群，这边沿用之前分享的使用kubeadm安装Kubernetes v15.4 ha集群，部署的HA丛集来进行
v1.15.4更新至v1.16.0。
-
使用aws-cli为常用产品批量添加监控告警
aws中国竟然没有为产品批量添加监控报警的功能…呵呵呵呵,为了减轻工作，实现批量初始化，没有我们就动手自己写脚本吧，使用
aws-cli工具可以获取到各项产品的信息，并且可以管理产品。
-
AWS 使用Lambda实现企业微信报警
aws 支持邮件和短信的报警通知，考虑时效性问题和结合公司的使用情况，需要接入企业微信的告警提醒，使用 Lambda 和 sns 的结合，可以实现这个需求，利用 Lambda 接受 SNS 的告警信息，然后通过 python 脚本发送到企业微信的接口上去。由企业微信客户端接收通知。
-
将Debian AMI从全球AWS区域迁移到中国区域
因为中国区域的
Debian版本没有新版的,是不是很无语。云平台竟然连 linux 发行版的系统都没的。。。大概的步骤
-
首先,在
AWS东京地区启动Debian实例,将适当大小的EBS卷挂载到该 Debian 实例上,然后使用dd命令将Debian实例的整个根卷作为文件保存到该EBS卷。 - 之后,将文件复制到
cn-north-1区域中的实例.在该cn-north-1区域的实例中,使用dd命令将该文件写入EBS卷,然后为该EBS卷创建快照,并使用该快照在cn-north-1区域中创建AMI。 - 最后,用户可以使用该
AMI启动CentOS实例,该实例与在东京地区运行的实例相同。
-
-
基于Drone + GitFlow + K8s的云原生语义化 CI 工作流
在进行构建CI工作流前,先了解下2个概念
什么是GitOps?
GitOps是一种持续交付的方式.它的核心思想是将应用系统的声明性基础架构和应用程序存放在Git的版本库中.
将Git作为交付流水线的核心,每个开发人员都可以提交拉取请求（Pull Request）并使用Git来加速和简化应用程序部署和运维任务.通过使用像Git这样的简单熟悉工具,开发人员可以更高效地将注意力集中在创建新功能而不是运维相关任务上（例如,应用系统安装,配置,迁移等）
通过应用 GitOps ,应用系统的基础架构和应用程序代码可以快速查找来源——基础架构和应用程序代码都存放在 GitLab 、或者 GitHub 等版本控制系统上.这使开发团队可以提高开发和部署速度并提高应用系统可靠性.
将 GitOps 应用在持续交付流水线上,有诸多优势和特点：
- 安全的云原生 CI/CD 管道模型
- 更快的平均部署时间和平均恢复时间
- 稳定且可重现的回滚（例如,根据 Git 恢复/回滚/ fork）
- 与监控和可视化工具相结合,对已经部署的应用进行全方位的监控
在我看来 GitOps 的最大优势就是通过完善的 Git 分支管理来达到管理所有 CI/CD 管道流水线的目的,不同的环境可以对应不同分支,在该环境出现问题时候,可以直接查找对应分支代码,达到快速排查问题的目的.而对于 Git 的熟悉,更是省去学习使用一般 DevOps 工具所需的学习成本和配置时间,开发人员可以无任何培训直接上手使用,进一步降低了时间与人力成本.
-
Drone CI 介绍
什么是CI/CD
持续集成（ContinousIntergration，CI）是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都需要通过自动化的编译、发布、自动化回归测试来验证，从而尽快地发现集成错误。而这些自动化的操作则由CI软件进行执行。
持续部署（ContinousDelivery，CD）在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境中。交付团队 - >版本控制 - >构建和单元测试 - >自动验收测试（e2e）- > UAT - >发布（部署，DevOps）
什么是Drone
Drone 是一个基于Docker容器技术的可扩展的持续集成引擎，用于自动化测试与构建，甚至发布。每个构建都在一个临时的Docker容器中执行，使开发人员能够完全控制其构建环境并保证隔离。开发者只需在项目中包含
.drone.yml文件，将代码推送到 git 仓库，Drone就能够自动化的进行编译、测试、发布。官方文档上面大量充斥着
0.8版本的配置文件描述,而最新的版本是1.2.3,两个版本之间有大量的不同地方，需要大家一点一点的试错摸索，不过读者在读完本篇文章后，就可以很顺畅的编写pipeline了。
-
使用kubectl插件检查deployment的所有pod是否就绪
描述
我们在进行
ci/cd流程时，应用了deployment资源时，无法知道修改的pod是否处在就绪状态，并正常工作。但是我们的应用操作时成功执行了，如果说这时pod没有正常就绪工作，也就是说我们要改变的pod没有改变，目标集群运行的还是之前的pod，如果说我们有对deployment的不可用pod进行监控，那我们得到的通知时间也是很滞后了，因此，我们需要一个在ci/cd流程中检查deployment的所有pod是否就绪并正常工作。kubectl-check就是为了解决这个场景而诞生的。
-
使用国内镜像点获取谷歌容器镜像
由于种种原因吧，我们在下载k8s组件镜像的时候，常常会遇到下载龟速的问题，很多小伙伴在自己的docker hub中定时同步谷歌镜像，当然国内也有公司为此做了镜像站点, Azure,阿里云等等。
在使用docker hub下载镜像时，需要加上docker的国内加速站点.
常规下载谷歌镜像站点
# docker pull gcr.azk8s.cn/google_containers/pause-amd64:3.1 3.1: Pulling from google_containers/pause-amd64 67ddbfb20a22: Pull complete Digest: sha256:59eec8837a4d942cc19a52b8c09ea75121acc38114a2c68b98983ce9356b8610 Status: Downloaded newer image for gcr.azk8s.cn/google_containers/pause-amd64:3.1 # docker tag gcr.azk8s.cn/google_containers/pause-amd64:3.1 gcr.io/google_containers/pause-amd64:3.1 # docker images REPOSITORY TAG IMAGE ID CREATED SIZE gcr.azk8s.cn/google_containers/pause-amd64 3.1 da86e6ba6ca1 19 months ago 742kB gcr.io/google_containers/pause-amd64 3.1 da86e6ba6ca1 19 months ago 742kB这种下载一个镜像还行，如果是多个的话，那就要累死了，为此我写了一个脚本，减轻我们的一些工作。
-
使用AlertManager为Zabbix做报警分组和沉默
因为Zabbix没有报警分组和沉默的功能，有时候大规模的产生报警，就会有很多的报警邮件或短信通知，导致了一些不必要的浪费，而Prometheus套件中的AlertManager符合我们的诉求，可以将报警分组聚合进行发送，并且可以在一段时间内沉默报警.这里就以zabbix报警脚本向AlertManager发送报警信息，再由AlertManager处理后通知用户。
- git 8
- vpn 3
- python 9
- Nginx 2
- Ansible 132
- 初创型公司运维专题 10
- 杂项 2
- kubernetes 20
- jekyll 3
- Linux性能优化 7
- LDAP 7
- AD 1
- monitor 1
- drone 2
- aws 4
- supervisor 3
- docker 6
- 运维 8
- rabbitmq 6
- openssl 1
- openssh 1
- linux 5
- jenkins 1
- container 1
- harbor 1
- cncf 1
- 学习周报 12
- 运维小需求 6
- PostgreSQL 2
- GreenPlum 2
- 运维规范 1
- rancher 1
- prometheus 1
- bpf ebpf 1
- 大模型 2