Docker

前言 Docker 是一个广受欢迎的开发平台，它允许用户通过容器化技术来构建、打包和部署应用程序。尽管 Docker 提供了强大的功能和灵活性，但对于初学者而言，在项目中配置 Docker 可能会遇到一些挑战。 不过，Docker 官方为了降低使用门槛，推出了一个便捷的命令docker init。这个命令旨在快速初始化 Docker 配置，从而简化将 Docker 集成到项目中的流程。通过使用这个命令，用户可以轻松地为项目设置必要的 Docker 支持，进而享受到 Docker 带来的便利和效率提升。 docker init 简介 docker init 命令会根据用户指定的选项生成运行容器的一些文件，极大的加快了项目的容器化: .dockerignore : docker 构建时忽略的文件列表 Dockerfile: 镜像的核心文件 Compose.yaml: docker compose 的配置文件 README.Docker.md 如果你的项目中已有以上文件，会让你选择是否覆盖旧文件避免文件冲突问题。 docker init 提供了一组项目的模板文件，包括了 Go、Python、ASP.NET Core等常见的服务器应用程序及一个其它类型应用程序模板。开发者使用 init 命令时，可以根据选择的模板生成相应的文件，使开发者可以快速的构建并启动容器。 使用 接下来介绍如何使用 docker init 进行项目容器的初始化，这里以前文的go项目为例子进行介绍。 进入项目根目录执行 init 命令,选择go模板,会让你选择使用的go版本,主程序的位置及应用所使用的端口: 执行完可以看到会生成相应的文件及如何构建并运行的命令。 查看生成的Dockerfile 和 Compose.yaml文件: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 # syntax=docker/dockerfile:1 # Comments are provided throughout this file to help you get started....

最近在学习常用的容器运行时 containerd, 本篇我就来介绍如何本地构建 containerd 进行调试开发，主要介绍2种 常规方式和使用容器构建，由于本地环境限制，我主要是使用 docker 搭建本地调试环境。 非容器 build 这里先开始介绍常规直接从源码本地构建的方式。 构建环境要求 1 go1.19.x及以上版本 2 Protoc 3.x+ 3 适用于您的发行版的 Btrfs 标头和库。请注意，可以通过构建标签禁用构建 btrfs 驱动程序no_btrfs，从而删除此依赖项。 前面2点相信大家都很清楚，第三点的 Btrfs 是什么呢？Btrfs是一种现代的Linux写时复制（COW）文件系统，旨在实现先进的功能，同时也注重容错、修复和简易管理。 build 1 拉取containerd 源代码至本地 2 构建 进入源代码根目录，执行一下命令: 1 2 cd containerd make 执行后，会在 ./bin/ 目录下生成所有项目的二进制文件。 如果你需要修改 gRPC API ,修改后需要使用 protoc 编译生成新的代码: make generate docker 容器构建 接下来讲解怎么通过 docker 构建本地 containerd 调试环境。 构建要求 1 go1.19.x及以上版本 2 Protoc 3.x+ 3 docker 构建 进入源代码根目录 cd containerd， 执行以下命令: 1 2 docker run -it -v ${PWD}/containerd:/go/src/github....

问题 最近在使用 MinIO SDK 上传资源对象时, 出现了一个问题: The difference between the request time and the server's time is too large. 从错误信息可以看出客户端上传资源的时间与 Minio server 的时间相差太大, 导致资源上传失败。 解决 根据错误信息得出 server 端的时间出现异常, 由于我采用容器部署的方式, 因此可以先查看容器的时间是否正确。 进入 Minio 容器 , 执行命令: date, 可以看到如图结果( UTC 时间): 而目前的时间是( CST 时间) : 可以看出容器的时间与实际的时间相差太大, 所以导致资源上传失败。 方法1 出现了时间异常的问题, 可能很多人第一反应就是调整容器的时间，通过 ntpdate 等工具调整时间, 这种解决方法方法适用于非容器的 MinIO SERVER 环境调整时间，容器因为一些限制无法使用此方法。 方法2 在网上查看了许多相关的问题，有了一个针对容器的解决方法，执行: 1 docker run --rm --privileged alpine hwclock -s 可以看到容器时间已经正常了: 我对这条命令不太明白，不明白为什么会影响到其它运行中的容器, 可能是与 docker for win 的一些容器实现机制相关。...

Docker grafana 启动失败 今天在使用 Docker 启动 grafana 的时候, 遇到了一个问题， 问题如图: 为什么会出现这个问题 根据错误日志的提示, 打开 http://docs.grafana.org/installation/docker/#migrate-to-v51-or-later 网址, 根据官方的描述，grafana Docker镜像在版本5.1及以后有了重大改变: * 在容器启动过程中不会改变文件的权限 * 默认用户ID由104 变为 472 * 删除了以下的隐式卷: * /var/lib/grafana * /etc/grafana * /var/log/grafana 解决 根据官方文档的提示，我仔细查看了我的 compose 文件， 发现我加了 user: ‘104’ , 应该是此行的原因导致 grafana 没有启动成功， 删除此行，顺利启动。

Nginx搭建静态图片资源服务器 本文介绍使用 Docker Nginx 搭建静态图片资源服务器的过程和搭建中间遇到的问题。 我使用 Docker compose 搭建静态图片资源服务器， 我使用的 compose 文件内容如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 version: '3.1' services: nginx: restart: always image: nginx container_name: asset ports: - 80:80 volumes: - ./nginx.conf:/etc/nginx/nginx.conf - ./uploads:/usr/share/nginx/uploads - ./conf.d:/etc/nginx/conf.d /srv/msg/storage/uploads:/usr/share/nginx/uploads 将本地的图片文件夹挂载到容器内的 /usr/share/nginx/uploads 文件夹 nginx.conf 是 Nginx 的主配置文件， conf.d 是各个网站配置的文件夹。 我的 nginx.conf 内容如下: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 user nginx; worker_processes 1; error_log /var/log/nginx/error....