“无知”小孩“卖弄”Docker

今天是我入职我司一个半月的时间，今天终于鼓起了勇气，完成了一直很忐忑又拖了很久的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后，有人就说下去之后反馈就忘记了，事实证明真的是这样。

所以以后类似的事情，要反馈一定要及时，最好当场给出反馈最及时，不能拖到事后，这样效果会非常的不好。

抽象能力很重要，把自己弄懂的知识，用别人听得懂的话讲出来很不容易！

加油，自己！