感冒发烧咳嗽血常规和C反应蛋白的一点知识

血常规和C反应蛋白的一点知识

前几天有家人感冒发烧,还有咳嗽,就去医院看病。因为就感冒,去医院不方便,就图方便去了边上的一个小医院。
这个医院是社保医院,但是属于民营医院,一般我就到这个医院开点药,做个化验,化验结果也是自己看,不找那的医生看。
这次看病的经历大致如下:
一进去,医生做了一般性的体检后,然后开化验单,一边很好心的和我解释:现在流感很多,流感很严重……,我一看化验单上:
1. 血常规 几元钱
2. C反应蛋白 好像50元
3. 流感病毒检测什么的 150元
然后我和医生说:那个检测流感的不要了。那个医生的脸色立时拉了下来,“这个流感很严重的啊……”,我说不要了。
1. 血常规结果出来了:
2. 白细胞 正常
3. 淋巴细胞 正常
4. 中性白细胞比例 高了丁点,高了0.8%
5. C反应蛋白 正常
6. 其他全部正常
把化验单交给那医生,那医生看了后,说:“中性高了点点,根据化验单来看,是病毒性感冒”,我就纳闷了,中性白细胞高了,反而是病毒性感冒,这个医学知识学得够好的啊,我就问了这个问题:“中性高是病毒性感冒?”……反正我也没有和他争了,反倒是陪同的家人脸色不太好,他们心里在嘀咕:“究竟你是医生还是他是医生”。
最后,开了点退烧的和治疗感冒的药物就回来了。以后决定小病都不能上这样性质的医院看。
回来了,查了资料,补全一下这方面的知识:
白细胞:当发生细菌性感染的时候,白细胞升高,当白细胞升得非常高的时候,说明细菌感染很厉害,比如有化脓、肺炎等。假如白细胞正常或者稍微偏高,可能病毒性感染,具体还要看中性白细胞和淋巴细胞的比例。
中性白细胞:当细菌感染的时候,中性白细胞升高。
淋巴细胞:当病毒感染的时候,淋巴细胞升高。
C反应蛋白:细菌感染的时候,C反应蛋白升高;病毒感染的时候,C反应蛋白正常。
其实,一开始一个血常规基本上就能满足要求了,甚至连C反应蛋白一开始都可以无需做的。

在docker中搭建redis集群以及哨兵sentinel

在上一篇文章《在一台centos7服务器上搭建redis集群以及哨兵sentinel》中,我们提到了一个很重要的知识点,大家可以去看看。
在这里,我们会反复提到这个知识点,对于docker下部署redis sentinel非常重要。

部署环境

  1. 假设该宿主机服务器的ip是:192.168.1.100,docker0的ip是:172.17.0.1
  2. 使用redis的镜像是:docker pull redis:5.0.4
  3. redis只搭建1主1从(网上很多都是1主2从,没有这个必要),3个sentinel(3个是必须的,否则在failover的时候就会出现一些不必要的问题)
  4. 6379:redis server,docker的volume目录在 /data/redis-6379
    6380: redis server,docker的volume目录在 /data/redis-6380
    26379:redis sentinel,docker的volume目录在 /data/redis-26379
    26380:redis sentinel,docker的volume目录在 /data/redis-26380
    26381:redis sentinel,docker的volume目录在 /data/redis-26381

部署过程

部署redis-6379

1,mkdir -p /data/redis-6379/conf && mkdir -p /data/redis-6379/data && chmod 666 -r /data/redis-6379 && cd /data/redis-6379/conf
这里的chmod 666 非常重要,原因有下面2个:
我们从redis Dockerfile中可以看到,docker中的redis用户和用户组是 redis,

RUN mkdir /data && chown redis:redis /data

redis在进行sentinel,failover的时候会改写配置文件,redis的用户是redis,而宿主机的目录是另外的人,所以需要改变目录权限
2,vi redis.conf,内容如下:
requirepass “123456”
masterauth “123456”
slave-announce-ip “192.168.1.100”
slave-announce-port 6379
重点来了,这里的masterauth,已经从上一篇文章中解释了。
还有2个配置:slave-announce-ip,slave-announce-port这2个呢?原因和masterauth一样的,当发生failover的时候,这个原先是主的redis就会成为从,所以这2个配置是给主在成为从的时候使用的。但是为什么要在docker环境中用这2个配置,在上一篇文章中为什么不用呢?因为在docker环境下,假如不用这2个配置,那么在连接到主服务器上后,ip地址会变成172.17.0.1这个docker0地址,同时端口始终是6379。等下我们可以看看。
3,加入 docker-compose.yml 以下内容

redis-6379:
  image: redis:5.0.4
  container_name: redis-6379
  volumes:
    - /data/redis-6379/conf/redis.conf:/usr/local/etc/redis/redis.conf
    - /data/redis-6379/data:/data
  ports:
    - 6379:6379
  command: redis-server /usr/local/etc/redis/redis.conf

4,运行docker-compose
docker-compose up -d redis-6379
5,登录redis控制台
docker exec -it redis-6379 /bin/bash
redis-cli
auth 123456
info
可以看到role: master
exit
exit

部署redis-6380

1,mkdir -p /data/redis-6380/conf && mkdir -p /data/redis-6380/data && chmod 666 -r /data/redis-6380 && cd /data/redis-6380/conf
2,vi redis.conf,内容如下:
requirepass “123456”
masterauth “123456”
slaveof 192.168.1.100 6379
slave-announce-ip “192.168.1.100”
slave-announce-port 6380
3,加入 docker-compose.yml 以下内容

redis-6380:
  image: redis:5.0.4
  container_name: redis-6380
  volumes:
    - /data/redis-6380/conf/redis.conf:/usr/local/etc/redis/redis.conf
    - /data/redis-6380/data:/data
  ports:
    - 6380:6379
  command: redis-server /usr/local/etc/redis/redis.conf

4,运行docker-compose
docker-compose up -d redis-6380
5,登录redis控制台
docker exec -it redis-6379 /bin/bash #注意这里是登录6379这个主redis容器
redis-cli
auth 123456
info
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.1.100,port=6380,state=online,offset=561,lag=1
这里可以看到 slave的ip是正确的。假如我们在 6380 的配置中没有设置slave-announce-ip “192.168.1.100” 和 slave-announce-port 6380的话,那么将在这里看到的是 slave0:ip=172.17.0.1,port=6379,state=online,offset=561,lag=1,如此的设置当然会在failover的时候发生异常了。所以从这里能很清楚明白这2个配置的重要性。
exit
exit

部署redis-26379

1,mkdir -p /data/redis-26379/conf && mkdir -p /data/redis-26379/data && chmod 666 -r /data/redis-26379 && cd /data/redis-26379/conf
2,vi sentinel.conf,内容如下:
protected-mode no
port 26379
sentinel monitor mymaster 192.168.1.100 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel auth-pass mymaster 123456
sentinel announce-ip “192.168.1.100”
sentinel announce-port 26379
这里的2个配置 sentinel announce-ip 和 sentinel announce-port 和 上面的那2个意思大致差不多,假如不这么设置的话,那么在 sentinel 的ip通信中就会出现 172.17.0.1:26379 这样错误的值。下面会进一步说到。
3,加入 docker-compose.yml 以下内容

redis-26379:
  image: redis:5.0.4
  container_name: redis-26379
  volumes:
    - /data/redis-26379/conf/sentinel.conf:/usr/local/etc/redis/sentinel.conf
    - /data/redis-26379/data:/data
  ports:
    - 26379:6379
  command: redis-server /usr/local/etc/redis/sentinel.conf

4,运行docker-compose
docker-compose up -d redis-26379

部署redis-26380

1,mkdir -p /data/redis-26380/conf && mkdir -p /data/redis-26380/data && chmod 666 -r /data/redis-26380 && cd /data/redis-26380/conf
2,vi sentinel.conf,内容如下:
protected-mode no
port 26379
sentinel monitor mymaster 192.168.1.100 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel auth-pass mymaster 123456
sentinel announce-ip “192.168.1.100”
sentinel announce-port 26380
3,加入 docker-compose.yml 以下内容

redis-26380:
  image: redis:5.0.4
  container_name: redis-26380
  volumes:
    - /data/redis-26380/conf/sentinel.conf:/usr/local/etc/redis/sentinel.conf
    - /data/redis-26380/data:/data
  ports:
    - 26380:6379
  command: redis-server /usr/local/etc/redis/sentinel.conf

4,运行docker-compose
docker-compose up -d redis-26380
5,cat /data/redis-26379/conf/sentinel.conf #注意这里查看 redis-26379
# Generated by CONFIG REWRITE
sentinel known-slave mymaster 192.168.1.100 6380
sentinel known-sentinel mymaster 192.168.1.100 26380 75f969e584d6cae9f23a6f9da6069d8c69873452
从这里能注意到2件事情:
a,看到“Generated by CONFIG REWRITE”这句注释,说明redis对配置文件进行了修改。这就是为什么我们一开始就把配置文件所在的volumn的权限设置为666的原因:chmod 666 -r /data/redis-xxx,假如上面没有修改,那么就会报错:CONFIG REWRITE failed: Permission denied,这个错误不影响启动,但是会影响发生failover后的一些问题,所以一定要事先设置好权限。
b,看到 192.168.1.100 26380 这个配置,这就是前面所讲到的 sentinel announce-ip, sentinel announce-port 的作用,假如没有设置,那么这里将是 172.17.0.1 26379 这个错误的ip。
cat /data/redis-26380/conf/sentinel.conf,也能看到如此的情况,不多说

部署redis-26381

这里不多说,和 redis-26380类似。

测试

咱们用 https://github.com/champbay/redis-sentinel 这个工程来进行测试
启动这个工程后,可以看到不断的往 redis 中插入 test-i 这样的值
然后,docker stop redis-6379,马上可以看到这个工程开始报错,大概过了5秒钟(因为我上面设置的是5秒钟),又恢复正常了,说明 redis sentinel已经起效了。
我们查看一下 6380 的配置文件,cat /data/redis-6380/conf/redis.conf,看到 slaveof 已经不见了,间接说明成为了主。通过进入redis-6380容器,redis-cli看一下info,可以看到确实成为了master。这里也说明需要事先修改一下配置文件的权限,否则这里就会报错。
我们再次启动 docker start redis-6379,稍等一会,查看6379的配置文件,发现最后多了一行 slaveof 192.168.1.100 6380,(slaveof == replicaof),说明已经成为了从,从 redis-cli也能看出。

一些js的加密混淆工具

在线

比较好的js加密解密网站:https://tool.lu/js, 这个工具中可以使用美化、净化、加密、混淆这几种方法。这些方法都是网站前台发到后台去处理的。通过美化、净化、加密、混淆后的js代码,就算通过解密也难以恢复那些变量的命名,增加了查看的难度,当然了,最终还是能够破解一些核心点的,只不过增加了难度而已。

这里提一下,有比较多的在线js加密解密混淆网站,打着免费使用的目的,在加密的文件中加入自己使用的软件名称,原因就是让破解者花钱找他们,让他们破解,这里大家在使用的时候要小心点。

uglifyjs

这个是目前js开源界中最有名的一个,在github上的地址:https://github.com/mishoo/UglifyJS2, 已经被 webpack 整合。中文文档在这里:https://segmentfault.com/a/1190000010874406。如何使用:
npm install uglify-js -g
uglifyjs aaa.js –compress –mangle -o aaa.min.js
通过uglifyjs出来的最终文件,可看性是还可以大致能看清一些核心代码的,通过解密后那些变量的命名也不能恢复。效果比上面提到的在线工具要差一些。

jsfuck

https://github.com/aemkei/jsfuck, 这个看上去很美,其实有2个致命问题:
1,可以被 http://codertab.com/JsUnFuck 顺利解开。
2,不兼容IE。
所以大家不要考虑了。

decent-messup

https://github.com/blackmiaool/decent-messup,是国人写的,这个也看上去不错,但是不兼容IE。

到现在为止还没有找到一个特别厉害的,所以一些涉及安全的js,还是尽量放在后台处理吧,前台目前只能将就一下了。

大家有好的,可以给我推荐,收费的尽量不要推荐了。

在一台centos7服务器上搭建redis集群以及哨兵sentinel

很早很早以前,具体时间有点忘记了,那个时候redis还没有高可用的方案,但是线上的又希望有redis的高可用,于是参考资料,搭建了一套基于haproxy和keepalived的方案,但是这套方案在测试的时候就发现了很大很大的问题,于是没有最终上线,只能等着redis官方的高可用版本。现在我们来看一下那个时候我写的一段内容:

当redis master宕机后,HaProxy会马上切换到redis slave上。
假如redis master再次启动后,这个时候问题出来了:
1)  HaProxy会自作聪明的再次将redis请求路由到redis master上。
2)  redis slave将会从redis master上再次同步数据,结果导致redis slave上的数据丢失。
为了应付这个问题,假设有redis master为r1,redis slave为r2,这个时候r1宕掉了,需要如下处理:
1)  千万不要马上重新启动r1,切记。
2)  用redis-cli 连接r2,发送命令。如:./redis-cli  SLAVEOF no one
3)  修改r1的配置文件,把r1设置为slave。如:slaveof  ip:port
4)  热配置HaProxy,将r2设置为主要路由,r1设置为failover路由。具体参见HaProxy的architecture.txt中的4.3 Hot Configuration
5)  启动r1。
上述步骤次序关键,不能搞错,搞错后就有可能导致redis上的数据完全丢失。

上述这段文字大家不用仔细看,只需要知道没有redis的哨兵模式时代是多少的痛苦。

重要知识点,很多同学因为下面这个知识点不明白,导致了出现问题

一开始,比如6379是主,6380是从,redis在进行设置的时候,是有主从设置的,那么在6380的配置文件中需要设置masterauth和slaveof这2个配置,而6379是不需要设置这2个配置的。
后来发生了failover,那6380就成了主,而6379就成了从。这个时候,sentinel会修改6379和6380的配置文件,slaveof还好说,sentinel会自动修改,但是6379要去访问6380,因为一开始在6379中是没有masterauth这个配置的,所以就会出现同步失败。
那为什么sentinel一开始不把6380这个从上设置的masterauth配置给记录下来?原因我没有去进一步探索,是不是涉及安全问题?

结论是:只有一开始的时候对某个redis来说是有主从固定配置的,后续一旦发生了failover,这些配置就会被自动改写。所以对于一开始的主并不能永远是主,那么在设置的时候,还需要参考从的一些配置,事先做好(这一点也会在我的后一篇文章《在docker中搭建redis集群以及哨兵sentinel》讲道),对于6379主,也需要设置好masterauth这个本应该是从的配置。

部署环境

  1. redis的哨兵模式和网络环境很有关系,当在docker、nat等环境下,需要进行额外的处理,详细见我的后一篇文章《在docker中搭建redis集群以及哨兵sentinel
  2. 本文只描述在一台服务器上部署,对于多台服务器结合我后面的那篇文章《在docker中搭建redis集群以及哨兵sentinel》(其实就是网络环境),过程也是同样的
  3. 假设该服务器的ip是:192.168.1.100,已经安装了 redis,版本比如是 5 以上的,其实 3.x.x 也是可以的,这个只需要查看一下redis官方文档即可。
  4. redis只搭建1主1从(网上很多都是1主2从,没有这个必要),3个sentinel(3个是必须的,否则在failover的时候就会出现一些不必要的问题)
  5. 该服务器已经开放了防火墙的端口给客户端来调用:6379,6380,26379,26380,26381
  6. 6379:redis server
    6380: redis server
    26379:redis sentinel
    26380:redis sentinel
    26381:redis sentinel

部署过程

部署redis-6379

1,mkdir -p /usr/local/redis-6379/data && cd /usr/local/redis-6379
2, vi redis.conf,内容如下:
requirepass “123456”
port 6379
daemonize yes
pidfile “/var/run/redis-6379.pid”
logfile “/usr/local/redis-6379/redis.log”
dir “/usr/local/redis-6379/data”
masterauth “123456” #这里是主,为什么还要设置从的配置,原因见上
3,redis-server redis.conf
4, redis-cli -p 6379
> auth 123456
> info
可以看到:
# Replication
role:master
connected_slaves:0
> exit

部署redis-6380

1,mkdir -p /usr/local/redis-6380/data && cd /usr/local/redis-6380
2, vi redis.conf,内容如下:
requirepass “123456”
port 6380
daemonize yes
pidfile “/var/run/redis-6380.pid”
logfile “/usr/local/redis-6380/redis.log”
dir “/usr/local/redis-6380/data”
masterauth “123456”
replicaof 192.168.1.100 6379 #replicaof == slaveof,在3.x.x中用 slaveof
3,redis-server redis.conf
4, redis-cli -p 6379
> auth 123456
> info
可以看到:
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.1.100,port=6380,state=online,offset=15680,lag=0
假如上面的slave0的ip不是192.168.1.100,而是另外一个ip,而这个ip又不是redis的客户端所能访问到的,那么就需要额外进行设置,详细见我的后一篇文章《》
> exit
5, redis-cli -p 6380
> auth 123456
> info
可以看到:
# Replication
role:slave
master_host:192.168.1.100
master_port:6379
可以看到6379是master,6380是slave,各自的配置都是正确的

部署redis-26379

1,mkdir -p /usr/local/redis-26379 && cd /usr/local/redis-26379
2, vi sentinel.conf,内容如下:
protected-mode no #允许外网访问
port 26379
daemonize yes
pidfile “/var/run/sentinel-26379.pid”
logfile “/usr/local/redis-26379/sentinel.log”
sentinel monitor mymaster 192.168.1.100 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel auth-pass mymaster 123456
3,redis-sentinel sentinel.conf
4, redis-cli -p 26379
> info
可以看到:
# Sentinel
sentinel_masters:1
master0:name=mymaster,status=ok,address=192.168.1.100:6379,slaves=1,sentinels=3
> exit

部署redis-26380

1,mkdir -p /usr/local/redis-26380 && cd /usr/local/redis-26380
2, vi sentinel.conf,内容如下:
protected-mode no #允许外网访问
port 26380
daemonize yes
pidfile “/var/run/sentinel-26380.pid”
logfile “/usr/local/redis-26380/sentinel.log”
sentinel monitor mymaster 192.168.1.100 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel auth-pass mymaster 123456
3,redis-sentinel sentinel.conf
4, redis-cli -p 26380
> info
可以看到:
# Sentinel
sentinel_masters:1
master0:name=mymaster,status=ok,address=192.168.1.100:6379,slaves=1,sentinels=3
# SENTINEL sentinels mymaster
可以看到到目前为止的2个sentinel,可以看到 sentinel 的ip,假如ip不是192.168.1.100,而是另外一个ip,而这个ip又不是redis的客户端所能访问到的,那么就需要额外进行设置,详细见我的后一篇文章《在docker中搭建redis集群以及哨兵sentinel
> exit

部署redis-26381

和redis-26380的一样,只需要把 26380 改成 26381

测试

咱们用 https://github.com/champbay/redis-sentinel 这个工程来进行测试
启动这个工程后,可以看到不断的往 redis 中插入 test-i 这样的值
然后,kill 掉 6379 这个 redis 进程,可以看到这个工程开始报错,大概过了5秒钟(因为我上面设置的是5秒钟),又恢复正常了,说明 redis sentinel已经起效了。
我们查看一下 6380 的配置文件,cat /usr/local/redis-6380/redis.conf,看到 slaveof 已经不见了,间接说明成为了主。通过redis-cli -p 6380看一下info,可以看到确实成为了master。
我们再次启动 6379,稍等一会,查看6379的配置文件,发现最后多了一行 slaveof 192.168.1.100 6380,(slaveof == replicaof),说明已经成为了从,从 redis-cli也能看出。

springboot如何正确使用tomcat连接池

在springboot的application.properties中,我们常常这么设置:

spring.datasource.url=jdbc:mysql://192.168.0.1:3306/dbname
spring.datasource.username=aaa
spring.datasource.password=123456
spring.datasource.driver-class-name=com.mysql.jdbc.Driver

假如只有上面这些关于连接池的设置,那么springboot将根据 org.springframework.boot.autoconfigure.jdbc.DataSourceBuilder 中的下面次序去找有没有相应的jar:

private static final String[] DATA_SOURCE_TYPE_NAMES = new String[] {
            "org.apache.tomcat.jdbc.pool.DataSource",
            "com.zaxxer.hikari.HikariDataSource",
            "org.apache.commons.dbcp.BasicDataSource", // deprecated
            "org.apache.commons.dbcp2.BasicDataSource" };

假如工程是内置tomcat容器的,那么默认就是 org.apache.tomcat.jdbc.pool.DataSource,同时tomcat连接池的那些最大最小参数都是默认值:
initialSize 10
maxActive 100
maxIdle 100
minIdle 10
可以看到这些默认值基本上也能满足大多数场景了。

假如觉得上面的这些值还不够好,那么需要在application.properties中这么设置才可以:
spring.datasource.tomcat.initialSize=10
spring.datasource.tomcat.maxActive=200
spring.datasource.tomcat.maxIdle=200
spring.datasource.tomcat.minIdle=10

这是因为在 org.springframework.boot.autoconfigure.jdbc.DataSourceConfiguration.Tomcat 这个类中如下定义:

@Bean
        @ConfigurationProperties(prefix = "spring.datasource.tomcat")
        public org.apache.tomcat.jdbc.pool.DataSource dataSource(
                DataSourceProperties properties) {
            org.apache.tomcat.jdbc.pool.DataSource dataSource = createDataSource(
                    properties, org.apache.tomcat.jdbc.pool.DataSource.class);
            DatabaseDriver databaseDriver = DatabaseDriver
                    .fromJdbcUrl(properties.determineUrl());
            String validationQuery = databaseDriver.getValidationQuery();
            if (validationQuery != null) {
                dataSource.setTestOnBorrow(true);
                dataSource.setValidationQuery(validationQuery);
            }
            return dataSource;
        }

可以看到 prefix = “spring.datasource.tomcat”,所以需要在配置中的前缀应该是 spring.datasource.tomcat,不这么设置,实际上是没有启用这些参数的。

最后,如何验证这些参数是否生效:在 org.apache.tomcat.jdbc.pool.DataSourceProxy 这个类的getConnection()方法中加个断点,然后运行后访问数据库时,查看这个 datasource 的这些参数。

下一篇将是 《springboot如何正确使用dbpc2连接池》

docker容器之间通过link方式的互联

这里只是描述在单docker容器之间通过link方式的互联,容器之间的其他联系方式不在本文里面描述。

首先我们来看一个例子:
1. 创建一个mysql容器:
docker run –name mymysql -d -p 3306:3306 -e MYSQL_ROOT_PASSWORD=123456 mysql:5.5.49
这里创建了一个名字是 mymysql 的容器,为了举例,故意把名字弄成不一样,同时只是为了举例,不用去计较volumes
2. 创建一个需要使用mysql的容器,这里用wordpress来举例:
docker run –name wordpress -d -p 80:80 –link mymysql:mysql wordpress
同样只是为了举例,不要去计较volumes。很神奇的,不用设置mysql的连接地址,不用设置mysql的密码,wordpress启动后,这些都识别出来了。

这里面到底发生了什么?下面让我们一点一点来分析一下:
我们把mymysql这个容器叫做“源容器”,把wordpress这个容器叫做“接收容器”。在“接收容器”创建的时候,用 –link mymysql:mysql,其中 mymysql是“源容器”的名称,mysql这个名称叫做“别名”,是在“接收容器”中会用到,比如在程序中可以用 jdbc:mysql://mysql:3306/xxdb。

为了让“接收容器”访问“源容器”,比如为了能使得jdbc:mysql://mysql:3306/xxdb找到真正的地址,比如jdbc:mysql://192.168.0.3:3306/xxdb, docker提供了2种方式:
1. 环境变量
2. /etc/hosts 文件

环境变量

我们先运行下面的命令:
docker run -i -t –rm –link mymysql:mysql busybox:latest env #这个意思是在“接收容器”busybox中打印出所有的环境变量

HOSTNAME=5878f7496b83
TERM=xterm
MYSQL_PORT=tcp://192.168.0.3:3306
MYSQL_PORT_3306_TCP=tcp://192.168.0.3:3306
MYSQL_PORT_3306_TCP_ADDR=192.168.0.3
MYSQL_PORT_3306_TCP_PORT=3306
MYSQL_PORT_3306_TCP_PROTO=tcp
MYSQL_NAME=/inspiring_swanson/mysql
MYSQL_ENV_MYSQL_ROOT_PASSWORD=123456
MYSQL_ENV_GOSU_VERSION=1.7
MYSQL_ENV_MYSQL_MAJOR=5.5
MYSQL_ENV_MYSQL_VERSION=5.5.49
HOME=/root

看到了“接收容器”中的打印的环境变量就知道了,“接收容器”将“源容器”中的环境变量加了一个“别名”ENV这样的前缀,我们只要在程序中获取这些环境变量的值,就可以知道我们所需要的。

/etc/hosts 文件

我们先运行下面的命令:
docker run -i -t –rm –link mymysql:mysql busybox:latest cat /etc/hosts #这个意思是在“接收容器”busybox中打印出/etc/hosts这个文件的内容

127.0.0.1       localhost
::1     localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
192.168.0.3     mysql 1023833075ea mymysql
192.168.0.5     6761e72cb33f

看到上面的192.168.0.3 mysql的映射关系了,这样也就能理解为什么jdbc:mysql://mysql:3306/xxdb能找到真正的地址,比如jdbc:mysql://192.168.0.3:3306/xxdb

参考

docker从入门到实践(容器互联)
以Tomcat+Mysql为例,实现Docker多容器连接

世界,您好!

很早很早以前写过一些博客文章,因为平时工作偏忙,没有太多时间整理。久而久之,就把一些相关性的文章放到了云笔记中。

现在想想,很有必要将这些知识点写出来,和大家一起分享、一起成长。比如一些资料在网上海查了半天,都是你抄我,我抄你的。我把我遇到的一些问题和我的一些解决办法共享出来,可以省去遇到类似问题的而找不到答案的同学。

非常感谢这么多年来在网上奉献经验、知识的人,很多时候我都是拿来主义,从没有拿出一些我的知识,一直深感内疚和自责。

尽管我不是专家,尽管我的一些解决方式方法可能不一定正确,但是,世界,您好,我来了!