运维日记一

最新推荐文章于 2024-01-04 17:59:10 发布

qq_40380475

最新推荐文章于 2024-01-04 17:59:10 发布

阅读量421

点赞数

文章标签：负载均衡运维

本文链接：https://blog.csdn.net/qq_40380475/article/details/109468955

版权

这篇运维日记详细记录了在微软云环境中使用Docker Compose部署服务，遇到的负载均衡问题以及解决之道。作者起初使用Nginx-Proxy进行负载均衡，但在多节点环境中遇到困难，最终转向Traefik以实现自动服务发现、热更新和多节点负载均衡。同时，文章还探讨了日志收集和监控系统的选型，如ELK、EFK、Fluentd、Filebeat、Loki和Prometheus+Grafana。

摘要由CSDN通过智能技术生成

运维日记一

前言

提示：这里记录一些工作时候遇到的一些坑，以及选择架构搭建时的考虑等等

一、基础环境

基础环境是微软云提供的，所以一些可能我认为是默认已安装的工具实际上普通创建的虚拟机要手动安装

以前部署服务的方式采取的是微服务 + DOCKER-COMPSOE 的方式来部署，就是利用 YAML 文件做规范。
那时候的负载均衡器用的是 nginx-proxy，基于 nginx 做的扩展，GITHUB 上的一个开源项目，对于单节点服务部署是比较友好的，支持热更新，自动服务发现，配合 letsencrypt 的一个组件，可以自动发布证书文件支持 HTTPS 访问方式，日志和监控都没有。
将服务的域名访问方式配置在 nginx-proxy 后端中的时候遇到了一些问题：
DOCEKRFILE 文件中如果指定了 expose 的端口，那么 nginx-proxy 的 virtualPort 就不能是其他的端口，否则会报上游服务 down 的错误。
这里我当时有一个误区，因为对于 DOCKER 方式运行的容器来说，容器之间的端口是都可以访问的，完全开放，所以如果 DOCKERFILE 中没有指定 expose 字段，那么应用运行时所在的端口可以直接指定为 nginx-proxy 的虚拟端口，但是如果 expose 端口被指定，比如说是 80 端口，那么应用运行的端口和虚拟端口都必须是 80&#