ssh-keygen 的 详解

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"     为了让两个Linux机器之间使用ssh不需要用户名和密码。所以采用了数字签名RSA或者DSA来完成这个操作。 模型分析 假设 A (192.168.20.59)为客户机器,B(192.168.20.60)为目标机; 要达到的目的: A机器ssh登录B机器无需输入密码; 加密方式选 rsa|dsa均可以,默认dsa ssh-keygen -t rsa #使用rsa加密 二、具体操作流程 单向登陆的操作过程(能满足上边的目的): 1、登录A机器 2、ssh-keygen -t [rsa|dsa],将会生成密钥文件和私钥文件 id_rsa,id_rsa.pub或id_dsa,id_dsa.pub 3、将…

Continue Reading

用Kanban-Ace框架改进Scrum

关键点 Scrum已经几乎成了敏捷的同义词;虽然Scrum相当有用,但它仍有弱点和有待改善的空间。Kanban-Ace框架可以帮助它克服这些弱点。 Kanban-Ace框架接受Scrum,并帮助团队提高他们的敏捷水平。这些改进通过以下做法完成: Akashi Bridge:这是一种新的工具,它可以在Kanban-Ace板的背景下使用每一个Scrum事件,包括Sprint、Sprint计划、每日站立短会、Sprint重整和回顾等。 Kanban-Ace板:它内置Akashi Bridge,大大提高了软件开发的各个方面可视化程度,让团队可以识别趋势,提高自身的敏捷度。 精益思想:它是Kanban-Ace精益DNA的一部分。精益思想使团队减少浪费,并优化Kanban-Ace事件和过程以满足团队的需要。 ---------------------------------------------------------------------------------------------------------------------------------------------------------------- Scrum是一种广泛使用的敏捷框架,它已被证明对许多公司和机构都非常有用。然而,正如Fred Brooks的名言所说的那样,在信息技术上没有“银弹”,尽管Scrum有其好的部分,但有时我们敏捷专业人员却因为各种原因而不得不与Scrum的某些方面进行斗争。在进一步展开本文的陈述之前,我要清楚地说明我喜欢Scrum。从2008年起,我就一直使用它。我甚至拿到了ScrumMaster的认证。而且,我发现Scrum有两个概念特别有价值:受保护的迭代或Sprint,也有人正式代表用户,那就是产品经理。 然而,我个人对于敏捷和精益的理解超越了单一的方法或框架,获益于几个灵感来源的智慧结晶,比如:Kanban、极限编程,精益开发,以及一些其它方法中的精华,来以更好的方式来实现敏捷。因此,我开始建立一种方法,它基于精益和敏捷的影响,Kanban是主要的统一力量,在2013年,Kanban-Ace方法已经在我们的网站上公布。 然而直到现在,还没有一本书整理Kanban-Ace方法的价值、原则和技术。原因是,在Agilelion公司里,我们专注于通过录制好了的视频进行在线教学,同时也进行现场授课。何其幸运,Kanban-Ace方法能够被世界各地的人们所使用,在这三年里得到了人们大量的反馈信息,这些反馈近的来自美国和加拿大,远的来自德国、瑞士和澳大利亚。 从我们的学生身上和我的职业咨询实践中,我注意到Scrum是无处不在的,它几乎成为敏捷的同义词;虽然Scrum是众多敏捷方法之中的一种方法,不可否认的是,它是最广泛使用的一种方法。而且,作为受认证的ScrumMaster专家,我在乎Scrum,并想向来了解Kanban-Ace的人展示,他们如何能在保留几个他们喜欢的Scrum关键优势的同时,提高他们的敏捷性。 Kanban-Ace现在是一个框架,而不是一种方法。原因是,框架的建立是为了适应一个特定的域,我们打算把Kanban-Ace扩展到以下一些新的领域:对Scrum的全面支持、轻量级敏捷提升和产品创新工具。 这篇文章只是对第一个关键领域会发生什么事情的预览:对Scrum的全面支持。然而,我们不能在这里停下脚步,我们要改进Scrum并使Kanban-Ace框架成为你的敏捷工具集的一个有价值的补充,但在我们开始之前,我们需要给你介绍一下Kanban的相关背景知识。 Kanban简史 要了解Kanban今天的地位,必须知道它的过去情况。制造Kanban,有时用小写“kanban”直接指的是丰田公司组织跨工厂和部门工作的制造技术,这种技术和其他几种技术构成了丰田生产系统(Toyota Production System,TPS)。TPS开始于1945年。到了1978年,大野耐一在日本出版的书是一个重要的里程碑。感谢Norman Bodek的努力,十年后这本书的英文版出版,使得它可以在西方世界传播。 知识工作Kanban或首字母大写的Kanban指的是围绕应用TPS理念、约束理论、精益开发和其他相关资源的改变和创新,以便重点管理和改善人类创造力相关的领域,特别强调以软件开发、信息工程、营销和管理为重点。知识工作Kanban是最早的敏捷和精益的方法,是我们各种Kanban类型的创立者。从现在开始,我们所有提到的Kanban都是指这种特殊类型的Kanban。 Kanban的起源 2009年,Corey Ladas在他的关于Kanban的书《Scrumban:论Kanban系统的精益软件开发》(Scrumban - Essays on Kanban Systems…

Continue Reading

20步打造最安全的Nginx Web服务器

Nginx是一个轻量级的,高性能的Web服务器以及反向代理和邮箱(IMAP/POP3)代理服务器。它运行在UNIX,GNU /linux,BSD 各种版本,Mac OS X,Solaris和Windows。根据调查统计,6%的网站使用Nginx Web服务器。Nginx是少数能处理C10K问题的服务器之一。跟传统的服务器不同,Nginx不依赖线程来处理请求。相反,它使用了更多的可扩展的事 件驱动(异步)架构。Nginx为一些高流量的网站提供动力,比如WordPress,人人网,腾讯,网易等。这篇文章主要是介绍如何提高运行在 Linux或UNIX系统的Nginx Web服务器的安全性。 默认配置文件和Nginx端口 /usr/local/nginx/conf/ – Nginx配置文件目录,/usr/local/nginx/conf/nginx.conf是主配置文件 /usr/local/nginx/html/ – 默认网站文件位置 /usr/local/nginx/logs/ – 默认日志文件位置 Nginx HTTP默认端口 : TCP 80 Nginx HTTPS默认端口: TCP 443 你可以使用以下命令来测试Nginx配置文件准确性。 /usr/local/nginx/sbin/nginx…

Continue Reading

配置Tomcat使用https协议

一.  创建tomcat证书   这里使用JDK自带的keytool工具来生成证书:   1. 在jdk的安装目录\bin\keytool.exe下打开keytool.exe     2. 在命令行中输入以下命令: keytool -genkeypair -alias "tomcat" -keyalg "RSA" -keystore "g:\tomcat.keystore"     以上命令将生产一对非对称密钥和自我签名的证书g:\tomcat.keystore 注意:“名字与姓氏”应该是域名,输成了姓名,和真正运行的时候域名不符,会出问题 这里我输入的密码是123456,  域名是以tomcat为例,  省市以广东深圳为例   二. 配置tomcat服务器  …

Continue Reading

centos服务器设置代理上网的方法

这里以centos7.0为例,记录代理服务器设置过程: 1.全局的代理设置: vi /etc/profile 添加下面内容 http_proxy = http://username:password@yourproxy:8080/ ftp_proxy = http://username:password@yourproxy:8080/ export http_proxy export ftp_proxy 2.yum的代理设置: vi /etc/yum.conf 添加下面内容 proxy = http://username:password@yourproxy:8080/ 或者 proxy=http://yourproxy:808 proxy=ftp://yourproxy:808 proxy_username=username proxy_password=password 3.Wget的代理设置: vi /etc/wgetrc 添加下面内容…

Continue Reading

JDK下载

wget --no-check-certificate --no-cookies --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/8u91-b14/jdk-8u91-linux-x64.rpm 从Oracle官网下载JDK,把后面地址部分改一下就OK。

Continue Reading

DevOps的前世今生

目前在国外,互联网巨头如Google、Facebook、Amazon、LinkedIn、Netflix、Airbnb,传统软件公司如Adobe、IBM、Microsoft、SAP等,亦或是网络业务非核心企业如苹果、沃尔玛、索尼影视娱乐、星巴克等都在采用DevOps或提供相关支持产品。那么DevOps究竟是怎样一回事?在Puppet、RightScale分别DevOps出版的调查报告基础上,整理本文,以期为读者理清思路。另外,中国正在开展了一份自己的调查问卷,由南京大学发起,欢迎大家投票参与。 DevOps是什么?从哪里来? DevOps的概念 DevOps一词的来自于Development和Operations的组合,突出重视软件开发人员和运维人员的沟通合作,通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。 DevOps概念早先升温于2009年的欧洲,因传统模式的运维之痛而生。 DevOps是为了填补开发端和运维端之间的信息鸿沟,改善团队之间的协作关系。不过需要澄清的一点是,从开发到运维,中间还有测试环节。DevOps其实包含了三个部分:开发、测试和运维。 换句话说,DevOps希望做到的是软件产品交付过程中IT工具链的打通,使得各个团队减少时间损耗,更加高效地协同工作。专家们总结出了下面这个DevOps能力图,良好的闭环可以大大增加整体的产出。 历史变革 由上所述,相信大家对DevOps有了一定的了解。但是除了触及工具链之外,作为文化和技术的方法论,DevOps还需要公司在组织文化上的变革。回顾软件行业的研发模式,可以发现大致有三个阶段:瀑布式开发、敏捷开发、DevOps。 DevOps早在九年前就有人提出来,但是,为什么这两年才开始受到越来越多的企业重视和实践呢?因为DevOps的发展是独木不成林的,现在有越来越多的技术支撑。微服务架构理念、容器技术使得DevOps的实施变得更加容易,计算能力提升和云环境的发展使得快速开发的产品可以立刻获得更广泛的使用。 (注:上图摘自上月红帽副总裁Ashesh Badani的一次新闻分享会) DevOps的几个关键问题 好处是什么? DevOps的一个巨大好处就是可以高效交付,这也正好是它的初衷。Puppet和DevOps Research and Assessment (DORA) 主办了2016年DevOps调查报告,根据全球4600位各IT公司的技术工作者的提交数据统计,得出高效公司平均每年可以完成1460次部署。与低效组织相比,高效组织的部署频繁200倍,产品投入使用速度快2555倍,服务恢复速度快24倍。在工作内容的时间分配上,低效者要多花22%的时间用在为规划好或者重复工作上,而高效者却可以多花29%的时间用在新的工作上。所以这里的高效不仅仅指公司产出的效率提高,还指员工的工作质量得到提升。 DevOps另外一个好处就是会改善公司组织文化、提高员工的参与感。员工们变得更高效,也更有满足和成就感;调查显示高效员工的雇员净推荐值(eNPS:employee Net Promoter Score)更高,即对公司更加认同。 快速部署同时提高IT稳定性。这难道不矛盾吗? 快速的部署其实可以帮助更快地发现问题,产品被更快地交付到用户手中,团队可以更快地得到用户的反馈,从而进行更快地响应。而且,DevOps小步快跑的形式带来的变化是比较小的,出现问题的偏差每次都不会太大,修复起来也会相对容易一些。 因此,认为速度就意味着危险是一种偏见。此外,滞后软件服务的发布也并不一定会完全地避免问题,在竞争日益激烈的IT行业,这反而可能错失了软件的发布时机。 为什么DevOps会兴起?为什么会继续火下去? 条件成熟:技术配套发展 技术的发展使得DevOps有了更多的配合。早期时,大家虽然意识到了这个问题的,但是苦于当时没有完善丰富的技术工具,是一种“理想很丰满,但是现实很骨感”的情况。DevOps的实现可以基于新兴的容器技术;也可以在自动化运维工具Puppet、SaltStack、Ansible之后的延伸;还可以构建在传统的Cloud…

Continue Reading

肖俊:HPE IT 的DevOps 实践分享

本篇文章来自于HPE和msup共同举办的技术开放日HPE测试技术总监肖俊的分享,由壹佰案例整理编辑。 一、DevOps含义解析 这是DevOps的趋势图。DevOps这个概念大概是在2009年被提出来的,2010年有一些公司开始试点,之后DevOps的热度持续增加,这是我们在谷歌搜索DevOps关键字得到的搜索量,这条曲线表示了DevOps热度呈指数级增长。因此我预计2016年DevOps仍然会成为一个非常受关注的技术。 什么是DevOps? 我们在试点DevOps的时候做了很多研究,也在网上做了很多搜索。比较普遍的说法是:DevOps是一种文化,用以打破开发、运维以及测试之间的工作壁垒。之所以会有壁垒是因为开发、测试、运维的工作职责、目的存在不一致性。比如开发的主要目的是赶紧实现业务级的新需求及功能,交给客户使用,然后根据反馈信息继续更新;运维的主要目的是生产必须快速、不能出问题,所以他们不是很喜欢“变化”,因为变化可能会带来风险,随之而来的就是各种问题,这是他们最不愿意看到的。 如果站在他们各自的角度来看,这些考虑都很正确,但现在的市场要求所有研发人员的最终目的都是“帮助业务部门创造商业价值”,而不只是狭隘地满足各自的目标。如何创造商业价值?充分满足客户的需求。客户的需求是多变的,而且变化的速度很快,这就要求我们必须跟上他们的步伐,快速实现最新功能并交给客户使用,如果一个系统很稳定但没有人使用,那它一样不能给我们带来任何东西。 维基百科上对DevOps的解释是:软件开发人员和IT运维技术人员之间沟通合作的文化、趋势或实践。透过自动化(软件缴付)的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。之前开发、测试、运维三者之间可能是独立的,现在要求更紧密一点。一句话总结,DevOps就是:开发测(试)(运)维融一体,敏捷高效自动化。这也是我们对DevOps的定义和理解。 自2009年提出DevOps的概念起,很多公司都开始实施DevOps,国外比较著名的有Google、Facebook等,国内著名的有百度、华为、阿里、Flickr等,他们实施DevOps的结果是每天有10次部署,这是非常了不起的。 二、HPE IT在DevOps上的实践 HPE IT部门在2014年年底的时候引入DevOps概念,2015年找了一些内部的敏捷项目做试点,2016年我们开始在400多个应用里推广DevOps。 1、引入DevOps的实际背景 既然要实践要推广,我们看一下目前的现状。IT在开发的流程上使用敏捷已经很久了,所以可以看到,开发实际上采用了敏捷的迭代方法,每个冲刺都会产出一个可发布的产品。到了运维这边,我们不得不遵循企业发布规则:每三个月一次发布窗口,我们就必须等待。根据应用的技术不同,有不同的运维团队来帮助你做生产环境的部署和监控,所以我们得找到相应的运维团队,提前7天提交一个rfc。这些流程做完之后,运维团队开始部署,这时要写一个“部署文档”告诉他怎么上传到服务器,把哪个文件删掉、哪个文件备份等,我看到最大的可能有十几页,很多时候运维人员要管很多项目,部署又有问题。整个流程非常繁琐,敏捷在实现在开发中的运用,但在运维中仍然不足。最后我们看到“部署”变成最后一公里,最后一公里如果没法做到“敏捷”的话,前面的“敏捷”可能就白做了。 2、DevOps持续交付、持续部署 为了解决这些问题,我们提出了一个DevOps的方案,通过持续交付和持续部署来实现。持续交付和持续部署大体上包括了4个部分:1.开发和开发相关的;2.QA测试相关;3.用户测试相关;4.生产运维相关。通过整个的DevOps持续集成、持续交付把开发、测试、运维三者都包括其中。 开发环节的持续集成 我们强调每一个开发人员做的任何修改,必须得在本地通过新功能的单元测试。通过了新功能的单元测试后会做整合,然后提交到代码仓库,一旦提交代码到代码仓库,我们的服务器会自动触发,做自动化构建和比较全面的单元测试,然后再做部署到itg上面,如果这个新的代码通过了itg的测试就会显示时绿色的,没通过会显示是红色的。 有的时候开发很着急,不断写新代码希望做得快一些,不注意细节,QA就觉得很难理解,有的时候甚至构建不起来,提交过来也没办法部署。举个例子,我们要求所有代码都是小写,有一次我们的开发用了第三方的一些库文件,而这个第三方的库文件中间会有大写的字母,这些大写的字母出现在配置文件中,到部署时就可能导致QA环境出错。因为我们的QA环境是Liunx的系统,对大小写比较敏感。 开发经常说:“在我这边是好的,是你的问题,不是我的问题。”为了避免这样的状况出现,我们要求必须得在itg上做测试,这个itg和生产环境比较类似,都是Liunx。 代码分支策略:单分支结构 接下来介绍一个我们的分支策略。我们的代码分支策略叫单分支结构,这样的好处有: (1)如果在开发时有太多的分支,最后合并会很麻烦。每一次合并分支开发人员都要花少则半个小时到一个小时,多则半天到一天的时间,合并好以后测试人员再做回归测试。整个流程下来,一天就过去了,所以我们不太赞成有太多的分支。 (2)我们持续集成的服务是监控主干的,主干上有任何代码提交都会发现。如果我们不去看这些分支,这些分支就不做持续集成,这样的风险很大。 这是我们分支的策略,我们要求每个开发每天至少要提交一次代码到代码仓库。每天提交、每天做测试就不会那么容易出现问题;如果很久才做测试的话不仅会发现很多问题,而且修改起来非常费时间。我们可以做到大概每天1.5次/人的代码提交。 测试环节的持续集成 持续测试 测试环节主要是新功能和非功能的回归测试。每个地方都有一个圈子,圈上面有剪头,表示持续循环地做,而不是只做一次,所以我们叫“持续做测试”。我们尽量使用和生产环境类似的操作系统、数据等来做测试,这样回归测试做完之后我们就很有信心,因为测试环境和生产环境一致,测试完之后放到生产环境中就很放心了。测试中我们在Shift Letf上的关注有几点: (1)需求给了开发,开发完之后给测试,大家目的不一致互相不买账,讨论来讨论去大家开始扯皮,到底是开发与测试对需求的理解不一样还是什么?再把BA等拉进来讨论,非常浪费时间,这不是我们希望看到的。我们希望看到的是整个自动的流程就过去了,这样才可以达到敏捷和快速交付的目的。所以我们会在做需求的时候就让测试参与进来。…

Continue Reading
Close Menu