上周随手点开了自己的网站, 才发现SSL证书已经过期一周多了, 继而才想起这个网站已经上线一年了.

新手整出1GB的镜像, 说能跑就行. 老手看不下去给Dockerfile改了几行, 最后出来的镜像只有27MB, 一样能跑.

介绍HLS(HTTP Live Streaming), 以及自制m3u8播放链接的步骤

前言

自从开始了这个ELK专题之后, 笔者就一直都在Elastic Stack的框架下介绍里面的各种应用. 目前有覆盖到的有Elasticsearch, Logstash, Kibana, Beats(filebeat, metricbeat), 但是在真实的生产环境下, 做技术选型的时候往往还会依据现实的需要加入其它类型的中间件. 比如说, 为了进一步加强日志系统集群的健壮性, 我们还可以考虑增加一个消息队列的中间件.
在本文中, 我们就尝试着为ELK集群增加一个Kafka.

需要说明的是, 在前面的章节中介绍到的方案, 会把原始日志里面的json内容当做是纯文本去处理, 去到Logstash的时候再识别成json格式, 过程显得繁琐.

在最后的拾遗部分, 会再提供一个简便一点的方案.

前言

在运维的技术栈里面，说到监控系统，大多数人可能首先想到的对后台服务器的CPU、内存、网络流量、磁盘IO等性能指标监控起来。要是再深入一点，可能会再做一个日志监控，把各个事务的日志统计起来，可以跟踪各个事务的时间和数量的分布等等。

那假如，我们想更深入一层，想要知道各个API在处理事务的过程中在每个步骤上都花了多少时间呢？比方说，有一个接口GET /user_info/<user_id>，服务器在处理这个接口的时候需要从数据库上使用user_id查询用户的昵称，同时请求其他API得到玩家的排行榜信息。我们自然可以使用日志打点的方式把这些步骤都记录下来，再通过ELK的日志监控去完成，但这样无疑会增加大量的开发成本，而且很有可能需要反复打磨才能获得一个满足各个场景的通用标准。

而今天要说的Elastic APM(application performance monitoring)就是专门针对这种场景的通用解决方案。

发现内存告警，初级运维搞扩容，中级运维调参数，高级运维骂开发（误）。

前言

对刚刚接触Kubernetes的新手来说，在开始使用之前，有必要先理解一些关于Kubernetes的基本概念。

很多地方都会把Kubernetes和容器技术放在一起去讨论，但需要明确的是，Kubernetes是一个容器编排和管理的工具，为用户提供自动部署和容器监控等解决方案。目前在大多数主流的容器管理平台都支持Kubernetes，国外的有：OpenShift、Docker EE、AWS EKS、Rancher，而国内的则以腾讯云的TKE和阿里云的ACS为主流。

在下面的内容，我们主要来讨论一下在Kubernetes集群中的网络原理。

前言

笔者最初接触容器技术的时候，心中是充满疑问的。

“容器是一个进程吗？”

“和虚拟机有什么区别？”

“使用容器后，服务器内部到底发生了什么？”

……

后来，经过了较长的一段时间的学习，从实践到理论知识，才慢慢地摸索和总结出容器的工作原理。

跟往常的行文方式不同，这次会使用很多短句和换行，力求简明扼要地把概念说完。

毕竟，如果想要详细的话，我为什么不去看官方文档呢？ :-)

另外需要强调一点，本文讨论的是关于容器技术的通用解决方案，旨在简单介绍容器的设计思路和实现方式，可能会和现有的一些具体的容器方案有出入。

虚拟机和容器这两种虚拟化技术都是为了更有效地发挥软硬件性能而诞生的，其中容器技术在最近几年开始流行并迅速改变了互联网的生态，而虚拟机技术则是在更早之前就已经是行业内的主流方案并广泛存在于各大数据中心。

而当我们要规划一个项目的架构时，往往都需要深入研究他们各自的工作原理和区别，从而制定出一个最适合的方案。

前言

Kubernetes(K8s)脱胎于Google的Borg系统，在2015年发布以来，已经是当下最流行的容器编排工具(没有之一)。在本文中，笔者会使用上一篇文章中的demo，模拟把代码部署到K8s的过程，同时也会在这个过程中讨论一下部署方案的设计思路。

本文内容主要都是应用发布相关，为了简化步骤，使用minikube进行演示。