DevOps

在 WSL2 环境中 clone 一个很大的 git 项目，不走代理速度很慢，所以研究了一下怎么让 WSL2 走 Windows 的代理客户端。 WSL1 和 WSL2 网络的区别 在 WSL1 时代，由于 Linux 子系统和 Windows 共享了网络端口，所以访问 Windows 的代理非常简单。例如 Windows 的代理客户端监听了 8000 端口，那么只需要在 Linux 子系统中执行如下命令，就可以让当前 session 中的请求通过代理访问互联网。 export ALL_PROXY="http://127.0.0.1:8000" 但是 WSL2 基于 Hyper-V 运行，导致 Linux 子系统和 Windows 在网络上是两台各自独立的机器，从 Linux 子系统访问 Windows 首先需要找到 Windows 的 IP。 配置 WSL2 访问 Windows 上的代理 有两个关键步骤： WSL2 中配置的代理要指向 Windows 的 IP； Windows 上的代理客户端需要允许来自本地局域网的请求； 由于 Linux 子系统也是通过 Windows 访问网络，所以 Linux 子系统中的网关指向的是 Windows，DNS 服务器指向的也是 Windows，基于这两个特性，我们可以将 Windows 的 IP 读取出来。 ...

为什么要使用 Windows 做开发 一直以来 macOS 以类 unix 的特性，获得了程序员的青睐，但是近几年 Apple 在硬件领域少有让人耳目一新的产品，加上取消 Esc、使用蝶式键盘、基本为 0 的硬件可升级性、系统权限的收紧等骚操作，让 Mac 从软件到硬件都不如以前适合编程。另一方面，PC 阵营在软件层面保持开放的基础上，硬件体验也逐步赶上甚至超越 Mac，我也不想在用 Mac 做开发，用 PC 玩游戏，希望用一台电脑兼顾游戏和开发，所以选择回到了 PC 阵营。 随着微软拥抱开源领域，Windows 也开始变得程序员友好。Windows 10 2004 发布后，WSL2 也可以在正式版 Windows 10 中使用，相比于 macOS，WSL2 是一个原生 Linux 环境而非类 unix 环境，甚至可以在 App 商店中选择所需要的发行版。而相比于 WSL1，WSL2 采用了 HyperV 虚拟机的方式，解决了 WSL1 不能安装 Docker 等问题。 WSL1 和 WSL2 相比于 WSL1，WSL2 通过虚拟机的方式带来了更完整的 Linux 内核，但这种方式也引入了一些问题，微软给出了下面的图表来展示这些不同： WSL2 不能和 VMWarework Station、VirtualBox 同时运行这一条已经过时了，VirtualBox 和 VMWare Workstation 都发布了支持 WSL2 和 Hyper-V 的新版。 ...

问题现象 在制作 docker 镜像时，有复制某一个路径下所有文件和文件夹到镜像的需求，写下了如下 dockerfile： FROM alpine WORKDIR /root/test_docker_proj COPY * ./ 原始目录结构是这样的： /projects/test_docker_proj ├── Dockerfile ├── dir1 │ ├── dir11 │ │ └── file11 │ └── file1 └── file2 然而复制到 docker 镜像里的目录结构变成了这样： /root/test_docker_proj ├── Dockerfile ├── dir11 │ └── file11 ├── file1 └── file2 可以看到 dir1 这个文件夹并没有被复制到镜像里，但是 dir1 中的子文件夹和文件都被复制进来了，和 dir1 同级的文件也被复制了。也就是说，在 COPY 执行的过程中，第一层文件夹被「解包」了。 COPY/ADD 行为逻辑 为了确定 COPY 和相似的 ADD 命令的行为，做了以下测试： FROM alpine WORKDIR /root/test_docker_proj_1 COPY * ./ WORKDIR /root/test_docker_proj_2 ADD * ./ WORKDIR /root/test_docker_proj_3 COPY ./ ./ WORKDIR /root/test_docker_proj_4 ADD ./ ./ WORKDIR /root/test_docker_proj_5 COPY ./dir* ./ WORKDIR /root/test_docker_proj_6 ADD ./dir* ./ 通过测试可以发现 COPY/ADD 命令有这么几个规则： ...

问题描述 在使用 docker build 打包镜像时，遇到了需要使用代理访问网络的需求。使用如下的 Dockerfile 来模拟这个场景： FROM golang:1.12 RUN curl www.google.com --max-time 3 国内一般网络环境下，curl www.google.com 是无法正常返回的，加入 –max-time 让 curl 的耗时不要太长。 配置 http_proxy 变量 首先需要在环境变量中设置 http_proxy 和 https_proxy，使得访问网络的命令（这里使用 curl 来代表）能够通过环境变量中配置的代理服务器访问 www.google.com。 docker build 命令虽然是在 docker 所在的宿主机上执行的，看上去像是直接使用了宿主机的网络环境，但实际上 docker build 也是启动了一个 container 进行构建，所以在构建过程中的所有命令都是在 container 中执行的，http_proxy 和 https_proxy 的配置也应该是在 container 中进行的。可以使用 ENV 来配置 container 中的环境变量。 代理服务器启动在宿主机的 1087 端口上，修改 dockerfile 文件： FROM golang:1.12 ENV http_proxy "http://127.0.0.1:1087" ENV HTTP_PROXY "http://127.0.0.1:1087" ENV https_proxy "http://127.0.0.1:1087" ENV HTTPS_PROXY "http://127.0.0.1:1087" RUN curl www.google.com --max-time 3 重新执行 docker build 会发现 curl 依旧无法访问 www.google.com，从报错信息上可以看到 127.0.0.1 上的 1087 端口上并没有服务。 ...

关于 count 函数的使用一直存在争议，尤其是在 MySQL 中，作为流行度越来越高的 PostgreSQL 是否也有类似的问题呢，我们通过实践来理解一下 PostgreSQL 中 count 函数的行为。 构建测试数据库 创建测试数据库，并创建测试表。测试表中有自增 ID、创建时间、内容三个字段，自增 ID 字段是主键。 create database performance_test; create table test_tbl (id serial primary key, created_at timestamp, content varchar(512)); 生成测试数据 使用 generate_series 函数生成自增 ID，使用 now() 函数生成 created_at 列，对于 content 列，使用了 repeat(md5(random()::text), 10) 生成 10 个 32 位长度的 md5 字符串。使用下列语句，插入 1000w 条记录用于测试。 performance_test=# insert into test_tbl select generate_series(1,10000000),now(),repeat(md5(random()::text),10); INSERT 0 10000000 Time: 212184.223 ms (03:32.184) 由 count 语句引发的思考 默认情况下 PostgreSQL 不开启 SQL 执行时间的显示，所以需要手动开启一下，方便后面的测试对比。 \timing on count(*) 和 count(1) 的性能区别是经常被讨论的问题，分别使用 count(*) 和 count(1) 执行一次查询。 ...