原本是继续阅读《每天5分钟玩转Kubernetes》一书的，发现该书所用的 Kubernetes 版本着实有点老旧( 1.7), 当前版本是 1.18。操作起来有些不同，所以找来了最新的 《Kubernetes in Action》第二版 来看，该书还在写作当中。第二章全是讲 Docker 的内容，本人读书有个不好的习惯，就是不喜欢跳过跳过。看了总会有收获的，这不，就从中稍微理清了 Docker 容器内进程与 Namespace 的关系。
Docker 容器间的进程本质上是宿主主上的一个进程，它能相互隔离靠的是 chroot, namespace 和 cgroup(对 CPU, 内存，磁盘，带宽等的配额)。千万不要认为启动一个 Docker 容器就是启动了一个虚拟机。
其中 namespace 实现了以下几项资源的隔离
经过前几天从 Docker Swarm 到 Docker Compose 的历练之后，终于踏上了 Kubernetes 的学习征程了。虽说前两者并非必要的学习 Kubernetes 的基础，但了解它们之后与 Kubernetes 中的一些概念可以进行对比理解。
本系列是阅读 《每天5分钟玩转Kubernetes》的笔记，书名倒是来的轻松，对我来说每天 5 分钟根本吸收不了什么知识。如果把阅读该书比作台上的话，基本就是台上 5 分钟，台下 50 分钟都不够，实际操作起来不光是版本有差异，还会出现各种意外带来惊喜与折磨。另外该书所采用的版本是 Kubernetes 1.7.4, 当前为 1.18，有不小的差别。
Kubernetes 是当今容器编排引擎的事实标准，以前为 Google 内部项目的 Omega 开源为 Kubernetes。传说中的容器编排三足鼎力，Kubernetes, Docker Swarm 和 Apache Mesos, 现在已是 Kubernetes 的一骑绝尘。Mac 下的 Docker Desktop 版本已内置了 Kubernetes 的支持。AWS 中在 ECS 外也支持了 EKS(Elastic Kubernetes Service)。 阅读全文 >>
继续向 Kubernetes 进发，上一篇 Docker Swarm 集群模式实操 了解完 Swarm 后，有必要对 Docker Compose 了解一番。Docker Swarm 是把 Docker 宿主机组成集群，部署服务时只要告知 Manager 节点，它就会自动找到相应节点去运行相应的容器。Compose 完全是另一个概念，它把相关联的多个容器组织成一个整体来部署，如由负载容器，多个 Web 容器和一个 Redis 缓存容器构成一个整体。
由其名 Compose 正式有了容器编排这么一个概念，后来将要学的 Kubernetes 是更高级别的组织，运行，管理容器的工具。Compose 由于把容器组织起来了，所以能够一条命令启动多个相关联的容器，而无需单独启动一个一个的容器。
关于 Docker Compose 的安装，在 Mac OS X 下的 Docker Desktop 自带了 docker-compose; 由于 Docker Compose 是用 Python 编写的，我们可以用 pip install docker-compose 的安装，安装后使用它的命令就是 docker-compose。
下方的 Docker Container, Swarm, Compose 三者之间的关系图很形像 阅读全文 >>
在正式进入 Kubernetes 之前希望能对早先的 Docker Swarm 有所了解，虽然它目前基本上没什么用处。Swarm 提供的是 Docker 宿主机的集群，集群中至少有一个 Manager(或多个), 再加上 0 或多个 Worker。它的大意是有个 Docker 服务(容器)通过 Manager 告诉用所管理的 Swarm 集群来执行，它就会在该集群中找到相应的宿主机来执行。Manager 和 Workder 都可用来运行 Docker 容器，但只有 Manager 才能执行部分管理命令。
下面两张图很好的体现了我们平时在一个宿主机上和 Swarm 集群宿主机上运行 Docker 容器的区别
 所有容器自己扛 |
=> | 容器大家一起扛 |
Docker 在 1.12 之后自带了 Swarm 模式。本文实质上对 使用Docker Swarm模式搭建Swarm集群 的一次实际操作与体验。只是自己方便使用了三个 Vagrant 虚拟机进行实践，其中一个 Swarm Manager 节点，两个 worker 节点 阅读全文 >>
常要在 Linux 下分析日志或其他类型的文件，基本用的命令也就 grep, awk, sed, cut, vim, cat, find, xargs, tail, more 或 less。本人工作平台为 Mac OS X, 而 Mac 下的 grep, sed, awk 的行为与 Linux 下的 GNU 标准的相应命令是有差别的, 所以我总是在 Mac 下安装 GNU 的 grep, sed, awk 等命令来替代系统默认的。
比如安装下面的命令
$ brew install findutils gawk gnu-sed grep
以上会安装 GNU 的 find, awk, sed 和 grep 命令，使用时要加个前缀，如 gfind, gawk, gsed 或 ggrep，也可以设置别名或符号链接来替换掉系统的相应命令。
注： brew install coreutils 会安装众多 Linux 下的基本命令替代品，ls, cat, cut 都在其中，使用它也是要加上前缀 g, 如 gls, gcut 等。
以下 grep, find, grep, sed 以 GNU 的行为为准。 阅读全文 >>
通常我们注册 Spring Bean 是通过像 @Named, @Bean, @Component, @Service 这样的注解来注册的，或者用更为古老的 XML 配置文件的方式。难免有时候要根据实际业务需求在 Spring 运行期间动态注册 Spring Bean, 比如基本某种形式的配置文件或系统属性来注册相应的 Bean, 这好像又回到了 XML 文件注册方式，也不尽然。
那为什么在运行期还要去注册 Spring Bean 呢，直接 new 对象不行吗？当然行得通，不过这样的话就不能更好的使用到 Spring IOC 的好处了。像待注册的 Bean 构造函数可以直接用到其他的 Spring 对象，或 @Value 引入环境变量，还有 @PostContruct 这样的行为。
最初思考如何注册 Spring Bean 时还是费了不少周折，如今清晰了许多。了当的说，不管是 Spring 初始时还是运行时，注册 Bean 的关键(应是唯一) 入口就是 BeanDefinitionRegistry 接口的方法 阅读全文 >>
看到本文标题也许要奇怪了，Python 的 print 难道不是也上可以看到结果的吗？在 Python shell 下只要
>> print('Hello world!')
Hello world!
不就立马能看到控制台输出的 "Hello world!" 吗。或者是一个 Python 脚本文件 hello.py
import time
for i in range(3):
print('Hello {}'.format(i))
time.sleep(3)
然后执行 python hello.py 的话，我们也同样能看到在控制台下在预定的每 3 秒输出一行
Hello 0
Hello 1
Hello 2
但执行下面的命令试图重定向输出到文件时的效果就不一样了 阅读全文 >>
学习理解一个软件非常好的方法就是跟随每一个版本演进的新特性，好比一个人被别人看着长大的，知子莫若父。因此每个版本的 Changelogs 或 What's New 是非常值得一读的，见 What's New In Python 3.8。因为接触 Python 比较晚，没能即时的重前往后的看过 Python 各版本的新特性，于是采用倒叙的方式来看 Python 的演进也不错。
在正式进入 Python 3.8 新特性前，先来看 Python 3.8 的安装和以及介绍一个非常棒的 Python 命令行解析器 bpython 作为 python 命令，ipython, idle 的替代品。
Python 3.8 各平台的安装包可在 https://www.python.org/downloads/release/python-380/ 找到。比如 Mac OS X 下可下载 https://www.python.org/ftp/python/3.8.0/python-3.8.0-macosx10.9.pkg，然后执行安装。安装完后，我机器上的 /usr/local/bin/python3 就指向到了 Python 3.8, 要用 Python 3.7 的话命令是 python3.7; pip3 却仍然是老版本的。
bpython 的安装要用相应版本的 pip install bpython, 如 /Library/Frameworks/Python.framework/Versions/3.8/bin/pip3 install bpython, 或者创建的虚拟环境中安装, python -m venv .venv; source .venv/bin/activate; pip install bpython。安装后启动 bpython 进入一个更智能的 Python 命令解析器。py
下面正式了解 Python 3.8 的主要新特性 阅读全文 >>
继续把 Kafka 捋一捋，还剩两个主要的组件了，分别为 Kafka Connect 和 Kafka Streams。而其中的 Kafka Connect 是在 Kafka 0.9.0.0 开始加入的我，Connect 的出现让 Kafka 与外部世界更紧密连接起来了，进而可以让其他外围组件通过 Connect 的 Source 与 Sink 紧密的团结在以 Kafka 为核心的消息中心。从此不再总是以标准的 Kafka Consumer 和 Producer 与外部联络。
Kafka Connect 主要由两部分组成，Source Connector 和 Sink Connector，这两个来自于 Akka Stream 这一 Reactive 框架的概念，即往 Kafka 流入数据的 Connector 是 Source, 从 Kafka 导出数据的是 Sink。 要自己实现 Kafka 的 Connector 需要用到 org.apache.kafka:connect-api 组件，不包含在 kafka-clients 依赖中，其中定义了两个主要抽像类
Kafka 默认情况下是没有启用安全机制，这让能连接到 Broker 的客户端可以为所欲为，自 Kafka 0.9.0.0 版本引入了安全配置，但是需要进行一些配置来开启它。Kafka 安全主要包含三个方面：认证(authentication)，授权(authorization), 和信道加密(encryption)。其中认证机制和授权分别通过 SASL(Simple Authentication and Security Layer)和 ACL(Access Control List) 来实现。本篇主要演示 SASL + ACL 的配置，未涉及 SSL 信道加道，所以没有配置 Kerberos, 客户端与 Broker 之间的数据传输仍然以明文(PLAINTEXT) 传输，这在内网使用 Kafka 基本没问题。
开启 SASL 和 ACL 需要在 Broker 和 Client 端进行相应的配置，要为两端创建包含用户认证信息的 JAAS(Java Authentication and Authorization Service) 文件。听其名就是为 Java 代码服务的，不知客户端要支持别的语言(如 Python) 时应该如何配置客户端。 阅读全文 >>