传统服务可以通过键盘和显示器本地管理,OpenSSH 远程管理,通过配置还能使用串口。
容器的管理让你抓狂 docker exec 和 kubectl exec 进入后与传统Linux差异非常大,这是镜像制作者造成了。
卧槽!!! 一万匹草泥马
然后就自己用 Dockerfile 编译,整出200MB的镜像,卧槽这么大。
很多容器的镜像中是不包含 iptables 的,所以无法做颗粒度很细的容器内部网络安全设置。即使你制作的镜像带有iptables ,多数容器的侧咯,IP地址和端口是随机变化的。
绑定IP地址又带了容器的复杂性。
一旦攻入一个容器,进入容器后,容器与容器间基本是畅通无阻。
在容器中藏一个后门比物理机更容易,如上文所说很多容器中没有调试相关命令,限制了你排查后门的难度。所以Dockerfile 制作镜像,最好使用官方镜像衍生出你的镜像。
谈到监控,跳不开 prometheus(普罗米修斯),它并不能覆盖到所有监控。
我曾经写过一篇文章《监控的艺术》网上可以搜到。
容器与CI/CD
在DevOps场景中,使用 docker 或 kubernetes 做 CI/CD 是很扯淡的。
当 git 产生提交后,gitlab/jenkins 启动容器,下载代码,编译,打包,测试,产生构建物,编译 Dockerfile ,上传 docker 镜像到 registry,最后部署到容器执行。
卧槽!!!速度能急死你。
于是乎,我们做了 Cache。 不用每次都 pull 镜像,缓存 Maven 的 .m2 库,不再清理代码(mvn clean)提速不少,测试环境凑合用吧。 注意不mvn clean 有时会编译出错
至于生产环境,我就不说了,有多少人真用CD部署生产环境。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。