文章

TF执行计划可视化

之前我们通过一篇文章入门了使用Terrafrom以声明式配置文件（可版本化的代码）来创建和管理基础设施资源。在使用命令terraform apply之前，我们通常使用terraform plan来查看执行计划，输出的执行计划以类似“git diff”的文本方式描述。这里我们将介绍如何以图形可是化的方式来了解执行计划。 Terrafrom Graph 首先Terraform CLI工具自带了一个子命令 - graph，graph命令用于生产配置和执行计划的图形表示，其输出是DOT格式，可以通过Graphviz转化为图片，例如在Linux终端下 ❯ terraform graph | dot -Tsvg > graph.svg 对于简单的项目（管理的资源对象比较的情况），我们可以通过这个图形了解资源对象的关系。但是如果一个项目管理了大量的资源对象，使用graph生成的图形会显得错中复杂，而且图形文件也比较庞大。那接下我们将介绍一款开源的可视化工具。 Rover Rover是一款开源的，可交互的Terraform配置和执行计划可视化工具，其通过Web服务的方式，是我们可以通过浏览器查看生成的图形，并进行一些交互操作。使用Rover非常容易，可以从其Github项目的Release下载为各平台编译好的二进制文件（命令）来运行，也可以通过Docker容器的方式运行。如果使用下载的二进制文件，将下载好的二进制文件（例如 rover_v0.2.2）放到PATH路径下，例如 /usr/local/bin/rover，接下來在Terraform项目的文件夹下执行 ❯ rover 2021/11/26 16:59:34 Starting Rover... 2021/11/26 16:59:34 Initializing Terraform... 2021/11/26 16:59:35 Generating plan... 2021/11/26 16:59:37 Parsing configuration... 2021/11/26 16:59:37 Generating resource overview... 2021/11/26 16:59:37 Generating resource map... 2021/11/26 16:59:37 Generating resource graph... 2021/11/26 16:59:37 Done generating assets. 2021/11/26 16:59:37 Rover is running on 0.

November 26, 2021 Read

解读OPEN GITOPS 1.0

GitOps的概念以及提出了几年时间了，伴随着DevOps的发展也来越流行。简单地说，GitOps是一套操作和管理软件系统的原则，其源自于现代软件运维，也根植于之前存在和广泛采用的最佳实践。虽然其名字中包含Git，但其所表示的是与版本控制系统相关，而不仅限于Git工具。也可以说其是一个运维框架，它将 DevOps 最佳实践用于应用程序开发，例如版本控制、协作、合规性和 CI/CD 工具，并将它们应用于基础设施自动化。去年，来自Amazon和Azure，Codefresh，Github，Redhat，Weaveworks等具有云原生经验公司的工程师们在云原生计算基金会（CNCF）下组建了一个GitOps工作组，并创建了OpenGitOps项目。 GitOps工作组在上个月（10/09）发布了OpenGitOps原则和术语1.0版本。 OpenGitOps 1.0 GitOps工作组的联合主席 - Leonardo Murillo说过，“很多人认为他们在做GitOps，因为他们正在使用git，并且使用拉取请求（Pull Request）和推送更改（Push Changes）。而我们希望社区开始看到GitOps不仅仅是使用git的CI/CD流水线，其还包含很多”。工作组首先定义了GitOps的核心原则和相关术语，而我们可以用自己的方式自由地解释这些原则，并通过相关的DevOps工具实现最佳实践。发布的1.0版本由两个简单的原则和术语文档组成，每一个原则都讨论了系统的需求状态（Desired State）以及它应该如何运行。 GitOps所管理的系统的需求状态必须满足声明式的（Declarative） - GitOps管理的系统必须以声明的方式表达其所需要的状态。版本化和不可变（Versioned & Immutable） - 系统所需要的状态将以不可变、版本化的方式存储，以及保留完整的版本历史信息。自动拉取（Pulled Automatically） - 软件代理会自动从源中提取所需的状态声明。持续调节（Continuously Reconciled） - 软件代理持续观察系统状态并尝试达到系统所需要的状态。进一步解读声明式的状态应该很好理解，声明式的描述不应该包含如何达到需求状态的操作，而仅仅描述系统或者应用所需要的状态。例如可使用Terraform来描述和管理一个基础设施，也可以使用Kubernetes的应用部署文件（mainfest）来管理部署的应用。版本化和不可变通常理解为是用“git”，其实不仅限于此，这里更加强调的是使用具体的版本标签来定义系统的一个版本状态，而不应该使用例如“latest”之类的标签，因为其不能回退到之前所需要的状态。而其他版本管理系统，只要满足这样的版本标签功能，以及符合团队的协作方式，都可用于GitOps。自动拉取意味着我们必须有一个系统内的代理持续观测系统的状态，其需要时时刻刻知道系统所需要的状态和当前状态，而不是在触发确切的更改时才去获取系统得到状态。这里的拉取（Pull）明确地表明了其于CI/CD流水线由条件来触发的不同。而持续调节将以上三个部分整合，系统内的代理必须时刻了解管理的系统的实际状态和所需的状态，当发现实际状态和所需的状态由偏差时，或者发现所需状态被改变时（版本改变），其应该尽力时系统状态达到所需求的状态。而这一切都是由系统自动完成的。当团队遵循以上原则来管理和维护系统和应用时，才是对GitOps的真正实践。 OpenGitOps发展 OpenGitOps 1.0仅仅定义了部分实现GitOps的原则，接下来还需要扩展更多的定义，例如如何在GitOps环境中处理事件管理，安全管理，凭证管理等。如果我们的基础设施环境以及我们的应该出现故障，那么在GitOps中应该遵循怎么样的处理原则？期待CNCF GitOps工作组的进一步工作。

November 25, 2021 Read

迁移本地项目到TF CLOUD

之前文章我们尝试了在本地环境使用Terraform来创建和管理AWS Lightsail资源，对于管理一些云资源，我们需要在本地安装相应的CLI工具和配置访问相应云资源的凭据（例如AWS CLI， AccessKeyID等），Terraform通过调用本地的CLI工具或者云API来管理云资源的状态，其默认使用的是local类型的Backend，资源的状态文件(.tfstate)也是保存在本地文件目录中的。这篇文章我们将尝试使用remote类型的Backend，将项目迁移到Terraform Cloud去执行，并且由Terraform Cloud来管理资源状态。什么是Terraform Cloud Terraform Cloud 是一个管理Terraform在一致且可靠的环境中运行的SaaS应用，从而可以替换在本地机器是执行Terraform项目，其存储共享的状态和机密数据，并可以连接到版本控制系统（如 Git)，使得我们可以在团队中将基础设施作为代码进行工作。 Terraform是一个商业应用，团队和商业使用将会收取费用并提供了更多的高级功能。但对于个人用户，可以免费使用基本的功能。关于费用和功能详情，可以参考 (https://www.hashicorp.com/products/terraform/pricing)。首先我们需要注册一个Terraform Cloud的账号，访问 https://app.terraform.io/public/signup/account ，根据提示注册账号注册完成后第一次登陆Terraform Cloud，其会询问如何开始一个项目，这里我们选择 Start from scratch，也就是将从一个空模板开始接下来我们需要创建一个组织（Organization），例如这里我创建一个名为 learn-terraform 的组织，一个组织就类似要给命名空间，可以管理多个工作空间（Workspace），还可以管理其下工作空间共享的变量和环境变量。接下来我们需要在本地环境登录Terraform Cloud，并添加相应的配置来重新初始化项目。重新初始项目完成了Terraform Cloud的账号注册之后，我们需要在本地终端运行 terraform login ，会打开浏览器来登录账号得到一个Token值，将其复制填入终端完成登录 > terrafrom login Terraform must now open a web browser to the tokens page for app.terraform.io. If a browser does not open this automatically, open the following URL to proceed: https://app.terraform.io/app/settings/tokens?source=terraform-login --------------------------------------------------------------------------------- Generate a token using your browser, and copy-paste it into this prompt.

November 25, 2021 Read

TF管理AWS LIGHTSAIL实例

Terraform是一种开源基础设施及代码（IaC）的工具，可提供一致的CLI（命令行接口)工作流来管理数百个云服务，将云API编码为声明性的配置文件进行管理。本文创建一个管理AWS Lightsail实例的例子来入门Terraform的使用。安装Terraform CLI 要使用Terramform，首先要在本地系统安装Terraform命令行工具。HashiCorp提供了预编译好的二进制分发包，可以通过(https://www.terraform.com/downolads.html) 直接下载相应平台的二进制包，解压后放到相应的执行路径。也可以通过一些软件包管理工具安装，例如在Linux/OS X上通过LinuxBrew/HomeBrew进行安装，在Windows上通过Chocolatey进行安装。这里我们示例在Linux上是使用LinuxBrew进行安装 > brew install terraform 安装完成后，可以查看其版本 ❯ terraform -version Terraform v1.0.11 on linux_amd64 使用-help查看其可用命令，安装成功后，我们就可以使用Terraform来创建相应的基础设施项目了。 AWS账号准备本文将通过创建一个管理AWS Lightsial实例的项目来尝试Terraform，因此需要一个AWS账号，以及在本地环境安装和配置好AWS CLI工具的访问凭据。安装和配置AWS CLI，请参考其文档 (https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html) 。配置完成之后，可以在本地命令行终端访问相应的AWS资源。创建并初始化Terraform项目 Terraform在本地通过文件夹来管理一个基础设施项目的声明性代码，例如我们在本地创建一个文件夹 > mkdir mylightsail > cd mylightsail/ 进入文件夹后，创建一个以 .tf 作为后缀的文件，例如 main.tf > touch main.tf 然后使用编辑器打开文件进行编辑，写入以下代码块 terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 3.65" } } } # Configure the AWS Provider provider "aws" { region = "ap-southeast-1" } 其中 terraform/required_providers 块定义了该项目需要的 Provider，Terraform是通过不同的Provider来管理相应的基础设施资源的，可到 (https://registry.

November 23, 2021 Read

Windows10上安装WSL2

现在Windows （10）是越來越向Linux靠近了，对于开发者开说，特别是在Windows上的Linux子系统非常好用。 WSL2（Windows Subsystem for Linux ）是Windows 10上的一个工具，允许开发人员在Windows上直接运行Linux环境，使得在Windows系统上进行Linux的原生体验。对于WSL2，其底层通过微软的内置虚拟化技术（Hyper-V）实现Linux的环境。本文将一步步知道如何在Windows 10上启用WSL2，并安装一个Ubuntu 20.04分发版本的Linux。前提条件想要在Windows 10上启用WLS2，需要满足以下条件： Windows 10 版本 1903 Build 19362，或高于该版本如果是ARM64的系统，则需要版本2004 Build 19041，或高于该版本步骤一　- 为WSL启用Windows服务想要在Windows 10上运行WSL，首先需要启用Windows上的一些服务，这些服务默认是关闭的。开始菜单，搜索 PowerShell，右键 PowerShell，选择使用管理员运行。在打开的 PowerShell 终端，执行如下命令： PS C:\Windows\system32> dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart [dism.exe]是Windows的部署映像服务和管理工具，上面的命令开启了WSL的功能。以上命令执行成功之后，继续执行如下命令来开启Hyper-V的功能 PS C:\Windows\system32> dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart 补充：上面的两个操作也可以通过以下命令实现 PS C:\Windows\system32> Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform, Microsoft-Windows-Subsystem-Linux 完成以上操作之后，需要重启Windows操作系统，重启之后再次登陆系统。接下来需要从微软下载一个最新的Linux内核升级包并安装，下载安装包 wsl_update_x64.msi，下载完成后直接安装。完成之后，以管理员身份运行 PowerShell，执行如下命令来设置wsl使用的默认版本 PS C:\Windows\system32> wsl --set-default-version 2 这里我们将默认设置为 wsl 2 。

June 8, 2021 Read

加载virtio驱动的Windows10安装镜像

如今虚拟化已经非常流行，当我们使用Linux桌面环境时，可以通过安装libvirt和QEMU直接使用基于内核的虚拟化（KVM）来创建虚拟机并安装其他类型的操作系统。在基于Linux的服务器上，也可以通过oVirt或者PVE等基于KVM的虚拟化方案来实现虚拟机环境。当我们想通过官方iso系统镜像安装比较新的Windows（例如Windows 10，Windows Server 2019等），在进入到选择安装磁盘，会发现找不到创建的虚拟磁盘，如下图所示这是因为在官方的iso镜像中的Widnows未包含针对KVM的virtio-win驱动，因此我们可以基于Windows的iso镜像，加载virtio-win的相应驱动之后，重新创建一个包含了virtio-win驱动的iso镜像文件。关于virtio-win的更多信息，可以参考 https://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers 。前提条件为了创建一个加载virtio-win驱动之后的iso镜像文件，我们需要以下准备：具有管理员权限的Windows 10工作系统并安装Windows ADK Windows 10的安装iso文件（这里以Windows 10作为例子） virtio-win驱动的iso文件 (https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.196-1/virtio-win-0.1.196.iso) UltraISO工具准备工作创建工作目录假设在你的Windows 10系统上有D盘，那我们在D盘创建相应的工作目录，以管理员权限打开PowerShell，并执行 PS D:\> mkdir D:\mnt\windows_temp,D:\mnt\boot,D:\mnt\install,D:\virtio-win 提取Windows安装文件使用UltraISO工具打开windows 10的iso文件，并将所有文件提取到目录 *D:\mnt\windows_temp* 下然后给Windows的镜像文件授权读写 PS D:\> attrib -r C:\mnt\windows_temp\sources\*.wim /s 提取virtio驱动文件使用UltraISO打开下载的virtio-win的iso文件，同样提取到目录 *D:\virtio-win* 下，然后查看有哪些w10（针对windowns10）的驱动我们可以看到在 0.1.196 版本中，包含了以下w10（64位）的驱动，为了方便后面一条命令加载所有驱动，我们把这些驱动重新放到一个目录下 PS D:\> cd virtio-win\ PS D:\virtio-win\> mkdir w10 PS D:\virtio-win\> cp -r .\Balloon\w10\amd64\ .\w10\Balloon PS D:\virtio-win\> cp -r .\NetKVM\w10\amd64\ .\w10\NetKVM PS D:\virtio-win\> cp -r .

June 8, 2021 Read

本地环境运行MQTT容器

在我们的本地开发环境（Windows, Mac or Linux），我们可以很容易地使用Docker容器的方式，跑一个MQTT的Broker起来，方便我们的应用开发调试MQTT相关的功能。这里我们以Emqx作为MQTT的Broker来做示例。环境准备首先需要在我们本地的Workstation上安装Docker环境: Windows - 如果是Windows 10，推荐使用Docker Desktop或者WSL2，如果是10一下版本，可以使用Docker Toolbox，或者在Windows上跑一个Linux虚拟机，直接在虚拟机里安装Docker Mac - 使用Docker Desktop Linux - 直接安装Docker引擎如果选择使用Docker Desktop，可以参考 Windows上的Docker Desktop 。 Docker运行emqx容器 Emqx的开发者已经构建了可用的容器映像，放在Docker Hub上，所以我们这里不需要自己构建映像，而是直接从Docker Hub上拉取 $ docker image pull emqx/emqx:v4.0.5 如果是在Windows上使用Docker Desktop，则上面的命令是在PowerShell里执行。使用如下的命令直接启动一个emqx的容器 $ docker image container run --name dev_emqx -d -p 18083:18083 -p 1883:1883 emqx/emqx:v4.0.5 启动成功后，我们可以使用命令查看运行情况 $ docker container ls docker container ls CONTAINER ID NAMES IMAGE CREATED ago STATUS PORTS COMMAND 7c93940c07a3 dev_emqx emqx/emqx:v4.0.5 39 minutes ago ago Up 39 minutes 4369/tcp, 5369/tcp, 6369/tcp, 8080/tcp, 8083-8084/tcp, 8883/tcp, 0.

March 10, 2021 Read

一体化CI/CD平台

前言匆匆忙忙结束了2020年，想着还是要在2021年的第一个月要写一篇文章。在看了[Gitlab]推送的文章之后，自己也比较认同在DevOps实践中如果使用一个一体化的CI/CD平台或者工具所能带来的好处。不过每个组织或者团队有自身的一些考量和实际情况，就比如的当前我在工作中也使用了多个工具来实现整个CI/CD流程，似乎是分离了CI和CD的过程，因为公司更加考量了做交付的稳定性和安全性考量，并没有做到完全的持续发布。所以这篇文章仅仅是探讨一些一体化CI/CD平台可以带来的优势。 CI/CD 持续继承和交付（CI/CD）改变了我们构建，测试和部署软件应用的方式。CI/CD工具自动化这些流程，减少错误率，并且优化了整个工作流。代码在整个开发阶段中进行自动化测试，已确保在错误到达生产之前就将其捕获并修复。 CI/CD工具的使用将持续增加并改善软件开发的方式，应的部署也不再需要是每年一次，每个季度一次，甚至每个月一次。通过CI/CD，开发运维团队可以一天内部署多次。 10个CI/CD的优点上面说了什么是CI/CD，那接下来我们看看其有哪些优点。 1. 更少的交接在开发管道中更多的交接，那将带来更多的故障点和更多的复杂性。 2. 增加开发速度通过CI/CD，开发的所有阶段都更快，整个过程中更快的迭代速度使每个团队的工作效率更高，开发人员也可以更有信心地转移到其他项目。 3. 更多的部署每两周或更长时间发生一次的发布，现在可以每天推送多次。 4. 更快的测试开发工作流程中一个比较耗时的部分被移除，开发人员可以从事其他高价值的项目。自动化测试让团队可以更快速地获得反馈，并尽早失败，而不是在生产中产生这些错误，或者更糟糕地将错误带到最终的发布版本中。 5. 更少的代码缺陷通过开发流程中引入自动化测试，在代码缺陷发生时就能及时捕获，并避免代码合并入主分支。这样可以确保整体上的具有更高的代码质量，并且每个发布版本都能按预期工作。 6. 增强合规性合规性任务可以纳入开发生命周期，减少发布不合规应用的风险。自动化合规检查使得更容易完成审核，并可以防止高代价的错误。 7. 更多的创新时间花费在集成维护的时间越少，IT支出不变，也就意味着可以更多的时间投入到其他地方。 8. 更开心的开发者开发人员能够更有自信地工作和快速地修复缺陷，而不是等上几个星期来了解错误发生在哪里。 9. 减少管理费用组织中开发人员的时间是有限的，开发时间是可计费时间的很多倍，而手动测试和部署代码可能会破坏整个IT预算。自动化的工作流程减少了手动任务，可以使预算更加有效。 . 流程一致性开发流程中具有更高的自动化程度意味着没人会忘记该过程中执行的步骤，也使得构建更加一致。这样更容易培训新的开发人员，组织也可以更加容易控制如何构建，以及何时进行发布。一体式CI/CD优势上面概述了CI/CD可以带来的好处，然而在实际的实践中，如何真正地衡量生产力速度，需要评估整个软件开发生命周期（SDLC），而不仅仅是点点滴滴。无缝地持续集成和交付应具有使应用程序为部署做好准备所需的一切，不幸的是，很多使用CI/CD的组织由于使用的工具而陷入了无法达到最佳工作流程的困境。一个可以在整个软件开发生命周期提供可见性的应用程序是确保和优化每个开发阶段的最佳方法，当一切都在一个屋檐下时，就容易发现流程的瓶颈，以及评估影响开发速度的每一个元素。在单个DevOps平台下的每个步骤都提供了一条信息，可就是否准备好合并代码做出明智的决定。当然，所有这些步骤可以在没有一体式CI/CD的解决方案的情况下执行，但是功能全面的工具可以创建单一的事实来源，在此情况下，可以更快地监视每个步骤，并减少遗漏错误的可能性。一体式CI/CD平台带来以下好处：整个软件开发生命周期的可见性所有开发阶段的单一真实来源无需登陆多个应用程序在一个界面上导航更简单只需要安装，维护，扩展，备份一个应用程序更容易的授权管理降低运营费用因此，推荐在组织或团队中构建单一的CI/CD平台来加速应用创新，例如选择使用 Gitlab，Github，以及各大公有云提供商发行的DevOps平台及工具来优化整个CI/CD流水线。

January 25, 2021 Read

K8S健康检查最佳实践

我们都知道分布式系统非常难以管理，很大的一个原因是要是整个系统的可用性，是需要所有的部件（服务）都正常工作。如果一个小的部件不可用，系统应该可以检测到，绕过该部件，然后修复它，而且这样的行为应该可以自动进行。健康检查就是一个简单方法，使系统可以知道应用（服务）的一个实例是否正常工作。如果一个实例能正常工作，那其他服务不应该访问它或者向它发送请求，请求应该发送到健康的实例。而系统应该恢复应用的监控状态。当我们使用 Kubernetes 来运行和管理我们的应用（服务），默认情况下当一个Pod里的所有容器都启动后，就向该Pod发送相应的流量，并且当容器崩溃的时候重启容器。在一般情况下，这个行为也是可以接受的，不过k8s还提供了对容器的健康检查机制，可以让我们的部署更加健壮。在演示如何具体配置K8S的健康检查之前，让我们来看看什么健康探测模式（Health Probe Pattern）? 健康探测模式当我们设计一个关键任务，高可用的应用时，弹性是我们需要考虑的最重要方面之一。当一个应用能快速从失败中恢复，那个这个应用就是具有弹性的。为了保证基于k8s部署的应用是高可用的，在设计集群时，我们需要遵从特定的设计模式。而健康探测就是其中的一种模式，它定义了应用如何向系统（k8s）报告它自己的健康状态。这里所谓的健康状态不仅仅是Pod是否启动及运行，还应包括其是否可以正常处理请求并响应，这样k8s就可以更加合理地进行流量路由以及负载均衡。 Kubernetes的健康探测我们都知道，k8s通过各种控制器对象（Deployment, StatefulSets等）来监控Pod的状态，如果一个控制器检测到Pod由于某些原因崩溃，它就会尝试重新启动Pod，或者把Pod调度到其他节点上进行启动。然而，Pod是可以报告自己的状态的，例如一个使用Nginx作为web服务器的应用，通过Deployment部署到集群里并正常启动，这个时候检测到Pod的的状态是运行着的，但是可能由于某些原因导致访问web服务时确返回500（内部服务错误），对请求者来说该服务是不可用的状态。默认情况下，k8s的kubelet继续地探测容器的进程，当探测到进程退出，它会重启容器的Pod，有些情况下重启可以让容器恢复正常。但像上面的例子，容器的进行正常运行，而应用却返回500错误，并不能正确地探测到应用的健康状态。因此，k8s提供了两个类型的探测：存活探测（Liveness Probe），就绪探测（Readiness Probe）。存活探测（Liveness Probe）很多应用在长时间运行，或者遇到某种错误进入死锁状态，除非重启，否则无法恢复。因此k8s提供存活探测（Liveness Probe）来发现并恢复这种状态，当然存活探测检查到错误时，kubelet将对Pod采取重启操作来恢复应用就绪探测（Readiness Probe）有时应用会暂时性的不能对外提供网络服务，例如在负载比较大的是偶，或者在应用启动的时候可能需要加载大量数据或做一些初始化的动作，需要一定时间来准备对外提供服务。这样的情况下，系统探测到应用实例不可用时，不应该杀死应用重启，而是应该分配流量，不往该实例发送请求（通过配置服务负载）。因此，k8s提供了就绪探测来发现并处理这种情况，发现Pod里的容器为就绪时，会设置应用的service(k8s资源对行)移除该实例的Endpoint（服务端点），使得流量然过该不可用的服务实例，等待探测起就绪后，再将其端点添加回相应的服务。当然如果应用是第一次启动，则会等待就绪探测成功后才会将其添加到服务端点。 Kubernetes探测方法那系统如何来探测容器的健康状态呢？k8s支持配置三种探测方法：执行命令，TCP，HTTP 。三种方法都可以应用到存活和就绪探测。执行命令通过在容器内执行命令来判断容器的状态，如果命令返回值为 0，则认为容器是健康的；如果返回值为非 0，则认为容器是不健康的。这种方式一般在容器运行的应用没有提供HTTP的服务，也没有任何TCP端口启动来提供服务的情况，而可以通过运行一个命令来确定应用是否健康。下面是配置一个Pod使用命令 apiVersion: v1 kind: Pod metadata: name: app spec: containers: - image: example/app:v1 name: app livenessProbe: exec: command: - cat - /tmp/healthy initialDelaySeconds: 5 上面的示例就使用命令 cat /tmp/healthy 来进行存货探测，如果容器里不存在 /tmp/healthy 文件，则命令返回非0值，k8s则认为容器不健康，这里使用了存活探测，因此会重启该Pod。 TCP 那TCP方式，就是通过尝试向容器监听的端口建立TCP连接来确定其是否健康，如果能成功建立连接，则认为健康，否则不健康。

December 8, 2020 Read

在LINUX上配置WIREGUARD

什么是 WireGuard ？其官方宣称是快速、现代以及安全的VPN隧道（Fast, Modern, Secure VPN Tunnel）。 WireGuard使用了最先进的加密技术，相比 IPSec 更简单更精简，而且拥有几乎超越 OpenVPN 的性能。其最初是针对Linux内核发布的，但是现在已经跨平台（Windows, MacOS, BSD, Android, iOS等）可部署。接下来这篇How To系列文章，就来一步步在Ubuntu (Linux)上安装和配置WireGuard VPN，其中一台云主机运行Ubuntu-20.04用作VPN服务器，另一台本地的linux桌面环境作为VPN客户端。服务器端安装WireGuard 这里我们的服务器使用的是操作系统为Ubuntu 20.04的云主机，对于如何创建并配置一台云主机，可以选择 [DigitalOcean]（https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-20-04）。这里我们我们已经配置好一台Ubuntu 20.04的云主机，并且可以通过SSH访问。首先对系统进行安全更新 $ sudo apt update $ sudo apt upgrade 接下来直接使用APT安装WireGuard软件包 $ sudo apt install wireguard 会同时安装 wireguard-tools 软件包，我们需要使用其工具进行相关的配置。配置WireGuard服务端进入root权限进行操作，为服务端生产私有/公共密钥对 $ sudo -i \# cd /etc/wireguard/ \# umask 077 \# wg genkey | tee privatekey | wg pubkey > publickey 执行完上述命令后，我们会在目录 /etc/wireguard/ 下生产两个密钥文件 privatekey 和 publickey 。

December 3, 2020 Read

LINUX上统计网络接口数据包

在Linux系统上，我们可以通过 ip , netstat 或者 [ethtool] 命令显示网络接口丢弃数据包的统计信息。接下来我们看看如何使用每个命令。使用netstat按接口显示数据包其实 netstat 命令已经过时，可使用命令 ip 和 ss 来代替。但是 netstat 依然在一些旧的Linux分发版本上可用，因此在 ip/ss 不可用的情况，我们可以使用netstat，其语法如下 netstat -i netstat --interfaces 例如 ~$ netstat -i Kernel Interface table Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg docker0 1500 0 188180 0 0 0 151852 0 0 0 BMRU eth0 1500 0 472368 0 0 0 375351 0 0 0 BMRU lo 65536 0 51687 0 0 0 51687 0 0 0 LRU vethc8f46ea 1500 0 136984 0 0 0 79587 0 0 0 BMRU 如果想显示每种协议的概要统计信息，可以执行

December 2, 2020 Read

DOCKERFILE构建最佳实践

在进行应用容器化的实践中，我们可以使用多种方式来创建容器镜像，而使用Dockerfile是我们最常用的方式。而且在实现CI/CD Pipeline的过程中，使用Dockerfile来构建应用容器也是必须的。本文不具体介绍Dockerfile的指令和写法，仅仅是在实践中积累的一些写好一个Dockerfile的小提示，体现在一下几个方面：减少构建时间减小镜像大小镜像可维护性重复构建一致性安全性减小构建时间首先来看看下面这个Dockerfile FROM ubuntu:18.04 COPY . /app RUN apt-get update RUN apt-get -y install ssh vim openjdk-8-jdk CMD [“java”,”-jar”,”/app/target/app.jar”] 要减小构建的时间，那我们可以例如Docker构建的缓存特性，尽量保留不经常改变的层，而在Dockerfile的指令中， COPY和RUN都会产生新的层，而且缓存的有效是与命令的顺序有关系的。在上面的Dockerfile中，COPY . /app在RUN apt-get ...之前，而COPY是经常改变的部分，所以每次构建都会到导致RUN apt-get ...缓存失效。 Tip-1 : 合理利用缓存，而执行命令的顺序是会影响缓存的可用性的。要减小构建时间，另一方面是应该仅仅COPY需要的东西，对于上面这个Dockerfile的目的，应该仅仅需要COPY Java应用的jar文件。 Tip-2 : 构建过程中仅仅COPY需要的东西。上面的Dockerfile对apt-get命令分别使用了两个RUN指令，会生成两个不同的层。 Tip-3 : 尽量合并最终镜像的层数。还有对于这个示例，我们最终是想要一个JRE环境来运行Java应用，因此可以选择一个jre的镜像来作为基础镜像，这样不用花时间再去安装jdk。 Tip-4 : 选择合适的基础镜像这样我们可以把Dockerfile写成： FROM ubuntu:18.04 RUN apt-get update \ && apt-get y install ssh vim openjdk-8-jdk COPY target/app.jar /app CMD [“java”,”-jar”,”/app/app.

July 15, 2020 Read