小公司java服务devops的几种方案

发表于

小知识，大挑战！本文正在参与“程序员必备小知识”创作活动。

devops这个概念无疑是解决开发运维之间的鸡零狗碎小矛盾的良方，但针对lz所在的小公司而言，还是开发占据了决策的主导地位，也承担了更多的责任。所以在此文中做一下我们小公司的一体化运维的方案

当然不管是什么时期，不管是什么部署方案，都逃不了如下几个步骤

  • 程序打包（分不同运行环境）
1
go复制代码譬如：maven package
  • 上传程序包至运行服务器对应路径下，一般是某个tomcat的webapps下
1
bash复制代码譬如：mv /**.jar /tomcat/webapps/**.jar
  • 运行或重启tomcat
1
2
3
4
5
bash复制代码譬如：
# 先停止服务
kill -9 ***
# 再启动服务
sh /tomcat/bin/startup.sh
  • 查看对应的启动日志，及其启动情况
1
bash复制代码tail -f /tomcat/logs/catalina.out

主要分为以下几个时期：

手动发包

这个时期，完完整整滴对应了上面的几个环节，只不过就是有点麻烦，麻烦，麻烦

具体操作：

  • 手动打包
  • 手动传递
  • 手动操作tomcat服务
    优点：适合新手熟悉linux平台
    缺点：但每个环节都需要自己手动的调整一些参数，而且每次都需要很多重复性的工作，一不小心的话可能就得重来

jenkins脚本及定时任务

服务直接对接了代码管理平台，代码提交/手动触发版本迭代，固定的活动固定的环境

具体操作：

  • 搭建配置jenkins服务
  • 每个服务对应一个活动
  • Maven、Gradle、Ant脚本打包
  • shell脚本远程复制、重启服务
    优点：适合在固定的服务器下，譬如请求数量稳定的生产服务或者小型的测试服务，不同测试环境针对不同分支代码，便于业务测试和专业测试，对于开发人员更加友好
    缺点：扩容或收缩服务时，细节操作过多，工作量大

开发平台流水线+K8S平台

代码管理平台打包，制作镜像，kubernetes编排管理docker容器、负载均衡，这个时期将运维和开中间的问题解决了很大一部分，主要归功于虚拟化容器平台，省去了繁琐的配置，不用双方来回甩锅，也不用为了一个小小的低级问题去排查半天，从某一方面极大的提升了生产力

具体操作：

  • 平台侧程序打包
  • 集成dockerfile构建镜像，上传至镜像仓库
  • 运行docker容器
    优点：开发侧和运维侧的清晰划分，省去细节配置，避免低级问题，平滑扩容
    缺点：维护工作量大，开发侧需考虑更多部署策略

个人看法

没有最好的，只有最合适的

一个服务就部署一次，那就手动发

一个团队做个服务频繁走测试，那就jenkins

一个服务要在不同的时间节点扛住不同的压力，或者要明确划分开发运维体系，那就k8s

本文转载自: 掘金

开发者博客 – 和开发相关的 这里全都有

0%