使用 acme.sh 自动签发 https 证书

安装

curl https://get.acme.sh | sh -s email=my@example.com

使用域名解析商提供的 api 自动添加 txt 记录完成验证

以阿里 dns 为例,其他服务商参考 How to use DNS API

export Ali_Key="key"
export Ali_Secret="secret"
acme.sh --issue --dns dns_ali -d example.com -d *.example.com

copy 证书

mkdir -p /etc/nginx/certs/example.com
acme.sh --install-cert -d example.com --key-file /etc/nginx/certs/example.com/key.pem --fullchain-file /etc/nginx/certs/example.com/cert.pem

使用证书

在 nginx 443 端口的配置中添加如下配置:

ssl_certificate /etc/nginx/certs/example.com/cert.pem;
ssl_certificate_key /etc/nginx/certs/example.com/key.pem;

并把 80 的请求跳转到 443,上述配置可以单独列在一个文件中,需要的地方引入即可

[转]docker-compose up 使用代理

原文

I did a bit more research and seem to have used better key words because I found my solution now. I wanted to share the solution with everyone, in case someone else may ever need it.

Create folder for configuring docker service through systemd

mkdir /etc/systemd/system/docker.service.d

Create service configuration file at /etc/systemd/system/docker.service.d/http-proxy.conf and put the following in the newly created file

[Service]
# NO_PROXY is optional and can be removed if not needed
# Change proxy_url to your proxy IP or FQDN and proxy_port to your proxy port
# For Proxy server which require username and password authentication, just add the proper username and password to the URL. (see example below)

# Example without authentication
Environment="HTTP_PROXY=http://proxy_url:proxy_port" "NO_PROXY=localhost,127.0.0.0/8"

# Example with authentication
Environment="HTTP_PROXY=http://username:password@proxy_url:proxy_port" "NO_PROXY=localhost,127.0.0.0/8"
Reload systemctl so that new settings are read

sudo systemctl daemon-reload

Verify that docker service Environment is properly set

sudo systemctl show docker --property Environment

Restart docker service so that it uses updated Environment settings

sudo systemctl restart docker

Now you can execute the docker-compose command on your machine without getting any connection refused error messages.

双层 nginx,nginx gzip on 未生效问题排查

背景

某 spring 服务使用 nginx 反向代理(下文称为 nginx-a),对外提供服务,并且在 nginx 上配置了 gzip on

后来由于某些原因,需要在 nginx 前面再加一层 nginx 做反向代理(下文称为 nginx-b),并且没有开启 gzip,因为已经在 nginx-a 开启了 gzip,无需开启两次

问题

加上 nginx-b 之后发现,浏览器访 nginx-b 问的时 gzip 失效了,于是又把域名指向 nginx-a,发现 gzip 却是生效的。

结论

排查之后发现是由于 nginx 作为反向代理服务器(nginx-b),会给后端服务发送一个 header Via: nginx,并且 nginx 作为 upstream(nginx-a)回检查 header 中的 Via,默认配置下如果设置了这个 header,nginx 返回的内容就不做 gzip 压缩,所以访问 nginx-b 的时候 gzip 失效了。

解决办法

只需要在 nginx-b 的配置里加上 gzip_proxied: any,表示任何时候返回的内容都做 gzip,具体介绍见 nginx 官网文档

参考文献:

情绪管理

不要情绪化

有问题就陈述具体事项和带来的影响,而不是描述自己的感受和可能做出的应对策略

示例一

错误示例:你这么搞我没法干了(描述应对策略)

正确示例:你这么搞导致我做这件事情的成本太高了(陈述问题和带来的影响)

示例二

错误示例:各种流程太多了,让人觉得很烦(描述自身感受)

正确示例:各种流程太多了,导致做事情效率太低(陈述问题和带来的影响)

docker 中使用 xdebug 做性能分析

Dockerfile

在原来镜像的 Dockerfile 中添加如下定义

RUN pecl install xdebug-3.0.2
RUN docker-php-ext-enable xdebug

RUN { \
        echo 'zend_extension=xdebug.so'; \
        echo 'xdebug.mode=profile'; \
        echo 'xdebug.start_with_request=trigger'; \
        echo 'xdebug.output_dir=/tmp/xdebug'; \
    } > /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini;

重新打包镜像就能得到一个包含了 xdebug 扩展的 php 镜像了,如果不确定是否添加成功,可以在容器运行起来之后,执行docker exec -i container_name php -m | grep xdebug 检查 xdebug 扩展是否安装成功

配置解析

这里我们采用的是 xdebug3,配置与 xdebug2 不太一样,具体区别可以看这里,网上能搜到的大部分都是 xdebug2 的配置。

为了不影响其他请求的性能,也为了减少日志数量,我们采用 start_with_request=trigger,手动触发 xdebug profile

xdebug.mode=profile 表示使用 xdebug 的 profile 模式
xdebug.start_with_request=trigger 表示默认不开启 xdebug profile,需要通过 http 请求中,添加 > XDEBUG_PROFILE=1 参数来开启,GET/POST 均可
xdebug.output_dir 指定 xdebug 日志的存放位置,如果指定的文件夹不存在,是无法生成日志的

由于我们是在 docker 中使用 xdebug,xdebug.output_dir 对应的目录最好从宿主机挂载进去,方便查看

开始分析

构造一个请求,例如:http://127.0.0.1:8080/xdebug?XDEBUG_PROFILE=1。

之后可以在上述配置的文件夹中找到文件名类似cachegrind.out.20的文件,就是我们要的 profile 文件了。

Mac 用户可以下载 qcachegrind 来查看 profile 文件 brew install qcachegrind

下载完之后打开文件就能看到图形化的分析结果了。

参考文献