知识是人类最大的财富
在测试机上，通过 ssh 登录，需要键入密码，有时候会觉得特别麻烦，测试机无所谓安全，所以有没有“免密码登录”的功能（对于公钥方式的那种免密登录不是本篇文章所涉及的）
可以按照如下步骤进行：
1. vi /etc/ssh/sshd_config
PermitEmptyPasswords yes
也就是允许空密码登录。
2. systemctl restart sshd，然后再登录发现还是需要输入密码。原因是该用户本来就有密码，那么：
3. passwd -d someuser-name，也就是把某个用户的密码删除即可。
本文结束。
用root远程登录的时候，用户名和密码都正确，但是报错：Permission denied, please try again.
先说一下，用户登录linux的几种方式：
1. 通过密码方式
2. 通过公钥方式
3. 通过键盘交互方式：登录的时候提示你输入用户名和密码那种方式
需要这么修改：
首先修改 /etc/ssh/sshd_config 中的 PermitRootLogin，这个 PermitRootLogin 有以下几个值可以选择，通过 man sshd_config 可以看到具体哪几个值可以选。
yes：这个是默认值，允许上面3种登录方式。
prohibit-password 和 without-password：这2个是一样的，禁止密码方式、禁止键盘交互方式，只允许公钥方式。
forced-commands-only：可以登录，但是登陆后不能进入交互，而是执行指定的命令后 自动退出，指定的命令在authorized_keys里面列出，例如/bin/date
no：不允许root远程登录
所以，我们设置 PermitRootLogin yes，然后 systemctl restart sshd 即可以解决上面这个问题。
只要宿主机能访问外网，那么天生的容器就能自然而然的访问外网。假如你的容器访问不了外网，那么就需要知道容器能访问外网是怎么做到的，然后再去排查问题。
这是宿主机和容器之间采用了 ip_forward 技术，那么什么是 ip_forward，请看这篇文章：ip_forward与路由转发。不过这篇文章讲得比较深奥，我是没有太看明白，只是明白了这么一点浅显的道理：内网、容器、虚拟机要访问外网，那么在网关（针对内网）、宿主机（针对容器、虚拟机）上要设置 ip_forward。
内网 --> 网关 --> 外网 ： 那么需要在网关上设置ip_forward
容器 --> 宿主机 --> 外网 ： 那么需要在宿主机上设置ip_forward
虚拟机 --> 宿主机 --> 外网 ： 那么需要在宿主机上设置ip_forward
在宿主机上查看 ip_forward 有没有打开的方法：
cat /proc/sys/net/ipv4/ip_forward
或者
sysctl net.ipv4.ip_forward
对于sysctl，可以查看这篇文章：《lsmod，modprobe和sysctl的说明》
在docker安装的时候，安装程序会将 net.ipv4.ip_forward 设置为1，同时安装程序进一步会将 net.ipv4.conf.all.forwarding 也设置为1。
我估计对于虚拟机的安装程序来说，也会有这样的操作。
这里只讲在一台机器上的容器之间通信，同时不涉及以下情况：
1. 不涉及：参见我以前的博文《docker容器之间通过link方式的互联》
2. 不涉及 docker network create 创建的容器之间的网络
3. 不涉及 overlap 网络，比如 ingress 和 flannel
比如有2个容器，a容器的ip是 172.17.0.2（其中有一个nginx，对外暴露了80端口），b容器的ip是 172.17.0.3 ，那么在 b容器中：
telnet 172.17.0.2 80
OK，没有问题。
所以，在一台机器内的容器，只要2个都属于同一个 虚拟 bridge，比如默认的 docker0，那么通过IP互联没有任何问题。
上面这句话很绕口，我们来举个例子：
宿主机的IP是 192.168.1.100
a容器内有一个nginx，对外暴露了80端口，比如 docker run -d -p 80:80 nginx
在b容器内进行：
ping 192.168.1.100 #OK，没有问题，说明能访问到宿主机
telnet 192.168.1.100 80 #不行了，说明能访问到宿主机，但是因为宿主机的防火墙给挡住了
那么我们修改一下宿主机的iptables，让来自 docker0 这个虚拟网卡的流量能通行：
iptables -I INPUT chainnumber -i docker0 -j ACCEPT
以后修改iptables尽量不要用 iptables -A，因为 iptables 的策略中有可能最后一条是 reject all，所以必须要插在 reject all 这一条之前。
那么上面中的 chainnumber 用 iptables -L -n –line-numbers 来查看，具体大家可以去查互联网资料。
修改后iptables后，这样就可以在b容器访问宿主机的某个容器暴露端口了。
我们经常听到linux内核，非常的高大上，内核中包含很多模块组件，构成了整个完整的内核。
如何查看linux装载的内核？很简单，用 lsmod 命令，然后会显示一大堆内核中内含的模块，我们想要看某一个模块有没有，可以用如下的命令，举例：
lsmod | grep ip_tables
ip_tables 27126 2 iptable_filter,iptable_nat
出来3列，这3列的名称我们先用一个例子举出来，然后再来解释：
lsmod | egrep 'Module|ip_tables'
Module Size Used by
ip_tables 27126 2 iptable_filter,iptable_nat
Module: 模块名称
Size: 模块的大小
Used by：第1个数字表示这个模块被其他的几个模块所使用(其实表示了依赖关系)，后面的是依赖这个模块的其他模块
用来加载和移除模块的命令，比如：
modprobe br_netfilter #加载
modprobe -r br_netfilter #移除
上面说了加载模块，现在来了问题了，每个模块都有参数需要设定的，那么如何修改这些参数，这些参数又是存储在哪里的，这个就是 sysctl 的作用了。
sysctl 说简单点就是用来修改内核模块参数的，嗯，非常好理解。可以看这篇介绍sysctl的文章：sysctl介绍，基本上该有的都有了，下面是对这篇文章的一些小补充：
KVM安装好后，最方便的使用KVM的界面管理器，但是有时候通过远程连接登录宿主机，不方便做到用界面来管理虚拟机，这个时候，就需要用到虚拟机的命令来管理了。
参考这篇文章，比较简单，当作入门：centos7KVM虚拟化常用虚机管理命令
这里对这些命令做个简单的补充：
1. 直接在宿主机中键入 virsh，即可以进入KVM的专有console，其中通过help能看到所有的KVM命令，比上面那篇文章中还要简单。
2. virsh list，可以查看哪些虚拟机在运行，不运行的不显示；通过
virsh list --all
可以看到所有的虚拟机，其中有名称(name)这一列用在后续的很多命令中
3. 在宿主机中可以查看虚拟机的一些基本信息
virsh dominfo your_vm_name
virsh domifaddr your_vm_name
virsh start your_vm_name
但是我想知道这个虚拟机的更多信息，比如网络；或者我想登录这个虚拟机进一步操作这个虚拟机，那怎么办？
virsh console your_vm_name
但是这个命令键入后会卡在那里，没有反应，原因是虚拟机内部还需要事先设置一下，这样宿主机才能登录，如此设置：
systemctl start serial-getty@ttyS0.service
systemctl enable serial-getty@ttyS0.service
设置好后，再在宿主机中键入上面的console命令，然后再回车1下，或者几下都可以，这样就能登录了。要从虚拟机中登出，ctrl + ] 就可以退出到宿主机了。
基于docker的gitlab安装，大家一定要看一下官方文档: https://docs.gitlab.com/omnibus/docker/
我的这个gitlab安装有一些约束条件：
1. 没有域名，只有IP
2. 服务器内存只有4G
3. 内部人员协同开发，无需使用电子邮件
4. 仅仅用于最基本的git协同开发，没有使用auto devops
5. 没有采用 https，只暴露80端口，其他的22端口也无需暴露
6. 没有采用 Prometheus
7. 采用 docker-compose 来安装
docker-compose.yml 配置如下：
gitlab:
image: 'gitlab/gitlab-ce:latest'
restart: always
container_name: gitlab
environment:
- GITLAB_OMNIBUS_CONFIG=external_url 'http://192.168.1.100'
- TZ=Asia/Shanghai
ports:
- '80:80'
volumes:
- '/srv/gitlab/config:/etc/gitlab'
- '/srv/gitlab/logs:/var/log/gitlab'
- '/srv/gitlab/data:/var/opt/gitlab'
这个配置文件解释一下：
TZ=Asia/Shanghai详见这篇文章：设定docker容器时间的3种方法
通过 docker-compose up -d gitlab 起来后，别忘记了有一个安全问题，仅内部访问，限制外界访问，详见这篇文章：Docker中限制网络访问中的ext_if是什么?
gitlab起来后，登录 root 的账号，登录后，进行应用管理设置，其中关闭 auto devops 这个功能：
Admin area –> Settings –> CI/CD –> Default to Auto DevOps pipeline for all projects 前面的勾去掉。
修改 /srv/gitlab/config/gitlab.rb，将 prometheus 禁用：
prometheus_monitoring[‘enable’] = false
上述过程做好后，过了一天，发现gitlab运行相当慢，一看服务器内存已经没有了，而且使用了大量的swap，于是上网查如何内存优化 gitlab，找到了这篇讲得很全面的文章：解决GitLab内存消耗大的问题。最终我的优化如下：
unicorn['enable'] = true
unicorn['worker_timeout'] = 60
unicorn['worker_processes'] = 2
unicorn['worker_memory_limit_min'] = "300 * 1 << 20"
unicorn['worker_memory_limit_max'] = "500 * 1 << 20"
sidekiq['concurrency'] = 16
postgresql['shared_buffers'] = "256MB"
postgresql['max_worker_processes'] = 8
重启后，观察了2天，内存始终消耗为 1.5-2 G之间。
上述的内容已经有些过时了，最新的gitlab有些不同了，这里做一些补充
gitlab:
image: 'gitlab/gitlab-ce:latest'
restart: always
container_name: gitlab
environment:
- GITLAB_OMNIBUS_CONFIG=external_url 'http://192.168.1.100:8000'
- TZ=Asia/Shanghai
ports:
- '8000:8000'
volumes:
- '/etc/gitlab/config:/etc/gitlab'
- '/etc/gitlab/logs:/var/log/gitlab'
- '/etc/gitlab/data:/var/opt/gitlab'
puma[‘enable’] = true
puma[‘worker_timeout’] = 60
puma[‘worker_processes’] = 2
puma[‘max_threads’] = 4
puma[‘per_worker_max_memory_mb’] = 1024
sidekiq[‘max_concurrency’] = 16
postgresql[‘shared_buffers’] = “256MB”
postgresql[‘max_worker_processes’] = 8
先进入容器内，docker exec -it gitlab /bin/bash，然后执行 gitlab-rake “gitlab:password:reset”，意外的事情发生了，居然久久没有反应，感觉像死掉一样，过了大概5分钟，才会出来一些提示，在这个5分钟内，假如你等不及敲了一些回车，对不起，这个过程还要重新再来。所以记住：这个过程会很长，不要着急，千万不要敲回车。(这一段是修改密码的，现在的gitlab有设定初始密码的地方，见下面）
root and the password from the following command:docker exec -it gitlab grep ‘Password:’ /etc/gitlab/initial_root_password
Dockerfile中的COPY作用、格式的详细描述不是本文所要涉及的。本文只是聊一下COPY时候要注意的context。
我们先来简单看一下COPY的第一种格式，第二种格式不说了：
COPY <src>... <dest>
dest: 指得是镜像(image)中的路径
src: 指得是Dockerfile所在的context路径
那么COPY的作用就是：将构建镜像的电脑上的文件或者文件夹拷贝到镜像中去。
我们知道，Dockerfile文件往往是放在github上的某个工程里，当我们checkout工程，然后执行 docker build 命令的时候，我们的电脑和作者的电脑肯定不一样的，所以，明白了这一点，基于这样最基本的常识，我们马上就能明白什么样的src是正确的，什么样的src是错误的：
正确：
COPY ./package.json /app/
COPY package.json /usr/src/app/
错误：
COPY ../package.json /app 因为上一层目录大家都不一样的
或者 COPY /opt/xxxx /app 有可能连操作系统都不一样，哪里有什么/opt这样的目录
所以，Dockerfile中的COPY中的context(上下文)指得就是 Dockerfile 所在的工程中的目录结构，离开了这个工程的其他目录都是错误的。
顺便说一下：dest 是可以在镜像中的任意位置的，这个无所谓，不用解释大家都明白了吧。
我们往往通过 -p 来使得外界访问docker中的容器，比如：
docker run -p 80:80 some-app-image
但是有下面几个场景需要知道：
1，其他容器想要访问这个容器的端口，外界不允许访问，这个容易，用docker的network既可以实现。
2，为了安全问题，只允许我所知道的外界来访问这个端口，除此以外我都不允许访问。
第2个场景经常出现，比如某服务器，有外网网卡，其中某个内网应用，通过上面的 -p 开放会使得外网也能访问。对此问题，我记得最早时候的docker是没有提到这个问题的(或者在某个地方我没有注意到)，为此我还专门到网上去查找资料和询问别人，别人和我说需要对iptables进行设置。
后来，我再看docker官方文档的时候，发现了Restrict connections to the Docker daemon，限制连接访问docker，文档中举了几个例子，我们来看一下这个例子：
$ iptables -I DOCKER-USER -i ext_if ! -s 192.168.1.1 -j DROP
-I DOCKER-USER: 表示插入用户自定义的DOCKER-USER的chain中
-i ext_if: 针对 ext_if 网卡
! -s 192.168.1.1 -j DROP: 除了来源是 192.168.1.1 以外的地址全部不能访问
那 ext_if 是什么网卡？难道是 docker 又弄出来的？到网上查了一下，到处没有说起这个 ext_if 是什么，直到我最终在docker的官方文档:where ext_if is the name of the interface providing external connectivity to the host.中找到这样的话才明白，原来这个 ext_if 就是docker daemon所在服务器的网卡名称，也就是说换成比如 eth0 这样的即可。
这个让我想起了一个故事：
微软的很多安装，有时候会蹦出这样的一段话：“请按任意键继续”，于是很多人就打电话去问微软的客服：“请问任意键在键盘中的哪个位置，我怎么找不到这个键啊？”，后来微软为了解决这个歧义，把这句话改成了：“请按空格键继续”。
那么docker文档中的这句话也出现了歧义：iptables -I DOCKER-USER -i ext_if ! -s 192.168.1.1 -j DROP，应该改成这样就好了，否则找了一大圈最后才发现原来出现歧义了：iptables -I DOCKER-USER -i “your_extern_interface” ! -s 192.168.1.1 -j DROP，并且用双引号括起来，这样一来每个人都能明白了。
wind: 风
breeze: 微风
gale: 大风，强风
whirlwind: 旋风
hurricane: 飓风
tornado: 龙卷风
twister: 龙卷风
cyclone: 龙卷风
typhoon: 台风
大部分的容器在制作的时候，时间都是UTC时间（又是格林威治标准时间GMT），所以我们在使用的时候，容器内部时间都是和北京时间相差8小时。
如何设定docker容器时间的3种方法，我们以alpine来举例，在举例之前，需要参考这篇文章《如何对alpine设置时区为Asia/Shanghai》，将alpine的时区功能补全，否则下面的举例不会起效：
1，容器启动后，进入容器内：
docker exec -it xxxx /bin/sh
然后执行下面的语句：
cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
最后看一下时间，看到已经改成正确的：
date
这种方法在容器重启后时间又会回到UTC，所以只有在紧急的情况下才能用一下，这种方法是最不靠谱的。
2，自己做一个以alpine为基础的镜像，增加时区功能，Dockfile如下：
FROM alpine
RUN apk add --no-cache tzdata
ENV TZ=Asia/Shanghai
这种方法的缺点很明显，大部分的镜像都是UTC时间，难道需要每个都做一个自己的镜像？所以这种方法往往用在制作自己应用的镜像时候。
为什么要安装tzdata这个包，见下面的参考资料《Linux – 时区和时间调整方法》，讲得很好。
3，启动容器时，加入环境变量，比如：
docer run -e TZ=Asia/Shanghai --rm myalpine date
这3种方法中，以这种方法最好最灵活。