最近半年一直在尝试物联网相关技术在传统行业的应用，推动企业数字化转型。结合阿里云和阿里云IoT平台，初步实现了几个主要业务功能，整理分享如下：
核心诉求是终端设备接入物联网：一方面是为了数据的远程交互，另一方面是数据的收集和应用
目前终端种类繁多，未统一平台和标准，操作系统覆盖Windows、Android、Linux. 而IoT模组又依据主流通讯技术分成2G、3G、4G和NB-IoT，不同通讯技术的模组使用的协议不尽相同，这对于终端仪器开发的同学来说是个痛点，各个操作系统和开发语言均需对接IoT模组，一旦模组被更换，又需要重新匹配新的协议。
数据接收端也不好过，不同的运营商有自己的IoT平台，管理物联网卡和数据收发。更有运营商强制要求指定型号的模组只能用自家平台进行数据管理（如移远 BC95-5 只能使用电信Easy IoT平台）。应用系统开发需要维护多个运营商IoT平台，接口亦需开发多套。
我们探讨数字化生存，数字化转型，那么何为数字化转型？为什么要转型？如何去做转型？这是我们探讨话题的最根本的问题。我将结合自身工作经验和行业案例，浅谈这三个问题，旨在抛砖引玉。
什么是数字化转型
我们谈转型，这是一个过程，有始有终。那么数字化转型是从哪转到哪？一般来讲，我们认为是从信息化技术也就是IT，转型到数字化技术DT.
IT与DT最直观的区别是，IT是落后于需求的，而DT是领先于需求的。如何理解这一说法，这里举一个例子：
为了在Kubernetes上搭建RabbitMQ3.7.X Cluster，踩爆无数坑，官方整合了第三方开源项目但没有完整demo，网上的post都是RabbitMQ 3.6.X旧版的部署方案，几经周折，最终弄明白在Kubernetes集群下，基于Kubernetes Discovery，使用hostname方式部署RabbitMQ3.7.X Cluster，总结如下：
rabbitmq-peer-discovery-k8s是RabbitMQ官方基于第三方开源项目rabbitmq-autocluster开发，对3.7.X版本提供的Kubernetes下的同行发现插件，但官方只提供了一个基于IP模式的demo
1 | kind: Service |
在ConfigMap配置项中，指明 cluster_formation.k8s.address_type = ip，也就是说RabbitMQ Node的命名和访问地址是以IP地址作为区分，如rabbit@172.0.5.1
前言：
在上一篇文章中，我们已经在K8S集群部署了Jenkins、Harbor和EFK。作为本系列最后一篇文章，将通过实际案例串联所有的基础软件服务，基于K8S做DevOps。
整体的业务流程如下图所示：
前言：
在系列的第一篇文章中，我已经介绍过如何在阿里云基于kubeasz搭建K8S集群，通过在K8S上部署gitlab并暴露至集群外来演示服务部署与发现的流程。文章写于4月，忙碌了小半年后，我才有时间把后续部分补齐。系列会分为三篇，本篇将继续部署基础设施，如jenkins、harbor、efk等，以便为第三篇项目实战做好准备。
需要说明的是，阿里云迭代的实在是太快了，2018年4月的时候，由于SLB不支持HTTP跳转HTTPS，迫不得已使用了Ingress-Nginx来做跳转控制。但在4月底的时候，SLB已经在部分地区如华北、国外节点支持HTTP跳转HTTPS。到了5月更是全节点支持。这样以来，又简化了Ingress-Nginx的配置。
该教程仅对docker常用操作进行了总结归纳
Docker是2013年，dotCloud用Golang开发的基于LXC的高级容器引擎
Linux Container的简写。可以提供轻量级的虚拟化，以便隔离进程和资源，而且不需要提供指令解释机制以及全虚拟化的其他复杂性。相当于C++中的NameSpace
孔老夫子说：“吾十有五，而志于学。三十而立，四十而不惑，五十而知天命，六十而耳顺，七十而从心所欲，不逾矩” 。然而我的而立之年，却是感受了两次“死亡”……
2017，疾病先后夺去了我父亲和祖父的生命，整个家庭乃至整个家族都被巨大的阴霾所笼罩。我不清楚我和我的家人究竟是如何熬过这一年的，但在2018新年钟声敲响的那一刻，所有人都满怀希望，祈祷新的生活，美好的生活。
前言：
考虑到公司持续集成与docker容器技术实施已有一段时间，取得了不错的效果，但对于设备运维、系统隔离、设备利用率和扩展性还有待提升，综合目前比较成熟的微服务技术，打算把现有业务迁移到K8S集群。
由于公司所有业务均部署在阿里云上，最开始就调研了阿里云自己提供的Kubernetes集群，但后来还是放弃了，主要考虑几方面：
接下来会详细介绍在阿里云搭建原生Kubernetes集群的过程。
