• Feeds

  • Posts Tagged ‘docker’


    我为什么选择DigitalOcean VPS来做开发

    工程师在开发过程中经常需要下载及实时访问国外各种软件及服务,比如从github下载软件及在Linux上运行docker等软件,通常会在本机创建虚拟机或者通过一些公共的测试服务器来进行,我为什么选择付费的DigitalOcean来当做自己的开发环境? 本文介绍DigitalOcean相对于自建服务器及其他VPS如Linode的优势。

    先说一个案例,一个月前某工程师说,“看了你写的kubernetes文章后,我也打算试下”。最近再碰到他时,他很惭愧的说,“试了好多次,还没跑通”。在国内运行各种常用开发软件确实存在访问国外云服务及各种软件的问题,一方面速度慢,另外也存在不少资源莫名其妙就被墙了,因此更推荐大家使用国外的VPS来进行日常的学习及测试。因此给大家介绍Tim日常使用DigitalOcean(简称DO)的一些便利之处。

    1. 虽然大家所在公司也都有公共测试服务器,但是使用这些资源通常面临多人共同使用的冲突;独占的服务器通常需要领导审批,也存在随时被业务征用走的情况。而在自己工作电脑创建虚拟机则由于占用资源较大,影响本身工作环境效率。使用云主机创建帐号开通一个虚拟机只需要几秒钟,不会出现启动的服务被人停掉的困扰。
    2. DigitalOcean是经过Tim比较后一种性价比非常高的VPS,它的特点是全SSD存储,费用低,比同类型的云服务及VPS如Linode更便宜。按小时计费,基本款每天开24小时只需要1.04元人民币。如果只开1小时,则只收费1小时,不到1毛钱。
    3. 与Linode相比,稳定性基本相当,Tim的博客从Linode迁移到DigitalOcean已经有半年以上,没碰到过稳定性方面问题。
      清华大学的梁斌博士比较了大量VPS之后也称赞digitalocean

      最近try了很多厂商的vps,一个体会,凡是没有名气的,大多比较渣。而且有个特点,只卖小机器,不卖多cpu,大内存的,很显然小机器好超卖啊。整个vps提供商比较业界良心的也就linode和digital ocean了,他们是把这事当事业在做的。

    4. DigitalOcean支持CoreOS,CoreOS是一种天生为容器而设计的Linux发行版,由于CoreOS没有包管理工具,无法直接安装各种应用,所有的功能推荐用容器来实现,因此可以帮助大家在测试Docker环境时更好理解容器化理念、更好的分清宿主机与容器的边界、更好的理解分布式的容器及服务。DigitalOcean自带了较新版本的CoreOS,利用CoreOS自带的docker,创建虚拟机后1分钟内就可以完成下载镜像及启动容器的工作。
    5. DO的网速很快,可极大提升工作效率,在DigitalOcean美国机房访问github等资源基本上一回车就下载完了,从docker registry拉一个200M的unbutu镜像只要数秒。而国内访问大部分技术资源速度比较慢,比如CoreOS默认是在线安装方式,在国内装CoreOS要2小时以上;从Docker registry下载一个ubuntu image也需要20分钟左右。
    6. 建议使用以下推荐链接 https://www.digitalocean.com/?refcode=b5d7cd2d0410 来注册用户,当你使用及付费后,Tim可以获得一杯咖啡左右的推荐费的好处,你可以获得$10的奖励费用,相当免费使用2个月。

    PS:给那些申请成功的同学:

    1、CoreOS默认的用户名不是你的 ssh-key 指定的用户或 root,而是 core,因此使用以下命令登录。
    ssh -i ssh-key-file core@ip
    2、Droplet在服务器不启动时可能也会收费,如果是测试用途,长时间不用前建议将Droplet删除,以免产生额外费用。

    3、DO美国机房从国内SSH访问会有丢包的情况,可以尝试MOSH来代替SSH,也可以选择新加坡机房。

    4、DO的文档也非常丰富,英文熟练的同学可以参看 tutorials

    Kubernetes – Google分布式容器技术初体验

    Kubernetes是Google开源的容器集群管理系统。前几天写的 分布式服务框架的4项特性 中提到一个良好的分布式服务框架需要实现

    服务的配置管理。包括服务发现、负载均衡及服务依赖管理。
    服务之间的调度及生命周期管理。

    由于Kubernetes包含了上述部分特性,加上最近Google新推出的Container Engine也是基于Kubernetes基础上实现,因此最近对Kubernetes进行了一些尝试与体验。

    运行环境

    Kubernetes目前处于一个快速迭代的阶段,同时它的相关生态圈(比如docker,etcd)也在快速发展,这也意味没有适合新手使用非常顺畅的版本,网上的各种文档(也包括官方文档)和当前最新的发布版会有不同程度滞后或不适用的情况,因此在使用时可能会碰到各种细节的障碍,而且这些新版本碰到的问题,很有可能在网上也搜索不到解决方案。

    Kubernetes设计上并未绑定Google Cloud平台,但由于以上原因,为了减少不必要的障碍,初次尝试建议使用GCE作为运行环境(尽管GCE是一个需要收费的环境)。默认的cluster启动脚本会创建5个GCE instance,测试完需要自己及时主动删除。为了避免浪费,可以将minions减少,同时instance类型选择f1-micro。费用方面一个f1-micro instance运行1个月大约50元人民币,因此用GCE来测试Kubernetes,如果仅是测试时候开启的话,并不会产生太多费用。

    Pods及Replication Controller

    Kubernetes的基本单元是pods,用来定义一组相关的container。Kubernetes的优点是可以通过定义一个replicationController来将同一个模块部署到任意多个容器中,并且由Kubernetes自动管理。比如定义了一个apache pod,通过replicationController设置启动100个replicas,系统就会在pod创建后自动在所有可用的minions中启动100个apache container。并且轻松的是,当container或者是所在的服务器不可用时,Kubernetes会自动通过启动新的container来保持100个总数不变,这样管理一个大型系统变得轻松和简单。

    kubernetes

    Service 微服务

    在解决部署问题之后,分布式服务中存在的一大难题是服务发现(或者叫寻址),用户访问的前端模块需要访问系统内部的后端资源或者其他各种内部的服务,当一个内部服务通过replicationController动态部署到不同的节点后,而且还存在前文提到的动态切换的功能,前端应用如何来发现并访问这些服务?Kubernetes的另外一个亮点功能就是service,service是一个pod服务池的代理抽象,目前的实现方法是通过一个固定的虚拟IP及端口来定义,并且通过分布在所有节点上的proxy来实现内部服务对service的访问。

    Kubernetes自身的配置是保存在一个etcd(类似ZooKeeper)的分布式配置服务中。服务发现为什么不通过etcd来实现?Tim的判断更多的是为了Kubernetes上的系统和具体的配置服务解耦。由于服务发现属于各个系统内部的业务逻辑,因此如果使用etcd将会出现业务代码的逻辑中耦合了etcd,这样可能会让很多架构师望而却步。

    尽管没有耦合etcd,部署在Kubernetes中的服务需要通过container中的环境变量来获得service的地址。环境变量虽然简单,但它也存在很多弊端,如存在不方便动态更改等问题。另外service目前的实现是将虚拟IP通过iptables重定向到最终的pod上,作者也提到iptables定向的局限性,不适合作为大型服务(比如上千个内部service一起运作时)的实现。

    services_detail

    由于service定位是系统内部服务,因此默认情况下虚拟IP无法对外提供服务,但Kubernetes当前版本并没直接提供暴露公网IP及端口的能力,需要借助云服务(比如GCE)的load balancer来实现。

    小结

    总的看来Kubernetes提供的能力非常令人激动,pod、replicationController以及service的设计非常简单实用。但如果立即将服务迁移到Kubernetes,还需要面对易变的环境。另外尽管Kubernetes提供health check的机制,但service生产环境所需的苛刻的可用性还未得到充分的验证。Service发现尽管不跟Kubernetes的内部实现解耦,但利用环境变量来实现复杂系统的服务发现也存在一些不足。

    安装说明

    Kubernetes cluster简单安装说明如下,需要尝试的朋友可参考。

    前提准备
    一个64 bit linux环境,最好在墙外的,避免访问google cloud出现超时或reset等问题;另外创建Google Cloud帐号,确保创建instances以及Cloud Storage功能可用;

    安装步骤
    1. 安装go语言环境(可选,如果需要编译代码则需要)

    2. 安装Google cloud sdk
    $ curl https://sdk.cloud.google.com | bash
    $ gcloud auth login
    按提示完成授权及登录

    3. 安装 etcd 二进制版本(V0.4.6), 解压后将其目录加入PATH

    4. 安装 kubernetes最新的relase binary版本(V0.5.1)
    修改 cluster/gce/config-default.sh,主要是修改以下字段以便节约资源。

    MASTER_SIZE=f1-micro
    MINION_SIZE=f1-micro
    NUM_MINIONS=3
    

    在kubernetes目录运行
    $ cluster/kube-up.sh

    执行成功后会显示 done

    5. 测试pod
    以上脚本启动了examples/monitoring 下面定义的service,如果尝试启动其它自己的pods,比如启动一个tomcat集群

    {
      "id": "tomcatController",
      "kind": "ReplicationController",
      "apiVersion": "v1beta1",
      "desiredState": {
        "replicas": 2,
        "replicaSelector":{"name": "tomcatCluster"},
        "podTemplate":{
      "desiredState": {
        "manifest": {
          "version": "v1beta1",
          "id": "tomcat",
          "containers": [{
            "name": "tomcat",
            "image": "tutum/tomcat",
         "ports": [
         {"containerPort":8080,"hostPort":80}
         ]
         }]
        }
      },
      "labels": {"name": "tomcatCluster"}}
      },
      "labels": {
        "name": "tomcatCluster",
      }
    }
    

    其中pod的tomcat image可以通过Docker Hub Registry https://registry.hub.docker.com/ 搜索及获取

    $ cluster/kubectl.sh create -f tomcat-pod.json

    创建成功后通过 cluster/kubectl.sh get pods 来查看它所在minion及ip,可以通过curl或浏览器来访问(请开启GCE防火墙端口设置)。

    再定义一个 service

    {
      "id": "tomcat",
      "kind": "Service",
      "apiVersion": "v1beta1",
      "port": 8080,
      "containerPort": 8080,
      "labels": {
        "name": "tomcatCluster"
      },
      "selector": {
        "name": "tomcatCluster"
      }
    }
    

    保存为 tomcat-service.json

    $ cluster/kubectl.sh create -f tomcat-service.json
    检查service启动后的ip及端口,由于service是内部ip,可以在GCE上通过curl来测试及验证。
    $ cluster/kubectl.sh get services

    6. 关闭cluster
    cluster/kube-down.sh