配置Grafana启动LDAP认证
使用Grafana作为团队监控系统的图表组件，为了安全还需配置使用团队基于OpenLDAP的统一用户认证。 Grafana从2.1开始支持LDAP集成，但是在参考官方文档Grafana LDAP Authentication进行配置时遇到了一些问题，这里做一个简单的记录，便于后边查看。
使用kubeadm安装Kubernetes 1.7
kubeadm是Kubernetes官方提供的快速安装和初始化Kubernetes集群的工具，目前的还处于孵化开发状态，伴随Kubernetes每个版本的发布都会同步更新。 当然，目前的kubeadm是不能用于生产环境的。 但伴随着Kubernetes每次版本升级，kubeadm都会对集群配置方面的一些实践做调整，通过实验kubeadm我们可以学习到Kubernetes官方在集群配置上一些新的最佳实践。 例如从Kubernetes 1.6开始kubeadm的目标就是可以快速初始化一个更加安全的Kubernetes集群，Kubernetes 1.6进入beat的RBAC，在这版的kubeadm就有了集成。 目前，我们一套Kubernetes 1.6环境的部署，就是先根据kubeadm中的配置实践整理，再编写成ansible role部署的：
配置Harbor启用LDAP认证
现在我们的Harbor使用前置的nginx接入，并在前置nginx上启用了SSL，Harbor的MySQL使用的是我们环境中高可用的MySQL GR集群。 为了我们的团队环境整合到一起，我们还需要为Harbor启用LDAP认证。 Harbor对LDAP支持的很好，只需要修改harbor.cfg:
配置Harbor启用https和外部数据库
我们已经快速安装和启动了Harbor，接下来我们进一步探索一些定制化的配置： 安全上我们要启用https 默认安装的Harbor将数据Volume挂载到主机的/data目录，我们需要做一些定制，本篇我们将其挂载到主机的其他目录。后边为了实现Harbor的高可用，再继续探索将Registry的存储驱动切换为CephFS或S3。 将Harbor默认安装启动的mysql docker容器切换为外部的数据库， 我们的环境中已经有高可用的MySQL GR集群。后边我们再继续探索多个节点Harbor使用相同的外部高可用MySQL。 1.配置https访问 1.1 使用自签名证书 这里还是使用cfssl这个工具生成SSL证书和秘钥。
企业级Docker镜像仓库Harbor部署记录
我们一直使用Docker官方的Registry v2搭建我们的私有Docker镜像仓库。 最近我们打算使用Harbor这个VMware China开源的企业级镜像仓库，实际上Harbor以Docker官方的Registry为基础，在其上增加了管理UI、访问控制等企业用户需要的功能。
OpenLDAP 2.4的配置
本篇整理一下OpenLDAP 2.4的配置。 OpenLDAP 2.4有两种配置方式： 通过配置文件slapd.conf进行配置，这是旧版本的配置方式 通过修改配置数据库(cn=config)，这是新的推荐的配置方式 这里我们学习cn=config的方式。cn=config实际上是将slapd.conf中的内容转换成ldif格式，并组成以cn=config为根的目录树，这棵树会有很多节点，如下图所示：
使用Ansible部署Kubernetes 1.6高可用集群
我们已经用ansible在新的环境中部署了etcd和docker，接下来使用ansible部署Kubernetes 1.6集群。 由于对ansible的使用已经没有什么问题了，因此本篇记录的侧重点是白话描述一下部署的具体步骤，以及部署过程踩的一些坑。 因为前段日子写过一篇《Kubernetes 1.6 高可用集群部署》，本次在编写ansible部署Kubernetes的roles时主要是一这篇文章里手动部署的过程为参考。
使用Ansible部署etcd 3.2高可用集群
本文内容已过期 之前写过一篇手动搭建etcd 3.1集群的文章《etcd 3.1 高可用集群搭建》，最近要初始化一套新的环境，考虑用ansible自动化部署整套环境， 先从部署etcd 3.2集群开始。 需要部署etcd的主机信息如下： node1 192.168.61.11 node2 192.168.61.12 node3 192.168.61.13 1.配置管理项目目录结构 ├── inventories │ ├── staging │ │ ├── group_vars │ │ │ ├── all.yml │ │ │ └── etcd-nodes.yml │ │ ├── host_vars │ │ │ ├── node1.yml │ │ │ ├── node2.yml │ │ │ └── node3.yml │ │ └── hosts │ └── production ├── roles │ ├── common │ │ ├── defaults │ │ │ └── main.yml │ │ └── tasks │ │ └── main.yml │ ├── etcd3 │ ├── defaults │ │ └── main.yml │ ├── files │ │ └── make-ca-cert.sh │ ├── meta │ │ └── main.yml │ ├── tasks │ │ ├── create_etcd_user.yml │ │ ├── etcd-restart.yml │ │ ├── etcd-start.yml │ │ ├── etcd-stop.yml │ │ ├── gen-etcd-certs.yml │ │ ├── gen-etcd-systemd.yml │ │ ├── install_etcd_bin.yml │ │ └── main.yml │ └── templates │ ├── etcd.conf.j2 │ └── etcd.service.j2 ├── deploy-etcd3.yml roles/etcd3/defaults/main.yml：
服务治理之限流
大型网站系统主要的挑战是庞大的用户流量和高并发的访问，尤其是在一些大促场景下的会流量突增，如果不对这些流量加以管控，任由流量放大冲击系统，将会导致一系列恶劣的问题，例如一些可用的线程资源、连接资源被耗尽，分布式缓存容量被爆掉等，有可能会引起整个系统的雪崩。 当然普通网站系统在出现大量恶意流量和攻击时也会这些问题。
团队环境：Jenkins版本升级和插件更新
Jenkisn官方提供两种支持方式的版本： LTS(Long-term-Support)版本：大约每12周更新一次 Weekly Release：每周更新一次，每个版本会有一些enhancement和bug fix 我们使用的是Weekly版本，这里记录一下Jenkins版本的升级和插件更新。 最初我们是使用rpm安装的Jenkins，这种安装方式jenkins.war被默认安装到/usr/lib/jenkins下。 升级Jenkins的版本只要将这个目录的jenkins.war替换成新的版本，重启Jenkins服务即可。