基于SLB的滚动发布脚本示例

更新时间:2018-01-12 16:12:44    滚动发布 滚动发布(rolling update)是最常见的一种发布模式。比如我有10台机器,一台一台的进行部署。每台机器进行部署时,需要保证没有请求会派发到该机器,否则用户就会看到502的错误。所以需要有一个“下线”的操作,把当前机器从负载均衡中摘除,然后在部署完成之后,再把自己挂回到负载均衡中,这个过程称为“上线”。接下来会讲解,配合阿里云SLB如何做上线/下线操作。 基于阿里云SLB的滚动发布 在SLB中进行如下配置: 图中的关键点: 健康检查路径,需要由实例上的web服务器提供,在本例中是/nginx-status 。 健康检查间隔,配置为2S。 健康阈值,配置为2,也就说2次健康检查失败,则认为该后端服务器不可用。同样的,两次连续的健康检查成功,就会认为该后端服务器可用。 按照这个配置,如果/nginx-status这个URL不可用超过4S,则SLB会把该服务器摘除。在这4S内,应用服务仍需要是可用的,因为还会有请求派发过来。可以通过如下方式达到这个效果。 配置nginx 将/nginx-status这个URL派发到一个本地文件,使用如下配置文件: server { location ~ ^/(nginx-status) { root /home/admin/status; } }...

5个小时写一个扑克牌游戏——金钩钓鱼

  罗大佑有歌云:“无聊的日子总是会写点无聊的歌曲……”,我不是歌手,我是程序员,于是无聊的日子总是会写点无聊的程序。程序不能太大,不然没有时间完成;程序应该有趣,不然就达不到消磨时间的目的;程序应该有那么一点挑战性,不然即使写完了也没有进步。 金钩钓鱼游戏是我儿时经常玩的一种扑克牌游戏,规则非常简单,两个玩家,一旦牌发到手里之后,接下来每个人出什么牌基本上已经就定了,玩家没有自己做决策的机会,所以这个游戏很容易用程序自动模拟出来。   (一)关于金钩钓鱼游戏 基本规则(简化版):两个玩家(Player),一副扑克(Deck),大小王(Joker)可要可不要,我们的游戏假定包含大小王,洗牌(Shuffle)之后,每个玩家得到同样数目的牌(27张),玩家任何时候不能看自己手里的牌,玩家依次出牌,每次出一张,轮到自己出牌时,抽出自己手中最底下的一张牌放到牌桌(Board)上,牌桌上的牌按照玩家出牌的顺序摆成一条长链。J(钩)是最特殊的一张牌,当某个玩家出到J时,便将牌桌上的所有牌都归为己有,并放到自己牌池的最上面(与出牌时恰恰相反),此即所谓“金钩钓鱼”,此时牌桌清空,再由此玩家重新出牌。另外,当自己出的牌与牌桌上的某张牌点数相同时,便将牌桌中那张牌及其之后的牌都归为己有(包含自己刚出的那张),再由此玩家重新出牌,比如牌桌上的牌为3,7,8,4,9,当某个玩家出了8,便将牌桌上的8,4,9连同自己刚出的8一并收回,派桌上剩下3,7。最后,谁手中的牌最先出完,谁就输了。   (二)对于一副牌的建模 由于花色(Suit)对于此游戏并不重要,所以对扑克牌建模时省略了对花色的建模,同样,由于不需要比较大小,牌的点数(Rank)可以用String来表示(其中王用”W”表示)。 package com.thoughtworks.davenkin.simplefishinggame; public class Card { private String rank; public Card(String rank) { this.rank = rank; }...

重温大师经典:Martin Fowler的持续集成

持续集成 作者:Martin Fowler     译者:滕云 原文发布时间:2006年5月1日     翻译时间:2012年2月25日 原文链接:http://www.martinfowler.com/articles/continuousIntegration.html (此翻译已获原作者同意)   持续集成(Continuous Integration, CI)是一种软件开发实践,在实践中项目成员频繁地进行集成,通常每个成员每天都会做集成工作,如此,每天整个项目将会有多次集成。每次集成后都会通过自动化构建(包括测试)来尽快发现其中的错误。许多团队都发现这种方法大大地减少了集成问题并且能够快速地开发出高内聚性的软件。本文简要地总结了持续集成技术及其现状。 我还清楚地记得我刚加入一个大型软件项目时的情形,那时我正在英国一个电子公司做暑期实习。我的经理(属于QA部门)领我参观了一个巨大并很压抑的房间,里面全是格子间。经理告诉我这个项目已经开发了有些年头,现在正在做集成,并且已经集成了好几个月了。经理还告诉我说,没有人真正知道完成集成工作需要多少时间。由此我学到了软件项目的一个通病:软件集成是一个漫长并且无法预测的过程。     然而,软件集成不必像这样的。在ThoughtWorks的大多数项目还有世界上许多其它组织的软件项目中,软件集成并不是什么难事。每个开发人员离共享的工程状态只有咫尺之遥,并且可以在几分钟之内将自己的代码集成进去。任何集成错误都能被快速地发现并得到快速的修正。 这种鲜明的对比并不是源自于后者有多么昂贵或复杂的工具,而关键在于每人都频繁集成这种简单实践,通常是每天向一个被管控的代码库集成。 当我向人们阐述这种实践时,通常得到两种反应:“(在我们这里)行不通”和“无关紧要”。当人们尝试了这种实践之后,他们发现其实做起来比说起来简单,而且这样的实践对于开发“至关重要”。因此有了第三种反应:“是的,我们就是这么做的,不然该怎么活啊?” “持续集成”源自于极限编程(XP),并且是XP最初的12种实践之一。当我以咨询师的角色加入ThoughtWorks时,我鼓励我的团队使用这种技术。Matthew Foemmel将我的建议变成了实实在在的行动,由此软件集成从少有发生并且复杂的状态变成了一桩易事。Matthew和我将我们的经验写在了本文的第一版中,而本文也是我的个人网站上最受欢迎的文章之一。 虽然持续集成并不需要使用特别的工具来部署,但是我们发现拥有一台持续集成服务器将大有益处,其中最著名的有开源的CruiseControl,该软件最初由ThoughtWorks的几个员工开发,现在由一个很大的社区维护着。后来几款其它的持续集成服务器也相继出现了,有开源的,也有商业化的,包括ThoughtWorks Studios的Cruise。    ...

十步搭建 OpenVPN

摘要: 十步搭建 OpenVPN,享受你的隐私生活 我们支持保护隐私,不为我们有自己的秘密需要保护,只是我们认为保护隐私应该成为一项基本人权。所以我们坚信无论谁在什么时候行使这项权利,都应该不受拘束的获取必须的工具和服务。 十步搭建 OpenVPN,享受你的隐私生活 我们支持保护隐私,不为我们有自己的秘密需要保护,只是我们认为保护隐私应该成为一项基本人权。所以我们坚信无论谁在什么时候行使这项权利,都应该不受拘束的获取必须的工具和服务。OpenVPN就是这样一种服务并且有多种工具(客户端) 来让我们利用并享受这种服务。 通过与一个OpenVPN服务器建立连接,我们基本上在我们的设备和远端运行OpenVPN的主机之间建立了一个安全的通信通道。尽管在两个端点之间的通信可能被截获,但是信息是经过高强度加密的所以实际上它对于攻击者没什么用。OpenVPN除了扮演加密通信通道的调解人,我们也可以通过设置使服务器扮演互联网网关的角色。通过这种方式,我们可以连接任何不安全的Wifi,然后迅速的链接到远程的OpenVPN服务器,然后在不需要考虑偷窥的人或者无聊的管理员的情况下运行需要上网的程序。(注意:OpenVPN服务器旁还是需要信任的管理员的。) 这篇文章将一步一步的教会你如何在Ubuntu Server 14.04 LTS上安装OpenVPN。OpenVPN所在的主机可能是云上的一台VPS,一台在我们家里某台电脑上运行的虚拟机,或者是一个老到你都快忘了的设备。 第一步 准备系统 我们需要Ubuntu Server主机的一个命令行终端,比如通过SSH从远程访问它。首先需要更新它的本地仓库数据: sub0@delta:~$ sudo apt-get update 进行操作系统和已安装的包的升级,输入: sub0@delta:~$ sudo apt-get...