发表于 | 阅读次数
阅读时长 1

背景说明

考虑到日常运维中涉及到故障的记录、统计等需求，针对不同的产品线、故障类型、级别等开发了运维故障管理系统FMS

善于总结故障，刨根问底，方可预防，减少避免类似问题的出现

项目说明

1
2
3
Python: 3.6
Django: 1.11.0
项目地址: git@github.com:geekwolf/fms.git

功能说明

  • 故障管理(类型、级别等)
  • 项目管理(针对区分不同业务线)
  • 用户管理(用户、用户组)
  • 权限管理
  • 统计Dashboard

部署配置

1
pip3 install -i https://pypi.douban.com/simple/  -r requirements.txt

MySQL配置修改settings.py:

1
2
3
4
5
6
7
8
9
10
DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': 'fms',
        'USER': 'root',
        'PASSWORD': 'xxxx',
        'HOST': '127.0.0.1',
        'PORT': '3306',
    }
}

修改故障通知邮箱settings.py:

1
2
3
4
5
6
7
EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
EMAIL_USE_TLS = False
EMAIL_HOST = 'service.simlinux.com'
EMAIL_PORT = 25
EMAIL_HOST_USER = 'admin@service.simlinux.com'
EMAIL_HOST_PASSWORD = 'xxx'
DEFAULT_FROM_EMAIL = 'geekwolf <admin@service.simlinux.com>'

初始化数据

1
2
3
4
python manage.py makemigrations
python manage.py migrate
python manage.py loaddata default_types
python manage.py loaddata default_user

登录：

1
2
3
python manage.py runserver
http://127.0.0.1:8000
admin admin

Demo





发表于 | 分类于 | 阅读次数
阅读时长 13

Etcd是什么

Etcd是一个分布式、使用Raft算法维护一致性的kv存储系统，与其类似产品有Zookeeper(老牌经典)、Consul等，Etcd相对ZK，更加轻量、易运维。具体三者之间的对比可参考 https://luyiisme.github.io/2017/04/22/spring-cloud-service-discovery-products/

使用场景

和zk、consul等类似，使用场景多用于:

  • 服务发现
  • 消息发布与订阅
  • 负载均衡
  • 分布式锁
  • 分布式队列

读写性能

压测数据参考官方：
https://coreos.com/etcd/docs/latest/op-guide/performance.html

本地集群部署

  • 操作系统:Debian8 x64
  • Etcd v3.2.7

A. 安装

1
2
3
4
5
6
7
wget https://github.com/coreos/etcd/releases/download/v3.2.7/etcd-v3.2.7-linux-arm64.tar.gz
tar xf etcd-v3.2.7-linux-arm64.tar.gz
cd etcd-v3.2.7-linux-amd64
cp etc* /usr/local/bin/
etcd: Etcd服务端文件
etcdctl: 供用户使用的命令客户端

B. 启动服务

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
root@a4c8d490:/home/geekwolf# etcd
2017-09-07 15:42:23.957656 I | etcdmain: etcd Version: 3.2.7
2017-09-07 15:42:23.957699 I | etcdmain: Git SHA: bb66589
2017-09-07 15:42:23.957718 I | etcdmain: Go Version: go1.8.3
2017-09-07 15:42:23.957723 I | etcdmain: Go OS/Arch: linux/amd64
2017-09-07 15:42:23.957729 I | etcdmain: setting maximum number of CPUs to 8, total number of available CPUs is 8
2017-09-07 15:42:23.957739 W | etcdmain: no data-dir provided, using default data-dir ./default.etcd
2017-09-07 15:42:23.957764 N | etcdmain: the server is already initialized as member before, starting as etcd member...
2017-09-07 15:42:23.957995 I | embed: listening for peers on http://localhost:2380
2017-09-07 15:42:23.958107 I | embed: listening for client requests on localhost:2379
2017-09-07 15:42:23.964607 I | etcdserver: name = default
2017-09-07 15:42:23.964633 I | etcdserver: data dir = default.etcd
2017-09-07 15:42:23.964652 I | etcdserver: member dir = default.etcd/member
2017-09-07 15:42:23.964657 I | etcdserver: heartbeat = 100ms
2017-09-07 15:42:23.964663 I | etcdserver: election = 1000ms
2017-09-07 15:42:23.964668 I | etcdserver: snapshot count = 100000
2017-09-07 15:42:23.964680 I | etcdserver: advertise client URLs = http://localhost:2379
2017-09-07 15:42:23.973007 I | etcdserver: restarting member 8e9e05c52164694d in cluster cdf818194e3a8c32 at commit index 14
2017-09-07 15:42:23.973041 I | raft: 8e9e05c52164694d became follower at term 2
2017-09-07 15:42:23.973065 I | raft: newRaft 8e9e05c52164694d [peers: [], term: 2, commit: 14, applied: 0, lastindex: 14, lastterm: 2]
2017-09-07 15:42:23.984367 W | auth: simple token is not cryptographically signed
2017-09-07 15:42:23.993237 I | etcdserver: starting server... [version: 3.2.7, cluster version: to_be_decided]
2017-09-07 15:42:23.993659 I | etcdserver/membership: added member 8e9e05c52164694d [http://localhost:2380] to cluster cdf818194e3a8c32
2017-09-07 15:42:23.993754 N | etcdserver/membership: set the initial cluster version to 3.2
2017-09-07 15:42:23.993796 I | etcdserver/api: enabled capabilities for version 3.2
2017-09-07 15:42:24.473288 I | raft: 8e9e05c52164694d is starting a new election at term 2
2017-09-07 15:42:24.473451 I | raft: 8e9e05c52164694d became candidate at term 3
2017-09-07 15:42:24.473519 I | raft: 8e9e05c52164694d received MsgVoteResp from 8e9e05c52164694d at term 3
2017-09-07 15:42:24.473568 I | raft: 8e9e05c52164694d became leader at term 3
2017-09-07 15:42:24.473605 I | raft: raft.node: 8e9e05c52164694d elected leader 8e9e05c52164694d at term 3
2017-09-07 15:42:24.478746 I | etcdserver: published {Name:default ClientURLs:[http://localhost:2379]} to cluster cdf818194e3a8c32
2017-09-07 15:42:24.478824 I | embed: ready to serve client requests
2017-09-07 15:42:24.479116 N | embed: serving insecure client requests on 127.0.0.1:2379, this is strongly discouraged!

由上面的输出可知：

  • etcd服务之间通信端口是2380，暴露给客户端端口为2379
  • 默认将数据存放到当前路径default.etcd/目录下
  • 该节点的名称默认为default
  • 集群和节点都会生成唯一的uuid
  • 启动服务时，会根据raft算法，选举leader

C. 测试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
查看api版本（默认api版本是v2）
root@a4c8d490:~/k8s/etcd-v3.2.7-linux-amd64# etcdctl  --version
etcdctl version: 3.2.7
API version: 2
使用API V3方法：
Etcd服务端和客户端添加变量 export ETCDCTL_API=3,重新启动etcd服务即可
以下操作在api v3版本:
写入key: etcdctl put foo bar
读取key: etcdctl get foo
多key范围读取: etcdctl get foo foo9(会将foo..foo8的key读取,不包括foo9)
读取过往版本key的值(Etcd键值对的修改都会增加全局修订版本号,--rev为版本号):
 etcdctl get --rev=4 foo foo9
删除key: etcdctl del foo
范围删除(foo-&gt;foo9):etcdctl del foo foo9
观察key变化:etcdctl watch foo
观察范围key变化: etcdctl watch foo foo9
从rev=2版本开始观察key变化: etcdctl watch --rev=2 foo
压缩版本5之前的修订版本(压缩后5之前的版本不可能访问): etcdctl compact 5
授予key有效期:
创建租约: 
$ etcdctl lease grant 10
lease 694d5e5b63a74f31 granted with TTL(10s)
附加key foo到租约694d5e5b63a74f31，该租约过期后，会删除附加的所有key
撤销租约(撤销后，附加改租约的所有key被删除): etcdctl lease revoke 32695410dcc0ca06
维持租约(执行后，会一直维持该租约): etcdctl lease keep-alive 32695410dcc0ca0
其他参数可参考 etcdctl --help
通过HTTP操作：
Etcd v2: https://coreos.com/etcd/docs/latest/v2/api.html
Etcd v3: https://coreos.com/etcd/docs/latest/dev-guide/api_grpc_gateway.html

多节点集群部署

静态模式部署
环境说明(三节点集群)
节点 地址 主机
etcd1 192.168.234.133 etcd1.simlinux.com
etcd2 192.168.234.133 etcd2.simlinux.com
etcd3 192.168.234.133 etcd3.simlinux.com
初始化环境

三个节点分别设置主机名:

1
2
3
hostnamectl --static  set-hostname etcd1.simlinux.com
hostnamectl --static  set-hostname etcd2.simlinux.com
hostnamectl --static  set-hostname etcd3.simlinux.com

三个节点hosts文件添加:

1
2
3
4
vim /etc/hosts
192.168.234.133 etcd1.simlinux.com 
192.168.234.133 etcd2.simlinux.com 
192.168.234.133 etcd3.simlinux.com

生成etcd证书(用于etcd间、客户端与etcd通信)

由上篇k8s部署之使用CFSSL创建证书的CA来生成

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
cat  etcd.json 
{
    "CN": "etcd",
    "hosts": [
        "127.0.0.1",
        "192.168.234.133",
        "192.168.234.134",
        "192.168.234.135"
    ],
    "key": {
        "algo": "ecdsa",
        "size": 256
    },
    "names": [
        {
            "C": "CN",
            "L": "ShangHai",
            "ST": "ShangHai",
            "O": "K8s",
            "OU": "System"
        }
    ]
}
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=peer etcd.json | cfssljson -bare etcd
将CA和etcd证书拷贝到etcd所有节点:
cp ca.pem  etcd-key.pem  etcd.pem /etc/etcd/ssl/
安装etcd节点(所有节点)
1
2
3
4
5
wget https://github.com/coreos/etcd/releases/download/v3.2.7/etcd-v3.2.7-linux-amd64.tar.gz
tar xf etcd-v3.2.7-linux-amd64.tar.gz
cd etcd-v3.2.7-linux-amd64
chmod +x etcd*
cp etcd* /bin
etcd配置
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
服务管理(所有节点相同):
vim /usr/lib/systemd/system/etcd.service
[Unit]
Description=Etcd Server
After=network.target
After=network-online.target
Wants=network-online.target
Documentation=https://github.com/coreos
[Service]
Type=notify
WorkingDirectory=/data/k8s/etcd/
EnvironmentFile=/etc/etcd/etcd.conf
ExecStart=/bin/etcd 
  --name=${NAME} 
  --cert-file=/etc/etcd/ssl/etcd.pem 
  --key-file=/etc/etcd/ssl/etcd-key.pem 
  --peer-cert-file=/etc/etcd/ssl/etcd.pem 
  --peer-key-file=/etc/etcd/ssl/etcd-key.pem 
  --trusted-ca-file=/etc/etcd/ssl/ca.pem 
  --peer-trusted-ca-file=/etc/etcd/ssl/ca.pem 
  --initial-advertise-peer-urls=${INITIAL_ADVERTISE_PEER_URLS} 
  --listen-peer-urls=${LISTEN_PEER_URLS} 
  --listen-client-urls=${LISTEN_CLIENT_URLS} 
  --advertise-client-urls=${ADVERTISE_CLIENT_URLS} 
  --initial-cluster-token=${INITIAL_CLUSTER_TOKEN} 
  --initial-cluster=${INITIAL_CLUSTER} 
  --initial-cluster-state=new 
  --data-dir=${DATA_DIR}
Restart=on-failure
RestartSec=5
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target

配置文件:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
vim /etc/etcd/etcd.conf
#节点名称
NAME="etcd1"
#etcd数据存放目录
DATA_DIR="/data/k8s/etcd"
#etcd节点间通信监听地址
LISTEN_PEER_URLS="https://192.168.234.133:2380"
#对外提供服务的地址
LISTEN_CLIENT_URLS="https://192.168.234.133:2379,https://127.0.0.1:2379"
#通知其他etcd节点本实例地址
INITIAL_ADVERTISE_PEER_URLS="https://192.168.234.133:2380"
#初始化集群内节点地址
INITIAL_CLUSTER="etcd1=https://192.168.234.133:2380,etcd2=https://192.168.234.134:2380,etcd3=https://192.168.234.135:2380"
#初始化状态.new表示新建,已经存在的集群使用existing
INITIAL_CLUSTER_STATE="new"
#创建集群的token,每个集群唯一
INITIAL_CLUSTER_TOKEN="k8s-etcd-cluster"
#告知其他集群本节点客户端监听地址
ADVERTISE_CLIENT_URLS="https://192.168.234.133:2379"
ETCDCTL_API=3
其中NAME/LISTEN_PEER_URLS/LISTEN_CLIENT_URLS/INITIAL_ADVERTISE_PEER_URLS/ADVERTISE_CLIENT_URLS替换成相应节点名称和地址

服务管理
1
2
3
systemctl start etcd.service
systemctl stop etcd.service
systemctl status etcd.service(查看服务状态及日志)
测试验证
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
[root@etcd1 ~]# export etcd1=192.168.234.133
[root@etcd1 ~]# export etcd2=192.168.234.134
[root@etcd1 ~]# export etcd3=192.168.234.135
[root@etcd1 ~]# export ENDPOINTS=$etcd1:2379,$etcd2:2379,$etcd3:2379
查看集群成员:
[root@etcd1 etcd]#  etcdctl --write-out=table --endpoints=$ENDPOINTS --cacert=/etc/etcd/ssl/ca.pem  --cert=/etc/etcd/ssl/etcd.pem --key=/etc/etcd/ssl/etcd-key.pem member list
+------------------+---------+-------+------------------------------+------------------------------+
|        ID        | STATUS  | NAME  |          PEER ADDRS          |         CLIENT ADDRS         |
+------------------+---------+-------+------------------------------+------------------------------+
| 1a4a83ef243ff1c9 | started | etcd2 | https://192.168.234.134:2380 | https://192.168.234.134:2379 |
| 68243ef8797bd1ce | started | etcd1 | https://192.168.234.133:2380 | https://192.168.234.133:2379 |
| fa30209a63d949b0 | started | etcd3 | https://192.168.234.135:2380 | https://192.168.234.135:2379 |
+------------------+---------+-------+------------------------------+------------------------------+
查看集群状态:
[root@etcd1 ~]# etcdctl --write-out=table --endpoints=$ENDPOINTS --cacert=/etc/etcd/ssl/ca.pem  --cert=/etc/etcd/ssl/etcd.pem --key=/etc/etcd/ssl/etcd-key.pem endpoint status
+----------------------+------------------+---------+---------+-----------+-----------+------------+
|       ENDPOINT       |        ID        | VERSION | DB SIZE | IS LEADER | RAFT TERM | RAFT INDEX |
+----------------------+------------------+---------+---------+-----------+-----------+------------+
| 192.168.234.133:2379 | 68243ef8797bd1ce |   3.2.7 |   25 kB |     false |        10 |          9 |
| 192.168.234.134:2379 | 1a4a83ef243ff1c9 |   3.2.7 |   25 kB |     false |        10 |          9 |
| 192.168.234.135:2379 | fa30209a63d949b0 |   3.2.7 |   25 kB |      true |        10 |          9 |
+----------------------+------------------+---------+---------+-----------+-----------+------------+
[root@etcd1 ~]# etcdctl --write-out=table --endpoints=$ENDPOINTS --cacert=/etc/etcd/ssl/ca.pem  --cert=/etc/etcd/ssl/etcd.pem --key=/etc/etcd/ssl/etcd-key.pem endpoint health
192.168.234.135:2379 is healthy: successfully committed proposal: took = 1.374345ms
192.168.234.134:2379 is healthy: successfully committed proposal: took = 2.217525ms
192.168.234.133:2379 is healthy: successfully committed proposal: took = 1.996245ms
保存快照:
[root@etcd1 ~]# etcdctl --write-out=table --endpoints=$ENDPOINTS --cacert=/etc/etcd/ssl/ca.pem  --cert=/etc/etcd/ssl/etcd.pem --key=/etc/etcd/ssl/etcd-key.pem snapshot save my.db
Snapshot saved at my.db
查看快照状态:
[root@etcd1 ~]# etcdctl --write-out=table --endpoints=$ENDPOINTS --cacert=/etc/etcd/ssl/ca.pem  --cert=/etc/etcd/ssl/etcd.pem --key=/etc/etcd/ssl/etcd-key.pem snapshot status my.db
+----------+----------+------------+------------+
|   HASH   | REVISION | TOTAL KEYS | TOTAL SIZE |
+----------+----------+------------+------------+
| 9a496339 |        3 |          8 |      25 kB |
+----------+----------+------------+------------+
恢复数据(要先删除原来数据目录,所有节点操作)：
[root@etcd1 ~]# etcdctl  --endpoints=$ENDPOINTS --cacert=/etc/etcd/ssl/ca.pem  --cert=/etc/etcd/ssl/etcd.pem --key=/etc/etcd/ssl/etcd-key.pem snapshot restore my.db  --data-dir=/data/k8s/etcd/
2017-09-09 02:28:52.439616 I | etcdserver/membership: added member 8e9e05c52164694d [http://localhost:2380] to cluster cdf818194e3a8c32
删除节点:
[root@etcd1 ~]# etcdctl --write-out=table --endpoints=$ENDPOINTS --cacert=/etc/etcd/ssl/ca.pem  --cert=/etc/etcd/ssl/etcd.pem --key=/etc/etcd/ssl/etcd-key.pem member remove 68243ef8797bd1ce
更新节点:
[root@etcd1 ~]# etcdctl --write-out=table --endpoints=$ENDPOINTS --cacert=/etc/etcd/ssl/ca.pem  --cert=/etc/etcd/ssl/etcd.pem --key=/etc/etcd/ssl/etcd-key.pem member update 68243ef8797bd1ce https://192.168.234.133:1111(INITIAL_ADVERTISE_PEER_URLS)
添加节点(删除etcd3，添加etcd4):
export etcd4=192.168.234.136
[root@etcd1 ~]#  etcdctl --endpoints=${etcd1}:2379,${etcd2}:2379 --cacert=/etc/etcd/ssl/ca.pem  --cert=/etc/etcd/ssl/etcd.pem --key=/etc/etcd/ssl/etcd-key.pem  member add etcd4 --peer-urls=http://192.168.234.136:2380

Etcd:从应用场景到实现原理的全方位解读 http://www.infoq.com/cn/articles/etcd-interpretation-application-scenario-implement-principle
Eetcd集群管理 https://coreos.com/etcd/docs/latest/demo.html

发表于 | 分类于 | 阅读次数
阅读时长 3

安装CFSSL

1
2
3
4
curl -s -L -o /bin/cfssl https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
curl -s -L -o /bin/cfssljson https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
curl -s -L -o /bin/cfssl-certinfo https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64
chmod +x /bin/cfssl*

容器相关证书类型

client certificate： 用于服务端认证客户端,例如etcdctl、etcd proxy、fleetctl、docker客户端
server certificate: 服务端使用，客户端以此验证服务端身份,例如docker服务端、kube-apiserver
peer certificate: 双向证书，用于etcd集群成员间通信

创建CA证书

生成默认CA配置
1
2
3
4
mkdir /opt/ssl
cd /opt/ssl
cfssl print-defaults config > ca-config.json
cfssl print-defaults csr > ca-csr.json

修改ca-config.json,分别配置针对三种不同证书类型的profile,其中有效期43800h为5年

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
    {
    "signing": {
        "default": {
            "expiry": "43800h"
        },
        "profiles": {
            "server": {
                "expiry": "43800h",
                "usages": [
                    "signing",
                    "key encipherment",
                    "server auth"
                ]
            },
            "client": {
                "expiry": "43800h",
                "usages": [
                    "signing",
                    "key encipherment",
                    "client auth"
                ]
            },
            "peer": {
                "expiry": "43800h",
                "usages": [
                    "signing",
                    "key encipherment",
                    "server auth",
                    "client auth"
                ]
            }
        }
    }
}

修改ca-csr.config

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
    {
    "CN": "Self Signed Ca",
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "L": "SH",
            "O": "Netease",
            "ST": "SH",            
            "OU": "OT"
        }    ]
}

生成CA证书和私钥

1
2
cfssl gencert -initca ca-csr.json | cfssljson -bare ca -
生成ca.pem、ca.csr、ca-key.pem(CA私钥,需妥善保管)

签发Server Certificate
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
cfssl print-defaults csr &gt; server.json
vim server.json
{
    "CN": "Server",
    "hosts": [
        "192.168.1.1"
       ],
    "key": {
        "algo": "ecdsa",
        "size": 256
    },
    "names": [
        {
            "C": "CN",
            "L": "SH",
            "ST": "SH"
        }
    ]
}
生成服务端证书和私钥
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=server server.json | cfssljson -bare server
签发Client Certificate
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
cfssl print-defaults csr &gt; client.json
vim client.json
{
    "CN": "Client",
    "hosts": [],
    "key": {
        "algo": "ecdsa",
        "size": 256
    },
    "names": [
        {
            "C": "CN",
            "L": "SH",
            "ST": "SH"
        }
    ]
}
生成客户端证书和私钥
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client client.json | cfssljson -bare client
签发peer certificate
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
cfssl print-defaults csr &gt; member1.json
vim member1.json
{
    "CN": "member1",
    "hosts": [
        "192.168.1.1"
    ],
    "key": {
        "algo": "ecdsa",
        "size": 256
    },
    "names": [
        {
            "C": "CN",
            "L": "SH",
            "ST": "SH"
        }
    ]
}
为节点member1生成证书和私钥:
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=peer member1.json | cfssljson -bare member1
针对etcd服务,每个etcd节点上按照上述方法生成相应的证书和私钥
最后校验证书

校验生成的证书是否和配置相符

1
2
3
openssl x509 -in ca.pem -text -noout
openssl x509 -in server.pem -text -noout
openssl x509 -in client.pem -text -noout

k8s集群所需证书

参考

https://coreos.com/os/docs/latest/generate-self-signed-certificates.html

发表于 | 分类于 | 阅读次数
阅读时长 2

首先,在使用Django内置权限管理系统时,settings.py文件要添加

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
INSTALLED_APPS添加:
'django.contrib.auth',
MIDDLEWARE添加:
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.auth.context_processors.auth',
TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [os.path.join(BASE_DIR, 'templates')],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.i18n',
                'django.template.context_processors.media',
                'django.template.context_processors.static',
                'django.template.context_processors.tz',
                'django.contrib.messages.context_processors.messages',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
            ],
        },
    },
]

如何在模板进行权限检查呢？
根据官网说明 https://docs.djangoproject.com/en/1.11/topics/auth/default/#permissions ,已登录用户权限保存在模板变量中,是权限模板代理django.contrib.auth.context_processors.PermWrapper的一个实例，
具体可以查看django/contrib/auth/context_processors.py源码

测试用例:

测试过程中,发现变量压根不存在,没有任何输出;好吧,只能取Debug Django的源码了

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
def auth(request):
    """
    Returns context variables required by apps that use Django's authentication
    system.
    If there is no 'user' attribute in the request, uses AnonymousUser (from
    django.contrib.auth).
    """
    if hasattr(request, 'user'):
        user = request.user
    else:
        from django.contrib.auth.models import AnonymousUser
        user = AnonymousUser()
    print(user, PermWrapper(user), '-----------------------')
    return {
        'user': user,
        'perms': PermWrapper(user),
    }

测试访问接口,发现有的接口有打印权限信息,有的没有，似乎恍然醒悟

1
2
3
4
可以打印权限信息的接口返回:
return render(request, 'fms/fms_add.html', {'request': request, 'form': form, 'error': error})
不能打印权限新的接口返回:
return render_to_response( 'fms/fms.html', data)

render和render_to_response区别
render是比render_to_reponse更便捷渲染模板的方法,会自动使用RequestContext,而后者需要手动添加:

1
return render_to_response(request, 'fms/fms_add.html', {'request': request, 'form': form, 'error': error},context_instance=RequestContext(request))

其中RequestContext是django.template.Context的子类.接受request和context_processors,从而将上下文填充渲染到模板
问题已经很明确，由于使用了render_to_response方法,没有手动添加context_instance=RequestContext(request)导致模板不能使用变量

发表于 | 分类于 | 阅读次数
阅读时长 1

部署环境

  • Centos7.3 x64
  • docker-ce-17.06.0
  • docker-compose-1.15.0
  • Python-2.7.5(系统默认)

部署目标

  • 使用HTTPS协议
  • 支持Clair(在Harbor1.2版本会支持)
支持HTTPS

生产环境最好由权威CA机构签发证书(免费的推荐StartSSL,可参考https://www.wosign.com/Support/Nginx.html),这里为了测试方便使用自签发的证书

  • 创建CA证书

    1
    openssl req  -newkey rsa:4096 -nodes -sha256 -keyout ca.key -x509 -days 365 -out ca.crt

  • 生成CSR公钥

    1
    openssl req  -newkey rsa:4096 -nodes -sha256 -keyout hub.wow.key  -out hub.wow.csr

  • 颁发证书

    1
    openssl x509 -req -days 365 -in hub.wow.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out hub.wow.crt

  • 部署证书

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    cp hub.wow.crt hub.wow.key   /data/harbor/keys/
    vim /data/harbor/harbor.cfg
      hostname = hub.wow
      ui_url_protocol = https
      ssl_cert = /data/harbor/keys/hub.wow.crt
      ssl_cert_key = /data/harbor/keys/hub.wow.key
        cd /data/harbor
        ./prepare  重新生成配置文件
        docker-compose down
        docker-compose up

  • 通过HTTPS访问私有仓库

    1
    2
    3
    4
    5
    WebUI: https://how.wow
    Docker Client:
    [root@hub ~]# docker login -u admin -p Harbor12345 hub.wow
    Login Succeeded

问题

docker login时提示x509: certificate signed by unknown authority
解决方法: 自签名的证书不被系统信任,需要cp ca.crt /etc/docker/certs.d/hub.wow/, 无需重启docker

发表于 | 分类于 | 阅读次数
阅读时长 2

部署环境

  • Centos7.3 x64
  • docker-ce-17.06.0
  • docker-compose-1.15.0
  • Python-2.7.5(系统默认)

Docker及Docker-compose安装

1
2
3
4
5
6
7
8
9
10
11
 yum install -y yum-utils device-mapper-persistent-data lvm2
 yum-config-manager \
    --add-repo \
    https://download.docker.com/linux/centos/docker-ce.repo
 yum-config-manager --enable docker-ce-edge
 yum makecache fast
 systemctl start docker 
 systemctl enable docker
curl -L https://github.com/docker/compose/releases/download/1.15.0/docker-compose-`uname -s`-`uname -m` > /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose

Habor部署配置

1
2
3
4
5
6
7
8
9
10
wget https://github.com/vmware/harbor/releases/download/v1.1.2/harbor-offline-installer-v1.1.2.tgz
tar xf harbor-offline-installer-v1.1.2.tgz
cd harbor/
vim harbor.cfg
hostname = hub.wow
其他默认(http协议)
./install.sh
安装成功后，可以通过http://hub.wow/访问

Docker客户端使用

由于Harbor默认使用的http协议,故需要在Docker client上的Dockerd服务增加–insecure-registry hub.wow
Centos7修改方式为:

1
2
3
4
5
vim /lib/systemd/system/docker.service
ExecStart=/usr/bin/dockerd  --insecure-registry hub.wow
systemctl daemon-reload
systemctl reload docker

1
2
3
4
5
6
7
8
9
10
[root@localhost harbor]# docker login -u admin -p Harbor12345 hub.wow
官方仓库下载busybox镜像
[root@localhost harbor]# docker pull busybox 
[root@localhost harbor]# docker images
REPOSITORY                  TAG                 IMAGE ID            CREATED             SIZE
busybox                     latest              efe10ee6727f        2 weeks ago         1.13MB
本地基于busybox:latest创建标记hub.wow/busybox:latest
[root@localhost harbor]# docker tag busybox:latest hub.wow/project_name/busybox:latest
推送本地镜像busybox:latest 到hub.wow私有仓库
[root@localhost harbor]# docker push hub.wow/project_name/busybox:latest

Harbor服务管理

1
2
cd harbor/
docker-compose -f ./docker-compose.yml  [ up|down|ps|stop|start ]

发表于 | 分类于 | 阅读次数
阅读时长 4

目的

  • 针对特定进程数量做监控报警

思路

  1. 通过Zabbix LLD自动发现：每台机器都跑了什么服务、每个服务应该跑多少进程
  2. Zabbix Agent 30s将当前机器跑了哪些服务、每个服务进程数上报Zabbix Server
  3. 开发给定配置文件proccessInfo.txt: IP 服务名称 进程数量,此配置作为监控依据
  4. proccessInfo.txt配置文件需在每次变更配置时，自动生成最新

配置流程

  1. LLD自动发现脚本
  2. 数据采集脚本
  3. Agent添加Key
  4. Zabbix Server添加模板组
  5. 创建自动发现规则(监控项、报警触发器)
  6. 添加当前进程数监控项(通过Zabbix Trapper方式，由Agent端)
  7. 定义报警内容

具体步骤

LLD自动发现脚本

LLD自动发现,将进程名称及进程总数上报Zabbix Server：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
/usr/bin/python services.py services_list
{
    "data": [
        {
            "{#SERVICENAME}": "192.168.1.2-p_q1_server", 
            "{#TRIGGER_VALUE}": 3
        }, 
        {
            "{#SERVICENAME}": "192.168.1.2-p_world_d2_server", 
            "{#TRIGGER_VALUE}": 1
        }, 
        {
            "{#SERVICENAME}": "192.168.1.2-p_gate_server", 
            "{#TRIGGER_VALUE}": 2
        }, 
        {
            "{#SERVICENAME}": "192.168.1.2-p_world_d1_server", 
            "{#TRIGGER_VALUE}": 1
        }
    ]
}
数据采集上报： /usr/bin/python services.py {HOST.HOST}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
# -*- coding: utf-8 -*-
import json
import commands
import subprocess
import re
import sys
class services_monitor:
        def __init__(self):
            self.zabbix_server_ip = '192.168.1.1'
            self.info_path = '/home/proccessInfo.txt'
            self.data_path = '/tmp/.process_number_monitor.log'
        def ip(self):
            ipstr = '([0-9]{1,3}\.){3}[0-9]{1,3}'
            ipconfig_process = subprocess.Popen("ifconfig", stdout=subprocess.PIPE)
            output = ipconfig_process.stdout.read()
            ip_pattern = re.compile('(inet addr:%s)' % ipstr)
            pattern = re.compile(ipstr)
            iplist = []
            for ipaddr in re.finditer(ip_pattern, str(output)):
                ip = pattern.search(ipaddr.group())
                if ip.group() != "127.0.0.1":
                    iplist.append(ip.group())
            ip = '|'.join(iplist)
            return ip
        def check_proc(self,proc_name):
            cmd = 'ps -ef |grep  %s|grep -v grep|wc -l' % proc_name
            proccess_info = subprocess.Popen(cmd,shell=True,stdout=subprocess.PIPE)
            # list=proccess_info.stdout.read().strip().split('\n')
            procss_num = proccess_info.communicate()[0]
            return procss_num
        def get_info(self,ip):
            service = []
            status, result = commands.getstatusoutput("grep -E '%s' %s" % (str(ip),self.info_path))
            result = result.split('\n')
            for i in result:
                i = list(i.split(' '))
                service.append({"{#SERVICENAME}": i[0].strip() + "-" + i[1].strip(), "{#TRIGGER_VALUE}":int(i[2].strip())})
            data = json.dumps({'data': service}, sort_keys=True, indent=4)
            return data
        def collect_data(self,data):
            data = json.loads(data)["data"]
            commands.getstatusoutput('cat /dev/null &gt;%s' % self.data_path)
            f = open(self.data_path,'a')
            for i  in data:
                name = i['{#SERVICENAME}'].split('-')
                ip = name[0]
                proc_name =  name[1]
                f.write('%s\tproc_num[%s]\t%s' %(ip,i['{#SERVICENAME}'],self.check_proc(proc_name)))
            f.close()
        def send_data(self,data_path):
            status,output = commands.getstatusoutput('/bin/bash -c "zabbix_sender -z  %s  -i  %s &amp;&gt;/dev/null"' % (self.zabbix_server_ip,self.data_path))
            print status,output
if __name__ == '__main__':
    services = services_monitor()
    ip = services.ip()
    data = services.get_info(ip)
    try:
        argv = sys.argv[1]
        if argv == "services_list":
            print data
        else:
            services.collect_data(data)
            services.send_data(services.data_path)
    except IndexError:
        print data

Agent添加Key

1
2
3
vim /usr/local/etc/zabbix_agentd.conf
UserParameter=dzpt.service.process.discovery,/usr/bin/python /home/opt/scripts/services.py services_list
UserParameter=dzpt.service.process.exec[*],/usr/bin/python /home/opt/scripts/services.py  $1

创建自动发现规则

(监控项Trapper方式、报警触发器)

添加当前进程数监控项

定义报警内容

Action中定义(此处略)

将定义好的模板链接到主机或者其他模板即可

最后

使用Zabbix LLD之后，可以设定多久更新一次监控项及监控阀值；当配置文件变更时，无需人为调整阀值和监控项

发表于 | 分类于 | 阅读次数
阅读时长 5

本系列博客主要是学习开涛《亿级流量网站架构核心技术》一书学习笔记及自己的感悟：

架构设计三大定律

墨菲定律

  • 任何事没有表面看起来那么简单
  • 所有的事都会比预计的时间长
  • 可能出错的事情总会出错

  • 担心某种事情发生，那么它就更有可能发生

    康威定律

  • 系统架构师公司组织架构的反映
  • 按照业务闭环进行系统拆分/组织架构划分，实现闭环、高内聚、低耦合，减少沟通成本
  • 如果沟通出现问题，应该考虑进行系统和组织架构的调整
  • 适合时机进行系统拆分，不要一开始就吧系统、服务拆分拆的非常细，虽然闭环，但是每个人维护的系统多，维护成本高
  • 微服务架构的理论基础 - 康威定律 https://yq.aliyun.com/articles/8611
  • 每个架构师都应该研究下康威定律 http://36kr.com/p/5042735.html

二八定律

  • 80%的结果取决于20%的原因

系统设计遵循的原则

1. 高并发原则

无状态

  • 无状态应用，便于水平扩展
  • 有状态配置可通过配置中心实现无状态
  • 实践: Disconf、Yaconf、Zookpeer、Consul、Confd、Diamond、Xdiamond等

拆分

  • 系统维度：按照系统功能、业务拆分，如购物车，结算，订单等
  • 功能维度：对系统功能在做细粒度拆分
  • 读写维度：根据读写比例特征拆分；读多，可考虑多级缓存；写多，可考虑分库分表
  • AOP维度： 根据访问特征，按照AOP进行拆分，比如商品详情页可分为CDN、页面渲染系统，CDN就是一个AOP系统
  • 模块维度：对整体代码结构划分Web、Service、DAO

服务化

  • 服务化演进: 进程内服务-单机远程服务-集群手动注册服务-自动注册和发现服务-服务的分组、隔离、路由-服务治理
  • 考虑服务分组、隔离、限流、黑白名单、超时、重试机制、路由、故障补偿等
  • 实践：利用Nginx、HaProxy、LVS等实现负载均衡，ZooKeeper、Consul等实现自动注册和发现服

消息队列

  • 目的: 服务解耦(一对多消费)、异步处理、流量削峰缓冲等
  • 大流量缓冲： 牺牲强一致性，保证最终一致性(案例：库存扣减，现在Redis中做扣减，记录扣减日志，通过后台进程将扣减日志应用到DB)
  • 数据校对: 解决异步消息机制下消息丢失问题

数据异构

  • 数据异构: 通过消息队列机制接收数据变更，原子化存储
  • 数据闭环: 屏蔽多从数据来源，将数据异构存储，形成闭环

缓存银弹

  • 用户层:

    • DNS缓存
    • 浏览器DNS缓存
    • 操作系统DNS缓存
    • 本地DNS服务商缓存
    • DNS服务器缓存
    • 客户端缓存
    • 浏览器缓存(Expires、Cache-Control、Last-Modified、Etag)* App客户缓存(js/css/image…)

  • 代理层：

    • CDN缓存(一般基于ATS、Varnish、Nginx、Squid等构建,边缘节点-二级节点-中心节点-源站)

  • 接入层：

    • Nginx为例：

    • Proxy_cache： 代理缓存,可以存储到/dev/shm或者SSD

    • FastCGI Cache
    • Nginx+Lua+Redis: 业务数据缓存
    • PHP为例：
      • Opcache： 缓存PHP的Opcodes

  • 应用层：

    • 页面静态化
    • 业务数据缓存(Redis/Memcached/本地文件等)
    • 消息队列

  • 数据层：

    • NoSQL： Redis、Memcache、SSDB等
    • MySQL： Innodb/MyISAM等Query Cache、Key Cache、Innodb Buffer Size等

  • 系统层：

    • CPU : L1/L2/L3 Cache/NUMA
    • 内存
    • 磁盘：磁盘本身缓存、dirty_ratio/dirty_background_ratio、阵列卡本身缓存

并发化

2. 高可用原则

降级

  • 降级开关集中化管理：将开关配置信息推送到各个应用
  • 可降级的多级读服务：如服务调用降级为只读本地缓存
  • 开关前置化：如Nginx+lua(OpenResty)配置降级策略，引流流量；可基于此做灰度策略
  • 业务降级：高并发下，保证核心功能，次要功能可由同步改为异步策略或屏蔽功能

限流

  • 目的: 防止恶意请求攻击或超出系统峰值

  • 实践：

    • 恶意请求流量只访问到Cache
    • 穿透后端应用的流量使用Nginx的limit处理
    • 恶意IP使用Nginx Deny策略或者iptables拒绝

切流量

  • 目的：屏蔽故障机器

  • 实践:

    • DNS: 更改域名解析入口，如DNSPOD可以添加备用IP，正常IP故障时，会自主切换到备用地址;生效实践较慢
    • HttpDNS: 为了绕过运营商LocalDNS实现的精准流量调度
    • LVS/HaProxy/Nginx: 摘除故障节点

可回滚

  • 发布版本失败时可随时快速回退到上一个稳定版本
3. 业务设计原则
  • 防重设计
  • 幂等设计
  • 流程定义
  • 状态与状态机
  • 后台系统操作可反馈
  • 后台系统审批化
  • 文档注释
  • 备份
4. 总结

先行规划和设计时有必要的，要对现有问题有方案，对未来有预案;欠下的技术债，迟早都是要还的。

发表于 | 分类于 | 阅读次数
阅读时长 2

安装i7z及cpufrequtils

1
apt-get install i7z cpufrequtils

常见的CPU工作模式

调速器 描述
ondemand 按需快速动态调整CPU频率， 一有cpu计算量的任务，就会立即达到最大频率运行，等执行完毕就立即回到最低频率（阙值为 95%
performance 运行于最大频率
conservative 按需快速动态调整CPU频率， 一有cpu计算量的任务，就会立即达到最大频率运行，等执行完毕就立即回到最低频率（阙值为 75%）
powersave 运行于最小频率
userspace 运行于用户指定的频率

查看当前CPU工作模式

1
2
3
4
5
查看CPU当前的工作模式
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
查看支持的CPU工作模式
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

由于在Debian 8下默认使用intel_pstate驱动,只支持performance和powersave模式,不同频率驱动程序支持的模式不同
具体可以参考：CPU frequency scaling http://t.cn/R6cQXvp

调整最高性能模式

1
echo 'performance' |tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

CPU调频

1
2
3
4
5
6
7
8
9
10
Usage: cpufreq-set [options] Options:
-c CPU, --cpu CPU       #指定CPU核心号，请注意上图的analyzing CPU数字。
-d FREQ, --min FREQ     #手工指定最小主频速度。（在userspace策略）
-u FREQ, --max FREQ     #手工指定最大主频速度。（在userspace策略）
-g GOV, --governor GOV  #设置工作策略
-f FREQ, --freq FREQ    #设定特定的工作频率（CPU默认档次）
#请参考上图的available frequency steps
-h, --help            #输出这个帮助信息
cpufreq-set  -d 2.4Ghz -u 2.4Ghz

实时查看频率

通过i7z命令可实时查看当前CPU的工作频率

发表于 | 分类于 | 阅读次数
阅读时长 1

Nginx代理配置

增加如下配置:

1
2
3
4
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X_FORWARDED_PROTO https;
proxy_set_header Host $host;

Haproxy配置

1
option forwardfor

后端Nginx配置

1
2
3
set_real_ip_from  1.1.1.1;  前端Nginx代理或者负载均衡的IP(在后端Nginx日志中显示的)
real_ip_header  X-Forwarded-For;
real_ip_recursive  on;

后端Nginx访问控制

1
2
3
4
5
6
7
8
9
10
location ~ /test/api/ {
    set $allow false;
    if ($http_x_forwarded_for ~ "2.2.2.2") {
        set $allow false;
                    }
    if ($allow = false) { return 403;}
        proxy_pass  http://web;
    }
}

参考