开发人员:Docker和DevOps一样不靠谱

“Docker天生就是为企业级应用服务的”
“Docker只能在OSX上工作,根本不支持Windows”
“我觉得让Docker跑起来太难了”

这些描述并不完全错误,但却容易让人忽略那些不正确的内容,或者不再正确的内容。很多文章中包含大量没用的术语,描述了大量复杂的框架,讨论如何仅使用3万个容器支持每秒1万个billion的请求,如何在600个云端服务器上支持5万个微服务。可是这些跟我一个程序员有毛关系?

276606876192475598

很遗憾关于Docker的这些误解和错误信息一致存在,阻碍了开发人员尝试使用Docker。因此,这里列举了关于Docker最常见的十大误解,同时给出了对应的解决办法。

误解10:我不能使用Docker进行开发工作(因为运维不允许我编辑Dockerfile)

开发人员对开发工具和环境配置有非常明确的要求。然而,开发人员被告之Docker镜像只能使用在生产环境上。这意味着开发人员没有权限编辑生产镜像的Dockerfile,因此他们就不能在镜像中增加自己需要的东西。
这种情况下,开发人员无法使用Docker支持应用开发。如果开发人员不能编辑Dockerfile去增加自己需要的工具和环境配置,他们怎么可能使用Docker支持应用开发?
开发人员当然可以copy&paste生产环境Dockerfile到自己的环境,然后按照自己的需要修改文件。但是,我们都知道复制是万恶之源。

解决办法

复制Dockerfile会造成许多潜在的问题,相比较而言,基于已存在的Docker镜像构建自己的镜像是一个更好的方案。
例如,开发人员可以以一个名字为“node:6”的镜像为基础,构建自己的产品镜像。所以,为什么不创建一个“dev.Dockerfile”,以产品镜像为基础构建自己的开发镜像?
现在开发人员可以修改dev.Dockerfile来满足自己的开发需要,并且这个开发镜像使用的环境配置和生产镜像完全一致。同时你还可以把这个dev.Dockerfile通过git共享给其他开发人员,这样他们就可以复制出和你一模一样的环境。

误解9:开发人员看不到容器中的任何东西

Docker是应用虚拟化(容器化)工具,而不是一个虚拟机。但是,开发人员经常希望像使用虚拟机那样使用容器。
开发人员经常需要拿到logs(不止是应用的简单输出),检查debug输出,并且要确保对容器中的文件和系统的修改都被正确执行了。
如果容器不能像虚拟机一样,开发人员如何得知系统运行的情况?开发人员如何才能看到文件,环境变量,以及其它需要在容器中获取的信息。

解决办法

从技术上来说,容器确实不等同于虚拟机,它只是运行了一个linux操作系统。
是的,这个系统是被裁剪过,像类似Alpine Linux的小型操作系统,但是它仍然拥有基本的Linux内核。以linux操作系统为基础的容器使开发人员可以深入到容器内部。
有两个基本的方法可以让开发人员深入到容器内部。

方法1:shell进入一个运行中的容器
如果容器已经在运行,开发人员可以使用“Docker exec”命令进入容器,开发人员可以对容器拥有完全的shell访问权限。
执行完这个命令,开发人员就进入了容器,像使用其它linux操作系统一样使用容器。

方法2:使用Shell执行容器命令
如果容器还没有运行,开发人员可以使用Docker命令,基于镜像启动一个新的容器。然后,就可以像方法1那样进入容器。

误解8:开发人员必须在容器内写代码?开发人员不能使用最喜爱的编辑器?!

开发人员第一次看到容器时,可能很兴奋,但是这种兴奋感很快就消失了。开发人员会困惑自己该如何把代码放入容器,然后构建一个新的镜像。
难道每次改代码都要重新构建镜像?那也太痛苦了吧。这当然不是一个好的做法。好吧,是不是可以进入容器,然后使用vim编辑代码?
确实可以,但如果开发人员希望在容器中使用更好的IDE/编辑器,恐怕就不行了,开发人员不得不使用像vim这样的工具(甚至不是习惯使用的vim版本)。
开发人员只能使用命令行/shell方式进入容器,他们怎样才能使用自己喜爱的编辑器?

解决办法

Docker允许开发人员使用“volume mount”在主机文件夹和容器文件夹之间进行映射。比如使用类似以下命令:

docker run –v /dev/my-app:/var/app

这种方式下,容器路径“/var/app”文件夹指向主机本地文件夹“/dev/my-app”。使用喜爱的编辑器在“/dev/my-app”路径下编写代码,容器对应路径下的代码当然也就发生了变化。

误解7:开发人员不得不使用命令行debugger?

误解8的解决方案已经让开发人员可以使用喜爱的编辑器编辑代码,并且把代码放入容器,但是开发人员只能进入容器才能进行代码调试?开发人员可以在容器内使用编码语言的命令行调试器进行代码调试,但这不是唯一选择。
有没有可能使用IDE/编辑器自带的调试器调试容器中的代码?

解决办法:

简单来说,答案就是使用“远程调试”。远程调试非常依赖于编程语言和运行时环境。
以Node.js为例,开发人员可以使用TCP/IP端口(5858)进行远程调试。要基于Docker容器进行远程调试,开发人员需要暴露出Docker镜像的5858端口。
基于5858端口,开发人员就可以shell进入容器,使用各种典型的方法进行Node.js调试。

误解6:开发人员不得不每次都使用“Docker run”,但是他们记不住“Docker run”的参数

毫无疑问,Docker包含大量的命令行参数。对着Docker帮助页找参数是一件痛苦的事情。当运行一个容器时,开发人员将毫无疑问的感到困惑和沮丧,因为从来都不会一次性正确运行。
更麻烦的是,每执行一次“Docker run”就会从同样的镜像创建出一个新的容器实例。
如果开发人员需要一个新的容器,那当然很棒。然而,如果开发人员只是希望运行一个以前创建的容器,运行“Docker run”就不会得到想要的结果,它只会创建一个新的容器实例。

解决办法:

开发人员不需要每次都使用“Docker run”,可以使用“stop”和“start”命令停止和启动容器。这些操作能够使容器两次运行之间的状态保持一致,意味着开发人员可以在需要的时候重启容器。如果开发人员修改了容器中的文件,这些变化在容器重启之后就会生效。

误解5:Docker不能在macOS和Windows上工作

几个月以前,这个说法还是正确的。
过去,Mac和Windows上的Docker需要使用一个完整的虚拟机作为“Docker machine”,同时使用额外的软件协议帮助VM进行里外通讯。
这种方法当然是可工作的,但是造成浪费的同时,也限制了Docker的某些特性。

解决办法:

幸运的是,Docker知道自己不能只支持Linux作为主机(host)操作系统。2016下半年,Docker发布了官方Docker for Mac和Docker for Windows软件包。
现在,在Mac和Windows上安装和使用Docker变得非常简单。

误解4:Docker就是一堆命令行

Docker出身于Linux,当然是天生支持命令行方式的工具。
Docker具有丰富的命令和参数,然而对于不喜欢使用console/terminal的开发人员来说,命令行方式会让他们抓狂并且降低效率。

解决办法:

伴随着Docker社区的成长,越来越多的工具包括可视化工具正在出现,它们帮助更多的开发人员习惯使用Docker。
举例来说,Docker for Mac和Docker forWindows包含和Kitematic的基本集成,使用GUI的方式管理Docker的容器和镜像。
使用Kitematic,开发人员很容易就可以在Docker镜像库中搜索出需要的镜像,同时管理各种已经创建和正在运行的容器。

误解3:不能在容器中运行数据库

容器是短暂存在的-它们根据需要随时被删除和创建,没有反悔的机会。如果开发人员存储数据在容器里的数据库中,删除容器就会删除数据。
更严重的是,数据库系统能够进行扩容-增大服务器配置以及扩展更多服务器。
Docker擅长于扩容,当需要更多计算能力时,Docker很容易创建更多实例。另一方面,大多数数据库系统在扩容方面要求具体的,特别的配置和维护。
是的,在容器中运行产品数据库并不是一个好主意。然而,也不乏使用容器支持数据库系统的例子。

解决方法

在Docker容器中运行数据库并不是一个好主意,但是对于开发环境还是非常有帮助的。
如果解决Docker容器的“短生命周期”的问题?还是使用“Volume mounts”。
和误解8(编写代码)类似,“volume mounts”提供了一个方便的方法,把数据存储在本地文件系统供容器使用。

误解2:Docker要么用,要么完全不用,好像不能一点一点用

刚开始接触Docker时,开发人员会认为要么使用Docker支持开发,调试,部署等整个DevOps过程,要么就根本不能用,因此很难把Docker应用在自己的项目上。
如果一个工具或技术被认为是只能全部应用或者根本不用,那这个工具或技术就应该被重新严格评估。如果评估结果确实如此,那么这个工具或技术就不值得时间和金钱的投入,尽管绝大多数情况下这都不是事实。

解决方法:

就像大多数开发工具一样,可以被一点一点应用。
从小处着手,先在容器中运行一个开发数据库。然后,构建一个包含单独library的容器,试着理解它是如何运作的。接着,构建一个运行在容器中,只需要几行代码的微服务。接下来,应用容器在一个多成员的项目上进行开发支持。
容器并不是要么全部应用,要么根本不能用。

误解1: Docker对普通开发人员来说根本就没用,因为Docker是给大企业用的,和DevOps一样

第一次看到Docker的开发人员都会有这个赶脚,这玩意是给大企业用的,对我没帮助。在大多数开发人员的眼里,Docker只会对团队有用,对个人来说只意味着多学东西,多些麻烦。
看看那些高大上的会议上的议题:某某特牛逼公司用Docker,Kubernetes还有内部特供专属大规模宇宙最强运维平台自动化了10,000,000个容器支持春节抢红包!听上去就跟我没一毛钱关系。对吧,对你大企业来说,对你们这些经理们来说好的很,对我有啥用,一大堆的命令行要学。

解决办法:

该学的还是要学一下,从最简单的开始。
比如你现在用一台12G内存的虚拟机跑了3个web应用,那么用一下docker你可以在这台机器上跑更多的应用,而且不用担心互相影响。意味着你可以接更多的私活儿,每家都收同样的运维费用,但是你的成本不增加一毛钱。
比如你现在要为了能在你的MacBook上同时运行不同版本的Node抓狂,用了Docker就不是问题;
比如你现在要忙着每次都要给mysql数据库灌入一堆测试数据,测试完了又要重来,用了docker就简化成了 docker run 一个装好测试数据的mysql容器。

最后记住:不要人云亦云!

这些对Docker的误解存在是有其原因的,因为Docker来自Linux,可能整日用Windows的你不太适应(对,一般Linux服务器都是运维在管理的,开发人员还是用Windows更顺手)。
但是记住,之所以这些被称为“误解”,是因为相信了这些东西的人都得不到其中的好处。
如果看了我列举的这些“误解”之后,你的回答仍然是:好吧,但是…
那么我需要提醒你花点时间,扔掉手游和娱乐节目,好好学点东西,不然怎么称自己为:骄傲的开发人员。
没关系,只要肯学习,Docker并没有那么难。这个公众号存在的意义之一就是帮助你,在我们的后台留言或者来参加我们的《基于Docker的DevOps实战培训》,你一定可以用好Docker。


请关注微信公众号 【devopshub】,获取更多关于DevOps研发运维一体化的信息

qrcode_for_gh_b7c158df1fd1_430