告警时将告警信息及当前一段时间趋势图发送邮件或word文档
注意:如果脚本不能正常运行，请检查权限
配置Actions注意:Default subject格式：{ITEM.ID}|Ploblem|{TRIGGER.NAME}
修改触发器，进行报警测试
生成报表
|
|
说明
报表功能比较简单，可以根据自身情况，修改代码，进行定制
|
|
最后，拷贝dist下的文件就可以使用了，不需在安装依赖
故障一般是指生产环境出现服务不可用、不稳定、服务性能降低等事件导致用户或玩家体验变差或功能不可用的问题;墨菲定律告诉我们:
无论故障发生的概率有多小，只要有出现的可能，它总会发生；同样海恩法则也警告我们：每一起严重事故的背后，必然有29次轻微事故和300次未遂先兆，以及1000个事故隐患，也就是说任何严重事故背后都是有很多次小问题的积累，当达到一定量级时就会导致质变，出现严重的问题；所以为了保证SLA，提前发现、准确定位、避免二次出现故障，解决责任界限不清晰，主导改进不明确等问题，甚至故障自愈，减少对项目的影响，我们需要一个规范可遵循的故障管理原则
为了衡量影响范围及影响程度，与PM、产品、开发共同确定统一的判断标准，避免后期复盘故障出现推卸责任及无所谓的问题。故障等级一般会根据MTBF(平均故障间隔时间，越长表示可靠性越高)、MTTR(平均恢复时间，越短表示影响越小)、MTTF(平均失效时间，系统平均正常运行多长时间，发生一次故障;可靠性越高，平均无故障时间越长)等作为衡量标准。根据我们游戏运营情况，按照影响玩家数量及故障时间来进行故障的定级：
故障分析报告模板：
针对未知故障，抽象检测脚本，在遇到二次故障告警时，通过Zabbix远程执行相关处理逻辑；可以参考蓝鲸的做法，将自愈作为套餐去消费
根据上述故障管理思路，开发了FMS故障管理系统，功能点如下图：
https://github.com/geekwolf/fms.git
有什么好的建议欢迎提issue~
由于游戏项目日志目前不够规范,不太容易根据字段结构化数据,开发又有实时查看生产和测试环境服务运行日志需求;如果写入ES通过Kibana查看,对于非分析类查看还是不太友好,当然也可以通过LogTrail插件
注释: 由于Logstash无法处理输出到文件乱序的问题，可通过不同的文件使用不同的Logstash,单线程归档；或者直接写入ES(基于@timestamp)、通过Flink输出到文件
|
|
|
|
|
|
笔者在测试Logstash单线程输出时，依然产生乱序问题(有知晓的可以留言),最终选择通过自己开发的daemon程序实现,参考Plogstash:123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244# -*- coding: utf-8 -*-# @Author: Geekwolf# @Date: 2018-01-29 14:23:04# @Last Modified by: Geekwolf# @Last Modified time: 2018-01-31 10:55:01#!/usr/bin/env python3# daemon.pyimport osimport sysimport timeimport redisimport jsonimport reimport atexitimport signal# import collectionsclass Base(object): def __init__(self, *args, **kwargs): self.pidfile = '/var/run/plogstash.pid' self.service_name = 'Plogstash' self.path = '/var/log/plogstash' os.makedirs(self.path, exist_ok=True) self.logfile = '%s/%s.log' % (self.path, self.service_name) self.redis_host = '127.0.0.1' self.redis_password = 'geekwolf' self.redis_port = 5044 self.redis_db = 0 self.redis_key = 'filebeat' self.batch_size = 5000 self.expires = 5 # second self.archive_time = 1 # how long time to archive self.base_dir = '/data/logs' # self._tmp = '/tmp/.%s' % self.service_nameclass Daemon(Base): def __init__(self, *args, **kwargs): super(Daemon, self).__init__(*args, **kwargs) def daemonize(self): # First fork (detaches from parent) try: if os.fork() > 0: raise SystemExit(0) # Parent exit except OSError as e: raise RuntimeError('fork #1 failed.') os.chdir('/') # set this will 777 # os.umask(0) os.setsid() # Second fork (relinquish session leadership) try: if os.fork() > 0: raise SystemExit(0) except OSError as e: raise RuntimeError('fork #2 failed.') # Flush I/O buffers sys.stdout.flush() sys.stderr.flush() # Replace file descriptors for stdin, stdout, and stderr with open(self.logfile, 'ab', 0) as f: os.dup2(f.fileno(), sys.stdout.fileno()) with open(self.logfile, 'ab', 0) as f: os.dup2(f.fileno(), sys.stderr.fileno()) with open(self.logfile, 'rb', 0) as f: os.dup2(f.fileno(), sys.stdin.fileno()) # Write the PID file print(os.getpid()) with open(self.pidfile, 'w') as f: print(os.getpid(), file=f) # Arrange to have the PID file removed on exit/signal atexit.register(lambda: os.remove(self.pidfile)) # Signal handler for termination (required) def sigterm_handler(signo, frame): raise SystemExit(1) signal.signal(signal.SIGTERM, sigterm_handler) def get_now_date(self): return time.strftime('%Y-%m-%d', time.localtime(time.time())) def get_now_timestamp(self): return time.time() def get_now_time(self): return time.strftime("%Y-%m-%d %H:%M:%S", time.localtime()) def logging(self, msg): with open(self.logfile) as f: print('%s %s' % (self.get_now_time(), msg)) def append_log(self): pass def start(self): if os.path.exists(self.pidfile): raise RuntimeError('Already running') else: try: self.daemonize() self.append_log() self.status() except RuntimeError as e: print(e, file=sys.stderr) raise SystemExit(1) def stop(self): # f = os.open(self.pipe_path, os.O_RDONLY | os.O_NONBLOCK) # ret = os.read(f, 1024).decode('utf-8') # print(ret.split('\n')) # os.close(f) if os.path.exists(self.pidfile): # with open(self._tmp) as f: # _data = f.read() # if _data is not None and len(eval(_data)) > 0: # for k, v in eval(_data).items(): # v = v['fd'].rstrip('\n') # v.close() with open(self.pidfile) as f: os.kill(int(f.read()), signal.SIGTERM) print('Plogstash is stopped') else: print('Not running', file=sys.stderr) raise SystemExit(1) def restart(self): self.stop() self.start() def status(self): try: with open(self.pidfile, 'r') as f: pid = int(f.read().strip()) except: pid = None if pid: print('%s is running as pid:%s' % (self.service_name, pid)) else: print('%s is not running' % self.service_name)class Worker(Daemon): def __init__(self, *args, **kwargs): super(Worker, self).__init__(self, *args, **kwargs) def _redis(self): pool = redis.ConnectionPool(host=self.redis_host, password=self.redis_password, port=self.redis_port, db=self.redis_db, socket_timeout=10000) rc = redis.StrictRedis(connection_pool=pool) return rc def get_redis_data(self): _data = self._redis().lrange(self.redis_key, 0, self.batch_size - 1) # 删除数据(可考虑处理完再删除) return _data def del_redis_data(self): _data = self._redis().ltrim(self.redis_key, self.batch_size, -1) def append_log(self): file_meta = {} # file_handler = collections.defaultdict(dict) # try: # os.mkfifo(self.pipe_path) # except Exception as e: # print(str(e)) # pipe_ins = os.open(self.pipe_path, os.O_SYNC | os.O_CREAT | os.O_RDWR) while True: time.sleep(self.archive_time) _data = self.get_redis_data() if _data: for _d in _data: try: _d = json.loads(_d.decode('utf-8')) _path = '%s/%s/%s/%s' % (self.base_dir, _d['fields']['env'], self.get_now_date(), _d['fields']['ip_address']) os.makedirs(_path + '/logs', exist_ok=True) file_name = _d['source'].split('/')[-1] # _path = '%s/%s/%s/%s' % (self.base_dir, _d['fields']['env'],self.get_now_date(), _d['fields']['ip_address']) if re.match('nohup', file_name): file_path = '%s/%s' % (_path, file_name) else: file_path = '%s/logs/%s' % (_path, file_name) with open(file_path, 'a') as f: f.write(_d['message'] + '\n') # if 'fd' not in file_handler[file_path]: # f = open(file_path, 'a', buffering=1024000) # file_handler[file_path]['fd'] = str(f) # file_handler[file_path]['time'] = self.get_now_timestamp() except Exception as e: self.logging(str(e)) self.del_redis_data() # with open(self._tmp, 'w') as f: # f.write(json.dumps(file_handler))if __name__ == '__main__': if len(sys.argv) != 2: print('Usage: {} [start|stop|restart|status]'.format(sys.argv[0]), file=sys.stderr) raise SystemExit(1) daemon = Worker() if sys.argv[1] == 'start': daemon.start() elif sys.argv[1] == 'stop': daemon.stop() elif sys.argv[1] == 'restart': print("Restart ...") daemon.restart() elif sys.argv[1] == 'status': daemon.status() else: print('Unknown command {!r}'.format(sys.argv[1]), file=sys.stderr) raise SystemExit(1)
Zabbix自3.4.5rc1版本开始支持Elasticsearch作为历史数据存储，17年12月28日发布了3.4.5
安装Elasticsearch和Kibana:123456789echo "deb http://http.debian.net/debian jessie-backports main" >>/etc/apt/source.listecho "deb https://artifacts.elastic.co/packages/6.x/apt stable main" > /etc/apt/sources.list.d/elastic-6.x.listwget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -apt-get -y updateapt-get install -t jessie-backports openjdk-8-jdkupdate-java-alternatives -s java-1.8.0-openjdk-amd64apt-get install -y elasticsearch kibana
配置Elasticsearch和Kibana(两者在同一台机):
|
|
启动Elasticsearch和kibana服务
|
|
注: 由于Zabbix3.4.5对libcurl库要求在7.20.0或者更高，Debian 8下面默认是7.38.0
|
|
|
|
说明:
Elasticsearch支持的监控项类型:uint,dbl,str,log,text
监控项数据类型|数据库表|对应Elasticsearch类型:
|
|
注: 3.4.0升级到3.4.5后，请勿使用旧的zabbix.conf.php，根据新的zabbix.conf.php.example重新配置
|
|
Zabbix配置ES成功后,通过Kibana可以看到：
创建索引
通过Zabbix Web访问是否正常显示数据
websocket是HTML5开始提供的一种新协议,用于浏览器和服务器之间实现全双工通讯的技术。本质上是基于tcp协议,先通过HTTP/HTTPS协议发起一条特殊的http请求进行握手后,创建一个用于双向数据交换的tcp连接,此后服务端与客户端通过此连接进行实时通信。在websocket之前实现全双工通讯一般使用轮训、SSE(Server-Sent Event,服务端推送事件)、Comet技术
在客户端，new WebSocket实例化一个新的WebSocket客户端对象，请求类似 ws://yourdomain:port/path 的服务端WebSocket URL，客户端WebSocket对象会自动解析并识别为WebSocket请求，并连接服务端端口，执行双方握手过程，客户端发送数据格式类似：
|
|
可以看到，客户端发起的WebSocket连接报文类似传统HTTP报文，Upgrade：websocket参数值表明这是WebSocket类型请求，Sec-WebSocket-Key是WebSocket客户端发送的一个 base64编码的密文，要求服务端必须返回一个对应加密的Sec-WebSocket-Accept应答，否则客户端会抛出Error during WebSocket handshake错误，并关闭连接。服务端收到报文后返回的数据格式类似：
|
|
Sec-WebSocket-Accept的值是服务端采用与客户端一致的密钥计算出来后返回客户端的，HTTP/1.1 101 Switching Protocols表示服务端接受WebSocket协议的客户端连接，经过这样的请求-响应处理后，两端的WebSocket连接握手成功, 后续就可以进行TCP通讯了
注释: WebSocket标识符是ws(如果加密,则是wss),如上图所示
WSGI
大家都知道WSGI,即Web Server Gateway Interface,是服务器和客户端交互的接口规范，符合这种借口的application可以在所有符合该接口的server上运行，解耦了server和application;web组件被分成三类：client、server、middleware
如上图所示
ASGI
由于WSGI协议支持HTTP,ASGI(Asynchronous Server Gateway Interface)在此基础上应运而生，对WSGI协议进行兼容和扩展，能够处理多种通用协议如HTTP、HTTP2、WebSocket，允许这些协议能通过网络或本地socket进行传输，以及让不同的协议被分配到不同的进程中
ASGI由三个不同的组件组成:协议服务、频道层(Channnel Layer)、应用层；其中Channel Layer是最重要的部分，同时对协议服务和应用提供接口；
大概了解ASGI规范之后，看下django基于ASGI协议实现HTTP/HTTP2/WebSocket的模块Channels,安装好channels后，django将有原来的request-response模式，转换成worker工作模式；并没有运行单独的wsgi进程，而是分成了三层:
下面用例子来看下如何使用Channels: 实现Zabbix报警实时传送到客户端
描述:
目录结构:123456789101112131415161718192021222324252627282930313233monitor├── monitor│ ├── celery.py│ ├── consumers.py│ ├── __init__.py│ ├── routing.py│ ├── settings.py│ ├── urls.py│ └── wsgi.py├── commands│ ├── admin.py│ ├── apps.py│ ├── __init__.py│ ├── management│ │ ├── commands│ │ │ ├── alert.py│ │ │ ├── __init__.py│ │ │ └── __pycache__│ │ ├── __init__.py│ │ └── __pycache__│ ├── migrations│ │ ├── __init__.py│ │ └── __pycache__│ ├── models.py│ ├── __pycache__│ ├── tests.py│ └── views.py├── static├── templates│ ├── base| |—— base.html├── README.md├── requirements.txt
|
|
|
|
|
|
|
|
|
|
|
|
|
|
访问http://192.168.1.1:8000,运行test.py脚本
- 利用Socket.IO实现消息实时推送 http://www.wukai.me/2017/08/27/push-message-with-socketio/
- WebSocket相关资料 http://www.52im.net/thread-331-1-1.html
- WSGI规范 http://wsgi.tutorial.codepoint.net/application-interface
- Channels文档:http://channels.readthedocs.io
- Chat Example： https://gearheart.io/blog/creating-a-chat-with-django-channels/
- Websocket 5分钟从入门到精通 https://segmentfault.com/a/1190000012709475
考虑到日常运维中涉及到故障的记录、统计等需求，针对不同的产品线、故障类型、级别等开发了运维故障管理系统FMS
善于总结故障，刨根问底，方可预防，减少避免类似问题的出现
|
|
|
|
MySQL配置修改settings.py:
|
|
修改故障通知邮箱settings.py:1234567EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'EMAIL_USE_TLS = FalseEMAIL_HOST = 'service.simlinux.com'EMAIL_PORT = 25EMAIL_HOST_USER = 'admin@service.simlinux.com'EMAIL_HOST_PASSWORD = 'xxx'DEFAULT_FROM_EMAIL = 'geekwolf <admin@service.simlinux.com>'
|
|
登录：123python manage.py runserverhttp://127.0.0.1:8000admin admin
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
A. 安装1234567wget https://github.com/coreos/etcd/releases/download/v3.2.7/etcd-v3.2.7-linux-arm64.tar.gztar xf etcd-v3.2.7-linux-arm64.tar.gzcd etcd-v3.2.7-linux-amd64cp etc* /usr/local/bin/etcd: Etcd服务端文件etcdctl: 供用户使用的命令客户端
B. 启动服务123456789101112131415161718192021222324252627282930313233root@a4c8d490:/home/geekwolf# etcd2017-09-07 15:42:23.957656 I | etcdmain: etcd Version: 3.2.72017-09-07 15:42:23.957699 I | etcdmain: Git SHA: bb665892017-09-07 15:42:23.957718 I | etcdmain: Go Version: go1.8.32017-09-07 15:42:23.957723 I | etcdmain: Go OS/Arch: linux/amd642017-09-07 15:42:23.957729 I | etcdmain: setting maximum number of CPUs to 8, total number of available CPUs is 82017-09-07 15:42:23.957739 W | etcdmain: no data-dir provided, using default data-dir ./default.etcd2017-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:23802017-09-07 15:42:23.958107 I | embed: listening for client requests on localhost:23792017-09-07 15:42:23.964607 I | etcdserver: name = default2017-09-07 15:42:23.964633 I | etcdserver: data dir = default.etcd2017-09-07 15:42:23.964652 I | etcdserver: member dir = default.etcd/member2017-09-07 15:42:23.964657 I | etcdserver: heartbeat = 100ms2017-09-07 15:42:23.964663 I | etcdserver: election = 1000ms2017-09-07 15:42:23.964668 I | etcdserver: snapshot count = 1000002017-09-07 15:42:23.964680 I | etcdserver: advertise client URLs = http://localhost:23792017-09-07 15:42:23.973007 I | etcdserver: restarting member 8e9e05c52164694d in cluster cdf818194e3a8c32 at commit index 142017-09-07 15:42:23.973041 I | raft: 8e9e05c52164694d became follower at term 22017-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 signed2017-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 cdf818194e3a8c322017-09-07 15:42:23.993754 N | etcdserver/membership: set the initial cluster version to 3.22017-09-07 15:42:23.993796 I | etcdserver/api: enabled capabilities for version 3.22017-09-07 15:42:24.473288 I | raft: 8e9e05c52164694d is starting a new election at term 22017-09-07 15:42:24.473451 I | raft: 8e9e05c52164694d became candidate at term 32017-09-07 15:42:24.473519 I | raft: 8e9e05c52164694d received MsgVoteResp from 8e9e05c52164694d at term 32017-09-07 15:42:24.473568 I | raft: 8e9e05c52164694d became leader at term 32017-09-07 15:42:24.473605 I | raft: raft.node: 8e9e05c52164694d elected leader 8e9e05c52164694d at term 32017-09-07 15:42:24.478746 I | etcdserver: published {Name:default ClientURLs:[http://localhost:2379]} to cluster cdf818194e3a8c322017-09-07 15:42:24.478824 I | embed: ready to serve client requests2017-09-07 15:42:24.479116 N | embed: serving insecure client requests on 127.0.0.1:2379, this is strongly discouraged!
由上面的输出可知：
C. 测试12345678910111213141516171819202122232425262728293031查看api版本（默认api版本是v2）root@a4c8d490:~/k8s/etcd-v3.2.7-linux-amd64# etcdctl --versionetcdctl version: 3.2.7API 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->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 10lease 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.htmlEtcd 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.134 | etcd2.simlinux.com |
| etcd3 | 192.168.234.135 | etcd3.simlinux.com |
三个节点分别设置主机名:123hostnamectl --static set-hostname etcd1.simlinux.comhostnamectl --static set-hostname etcd2.simlinux.comhostnamectl --static set-hostname etcd3.simlinux.com
三个节点hosts文件添加:1234vim /etc/hosts192.168.234.133 etcd1.simlinux.com 192.168.234.134 etcd2.simlinux.com 192.168.234.135 etcd3.simlinux.com
生成etcd证书(用于etcd间、客户端与etcd通信)
- etcdctl等客户端与etcd服务通信证书
- etcd服务之间通信证书
由上篇k8s部署之使用CFSSL创建证书的CA来生成
|
|
|
|
|
|
配置文件:123456789101112131415161718192021vim /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表示新建,已经存在的集群使用existingINITIAL_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替换成相应节点名称和地址
|
|
|
|
Etcd:从应用场景到实现原理的全方位解读 http://www.infoq.com/cn/articles/etcd-interpretation-application-scenario-implement-principle
Eetcd集群管理 https://coreos.com/etcd/docs/latest/demo.html
|
|
client certificate： 用于服务端认证客户端,例如etcdctl、etcd proxy、fleetctl、docker客户端
server certificate: 服务端使用，客户端以此验证服务端身份,例如docker服务端、kube-apiserver
peer certificate: 双向证书，用于etcd集群成员间通信
|
|
修改ca-config.json,分别配置针对三种不同证书类型的profile,其中有效期43800h为5年12345678910111213141516171819202122232425262728293031323334{"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.json123456789101112131415{"CN": "Self Signed Ca","key": { "algo": "rsa", "size": 2048},"names": [ { "C": "CN", "L": "SH", "O": "Netease", "ST": "SH", "OU": "OT" } ]}
生成CA证书和私钥12cfssl gencert -initca ca-csr.json | cfssljson -bare ca -生成ca.pem、ca.csr、ca-key.pem(CA私钥,需妥善保管)
|
|
|
|
|
|
校验生成的证书是否和配置相符123openssl x509 -in ca.pem -text -nooutopenssl x509 -in server.pem -text -nooutopenssl x509 -in client.pem -text -noout
https://coreos.com/os/docs/latest/generate-self-signed-certificates.html
首先,在使用Django内置权限管理系统时,settings.py文件要添加1234567891011121314151617181920212223242526INSTALLED_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的源码了123456789101112131415161718def 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), }
测试访问接口,发现有的接口有打印权限信息,有的没有，似乎恍然醒悟1234可以打印权限信息的接口返回: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,而后者需要手动添加:1return 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)导致模板不能使用变量
生产环境最好由权威CA机构签发证书(免费的推荐StartSSL,可参考https://www.wosign.com/Support/Nginx.html),这里为了测试方便使用自签发的证书
创建CA证书
|
|
生成CSR公钥
|
|
颁发证书
|
|
部署证书
|
|
通过HTTPS访问私有仓库
|
|
docker login时提示x509: certificate signed by unknown authority
解决方法: 自签名的证书不被系统信任,需要cp ca.crt /etc/docker/certs.d/hub.wow/, 无需重启docker