标签 学习 下的文章

Ubuntu Server 14.04安装docker

近期在研究docker这一轻量级容器引擎,研究docker对日常开发测试工作以及产品部署运维工作能带来哪些便利。前些时候刚刚将工作环境从 Ubuntu搬到了Mac Air上,对Mac OS X的一切均不甚熟悉,给docker研究带来了不便,于是打算在VirtualBox中安装一Ubuntu Server作为docker之承载平台。这里记录一下安装配置过程,主要为了备忘,如果能给其他人带来帮助,我会甚感欣慰。

docker官方对ubuntu的支持是蛮好的。docker对Linux内核版本有要求,要>=3.8,Ubuntu Server目前最新版本14.04.1恰符合这一要求,其kernel version = 3.13.0-32。

一、VirtualBox安装Ubuntu Server 14.04.1

VirtualBox安装Ubuntu OS做过了不止一遍,即便是换成最新的14.04.1 Server版,差别也没有太多,无非是按照安装提示,逐步Next。这里给Ubuntu Server 14.04分配了1G Memory, 32G动态硬盘空间。

【配置源】

  默认情况下,/etc/apt/sources.list中只有一组源:cn.archive.ubuntu.com/ubuntu。这个国外源的下载速度显然无法满足我的要求,于是我把我常用的sohu源加入sources.list中,并且放在前面:

  deb http://mirrors.sohu.com/ubuntu/ trusty main restricted
  deb http://mirrors.sohu.com/ubuntu/ trusty-security main restricted
  deb http://mirrors.sohu.com/ubuntu/ trusty-updates main restricted
  deb http://mirrors.sohu.com/ubuntu/ trusty-proposed main restricted
  deb http://mirrors.sohu.com/ubuntu/ trusty-backports main restricted

  deb-src http://mirros.sohu.com/ubuntu/ trusty main restricted
  deb-src http://mirrors.sohu.com/ubuntu/ trusty-security main restricted
  deb-src http://mirrors.sohu.com/ubuntu/ trusty-updates main restricted
  deb-src http://mirrors.sohu.com/ubuntu/ trusty-proposed main restricted
  deb-src http://mirrors.sohu.com/ubuntu/ trusty-backports main restricted

  公司采用代理访问外网,于是还得在/etc/apt/apt.conf中加上代理的设置,否则无法更新源,也就无法安装第三方软件:

  Acquire::http::Proxy "http://username:passwd@proxyhost:proxyport";

 【乱码处理】

  由于安装时候选择了中国区域(locale zh_CN.UTF-8),因此在VirtualBox的窗口中直接执行命令的提示信息可能是乱码。对于Server,我们一般是不会直接通过其主机显示 器登录使用的,都是通过终端访问,但在未安装和开启ssh服务和未配置端口转发前,我们只能先凑合这个窗口了。可先将/etc/default /locale中的LANGUAGE由"zh_CN:zh"改为"en_US:en", logout后重新登录就可以看到非乱码的英文提示信息了。

【安装VirtualBox增强组件】

  Ubuntu Server默认是不安装图形桌面的,只有一个命令行窗口,连鼠标都无法使用。因此增强组件安装的意义没有桌面系统那么强烈。我能想到的只有“共享目录”这一个功能有些用处。

  安装方法也不难,按下面步骤逐步操作即可:

  sudo apt-get install build-essential linux-headers-$(uname -r) dkms gcc g++
  sudo mnt /dev/cdrom /mnt
  cd /mnt
  sudo bash ./VBoxLinuxAdditions.run

  如果结果都是"done",重启后就ok了。

【安装ssh服务】

    ssh服务由openssh-server提供:
    sudo apt-get openssh-server
   
   安装成功后,ssh server服务就会自动启动起来。

   不过我们还是需要修改一些配置,比如允许Root登录:打开/etc/ssh/sshd_config,将PermitRootLogin后面的内容改为yes。
   
【设置端口转发】

  前面说过,对于Server,我们更多是在其他主机上通过ssh或telnet远程访问该Server并执行各种操作。由于这里是VirtualBox安 装的虚拟机,其他主机无法看到这台Server,我们需要设置端口转发将外部访问的数据转发给这个内部虚拟Server。

  我们通过VirtualBox软件提供的图形界面即可完成这个操作:
    1、“设置”这个虚拟机
    2、在“网络”标签中,点击“端口转发”按钮,进入端口转发规则添加窗口。
    3、添加一条规则:
          名称:ssh-rules
          协议:TCP
          主机IP、子系统IP可以为空。
          主机端口:2222
          子系统端口:22
   4、配置结束

    配置结束后,我们在宿主机上netstat -an|grep 2222,可以看到VirtualBox增加了该端口2222的监听。

  现在我们就可以在其他机器上通过ssh -l tonybai 宿主机ip -p 2222的方式登录到我们新安装的这台虚拟Server了。

  
二、安装docker

docker目前的最新版本号是1.2.0,但14.04源中的docker还是正式稳定版1.0之前的版本,显然这是无法满足我的要求的。我们只能另外添加docker源来安装最新版docker。

  【安装docker】

    我们在/etc/apt/sources.list中加入下面这个源:
       deb http://mirror.yandex.ru/mirrors/docker/ docker main
  
    执行apt-get update。

    sudo apt-get install lxc-docker

正在读取软件包列表… 完成
正在分析软件包的依赖关系树      
正在读取状态信息… 完成      
将会安装下列额外的软件包:
  aufs-tools cgroup-lite git git-man liberror-perl lxc-docker-1.2.0
建议安装的软件包:
  git-daemon-run git-daemon-sysvinit git-doc git-el git-email git-gui gitk
  gitweb git-arch git-bzr git-cvs git-mediawiki git-svn
下列新软件包将被安装:
  aufs-tools cgroup-lite git git-man liberror-perl lxc-docker lxc-docker-1.2.0
升级了 0 个软件包,新安装了 7 个软件包,要卸载 0 个软件包,有 59 个软件包未被升级。
需要下载 7,477 kB 的软件包。
解压缩后会消耗掉 35.4 MB 的额外空间。
您希望继续执行吗? [Y/n] y

  这个源里的docker居然是最新版。于是安装之。安装后,我们执行docker version来确认一下安装是否成功。

  tonybai@ubuntu-Server-14:~$ docker version
Client version: 1.2.0
Client API version: 1.14
Go version (client): go1.3.1
Git commit (client): fa7b24f
OS/Arch (client): linux/amd64
2014/09/26 13:56:53 Get http:///var/run/docker.sock/v1.14/version: dial unix /var/run/docker.sock: permission denied

  【为docker设置http代理】

    在公司内使用代理才能访问到外网,于是我们也需要为docker命令设置代理以使其顺利执行命令。

    我们安装的docker实际上分为两部分,docker命令行和docker daemon。两者是C/S结构,docker命令行将用户的请求转发给docker daemon,后者会真正与外部通信完成各种操作。

    于是我们可以这样为docker daemon设置http_proxy:
    sudo service docker stop
    sudo http_proxy='http://user:passwd@proxyhost:port' docker -d &

    这样设置启动后,我们可以通过下面命令测试设置是否ok:

      sudo docker search ubuntu

    如果你看到下面信息,说明设置成功了:

    tonybai@ubuntu-Server-14:~$ sudo docker search ubuntu
[info] GET /v1.14/images/search?term=ubuntu
[b36518a9] +job search(ubuntu)
[b36518a9] -job search(ubuntu) = OK (0)
NAME                                             DESCRIPTION                                     STARS                                   OFFICIAL   AUTOMATED
ubuntu                                           Official Ubuntu base image                      709                                     [OK]      
dockerfile/ubuntu                                Trusted automated Ubuntu (http://www.ubunt…   24                                                 [OK]
crashsystems/gitlab-docker                       A trusted, regularly updated build of GitL…   20                                                 [OK]
ubuntu-upstart                                   Upstart is an event-based replacement for …   13                                      [OK]      

… ….

 

关于编程语言学习的一些体会

Learn at least one new language every year.
                                              — Andy Hunt and Dave Thomas

自己一直是“每年学习一门新语言”的忠实拥趸,曾先后认真地学习了HaskellCommon LispPythonGo等语言,对PrologScalaErlangLuaPHP也有一定了解。但几年下来,只有Python一门语言算 是真正被留在我的大脑里,用在了工作中。其他那几门语言留下来的只是一些思想了。这似乎符合了Andy Hunt和Dave Thomas在《程序员修炼之道》中对于这一实践目的的阐述:“学会用多种方式解决问题,扩展我们的视野,避免思路僵化和停滞不前”^_^。

即便是残存的思想,其实也并不深刻。要真正会运用新思维并非那么简单。一门编程语言从入门到精通,至少要经历学语法、做实践、用idioms(写出地道的代码)三个阶段。这让我深刻的感悟到:不以使用为目的的语言学习,都是在浪费生命

有精力多学习些语言自然很好,我迫切期待能拥有一个像“七龙珠”中孙悟空那样的“精神时光屋”呢。但现实中,人的精力是有限的,而我们要面对的计算机科学领域中的知识、技能以及问题却似乎是无限的。因此在“每年至少学习一门新语言”这一实践上,建议不要过于教条。 从编程语言自身来看,范型(Paradigm)是影响语言思维差异的主要因素,而编程语言的范型有限,主流的也就那么几种:命令式(过程式)、函数式、逻 辑式、面向对象等。每种范型的背后都有几种、十几种甚至几十种语言,我们其实没有必要都去学。从拓展视野的角度去说,从每种主流范式中找到一两门典型的语 言去学习就可以了。比如命令式的,我们可以选择C;函数式我们选择Haskell;逻辑式的选择Prolog;面向对象的选择Java等。

即便是从每个范型中挑出一门,你要付出的精力依旧不少,我们还要考虑其实用性:要以使用为目的。如果能将其用在工作中,天天与你相伴,被他人接受,自然最 好;退而求其次,你能找到一两个开源项目,并参与其中也是可以的,至少可以让你保持手热;如果这两点都无法做到,仅仅是凭借个人的热情与坚持,那是不会持 久的,若干时间后,你就会对其生疏,可能连基本的"Hello World"语法都记不得了。不过这个年头,思想也不能不要。在有剩余精力的前提下,挑选些牛人们极力“鼓吹”的语言,吸收一下其思想精华,说不定哪天就 能用得上,让自己和大家都感觉你很NB,抬高一下自己的身价^_^。记住:编程语言也是要拼爹的系出名门的语言(诸如Go、Dart等)自然得到更多的青睐、使用和推广,出位的几率也就高出许多,尤其是在目前新编程语言百花齐放的阶段。因此在选择有思想的新语言时,最好在这些名门之后中做优选。

这个时代喜欢“专家”,因此我们在一两门语言上务必要做到“精专”,这是会给你带来黄油和面包的语言。要专到什么程度呢?我有一个同事,什么问题都用C解决。他甚至为此写了个不小的基础框架,所有业务问题的Code放在框架中被回调即可,即便是这个问题用Python实现只需几行代码。

计算机科学的研究核心是什么?我想肯定不是编程语言,就好比社会科学研究的核心不是人类语言一样。我比较欣赏这样的观点:作为程序员而言,最重要的是去创造,而不是研究。我们应更多的利用已经掌握的语言解决现实中的问题。做 编程语言研究的人可能要了解各种语言的特点与实现方式,但对于大多数的程序员来说,其实我们只需要关注问题域:做底层平台开发的,关注机器模型、通信原理 以及OS原理和实现细节;做算法的,很荣幸,那才是正统的程序设计的核心;前端攻城师则更多关注用户的体验。而在这些解决实际问题的过程中,我们更多采用 的是“制式”的编程语言。即做平台开发的,一般用C,C++等系统编程语言,更多的考虑的是性能;做前端开发的,PHP/JavaScript不可或缺。 我们要考虑的是如何利用这些制式的编程语言去解决问题,而在这些制式语言上,我们要做到精通。

从新兴语言中借鉴新思想,然后在旧语言中实现新语言的特性,其实更多是在旧语言中实现了某 种语法糖,你爱吃,不代表其他人也理解也爱吃,还容易被人误认为是“炫技”。如果你是技术负责人,且经过评估,新语言十分适合这个问题域,那莫不入直接引 入这门语言,让大家都能使用到这门语言的新思想、新特性。

辩证的说,任何一种编程语言都有其利与弊,比如Haskell,纯函数式语言,变量不能改变,无状态,对并行处理具有天然的适应性,但在处理基本IO时却要编写难于理解的monad;而在命令式语言中,这种IO处理简直简单的不得了。

关于函数式语言,个人感觉未来若干年内仍难以大行其道,建议还是跟上命令式语言的演化主线吧。

跨越问题域学习语言,通常收获不大。一个做平台服务端,用惯了C的资深程序员,让他去学PHP写前端代码,估计是无法迸发出任何火花的。

以上是自己这些年关于编程语言学习的一些体会,比较零散,但希望能有帮助。

利用ZooKeeper服务实现分布式系统的配置数据同步

很多时候,一旦习惯了某些事情,也就习惯了它们的恶劣,习惯了它们的丑陋,习惯了它们“赋予”你的各种痛苦。
                                                                                                                                                      – Tony Bai

一、痼疾难解

曾几何时,在那个还没有集群化,没有分布式的时代,它还是一个不错的方案,至少在线上没有暴露出太多问题,它也不在我们关注的重点范围之内。但随 着集群化、分布式的新版本的到来,那一大坨遗留的代码就变得格外让人不顺眼,同时问题也随之在线上暴露开来了。

这里的“它”指的就是我们目前的业务配置数据同步方案。简单描述这个方案如下:

* 方案涉及两个角色 – 数据库(DB)与应用节点(app_node);
* 所有的业务配置数据均统一存储在DB中;
* 应用节点在启动后从DB中读取最新业务配置数据;
* 应用节点运行过程中,如果DB中的业务配置数据发生变更(增/删/改),DB中的触发器(trigger)将会执行。在触发器的脚本中,触发器将会【串 行】地与每个应用节点建立TCP链接,并将业务配置表的变更信息发给各个应用节点。 应用节点会接收并【解析】触发器发过来变更数据包,并同步到自己的本地内存中。这样就达到了运行时更新配置的目的。

上面我用【】标记了两个关键词:“串行”和“解析”。这两个词隐含有这个方案的两个主要问题。

“串行” – 意味着每一次DB的业务配置数据变更,trigger脚本都要逐个与应用节点建立链接并收发数据。当应用节点逐渐增多时,每一次业务数据同步都会相当地耗 时。尤其是当某个应用节点所在主机出现问题时,到该节点链接建立的过程会阻塞,导致整个业务配置数据同步的时间达到无法忍受的地步。

“解析” – 我们自定义了trigger与应用节点之间的协议包。协议包中包含了每次变更的详细信息,比如在某个表添加一条记录,trigger会将这个记录的每个字 段信息排成一行打包发给应用节点。应用节点收到这个包后,会根据已有的表字段信息对该包进行解析。看得出这是一个很强的耦合:表字段一旦修 改,trigger脚本要修改,应用节点的解析函数要修改,还要考虑协议包中表字段的排序。如果应用节点解析时与trigger脚本打包时的字段 顺序不同的话,那就可能出现严重错误,而且这种错误有时难于校验并难于发现。

二、曾经的努力

针对这个方案的不足,我们曾经也做过改进,但主要针对的是解决“串行”这个问题上。

第一次改进:同步的发起能否并行做?trigger脚本能否并行发起对各个应用节点的链接建立请求?

Java组同事对trigger脚本做了改进。让trigger脚本调用function,而function中又调用了写好的Java方 法,Java代码由DB加载到环境中。在Java方法中创建多个同步线程,并发与各应用节点建立链接并发送数据。这个方法的确可以变“串行”为 “并行”,但不知为何生产环境中实际运行时偶尔会出现异常,该异常发生在DB中,影响很大。有时还会导致DB的一些异常现象。至今原因尚未明确, 我们无奈退回到以前的方案。

第二次改进:从Push模式到Pull模式

在之前部门新规划的一个产品中,开发人员对数据同步的机制做了重新的设计,将原来的Push模式改为了Pull模式。大致方案是:
   
    * 业务数据变更时,trigger直接将变更内容(以老方案中那个协议包的打包格式)写到一个“变更日志表”中,每条记录有一个唯一的序号,序号递增。
    * 应用节点启动后,从DB加载最新配置信息,查询“变更日志表”,得到该表内最新的一条记录的序号n。
    * 应用节点以“轮询”的方式定期查询“变更日志表”,并读取和解析那些序号比序号n更新的记录;更新完后,将继续保存最新的一条记录序号。
    * 数据库中有job定期对“变更日志表”中的记录进行过期删除处理。

个人感觉第二个方案应该是理想方案的一个雏形,虽然目前它的同步更新可能不是那么及时,与DB交互过多(方案细节中每个应用节点在处理完一条记录 后还要更新记录的状态)。该方案设计者也完全也可以放弃那个导致耦合的协议包设计,但他最终还是选择保留了原有协议包解析函数。目前该方案在产品 环境下运行还算良好,并未暴露出什么问题。这算是一次有效的改进,也为本文中要提到的方案提供了一些思路启示。

三、与时俱进

ZooKeeper生来就具备解决分布式系统的配置分发和同步的能力。利用ZooKeeper服务实现分布式系统的统一配置中心已经不是那么新鲜 的话题了。最简单的模型莫过于将配置数据存储在ZooKeeper上的路径节点上,然后应用节点在这些配置节点上添加watch。当配置数据变更 时,每个应用节点都可以及时得到通知,同步到最新数据。这种模型对于一些量少简单的系统配置来说较为合适。对于我们每个表动辄上万条配置的情形似 乎不那么适合,想象一下每个应用节点要添加上万个watch,这对ZooKeeper而言也是压力山大啊。因此用ZooKeeper提供的诸多服 务如何来优化我们上面提到的两个主要问题呢?这里提出一种方案仅供参考。

方案示意图:

DB  —-> Config Center Services(css_agent + ZooKeeper)  —> App Node

在新方案中,我们要:
    保留 – 保留trigger脚本,作为业务数据变更的唯一的触发起点;
    摒弃 – 摒弃那个复杂的带来耦合的协议格式;
    借鉴 – 借鉴“Push -> Pull”的数据获取方式。

新方案中除了DB、应用节点(app_node)外,新增加了一个角色Config Center Services(缩写为ccs),ccs由ZooKeeper + ccs_agent的集群组成。简单起见,每个ZooKeeper节点上部署一个ccs_agent。这些角色之间的数据流和指令流关系,即该方案的原理 如下:

    * 初始化
        – ZooKeeper集群启动;
        – ccs_agent启动,利用ZooKeeper提供的leader election服务,选出ccs_agent leader。ccs_agent leader启动后负责在ZooKeeper中建立业务配置表node,比如:表employee_info_tab对应的node路径为“/ccs /foo_app/employee_info_tab”;
        – ccs_agent启动后会监听一个端口,用来接受DB trigger向其发起的数据链接;
        – 应用节点启动,监听ZooKeeper上所有(数量有限的)业务配置表node的child event;
   
    * 数据变更
        – DB中某业务表比如employee_info_tab增加了一条id为"1234567"的记录;
        – 触发器启动,向ccs_agent cluster中任意一个可用的节点建立链接,并将数据包“^employee_info_tab|ADD|1234567$"发送给 ccs_agent;
        – ccs_agent收取并解析trigger发来的数据包,在对应的/ccs/foo_app/employee_info_tab下建立ZOO_SEQUENCE类 型节点“item-000000000”,该节点的值为“ADD 1234567";
        – ZooKeeper将/ccs/foo_app/employee_info_tab节点的child事件发给所有watch该节点事件的应用节点;
        – 应用节点“取出”/ccs/foo_app/employee_info_tab节点下的children节点"item-000000000",并读取 其值,后续到DB的employee_info_tab中将id = 1234567的这条记录select出来,将该条记录更新到本地内存中。应用节点记录下处理过的当下节点id为"item-000000000";
        – DB业务表employee_info_tab又增加了两条记录,id分别为"7777777"和"8888888",经过上面描述的流程,/ccs /foo_app/employee_info_tab节点下会增加"item-000000001"和"item-000000002"两项; 应用节点最终会收到child事件通知。应用节点“取出”/ccs/foo_app/employee_info_tab节点下的所有 children节点并排序。之后,处理那些id号大于"item-000000000"的节点,并将当前节点id记录为“item- 000000002"。依次类推。

    * 过期处理
        – ccs_agent leader负责定期扫描ZooKeeper中/ccs下各个表节点下的子项,对于超出过期时间的item进行删除处理。

    * 应用节点重启
        -  应用节点重启后,会首先从db读取最新信息,并记录启动时间戳;
        -  应用节点重启后,在收到zookeeper的数据变更事件后,会根据当前时间戳与变更表节点下的item创建时间进行比较,并仅处理比启动时间戳新的 item的数据。
   

这个方案主要利用了ZooKeeper提供的leader election服务以及sequence节点的特性,几点好处在于:

    – 串行通知变为并行通知,且通知到达及时;
    – 变更数据的Push模式为Pull模式,降低了或去除了诸多耦合,包括:
            1) 去除trigger脚本与表字段及字段顺序的耦合;
            2) 去除应用节点与表字段顺序的耦合;
            3) 降低应用节点与表字段构成的耦合。
    – 应用节点无需复杂的包解析,简化后期维护。

当然为了该方案新增若干网元会给产品部署和维护带来一些复杂性,这算是不足之处吧。

四、Demo

这里有一个600多行代码的Demo,模拟新方案中几个角色:
    DB – trigger_sim.py
    应用节点 – app.c
    ccs_agent – ccs_agent.c

模拟的步骤大致如下(单机版):

a) 启动ZooKeeper
    $> zkServer.sh start
    JMX enabled by default
    Using config: /home1/tonybai/.bin/zookeeper-3.4.5/bin/../conf/zoo.cfg
    Starting zookeeper … STARTED

b) 启动ccs_agent
    $> ccs_agent
    This is [ccs-member0000000037], i am a leader
    /ccs node exists
    /ccs/employee_info_tab node exists
    /ccs/boss_info_tab node exists
    trigger listen thread start up!
    item expire thread start up!

c) 启动app

d) 使用trigger_sim.py模拟DB触发trigger
        $> trigger_sim.py employee_info_tab ADD 1234567

可以看到ccs_agent输出结果如下:
    table[employee_info_tab], oper_type[ADD], id[1234567]

app的输出如下:
    child event happened: type[4]
    item-0000000015
    employee_info_tab: execute [ADD 1234567]

大约30s后,ccs_agent会输出如下:
    [expire]: employee_info_tab: expire [item-0000000015]

模拟步骤在README里有写。这里仅是Demo代码,存在硬编码以及异常处理考虑不全面的情况,不要拍砖哦。




这里是Tony Bai的个人Blog,欢迎访问、订阅和留言!订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:


如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:


以太币:


如果您喜欢通过微信App浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:



本站Powered by Digital Ocean VPS。

选择Digital Ocean VPS主机,即可获得10美元现金充值,可免费使用两个月哟!

著名主机提供商Linode 10$优惠码:linode10,在这里注册即可免费获得。

阿里云推荐码:1WFZ0V立享9折!

View Tony Bai's profile on LinkedIn


文章

评论

  • 正在加载...

分类

标签

归档











更多