Docker快速开启一个MySQL5.7实例

docker run --name mysql57 -v /Users/charles/docker/mysql57/etc:/etc/mysql/conf.d -v /Users/charles/docker/mysql57/data:/var/lib/mysql -p 3357:3306 -e MYSQL_ROOT_PASSWORD=root -d mysql:5.7

第一个-v是绑定mysql的配置文件夹

第二个-v是绑定mysql的数据文件夹

-p 3357:3306 将本机的3357端口绑定到docker实例的3306端口上

-e MYSQL_ROOT_PASSWORD=root 设置MySQL的root账号对应的密码是root

tips: -e是设置docker容器的环境配置

利用Docker搭建Elasticsearch和Kibana版本7.4.2(Mac)

最近公司技术部门发福利,给技术部小伙伴买了一些技术教程视频和书籍,考虑到App使用全文搜索功能,购买了Elasticsearch入门视频。

这篇文章记录一下使用Docker搭建本机测试用elasticsearch和网页图形工具kibana

当前elasticsearch和kibana的最新版本是7.4.2,使用命令拉取最新两个镜像:

docker pull elasticsearch:7.4.2
docker pull kibana:7.4.2

花费半小时拉取完毕之后(网速看脸,有时候快有时候慢),两个官方镜像就已经准备好了。

首先创建一下elasticsearch和kibana专用的docker网络:

docker network create --subnet=172.20.0.0/16 es

创建elasticsearch运行容器:

docker run -d --name elasticsearch -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" -v /Users/charles/docker/elasticsearch/data:/usr/share/elasticsearch/data --network es --ip 172.20.0.2 elasticsearch:7.4.2

上述命令中 /Users/charles/docker/elasticsearch/data 是elasticsearch存放索引数据的文件夹,换成你觉得方便的地方。设置固定ip方便设置kibana

防止遇到一些未知的错误,我建议你把上述命令中的-d参数去掉,不使用daemon方式运行,直接以前台运行,看到下图则表明elasticsearch运行正常,再加上-d作为后台服务运行

打开http://127.0.0.1:9200/测试一下是否运行正常

看到类似上图一样的JSON串说明elasticsearch运行正常。上图使用了Chrome的格式化JSON串插件,科学上网后点击此链接安装

接下来安装kibana客户端工具,使用命令获取elasticserach容器的虚拟内网ip地址

docker inspect elasticsearch | grep IPAddress
配图仅供参考

我的docker上显示的是 172.20.0.2,根据此IP地址启动kibana容器

docker run --network es --name kibana -e ELASTICSEARCH_URL=http://172.20.0.2:9200 -p 5601:5601 -d kibana:7.4.2

执行好此命令后,可以在浏览器打开http://127.0.0.1:5601

如果页面提示:Kibana server is not ready yet,稍等片刻再重试

见到上图,则说明kibana已经正常运行了。

可以使用命令,让elasticsearch、kibana在docker运行时自动启动,参考链接

docker update --restart=always elasticsearch
docker update --restart=always kibana

尽情享用elasticsearch吧

Xshell不能使用退格、删除键的解决方案

xshell使用中,若是敲错字母了的,按退键删除敲错的字母,却正在屏幕表现出了“^H”,无法正常删除,再按删除键,却表现出“^[[3~”

修改办法:当前连接属性–>终端 –>键盘 把delete 和backspace序列改为 ASCII 127即可。

nginx访问日志按照日期分文件存储

nginx默认的access_log存储方式是单文件,小流量网站没有问题,大流量网站在经历长时间运行后,日志文件变得非常大,难以维护,查阅nginx文档后,写下配置

if ($time_iso8601 ~ '(\d{4}-\d{2}-\d{2})')
{
    set $day $1;
}
access_log /home/wwwlogs/blog.yinghualuo.cn_$day.log;

如果有更好的方案,请不吝赐教

解决screen状态为Attached连上不的问题

当你挂起screen,下次想连上screen的时候,有时候会出现screen session的状态为Attached而怎么连也连不上的情况。下面给出解决方法。

列出状态为Attached的session id。

screen -ls
# 剔除某个session的占用
screen -D -r <session-id>

一种PHP的nginx伪静态写法

众所周知,thinkphp5的Nginx写法是这样子的:

location / {
   if (!-e $request_filename) {
      rewrite  ^(.*)$  /index.php?s=/$1  last;
   }
}

现在网站根目录下面有一个admin.php文件

请求http://abc.com/admin.php/login时候,请求会被nginx转发到index.php

按照开发需求,则需要转发至admin.php

nginx单host完整配置代码如下

server {
     listen 80;
     server_name abc.com;
     root /xxxx/xxxx;
     index index.html index.htm index.php;
     charset utf-8;
	location ~ [^/]\.php(/|$)
	{
		try_files $uri =404;
		fastcgi_pass  127.0.0.1:9000;
		fastcgi_index index.php;
		include fastcgi.conf;
		set $real_script_name $fastcgi_script_name;
		if ($fastcgi_script_name ~ "^(.+?\.php)(/.+)$") {
			set $real_script_name $1;
			set $path_info $2;
		}
		fastcgi_param SCRIPT_FILENAME $document_root$real_script_name;
		fastcgi_param SCRIPT_NAME $real_script_name;
		fastcgi_param PATH_INFO $path_info;
	}

	location / {
		if (!-e $request_filename) {
			rewrite  ^/(.*)$  /index.php?s=/$1 last;
			break;
		}
	}
}

跨域问题,当mode为include时,Access-Control-Allow-Origin不能为*,

The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.


配合前端写Vue项目时,浏览器遇到这种错误,按道理来说http response 的 header 中 Access-Control-Allow-Origin参数 为* 时,可以满足一切域名情况。

看样子 看了半天也不行,修改nginx的配置 Access-Control-Allow-Origin 改为 http://xxx.xxx.com时候,可以了。最后查找跨域文档才发现

跨域请求发送cookie的时候,需要判断是否包含了请求源的origin,不然不发送cookie,然后,OPTIONS请求发送成功后,并没有新的请求发出。

解决方法是:
nginx配置修改一下

add_header Access-Control-Allow-Origin *;

改成

add_header Access-Control-Allow-Origin "$http_origin";


这样满足任何情况

Http request header坑记录

在开发公共API时,在请求头中(http request header)加入key secret来认证用户。
类似阿里云AccessKey AccessSecret。
header的key为MERCHANT_KEY MERCHANT_SECRET,PHP后端接收不到这些key的header。
查阅nginx资料发现,nginx默认设置会把含有下划线的key给忽略掉。
修改这些设置有两个方法:

1、修改nginx设置,underscores_in_headers 设置为 on

2、使用减号代替下划线,推荐这个方法