通过Docker安装GitLab
Docker Compose
Compose项目是Docker官方的开源项目,负责实现对Docker容器集群的快速编排。
Compose 定位是**定义和运行多个Docker容器的应用。
我们知道使用一个Dockerfile模板文件,可以让用户很方便的定义一个单独的应用容器。然而,在日常工作中,经常会碰到需要多个容器相互配合来完成某项任务的情况。例如要实现一个Web项目,除了Web服务容器本身,往往还需要再加上后端的数据库服务容器,甚至还包括负载均衡容器等。
Compose恰好满足了这样的需求。它允许用户通过一个单独的docker-compose.yml
模板文件(YAML格式)来定义一组相关联的应用容器为一个项目。
Compose中两个重要的概念:
- (service):一个应用的容器,实际上可以包括若干运行相同镜像的容器实例。
- 项目 (project):由一组关联的应用容器组成的一个完整业务单元,在
docker-compose.yml
文件中定义。
Compose的默认管理对象是项目,通过子命令对项目中的一组容器进行便捷地生命周期管理。
Compose项目由Python编写,实现上调用了Docker服务提供的API来对容器进行管理。因此,只要所操作的平台支持Docker API,就可以在其上利用Compose来进行编排管理。
Docker部署MySQL
Dockerfile指令
Linux部署java项目
Docker
基本概念
Docker包括三个基本概念:
- 镜像(Image)
- 容器(Container)
- 仓库(Repository)
镜像
作系统分为内核和用户空间。对于 Linux 而言,内核启动后,会挂载root文件系统为其提供用户空间支持。而 Docker 镜像(Image),就相当于是一个root文件系统。
Docker 镜像是一个特殊的文件系统,除了提供容器运行时所需的程序、库、资源、配置等文件外,还包含了一些为运行时准备的一些配置参数(如匿名卷、环境变量、用户等)。镜像不包含任何动态数据,其内容在构建之后也不会被改变。
分层存储
因为镜像包含操作系统完整的root文件系统,其体积往往是庞大的,因此在 Docker 设计时,就充分利用 Union FS 的技术,将其设计为分层存储的架构。所以镜像只是一个虚拟的概念,其实际体现并非由一个文件组成,而是由一组文件系统组成,或者说,由多层文件系统联合组成。
镜像构建时,会一层层构建,前一层是后一层的基础。每一层构建完就不会再发生改变,后一层上的任何改变只发生在自己这一层。比如,删除前一层文件的操作,实际不是真的删除前一层的文件,而是仅在当前层标记为该文件已删除。在最终容器运行的时候,虽然不会看到这个文件,但是实际上该文件会一直跟随镜像。因此,在构建镜像的时候,需要额外小心,每一层尽量只包含该层需要添加的东西,任何额外的东西应该在该层构建结束前清理掉。
分层存储的特征还使得镜像的复用、定制变的更为容易。甚至可以用之前构建好的镜像作为基础层,然后进一步添加新的层,以定制自己所需的内容,构建新的镜像。
GOF23
Nginx架构
Nginx常见问题
- 多个server配置了相同的server_name优先级访问:
优先使用最先读取到的配置 - location匹配优先级:
由高到低分别是:
=
进行普通字符精确匹配,即完全匹配^~
表示普通字符匹配,使用前缀匹配,表示以什么开头~
开头表示区分大小写的正则匹配~*
开头表示不区分大小写的正则匹配/
通用匹配,任何请求都会匹配到
- try_files的使用
用于按顺序检查文件是否存在
location / {
# 首先查找$rui路径是否存在,不存在则查找$uri/路径,如果也不存在则跳转到/index.php目录
try_files $uri $uri/ /index.php
}
- alias和root的区别
# 当访问路径为http://www.test.com/request_path/image/cat.png
# 实际访问路径为/local_path/image/request_path/image/cat.png
location /request_path/image/ {
root /local_path/image/;
}
# 实际访问路径为/local_path/image/cat.png
location /request_path/image/ {
alias /local_path/image/;
}
获取用户真实ip地址
对第一层代理设置头信息存储ip,这样后端服务就可以通过$x_real_ip获得真实ipset x_real_ip = $remote_addr
常见错误码
- 413 Request Entity Too Large
解决方法: 用户上传文件限制client_max_body_size
- 502 bad geteway:后端服务无响应
- 504 Geteway Time-out:后端服务执行超时
性能优化
接口压力测试工具:ab
- 需要先安装
http-tools
- 使用:
ab -n 2000 -c 2 http://127.0..0.1/
- n 总的请求数
- c 并发数
- k 是否开启长连接
设置Nginx文件句柄
# 指定一个nginx进程可以打开的最多文件描述符数目
worker_rlimit_nofile num;
CPU亲和
将nginx设置与当前机器物理cpu个数相等,同时配置核心数
总核心数=cpu个数*每个核心数
# 启动多少个worker进程,建议与cpu总核心数一致,默认1
worker_processes num;
# cpu亲缘 ,将工作进程绑定到CPU组。
worker_cpu_affinity cpumask...;
# 设置工作进程可以打开的最大并发连接数
# 配置在events,默认512
# 这个数字包括所有连接(例如与代理服务器的连接等),而不仅仅是与客户端的连接。另一个考虑因素是实际的并发连接数不能超过最大打开文件数的当前限制,可以通过 worker_rlimit_nofile更改。
worker_connections number;
worker_cpu_affinity配置方法
使用位掩码表示:绑定到cpu0,cpu1,cpu2,cpu3
worker_cpu_affinity 0001 0010 0100 1000;
将工作进程绑定到CPU组,将第一个工作进程绑定到CPU0 / CPU2,将第二个工作进程绑定到CPU1 / CPU3。
worker_processes 2;
worker_cpu_affinity 0101 1010;使用
auto
允许将工作进程自动绑定到可用的CPU:worker_processes auto;
worker_cpu_affinity auto;
Nginx安全
常见恶意行为
爬虫行为和恶意抓取,资源盗用
解决方式:
- 使用基础防盗链功能,不让恶意用户能轻易的爬去网站对外数据
- secure_link_module:对数据安全性提高加密验证和实效性,适合如核心重要数据
- access_module:对后台、部分用户服务的数据提供IP防控
常见攻击手段
- 后台密码撞库:通过猜测密码字典不断对后台系统登录性尝试,获取后台登录密码
解决方式:
- 后台登录密码复杂度
- access_module:对后台提供IP防控
- 预警机制
- 文件上传漏洞:利用这些可以上传文件的接口将恶意代码植入到服务器中,再通过url去访问以执行代码
例如:在Nginx早期版本:
nginx会将其作为php代码执行
解决方式:检查文件上传格式是否合规
location ^~ /upload{
root /opt/app/images;
if($request_filename ~* (.*)\.php){
return 403;
}
}
- SQL注入:利用未过滤,未审核用户输入的攻击方法,让应用运行本不应该运行的SQL代码
解决方式
Nginx+LUA防火墙:拦截Cookie类型攻击,异常post请求,cc攻击(对某一个接口高频率访问),拦截URL,arg(get请求提交的参数)