From dc561beb6ed9a859a458c2eaf7adaedd4dbdf17e Mon Sep 17 00:00:00 2001 From: Administrator Date: Mon, 30 Mar 2015 10:17:27 +0800 Subject: [PATCH] update --- .DS_Store | Bin 0 -> 6148 bytes ...ecipes-javaee-applications-techtip80-cn.md | 168 ++++++ ...-and-Docker-comparable-and-different-cn.md | 11 + apache-mesos-vs-hadoop-lt.md | 504 ++++++++++++++++ difference-between-docker-and-vgrant-cn.md | 10 +- docker-machine-compose-swarm-cn.md | 569 ++++++++++++++++++ docker-security-tuning-cn.md | 159 +++++ friends-cn.md | 1 + question-cn.md | 27 + ...tributed-configuration-stores-cn-review.md | 119 ++++ 10 files changed, 1563 insertions(+), 5 deletions(-) create mode 100644 .DS_Store create mode 100644 9-docker-recipes-javaee-applications-techtip80-cn.md create mode 100644 How-are-OpenShift-OpenStack-Kubernetes-and-Docker-comparable-and-different-cn.md create mode 100644 apache-mesos-vs-hadoop-lt.md create mode 100644 docker-machine-compose-swarm-cn.md create mode 100644 docker-security-tuning-cn.md create mode 100644 friends-cn.md create mode 100644 question-cn.md create mode 100644 the-docker-ecosystem-service-discovery-and-distributed-configuration-stores-cn-review.md diff --git a/.DS_Store b/.DS_Store new file mode 100644 index 0000000000000000000000000000000000000000..5008ddfcf53c02e82d7eee2e57c38e5672ef89f6 GIT binary patch literal 6148 zcmeH~Jr2S!425mzP>H1@V-^m;4Wg<&0T*E43hX&L&p$$qDprKhvt+--jT7}7np#A3 zem<@ulZcFPQ@L2!n>{z**++&mCkOWA81W14cNZlEfg7;MkzE(HCqgga^y>{tEnwC%0;vJ&^%eQ zLs35+`xjp>T0 -e MYSQL_PORT = 5306 -p 8080：8080 -d arungupta / wildfly-的mysql-javaee7 +完整的细节这个配方在多个主机泊坞窗容器联解释。 + +泊坞窗配方＃7：两个容器上使用泊坞窗群不同的主机 + +泊坞窗机 + +泊坞窗群是本地集群的码头工人。原来泊坞窗主机池成一个单一的，虚拟主机。它拿起向上，其中泊坞窗机通过优化主机资源利用率​​，并提供故障转移服务留下了。具体来说，泊坞窗群允许用户创建运行泊坞窗守护进程的主机资源池，然后安排泊坞窗容器之上运行，自动管理工作量安置和维护群集状态。 + +关于这个配方的更多细节即将在随后的博客。 + +泊坞窗配方＃8：从Eclipse中部署Java EE应用程序 + +最后一个配方将处理如何将现有的应用程序部署到泊坞窗容器。 + +比方说，你正在使用JBoss的工具为你的开发环境和WildFly为您的应用程序服务器。 + +Eclipse的标志JBoss的工具徽标 + +有一对夫妇的方法，使这些应用程序可以部署： + +使用泊坞窗卷+本地部署：在这里，你的本地计算机上的某个目录安装为泊坞窗卷。 WildFly泊坞窗容器开始通过映射该目录的部署目录为： +泊坞窗运行 - 它-p 8080：8080 -v /用户/ arungupta的/ tmp /部署中：/ opt / JBoss的/ wildfly /独立/部署/：RW的JBoss / wildfly +配置JBoss工具WAR文件部署到该目录。 + +使用WildFly管理API +远程部署：启动WildFly泊坞窗容器，还揭露管理端口9990为： +泊坞窗运行 - 它-p 8080：8080 -p 9990：9990 arungupta / wildfly管理 +配置JBoss的工具来使用远程服务器WildFly和部署使用管理API。 + +这个配方进行了详细的部署，从Eclipse的解释WildFly和泊坞窗。 + +泊坞窗配方＃9：使用的Arquillian立方测试的Java EE应用程序 + +的Arquillian立方允许您控制泊坞窗图像的生命周期作为测试生命周期的一部分，无论是自动还是手动。多维数据集使用泊坞窗REST API交谈的容器。它使用了远程适配器的API，例如WildFly在这种情况下，进行通话的应用程序服务器。泊坞窗的配置被指定为Maven的万无一失，作为插件的一部分： + +<配置​​> +     +     wildfly-泊坞窗 +    admin +    Admin#70365 +     1.15 +     http://127.0.0.1:2375 +     +        wildfly-泊坞窗： +            图片：arungupta / javaee7样本，wildfly +            exposedPorts：[8080 / TCP，9990 / TCP] +            等待： +                策略：投票 +                sleepPollingTime：50000 +                迭代：5 +            portBindings：[8080 / TCP，9990 / TCP] +     +     + +可使用的Arquillian立方的码头工人运行的Java EE测试这个食谱完整细节。 + +你使用的是什么其他的配方使用泊坞窗来部署Java EE应用程序？ + +享受！ \ No newline at end of file diff --git a/How-are-OpenShift-OpenStack-Kubernetes-and-Docker-comparable-and-different-cn.md b/How-are-OpenShift-OpenStack-Kubernetes-and-Docker-comparable-and-different-cn.md new file mode 100644 index 0000000..fc589dd --- /dev/null +++ b/How-are-OpenShift-OpenStack-Kubernetes-and-Docker-comparable-and-different-cn.md @@ -0,0 +1,11 @@ +作为一个非常大的简化，可以看到泊坞窗（和一般的容器），薄的虚拟机，Openshift具有自己的Heroku和OpenStack的是拥有自己的AWS。 + +泊坞窗容器使用，让你在运行一个独立的网络应用程序，Linux内核的功能/内存/程序/文件系统环境，并增加了使用的unionfs的，所以你可以有一个“父”只写磁盘，一个孩子写的图像文件系统，在那里你有，如果你修改父文件写入时复制，并且能够让你有几个孩子共享相同的父（所以如果你有使用Ubuntu的基本安装，你只有一次几个容器，即使缓存上存储器一次）。它有一个灵活的API和命令行工具，用于创建容器，做一些基本的管理，把它们放在中央或你自己的资料库和更多。也让容器关联容器（想想之一DB，另一个用于Web服务器，一个不那么平凡的Web应用程序）链接更容易给对方。以及管理他们给自己的名字，以一堆相互关联的容器（齿轮，墨盒，kubelets等）的系统。和容器，因为他们本身运行作为一个普通的Linux内核下的应用，甚至可以在Linux已经内运行虚拟机运行。 + +和API使用几个项目，如CoreOS（觉得一个Linux发行意味着运行容器超过应用程序，有一些包括组件来帮助管理/成簇分布的容器），谷歌的Kubernetes（也意味着在集群上运行的容器，相关联的几个人在应该一起运行）组，或图（你也可以定义容器团体和它们之间的关系）。 + +OpenShift已经存在的时候泊坞窗曝光后，我认为这是基于LXC当时的情况。我看到在演示文稿的工作流程是开发商commiting到存储库，并得到发表在一个网站，或者至少让功能都要经过测试/分期/生产阶段的所有协调Openshift。使用泊坞窗优化了很多的工作流程，以及最新的迭代也使用Kubernetes来协调他们。你奉献了一堆机器（如裸机硬件或虚拟机）上运行它，它管理的工作流程，在需要时提供容器。其不是基于多克尔，Dokku，弗林或DEIS唯一的PaaS是他人的几个例子。 + +OpenStack的云的基础设施即服务水平，让你建立的东西了AWS的规模，为您提供一种方式来获得的虚拟机，所以你可以单独运行的虚拟机（运行Linux或其它操作系统），或用自己的网络中部署集群/存储/等。但也有司机部署泊坞窗的容器，而不是完整的虚拟机，以获得更多的服务密度虚拟化/裸机机。 + +这3个可在不同​​的抽象级别，并且可以使用它们本身，但是每一个都可以使用他人得到改善。 \ No newline at end of file diff --git a/apache-mesos-vs-hadoop-lt.md b/apache-mesos-vs-hadoop-lt.md new file mode 100644 index 0000000..8ea72cf --- /dev/null +++ b/apache-mesos-vs-hadoop-lt.md @@ -0,0 +1,504 @@ +#Apache Mesos vs Hadoop YARN #WhiteboardWalkthrough + +Hi, my name is Jim Scott, Director of Enterprise Strategy and Architecture at MapR. + +Today I'd like to talk to you in this white board walkthrough on Mesos vs YARN and why one may or may not be better and global resource management than the other. + +There is a lot of contention in these two camps between the methods and the intentions of how to use these resource managers. + +* Mesos was built to be a global resource manager for your entire data center. +* YARN was created as a necessity to move the Hadoop MapReduce API to the next iteration and life cycle. + +And so it had to remove the resource management out of that embedded framework and into its own container management life cycle model if you well. + +Now the primary difference between Mesos and YARN is going to be it's scheduler + +so in Mesos when a job comes in, a job request comes into the Mesos +master. and what Mesos does is it determines what the resources are +then available. It makes offers back and those offers can be accepted or rejected. This allows the framework to the side what the best fit is for the job that needs to be run. + +Now if it accepts the job for the resources it places the job on slave and all is happy. It has the option to reject the offer in wait for another offer to come in. + +Now one of the nice things about this model is it is very scaleable. This is a model that Google has proven that they have documented white papers are available for this that show the scalability %uh vein on +monolithic scheduling + +33 +00:01:59,002 --> 00:02:03,991 +capacity and so what happens is when you +move over to the yarn side + +34 +00:02:04,189 --> 00:02:07,242 +that a job request comes into the yard +Resource Manager + +35 +00:02:07,719 --> 00:02:11,980 +yarn evaluates all the resources +available it places the job + +36 +00:02:11,098 --> 00:02:14,717 +it's the one making the decision where +job should go + +37 +00:02:15,599 --> 00:02:17,800 +and so thus it is modeled + +38 +00:02:17,008 --> 00:02:20,105 +as a monolithic scheduler so from a +scaling perspective + +39 +00:02:21,077 --> 00:02:25,092 +may sales has better scaling +capabilities now + +40 +00:02:25,092 --> 00:02:28,121 +in addition to this yarn as I mentioned +before + +41 +00:02:29,021 --> 00:02:32,102 +was created as a necessity for the +evolutionary step up the MapReduce + +42 +00:02:33,002 --> 00:02:34,005 +framework + +43 +00:02:34,005 --> 00:02:37,101 +so what this means was that yaron was +created + +44 +00:02:38,001 --> 00:02:41,010 +to be a resource manager for Hadoop jobs + +45 +00:02:41,001 --> 00:02:44,060 +so yarn has tried to grow out of that +and grow + +46 +00:02:44,069 --> 00:02:47,136 +more into the space that may sell us is +occupying so well + +47 +00:02:48,036 --> 00:02:51,055 +so in that model + +48 +00:02:51,055 --> 00:02:54,057 +what we want to consider here is that + +49 +00:02:54,075 --> 00:02:57,158 +we have different scaling capabilities +and that + +50 +00:02:58,058 --> 00:03:02,104 +the implementation between these two is +going to be different and that the + +51 +00:03:03,004 --> 00:03:06,063 +people who put these in place had +different intentions to start + +52 +00:03:06,063 --> 00:03:10,146 +now this may makes an impact in your +decision for which to use + +53 +00:03:11,046 --> 00:03:16,061 +so what we have here is when you want to +evaluate how to manage your datacenter + +54 +00:03:16,061 --> 00:03:16,068 +as a whole + +55 +00:03:17,031 --> 00:03:21,035 +you've got mesas on one side that can +manage every single resource + +56 +00:03:21,035 --> 00:03:24,119 +in your data center and now the other +you have yard which can safely manage + +57 +00:03:25,019 --> 00:03:25,088 +the said you + +58 +00:03:25,088 --> 00:03:29,145 +Hadoop jobs now what that means for you +is that right now + +59 +00:03:30,045 --> 00:03:34,052 +yarn is not capable of managing your +entire data center so + +60 +00:03:35,015 --> 00:03:39,041 +the to have these are competing for the +space and in order for you to move along + +61 +00:03:39,041 --> 00:03:42,118 +if you want to benefit from both this +means you'll need to create + +62 +00:03:43,018 --> 00:03:46,042 +affectively a static the partition which +is + +63 +00:03:46,042 --> 00:03:50,081 +so many resources will be allocated Dr +and so many resources will be allocated + +64 +00:03:50,459 --> 00:03:51,450 +to mess us + +65 +00:03:51,045 --> 00:03:56,051 +so fundamentally this is an issue this +is the entire + +66 +00:03:56,051 --> 00:04:01,066 +I problem that may Sohus was designed to +prevent in the first place + +67 +00:04:01,066 --> 00:04:06,151 +static partitioning so you probably got +a big task ahead of you to figure out + +68 +00:04:07,051 --> 00:04:10,250 +which to use and where to use it and + +69 +00:04:10,709 --> 00:04:14,640 +my hope is that I've given you enough +information with respect to + +70 +00:04:14,064 --> 00:04:17,142 +resource scheduling for you to move +forward + +71 +00:04:18,042 --> 00:04:21,053 +and ask more questions and figure out +where to move + +72 +00:04:21,053 --> 00:04:24,079 +in your global resource management for +your datacenter now + +73 +00:04:24,079 --> 00:04:28,165 +the question as can we make the to this +play together harmoniously + +74 +00:04:29,065 --> 00:04:32,204 +for the sake of the benefit up the +enterprise in the data center + +75 +00:04:32,789 --> 00:04:36,870 +so ultimately we have to ask why can't +we all just get along + +76 +00:04:37,599 --> 00:04:40,696 +so if we put politics aside we can ask + +77 +00:04:41,569 --> 00:04:45,610 +can we make miso sauce and yard work +together in the answer is yes + +78 +00:04:45,979 --> 00:04:49,400 +now map are has worked in unison + +79 +00:04:49,004 --> 00:04:54,453 +with you bay Twitter and Mesa spear to +create a project called Project married + +80 +00:04:54,849 --> 00:04:58,900 +now project marian's goal is to actually +make the to these work together + +81 +00:04:58,009 --> 00:05:02,928 +what that means is may sell us can +manage your entire data center + +82 +00:05:03,819 --> 00:05:07,825 +with this open source software it +enables may source + +83 +00:05:08,419 --> 00:05:11,550 +myriad executors to + +84 +00:05:11,055 --> 00:05:14,078 +launch in manage yarn node managers + +85 +00:05:14,078 --> 00:05:17,083 +what happens is that + +86 +00:05:17,083 --> 00:05:20,922 +when a job comes n 2-yard + +87 +00:05:21,669 --> 00:05:24,743 +it will send the request to Mesa house + +88 +00:05:25,409 --> 00:05:28,840 +mesas in turn will pass it on to with +the Mesa slave + +89 +00:05:28,084 --> 00:05:31,102 +and then there's a myriad executor that +runs + +90 +00:05:32,002 --> 00:05:35,037 +near the yarn owed manager in the Mesa +slave + +91 +00:05:35,037 --> 00:05:38,176 +and what it does is it advertises to + +92 +00:05:38,509 --> 00:05:41,900 +the yarn node manager how many resources +it has available + +93 +00:05:41,009 --> 00:05:45,075 +now the beauty of this approach is this +actually makes yard + +94 +00:05:46,056 --> 00:05:51,056 +more dynamic because it gives the +resources to yarn + +95 +00:05:51,056 --> 00:05:54,080 +that it wants to place where it sees fit + +96 +00:05:54,008 --> 00:05:58,867 +and so from the May so side if you want +to add or remove resources from yard it + +97 +00:05:59,659 --> 00:06:01,757 +becomes very easy to dynamically control +your entire data center + +98 +00:06:02,639 --> 00:06:06,697 +the benefit here is that when you have +your production operations being managed + +99 +00:06:07,219 --> 00:06:11,286 +globally by mass else you can have the +people on the data analytic side + +100 +00:06:11,889 --> 00:06:14,916 +running their jobs in any fashion that +they see fit + +101 +00:06:15,159 --> 00:06:21,860 +via yarn for job placement this means +that dynamically + +102 +00:06:21,086 --> 00:06:24,945 +darn will be limited in a production +environment and + +103 +00:06:25,719 --> 00:06:29,000 +from a global perspective if you need to +take resources away + +104 +00:06:29,000 --> 00:06:32,063 +a douche resiliency with job placement +will allow those jobs to be placed + +105 +00:06:32,063 --> 00:06:32,144 +elsewhere + +106 +00:06:33,044 --> 00:06:37,133 +on the cluster you can kill instances of +yarn + +107 +00:06:37,529 --> 00:06:42,130 +and take back those resources to make +them available two missiles + +108 +00:06:42,013 --> 00:06:45,067 +this really is the best of both worlds +it removes the static partitioning + +109 +00:06:45,067 --> 00:06:47,114 +concept that running the two with these + +110 +00:06:48,014 --> 00:06:52,031 +independently in the and a data center +would create + +111 +00:06:52,031 --> 00:06:57,039 +so the benefit overall is that project +Mary it is going to enable you + +112 +00:06:57,039 --> 00:07:00,055 +to deploy both technologies in your data +center + +113 +00:07:00,055 --> 00:07:03,151 +leverage this for your data center +resource management as a whole + +114 +00:07:04,051 --> 00:07:07,143 +leverage this to manage those Hadoop +jobs where you may need them to just get + +115 +00:07:08,043 --> 00:07:09,049 +deployed faster + +116 +00:07:09,049 --> 00:07:14,065 +where you don't care about the accept +and reject capabilities that may sales + +117 +00:07:14,065 --> 00:07:14,163 +for those jobs + +118 +00:07:15,063 --> 00:07:18,077 +where data locality is your primary +concern + +119 +00:07:18,077 --> 00:07:22,101 +for Hadoop data only this is an enabling +technology + +120 +00:07:23,001 --> 00:07:28,035 +that we hope that you will look into and +evaluate if it's a fit for your company + +121 +00:07:28,035 --> 00:07:32,047 +project Mary it is hosted on github and +is available for download + +122 +00:07:32,047 --> 00:07:35,047 +there's documentation there that +explains how this works you probably + +123 +00:07:35,047 --> 00:07:37,058 +even see diagram similar to this but + +124 +00:07:37,058 --> 00:07:41,063 +while probably little prettier so go out +explore + +125 +00:07:41,063 --> 00:07:44,119 +and give it a try that's all for this +way toward walkthrough + +126 +00:07:45,019 --> 00:07:48,062 +of missiles purses are if you have any +questions + +127 +00:07:48,062 --> 00:07:52,079 +about this topic map are is the open +source leader for May so some yard + +128 +00:07:52,079 --> 00:07:55,708 +please feel free to contact us and asks +any questions on how to implement this + +129 +00:07:56,419 --> 00:07:57,370 +in your business + +130 +00:07:57,037 --> 00:08:02,066 +and remember if you've like this and +you'd like to suggest more topics please + +131 +00:08:02,066 --> 00:08:03,080 +comment below + +132 +00:08:03,008 --> 00:08:06,073 +and don't forget to follow us on Twitter +at map are + +133 +00:08:07,045 --> 00:08:09,106 +hash tag whitewater thank you + + diff --git a/difference-between-docker-and-vgrant-cn.md b/difference-between-docker-and-vgrant-cn.md index 1bb1f6c..1de74e4 100644 --- a/difference-between-docker-and-vgrant-cn.md +++ b/difference-between-docker-and-vgrant-cn.md @@ -10,14 +10,14 @@ Docker的伟大在于；它是轻量级的（因为它依赖于共享内核的Li Docker，并不限制它的灵活性 - “一切都是镜像”，你可以创建变体镜像和全栈镜像，其中每一个添加功能到前一个。管理这些会成为一个挑战。 -Vagrant也有类似的挑战，因为虚拟机可能会成为过时的，有时虚拟机可能很难找到和/或更新。有一些工具比如packer和以前的veewee可以用来帮助你构建所谓的'基础'虚拟机。 +Vagrant也有类似的挑战，因为虚拟机可能会过时，有时虚拟机可能很难找到以及更新。有一些工具比如packer和以前的veewee可以用来帮助你构建所谓的'基础'虚拟机。 -我相信这些工具可以很好地在一起工作，我觉得这样的组合会闪光的在你计划你的筹码的地方，或者在你要测试的更换整个部件甚至是基础操作系统的地方。 +我相信这些工具可以很好地在一起工作，我觉得这样的组合会在你计划的筹码中或者在你要做整个部件更换测试中，甚至是基础操作系统中大放异彩。 假设你有一个基于Centos的应用程序，并且你要切换到Ubuntu或是其他方式。假设你想完全地升级你的操作系统。 -我总是说，在开发或测试与分级，你总是要测试的当前生产环境（包括配置）和任何潜在的替代生产环境中的应用程序。您是否正在计划一个安全更新？你想更新或切换你的Java堆栈？ +我总是说在开发测试与分级中，对于当前生产环境（包括配置）以及在任何潜在的替代生产环境中你必须要测试你的产品。您是否正在计划一个安全更新？你想更新或是切换到Java吗？ -这是流浪和泊坞窗大放异彩。我希望泊坞窗，以帮助您加快对多个操作环境测试。 +这是Vagrant和Docker出彩的地方。我希望Docker帮助您加快对多个操作环境的测试。 -无论泊坞窗是一个有用的工具来部署应用程序投入生产？这是常见的广告使用情况 - 它可能是。然而，在配置文件中基本事实的变化，特别是在这些必须通过网络进行协调，可以更好地用一个工具，知道在网络中的其他组件的完成。 \ No newline at end of file +Docker是否一个部署应用程序到生产生产环境中的有用工具呢？这是它常见的使用情况 - 那么它可能是。然而，配置文件的本质变化，尤其是那些必须通过网络进行协调的地方，可以更好地用一个知道在网络中的其他组件的工具。 \ No newline at end of file diff --git a/docker-machine-compose-swarm-cn.md b/docker-machine-compose-swarm-cn.md new file mode 100644 index 0000000..08aec47 --- /dev/null +++ b/docker-machine-compose-swarm-cn.md @@ -0,0 +1,569 @@ +【编者的话】本文的案例结合了Docker的三大编排工具-Docker Machine、Compose与Swarm， + +自从我上次发表的[有关Docker博文](https://media-glass.es/2014/08/31/docker-fig-reverse-proxy-centos7/)，它发生了很多变化。Docker已经推出了一些新的命令行工具，使其在Docker实例、集群以及容器管理方面更方便地编排。他们是： + +* [Docker Machine](https://docs.docker.com/machine/) - 让你轻松部署Docker实例到很多不同的平台。 +* [Docker Compose](https://docs.docker.com/compose/) - [Fig工具](http://www.fig.sh/)的替代品。 +* [Docker Swarm](https://docs.docker.com/swarm/) - Docker众实例的原生集群。 + +这三种技术中，Swarm目前不适合在生产中使用，因此在这篇文章中我不会讲关于它的太多细节。 + +##Docker Machine + +对于直接下载预编译的二进制文件来说，我决定使用[Homebrew（OS X的管理包工具）](http://brew.sh/)公式： + +{{{ +# Make sure everything is up-to-date +brew update +brew doctor +brew cask update +brew cask doctor +# install docker-machine +brew cask install docker-machine }}} + +这样就安装了`docker-machine`。 + +{{{ +$ docker-machine -v +docker-machine version 0.1.0 +$ docker-machine ls +NAME ACTIVE DRIVER STATE URL SWARM +$ +}}} + +我已经安装了[VirtualBox](https://www.virtualbox.org/)，并且要创建一个叫“testing”的Virtual Machine： + +{{{ +$ docker-machine create --driver virtualbox testing +INFO[0000] Creating SSH key... +INFO[0000] Creating VirtualBox VM... +INFO[0006] Starting VirtualBox VM... +INFO[0006] Waiting for VM to start... +INFO[0038] "testing" has been created and is now the active machine. +INFO[0038] To point your Docker client at it, run this in your shell: $(docker-machine env testing) +}}} + +`docker-machine`使用几个命令来帮助你连接到本地安装的`docker`客户端： + +{{{ +$ docker-machine env testing +export DOCKER_TLS_VERIFY=yes +export DOCKER_CERT_PATH=/Users/russ/.docker/machine/machines/testing +export DOCKER_HOST=tcp://192.168.99.100:2376 +$ docker-machine config testing +--tls --tlscacert=/Users/russ/.docker/machine/machines/testing/ca.pem --tlscert=/Users/russ/.docker/machine/machines/testing/cert.pem --tlskey=/Users/russ/.docker/machine/machines/testing/key.pem -H="tcp://192.168.99.100:2376 +}}} + +就是这样，我现在启用了一个Virtual Machine并且准备使用Docker + +{{{ +$ docker-machine ls +NAME ACTIVE DRIVER STATE URL SWARM +testing * virtualbox Running tcp://192.168.99.100:2376 +``` + +和其他新安装的一样，让我们运行一个“Hello World”： + +{{{ +$ docker $(docker-machine config testing) run busybox echo hello world +Unable to find image 'busybox:latest' locally +511136ea3c5a: Pull complete +df7546f9f060: Pull complete +ea13149945cb: Pull complete +4986bf8c1536: Pull complete +busybox:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security. + +Status: Downloaded newer image for busybox:latest +hello world +}}} + +最后，你可以使用`docker-machie ssh machine-name`命令SSH到Virtual Machine： + +{{{ +$ docker-machine ssh testing +Boot2Docker version 1.5.0, build master : a66bce5 - Tue Feb 10 23:31:27 UTC 2015 +Docker version 1.5.0, build a8a31ef +docker@testing:~$ uname -a +Linux testing 3.18.5-tinycore64 #1 SMP Sun Feb 1 06:02:30 UTC 2015 x86_64 GNU/Linux +docker@testing:~$ cat /etc/*release +NAME=Boot2Docker +VERSION=1.5.0 +ID=boot2docker +ID_LIKE=tcl +VERSION_ID=1.5.0 +PRETTY_NAME="Boot2Docker 1.5.0 (TCL 5.4); master : a66bce5 - Tue Feb 10 23:31:27 UTC 2015" +ANSI_COLOR="1;34" +HOME_URL="http://boot2docker.io" +SUPPORT_URL="https://github.com/boot2docker/boot2docker" +BUG_REPORT_URL="https://github.com/boot2docker/boot2docker/issues" +docker@testing:$ exit +$ +}}} + +太棒了，我现在有一个Virtual Machine运行在我的电脑上，接下来呢？ + +设计`docker-machine`就是和以下公有和私有的云服务提供商（以后会添加更多）一起使用的 + +* Amazon EC2 +* Microsoft Azure +* Digital Ocean +* Google Compute Engine +* Rackspace +* SoftLayer +* OpenStack +* VMWare vCloud Air +* VMWare vSphere + +让我们使用`docker-machine`来启用一个Digital Ocean的实例。你需要生成一个Personal Access Token，你可以按照指南来做。一旦用token启用机子就会像下面所示一样： + +{{{ +$ docker-machine create \ +→ --driver digitalocean \ +→ --digitalocean-access-token cdb81ed0575b5a8d37cea0d06c9690daa074b1276892fc8473bdda97eb7c65ae \ +→ dotesting +INFO[0000] Creating SSH key... +INFO[0000] Creating Digital Ocean droplet... +INFO[0004] Waiting for SSH... +INFO[0071] Configuring Machine... +INFO[0120] "dotesting" has been created and is now the active machine. +INFO[0120] To point your Docker client at it, run this in your shell: $(docker-machine env dotesting) +}}} + +（当然，那个token并不是我的，它只是一串随机数） + +那么发生了什么呢？`docker-machine`访问我的Digital Ocean账户通过API并且启用了以下配置的实例： + +* OS = Ubuntu 14.04 x64 +* RAM = 512MB +* HDD = 20GB SSD +* Region = NYC3 + +这些默认的配置可以通过提供更多的选项被修改，运行`docker-machine create --help`获取帮助查看所有带例子的选项。 + +一旦实例开启，`docker-machine`通过SSH连接到安装、配置以及开启的最新的Docker上。 + +所以，我们现在有两台Machines，一个在本地，一个在Digital Ocean上。 + +{{{ +$ docker-machine ls +NAME ACTIVE DRIVER STATE URL SWARM +dotesting * digitalocean Running tcp://45.55.134.248:2376 +testing virtualbox Running tcp://192.168.99.100:2376 +}}} + +让我们再次运行“Hello World”，但是这次使用刚才启动的那个实例： + +{{{ +$ docker $(docker-machine config dotesting) run busybox echo hello world +Unable to find image 'busybox:latest' locally +511136ea3c5a: Pull complete +df7546f9f060: Pull complete +ea13149945cb: Pull complete +4986bf8c1536: Pull complete +busybox:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security. + +Status: Downloaded newer image for busybox:latest +hello world +}}} + +并且SSH到那个machine中： + +{{{ +$ docker-machine ssh dotesting +Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-43-generic x86_64) + +Documentation: https://help.ubuntu.com/ + + System information as of Sat Mar 21 07:24:02 EDT 2015 + + System load: 0.43 Processes: 72 + Usage of /: 11.4% of 19.56GB Users logged in: 0 + Memory usage: 12% IP address for eth0: 45.55.134.248 + Swap usage: 0% IP address for docker0: 172.17.42.1 + + Graph this data and manage this system at: +https://landscape.canonical.com/ + +root@dotesting:~# docker images +REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE +busybox latest 4986bf8c1536 11 weeks ago 2.433 MB +root@dotesting:~# docker ps -a +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES +b8a83077d858 busybox:latest "echo hello world" 4 minutes ago Exited (0) 4 minutes ago kickass_almeida +root@dotesting:~# exit +logout +$ +}}} + +最终，你可以使用`docker-mashie stop machine-name`和`docker-mashie rm machine-name`来停止和移除machines。请注意当使用`rm`时，是不会提示你是否确定删除。 + +{{{ +$ docker-machine ls +NAME ACTIVE DRIVER STATE URL SWARM +dotesting * digitalocean Running tcp://45.55.134.248:2376 +testing virtualbox Running tcp://192.168.99.100:2376 +$ docker-machine stop dotesting +$ docker-machine ls +NAME ACTIVE DRIVER STATE URL SWARM +dotesting * digitalocean Stopped tcp://45.55.134.248:2376 +testing virtualbox Running tcp://192.168.99.100:2376 +$ docker-machine rm dotesting +$ docker-machine ls +NAME ACTIVE DRIVER STATE URL SWARM +testing virtualbox Running tcp://192.168.99.100:2376 +$ +}}} + +总结，以上就是`docker-machie`的总览。正如你看到的，它确实很方便在很多不同的供应商中来引导Docker服务实例，并且使用一个本地machine命令就可以操控他们。 + +##Docker Compose + +Docker开始充满生机是因为有了Fig，[这是我曾在以前的文章中写到过](https://media-glass.es/2014/08/31/docker-fig-reverse-proxy-centos7/)，当前版本并没有添加太多的新功能，但它开始奠定了与`docker-swarm`工作的基础，单击[这里](https://github.com/docker/compose/releases/tag/1.1.0)查看详细日志。 + +像`docker-machine`一样，我使用Homebrew公式安装`docker-compose` + +{{{ +$ brew install docker-compose +==> Downloading https://homebrew.bintray.com/bottles/fig-1.1.0.yosemite.bottle.1.tar.gz +################################################################## 100.0% +==> Pouring fig-1.1.0.yosemite.bottle.1.tar.gz +==> Caveats +Bash completion has been installed to: + /usr/local/etc/bash_completion.d +==> Summary + /usr/local/Cellar/fig/1.1.0: 186 files, 2.2M +$ +}}} + +然后，使用`docker-machine`让我们创建一个Docker服务实例来使用`docker-compose`： + +{{{ +$ docker-machine create --driver virtualbox compose +INFO[0001] Creating SSH key... +INFO[0001] Creating VirtualBox VM... +INFO[0007] Starting VirtualBox VM... +INFO[0008] Waiting for VM to start... +INFO[0041] "compose" has been created and is now the active machine. +INFO[0041] To point your Docker client at it, run this in your shell: $(docker-machine env compose) +}}} + +因为`docker-compose`不直接与`docker-machine`交互，我们需要告诉`docker`客户端那些刚刚启动的服务器实例的详细信息 + +{{{ +$ $(docker-machine env compose) +}}} + +此命令注入所需Docker客户端的环境变量来连接到服务实例，要看到他们，你只需运行`docker-machine env machine-name` + +{{{ +$ docker-machine env compose +export DOCKER_TLS_VERIFY=yes +export DOCKER_CERT_PATH=/Users/russ/.docker/machine/machines/compose +export DOCKER_HOST=tcp://192.168.99.100:2376 +}}} + +往后它就像Fig一样，除了fig.yml文件现在应该改为`docker-compose.yml`，在我以前的博文里有一个`fig.yml`文件描述： + +{{{ +web: + image: russmckendrick/nginx-php + volumes: + - ./web:/var/www/html/ + ports: + - 80:80 + environment: + PHP_POOL: mywebsite + links: + - db:db +db: + image: russmckendrick/mariadb + ports: + - 3306 + privileged: true + environment: + MYSQL_ROOT_PASSWORD: wibble + MYSQL_DATABASE: wibble + MYSQL_USER: wibble + MYSQL_PASSWORD: wibble +}}} + +它启用两个容器并且把它们连接到一起，还有在NGINX容器内的`/var/www/html`被挂载到host的`./web`文件夹下。我准备运行`docker-compose`命令的文件夹的结构是这样的： + +{{{ +$ tree -a +. +├── \[russ 356] docker-compose.yml +└── \[russ 102] web +└── \[russ 67] index.php + +1 directory, 2 files +}}} + +开始我要拉取需要启用的镜像，你可以忽略此部分。 + +{{{ +$ docker-compose pull +Pulling db (russmckendrick/mariadb:latest)... +Pulling web (russmckendrick/nginx-php:latest)... +}}} + +现在镜像已经被拉取下来，是时候开启容器了： + +{{{ +$ docker-compose up -d +Creating example_db_1... +Creating example_web_1... +}}} + +我们现在有了两个正在运行的容器： + +{{{ +$ docker-compose ps +Name Command State Ports +---------------------------------------------------------------- +example_db_1 /usr/local/bin/run Up 0.0.0.0:49154->3306/tcp +example_web_1 /usr/local/bin/run Up 0.0.0.0:80->80/tcp +}}} + +你也可以打开浏览器： + +{{{ +open http://$(docker-machine ip) +}}} + +在我的例子中我看到`PHPinfo()`页面 + +![](https://media-glass.es/content/images/2015/03/phpinfo.png) + +一旦容器开启，你可以使用`docker exec`来连接到容器内部： + +{{{ +$ docker exec -it example_web_1 bash +[root@997bbe6b5c80 /]# ps aux +USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND +root 1 0.2 1.5 115200 15360 ? Ss 13:59 0:01 /usr/bin/python /usr/bin/supervisord -n +root 16 0.0 3.2 382876 33624 ? S 13:59 0:00 php-fpm: master process (/etc/php-fpm.conf) +root 17 0.0 0.2 110016 2096 ? Ss 13:59 0:00 nginx: master process nginx +nginx 18 0.0 0.5 110472 5568 ? S 13:59 0:00 nginx: worker process +webserv+ 19 0.0 1.5 383132 16284 ? S 13:59 0:00 php-fpm: pool mywebsite +webserv+ 20 0.0 0.8 382876 8848 ? S 13:59 0:00 php-fpm: pool mywebsite +webserv+ 21 0.0 0.8 382876 8848 ? S 13:59 0:00 php-fpm: pool mywebsite +webserv+ 22 0.0 0.8 382876 8848 ? S 13:59 0:00 php-fpm: pool mywebsite +webserv+ 23 0.0 0.8 382876 8852 ? S 13:59 0:00 php-fpm: pool mywebsite +root 95 0.0 0.4 91540 4740 ? Ss 13:59 0:00 /usr/libexec/postfix/master -w +postfix 97 0.0 0.6 91712 6508 ? S 13:59 0:00 qmgr -l -t unix -u +postfix 200 0.0 0.6 91644 6232 ? S 14:05 0:00 pickup -l -t unix -u +root 234 2.3 0.2 11748 2968 ? S 14:07 0:00 bash +root 250 1.0 1.1 110012 11616 ? S 14:07 0:00 nginx +root 251 0.0 0.2 19756 2212 ? R+ 14:07 0:00 ps aux +[root@997bbe6b5c80 /]# exit +exit +$ +}}} + +最后你可以停止以及移除容器，当然还有Docker实例： + +{{{ +$ docker-compose stop && docker-compose rm --force +Stopping example_web_1... +Stopping example_db_1... +Going to remove example_web_1, example_db_1 +Removing example_db_1... +Removing example_web_1... +$ docker-machine rm compose +$ docker-machine ls +NAME ACTIVE DRIVER STATE URL SWARM +$ +}}} + +##Docker Swarm + +在进一步讨论之前，官方文档警告: + +> 警告：Swarm当前是beta版本，因此后期可能会有变化。我们还不推荐在生产环境中使用。 + +现在让我们使用Homebrew来安装`docker-swarm`： + +{{{ +$ brew install docker-swarm +==> Downloading https://homebrew.bintray.com/bottles/docker-swarm-0.1.0.yosemite.bottle.tar.gz +################################################################## 100.0% +==> Pouring docker-swarm-0.1.0.yosemite.bottle.tar.gz + /usr/local/Cellar/docker-swarm/0.1.0: 4 files, 8.7M +}}} + +因为我们已经安装了`docker-machine`，我将要使用它在本地创建一个集群。首先，我们需要启动一个实例并运行swarm容器： + +{{{ +$ docker-machine ls +NAME ACTIVE DRIVER STATE URL SWARM +$ docker-machine create -d virtualbox local +INFO[0001] Creating SSH key... +INFO[0001] Creating VirtualBox VM... +INFO[0006] Starting VirtualBox VM... +INFO[0006] Waiting for VM to start... +INFO[0039] "local" has been created and is now the active machine. +INFO[0039] To point your Docker client at it, run this in your shell: $(docker-machine env local) +$ $(docker-machine env local) +$ docker run swarm create +Unable to find image 'swarm:latest' locally +511136ea3c5a: Pull complete +ae115241d78a: Pull complete +f49087514537: Pull complete +fff73787bd9f: Pull complete +97c8f6e912d7: Pull complete +33f9d1e808cf: Pull complete +62860d7acc87: Pull complete +bf8b6923851d: Pull complete +swarm:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security. + +Status: Downloaded newer image for swarm:latest +63e7a1adb607ce4db056a29b1f5d30cf +$ +}}} + +正如你所见，当容器启动时，我得到了一个token：`63e7a1adb607ce4db056a29b1f5d30cf`，我将要用它来添加更多的节点，但是首先我们需要创建一个Swarm master： + +{{{ +$ docker-machine create \ +→ -d virtualbox \ +→ --swarm \ +→ --swarm-master \ +→ --swarm-discovery token://63e7a1adb607ce4db056a29b1f5d30cf \ +→ swarm-master +INFO[0000] Creating SSH key... +INFO[0000] Creating VirtualBox VM... +INFO[0006] Starting VirtualBox VM... +INFO[0006] Waiting for VM to start... +INFO[0038] Configuring Swarm... +INFO[0043] "swarm-master" has been created and is now the active machine. +INFO[0043] To point your Docker client at it, run this in your shell: $(docker-machine env swarm-master) +}}} + +然后，我们需要连接Docker客户端到Swarm上，这就需要将`--swarm`添加到` $(docker-machine env machine-name)`命令上： + +{{{ +$ $(docker-machine env --swarm swarm-master) +}}} + +现在让我们添加另一个节点： + +{{{ +$ docker-machine create \ +→ -d virtualbox \ +→ --swarm \ +→ --swarm-discovery token://63e7a1adb607ce4db056a29b1f5d30cf \ +→ swarm-node-00 +INFO[0000] Creating SSH key... +INFO[0000] Creating VirtualBox VM... +INFO[0006] Starting VirtualBox VM... +INFO[0006] Waiting for VM to start... +INFO[0039] Configuring Swarm... +INFO[0048] "swarm-node-00" has been created and is now the active machine. +}}} + +我们现在有了2个节点的集群 - “swarm-master”： + +{{{ +$ docker-machine ls +NAME ACTIVE DRIVER STATE URL SWARM +local virtualbox Running tcp://192.168.99.100:2376 +swarm-master virtualbox Running tcp://192.168.99.101:2376 swarm-master (master) +swarm-node-00 * virtualbox Running tcp://192.168.99.102:2376 swarm-master +}}} + +使用`docker info`来获取更多有关集群的信息： + +{{{ +$ docker info +Containers: 3 +Nodes: 2 + swarm-master: 192.168.99.101:2376 + └ Containers: 2 + └ Reserved CPUs: 0 / 4 + └ Reserved Memory: 0 B / 999.9 MiB + swarm-node-00: 192.168.99.102:2376 + └ Containers: 1 + └ Reserved CPUs: 0 / 4 + └ Reserved Memory: 0 B / 999.9 MiB +}}} + +太棒了，但这意味着什么？ + +让我们拉取一些镜像： + +{{{ +$ docker -H 192.168.99.101:2376 pull redis +$ docker -H 192.168.99.102:2376 pull mysql +}}} + +注意到我是如何在“swarm-master”上拉取`redis`镜像以及在`swarm-node-00`上拉取`mysql`的，现在我可以保证容器只在有镜像的那个节点上启用： + +{{{ +$ docker run -d --name redis1 -e affinity:image==redis redis +af66148bbbc8dcd799d82448dfd133b968d34eb7066a353108bf909ea3324a58 +$ docker run -d --name mysql -e affinity:image==mysql -e MYSQL_ROOT_PASSWORD=mysecretpassword -d mysql +70b2d93d6f83aa99f5ad4ebe5037e228a491a4b570609840f3f4be9780c33587 +$ docker ps +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES +70b2d93d6f83 mysql:latest "/entrypoint.sh mysq 3 seconds ago Up Less than a second 3306/tcp swarm-node-00/mysql +af66148bbbc8 redis:latest "/entrypoint.sh redi 2 minutes ago Up 2 minutes 6379/tcp swarm-master/redis1 +}}} + +另一个例子是使用节点的端口，让我们在两个节点上都拉取我的NGINX-PHP镜像： + +{{{ +$ docker -H 192.168.99.101:2376 pull russmckendrick/nginx-php +$ docker -H 192.168.99.102:2376 pull russmckendrick/nginx-php +}}} + +现在，让我们启用一个容器并绑定到80端口 + +{{{ +$ docker run -d -p 80:80 russmckendrick/nginx-php +2d066b2ccf28d2a1fa9edad8ac7b065266f29ecb49a8753b972780051ff83587 +}}} + +再有： + +{{{ +$ docker run -d -p 80:80 russmckendrick/nginx-php +40f5fee257bb2546a639a5dc5c2d30f8fa0ac169145e431c534f85d8db51357f +}}} + +你会说这没什么特别的啊？正常来说，当试图启动第二个容器时，你会得到如下信息因为你不用将同一个端口绑定到两个容器上： + +{{{ +$ docker run -d -p 80:80 russmckendrick/nginx-php +FATA[0000] Error response from daemon: unable to find a node with port 80 available +}}} + +然而，在集群的情况下，因为Docker知道集群节点运行的是什么以及哪些端口是在使用的。Docker可以简单地通过Swarm在“swarm-node-00”上启动容器并且它知道“swarm-master”已经使用了80端口： + +{{{ +$ docker ps +CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES +40f5fee257bb russmckendrick/nginx-php:latest "/usr/local/bin/run" 4 seconds ago Up Less than a second 192.168.99.101:80->80/tcp swarm-master/elated_einstein +2d066b2ccf28 russmckendrick/nginx-php:latest "/usr/local/bin/run" 8 seconds ago Up Less than a second 192.168.99.102:80->80/tcp swarm-node-00/drunk_mestorf +70b2d93d6f83 mysql:latest "/entrypoint.sh mysq 26 minutes ago Up 26 minutes 3306/tcp swarm-node-00/mysql +af66148bbbc8 redis:latest "/entrypoint.sh redi 29 minutes ago Up 29 minutes 6379/tcp swarm-master/redis1 +}}} + +所有这一切都没有提示或特殊的命令行，它的帮助仅仅是用它来做到这些。 + +正如你所看到的，`docker-swarm`仍然非常大的发展潜力，也有一些不如意的地方，如容器不能够跨节点互相通讯。然而，伴随着[socketplane.io](http://socketplane.io/)（他们使用Open vSwitch开发了一个基于软件定义网络解决方案的容器）要加入Docker的消息，我认为用不了多长时间这个问题就能得到解决。 + +最后，让我们删除在运行的实例： + +{{{ +$ docker-machine rm local swarm-master swarm-node-00 +}}} + +就这样吧，期待在未来的几个月这些工具的更新，我也会进一步跟进。 + + +**原文：[Docker Machine, Compose & Swarm](https://media-glass.es/2015/03/21/docker-machine-compose-swarm/) （翻译：[田浩浩](https://github.com/llitfkitfk)）** + +＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ +**译者介绍** +田浩浩，[USYD](http://sydney.edu.au/engineering/it/)硕士研究生，目前在珠海从事Android应用开发工作。业余时间专注Docker的学习与研究，希望通过[DockerOne](http://dockerone.com/)把最新最优秀的译文贡献给大家，与读者一起畅游Docker的海洋。 \ No newline at end of file diff --git a/docker-security-tuning-cn.md b/docker-security-tuning-cn.md new file mode 100644 index 0000000..cd0337f --- /dev/null +++ b/docker-security-tuning-cn.md @@ -0,0 +1,159 @@ +#Docker安全调整 + +【编者的话】 + +从发表这个有关Docker安全系列的前两篇文章以来已经有一段时间没更新了。这边文章会更新有关Docker的最新添加的信息并且涵盖了那些正准备合并到上游Docker的新的功能。 + +##调整能力 + +在前面的文章中，我讲述了基于Linux的功能的容器分离。 + +Linux的功能允许你分离根用户权力到一些更小的特权群。目前，默认情况下Docker容器只有以下功能。 + +``` +CHOWN, DAC_OVERRIDE, FSETID, FOWNER, MKNOD, NET_RAW, +SETGID, SETUID, SETFCAP, SETPCAP, NET_BIND_SERVICE, +SYS_CHROOT, KILL, AUDIT_WRITE +``` + +在某些情况下，你可能要调整此列表，例如，如果你构建一个运行`ntpd`或`crony`的容器，就需要能够修改主机的系统时间。该容器将无法运行，因为它需要`CAP_SYS_TIME`。在旧版本的Docker中容器必须在`--privileged`模式 - 关闭所有的安全策略下运行。 + +在Docker1.3版本中添加了`--cap-add`和`--cap-drop`。现在为了运行`ntpd`容器，你可以只需运行： +``` +docker run -d --cap-add SYS_TIME ntpd +``` + +其中只添加了`SYS_TIME`功能到您的容器。 + +另一个例子是，如果你的容器没有改变任何进程的`UID/GID`，你可以从你的容器中删除这些功能，使其更加安全。 + +``` +docker run --cap-drop SETUID --cap-drop SETGID --cap-drop FOWNER fedora /bin/sh + +# pscap | grep 2912 +5417 2912 root sh chown, dac_override, fsetid, kill, setpcap, net_bind_service, net_raw, sys_chroot, mknod, audit_write, setfcap +``` + +或者你可以放弃所有功能并一一添加。 + +``` +docker run --cap-drop ALL --cap-add SYS_TIME ntpd /bin/sh + +# pscap | grep 2382 +5417 2382 root sh sys_time +``` + +##调整SELinux的标签 + +类似于调整功能，我们已经加入了调整SELinux的标签的能力。 + +如果你已经看了[SELinux coloring book](http://opensource.com/business/13/11/selinux-policy-guide)（译注：有关强制执行SELinux政策的文章，此文图文并茂、易于理解），你知道，我们可以通过类型和`MCS/MLS`级别来分离进程。我们使用类型用以保护主机来自容器的干扰。但是，我们也可以调节类型来控制允许进入和离开容器的网络端口。目前，我们都是以`svirt_net_lxc_t`运行所有容器。这种类型允许监听并连接所有的网络端口。我们可以通过调整SELinux的类型标签很好地设定容器的安全性。 + +与常规的SELinux和Apache httpd，在默认情况下我们只允许Apache进程来监听Apache的端口（http_port_t）。 + +``` +# sudo sepolicy network -t http_port_t + +http_port_t: tcp: 80,81,443,488,8008,8009,8443,9000 + +``` + +我们也阻止所有传出端口的连接。这可以帮助我们锁定了Apache进程，即便黑客像ShellShock一样通过安全漏洞破坏了应用程序，我们可以停止即将成为一个垃圾邮件僵尸的应用程序或者允许进程攻击其它系统。就像加州旅馆，“你可以随时进来，但你永远无法离开。” + +随着容器，可是如果你运行一个Apache服务器应用程序的容器，该应用程序被攻击，Apache进程能够通过网络连接到任何网络端口、成为垃圾邮件僵尸或者攻击其他主机/容器。 + +使用SELinux创建一个新的策略类型来运行你的容器相当的简单。首先，你可以创建一个SELinux TE（类型强制执行）文件。 + +``` +# cat > docker_apache.te << _EOF + +policy_module(docker_apache,1.0) + +# This template interface creates the docker_apache_t type as a +# type which can be run as a docker container. The template +# gives the domain the least privileges required to run. +virt_sandbox_domain_template(docker_apache) + +# I know that the apache daemon within the container will require +# some capabilities to run. Luckily I already have policy for +# Apache and I can query SELinux for the capabilities. +# sesearch -AC -s httpd_t -c capability +allow docker_apache_t self: capability { chown dac_override kill setgid setuid net_bind_service sys_chroot sys_nice sys_tty_config } ; + +# These are the rules required to allow the container to listen +# to Apache ports on the network. + +allow docker_apache_t self:tcp_socket create_stream_socket_perms; +allow docker_apache_t self:udp_socket create_socket_perms; +corenet_tcp_bind_all_nodes(docker_apache_t) +corenet_tcp_bind_http_port(docker_apache_t) +corenet_udp_bind_all_nodes(docker_apache_t) +corenet_udp_bind_http_port(docker_apache_t) + +# Apache needs to resolve names against a DNS server +sysnet_dns_name_resolve(docker_apache_t) + +# Permissive domains allow processes to not be blocked by SELinux +# While developing and testing your policy you probably want to +# run the container in permissive mode. +# You want to remove this rule, when you are confident in the +# policy. +permissive docker_apache_t; +_EOF + +# make -f /usr/share/selinux/devel/Makefile docker_apache.pp +# semodule -i docker_apache.pp +``` + +现在使用新类型运行容器： + +``` +# docker run -d --security-opt type:docker_apache_t httpd + +``` + +现在，对比正常的容器，这个容器有更为严格的SELinux安全性。注意，你可能会需要查看审计日志来看看你的应用程序是否需要额外的SELinux准许规则。 + +你可以通过使用`audit2allow`命令来添加规则到现有`.te`文件，重新编译并安装如下规则。 + +``` +# grep docker_apache_t /var/log/audit/audit.log | audit2allow >> docker_apache.te +# make -f /usr/share/selinux/devel/Makefile docker_apache.pp +# semodule -i docker_apache.pp + +``` + +##多极次安全模式 + +目前，我们使用`MCS`分离来确保容器不被其它容器干扰或交互，除非它是通过网络连接。某些政府系统需要不同类型的MLS（多极安全）政策。具有MLS时，你可以基于看到的数据级别来标记进程。 MLS说如果你的容器要处理绝密数据，那么它应该在绝密的地方运行。我们已经添加允许管理员设置容器在特定级别运行的Docker选项，这些应该满足MLS系统的需求。 + +``` +docker run -d --security-opt label:level:TopSecret --security-opt label:type:docker_apache_t httpd +``` + +这个命令将开启Docker容器的两个交替类型与级别，并且可以阻止容器使用不是相同标签的数据。不过在这一点上还没有通过认证，但我们愿意帮助第三方为MLS用户构建解决方案。 + +##调整命名空间 + +在其他有关安全的对话中，我已经讨论了命名空间可以被认为是一种安全机制，因为其排除了一个进程无法看到系统（PID命名空间）上的其他进程的能力。网络命名空间可以排除从命名空间中能看的到其他网络的能力。 IPC（内部进程间通信）命名空间具有阻断容器使用其它容器的IPC的能力。 + +Docker现在已经放宽这些限制。您可以用容器来共享主机的命名空间： + +--pid=主机让容器共享主机的PID命名空间 +--net=主机让容器共享主机的主机空间 +--ipc=主机让容器共享主机的IPC空间 + +需要注意的是，既然与主机共享了PID或IPC的命名空间，需要我们禁用SELinux分离以便让他们的工作。 + +``` +docker run -ti --pid=host --net=host --ipc=host rhel7 /bin/sh + +``` + +你很可能会阅读这篇有关这些的额外信息的文章-[Super Privileged Containers](http://developerblog.redhat.com/2014/11/06/introducing-a-super-privileged-container-concept/)。 + +**原文链接：[Tuning Docker with the newest security enhancements](https://opensource.com/business/15/3/docker-security-tuning) （翻译：[田浩浩](https://github.com/llitfkitfk)）** + +＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝ +**译者介绍** +田浩浩，[USYD](http://sydney.edu.au/engineering/it/)硕士研究生，目前在珠海从事Android应用开发工作。业余时间专注Docker的学习与研究，希望通过[DockerOne](http://dockerone.com/)把最新最优秀的译文贡献给大家，与读者一起畅游Docker的海洋。 \ No newline at end of file diff --git a/friends-cn.md b/friends-cn.md new file mode 100644 index 0000000..f68483d --- /dev/null +++ b/friends-cn.md @@ -0,0 +1 @@ +[田浩浩](http://dockerone.com/people/llitfkitfk)、[陈杰](http://dockerone.com/people/Sonyfe25cp)、[肖劲](http://dockerone.com/people/amwtke)、[左伟](http://dockerone.com/people/%E5%B7%A6%E4%BC%9F)、[叶可强](http://dockerone.com/people/%E5%8F%B6%E5%8F%AF%E5%BC%BA)、[梁晓勇](http://dockerone.com/people/sean)、[王哲](http://dockerone.com/people/hessen)、[郭蕾](http://dockerone.com/people/%E9%83%AD%E8%95%BE)、[崔婧雯](http://dockerone.com/people/%E5%B4%94%E5%A9%A7%E9%9B%AF)、[吴佳兴](http://dockerone.com/people/colstuwjx)、[隋鑫](http://dockerone.com/people/jeffsui)、[吴锦晟](http://dockerone.com/people/%E5%90%B4%E9%94%A6%E6%99%9F) 、[钟最龙](http://dockerone.com/people/kurtzhong)、[孙科](http://dockerone.com/people/codesun)、[路兴强](http://dockerone.com/people/deerlux)、[刘凯宁](http://dockerone.com/people/%E5%88%98%E5%87%AF%E5%AE%81)、[张逸仙](http://dockerone.com/people/zyx_today) \ No newline at end of file diff --git a/question-cn.md b/question-cn.md new file mode 100644 index 0000000..5dd2225 --- /dev/null +++ b/question-cn.md @@ -0,0 +1,27 @@ + + + +大的问题 - 很难跟上所有这方面的发展，因为这一切都如此快速变化。我会尽力给你我的观点作为一名工程师，在中间层。我要限制我的答案中间层技术，它的工作原理与其他工具，因为这是我所知道的最好的。 + +首先简要介绍Mesos，而我们的“栈”的基础上的。 Mesos是群集资源管理器。配置来反对运行，对节点数据中心（或云）运行在主机或从配置应用程序，它计算出在哪里运行中的各种约束集的应用实例。举例来说，如果一个正在运行的任务终止，失败或丢失 - 它通过一个API，它需要在应用某些事件来实现的回调提供了此功能。 + +这再次运行Mesos的API的应用程序称为框架。例如，有一个它运行火花一个Mesos群集上火花框架（火花实际上一开始只是一个例子Mesos应用程序，因此该框架的实现是特别好）。这是许多其他框架流行的分布式系统（如Hadoop的，卡桑德拉等），使他们能够使用Mesos的调度能力，以自己的最佳优势。 + + 但是，如果你的终端应用包括长时间运行的服务，有没有必要从头开始实现了一个框架。有中存在主要是为了协调部署和服务的运行与Mesos几个框架。一个例子，这是我们积极开发和支持，是马拉松（中间层/马拉松）。其他流行的框架包括Apache的奥罗拉（Apache的极光），HubSpot的奇异（HubSpot /奇点）。这三种方法都相当强劲 - 在不同的公司正在使用的生产。 + +同样，如果你正在寻找一个批处理应用程序迁移到同一组的计算资源，在Chronos的框架（mesos /克罗诺斯）允许你这样做。 + +我们相信，所有的应用程序移动到同一套物理资源，并使用像Mesos资源管理器是使用计算能力的最有效方式。所述Mesos纸本身（页上mit.edu）暗示的增加利用率。这是一个巨大的胜利为我们所有的客户。 + +微博已经被使用Mesos在生产了数年，现在来运行他们的基础设施，良好的比例，所以你会发现它是一个最成熟的出来你列出的项目。 （其他著名的用户包括易趣，Hubspot和Airbnb住宿。） + +关于你提到的其他技术，你会发现，几乎所有的人都用中间层的软件，很好地发挥。泊坞窗已支持原生的近6个月了（并已在某些能力较去年被支持）。您可以轻松地部署和启动Dockerized应用Mesos，马拉松和Chronos的。 + +中间层不会取代CoreOS。通常情况下，你仍然安装在底层主机操作系统的中间层软件，因此把它作为你的主机操作系统和您的顶级应用程序之间的抽象层。我们支持通常的流行 + “胖”的Linux发行版如Debian / Ubuntu的/ CentOS的/ RedHat和开始记录我们的CoreOS支持（中间层的单CoreOS实例）。 + +Kubernetes提供了类似的功能，以马拉松和我前面描述的其他服务框架。我们实际上是在与谷歌合作，提供Kubernetes强大的支持上Mesos（中间层/ kubernetes-mesos） - 它可以运行现在。这使您可以得到有Mesos处理在何处以及如何运行你的应用程序，并仍用好的抽象Kubernetes提供的效率优势。发展对Kubernetes速度快，所以这是非常令人兴奋的看到这个项目是怎么回事。 + +HAProxy的实际上是规范的方式为用户进行的马拉松（服务发现与中层）中运行的服务的服务发现和我们最近发布了Mesos-DNS（中间层/ mesos-DNS），一个简单的方法来执行应用程序运行的基于DNS服务发现在Mesos。 + +我希望这个信息可以帮助阐明你的追求:)。这听起来像你的架构将很好地映射到中间层的生态系统。如果您想了解更多信息，请联系我们（联系中层中层·），或找到我们在Freenode的#mesos！ \ No newline at end of file diff --git a/the-docker-ecosystem-service-discovery-and-distributed-configuration-stores-cn-review.md b/the-docker-ecosystem-service-discovery-and-distributed-configuration-stores-cn-review.md new file mode 100644 index 0000000..f986f47 --- /dev/null +++ b/the-docker-ecosystem-service-discovery-and-distributed-configuration-stores-cn-review.md @@ -0,0 +1,119 @@ +【编者的话】 +本文介绍了服务发现与全局可读配置存储两部分内容，不仅介绍了工作原理和工作方式，也介绍了与之相关的故障检测、重配置和安全问题，最后还介绍了常用的服务发现项目。整篇文章将这个知识点介绍的很全面细致，让读者能够对服务发现和全局可读配置存储有一个全面的认识，值得学习。 + + +###介绍 +容器给寻找大规模设计与部署应用的需求提供了一个优雅的解决方案。在Docker提供实际的容器技术的同时，许多其他的项目也在协助开发在部署环境中所需要的引导和沟通的工具。 + +多种Docker环境依赖的核心技术之一是服务发现。服务发现可以让一个应用或者组件发现其运行环境以及其它应用或组件的信息。它通常是采用的是分布式key-value的存储方式，而且它还用来作为一般查询配置细节信息的地方。用户配置一个服务发现工具就可以将实际容器跟运行配置分离开，这样用户就可以在多个环境中复用同一个镜像。 + +在这篇向导中，我们将讨论在一个Docker集群环境中服务发现工具带来的好处。主要关注在常规概念，在需要的地方会用详细的例子来描述。 + +###服务发现与全局可读配置存储 + +服务发现的基本思想是任何一个应用的实例能够以编程的方式获取当前环境的细节。这是为了让新的实例可以嵌入到现有的应用环境而不需要人工干预。服务发现工具通常是用全局可访问的存储信息注册表来实现，它存储了当前正在运行的实例或者服务的信息。大多数情况下，为了使这个配置具有容错与扩展能力，这个工具分布式地存储在基础设施中的多个宿主机上。 + +虽然服务发现平台的初衷是提供连接信息来连接不同组件的，但是它们更普遍地是用来存储任何类型的配置信息。许多部署工具通过写入它们的配置信息给发现工具来实现这个特性。如果容器配置了这些，它们就可以去查询这些预配置信息，并根据这些信息来调整自身行为。 + +###服务发现是怎么工作呢？ + +每一个服务发现工具都会提供一套API，使得组件可以用其来设置或搜索数据。正是如此，对于每一个组件，服务发现的地址要么硬编码到程序或容器内部，要么在运行时以参数形式提供。通常来说，发现服务用键值对形式实现，采用标准http协议交互。 + +服务发现门户的工作方式是：当每一个服务启动上线之后，他们通过发现工具来注册自身信息。它记录了一个相关组件若想使用某服务时的全部必要信息。例如，一个MySQL数据库服务会在这注册它运行的ip和端口，如有必要，登录时的用户名和密码也会留下。 + +当一个服务的消费者上线时，它能够在预设的终端查询该服务的相关信息。然后它就可以基于查到的信息与其需要的组件进行交互。负载均衡就是一个很好的例子，它可以通过查询服务发现门户得到各个后端节点承受的流量数，然后根据这个信息来调整配置。 + +这可将配置信息从容器内拿出。一个好处是可以让组件容器更加灵活，并不受限于特定的配置信息。另一个好处是使得组件与一个新的相关服务实例交互时变得简单，可以动态进行调整配置。 + +###配置存储是如何关联起来的？ + +全局分布式服务发现系统的一个主要优势是它可以存储任何类型的组件运行时所需的配置信息。这就意味着可以从容器内将更多的配置信息抽取出去，并放入更大的运行环境。 + +通常来说，为了让这个过程更有效率，应用在设计时应该赋上合理的默认值，并且在运行时可以通过查询配置存储来覆盖这些值。这使得运用配置存储跟在执行命令行标记时的工作方式类似。区别在于，通过一个全局配置存储，可以不做额外工作就能够对所有组件的实例进行同样的配置操作。 + +###配置存储如何帮助集群的管理？ + +在Docker部署中，分布式键值对存储其中最初可能不太明显的一个功能是对集群成员的存储和管理。配置存储是为了追踪宿主机成员变更和管理工具的最好环境。 + +一些可能会存在分布式键值对存储中的个人宿主机信息是： + +* 宿主机IP +* 宿主机自身的链接信息 +* 跟调度信息有关的标签或元数据信息 +* 集群中的角色（如果是采用了主从模式的集群） + +在正常情况下，使用一个服务发现平台时，这些细节可能不是你需要考虑的。但是他们为管理工具提供了一个可以查询或修改集群自身信息的地方。 + +###故障检测怎么实现？ + +故障检测的实现方式也有很多种。需要考虑的是如果一个组件出现故障，服务发现能否更新状态指出该组件不再提供服务。这种信息是至关重要的，关系到将应用或服务故障可能性降到最低。 + +许多服务发现平台允许赋值时带一个可配置的超时时间。组件可以设置一个超时时间，并能定期去请求服务发现来重置超时时间。如果该组件出现故障，超时时间达到设定值，那么这个组件的连接信息就会从服务发现的存储中被去掉。超时时间长度在很大程度上是它与应用需要多快去应对一个组件的故障的函数。 + +这也可以通过将一个基本的“助手”容器与每一个组件相连来实现,而它们唯一的责任是定期的健康检查组件以及更新注册表如果组件关闭。这种类型的架构值得担忧是,如果辅助容器出现故障,将导致不正确的信息在存储中。一些系统解决这个问题的方法是在服务发现的工具中定义健康检查。这样,发现平台本身可以定期检查已注册组件是否仍然可用。 + +###当细节变化时，配置服务会如何？ + +对于基本的服务发现模型来说，一个关键的改进就是动态重新配置。普通服务发现工具允许用户通过检查在启动时的信息来影响组件的初始配置，而动态重新配置涉及配置组件来反映配置存储中的新信息。例如，当你在运行一个负载均衡，后端服务器上的健康检查可能会提示集群中的某一个成员出现故障了。运行中的成员机器需要知道这个信息，并调整配置信息和重新加载它的负载。 + +这个有多种方式实现。由于负载均衡的例子是这个功能的主要应用场景之一，许多现有的项目专注在当配置变动时重新配置负载均衡。常见的是HAProxy配置调整，这要归结于在负载均衡领域内它的普遍性。 + +某些项目更加灵活，它们可在任何类型的软件中被用来触发变更。这些工具周期性的去请求服务发现工具，并且当变更被发现，利用模板系统和服务发现工具中的值来生成新配置文件。当配置文件生成结束，相应的服务将被重新加载。 + +这种类型的动态配置在构建过程中需要更多的规划和配置，因为这些所有的策略都需要存在于组件容器之中。这使得组件容器负责调整自身的配置。找出需要存在服务发现工具中的必要参数值并设计一个适当的数据结构以便使用，这是该系统的另一个技术挑战，但是它可以带来可观的效益和灵活性。 + +###安全方面如何？ + +许多人初次接触全局配置存储时担心的一个问题是访问的安全性。将连接信息存储在全局可访问的存储中真的合适么？ + +这个问题的答案很大程度上依赖于你准备在存储中存放的内容以及保护你的数据需要多少层的安全等级。几乎所有的服务发现工具可以采用SSL/TLS加密链接。对于一些服务，隐私性可能不是最重要的，而且发现服务放在内网中也可能让人满意。但是，大多数的应用会从它额外的安全性上获益。 + +有许多不同的方法来解决这个问题，同时各种项目也都提供他们自己的解决方案。一个项目的解决方案是继续允许开放发现服务平台本身，但是对于写入数据进行加密，使用者必须用相应的密钥来解码从服务发现中获取的信息才能使用。其他组件不可以获取到未加密的数据。 + +还有不同的方法，一些服务发现工具实现了访问控制列表，将不同的键值切分到不同的分组中。他们可以根据访问需要来制定不同的秘钥来访问相应的分组。这种简单的方式既保证了能够给特定组件提供信息又保证了对其他组件的不可访问性。每个组件都可以被配置为只允许访问它所需要的连接信息。 + +###有哪些常见的服务发现工具？ + +既然我们已经讨论了一些服务发现工具和全局分布式键值存储的一般特点和功能，下面我们来介绍几个与这些概念有关的项目。 + +一些常见的服务发现工具： + +* **etcd**：这是CoreOS的创建者提供的工具，面向容器和宿主机提供服务发现和全局配置存储功能。它在每个宿主机上有基于http协议的API和命令行的客户端。 +* **consul**：这个服务发现平台有很多高级的特性，使得它脱颖而出，例如：配置健康检查、ACL功能、HAProxy配置等等。 +* **zookeeper**：这个工具较上面两个都比较老，提供一个更加成熟的平台和一些新特性。 + +一些基本服务发现工具的扩展项目： + +* **crypt**：Crypt允许组件通过采用公钥加密的方式来保护它们的信息。需要读取数据的组件会被分配密钥，而其他组件则不能读取数据。 +* **confd**：Confd项目旨在基于服务发现的变化，而动态重新配置任意应用程序。该系统包含了一个工具来监测节点中的变化、一个模板系统来根据获取到的值来生成配置文件，并能够重新加载受影响的应用。 +* **vulcand**：Vulcand为成组的组件作为负载均衡使用。它使用etcd作为后端，并基于监测变更来调整它的配置。 +* **marathon**：虽然marathon主要是调度器（后续介绍），它也实现了一个基本的重加载HAProxy的功能，当发现变更时它来协调可用的服务。 +* **frontrunner**：这个项目嵌入在marathon中对HAProxy的更新提供一个更稳定的解决方案。 +* **synapse**：这个项目引入了嵌入式的HAProxy组件，它能够路由流量给各个组件。 +* **nerve**：它被用来与synapse结合一起来为各个组件提供健康检查，如果组件不可用，nerve将更新synapse将该组件移除出去。 + +###总结 + +服务发现工具和全局配置存储使得Docker容器可以适应它们当前所处环境并嵌入现有的组件。这是一个重要的先决条件为的是提供方便、容易扩展和部署的功能，通过允许组件跟踪和应对他们所在环境变化。 + +在下一个指南中，我们将探讨Docker容器和宿主机之间用自定义的网络配置进行通信。 + +###本系列的其他文章 + +Docker已经为开发者和管理员提供一个简单的平台来创建和部署可扩展的应用。在这个系列中，我们将探索Docker如何与其他组件整合在一起，并用它们提供的工具集来便捷地提供高可用性的分布式系统。 + +1. [常用组件介绍](http://dockerone.com/article/205)（已翻译） +2. [容器化的综述](http://dockerone.com/article/208)（已翻译） +3. 服务发现和分布式配置存储（本文） +4. 网络与通信（翻译中） +5. 调度与编制（翻译中） + + + + + +**原文：[The Docker Ecosystem: Service Discovery and Distributed Configuration Stores](https://www.digitalocean.com/community/tutorials/the-docker-ecosystem-service-discovery-and-distributed-configuration-stores) （译者：陈杰）** + +=============================================== +**译者介绍** +**陈杰**，北京理工大学计算机学院在读博士，研究方向是自然语言处理在企业网络信誉评价方面的应用，平时也乐于去实现一些突发的想法。在疲于配置系统环境时发现了Docker，跟大家一起学习、使用和研究Docker。 \ No newline at end of file