hadoop入门之完全分布式部署
需求前几天某机构老师向我推销大数据课程，看了他们的教学大纲第一阶段就是学“Java SE核心知识”，作为运维觉着现在再学Java有点力不从心啊；而这位老师也表示“没有Java基础，没法学大数据”。于是乎就产生了这样一个想法：对于我们这种没有Java基础的运维人，是否可以在大数据走出一条属于自己路？那就从此文开始学习起来吧。集群准备1.设置hosts及jdk#所有节点配置#配置hosts10.10.10.56 hadoop110.10.10.57 hadoop210.10.10.58 had
Prometheus+k8s之告警通知
需求集群外独立部署Prometheus+Grafana监控K8S全面解析一文剖析了k8s的监控，但是无法在grafana dashboard中配置告警，因此我们需要额外在Prometheus单独配置告警规则，配合AlertManager实现告警。
python入门操作HDFS
0.安装mkvirtualenv -p python3.6 -a hadoop hadooppip install hdfs1.配置vim ~/.hdfscli.cfg[global]default.alias = dev[dev.alias]url = http://dev.namenode:portuser = ann[prod.alias]url = http://prod.namenode:portroot = /jobs/命令行界面1.上传、下载文件# 命令帮
一套包含完整前后端的系统如何在K8S中部署？
需求实际应用中，一个系统往往是包含前后端的，通常前端使用Vue，后端使用Springboot。而之前我们只是在K8S中配置过后端Springboot项目，现在我们需要将完整的系统部署到K8S集群中，通过本次部署可以具体分析如何部署，为日后上线生产环境做好充足的准备。前端前端如果使用的Vue开发，需要将打包后的dist放到Web容器的root目录下，在此我们使用Deployent来部署Nginx pod。1.root目录Nginx镜像默认配置文件中指定的root目录为/usr/share/nginx
运维思索：系统监控体系
简述各位小伙伴，近期技术文感觉发的有点多，不知是否给大家在工作中解决实际问题带来了一些灵感。为什么这么说呢？因为正是文章中涉及的细小知识点积少成多，让我从零碎繁忙的运维工作中得到了一定程度的解放。相信认真读过的小伙伴，一定会觉得工作中并非只有什么高大上的技术才能解决痛点，恰恰相反，正是那些我们平时忽视的细节才是问题的要害。那么只有切中要害，我们才能对症下药。因此接下来一段时间，我可能会陆续分享运维过程中对一些问题的思考，希望给大家带来一定的启发。本次分享的是确立一套运维监控体系，构建可持续成长的监控平
运维思索：运维管理与运维自动化
简述各位小伙伴，近期技术文感觉发的有点多，不知是否给大家在工作中解决实际问题带来了一些灵感。为什么这么说呢？因为正是文章中涉及的细小知识点积少成多，让我从零碎繁忙的运维工作中得到了一定程度的解放。相信认真读过的小伙伴，一定会觉得工作中并非只有什么高大上的技术才能解决痛点，恰恰相反，正是那些我们平时忽视的细节才是问题的要害。那么只有切中要害，我们才能对症下药。因此接下来一段时间，我可能会陆续分享运维过程中对一些问题的思考，希望给大家带来一定的启发。本次分享的是运维管理与运维自动化的思考。一、运维的工作
运维思索：cmdb与zabbix监控系统的融合
简述各位小伙伴，近期技术文感觉发的有点多，不知是否给大家在工作中解决实际问题带来了一些灵感。为什么这么说呢？因为正是文章中涉及的细小知识点积少成多，让我从零碎繁忙的运维工作中得到了一定程度的解放。相信认真读过的小伙伴，一定会觉得工作中并非只有什么高大上的技术才能解决痛点，恰恰相反，正是那些我们平时忽视的细节才是问题的要害。那么只有切中要害，我们才能对症下药。因此接下来一段时间，我可能会陆续分享运维过程中对一些问题的思考，希望给大家带来一定的启发。本次分享的是cmdb与zabbix监控系统的融合。现状
运维思索：运维规范如何生成？
简述前面的文章老说“运维管理”、“运维自动化”，可能大家都听烦了，大道理谁都会说，能不能来点干货，把这些“大白话”落地？我自己也不断在想是否应该将这些分享出来，因为都是自己在工作过程中的个人理解，都是野路子。但换个角度，运维的工作并不是简单的修修补补，而是给业务赋能，让自己实现价值的，因此接下来的文章更多的是进行落地。运维框架运维思索：运维管理与运维自动化一文中我们从运维工作中提取了运维框架（红色代表缺失），由基础设施层、数据层、应用层、管理层、展示层组成，生成了我们最终的运维体系。下面我们从以下
运维思索：Cobbler无人值守实现操作系统安装规范化
简述运维思索：运维规范如何生成？一文介绍了怎样从平常工作中提取运维依据，实现运维规范的落地。接下来我们就要按照运维框架分层继续推进标准化工作了，不要以为"落地"是说着玩的！本文我们介绍"IT基础设施层"中比较基础的工作：服务器的操作系统安装，涉及到的场景是服务器上架批量安装操作系统。如果服务器数量较少，我们可以通过idrac或现场安装，但是服务器几十台甚至上百台可能就不适用了，此时我们就需要无人值守安装。不管数量多少，彻底和人工说88，在此推荐Cobbler。部署1.安装yum install h
运维思索：操作系统配置规范化、自动化
简述运维思索：Cobbler无人值守实现操作系统安装规范化一文只是实现了对操作系统的主机名、网络、磁盘分区的安装规范，但此时还不能够直接用于生产，因为操作系统还有很多配置没有进行优化，接下来的工作就是要对操作系统进行配置规范化。思路让我们先停止手头无休止的工作，来简单回想下曾经配置过数不清的服务器，配置过程是否和以下有所类似：yum源配置安装常用工具gcc、gcc-c++、cmake、wget、iftop、supervisor等环境变量配置a.终端超时时间b.优化history
运维思索：目录管理规范的重要性
简述作为运维团队的一员，当你登录服务器第一时间是否是以下行为：确定应用的启动目录、数据目录、日志目录、启动用户；确定应用如何启动及是否有开机自启动或守护进程；确定服务器的日常脚本目录、软件源码目录、公共目录等；如果你存在以上行为，那说明你们的团队需要做目录管理规范了。这是为什么呢？首先明确的是我们无论做什么规范，目的都是避免差异性；其次团队中每个人的习惯不同，没有规范必将导致服务器配置差异五花八门，无形中增加了运维的难度；最后目录的规范统一可以给后续的自动化打下坚实的基础。举个简单的例子：
运维思索：如何纳管服务器实现统一登录
简述继运维思索：Cobbler无人值守实现操作系统安装规范化、运维思索：操作系统配置规范化、自动化两篇文章后，运维团队已经能够快速交付规格一致的服务器了，接下来我们的需求就是如何进一步纳管服务器并对外提供统一登录。为了实现这一需求，我们需要借助于堡垒机。在此我们特通过JumpServer的应用来·深度体验如何纳管服务器并实现统一登录。传统管理方式传统管理方式给运维团队及开发、测试人员带来以下问题：开发、运维、测试登录生产环境，需要进行二次跳转，操作繁杂；开发、运维、测试登录各种环境服务器，强烈
运维思索：基础设施自动化落地
前言前面《运维思索》系列文章已经将我们的自动化运维之路铺好，接下来我们要进入的是基础设施自动化落地。本文希望能够将《运维思索》系列与之前分享的一些文章进行有效的串联，让历史文章不再孤单，再次发挥余热。串联在运维思索：运维管理与运维自动化一文中讲到了运维自动化的几个阶段：操作自动化>场景自动化>智能化，其在基础设施层的落地主要体现为：操作自动化运维思索：操作系统配置规范化、自动化一文，基于配置规范结合ansible实现了部分功能的操作自动化：（1）操作系统配置初始化、用户配置自动化、
K8SEASY：一键安装K8S高可用集群
简述kubeadm 二进制部署 k8s集群，整个部署过程相对比较繁琐，但是通过安装有助于入门者初步了解k8s的组件、网络等信息，因此还是需要了解的。而本文要推荐的是一款可快速部署多节点高可用K8S集群的软件：K8SEASY,同时内置了Dashboard、Prometheus、Grafana、node-exporter等组件，简单易用。其他优点如下：一键安装，安装一个系统只需要 3 分钟, 安装好以后完整的监控也一并装好，可以直接使用。（不止支持单master 还支持3master 高可用方案)新
运维思索：cmdb打通zabbix、jumpserver探索
需求《蓝鲸之路》系列文章我们通过蓝鲸标准运维打通了zabbix、jumpserver，虽然实现了虚拟机从创建、jumpserver资产录入到权限分配、cmdb资产录入这一套完整的上架流程。但是cmdb、jumpserver、zabbix之间的资产及分组关系不是统一的，团队需要花费一定的精力去维护及团队间信息同步，在此cmdb并没有起到统一数据源及提供数据支撑的作用，因为zabbix、jumpserver等都是脱离蓝鲸体系的。试想一下我们的jumpserver、zabbix 是要为运维团队的基础运维、应.
cmdb事件推送实现zabbix资产同步
前言《事件推送网关：让cmdb告别“花瓶”》一文我们将cmdb事件推送的参数进行了解析，并结合redis做了去重，避免事件的重复推送。接下来的任务我们计划是cmdb和zabbix进行资产同步，功能如下：cmdb的业务、集群、模块分组信息同步至zabbix主机分组；cmdb资产删除同步至zabbix进行相应的主机删除；cmdb资产新建同步至zabbix，并根据相应的信息绑定不同的模板；此时cmdb只是为zabbix提供了资产新建、分组、变更等基础数据，zabbix的告警信息如何与其关联，让运维.
事件推送网关：让cmdb告别“花瓶”
前言众所周知cmdb在运维过程中的重要性，但是我们不希望它是一个“花瓶”，因此《运维思索：cmdb打通zabbix、jumpserver探索》成了我们当前面临的一个课题。而我们可以借助cmdb的事件推送来解决此问题，因此引入了事件推送网关。事件推送网关是蓝鲸cmdb事件推送的一个目标系统，当cmdb中配置信息发生变化时，会实时通知到事件推送网关，由网关统一关联到各运维子系统，如jumpserver、zabbix等，实现配置信息的一致性同步，为上层应用做好数据支撑。各系统的一致性同步的前提是所有的配置.
cmdb事件推送实现jumpserver资产分组同步
前言《cmdb事件推送实现zabbix资产同步》一文实现了cmdb和zabbix的资产同步，接下来我们就离着《运维思索：cmdb打通zabbix、jumpserver探索》这个小目标就不远了。言归正传，jumpserver的资产分组同步，即jumpserver的资产列表与cmdb的业务拓扑保持一致，按照业务–集群–模块的树形结构分布。而cmdb和jumpserver的同步思路与前面基本保持一致，即：主机标识更新只有当主机转移至相关模块时，才会触发业务、集群、模块（例如分别对应消金生产环境–.
事件推送网关: “让基础设施建设动起来”
前言《事件推送网关：让cmdb告别“花瓶”》自发起至今已两月有余，在此期间我们从无到有对cmdb的事件推送进行了充分的摸索，不断的踩坑填坑，现已基本实现了以下功能：cmdb和zabbix同步，以“业务_集群_模块”的分组规则进行创建、更新、删除同步；主机创建、模板绑定、删除，代替zabbix的被动的自动发现或自动注册，掌 握一定的主动性；cmdb和jumpserver同步，按“/业务/集群/模块”的节点规则适配jumpserver的树形结构，对节点进行创建、更新、删除同步；资产的分组更新、删除；.
今日推荐
周排行