
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
云计算技术随着互联网的不断发展而得到了广泛的应用,而今天我们就通过案例分析来了解一下,云计算基础设施部署都有哪些注意事项。
只要是报错,运维都可以通过重新部署解救问题。
但如果我们把一切都通过基础设施即代码(IaC)定义了呢?再遇到这种莫名其妙报错的时候,我们就可以直接销毁出问题的资源,并重新将其部署即可。我们再也不用浪费时间纠结于一个不可能的报错了,把所有的debug都延后再做,先让服务跑起来再说。
运维可以快速回退到先前状态
在过去,运维的眼里所有的变更都是永久性的,有的甚至不能回滚。但有了IaC之后,我们可以回滚了!如果不行至少还是可以回退到上一个状态的。有的IaC禁止回滚(Terraform)但是有“前进”(move-ahead)的策略。这二者各有各的优缺点,但我个人认为具体该用什么看团队的喜好就行。
版本控制和同行评审
当你在运维环境部署东西时,你的同事只会希望你所有都写对了。毕竟他们做不到蹲在你身边看着你干活,也不能在你完成后一步步重新检查所有东西,他们只是默认你没搞错。但如果有了IaC,那就意味着我们终于有了一个版本控制工作流。同事们可以检查你要部署的东西,没问题的话就给通过。他们也可以清楚看到具体要部署的是什么,有问题的留下评论并和你一起修改。忘了启用加密?很容易检测,完全不用对所有的资源都来个年度大审查。
检测漂移
漂移是非常让人头疼的事情。如果业务有时间很紧的需求,那么就会引发漂移。一个要改架构的需求,但之前又完全没有文档可以参考,再加上执行请求的人又在休假……一切都散了架,而没人能解释清楚为什么。重置也没了作用,一切都乱了套以及这个见鬼的Redis实例是从哪冒出来的?
原因也很简单,糟糕的文档记录、被无视的流程手续等等,让你的环境已经从初的架构漂移走了,而直到后所有都散架了你才发现它其实已经漂了很多年。
但这对IaC来说小菜一碟,因为它可以让环境变得“不可变”。借助一些工具,我们可以检测到所有没有用IaC创建的资源,而没有使用IaC工具修改的资源也可以轻易被它检测到。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。