0%

前言

上一篇文章中,我们以本地开发环境为背景,完成了一个Flask通过Consul获取运行配置的demo。接下来,我们更进一步,模拟生产环境的需求,把这个demo运行在docker集群中,并完成横向扩容。

在这个过程中,我们会陆续遇到很多在现实生产场景中遇到的问题,比如说:

  • 如何规划一个高效又稳妥的发布方案?

  • 把服务封装成容器之后,要怎样配合consul实现自动注册和健康检查?

  • 横向扩容之后,每个节点的IP地址都不一样,不可以hard code到代码中,如何兼顾灵活和高效?

  • 多节点部署docker容器后,怎样才能方便地实现负载均衡?

而在接下来的内容中,上面的问题都会得到妥善解决。

先来看看架构图:

docker-consul

阅读全文 »

背景

最近笔者在对一个业务集群进行微服务的改造,其中就涉及到配置分离的场景。经过和开发组同事共同论证后,最终选择了当前很流行的kubernetes + consul架构。今天先来介绍一个demo,大致介绍consul配置中心的实现原理,也可以把这个当成是本地开发环境调试的参考。

demo架构以及设计思路

架构图如下:

python-consul-redis-demo-diagram

阅读全文 »

背景

笔者目前在一家从事手机游戏开发的公司担任运维岗,为了方便测试,我们往往会在办公电脑里面安装安卓模拟器去运行我们开发的游戏。在日常的工作中,会遇到一些场景需要对游戏APP进行抓包分析,下面来分享一些工作经验。

工具介绍

Whistle

Github地址:https://github.com/avwo/whistle

Whistle是基于 Node 实现的跨平台抓包调试代理工具,支持多种协议,并具有丰富的功能。

阅读全文 »

1. 前言

在2021年的当下,Ansible得益于自身配置简单功能丰富等优点,已经是一个很流行的自动化运维工具了。

而在笔者日常的工作场景中,当首选方案企业版蓝鲸系统作业平台处于维护状态或者是不可用时,会使用ansible作为自动化部署的备用方案。

今天来简单假设一个需求,为多台服务器批量安装zabbix-agent,通过这个过程介绍一下ansible-playbook的使用和编排方法。

我会假设你已经成功安装好了ansible,并且掌握ansible的基本使用方法。如果你没有,这里有个好东西: Installation Guide

阅读全文 »

1. 前言

在本专题介绍到的Elastic Stack的各个场景中,一直都没有涉及到通信安全的内容。一则是因为我们这一套环境是建立在内网,相对来说比较安全;二则是不想在初期就引入太多复杂的内容。然而,在实际的生产环境中,通信安全仍然是一个很重要的议题。

在当前的这个实验环境中,这个ELK集群一直都处于一个不设防的状态,不仅是没有做任何的数据加密,连最简单的账号密码认证都没有。今天我们就来尝试一下,从0开始,一步一步地完善整个集群的安全设置。

kibana-login

阅读全文 »

缘起

有一天,小明和小红在课堂上传纸条又被老师抓了个现行,还被破获了他们俩放学后去打超级玛丽的计划。这让两个小朋友很是懊悔,遂一起商量着要发明一套密语。就算被班主任抓住了,也没办法破译纸条里面的内容。

约定

聪明的小明很快就想出了一个酷炫的加密方式,遂找上小红,开始介绍他的方案。

小明拿出纸和笔,耐心地跟小红讲解起来了:“首先,我们需要两个质数,为了计算方便,我们选择$13$和$17$。”

小红很快反应过来:“对,我在读四年级的时候,数学老师有教过,质数就是除了$1$和本身之外没有其他因数的整数。”

“真是个小聪明!”小明很是欣慰,“那老师一定也教过欧拉函数吧?”

小红略作思考,失望地摇了摇头,说:“我没学过耶。”

“没关系的,我简单给你说说。”小明忙不迭地安慰小红,“我们已经选好了$13$和$17$两个质数,那我们算出一个$n=13×17=221$,那么欧拉函数$\varphi(n)=(13-1)×(17-1)=192$。”

阅读全文 »

1. 前言

我们搭建这一套ELK以来,一直都只是在关注怎么去使用和配置,截止至Day7,我们这一套基于ELK的日志监控和统计方案已经初具雏形,是时候考虑一下监控ELK本身了。

完善的监控有助于让我们实时了解到集群的运行状况,及时发现故障或者是高负载的情况,避免影响业务。同时,在足够多的监控数据的支持下,我们可以提前预知系统负载,提前做好扩容准备;或者是及时发现性能瓶颈或者是不合理的配置项,避免引起更大的问题。

在接下来的内容,我们会通过Metricbeat的简单示例配置,再配合Elastic Stack中的X-Pack实现集群的性能监控。

example

阅读全文 »

1. 前言

来了个新需求(假装不是一个人在战斗)。

网站是运行在一个公网带宽只有4Mbps的云服务器上,偶尔我会担心这条小水管会影响到用户体验,顺便我也想知道一下这个网站一共会产生多少公网流量,所以,就有了这次需求:

  1. 监控每个HTTP请求的处理时间
  2. 统计Nginx服务产生的流量

最后好不容易完成了,成果如下:

result

阅读全文 »