生产服务器，编译还是二进制？

/t/166397

基本上是 rpm 包，少数 java 应用可能会使用 tar 包。

生产环境即使需要自定义（编译）安装，也会尽可能制作成rpm包来部署。

因为一个运维工程师面对的是数千或数万的服务器（或虚拟机）。

现在兴起的Docker/CoreOS部署是另外一种运维架构，但也会以二进制方式完成部署，采用了Layer https://docs.docker.com/terms/layer/

不知道有没有使用 Gentoo 来运行生产环境的？

生产服务器一般是不让你在上面编译的.

编译的话要装很多东西啊，生产装这么多是作死
而且u no test？既然测试，一般都找一样的机器吧，那么反正都编译好了，就拿测试好的用，别作。

生产服务器一般是不让你在上面编译的+1

虽说源码base是一个，不过二进制包有千千万万其他人帮你测试，而你自己手工编译，你就是这份二进制的第一个吃螃蟹的人。

我自己目前来说最正式的一个服务器就是申请的免费试用的Azure CN，装的CentOS的一个变种，仅仅yum装了nginx、mysql-server、php-fpm、php-mysql这几个包，最后还是挂了，连SSH都上不去了，数据都取不回来

恩……手上的VPS两个Ubuntu一个Arch
打算全部换成基于Docker的……这样基本就不用关心底层系统了
一般来说除非有奇怪的依赖源里没有才会考虑自己编译
我倒是很关心豆瓣使用Gentoo作为服务器系统的心路历程XD

@zinev 装几个包也能装崩掉，你这水平也是醉了。不要用个案证明整体

@ryd994 我刚想了想，不是因为那几个包弄崩的，应该是我手贱在上面sudo yum update && sudo yum upgrade

@zinev nonono，正常来讲这也是没关系的。我好几个私用VPS都是cron里放这个的。

@ryd994 http://www.zinev.com/p/windows-azure-bug-i-have-meet.html

推荐用二进制，如果是编译，不仅浪费大量的时间，而且不方便多人共同运维，上次叫一个人帮忙搭个环境，结果发现编译的是一个非常老的版本，并且连他都不知道哪些东西放在哪儿了。。。

正式的生产环境是不可能用编译方式的，都是在一台机器上编译完成后把二进制文件往其他机器上复制，
所有的机器的操作系统都是一样的，库文件也一样，只要在一台机器编译完成后就可以随便往其他机器上复制，如果有1000台以上的服务器，更换文件都要有多台分发的方式上线，不然上线非常漫长，等到你想吐。

你在生产服务器编译会造成大量资源占用的

编译不便于维护，节点少还好说，如果手头有一大票节点要维护就悲催了。
而且有时候编译会遇到不少的坑，排错又会花掉你一大票时间。

有人像我司这么奇葩吗？现在其他机器上编译成二进制，再打包上运维系统，分发到机器上。。

哥们儿，如果你才大二，好好学Python/Java/C++吧。也许你毕业的时候，运维就不存在了…… 因为运维做的事情越来越多的被自动化了，人工参与越来越少，职位需求量越来越少。

@snnn 所以运维的事情不就是在编写这些自动化的东西吗...

别编译了。。。太费时间，如果服务器多的话，累死你。。。现在的服务器性能都很强，编译出来的东西，性能优势不明显。

感觉二进制没啥不好，当然就我的使用程度来讲，看法可能还是非常肤浅的

@onlyice 我认为这很合理，集中管理

@ryd994 如果编的是 Apache, Python, MySQL 这种东西呢？生产机器上连个包管理系统都没有，这些基础的包都要自己编译，相当要命

@snnn 编写这些自动化程序的人，还有监控这些程序是否被正确执行的人，以及发现异常后来处理的人是谁？依旧是运维。虽然现在有一种岗位叫“运维开发”，但其核心工作内容还是围绕着“运维”这件事。

生产环境是发布最终代码的地方。自然是用语言规定的最终格式。编译在编译机器上搞定，不是运维人员的范畴。

@onlyice 犯不着吧，生产服没包管理这也太……
没特殊原因的话这可以说是作

内网自建软件源，专用服务器打包过后放到源里面，需要的机器自己从源安装，本质上还是二进制分发

一是编译慢，二是无法表达依赖关系，容易缺feature

@zinev 你这也是醉了，要不是服务器提供镜像有 bug，要不是你打开方式不对。

早就不自己编译了，维护起来太麻烦，依赖关系自己很难搞清楚。。

在一台机器上编译解决完所有依赖后打包，传输到目标机器s解压，设置path 目前是这样搞的