Docker Desktop 设置网络代理

前言 最近遇到 Docker Desktop 构建 node 项目时,由于网络问题导致的构建失败问题,本文将介绍两个给 Docker Desktop 设置网络代理的方法。 修改 WSL2 配置 为了测试代理的效果,这里创建一个go服务,代码很简单,就是访问 https://www.google.com/ 并返回结果。如果能正常访问,说明代理设置成功。 package main import "net/http" func main() { resp, err := http.Get("https://www.google.com/") if err != nil { panic(err) } defer resp.Body.Close() println(resp.Status) } 第一种方法是修改 WSL2 的配置,在 windows C:\Users<your_username> 目录下创建 .wslconfig 文件,输入以下内容: [experimental] autoMemoryReclaim=gradual networkingMode=mirrored dnsTunneling=true firewall=true autoProxy=true 然后重启 WSL: wsl --shutdown networkingMode 为mirrored 表示网络模式使用镜像模式,会镜像宿主机的网络设置,能更好的集成宿主机和WSL的网络。 autoProxy 开启了自动代理的功能,意味 WSL 自动配置代理设置。 配置好,我们构建 Docker 镜像,运行: 可以看到代理成功生效,可以正常访问。 接下来介绍通过修改 Docker Desktop 的配置文件,设置代理。 修改 Docker Desktop 配置 打开 Docker Desktop 的设置,找到 Resources Proxies 选项,设置代理。 ...

九月 21, 2024 · overstarry

docker init 命令

前言 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文件: # syntax=docker/dockerfile:1 # Comments are provided throughout this file to help you get started. # If you need more help, visit the Dockerfile reference guide at # https://docs.docker.com/go/dockerfile-reference/ # Want to help us make this template better? Share your feedback here: https://forms.gle/ybq9Krt8jtBL3iCk7 ################################################################################ # Create a stage for building the application. ARG GO_VERSION=1.21.0 FROM --platform=$BUILDPLATFORM golang:${GO_VERSION} AS build WORKDIR /src # Download dependencies as a separate step to take advantage of Docker's caching. # Leverage a cache mount to /go/pkg/mod/ to speed up subsequent builds. # Leverage bind mounts to go.sum and go.mod to avoid having to copy them into # the container. RUN --mount=type=cache,target=/go/pkg/mod/ \ --mount=type=bind,source=go.sum,target=go.sum \ --mount=type=bind,source=go.mod,target=go.mod \ go mod download -x # This is the architecture you’re building for, which is passed in by the builder. # Placing it here allows the previous steps to be cached across architectures. ARG TARGETARCH # Build the application. # Leverage a cache mount to /go/pkg/mod/ to speed up subsequent builds. # Leverage a bind mount to the current directory to avoid having to copy the # source code into the container. RUN --mount=type=cache,target=/go/pkg/mod/ \ --mount=type=bind,target=. \ CGO_ENABLED=0 GOARCH=$TARGETARCH go build -o /bin/server ./retry/server ################################################################################ # Create a new stage for running the application that contains the minimal # runtime dependencies for the application. This often uses a different base # image from the build stage where the necessary files are copied from the build # stage. # # The example below uses the alpine image as the foundation for running the app. # By specifying the "latest" tag, it will also use whatever happens to be the # most recent version of that image when you build your Dockerfile. If # reproducability is important, consider using a versioned tag # (e.g., alpine:3.17.2) or SHA (e.g., alpine@sha256:c41ab5c992deb4fe7e5da09f67a8804a46bd0592bfdf0b1847dde0e0889d2bff). FROM alpine:latest AS final # Install any runtime dependencies that are needed to run your application. # Leverage a cache mount to /var/cache/apk/ to speed up subsequent builds. RUN --mount=type=cache,target=/var/cache/apk \ apk --update add \ ca-certificates \ tzdata \ && \ update-ca-certificates # Create a non-privileged user that the app will run under. # See https://docs.docker.com/go/dockerfile-user-best-practices/ ARG UID=10001 RUN adduser \ --disabled-password \ --gecos "" \ --home "/nonexistent" \ --shell "/sbin/nologin" \ --no-create-home \ --uid "${UID}" \ appuser USER appuser # Copy the executable from the "build" stage. COPY --from=build /bin/server /bin/ # Expose the port that the application listens on. EXPOSE 9000 # What the container should run when it is started. ENTRYPOINT [ "/bin/server" ] 可以看到 Dockerfile 是一个常见的多阶段构建镜像流程。 ...

四月 13, 2024 · overstarry

Containerd本地调试环境搭建

最近在学习常用的容器运行时 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 构建 进入源代码根目录,执行一下命令: cd containerd make 执行后,会在 ./bin/ 目录下生成所有项目的二进制文件。 如果你需要修改 gRPC API ,修改后需要使用 protoc 编译生成新的代码: make generate docker 容器构建 接下来讲解怎么通过 docker 构建本地 containerd 调试环境。 构建要求 1 go1.19.x及以上版本 2 Protoc 3.x+ 3 docker 构建 进入源代码根目录 cd containerd, 执行以下命令: docker run -it -v ${PWD}/containerd:/go/src/github.com/containerd/containerd -e GOPATH=/go -w /go/src/github.com/containerd/containerd golang:1.19 make && make install 这将会进行 containerd 的构建,过了一会发现构建失败,错误信息如下: ...

二月 19, 2023 · overstarry

容器出现时间异常问题及解决方法

问题 最近在使用 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 在网上查看了许多相关的问题,有了一个针对容器的解决方法,执行: docker run --rm --privileged alpine hwclock -s 可以看到容器时间已经正常了: 我对这条命令不太明白,不明白为什么会影响到其它运行中的容器, 可能是与 docker for win 的一些容器实现机制相关。 ...

十一月 12, 2021 · overstarry

Docker_grafana启动失败

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 没有启动成功, 删除此行,顺利启动。

八月 12, 2021 · overstarry