Merge pull request #4505 from jiajia9linuxer/master

[jiajia9linuxer] finish 2 blogs 我替你移动吧。。。

sources/tech/20160913 The Five Principles of Monitoring Microservices.md

@@ -1,93 +1,93 @@
-jiajia9linuxer
-The Five Principles of Monitoring Microservices
+监控微服务的5条原则
 ====
 
 ![](http://thenewstack.io/wp-content/uploads/2016/09/toppicsysdig.jpg)
 
-The need for microservices can be summed up in just one word: speed. The need to deliver more functionality and reliability faster has revolutionized the way developers create software. Not surprisingly, this change has caused ripple effects within software management, including monitoring systems. In this post, we’ll focus on the radical changes required to monitor your microservices in production efficiently. We’ll lay out five guiding principles for adapting your monitoring approach for this new software architecture.
+我们对微服务的需求可以归纳为一个词：速度，提供更多更可靠更快捷的功能的需求，彻底改变了软件开发模式，毫无疑问，这同样改变了软件管理和系统监控的方式。这里，我们着重于有效的监控生产过程中的微服务，我们将为这一新的软件开发模式制定5条原则来调整你的监控方法。
 
-Monitoring is a critical piece of the control systems of microservices, as the more complex your software gets, the harder it is to understand its performance and troubleshoot problems. Given the dramatic changes to software delivery, however, monitoring needs an overhaul to perform well in a microservice environment. The rest of this article presents the five principles of monitoring microservices, as follows:
+监控是微服务控制系统的关键部分，你的软件越复杂，那么你就越难了解其性能并解决问题。鉴于微服务给软件部署带来的巨大改变，监控系统同样需要进行彻底的改造。文章接下来介绍监控微服务的5条原则，如下：
 
-1. Monitor containers and what’s inside them.
-2. Alert on service performance, not container performance.
-3. Monitor services that are elastic and multi-location.
-4. Monitor APIs.
-5. Map your monitoring to your organizational structure.
+1. 监控容器和里面的东西
+2. 在服务性能上做监控，而不是容器
+3. 监控弹性和多变的服务
+4. 监控开发接口
+5. 将您的监控映射到您的组织结构
 
-Leveraging these five principles will allow you to establish more effective monitoring as you make your way towards microservices. These principles will allow you to address both the technological changes associated with microservices, in addition to the organizational changes related to them.
+利用这5条原则，你可以建立更有效的对微服务的监控。这些原则，可以让你定位微服务的技术变化和组织变化。
 
-### The Principles of Microservice Monitoring
+### 微服务监控的原则
 
-#### 1. Monitor Containers and What’s Running Inside Them
+#### 1.监控容器和里面的东西
 
-Containers gained prominence as the building blocks of microservices. The speed, portability, and isolation of containers made it easy for developers to embrace a microservice model. There’s been a lot written on the benefits of containers so we won’t recount it all here.
+容器是微服务重要的积木，容器的速度、可移植性和隔离特性让开发者很方便的建立微服务的模型。容器的好处已经写的够多了，在这里我们不再重复。
 
-Containers are black boxes to most systems that live around them. That’s incredibly useful for development, enabling a high level of portability from development through production, from developer laptop to cloud. But when it comes to operating, monitoring and troubleshooting a service, black boxes make common activities harder, leading us to wonder: what’s running in the container? How is the application/code performing? Is it spitting out important custom metrics? From the DevOps perspective, you need deep visibility inside containers rather than just knowing that some containers exist.
+容器对于其他的系统来说就像是黑盒子，它的高度的可移植性，对于开发来说简直大有裨益，从开发到生产，甚至从一台笔记本开发直到云端。但是运行起来后，监控和解决服务问题，这个黑盒子让常规的方法失效了，我们会想：容器里到底在运行着什么？这些程序和代码是怎么运行的？它有什么重要的输出指标吗？在开发者的视角，你需要对容器有更深的了解而不是知道一些容器的存在。
 
 ![](http://thenewstack.io/wp-content/uploads/2016/09/greatfordev.jpg)
 
-The typical process for instrumentation in a non-containerized environment — an agent that lives in the user space of a host or VM — doesn’t work particularly well for containers. That’s because containers benefit from being small, isolated processes with as few dependencies as possible.
+非容器环境的典型特征，一个代理程序运行在一台主机或者虚机的用户空间，但是容器里不一样。容器的有点是小，讲各种进程分离开来，尽可能的减少依赖关系。
 
-And, at scale, running thousands of monitoring agents for even a modestly-sized deployment is an expensive use of resources and an orchestration nightmare. Two potential solutions arise for containers: 1) ask your developers to instrument their code directly, or 2) leverage a universal kernel-level instrumentation approach to see all application and container activity on your hosts. We won’t go into depth here, but each method has pros and cons.
+在规模上看，成千上万的监测代理，对即使是一个中等大小的部署都是一个昂贵的资源浪费和业务流程的噩梦。对于容器有两个潜在的解决方案：1）要求你的开发人员直接提交他们的代码，或者2）利用一个通用的内核级的检测方法来查看主机上的所有应用程序和容器活动。我们不会在这里深入，但每一种方法都有优点和缺点。
 
-#### 2. Leverage Orchestration Systems to Alert on Service Performance
+#### 2. 利用业务流程系统提醒服务性能
 
-Making sense of operational data in a containerized environment is a new challenge. The metrics of a single container have a much lower marginal value than the aggregate information from all the containers that make up a function or a service.
+理解容器中数据的运行方式并不容易，一个容器的度量值比组成函数或服务的所有容器的聚合信息都要低得多。
 
-This particularly applies to application-level information, like which queries have the slowest response times or which URLs are seeing the most errors, but also applies to infrastructure-level monitoring, like which services’ containers are using the most resources beyond their allocated CPU shares.
+这特别适用于应用程序级别的信息，就像哪个请求拥有最短响应时间或者哪个URLs有最多的错误，同样也适用于基础设施水平监测，比如哪个服务的容器使用CPU资源超过了事先分配的资源数。
 
-Increasingly, software deployment requires an orchestration system to “translate” a logical application blueprint into physical containers. Common orchestration systems include Kubernetes, Mesosphere DC/OS and Docker Swarm. Teams use an orchestration system to (1) define your microservices and (2) understand the current state of each service in deployment. You could argue that the orchestration system is even more important than the containers. The actual containers are ephemeral — they matter only for the short time that they exist — while your services matter for the life of their usefulness.
+越来越多的软件部署需要一个业务流程系统，将逻辑化的应用程序转化到一个物理的容器中。
+常见的转化系统包括Kubernetes、Mesosphere DC/OS和Docker Swarm。团队用一个业务流程系统来定义微服务和理解部署每个服务的当前状态。容器是短暂的，只有满足你的服务需求才会存在。
 
-DevOps teams should redefine alerts to focus on characteristics that get as close to monitoring the experience of the service as possible. These alerts are the first line of defense in assessing if something is impacting the application. But getting to these alerts is challenging, if not impossible unless your monitoring system is container-native.
+DevOps团队应该尽可能将重点放到如何更好的监控服务的运行特点上，如果应用受到了影响，这些告警点要放在第一道评估线上。但是能观察到这些告警点也并不容易，除非你的监控系统是容器本地的。
 
-Container-native solutions leverage orchestration metadata to dynamically aggregate container and application data and calculate monitoring metrics on a per-service basis. Depending on your orchestration tool, you might have different layers of a hierarchy that you’d like to drill into. For example, in Kubernetes, you typically have a Namespace, ReplicaSets, Pods and some containers. Aggregating at these various layers is essential for logical troubleshooting, regardless of the physical deployment of the containers that make up the service.
+容器原生解决方案利用业务流程元数据来动态聚合容器和应用程序数据，并计算每个服务基础上的监控度量。根据您的业务流程工具，您可能有不同层次的层次结构想检测。比如，在Kubernetes里，你通常有Namespace、ReplicaSets、Pods和一些其他容器。聚集在这些不同的层有助于故障排除，这与构成服务的容器的物理部署无关。
 
 ![](http://thenewstack.io/wp-content/uploads/2016/09/servicemonitoring.jpg)
 
-#### 3. Be Prepared for Services that are Elastic and Multi-Location
+#### 3. 监控弹性和多变的服务
 
-Elastic services are certainly not a new concept, but the velocity of change is much faster in container-native environments than virtualized environments. Rapidly changing environments can wreak havoc on brittle monitoring systems.
+弹性服务不是一个新概念，但是它在本地容器中的变化速度比在虚拟环境中快的多。迅速的变化会严重影响检测系统的正常运行。
 
-Frequently monitoring legacy systems required manual tuning of metrics and checks based on individual deployments of software. This tuning can be as specific as defining the individual metrics to be captured, or configuring collection based on what application is operating in a particular container. While that may be acceptable on a small scale (think tens of containers), it would be unbearable in anything larger. Microservice focused monitoring must be able to comfortably grow and shrink in step with elastic services, without human intervention.
+经常监测系统所需的手动调整指标和单独部署的软件，这种调整可以是具体的，如定义要捕获的单个指标，或收集应用程序在一个特定的容器中操作的配置数据。小规模上我们可以接受，但是数以万计规模的容器就不行了。微服务的集中监控必须能够自由的监控弹性服务的增长和缩减，而且无人工干预。
 
-For example, if the DevOps team must manually define what service a container is included in for monitoring purposes, they no doubt drop the ball as Kubernetes or Mesos spins up new containers regularly throughout the day. Similarly, if Ops were required to install a custom stats endpoint when new code is built and pushed into production, challenges may arise as developers pull base images from a Docker registry.
+比如，开发团队必须手动定义容器包含那个服务做监控使用，他们毫无疑问会把球抛给Kubernetes或者Mesos定期的创建新的容器。同样，如果开发团队需要配置一个自定义的状态点从新代码的产生到付诸生产，那么基础镜像从容器中注册会给开发者带来更多的挑战。
 
-In production, build monitoring toward a sophisticated deployment that spans multiple data centers or multiple clouds. Leveraging, for example, AWS CloudWatch will only get you so far if your services span your private data center as well as AWS. That leads back to implementing a monitoring system that can span these different locations as well as operate in dynamic, container-native environments.
+在生产中，建立一个复杂的跨越多个数据中心或多个云部署的监控，会使你的服务跨越你的死人数据中心，具体的应用，比如亚马逊的AWS CloudWatch。通过动态的本地容器环境，这个实时监控系统，会监控不同区域的数据中心。
 
-#### 4. Monitor APIs
+#### 4.监控开发接口
 
-In microservice environments, APIs are the lingua franca. They are essentially the only elements of a service that are exposed to other teams. In fact, response and consistency of the API may be the “internal SLA” even if there isn’t a formal SLA defined.
+在微服务环境中，API接口是通用的。它们是一个服务的必备组件，实际上，API的响应和一致性是服务的内部语言，虽然暂时还没人定义它们。
 
-As a result, API monitoring is essential. API monitoring can take many forms but clearly, must go beyond binary up/down checks. For instance, it’s valuable to understand the most frequently used endpoints as a function of time. This allows teams to see if anything noticeable has changed in the usage of services, whether it be due to a design change or a user change.
+因此，API接口的监控也是必需的。API监控可以有不同的形式，但是它绝对不是简单的上下检查。例如，了解最常使用的点作为时间函数是有价值的。这使得团队可以看到，服务使用的变化，无论是由于设计变更或用户的改变。
 
-You can also consider the slowest endpoints of your service, as these can reveal significant problems, or, at the very least, point to areas that need the most optimization in your system.
+你也可以记录服务最缓慢的点，这些可以揭示重大的问题，至少，指向需要在系统中做优化的区域。
 
-Finally, the ability to trace service calls through your system represents another critical capability. While typically used by developers, this type of profiling will help you understand the overall user experience while breaking information down into infrastructure and application-based views of your environment.
+最终，跟踪系统服务响应会成为一个很重要的能力，它会帮助开发者了解最终用户体验，同时将信息分成基础设施和应用程序环境两大部分。
 
-#### 5. Map Monitoring to Your Organizational Structure
+#### 5. 将您的监控映射到您的组织结构
 
-While most of this post has been focused on the technological shift in microservices and monitoring, like any technology story, this is as much about people as it is about software bits.
+这篇文章着重在微服务和监控上，像其他科技文章一样，这是因为很多人都关注软件层面。
 
-For those of you familiar with Conway’s law, he reminds us that the design of systems is defined by the organizational structure of the teams building them. The allure of creating faster, more agile software has pushed teams to think about restructuring their development organization and the rules that govern it.
+对于那些熟悉康威定律的人来说，系统的设计是基于开发团队的组织结构。创造更快，更敏捷的软件的迫力，推动团队思考重新调整他们的组织结构和管理它的规则。
 
 ![](http://thenewstack.io/wp-content/uploads/2016/09/mapmonitoring.jpg)
 
-So if an organization wants to benefit from this new software architecture approach, their teams must, therefore, mirror microservices themselves. That means smaller teams, loosely coupled; that can choose their direction as long as it still meets the needs of the whole. Within each team, there is more control than ever over languages used, how bugs are handled, or even operational responsibilities.
+如果他们想从新的软件架构比如微服务上获益，那么他们需要更小的更松散更耦合的团队，可以选择自己的方向只要能够满足整个需求即可。在一个团队中，对于什么开发语言的使用，bug的提交甚至工作职责都会有更大的控制能力。
 
-DevOps teams can enable a monitoring platform that does exactly this: allows each microservice team to isolate their alerts, metrics, and dashboards, while still giving operations a view into the global system.
+开发团队可以启用一个监控平台：让每一个微服务团队可以定位自己的警报，指标，和控制面板，同时也要给全局系统的操作一个图表。
 
-### Conclusion
+### 总结
 
-There’s one, clear trigger event that precipitated the move to microservices: speed. Organizations wanted to deliver more capabilities to their customers in less time. Once this happened, technology stepped in, the architectural move to micro-services and the underlying shift to containers make speed happen. Anything that gets in the way of this progress train is going to get run over on the tracks.
+快捷让微服务流行起来。开发组织要想为客户提供更快的更多的功能，然后微服务技术就来了，架构转向微服务并且容器的流行让快捷开发成为可能，所有相关的进程理所当然的搭上了这辆火车。
 
-As a result, the fundamental principles of monitoring need to adapt to the underlying technology and organizational changes that accompany microservices. Operations teams that recognize this shift can adapt to microservices earlier and easier.
+最后，基本的监控原则需要适应加入到微服务的技术和结构。越早认识到这种转变的开发团队，能更早更容易的适应微服务这一新的架构。
 
 --------------------------------------------------------------------------------
 
 via: http://linoxide.com/firewall/pfsense-setup-basic-configuration/
 
 作者：[Apurva Dave][a] [Loris Degioanni][b]
-译者：[译者ID](https://github.com/译者ID)
+译者：[jiajia9linuxer](https://github.com/jiajia9linuxer)
 校对：[校对者ID](https://github.com/校对者ID)
 
 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

sources/tech/20160915 Using Ansible to Provision Vagrant Boxes.md

@@ -1,72 +1,71 @@
-jiajia9linuxer
-Using Ansible to Provision Vagrant Boxes
+用Ansible来配置Vagrant Boxes
 ====
 
 ![](https://i1.wp.com/cdn.fedoramagazine.org/wp-content/uploads/2016/08/vagrant-plus-ansible.jpg?w=1352&ssl=1)
 
-Ansible is a great tool for system administrators who want to automate system administration tasks. From configuration management to provisioning and managing containers for application deployments, Ansible [makes it easy][1]. The lightweight module based architecture is ideal for system administration. One advantage is that when the node is not being managed by Ansible, no resources are used.
+Ansible 是一款系统管理员进行自动化运维的强大工具。Ansible 让配置、交付、管理各种容器，软件部署变得非常简单[1]。基于轻量级模块的架构非常适合系统管理，一个优点就是如果某个节点没有被 Ansible 管理的话，它的资源是没有被使用的。
 
-This article covers how to use Ansible to provision Vagrant boxes. A [Vagrant box][2] in simple terms is a virtual machine prepackaged with tools required to run the development environment. You can use these boxes to distribute the development environment used by other team members for project work. Using Ansible, you can automate provisioning the Vagrant boxes with your development packages.
+这篇文章介绍用 Ansible 来配置 Vagrant boxes，它是一个配置好的基础虚拟机映像，包含在开发环境中需要用到的工具。你可以用它来部署开发环境，然后和其他成员协同工作。用 Ansible，你可以用你的开发包自动化配置 Vagrant boxes。
 
-This tutorial uses Fedora 24 as the host system and [CentOS][3] 7 as the Vagrant box.
+我们用 Fedora 24 做主机，用 CentOS 7 来作 Vagrant box
 
-### Setting up prerequisites
+### 设置工作环境
 
-To configure Vagrant boxes using Ansible, you’ll need a few things setup. This tutorial requires you to install Ansible and Vagrant on the host machine. On your host machine, execute the following command to install the tools:
+在用 Ansible 配置 Vagrant boxes 时，你需要做几件准备的事情。首先在主机上安装 Ansible 和 Vagrant，在主机上运行下面的命令来安装：
 
 ```
 sudo dnf install ansible vagrant vagrant-libvirt
 ```
 
-The above command installs both Ansible and Vagrant on your host system, along with Vagrant’s libvirt provider. Vagrant doesn’t provide functionality to host your virtual machine guests (VMs). Rather, it depends on third party providers such as libvirt, VirtualBox, VMWare, etc. to host the VMs. This provider works directly with libvirt and KVM on your Fedora system.
+上面的命令将 Ansible 和 Vagrant 在你的主机上，也包括 Vagrant 的自动部署工具。Vagrant 不能自己管理虚拟主机，需要第三方工具比如：libirt，VirtualBox，VMWare等等。工具直接在你的 Fedora 系统上运行。
 
-Next, make sure your user is in the wheel group. This special group allows you to run system administration commands. If you created your user as an administrator, such as during installation, you’ll have this group membership. Run the following command:
+接着确认你的账户在正确的用户组 wheel 当中，确保你可以运行系统管理员命令。如果你的账号在安装过程中就创建为管理员，那么你就肯定在这个用户组里。运行下面的命令：
 
 ```
 id | grep wheel
 ```
 
-If you see output, your user is in the group, and you can move on to the next section. If not, run the following command. You’ll need to provide the password for the root account. Substitute your user name for the text <username>:
+如果你能看到输出，那么你的账户就在这个组里，可以进行下一步。如果没有的话，你需要运行下面的命令，这一步需要你提供 root 账户的密码，在<username>里加上你的用户名：
 
 ```
 su -c 'usermod -a -G wheel <username>'
 ```
 
-Then you will need to logout, and log back in, to inherit the group membership properly.
+然后，你需要注销然后重新登录，确保在用户组里。
 
-Now it’s time to create your first Vagrant box, which you’ll then configure using Ansible.
+现在要建立你的第一个 Vagrant box 了，你需要用 Ansible 来配置它。
 
-### Setting up the Vagrant box
+### 设置 Vagrant box
 
-Before you use Ansible to provision a box, you must create the box. To start, create a new directory which will store files related to the Vagrant box. To create this directory and make it the current working directory, issue the following command:
+配置一个镜像 box 之前，你需要先创建它。创建一个目录，存放 Vagrant box 相关的文件，并且将它设置为工作目录，用下面这条命令：
 
 ```
 mkdir -p ~/lampbox && cd ~/lampbox
 ```
 
-Before you create the box, you should understand the goal. This box is a simple example that runs CentOS 7 as its base system, along with the Apache web server, MariaDB (the popular open source database server from the original developers of MySQL) and PHP.
+在创建镜像 box 之前，你需要搞清楚目的，这个镜像 box 是一个运行 CentOS 7 基础系统的模板包括 Apache 的 web 服务，MariaDB（MySQL 原始开发者创建的一个流行的开源数据库）数据库和 PHP 服务。
 
-To initialize the Vagrant box, use the vagrant init command:
+初始化 Vagrant box，用 vagrant 开发工具初始化命令：
 
 ```
 vagrant init centos/7
 ```
 
-This command initializes the Vagrant box and creates a file named Vagrantfile, with some pre-configured variables. Open this file so you can modify it. The following line lists the base box used by this configuration.
+这个命令初始化 Vagrant box 创建一些 Vagrantfile 名字的文件，也包含一些预先配置的文件。你可以打开和编辑它们，下面的命令显示基本的镜像box和配置。
 
 ```
 config.vm.box = "centos/7"
 ```
 
-Now setup port forwarding, so after you finish setup and the Vagrant box is running, you can test the server. To setup port forwarding, add the following line just before the end statement in Vagrantfile:
+设置端口转发，这样在你设置玩 Vagrant box 之后可以测试它。用下面的命令实现：
 
 ```
 config.vm.network "forwarded_port", guest: 80, host: 8080
 ```
 
-This option maps port 80 of the Vagrant Box to port 8080 of the host machine.
+这个命令将 Vagrant Box 的 80 端口映射为主机的 8080 端口。
 
-The next step is to set Ansible as our provisioning provider for the Vagrant Box. Add the following lines before the end statement in your Vagrantfile to set Ansible as the provisioning provider:
+下一步是设置 Ansible 作为配置 Vagrant Box 的工具，下面的命令将 Ansible 作为配置工具在 end 之前加入到 Vagrantfile 中：
 
 ```
 config.vm.provision :ansible do |ansible|
@@ -74,13 +73,13 @@ config.vm.provision :ansible do |ansible|
 end
 ```
 
-(You must add all three lines before the final end statement.) Notice the statement ansible.playbook = “lamp.yml”. This statement defines the name of the playbook used to provision the box.
+（必须将这三行在最后的语句之前加入）ansible.playbook = "lamp.yml"这一句定义了配置镜像box的手册的名字。
 
-### Creating the Ansible playbook
+### 创建Ansible详细手册
 
-In Ansible, playbooks describe a policy to be enforced on your remote nodes. Put another way, playbooks manage configurations and deployments on remote nodes. Technically speaking, a playbook is a YAML file in which you write tasks to perform on remote nodes. In this tutorial, you’ll create a playbook named lamp.yml to provision the box.
+Ansible 的手册描述的是执行在你的远端节点的策略，换句话说，它管理远端节点的配置和部署。详细的说，手册是一个 Yaml 文件，在里面你写入在远端节点上将要执行的任务。所以，你需要创建一个名为 lamp.yml 的手册来配置镜像 box。
 
-To make the playbook, create a file named lamp.yml in the same directory where your Vagrantfile is located and add the following lines to it:
+在 Vagrantfile 的目录里创建一个 lamp.yml 文件，将下面的内容粘贴到文件当中：
 
 ```
 ---
@@ -104,43 +103,43 @@ To make the playbook, create a file named lamp.yml in the same directory where y
     command: firewall-cmd --add-service=http --permanent
 ```
 
-An explanation of each line of lamp.yml follows.
+每一行代表的意思：
 
-- hosts: all specifies the playbook should run over every host defined in the Ansible configuration. Since no hosts are configured hosts yet, the playbook will run on localhost.
-- sudo: true states the tasks should be performed with root privileges.
-- tasks: specifies the tasks to perform when the playbook runs. Under the tasks section:
-- - name: … provides a descriptive name to the task
-- - yum: … specifies the task should be executed by the yum module. The options name and state are key=value pairs for use by the yum module.
+- hosts: 定义 Ansible 配置文件需要在所有的主机上运行，因为还没定义主机，暂时只在本地运行。
+- sudo: 需要用 root 权限运行的任务
+- tasks: 确定的任务
+- - name: 描述任务的名字
+- - yum: 描述任务需要调用 yum 模块，需要 key=value 成对被 yum 模块调用。
 
-When this playbook executes, it installs the latest versions of the Apache (httpd) web server, MariaDB, and PHP. Then it installs and starts firewalld, and opens a port for the Apache server. You’re now done writing the playbook for the box. Now it’s time to provision it.
+当手册运行时，它会安装最新的 Apache 的 web 服务，MariaDB 和 PHP。当安装完毕开始工作，会给 Apache 打开一个端口。你可以给镜像 box 写手册，并且可以配置它了。
 
-### Provisioning the box
+### 配置镜像 box
 
-A few final steps remain before using the Vagrant Box provisioned using Ansible. To run this provisioning, execute the following command:
+用 Ansible 配置 Vagrant Box 只需要以下几部了：
 
 ```
 vagrant up --provider libvirt
 ```
 
-The above command starts the Vagrant box, downloads the base box image to the host system if not already present, and then runs the playbook lamp.yml to provision.
+上面的命令运行 Vagrant box，将基本的镜像 box 下载到主机当中，然后运行 lamp.yml 手册来进行配置。
 
-If everything works fine, the output looks somewhat similar to this example:
+如果一切正常，输出应该和下面的例子类似：
 
 ![](https://i1.wp.com/cdn.fedoramagazine.org/wp-content/uploads/2016/08/vagrant-ansible-playbook-run.png?w=574&ssl=1)
 
-This output shows that the box has been provisioned. Now check whether the server is accessible. To confirm, open your web browser on the host machine and point it to the address http://localhost:8080. Remember, port 8080 of the local host is forwarded to port 80 of the Vagrant box. You should be greeted with the Apache welcome page like the one shown below:
+这个输出显示镜像 box 已经被配置好了，现在检查服务是否可用，打开浏览器，输入 http://localhost:8080，记住主机的 8080 端口是 Vagrant box 映射过来的 80 端口。你应该可以看到如下的 Apache 的欢迎界面。
 
 ![](https://i0.wp.com/cdn.fedoramagazine.org/wp-content/uploads/2016/08/vagrant-ansible-apache-up.png?w=1004&ssl=1)
 
-To make changes to your Vagrant box, first edit the Ansible playbook lamp.yml. You can find plentiful documentation on Ansible at [its official website][4]. Then run the following command to re-provision the box:
+改变 Vagrantbox，你可以修改 lamp.yml 手册，你能从 Ansible 的官网上找到很多文章。然后运行下面的命令：
 
 ```
 vagrant provision
 ```
 
-### Conclusion
+### 总结
 
-You’ve now seen how to use Ansible to provision Vagrant boxes. This was a basic example, but you can use these tools for many other use cases. For example, you can deploy complete applications along with up-to-date version of required tools. Be creative as you use Ansible to provision your remote nodes or containers.
+现在我们知道怎么用 Ansible 来配置 Vagrant boxes 了。这只是一个基本的例子，但是你可以用这些工具来实现不同的例子。比如你可以部署最新的工具，现在你可以用 Ansible 来配置你自己的远端服务器和容器了。
 
 
 --------------------------------------------------------------------------------
@@ -148,7 +147,7 @@ You’ve now seen how to use Ansible to provision Vagrant boxes. This was a basi
 via: https://fedoramagazine.org/using-ansible-provision-vagrant-boxes/
 
 作者：[Saurabh Badhwar][a]
-译者：[译者ID](https://github.com/译者ID)
+译者：[jiajia9linuxer](https://github.com/jiajia9linuxer)
 校对：[校对者ID](https://github.com/校对者ID)
 
 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出