Category: Docker

在信息化时代，传统的家谱记录方式（如纸质、Excel 文档）逐渐暴露出诸多问题：数据不结构化、难以查询、共享不便、易丢失。为了实现家谱数据的长期存储、结构化管理以及代际传承，选择一个稳定、开源、可自托管的家谱管理系统显得尤为重要。 为什么选择 Webtrees？ Webtrees 是一款专为家谱管理设计的开源应用，具备以下优势： 这些特性使得 Webtrees 成为构建“可传承家谱系统”的理想选择。 Docker 化部署：零污染、易迁移、长期运行 为了避免在主系统中安装 PHP、数据库等依赖，Webtrees 可以通过 Docker 容器快速部署。此方法可实现环境隔离、版本控制、轻松备份，是当前最推荐的部署方式。 项目结构说明 建议在主目录下创建如下结构： webtrees/├── docker-compose.yml├── webtrees-data/ # 存储 Webtrees 配置、媒体文件└── db-data/ # 存储 MariaDB 数据库数据 docker-compose.yml 示例 version: ‘3.8’services: webtrees: image: webtrees/webtrees:latest ports: – “8080:80” volumes: – ./webtrees-data:/var/www/html/data environment: – WT_DB_HOST=db – WT_DB_PORT=3306 – WT_DB_NAME=webtrees …

本文介绍如何使用 Docker 和 Docker Compose，快速部署一个基于 React Three Fiber 构建的交互式 3D 太阳系模拟器。该项目适用于展示、教学或个人网站嵌入。 🧱 项目简介 该可视化项目采用以下技术栈： 🐳 部署步骤 1. 克隆项目代码 git clone https://github.com/<用户名>/solar_system.gitcd solar_system 2. 创建 Dockerfile # 构建阶段FROM node:18-alpine AS builderWORKDIR /appCOPY . .RUN npm installRUN npm run build# 生产部署阶段FROM nginx:alpineCOPY –from=builder /app/dist /usr/share/nginx/htmlCOPY nginx.conf /etc/nginx/conf.d/default.confEXPOSE 80CMD [“nginx”, “-g”, “daemon off;”] …

在容器化部署和运维过程中，许多用户最初会使用 docker run 命令快速启动服务。然而，随着服务数量增多、配置复杂化，这种方式逐渐显现出诸多局限，例如管理分散、配置难以集中备份、迁移麻烦等问题。 为了提升长期可维护性与安全性，近期完成了一次全面架构优化：将所有容器从 docker run 切换到 docker-compose 管理，以下为思路与实践总结。 🟢 原有容器情况 原系统中共运行约 28 个容器，覆盖 7 个主要业务应用（stack），例如以下示例服务： 部分服务最初通过 docker run 手动启动，虽然方便，但长期来看容易导致配置不一致、维护难度增大。 💡 切换至 Compose 管理的思路 ✅ 推荐方案 对于这些服务，最终选择了「重新整理 Compose 文件」的方式（官方推荐），核心步骤如下： 1️⃣ 为每个服务重新编写或整理对应的 docker-compose.yml 文件，清晰记录端口、卷挂载、环境变量、网络配置等所有细节。 2️⃣ 将 Compose 文件集中保存（如放入版本控制仓库或私有同步盘），方便后期维护、审计及灾备。 3️⃣ 使用 docker-compose up -d 管理服务生命周期，实现一键部署和统一启动。 ⚠️ 注意事项 🛡️ Portainer 的角色 此次优化中，Portainer …

本指南适用于以下部署架构： 🧠 适用场景 你当前使用的是： ✅ 一、概览：更换域名时涉及的内容 项目 是否必须修改 说明 Mailcow 配置文件 ✅ 内部逻辑引用主机名，需更新 DNS 记录 ✅ 通知全球邮件系统指向新服务器 反向代理配置 ✅ 更换域名入口访问路径 邮箱地址使用的域名 ❌（可选） 可继续使用旧域名或添加新域名 Mailcow 的数据卷 ❌ 保留原样，邮件和设置不受影响 Docker 容器结构 ❌ 无需更改 🔧 二、操作步骤 1. 修改 Mailcow 配置文件 打开 Mailcow 安装目录下的配置文件（如 /opt/mailcow/mailcow.conf），找到并修改以下行： iniCopyEditMAILCOW_HOSTNAME=mail.old-domain.com 改为： iniCopyEditMAILCOW_HOSTNAME=mail.new-domain.com ⚠️ 该设置影响系统识别主机、SOGo 链接生成、邮件头部显示等，必须修改。 2. 修改反向代理（Nginx 等） …

许多站长或技术爱好者部署 Mailcow 邮件服务器后，往往会有这样的需求： 我是否可以在一台服务器上同时托管多个邮箱域名，比如 user@domain.com 和 admin@abc.com？ 答案是肯定的。Mailcow 完全支持“一套服务，多域名共用”的架构。本文将从 原理、配置方法、DNS 设置 等角度详细介绍。 ✉️ 一、理解邮箱域名与服务器域名的区别 在 Web 系统中，一个域名通常绑定一个网站。但在邮件系统中，邮箱的域名（@后面的部分）和服务器实际绑定的域名可以是不同的。 比如： 这两者之间的关联，完全靠 DNS 中的 MX 记录 来建立。 🧠 二、工作原理解析：邮件是如何投递的？ 当其他服务器向 user@abc.com 发送邮件时，流程如下： ✅ 由此可见，邮件通信靠的是 DNS 中的 MX 路由，而不是服务器的主机名或 HTTPS 域名！ 🛠️ 三、Mailcow 多域名部署方法 步骤 1：添加多个域名到 Mailcow 登录 Mailcow 管理后台： 步骤 2：为每个域名添加邮箱账户 即可创建如 admin@abc.com、info@xyz.org …

Portainer 是一个轻量级的图形化 Docker 管理面板，适用于个人服务器管理、容器项目可视化操作、多服务部署维护等场景。本文记录了使用 Docker Compose 安装 Portainer CE 的完整流程，并通过 Nginx + FRP 实现公网安全访问。 🧱 系统结构概览 访问链路为： ✅ 步骤一：在内网主机上部署 Portainer（Host A） 创建目录： 编写 docker-compose.yml 文件： 启动服务： ✅ 步骤二：Nginx 反向代理配置（Host B） 在 Nginx 中添加如下配置（监听代理端口，转发至 Host A）： ✅ 步骤三：FRP 穿透配置（VPS + Host B） VPS 上 FRPS 配置（已有可跳过）： 确保已开放指定端口，并配置好 frps.ini Host B 上 …

🌍 一、系统架构概览 本架构实现了一个内网部署 + 反向代理 + 公网穿透 + 统一认证的视频会议系统，支持与 Rocket.Chat 集成： cssCopyEdit[Jitsi 主机] └─ 使用 docker-compose 部署 Jitsi Meet 各服务（web, jvb, prosody, jicofo） [反向代理主机] └─ Nginx 启用 HTTPS 并将请求转发至 Jitsi 内网地址 [公网入口 VPS] └─ FRP 映射 443 → 反代主机，公网访问统一通过域名入口 🧱 二、环境信息（匿名化） 项目 内容 Jitsi 服务主机 局域网服务器 A 反向代理主机 局域网服务器 B …

Docker 作为当今容器技术的代表，在现代软件开发和运维中发挥着重要作用。本文将从应用场景、架构原理、安全性以及与 Kubernetes 的关系四个方面，对 Docker 技术进行全面综述。 应用场景 Docker 提供了轻量级的容器化环境，在以下场景中得到广泛应用： 架构原理 Docker 采用客户端-服务端架构，利用操作系统的虚拟化特性来实现容器的构建和运行。其核心组成和工作机制包括： Docker架构核心组件： Docker 的工作机制： 安全性 容器安全是 Docker 技术的重要考量点。由于容器共享宿主内核，在带来性能优势的同时也提出了独特的安全挑战。下面从隔离机制、网络、安全配置等方面探讨 Docker 的安全模型与注意事项： Docker 与 Kubernetes 的关系 Docker 与 Kubernetes 在容器生态中密不可分。Kubernetes（K8s）是容器编排系统，本身并不负责构建镜像，而是负责调度和管理容器的运行。两者的关系和演变可以从以下几个方面理解： 总的来说，Docker 与 Kubernetes 是容器生态系统中互补的技术：Docker 更侧重于容器打包和开发时的便利性，而 Kubernetes 专注于容器的编排调度和集群管理。即使 Kubernetes 不再直接调用 Docker 引擎，Docker 在镜像制作、开发测试中的价值依然不可替代。现代的云原生开发流程往往是：开发者本地用 Docker 容器构建并测试应用，然后将镜像交给 Kubernetes 部署到大规模集群上运行。两者相结合，极大地提高了应用从开发到上线的效率和一致性。可以预见，在未来的容器化基础设施中，Docker 仍将作为重要的构建与发行工具存在，而 Kubernetes 将持续作为运行时代管，协同推动云原生技术的发展。

https://blog.csdn.net/txpp520/article/details/104820736/ Docker 的优点很多，比如： 1、一体化——将操作系统、库版本、配置文件、应用程序等全部打包装在容器里。从而保证 QA 所测试的镜像 (image) 会携带同样的行为到达生产环境。 2、轻量——内存占用极小，只为主要过程分配内存。 3、快读——一键启动，就像启动常见的 linux 过程一样快。 尽管如此，众多用户仍然只是把容器当做常见的虚拟机，而忘记了容器的一个重要特性： 正因为这一特点，一些用户需要改变他们对容器的观念，为了更好的使用与发挥 Docker 容器的价值，有一些事情是绝对不应该做的： 1.不要在容器（container）中存储数据 容器可能会被中断、被替换或遭到破坏。在容器中运行的 1.0 版应用程序很容易就会被 1.1 版取代，而不会对数据造成影响或导致数据丢失。因此，如果需要存储数据，请存储在卷 (volume) 中。在这一情况下，还应注意两个容器是否会在同一个卷上写入数据，这将导致损坏。请确保应用程序适用于写入共享的数据存储。 2. 不要分两部分传送应用程序 有些人把容器当作虚拟机 所以他们大多会认为，应该将应用程序部署到现有正在运行的容器中。在需要不断部署和调试的开发阶段，可能确实如此；但对于 QA 和生产的持续交付 (CD) 渠道，应用程序应当是镜像的一部分。切记：容器转瞬即逝。 3. 不要创建大尺寸镜像 大尺寸的镜像难以分配。请确保仅使用必需文件和库来运行应用程序。不要安装不必要的数据包，也不要运行“更新”(yum update)，这些操作会把大量文件下载到新的镜像层。 4. 不要使用单层镜像 为了有效利用多层文件系统，请始终为操作系统创建属于自己的基本镜像层，然后为用户名定义创建一个层，为运行时安装创建一个层，为配置创建一个层，最后再为应用程序创建一个层。这样，重新创建、管理和分配镜像就会容易些。 5. 不要从正在运行的容器中创建镜像 换句话说，不要使用”docker commit”命令来创建镜像。这一镜像创建方法不可复制，因此应完全避免使用。请始终使用 Dockerfile 或其他任何可完全复制的 S21（从源代码到镜像）方法，如此一来，如果存储在源代码控制存储库 (GIT) 中，就可以跟踪 Dockerfile 的变更情况。 …

使用docker的mysql镜像 环境 macOS 10.13.2 ​ docker 17.12.0 ​ mysql镜像版本 5.7.21 确保docker运行 安装mysql镜像 到官网查看mysql镜像相关信息，使用docker指令pull安装 docker pull mysql:5.7.21 1 使用docker指令images查看是否安装成功 [1] 初次运行镜像 docker run –name mysql.5.7.21 -p 3306:3306 -e MYSQL_ROOT_PASSWORD=Nzy19970502 -d mysql:5.7.21 1 ​ —name 为设置容器的名字，我设置为mysql.5.7.21 ​ -p 端口映射 ​ -e 为设置执行时的环境变量，在这里我设置mysql的root密码，相关变量可参考官网 ​ -d 为设置镜像，镜像名:版本 完成后使用docker命令ps查看是否成功运行 docker ps 1 使用终端登录数据库 mysql -h …