本文关键词：openshift 做网站
前两天有个哥们私信我，说想搞个企业官网，预算不多，但想要高可用，还要方便扩容。我第一反应是：“上K8s呗。” 他问：“K8s太难了，我搞不定啊。” 我说：“那试试openshift吧，红帽亲儿子，虽然也是K8s，但稍微友好那么一丢丢。” 结果他更懵了：“这玩意儿真能拿来建网站？不是搞什么大数据、微服务架构的吗？”
这就得说道说道了。很多人对openshift 做网站这事儿有误解，觉得那是给大厂用的重型武器。其实吧，只要你懂点Linux，稍微折腾一下，它真能跑起来。不过，咱得说实话，这玩意儿不是拿来给小白建个静态博客的，那是杀鸡用牛刀。但如果你是要做那种对稳定性要求高、以后可能还要搞微服务拆分的业务系统，那它确实是个好选择。
我去年帮一个做跨境电商的朋友搭过一套环境。当时他们原来的服务器经常崩，特别是大促期间，流量一上来，PHP-FPM直接撑不住。我就建议他们把应用容器化，部署到openshift 做网站 的环境里。刚开始我也头疼，因为openshift的权限管理（SCC）挺严的，普通用户甚至没权限跑privileged容器。我们折腾了两天，才把那个基于Nginx和PHP的镜像给调通。
这里有个坑，我得提一嘴。很多教程里说直接docker build然后push，但在openshift里，你得用BuildConfig。而且，默认的s2i（Source-to-Image）镜像有时候不太兼容某些老旧的PHP扩展。我朋友那个项目，因为用了一个很偏门的加密扩展，死活编译不过去。最后没办法，我写了一个自定义的Dockerfile，基于centos:7，手动安装那些依赖，再推送到openshift的镜像流里。这个过程挺折磨人的，大概花了半天时间。但一旦跑起来，那个爽感，真的。
你看，现在的流量波动，以前得提前一周准备服务器，现在？在openshift里加几个副本，点几下鼠标，或者配个HPA（水平自动伸缩策略），系统自己就扩容了。我朋友那边，大促期间流量翻了五倍，服务器没崩，反而因为自动扩容，响应速度还快了点。当然，代价是运维成本上去了。你得有人懂K8s的基本原理，懂Pod、Service、Route这些东西。如果你是个纯小白，连SSH都不会连，那还是老老实实买那种“宝塔面板”式的虚拟主机吧，别来折腾这个。
还有个问题，就是存储。openshift 做网站 的时候，持久化存储是个大坑。如果你用NFS，那得配好权限；如果用Ceph，那更是重量级选手。我朋友那个项目，图片上传功能，一开始直接用本地目录，结果Pod一重启，图片全没了。后来我们接入了MinIO，虽然配置稍微复杂点，但数据安全了。这里有个小经验，别在容器里存任何重要数据，永远把数据往外挂。
再说点实在的，关于成本。很多人觉得openshift贵，其实如果是用开源版OKD，软件授权费是零。你只需要付云服务器的钱。但是，运维的人力成本很高。如果你团队里没有专门搞DevOps的人，那这个钱花得就有点冤。我见过不少小公司，花大价钱买了云上的OpenShift集群，结果没人会用，最后集群里跑的全是闲置的Pod，钱烧得哗哗的。
所以，我的建议是，除非你的业务真的需要容器化带来的敏捷性和弹性，否则别为了“高大上”而去用。对于大多数中小企业官网，WordPress搭在普通的LAMP环境上，配合CDN，性价比最高。但如果你是在做SaaS平台，或者需要频繁迭代、灰度发布的复杂应用，那openshift 做网站 绝对值得你投入时间去学习。
最后再啰嗦一句，别信那些“一键部署”的神话。在容器世界里，没有真正的“一键”。你看到的平滑，背后是无数次的配置调试和故障排除。当你第一次看到Pod在故障节点自动迁移，业务无感知继续运行时，你会明白，这一切折腾都是值得的。
总之，技术没有好坏，只有适不适合。别盲目跟风，根据自己的团队能力和业务需求来选。希望这篇碎碎念，能帮你少走点弯路。
