Linux环境搭建太慢？3步绕过90%配置坑

　　去年七月份那会儿，我原以为给新项目搭Linux环境能像往常一样，装个CentOS 8，跑几行yum install就完事儿。结果产品经理突然甩过来个需求："要兼容某个小版本的Docker，还得用他们指定的内核参数。"我盯着屏幕上的报错，凉了的外卖在桌上放着，心想这活儿怕是要拖到半夜——结果发现，90%的坑根本不用跳，绕着走就行。

　　第一步：别碰系统自带的包管理器。我原以为yum/apt是万能的，结果在CentOS 8上装Docker CE时，官方repo的版本比产品要求的低了三个小版本。后来学乖了，直接去GitHub下载二进制包，解压到/usr/local/bin，配置文件扔/etc/docker，三分钟搞定。产品经理那句"就这么点东西"还在耳边，可他不知道，光等yum update就得抽根烟的功夫。

　　地铁上掏手机复现过这事儿：用系统自带的docker-ce-19.03.15，启动容器时总报"OCI runtime create failed"。后来换成从Docker官网下的20.10.20，连重启都不用，直接docker run --rm hello-world就通了。这事儿我敢打包票——但凡碰到版本卡死的，别跟包管理器较劲，直接下二进制包，省事儿。

　　第二步：内核参数别手动改。我见过太多人把/etc/sysctl.conf改得跟代码注释似的，结果重启后一半参数没生效。去年帮测试组排坑，桌上排成一排的测试机，每台都贴着"已改内核参数"的标签，可跑压力测试时还是掉链子。后来发现，用systemd-sysctl.service自动加载才是正道——把参数扔/etc/sysctl.d/99-custom.conf，执行systemctl restart systemd-sysctl，比手动sysctl -p靠谱多了。测试组那哥们儿当时就沉默了，UI走查时的沉默都没这么尴尬。

　　但这里有个坑：某些云厂商的镜像会覆盖/etc/sysctl.d/下的文件。我原以为把参数写到/etc/sysctl.conf里能覆盖，结果重启后全被云厂商的脚本冲掉了。后来学乖了，先查/etc/cloud/cloud.cfg，看有没有"preserve_hostname: false"这种会覆盖配置的选项，有的话就改cloud-init的配置，或者直接在用户数据里写runcmd脚本——虽然麻烦，但至少不会半夜被测试组打电话叫起来。

　　第三步：别信"官方文档说必须这样"。去年搭K8s环境时，文档里写着"必须用kubeadm init --kubernetes-version=v1.23.5"，结果跑起来总报"image pull backoff"。后来发现，官方镜像仓库里v1.23.5的标签指向了错误的版本，而v1.23.6反而能用。我直接改了kubeadm的配置文件，把version字段改成v1.23.6，问题解决。产品经理那会儿正催进度，我回他："官方文档有时候也坑人，得自己试。"

　　这事儿让我想起之前帮运维组搭Jenkins：文档里说必须用OpenJDK 11，结果跑起来总报"Unsupported class file major version 61"。后来发现，是Jenkins的某个插件还没适配JDK 17的字节码版本，而OpenJDK 11刚好卡在这个边界上。我直接换了AdoptOpenJDK 17，问题解决——官方文档没说不能换JDK版本，但也没说能换，全靠自己试。

　　说到底，Linux环境搭建慢，90%的坑都是"非得按官方文档来"或者"非得用系统自带的工具"。优胜劣汰的道理在这儿特别明显：能绕过这些坑的，都是被坑过无数次的老油条；还在跟包管理器较劲的，要么是新人，要么是头铁。我现在搭环境，第一步就是看有没有二进制包，第二步是查systemd的加载顺序，第三步是直接改配置文件——官方文档？等环境跑起来再说。

文章配图，仅供参考

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!