因为重启 docker，服务起不来，把开发环境搞崩了，严严实实背了口锅
a663 · 2018-11-22 22:43:19 +08:00 via Android · 7485 次点击这是一个创建于 2191 天前的主题，其中的信息可能已经有所发展或是发生改变。
诶，今晚因为领导要我加一个应用的 ci 给开发和测试环境，就在本地搭建了一个私有 docker registry，搭建完成后得把开发节点的 docker 配置修改后重启。 就 system ctl docker restart （正确做法应该是先 stop 再 start ），结果某些应用没有正确退出，只是容器退出了，就导致 restart 结束后部分 container 没跑起来，还有部分跑起来了但访问不到。 然后这里还有最重要的是 gitlab 服务在这里。
说一下公司现状，刚来公司不久，之前没有运维，也没人做任何的运维规划，各种乱象，比如 gitlab 搭建在开发节点（只有一台开发节点），然后开发节点的很多 container 退出后不删除的大把，还有就是有些没用的服务乱起，各种。 之前有提议说想把 gitlab 迁移，领导没反馈，就先留着，想等以后在做了。
然后自己也一直不想去理开发环境，结果这次 ci 的任务就给搞出问题了。 然后，由于不确定哪些应用有没有正确起来的，就和领导说明天一大早计划迁移 gitlab，清掉开发节点的所有 container，让开发重新部署一遍，貌似现在感觉氛围不太对了。 好尴尬啊，自己的锅，跑不了了
之前一直觉得开发环境哪天肯定会崩，没曾想是自己搞崩的……还是自己不够细心，很自责
 |
1
Dingo 2018-11-22 22:47:19 +08:00
楼主加油，好人一生平安
|
 |
2
alvin666 2018-11-22 22:48:26 +08:00 via Android
restart 不是先 stop 再 start 吗？...
就提示不也是先 stop 成功再 start 成功吗 |
 |
3
zhongyiio 2018-11-22 22:49:22 +08:00 via Android
同情，要是 container 没有配 restart:always 就瞎了
|
 |
4
johnniang 2018-11-22 22:51:14 +08:00
只要数据还在都不是事儿
|
 |
5
a663 OP @johnniang 数据还在，然后得麻烦开发一遍，还需要群里沟通，头儿有点不太开心，我表示理解他的心情😢😢
|
 |
6
duola 2018-11-22 22:56:39 +08:00
千万不要把数据弄丢了。
|
|
7
a663 OP @zhongyiio 有些配了有些没陪，开发自己玩的，然后容器的使用也比较粗糙，他们是先把容器停了，在把代码文件在容器内替换，然后重启
|
|
12
alvin666 2018-11-22 23:05:24 +08:00 via Android
学到了...以后用 systemctl stop &&systemctl start
|
 |
15
xuanbg 2018-11-22 23:29:28 +08:00
没启动的容器 start 一下不行吗？
|
 |
16
momocraft 2018-11-22 23:30:14 +08:00
restart 不可以 stop+start 可以是为什么
|
 |
17
afc 2018-11-22 23:32:23 +08:00
我不知道你的容器里面跑了什么，在我看来只要 MySQL 这些数据库能启动，不可能程序会因为非正常退出就无法启动。还有，你重启了 docker，你只要看 docker ps -a 里面 Exited 时间一致的那一批 container，就是你重启前在跑的 container，至于不能启动的，慢慢查日志。
|
 |
18
woodfish 2018-11-23 00:40:01 +08:00
容器看制作者质量，有些满足幂等性的随挺随起，有些不满足幂等的挺了再起就又重新初始化了。用容器前先测试它的幂等性
|
 |
19
mason961125 2018-11-23 00:53:35 +08:00
很好奇为什么这些人写 Dockerfile 的时候不考虑万一容器崩了重启的情况？而且好像似乎也没有做数据持久化？
|
 |
20
chuanzhangACE 2018-11-23 00:53:35 +08:00 via Android
@a663 我们 docker 数据也是直接挂载的，代码通过 jinkens 替换，所以想请教一下你们现在 docker 使用细节，你说的 docker 使用粗糙指的什么
|
 |
21
likuku 2018-11-23 01:03:33 +08:00
看起来也没有标准操作流程手册之类 [ 如此这般，责任每个人都有啦 ]...虽然你们是 dev 也干了 ops 的活...
|
 |
22
ywgx 2018-11-23 08:10:08 +08:00 via Android
典型的大部分互联网企业特点，运维管理，部署结构混乱
|
 |
23
18660103530 2018-11-23 08:24:14 +08:00
我也搞蹦过，只要数据卷还在就好。另外我那次搞蹦的是 docker 服务器直接没了，但是 daemon.json 还在，重新安装了 docker 服务容器全部自己回来了。
|
 |
24
bigbyto 2018-11-23 09:12:52 +08:00 via iPhone
人在江湖飘，难免有背锅的时候。感觉楼主还是蛮有担当的，过去就好了
|
 |
25
saltxy 2018-11-23 09:19:55 +08:00
@chuanzhangACE 我们是 jenkins 构建代码打包到 image 里，push image 到自建的 registry，生产服务器直接移除老的 container 启动新的 container
|
 |
26
lincolnhuang 2018-11-23 09:41:05 +08:00
现在运维就是一个背锅的，感觉 LZ 以后还会背。。所以现在运维难招啊，没人肯做
|
 |
27
zhouzm 2018-11-23 10:05:50 +08:00
做好数据持久化，使用 docker-compose，容器崩了怕什么？
我经常 docker-compose down && docker-compose up -d |
 |
28
buhi 2018-11-23 10:32:08 +08:00
mount 代码是什么骚操作...
|
 |
29
jwdlh 2018-11-23 10:46:28 +08:00
不请运维好歹请个备份啊
|
 |
30
okwork 2018-11-23 11:09:51 +08:00
一台机器上容器太多了，互相依赖的话，真的很慌。像比较重的服务，还是单独拎出来独立部署吧
|
 |
31
anubu 2018-11-23 11:36:30 +08:00
容器不是虚拟机。实际应用中，对于容器，启动、停止、重启是小概率事件，创建、删除、重建是大概率事件。在容器化一个应用时，主要考虑的是能不能方便的在其他 docker 主机上重建这个应用容器。这应该就是我们使用容器的目的吧，方便的部署和迁移。
一点经验： 1. 不要使用 docker run 来创建和启动一个容器，而是使用 docker-compose。使用 yaml 文件定义的容器更清晰，更容易被复制重建。 2. 充分考虑需要数据持久化的应用数据，显式的指定挂载卷路径并做好备份。 3. 不要在容器中修改非持久化保存的数据。 |
 |
32
march13th 2018-11-23 17:38:40 +08:00
楼主所说的环境,很符合目前我当下的环境...没有运维,我(开发) 自己搞的一套 docker 测试环境和生产环境，然后也是比较乱。
|
Select Language