今天是我入职我司一个半月的时间,今天终于鼓起了勇气,完成了一直很忐忑又拖了很久的docker 分享。这个分享的产生其实是源于这样一个故事:之前由于为项目搭建了一个mock server,然后就和团队里的运维哥哥一起将它放到docker中打包成镜像,并部署到服务器上,在运维哥哥的引导了,我完成了人生中的第一个我之前一直认为很高深的Dockerfile,然后运维哥哥就让我给大家做个docker分享!所以就有了今天这个操作。
开始的状态
之前一直都在准备ppt和分享的内容,在这个过程中,实际上自己一直都是不自信。
其一:
觉得我会的大家都会,我不会的大家也会,那做这个分享就是浪费别人的时间;
其二:
对自己没有信心,感觉自己吃不透docker,给大家分享就会很担心被问住,陷入了绝望的恐慌中。
这样想,我就会越来越觉得做这个分享没有很大的必要性。但是之前答应的事情,不能说放弃就放弃。就这样,我陷入了痛苦的恶性循环中,无法自拔。
寻求帮助,改善自己的状态
然后,我找到了我的buddy,说出了我的想法,他告诉我:其实做这个分享,你不要把它当做一个培训,它是一个你是否敢于表达出你学会的东西,讲出来,让大家听明白,这才是重点!
听完buddy的话,我恍然大悟:作为一个新生,我不应该把给大家分享我会的东西当做一种培训来看待,就像之前那些想法,仿佛非要让大家学会点东西才值得。因为最起码,在目前看来,这不因为是最重要的初衷。 现阶段,其实我可以自私点儿想,我有机会给大家做分享,对我来说这是一个很大的挑战和锻炼的机会,在大家面前能够勇敢的自信的把自己会的东西讲清楚,让大家听明白,在这个过程中发现我不足的地方,然后加以改进,这才是分享最主要的出发点。这样想,我感觉轻松了许多,也有了很大的勇气和动力去更好的准备。
准备中
首先是翻遍网上的各种docker学习文档, 学习docker的原理,理念,以及练习docker一些的操作。
最后终于敲定了分享的内容:
-
ppt
docker 介绍(what ,why,can do what,demo description)
-
demo
demo1
1.编写Dockerfile
2.将自己的项目构建成一个镜像
3.使用docker-compose来管理docker 容器,使用docker-compose运行项目demo2 :
1.在项目中使用Docker中的服务mysql
2.将项目打包成镜像
3.使用docker-compose来管理docker 容器,运行项目
虽然最后完美告终,但是过程中也有很多的问题:
-
不细心
案例: ppt中有错别字,docker拼写混乱
产生原因:做完ppt就没有再去过一遍检查是否有细节问题,跟没有检查错别字的问题
改进:做完ppt应该自己认真的再检查一遍:是否有语病,错别字等低级错误
-
讲东西时,整体 和 各内容模块 的逻辑结构不够有条理
案例:比如再讲docker-compose时,突然就讲里面的配置内容如何写的,就没有说docker-compose到底是什么东西,有什么作用之类,这样就会使听众很懵逼。
产生原因: 如果自己不能临场发挥有条理的组织所讲内容,并且自己也没有提前对每一部分列个提纲,构思该如何去讲,这样的话,那必然讲的没有组织,没条理
改进: 下次再讲时,提前列个提纲,组织下内容和语言,最好自己多预演模拟几次
-
估算的时间超出太多
案例:估算了20分钟,实际上用了一个小时20分钟
产生原因: 自己根本没有预先演练,计时,根本就是瞎估计的时间,完全没有可靠性;
改进: 下次类似的事情,应该提前演练,预估时间一个有依据的、可靠的时间;到了估算的结束时间 ,应该设闹钟提醒,以便于提醒自己和大家,注意把控时间,就不至于时间超出的太多。
做的好的地方:
- 看得出来有比较足的知识准备
- 讲的大部分都清楚
最后为了想让大家给我做一个全面的反馈,下来后我当晚做了一个金数据,发下去,结果其实并没有几个人给我填反馈,记得当时讲完session后,有人就说下去之后反馈就忘记了,事实证明真的是这样。
所以以后类似的事情,要反馈一定要及时,最好当场给出反馈最及时,不能拖到事后,这样效果会非常的不好。
抽象能力很重要,把自己弄懂的知识,用别人听得懂的话讲出来很不容易!
加油,自己!