部署从来不是一个省心活，自实习以来，踩过多次部署的“坑”，从头晕目眩，到双手合十，再到一段时间的貌似驾轻就熟，到现在感觉要学的越来越多。
实习
实习初入江湖，与部署结缘，与Docker、Kubernetes初识
记得那是入职的第一周，正在学习Docker、K8S的入门知识，突然来了第二周出差的指令 我也是没想到刚来就被安排了，我不是来做开发的吗，怎么安排我搞运维的活？。
目的地：山东省某市甲方公司
工作内容：实习公司是做私有云平台的，要去部署平台，将客户的一个服务容器化并上云运行，后者是我的工作内容
用户服务信息：出发之前不详
容器化
第一周还剩两天，抓紧熟悉docker命令，了解常见的服务容器化方式，还没入门就上生产了，慌~
第二周周一，凌晨4点半，起床匆匆赶高铁，记得大概中午到达目的地附近的汉庭酒店，门口餐厅匆匆扒拉几口后，奔赴甲方现场。
了解到甲方要上云的应用只有tomcat + DB2数据库，顿感轻松，tomcat容器化自己已经演练多次，DB2数据库想来也和mysql容器化大同小异，抓紧搞定返程~
还是太年轻了，tomcat容器化 & 稳定运行后，DB2容器化卡死。
首先要遇到的问题是甲方的版权要求，DB2要求安装其使用的版本，安装后安装license。还记得当时网上DB2容器化的指导少之又少，使用docker commit的方式构建镜像，总会卡死在一个步骤上，而对此步骤的纠错，相当于在搜索引擎中大海捞人（面向搜索引擎运维），大概历时两周，才在百度知道的某个被折叠的回答中找到了解决方法。
DB2容器化完成，原以为大功告成，刚准备打道回府，却被告知容器化后的DB2数据库有性能问题，甲方的业务，需要每天向数据库导入十几G的数据，原本运行在服务器上的写入脚本，只需运行2小时，而使用容器化的DB2实例导入数据，时间竟然要4个小时。
性能问题
好一个性能问题，这下头可大了，这可怎么处理？
首先使用单一变量法，是不是我构建的镜像有问题？
进入docker hub，拉取DB2的镜像好嘛，当时最新的DB2，也是当时（2018）得3年前构建的
替换为docker hub的镜像，再次导入数据，问题依旧~
接下来使用排除法，脑袋里列了一下可能影响的因素：资源、网络、IO，那么，一项一项排除吧
资源对比：原运行DB2的服务器，16U内存32G；现运行DB2容器，分配16U32G。好吧，同样资源继续跑一遍，问题依旧~
网络：网络对比验证，由甲方的网络工程师完成，验证结果是网络传输速度基本一致，看来网络也不是阻塞点
磁盘IO：在PaaS中，DB2数据库容器将数据目录挂载到存储中，所以服务器跑的DB2和容器化后的DB2的磁盘IO对比，只需要将服务器运行的DB2实例，数据目录挂载到同一个存储中，验证导入速度即可。唉~ 服务器上跑的DB2实例，挂载同一份存储，速度就是快一倍。
这可怎么办呀，我的三板斧已经挥完了，从现在的角度看来，应该会着手看DB2本身的配置了，当时选择了向上求助
向上求助
问题没有解决，我选择了回公司寻求解决方法
领导安排我的导师第二天带我一起杀回去
第二天中午，在甲方公司开搞，从DB2的众多参数入手，每次更改一个进行实验
经过多次实验，也经历了一个通宵(白交了一晚酒店钱)后，终于定位到是DB2的一个内存参数问题，虽然给到DB2容器的内存资源是32G，但实际容器中的DB2实例内存配置只有4G 虽然你给的多，但我只用一点点
最终，DB2的性能问题被解决了，第三天晚上导师带着去夜爬了泰山，只记得短袖短裤等日出的我好冷，但问题解决后心里好暖
然而，DB2最终的归宿，还是服务器。因为他的稳定性并不好，实际使用时很容易出现实例挂掉重启的情况，而实际生产又有强稳定性要求
这是我与部署的第一次偶遇，见面的邀请很突然，互相了解的过程很艰难，前后历时小俩月，酒店会员金升铂
安卓
校招误闯安卓领地，合规竟是最后一根稻草
本想奔赴后端开发，中途被安卓截了胡 岗位调剂
又是与新领域的一次新碰撞，从SSM框架到四大组件，如此转换猝不及防，踉踉跄跄勉强跟上了节奏
组里主要负责解决各种生产bug，每天乐此不疲
后来，给大家分任务开始了代码的整体重构，我被分到了埋点 & 合规
埋点用来记录用户行为数据，当用户触发某个行为时，同时记录用户触发时系统中各参数的状态
合规用来适配各地法规要求，并通过参数做编译区分。比如欧洲的GDPR，就有要求不能有数据出境（欧洲 -> 非欧洲），也就不能使用埋点功能
这里的埋点和合规，也就是我和安卓的部署缘分。
合规需求稳步向前，突然来的“一棒子”，让我了解到企业的发展需要密切关注国际关系的变化
当时中印关系交恶，阿三对中国企业处处使绊子，为了防止阿三借机找茬，需要紧急关闭所有历史机型（手机厂）的埋点上报
涉及到的机型共计60余个，安卓版本跨度从3.x到10.x，编译方式也有所差别，只记得最新的的gradle编译，最老的编译方式还木有接触过
作为部门的接口人，周末紧急被安排整改，经历两周时间，60+机型新版本成功上线
但，每天凌晨2点下班，上午10点又要赶来上班汇报进度，身心俱疲，于是，决定离开，合规也变成离开的最后一根稻草
这是与安卓的第一次相遇，安卓的“部署”让我很受伤
云计算
双手合十，拜向屏幕，祈祷部署成功
离开上家，加入了公有云大家庭，成为一名云服务开发，内容是算法平台类云服务
刚加入，一切伊始，自己刚刚接触算法领域，平台刚刚开始构建，自己和平台一并开启了成长之路
还记得第一个任务，是做聊天机器人的改造，从安卓阵营切到后端，一时还不适应，什么websocket，什么ES，统统不了解，好在有足够的时间学习进步
随着服务逐渐的完备，为了适配政务云的售卖方式，提升云服务的交付效率被提上了日程，政务云环境可以简单理解为各地政府买的自己的私有云，在内网和公有云使用方式类似
政务云服务的交付，层层依赖，首先需要有底层的裸金属服务器、网络、机房等配置，等这些都配置好后，一些基础云服务如虚拟机服务，虚拟网络服务，数据库服务，K8S服务... 需要首先完成部署交付，而我们所在的上层云服务，部署排在最后一个步骤
部署借助工作流平台实现，按配置选择网段、选择虚拟机规格等，最重要的是做好你的微服务配置
初次接触部署时，对于整体链路缺乏了解，仅是大致了解参数作用，就开始着手部署，部署的步骤层层依赖，如果过程中某一步失败了，整个部署需要从头来过，这也导致，这个阶段的我，每次部署，必双手合十，祈祷部署成功
一些玄学问题的出现，可能是因为你对它不够了解，部署就是这样的玄学问题，为了能更多的掌控部署，自己逐渐开始扣细节，日常会给自己留一些疑问，通过探索答案来让部署之路逐渐明朗
可用区是做什么的？
资源规格从哪里找？
网络请求过来，流转链路是什么样的？
如何实现服务配置的动态更新？
......
通过部署，增加了自己的求知欲，当你有了渴望，才会不断寻觅
部署于我，亦师亦友
我与部署的缘分，未完，待续
