月份：2020年9月

[已解决] golang go test 是遇到报错 call has possible formatting directive %v

golang 运行 go test 时 遇到报错 call has possible formatting directive %v 怎么解决

Println call has possible formatting directive %v

go test 中使用 fmt.Print(“%v”) 报错

问题

Println call has possible formatting directive %v

go test 中不能使用 fmt.PrintLn(“%v”, v)

解决否

已解决

方案

使用 fmt.Printf(“%+v”, v)

[待解决] gRPC 访问 Nginx 时 access_log nginx PRI * HTTP/2.0

gRPC 访问 Nginx 时 access_log nginx PRI * HTTP/2.0 怎么调整策略呢

nginx PRI * HTTP/2.0

问题

通过Nginx 代理 gRPC 服务，其他 client 通过 Nginx 访问后端服务时，后端的 gRPC服务没收到任何请求，发现access_log 是如下信息：

10.0.2.2 - - [24/Sep/2000:08:14:31 +0000] "PRI * HTTP/2.0" 400 173 "-" "-"

检查你的 nginx/conf.d/grpc_proxy.conf 是这样的：

server
{

    listen 443 ssl http2;
    server_name _;
    index index.php index.html index.htm;
    root  /usr/share/nginx/html/;

    ssl                     on;
    ssl_certificate         /etc/nginx/cert/server.pem;
    ssl_certificate_key     /etc/nginx/cert/server.key;
    ssl_session_timeout     5m;
    ssl_protocols           TLSv1.2;

    ssl_prefer_server_ciphers on;
    ssl_ciphers 'ECDHE-RSA-AES2...';

    location / {
        proxy_http_version  1.1;
        proxy_set_header    Upgrade $http_upgrade;
        proxy_set_header    Connection "keep-alive";
        proxy_set_header    X-Real-IP $remote_addr;

        if (!-f $request_filename) {
             proxy_pass http://127.0.0.1:8080;
        }
    }

解决否

已解决

方案

我估计你的证书没有被信任，你可以去掉证书试试， 调整后的 nginx/conf.d/grpc_proxy.conf 的配置如下

server
{
    listen 443 http2;

    root  /usr/share/nginx/html/;

    access_log  /var/log/nginx/access_grpc_proxy.log;
    error_log /var/log/nginx/error_grpc_proxy.log;

    location / {
        # Replace localhost:50051 with the address and port of your gRPC server
        # The 'grpc://' prefix is optional; unencrypted gRPC is the default

        # grpc_pass grpc://127.0.0.1:8080;
        proxy_pass http://127.0.0.1:8080;
    }
}

这里我们去掉了nginx的ssl封装。这样就好了。

client 证书

或者你检查下 gRPC client 是否使用了正确的证书，nginx 拦截了流量没到proxy端，估计就是请求认证有问题。

参考

  • https://www.nginx.com/blog/nginx-1-13-10-grpc/

记一次PHPStorm Xdebug Docker PHP 调试问题

记一次PHPStorm Xdebug Docker PHP 调试问题

背景

在这之前一直在用 Virtual Box 上的 Ubuntu v16.04.4 虚拟机在做测试环境，随着项目增加，12G硬盘大小的虚拟机会经常报磁盘已满，不断的删日志才能维持工作。于是我就想着再开一台虚拟机，硬盘设置个20G,(还是这么小气）。用的 ubuntu1 v16.04.10，（为啥不上ubuntu18，这个虚拟机软件太老装新系统，发现有性能问题，估计有指令不兼容问题）

我的是Mac环境，（之前也用过Windows）Virtual Box（后简称vbox），装好Ubuntu后，配置NAT网络，就开始装Docker软件，安装步骤是严格按照官网的步骤来的。
https://docs.docker.com/v17.09/engine/installation/linux/docker-ce/ubuntu/#install-using-the-repository

好吧，我承认我的环境有点非主流。这是有历史原因的。

开始造

安装好vbox、ocker，配置好Docker mirror，就开始用docker-compose 拉起测试环境。

Docker Remote API

开始在PHPStorm配置第二台Docker。这里遇到了很多次connection refused。我参考这为老哥的方法一，配置怎么都不生效。换第二个方案就好了。这是第一个坑。

将ubuntu那的 docker Daemon API 端口映射到Vbox nat网络上，我就不细讲了

得到Connection Successful的结果后。开始进行下一步。

PHPStorm php 运行环境

开始配置 PHP :: CLI Interpreter.

选择远程 Docker， Server 选择我们刚刚配置好的 server，在选择我们要调试的 php容器，（这个容器是在 php:7.1.21-cli-jessie 基础上构建的）。

然后就遇到这个问题：

 failed to parse validation script output

phpstorm_helper

当时出问题，没截图，这是网上找了个报错信息一样的图

通过搜索发现需要一个phpstorm_helper docker镜像。

于是在另外一台Ubuntu虚拟机上 docker save， 再到现在Ubuntu 上 docker import 搞定。

再点击刷新还是 failed to parse validation script output
然后，就又是在百度，谷歌，必应～～～
～～～

PHPStorm<->Docker 抓包

还是无果，去洗了下脸，想起网上有人用抓包定位这个问题。我这本地的PHPStorem和vbox里面的Docker Daemon通信就是用的tcp啊。

打开Wireshark，抓包。

通过抓包发现，PHPStorem 与 Docker 之间的请求就是：1.获取当前所有镜像，2.基于你选择的PHP镜像，来创建一个容器。3.运行容器，4.获取容器输出，5.删除容器。根据那一行红色的报错信息，我估计是在运行容器时，输出的内容不是phpstorm预期的，导致报错。由于最后一个操作是删除容器，我就不好调查这个创建的容器到底咋回事了。

于是就抓包，并模拟请求，在删除命令前止住。这样来调查这个创建的容器。

创建容器请求

转换为curl命令：

$ curl -X POST --header "Content-Type:application/json" http://127.0.0.1:52376/v1.24/containers/create -d '{"AttachStdin":true,"OpenStdin":true,"Env":["JETBRAINS_REMOTE_RUN=1"],"Cmd":["-dxdebug.remote_enable=0","/opt/.phpstorm_helpers/phpinfo.php"],"Entrypoint":["php"],"Image":"sha256:292111a5a867f13da8759d3388908b376cf455ecaece86785ea97e9b46f5255f","Volumes":{},"ExposedPorts":{},"HostConfig":{"Binds":["/Users/paulxu/Jumei/compose/portia/php/phpspider:/opt/project:rw"],"Links":[],"LogConfig":{"Type":null,"Config":null},"VolumesFrom":["abeb0f2ead37c672b838726ff9bef51bb1011235c8712dc687f7b7135610cbb2:rw"]}}'

这里的image的id是，作为PHP脚本运行的镜像的ID。

接触容器

对应curl命令：

$ curl -X POST --header "Content-Type:application/json" http://127.0.0.1:52376/v1.24/containers/f434099c2157c1a0cabea5131d9c2a5b8d809cc1e1289abcffb95eb7cf7fc4d0/attach?stdin=true&stdout=true&stderr=true&stream=true

这里的容器ID是上一个创建容器请求的返回值。

开始运行容器

curl 命令：

$ curl -X POST --header "Content-Type:application/json" http://127.0.0.1:52376/v1.24/containers/f434099c2157c1a0cabea5131d9c2a5b8d809cc1e1289abcffb95eb7cf7fc4d0/start

获取输出内容

转换为Curl命令：
curl -X POST –header “Content-Type:application/json” http://127.0.0.1:52376/v1.24/containers/f434099c2157c1a0cabea5131d9c2a5b8d809cc1e1289abcffb95eb7cf7fc4d0/wait

  • 我去看了下老环境的输出如下：

通过docker ps -a，找到通过api创建的容器

检查容器的日志

如下是新环境容器的报错信息：

Could not open input file: /opt/.phpstorm_helpers/phpinfo.php

我在打包的时候，记得是没有往镜像里打包这个文件的。通过查阅刚刚抓包的API参数，发现他有把一个容器作为磁盘挂载在这个新容器上。

来通过docker inspect [container ID] 检查两个容器有何不同。

如下是有问题的镜像

如下是正常的容器。

通过对比，我估计PHP容器所挂载的磁盘容器有问题。

检查容器磁盘

接下来我又细致检查了两个作为磁盘的容器。

如下是有问题的容器。

如下是正常的容器。

这两个作为磁盘的容器都是基于 phpstorm_helpers:PS-181.5281.35镜像构建的。都是基于同一个容器构建的会有什么问题呢？

接下来我检查了下 IMAGE ID，不一样。怎么会不一样呢。我查了下我的命令命令历史记录， docker save ，docker import。

结案

哦，这， save 和 load， export 和 import。 我命令搞混了。在新环境删除了错误的镜像。重新让PHPStorm检查下就好了。

附上成功图：