本篇文章分享Docker学习笔记:后端、数据库和反向代理怎么一起跑起来，对你有帮助的话记得收藏一下，看极客资料网收获更多编程知识

Docker学习笔记:后端、数据库和反向代理怎么一起跑起来

好家伙,

这次我们来系统梳理一下 Docker.

之前我对 Docker 的理解比较散:

知道它能部署项目
知道它有镜像和容器
知道 docker compose 可以一起启动多个服务

但真正把一个 Go 后端服务,PostgreSQL 数据库,Nginx 反向代理放到一起思考时,才发现 Docker 不是单纯的"启动工具".

它更像是把一个系统的运行环境,依赖关系,启动方式,网络关系,统一整理成一套可以重复执行的部署方案.

这篇文章就从一个后端项目部署的角度,把 Docker 里的几个核心概念串起来.

0.背景:为什么会有多系统协作问题

先看一个最常见的后端项目.

它看起来好像只是一个服务:

Go API 服务

但真正部署时,它往往不是单独存在的.

它还需要:

1. 数据库,比如 PostgreSQL
2. 反向代理,比如 Nginx
3. 环境变量,比如数据库密码和 token
4. 端口映射,比如本机 18088 对应容器里的 8080
5. 数据持久化,比如数据库数据不能随着容器删除一起丢
6. 服务网络,比如 API 容器怎么访问数据库容器

也就是说,一个后端系统真正跑起来时,更像这样:

用户
  -> Nginx
  -> Go API
  -> PostgreSQL

这个时候问题来了:

如果我手动部署,我要在服务器上做很多事:

安装 Go
安装 PostgreSQL
配置数据库账号
配置 Nginx
配置环境变量
启动后端进程
处理端口冲突
处理日志
处理重启

这套东西在我的电脑上能跑,不代表在服务器上也能跑.

甚至今天能跑,下个月换一台机器,可能又要重新踩一遍坑.

所以 Docker 要解决的核心问题不是"让命令变短".

而是:

让应用和运行环境一起被描述,一起被交付,一起被启动.

这就是 Docker 对部署最有价值的地方.

1.Docker介绍:它到底解决什么问题

我现在对 Docker 的理解是:

Docker 是一个应用打包和运行环境管理工具.

它可以把应用运行需要的东西放到一个相对独立的环境里.

比如一个 Go 后端服务需要:

Linux 运行环境
编译好的二进制文件
配置文件
环境变量
端口
启动命令

这些东西可以通过 Dockerfile 和 compose 文件描述出来.

这样别人拿到项目时,不需要问:

你本机 Go 版本是多少?
数据库怎么装?
端口怎么配?
服务怎么启动?

而是直接:

docker compose up -d --build

当然,Docker 不是虚拟机.

它不是在你的电脑里完整模拟一台新电脑.

更准确一点说,Docker 是让进程运行在隔离的容器环境里.

这个隔离环境里有自己的文件系统,网络,环境变量和启动命令.

所以我们会经常看到这些关键词:

Dockerfile
image 镜像
container 容器
volume 数据卷
network 网络
compose 多服务编排

这些词刚开始看起来多,但其实可以按一个流程理解:

Dockerfile 写打包规则
  -> build 出镜像
  -> run 出容器
  -> volume 保存数据
  -> network 连接服务
  -> compose 管理一组服务

2.镜像:什么是镜像

镜像这个词一开始很容易听懵.

我觉得可以这样理解:

镜像 = 打包好的运行模板

它还不是正在运行的程序.

它只是一个模板.

比如:

postgres:16-alpine

这是 PostgreSQL 官方提供的数据库镜像.

你用它启动一个容器,才会真正跑出一个 PostgreSQL 数据库进程.

再比如:

tsu_engine-api:latest

这是我们自己构建出来的后端服务镜像.

它里面可能包含:

1. 一个 Linux 运行环境
2. 一个编译好的 Go 可执行文件
3. 一些运行需要的配置
4. 一个默认启动命令

我们可以用一句话串起来:

Dockerfile = 打包说明书
镜像 = 按说明书打出来的运行模板
容器 = 镜像启动后的真实进程

2.1 基础镜像和业务镜像

镜像还可以分成两类理解.

第一类是基础镜像:

golang:1.24.5-bookworm
alpine:3.20
postgres:16-alpine
nginx:alpine

第二类是业务镜像:

tsu_engine-api:latest

基础镜像是别人提供的运行环境.

业务镜像是我们基于基础镜像,把自己的代码打进去以后得到的镜像.

2.2 Go项目为什么适合多阶段构建

Go 项目有一个很适合 Docker 部署的特点:

可以编译成一个二进制文件.

所以 Dockerfile 可以分成两个阶段.

第一阶段用 Go 镜像编译:

FROM golang:1.24.5-bookworm AS build

WORKDIR /src

ENV GOPROXY=https://goproxy.cn,direct
ENV GOSUMDB=sum.golang.google.cn

COPY go.mod go.sum ./
RUN go mod download

COPY . .
RUN CGO_ENABLED=0 GOOS=linux go build -o /out/tsu-server ./cmd/server

第二阶段用更小的运行镜像:

FROM alpine:3.20

WORKDIR /app
COPY --from=build /out/tsu-server /app/tsu-server

EXPOSE 8080
CMD ["/app/tsu-server"]

这么做的好处是:

构建阶段需要 Go
运行阶段不需要 Go

所以服务器最终运行时,不需要安装 Go,也不需要保留编译工具链.

它只需要运行最终镜像里的二进制文件.

3.容器:什么是容器

镜像是模板.

容器是镜像真正运行起来后的实例.

比如:

docker run postgres:16-alpine

这时启动出来的那个 PostgreSQL 进程,就是容器里的进程.

一个镜像可以启动多个容器.

就像一个类可以 new 多个对象.

postgres:16-alpine 镜像
  -> postgres-1 容器
  -> postgres-2 容器

当然,数据库这种东西一般不会乱开多个,这里只是为了说明镜像和容器的关系.

3.1 容器可以删,数据不能乱丢

容器本身应该是可以删除重建的.

比如后端服务升级:

删掉旧容器
用新镜像启动新容器

这很正常.

但数据库数据不能随着容器一起消失.

所以数据库通常要配 volume.

可以理解成:

容器 = 运行进程
volume = 容器外面保存数据的地方

如果 PostgreSQL 的数据目录挂到了 volume,那么容器删了再建,数据还在.

这就是数据持久化.

4.Docker具体使用:配置文件怎么写

单个服务可以用 docker run.

但只要出现后端 + 数据库,我就更倾向用 Docker Compose.

因为 Docker Compose 可以把多个服务写在一个文件里.

比如一个简化版:

services:
  api:
    image: tsu_engine-api:latest
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "18088:8080"
    environment:
      TSU_MONITOR_POSTGRES_HOST: postgres
      TSU_MONITOR_POSTGRES_PORT: "5432"
      TSU_MONITOR_POSTGRES_DB: tsu_monitor
      TSU_MONITOR_POSTGRES_USER: tsu_user
      TSU_MONITOR_POSTGRES_PASSWORD: ${TSU_MONITOR_POSTGRES_PASSWORD}
      BATTLE_MONITOR_ADMIN_TOKEN: ${BATTLE_MONITOR_ADMIN_TOKEN}
    depends_on:
      - postgres

  postgres:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: tsu_monitor
      POSTGRES_USER: tsu_user
      POSTGRES_PASSWORD: ${TSU_MONITOR_POSTGRES_PASSWORD}
    volumes:
      - postgres-data:/var/lib/postgresql/data

volumes:
  postgres-data:

这里面几个配置特别重要.

4.1 ports

ports:
  - "18088:8080"

意思是:

宿主机 18088 端口 -> 容器内 8080 端口

所以本机访问:

http://127.0.0.1:18088

实际会打到 API 容器里的 8080.

4.2 environment

环境变量是容器运行时配置.

比如数据库密码,token,运行环境,端口,都适合放这里.

但这里要注意:

不要把生产密码直接写死到 compose 文件里.

更好的方式是通过 .env 或服务器环境变量传入.

例如:

TSU_MONITOR_POSTGRES_PASSWORD=强密码
BATTLE_MONITOR_ADMIN_TOKEN=强token

4.3 depends_on

depends_on:
  - postgres

它表示 API 服务依赖 postgres 服务.

但这里要注意:

depends_on 只能保证启动顺序,不一定保证数据库已经完全准备好.

所以后端连接数据库时,最好自己有重试逻辑,或者 compose 里再加 healthcheck.

5.数据库怎么配置

数据库是部署里最不能随便的部分.

后端容器可以删了重建.

数据库数据不能说没就没.

5.1 PostgreSQL为什么也放进Compose

把 PostgreSQL 放进 Compose 有几个好处:

1. 本地一条命令就能启动完整后端环境
2. API 和数据库自动在同一个 Docker 网络里
3. 数据库账号,库名,密码可以统一管理
4. 数据目录可以通过 volume 持久化

这样本地调试时就不需要手动安装 PostgreSQL.

直接:

docker compose up -d

API 和数据库一起起来.

5.2 API容器怎么访问数据库

这里有一个很容易踩的坑.

在 Docker Compose 网络里,API 容器不要访问:

localhost:5432

因为对 API 容器来说,localhost 是它自己,不是 postgres 容器.

应该访问服务名:

postgres:5432

所以后端数据库配置应该类似:

TSU_MONITOR_POSTGRES_HOST=postgres
TSU_MONITOR_POSTGRES_PORT=5432

这个 postgres 就是 compose 文件里的服务名.

5.3 数据库端口要不要暴露

本地开发时,有时候为了方便连接数据库,会写:

ports:
  - "5432:5432"

但生产环境要谨慎.

如果没有必要,PostgreSQL 不要直接暴露到公网.

更合理的方式是:

API 容器通过 Docker 内部网络访问 PostgreSQL
外部用户只访问 Nginx

也就是说:

公网 -> Nginx -> API -> PostgreSQL

而不是:

公网 -> PostgreSQL

数据库直接暴露公网,风险太高.

6.反向代理怎么配置

后端服务本地跑在:

127.0.0.1:18088

生产环境一般不会让用户直接访问这个端口.

更常见的是用 Nginx 做入口.

结构大概是:

用户请求
  -> Nginx 80/443
  -> 127.0.0.1:18088
  -> Go API

Nginx 配置可以类似这样:

server {
    listen 80;
    server_name example.com;

    location /api/ {
        proxy_pass http://127.0.0.1:18088/api/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

这样用户访问:

http://example.com/api/health

Nginx 会转发到:

http://127.0.0.1:18088/api/health

这里 Nginx 负责对外入口.

Go API 只负责业务接口.

HTTPS,域名,证书,访问日志这些东西,后续也可以放在 Nginx 层统一处理.

7.从本地到服务器怎么走

本地跑通以后,服务器部署不建议搬"容器".

更推荐搬:

镜像 + compose 配置 + 环境变量

比如本地导出镜像:

docker save tsu_engine-api:latest -o tsu_engine-api.tar

上传服务器:

scp .\tsu_engine-api.tar root@服务器IP:/opt/tsu_engine/

服务器加载镜像:

cd /opt/tsu_engine
docker load -i tsu_engine-api.tar

然后准备:

docker-compose.yml
.env
nginx 配置

最后启动:

docker compose up -d

这个流程比较清晰.

本地负责构建.

服务器负责运行.

8.如何验证部署成功

部署不是容器显示 running 就结束了.

还要验证接口.

先测健康检查:

curl http://127.0.0.1:18088/api/health

期望返回:

{
  "engine": "tsu_engine v2",
  "status": "online"
}

再测监控接口:

curl -H "Authorization: Bearer local-monitor-token" http://127.0.0.1:18088/api/battle-monitor/status

如果返回里有:

{
  "enabled": true,
  "mode": "active",
  "schema_init": true
}

说明后端和 PostgreSQL 的链路基本通了.

这里我会重点看:

1. API 是否 online
2. 数据库 schema 是否初始化成功
3. 监控功能是否 enabled
4. Nginx 转发是否能访问到 /api/

9.总结

这次重新梳理 Docker,我觉得最重要的是把几个概念串起来.

Dockerfile 是打包说明书
镜像是运行模板
容器是运行实例
Compose 是多服务编排
Volume 是数据持久化
Nginx 是对外入口

如果只是单独记命令,很容易乱.

但如果从一个真实后端系统看,关系就很清楚:

用户
  -> Nginx
  -> Go API 容器
  -> PostgreSQL 容器
  -> volume 保存数据库数据

这次的收获:

1. Docker 解决的是环境一致性和部署可重复问题
2. 镜像不是容器,镜像只是模板
3. 容器可以删了重建,数据库数据要靠 volume 保存
4. API 容器访问数据库时,应该用 compose 服务名
5. 生产环境不要随便暴露 PostgreSQL 端口
6. Nginx 负责公网入口,后端服务专注业务接口

踩坑点也记一下:

1. Go 版本要和 go.mod 匹配
2. Docker Hub 拉镜像可能需要代理或镜像源
3. Go 下载依赖可能需要配置 GOPROXY
4. depends_on 不是数据库 ready 的保证
5. 本地默认 token 不要带到生产环境

最后一句话总结:

Docker 部署不是把一个程序塞进容器这么简单.

真正要理解的是:

多个系统如何被打包,配置,连接,启动,验证.

把这条链路跑通以后,后端部署这件事就会清晰很多.

文章来源:https://www.cnblogs.com/FatTiger4399/p/20046764
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！