我的Python是从使用开始的，因此很多Python基础理论并不是很足，之前在使用Celery时，因为日志无法正常打印而排查了一天。所以，为了节省时间，同时知其所以然，是时候系统梳理一下Python中日志的使用方法了。

之前的文章介绍了如何编写一个Maven插件。那插件的使用上呢？在本地，我们可以安装到本地仓库，使用没问题；在SIT环境中，我们可以安装到公司内部的私有仓库中。但如果公司的Maven包尚未形成规模，不需要搭建私有仓库，且私有仓库需要有专人进行维护，如果只有少量包，可能过一段时间都忘了还有这么个东西。等到出问题了找半天，又是一个麻烦事。

上传到Maven中央库也许是一个非常好的选择，任何人在任何地方都可以使用该包，爽歪歪。

Maven是个很好用的打包编译工具，也是目前自己正在使用的主力工具。对一些个性化的需求，编写插件，实现一些特有的功能，还是非常有效的。这次刚好，有需求如是：maven编译时用到数据库表描述文件自动生成插件，需要从配置文件中读取账号密码，而目前maven只提供了读取properties文件到声明周期的工具。而项目的通用配置文件是json，如果临时加一个重复的properties文件，显得多余且没必要。于是需求应运而生，开发一个读取json文件到Maven生命周期的工具。

我叫它 json-loader-maven-plugin。

引子

这是一个晴朗的午后，我沐浴着窗口洒落的阳光，懒洋洋地敲着代码，喝着并不存在的咖啡，听着窗外并不存在的熙熙攘攘。这是一个疫情中的午后，深圳二月份的天气算是比较厚道，一件薄外套已经让我微微出汗。我，又遇到bug了，调了一上午的bug，自己写的bug，查了半天的bug，甚至让我分不清此刻的汗水是气温还是bug导致的。

随着时间的流逝，bug终究会解决，我们要做的，就是静静地等着。不知不觉已经到了晚上，果然，bug解决了。往往一个bug的持续时间决定了它是否值得被记录。解决完这个bug时，我惊喜地意识到又可以水一篇博文了。呵呵。

开篇废话

第一次接触到内网穿透这一概念大概是20017年左右，手中有一树莓派，想到如何能够在公司访问运行在家里的树莓派呢？百度之，基本就是下面这种情况——广告劝退，我一个小小的需求，要什么花里胡哨的东西，当时不了了之。后来了解到NATAPP，使用方便，价格也不贵，关键是配置简单，还支持自定义二级域名（当然是要钱的啦），这样使用了很长一段时间。但后来发现自己的使用场景是希望长期处于内网穿透，偶尔用一下，频率相当低。即使使用NATAPP这样低至9元/月的服务都嫌贵。

前两天使用K8S的ingress配置，遇到两个有包含关系的uri需要匹配到两个不同的容器中的情况，找了一下具体的匹配规则，主要来自这篇文章

根据墨菲定律，可能会发生的事就一定会发生。如果对Nginx的路径配置一直存疑，迟早会出问题。因此，搞懂很重要。

总体来说，Nginx将配置根据不同的server分成了不同的块，每当一个请求过来时，Nginx都会根据一定的算法确定哪一个配置块来处理该请求。其中起关键性作用的是server块和location块。前者定义了一个虚拟服务器，管理员通常会定义多个server块，然后根据请求的域名，端口或IP决定匹配到哪一个；后者存在于server块内，根据URI对虚拟服务器进行更加详细的区分。二者组合起来能够实现非常灵活的配置。

Pipenv是一个包管理和虚拟环境工具，致力于将所有的打包工具（bundler, composer, npm, cargo, yarn等）中的优点带到python世界。它将pip和virtualenv结合起来，为每个project创建一个虚拟环境，同时通过Pipfile指定需要安装的依赖，并自动解析依赖的依赖，生成的Pipfile.lock将各依赖版本锁定，以使各个环境保持一致。

DNS，全称Domain Namespace System，即域名系统。是互联网一项核心服务，将域名映射为IP地址（或其他类型记录），使得用户能够通过域名方便地访问特定的网站，而不必记住复杂而晦涩的IP地址。
如此重要功能，各大云服务商一般都有提供域名申请和域名解析服务。域名申请服务提供获得全网唯一域名的方式，如zouguodong.top、baidu.com等；域名解析服务则能够提供域名到指定服务的映射，最常见的就是映射到IP。

什么是有状态pod，即pod的运行状态与该pod耦合，当发生pod调度时新创建的pod必须和原有pod保持一致的状态，否则会出现状态丢失。前面我们所学习的pod都是由RC或RS创建的，然而他们无法满足pod对状态的需求。于是我们有了StatefulSet，它是专门定制的一类应用，这类应用的每个实例都是不可替代的个体，都拥有稳定的名字和状态。

前面介绍了各种Kubernetes资源以及使用方法，但在实际使用中，发布和升级总是避免不了的话题。使用一个容器级别的工具，每次发布时候敲一大段命令肯定是不行的，K8S提供声明式的发布升级方式，只需替换镜像即可触发，且提供滚动升级、回滚、暂停等操作。

对于特殊的pod，比如系统监控应用，知晓应用运行环境的各项参数是很常见的功能。Kubernetes对此也提供了很好的支持，用户可以通过环境变量、文件、API等多种方式获取到相关数据。

根据应用的开发进程，应用的配置一般会经历先嵌在应用本身，或通过命令行参数的形式传入。到测试生产阶段随着配置的增多会抽取为一个或多个配置文件。对于容器化应用，我们还可以为容器设置环境变量，应用中读取该变量即可。而对于K8S，还可以使用gitRepo卷作为配置文件的载体。但这些都还是太笨重了，K8S提供了更加简单的方法：ConfigMap，用于提供普通配置；Secret用于提供需要加密的配置。

第一篇文章已经说过了Service存在的意义，主要是由于POD机制无法对外提供一个稳定的地址，因此需要服务进行固定地址的暴露和负载均衡。官方一点的话：k8s的服务是一种为一组功能相同的pod提供单一不变的接入点的资源。

Kubernetes是一个容器编排系统，维护节点集群，负责创建、管理容器，本章介绍k8s的核心POD（容器的容器）和负责管理POD策略性工具（决定如何维护POD的数量和方式）。

Kubernetes是一个软件系统， 允许部署和管理容器化的应用。使用该系统，用户不需要关心如何维护实体集群关系，也不用徒手部署应用，不必烦恼应用的运行状态，只需要按照系统说明编写描述信息，k8s会按照描述信息自动维护整个集群。对用户，k8s将维护和部署集群化应用的复杂过程隐藏起来并进行了抽象，使得开发者能够更加专注于应用的开发上。同时减轻了运维人员的工作压力