Network

Etcd V3新特性

[不指定 2016/08/26 15:09 | by ipaddr ]

Etcd 3.0已经于2016/07正式发布了,新版还是带来了不少新特性:

  • RPC调用的优化,使用gRpc+ProtoBuff来替代原来的HTTP;
  • 使用租约来替代原来的TTL;
  • Watcher的优化
  • ...

 

以下记录下一些官方文档以及前人的总结:

官方文档: https://coreos.com/blog/etcd3-a-new-etcd.html

中文翻译: http://www.infoq.com/cn/news/2016/07/etcd3

升级实录: https://segmentfault.com/a/1190000005947453c

升级介绍: https://chromium.googlesource.com/external/github.com/coreos/etcd/+/HEAD/Documentation/op-guide/v2-migration.md

 

 

 

GoLang里的DB连接池

[不指定 2015/11/03 18:01 | by ipaddr ]

GoLang的数据库类库,自带了DB连接池功能,官方文档有介绍:

https://golang.org/pkg/database/sql/#DB

DB is a database handle representing a pool of zero or more underlying connections. It's safe for concurrent use by multiple goroutines.

The sql package creates and frees connections automatically; it also maintains a free pool of idle connections. If the database has a concept of per-connection state, such state can only be reliably observed within a transaction. Once DB.Begin is called, the returned Tx is bound to a single connection. Once Commit or Rollback is called on the transaction, that transaction's connection is returned to DB's idle connection pool. The pool size can be controlled with SetMaxIdleConns.


可以通过SetMaxIdelConns, SetMaxOpenConns来限制DB的连接数。

GoLang自动进行连接池的管理,默认情况下没有连接数限制,同时没有连接可用的话会新建连接;所以代码中没有正确的释放连接将导致连接数不断增加,比如以下代码:

 _, err := db.Query("SELECT uId FROM tUser WHERE userName='tomzhou'")

此代码,由于返回的Row未使用,所以此连接会一直占用不会释放;正确的做法:

rows, err := db.Query("SELECT uId FROM tUser WHERE userName='tomzhou'")

defer rows.Close()
//或在合适的地方主动关闭rows;




最近发现,升级Chrome后访问某些HTTPS站点,Chrome给出明显的红叉警告证书不安全,比如:


 


Chrome官方对此有说明:

主要原因是:
1. SHA1算法已被证明不够健壮,容易受到攻击;
2. Google, Microsoft将在2017年淘汰SHA1算法;
3. 从Chrome 41版本开始,将对SHA1算法的数字证书进行安全告警;
4. 如果SHA1证书有效期到2016年,将出现黄色告警,如果SHA1证书有效期到2017年以后,将出现红色告警;
www.iamadmin.com原创,转载请注明)
解决办法:
1. 证书签发时升级到SHA2算法, 但是还是有不少客户端不支持,比如WindowsXP SP2以下,以及Android 2.2;
2. 证书有效期缩短在2015或2016年内, 等业界推动旧客户端废弃后,再上SHA2;

目前Google, Baidu这些都是控制有效期在2015年, 部分站点直接上了SHA2;

GRPC是一个高性能、开源、通用的RPC框架,面向移动和HTTP/2设计,是由谷歌发布的首款基于Protocol Buffers的RPC框架。


目前提供C、Java和Go语言版本,这三个版本的源码全都托管在Github上,分别是:grpcgrpc-javagrpc-go。其中C版本支持CC++Node.jsPythonRubyObjective-CPHP 和 C#

GRPC基于HTTP/2标准设计,带来诸如双向流、流控、头部压缩、单TCP连接上的多复用请求等特性。这些特性使得其在移动设备上表现更好,更省电和节省空间占用。Protocol Buffers简称protobuf是Google公司开发的一种数据描述语言,类似于XML能够将结构化数据序列化,可用于数据存储、通信协议等方面。它不依赖于语言和平台并且可扩展性极强。现阶段官方支持C++、JAVA、Python等三种编程语言,但可以找到大量的几乎涵盖所有语言的第三方拓展包。

Docker的价值和应用场景分析

[不指定 2015/02/28 16:36 | by ipaddr ]

近年来,Docker在IT界可谓风光十足,各大技术论坛上赚足了眼球,公司内外也有相当多的介绍和尝试;看上去如此高大上的技术,貌似会给云时代、服务部署、运维等领域带来颠覆性的创新;

近期查阅了一些文档,较深入的了解Docker的技术细节,发现Docker确实在解决部分需求时恰到好处,但也绝对不是无所不能的万金油;

(http://www.iamadmin.com/, tomzhou 原创, 转载请注明.)

一、什么是Docker

官方定义:
Develop, Ship and Run Any Application, Anywhere

Docker is a platform for developers and sysadmins to develop, ship, and run applications. Docker lets you quickly assemble applications from components and eliminates the friction that can come when shipping code. Docker lets you get your code tested and deployed into production as fast as possible.


解读:

  • 官方把Docker定义为应用打包、部署的平台;而不是虚拟化技术;
  • Docker本身并没有革命性的创新,其核心是Container,Container是很多年前就提出来的理念,并且在Linux, Unix, FreeBSD上都有技术实现,Linux成熟的方案是lxc;
  • Docker是一个基于lxc(linux container),以及cgroup的上层工具;通过对lxc,cgroup及相关系统命令的封装,使得用户可以非常方便的使用Linux Container;
  • Docker Hub提供了应用包的版本管理和分发能力;

二、Docker的价值及同类技术对比

Container的核心价值在于隔离性和封装性,在这两方面也有较多类似解决方案,简单分析和对比一下:

1. 隔离性

Docker的隔离性是通过Container来实现的,并且是基于Lxc;与此相对应的另外一个解决方案是虚拟化;两者对比如下:

优点:

  • 非常轻量
    • 与创建或启动一个虚拟机相比,Container可以认为没啥开销,约等于Linux下创建一个进程;
    • 有个夸张的说法:单机可以轻易的启动多达上千个Container,但基本不太可能启动上千个虚拟机;
    • 但这比较的前提是需要在单机上隔离1000个应用;如果只需隔离两个应用,每个应用运行500个进程的话,对比应该是两个Container与两个VM;

缺点:

  • 隔离层次高
    • docker在Linux kernel之上进行隔离,确切的讲是进程间的隔离,这就决定了:
    • 1. Docker只支持64位Linux,必然不支持windows, unix, bsd...,而虚拟化可支持所有主流操作系统;
    • 2. Docker隔离在kernel之上,并且本身依赖于kernel的特性,所以只能模拟出高版本的Linux发行版;必然找不到ubuntu 9.04这样的image;
    • 3. Container使用的Kernel与主机的Kernel是一致的,无法定制Container的内核;
  • 硬件资源度量和配额能力
    • 通过cgroup,Docker具备一定的能力控制Container的资源使用,但在网络、磁盘、CPU的使用上,度量和隔离能力还没有VM成熟;
    • 此外,从用户角度来看,VM可以做到非常透明,可以直接理解为一台主机;但Container在网络连接、数据存储方面都需要经过特殊处理;


所以,与虚拟化相比,从隔离性上看,Docker的优势在于性能损耗低,劣势在于隔离层次比较高;
如果你的需求在是单机上进行尽可能多的隔离,那Docker是首选;
如果你的需求是尽可能彻底的隔离,对硬件资源精准控制且可度量,同时对隔离份数要求不多的话,那虚拟化是首选;

2. 封装性

从Docker的Logo以及官方的定义来看,它的主要能力并不在隔离性,而在于封装性,也就是应用的打包、部署、运行;


在封装方面的优势,主要体现在:

  • 封装大小
    • 与VM相比,Docker的image确实很小,官方的Centos image大概只有220M(被精减成最基本的Centos了,连ifconfig命令都没有,安装完常用工具,你会发现也不小了);
  • 可对应用高度定制和封装
    • 可通过Dockerfile定义应用包,Image内的部署可高度定制和封装,对外接口收敛且清晰;使用者无需关注细节;
  • Image仓库及版本管理
    • 非常成熟的公共和私有仓库搭建和使用,以及版本管理,并可通地仓库很容易的进行共享、分发、部署;
  • 应用和运行分离
    • 我们所看到的Image是静止的,只读的;将image运行起来后是Container了,在运行时的修改,只影响当前Container,不影响Image;

从上面可以看出,与VM Image的部署能力相比,Docker设计理念先进,优势明显,而且几乎没有啥缺点;

但从封装部署角度来看,Docker的竞品应该不是VM,而是RPM+YUM,DEB+APT这样的组合;
你会发现,与这两组合相比,能力出奇的相似了;但还是有些区别:

  • 封装能力:
    • Docker的Image,可以轻易实现在Centos上面跑Ubuntu,而且非常轻量,这个是Rpm,Deb不具备的;
    • 这个在一些测试、学习、或小规模的Paas场景下,是非常有价值的;
    • 但任何较大规模的应用,我想不太可能出现这样的部署;
  • 封装粒度及依赖管理:
    • Docker自kernel之上,全打包在一块了,里面包含了Linux用户环境、系统类库、应用程序;可以理解为,一个Docker Image的外部依赖只有Linux Kernel了;从另外一方面看,极大提升了移植能力;
    • Rpm、Deb的打包粒度比Docker更细,只打包单个应用自身,外部依赖通过只记录并不存储在包内,通过apt,yum这样的辅助工具也非常容易解决外部依赖;这样做的好处在于更轻量,理论上包大小肯定小于Docker;在大规模业务部署下,上千台设备发布20M的RPM,与发布200M的Docker image,效率上的差距应该还是比较大的;
    • 实际应用当中,在解决外部依赖问题上,C/C++程序还可以简单的通过静态链接来实现;Java/PHP/GoLang这类程序基本不存在系统类库的依赖,跨平台的能力也胜过Docker本身;
  • 跨平台:
    • 在各大Linux发行版下,你都可以按相同的方式使用Docker来管理打包及部署;但Rpm,Deb都有自己的粉丝和发行版本,在发行版间不通用;
    • 但Docker自身的学习和部署成本,要高于Rpm,Deb;

所以,从封装性看,Docker远胜于VM,与Rpm+Yum&Deb+Apt能力相当,从用户角度来看是多了一个选择;

抛开隔离性,假设你需要在单机上运行一个MySQL,你是希望安装Docker、再用Docker来部署MySQL?还是直接yum install mysql?

综合来看,Docker的核心价值就在于隔离性和封装性,并在两者间有个很好的平衡和兼顾,可预见的是在小规模的Paas领域是最好的解决方案;


三、Docker在公司内应用的思考

前面讲到Docker的核心价值在于隔离性和封装性,讨论Docker在公司内业务的应用也应该从这两个方面来看;

哪些场景可以用到隔离性:

  1. 研发测试流程,单机多版本并行部署和运行;
  2. 公司内部的类Paas服务,比如TDW计算、蓝鲸;
  3. 海量服务的正式环境,基本单个服务就能跑满单机,可以说完全没有隔离性需求;

哪些场景用到封装性:

公司所有业务都需要打包部署,但各大业务都已经有非常成熟的包发布系统;整合研发、编译、测试、发布以及架构、配置、路由等各方面的能力;推倒现有包发布系统,基于Docker重构的话,开发和用户学习成本相当高,但技术上并没有明显价值;

如果是全新开发的技术框架和运维体系的话,Docker会是一个较好的选择;但个人更倾向于Centos+Yum+RPM的组合;


四、其它

GoLang大放异彩

GoLang相比于传统语言,在设计上有如C->Java的跨越,而且在性能及部署上更为优秀;
之前在了解的过程中,惊叹此语言的各种内置功能和高级特性,料想在主流开发语言中必然占有一席之地,如今从docker及周边的组件来看,golang应用已是遍地开发;

基础运营环境更新工作任重道远

安装Docker需要Linux Kernel版本至少3.8+, 目前公司最新版的Tlinux 1.2的内核版本为2.6.32,加上公司对内核的管控,短时间内不太可能在正式环境大规模应用Docker;

IT技术日新月异,新技术和组件层出不穷,类似Docker之类的使用势必要求基础运营环境与业界保持同步更新;

但实际情况是公司主流的操作系统Suse10发布已经快十年了,正在更新的Tlinux1.2发布也有三年多了,覆盖率应该未达到50%;仍能在一些老业务上看到slockware的机器;

为了能保持与业界同步,技术团队仍需花费巨大精力投入到无任何业务产出的工作当中;

Centmin Mod

[不指定 2014/12/10 16:42 | by ipaddr ]

http://centminmod.com/

What is Centmin Mod ?

Centmin Mod - LEMP (Linux, Nginx, MariaDB MySQL & PHP-FPM) web stack for CentOS 6.x Linux (also Oracle Linux 6.x and CentOS 7 soon) byGeorge Liu (eva2000) with a shell menu based installer (shown on the right). The shell based menu allows you to do basic Nginx & PHP related management including upgrading or downgrading Nginx & PHP or setting upNginx vhosts. Centmin Mod auto installs Nginx server along with the following software:

SSL Server Test

[不指定 2014/12/03 14:24 | by ipaddr ]

https://www.ssllabs.com/ssltest/index.html

This free online service performs a deep analysis of the configuration of any SSL web server on the public Internet.

推荐一个在线免费服务端SSL测试工具,可给HTTPS服务评级,并给出优化建议。

此外,还可用于客户端的SSL兼容性测试:

https://www.ssllabs.com/ssltest/viewMyClient.html


ProcessOn是一款专业作图人员的社交网络,这里汇聚很多业界专家、学者,同时他们分享的作品又形成一个庞大的知识图库,你在学习专业知识的同时还可以结交一些志同道合的新朋友。

ProcessOn核心设计器采用HTML5 canvas、JavaScript等技术完成,它跟Visio这类传统的软件最大的区别就是无需下载和安装,更不用激活,即开即用。操作起来极为方便和简单,你可以在浏览器中简单拖拖拽拽,即可完成作图,相当人性化,ProcessOn还支自动时保存和实时协作,通过HTML5独特的技术做到毫无延迟,允许多个用户同时对同一文件进行协作编辑和多人聊天。

随着时间推进和技术的发展,如今在线应用型产品越来越受关注和重视,这在一定程度上折射出互联网的发展趋势:WEB化和移动化,传统的软件必将在未来几年被WEB应用所替代,相信不久的将来也一定会出现更多在线版的传统软件。再延伸地去说,浏览器已经开始被赋予越来越重的责任和使命,想象一下现在所有的软件将来都会被“装进”浏览器中,这个趋势谁也改变不了。ProcessOn的崛起也必将在不久的将来取代现在传统专业作图工具的市场份额和地位!一个浏览器,一个窗口,全部搞定。

使用了一会,感觉很不错,期待会有数据相关展示控件,在我看来ProcessOn是一个动词,开始吧,On一下!

ProcessOn:www.ProcessOn.com

Server Name Indication是用来改善SSL(Secure Socket Layer)和TLS(Transport Layer Security)的一项特性。它允许客户端在服务器端向其发送证书之前请求服务器的域名。这对于在虚拟主机模式使用TLS是必要的。
TLS背景
加密一个面向流的通讯会话最常用的方法之一就是使用TLS协议。比如,当用户在浏览器的地址栏里面输入https时就是在使用这个协议。
为了确认用户想要连接的站点就是浏览器实际连接到的站点,TLS使用包含站点域名的数字签名证书。客户端软件(比如浏览器)通常信任这个证书,如果这个证书是由其内置信任的认证机构签发的。
在TLS启动阶段,客户端软件比较用户输入的URI的域名部分与在服务器证书里面找到的域名部分,如果比较失败,浏览器会提示用户,这个站点的证书存在问题。
缺点
SSL v2的设计顺应经典的公钥基础设施PKI(public key infrastructure)设计,后者认为一个服务器只提供一个服务从而也就只使用一个证书。这意味着服务器可以在TLS启动的早期阶段发送或提交证书,因为它知道它在为哪个域服务。
HTTP服务器开启虚拟主机支持后,每个服务器通过相同的地址可以为很多域提供服务。服务器检查每一个请求来决定它在为哪个域服务。这个信息通常从HTTP请求头获得。不幸的是,当设置了TLS加密,服务器在读取HTTP请求里面的域名之前已经向客户端提交了证书,也就是已经为默认域提供了服务。
因此,这种为虚拟主机提供安全的简单途径经常导致使用了错误的数字证书,从而导致浏览器对用户发出警告。
钓鱼连接
实际上,这意味着每一个HTTP服务器只能为一个域提供安全浏览。而事实上每一个web服务器都为很多域提供服务,结果就是其他的域无法使用安全通信,从而处于危险境地。此外,安全浏览的缺乏使浏览器无法认证服务器,亦即它无法校验站点是否真的是属于宣称它的那个人或实体。钓鱼的一个重要因素是他们企图通过虚假站点来获取用户的信息。使用SSL或者TLS安全连接,浏览器可以基于它的证书来认证站点。钓鱼站点不会作为一个欺骗性的站点得到认证,浏览器会警告这个安全风险。然而,没有安全HTTP就没有标准的方法去认证服务器,使这种钓鱼的企图很容易就能实现。
修正
一个叫做SNI的TLS扩展通过发送虚拟域的名字做为TSL协商的一部分修正了这个问题。这会使服务器更早的切换到正确的虚拟域,并且发送给浏览器包含正确名字的数字证书。
行动
在2005年,人们意识到从SSL v2到TLS没有很容易的升级路径,并且站点不得不升级他们的软件来。为了尽快的推进,Mozilla宣告完全抛弃对SSL v2的支持。Firefox社区确信其余的站点会升级他们的服务器到SSL v3或TLS v1。
从2005年开始,CAcert在虚拟服务器上用不同的方法使用TLS来进行试验,大部分试验是不满意并且不实际的。比如,可以使用subjectAltName在一个数字证书中包含多个域,但是这是一个证书,意味着所有的域必须被一个人拥有并控制,并且每次域列表发生变化,证书必须重新发放。
2004年,EdelKey project为OpenSSL里面的TLS/SNI开发了一个补丁。2006年这个补丁进入OpenSSL的开发分支,2007年,它被向后移植到了OpenSSL 0.9.8,也就是当前的发行版本。
支持状况
支持SNI的浏览器
* Mozilla Firefox 2.0 or later
* Opera 8.0 or later (the TLS 1.1 protocol must be enabled)
* Internet Explorer 7 (Vista, not XP) or later
* Google Chrome (Vista, not XP)
* Safari 3.2.1 Mac OS X 10.5.6
支持SNI的服务器
* Apache 2.2.12 or later using mod_ssl (or alternatively with experimental mod_gnutls)
* Cherokee if compiled with TLS support
* Versions of lighttpd 1.4.x and 1.5.x with patch
* Nginx with an accompanying OpenSSL built with SNI support
* acWEB with OpenSSL 0.9.8j and later (on Windows)
支持SNI的库
* Mozilla NSS 3.11.1 client side only
* OpenSSL
0.9.8f (released 11 Oct 2007) – not compiled in by default, can be compiled in with config option ‘–enable-tlsext’.
0.9.8j (released 07 Jan 2009) – now compiled in by default
Unreleased 0.9.9 is likely to include SNI compiled in by default.
* GNU TLS
不支持SNI的操作系统,浏览器和库
客户端
* Windows XP and Internet Explorer
* Konqueror/KDE in any version
服务器端
* Microsoft Internet Information Server IIS (As of 2009).
* Qt
* Mozilla NSS server side
* Python
------------------------------------------
ipaddr注:
------------------------------------------
语言支持能力:
JavaSE 7+ & HttpClient 4.3.2+
PHP 5.3.2 + openssl 0.9.8f+
工具支持能力:
curl 7.18.1+ & openssl 0.9.8j+  
wget 1.14+ & openssl 0.9.8j+  
(单向认证的情况下,低版本curl可以通过-k参数来规避,低版本wget可以通过--no-check-certificate来规避,但双向认证只能升级新版本)
其它支持情况,请参考: http://en.wikipedia.org/wiki/Server_Name_Indication

CATool

一、简介

CATool是 鱼漂[admin.net(#)163.com] 使用DOS命令编写的,一个简单的,生成供Apache使用的数字证书的小工具,CATool运行在Windows操作系统上;此工具已内置openssl,并使用它来生成数字证书。

CATool参考了另外一个Bash写的脚本 ( http://www.openssl.org/contrib/ssl.ca-0.1.tar.gz ),并增加了部分功能。(如果您在Windows中安装Cygwin的话,仍然可以在Windows下使用ssl.ca-0.1.tar.gz,如果没有安装Cygwin,请在Windows下使用CATool).

CATool调用openssl来生成数字证书,生成的证书可以给Windows或Unix(Linux)下的Apache使用,以支持Apahce的HTTPS。

您可以在 http://www.eit.name/catool/ 找到CATool的最新版本和用法。

此外,openssl官网的工具增强版也可以此下载


201404:第二次更新,更新openssl的版本(Win7下运行正常),避免对vc7运行库的依赖,增加客户端证书签发功能.linux下官方版本增强.

分页: 1/20 第一页 1 2 3 4 5 6 7 8 9 10 下页 最后页 [ 显示模式: 摘要 | 列表 ]