mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-28 23:20:10 +08:00
Merge pull request #3402 from ictlyh/master
Translated sources/tech/20150929 A Developer's Journey into Linux Con…
This commit is contained in:
ictlyh
commit
90c860078d
@ -1,129 +0,0 @@
|
||||
ictlyh Translating
|
||||
A Developer’s Journey into Linux Containers
|
||||
================================================================================
|
||||
|
||||
|
||||
I’ll let you in on a secret: all that DevOps cloud stuff that goes into getting my applications into the world is still a bit of a mystery to me. But, over time I’ve come to realize that understanding the ins and outs of large scale machine provisioning and application deployment is important knowledge for a developer to have. It’s akin to being a professional musician. Of course you need know how to play your instrument. But, if you don’t understand how a recording studio works or how you fit into a symphony orchestra, you’re going to have a hard time working in such environments.
|
||||
|
||||
In the world of software development getting your code into our very big world is just as important as making it. DevOps counts and it counts a lot.
|
||||
|
||||
So, in the spirit of bridging the gap between Dev and Ops I am going to present container technology to you from the ground up. Why containers? Because there is strong evidence to suggest that containers are the next step in machine abstraction: making a computer a place and no longer a thing. Understanding containers is a journey that we’ll take together.
|
||||
|
||||
In this article I am going to cover the concepts behind containerization. I am going to cover how a container differs from a virtual machine. I am going to go into the logic behind containers construction as well as how containers fit into application architecture. I’ll discussion how lightweight versions of the Linux operating system fits into the container ecosystem. I’ll discuss using images to create reusable containers. Lastly I’ll cover how clusters of containers allow your applications to scale quickly.
|
||||
|
||||
In later articles I’ll show you the step by step process to containerize a sample application and how to create a host cluster for your application’s containers. Also, I’ll show you how to use a Deis to deploy the sample application to a VM on your local system as well as a variety of cloud providers.
|
||||
|
||||
So let’s get started.
|
||||
|
||||
### The Benefit of Virtual Machines ###
|
||||
|
||||
In order to understand how containers fit into the scheme of things you need to understand the predecessor to containers: virtual machines.
|
||||
|
||||
A [virtual machine][1] (VM) is a software abstraction of a computer that runs on a physical host computer. Configuring a virtual machine is akin to buying a typical computer: you define the number of CPUs you want along with desired RAM and disk storage capacity. Once the machine is configured, you load in the operating system and then any servers and applications you want the VM to support.
|
||||
|
||||
Virtual machines allow you to run many simulations of a computer on a single hardware host. Here’s what that looks like with a handy diagram:
|
||||
|
||||
|
||||
|
||||
Virtual machines bring efficiency to your hardware investment. You can buy a big, honking machine and run a lots of VMs on it. You can have a database VM sitting with a bunch of VMs with identical versions of your custom app running as a cluster. You can get a lot of scalability out of a finite hardware resources. If you find that you need more VMs and your host hardware has the capacity, you add what you need. Or, if you don’t need a VM, you simply bring the VM off line and delete the VM image.
|
||||
|
||||
### The Limitations of Virtual Machines ###
|
||||
|
||||
But, virtual machines do have limits.
|
||||
|
||||
Say you create three VMs on a host as shown above. The host has 12 CPUs, 48 GB of RAM, and 3 TB of storage. Each VM is configured to have 4 CPUs, 16 GB of RAM and 1 TB of storage. So far, so good. The host has the capacity.
|
||||
|
||||
But there is a drawback. All the resources allocated to a particular machine are dedicated, no matter what. Each machine has been allocated 16 GB of RAM. However, if the first VM never uses more than 1 GB of its RAM allocation, the remaining 15 GB just sit there unused. If the third VM uses only 100 GB of its 1 TB storage allocation, the remaining 900 GB is wasted space.
|
||||
|
||||
There is no leveling of resources. Each VM owns what it is given. So, in a way we’re back to that time before virtual machines when we were paying a lot of good money for unused resources.
|
||||
|
||||
There is *another* drawback to VMs too. They can take a long time to spin up. So, if you are in a situation where your infrastructure needs to grow quickly, even in a situation when VM provisioning is automated, you can still find yourself twiddling your thumbs waiting for machines to come online.
|
||||
|
||||
### Enter: Containers ###
|
||||
|
||||
Conceptually, a container is a Linux process that thinks it is the only process running. The process knows only about things it is told to know about. Also, in terms of containerization, the container process is assigned its own IP address. This is important, so I will say it again. **In terms of containerization, the container process is assigned its own IP address**. Once given an IP address, the process is an identifiable resource within the host network. Then, you can issue a command to the container manager to map the container’s IP address to a IP address on the host that is accessible to the public. Once this mapping takes place, for all intents and purposes, a container is a distinct machine accessible on the network, similar in concept to a virtual machine.
|
||||
|
||||
Again, a container is an isolated Linux process that has a distinct IP address thus making it identifiable on a network. Here’s what that looks like as diagram:
|
||||
|
||||
|
||||
|
||||
A container/process shares resources on the host computer in a dynamic, cooperative manner. If the container needs only 1 GB of RAM, it uses only 1 GB. If it needs 4 GB, it uses 4 GB. It’s the same with CPU utilization and storage. The allocation of CPU, memory and storage resources is dynamic, not static as is usual on a typical virtual machine. All of this resource sharing is managed by the container manager.
|
||||
|
||||
Lastly, containers boot very quickly.
|
||||
|
||||
So, the benefit of containers is: **you get the isolation and encapsulation of a virtual machine without the drawback of dedicated static resources**. Also, because containers load into memory fast, you get better performance when it comes to scaling many containers up.
|
||||
|
||||
### Container Hosting, Configuration, and Management ###
|
||||
|
||||
Computers that host containers run a version of Linux that is stripped down to the essentials. These days, the more popular underlying operating system for a host computer is [CoreOS, mentioned above][2]. There are others, however, such as [Red Hat Atomic Host][3] and [Ubuntu Snappy][4].
|
||||
|
||||
The Linux operating system is shared between all containers, minimising duplication and reducing the container footprint. Each container contains only what is unique to that specific container. Here’s what that looks like in diagram form:
|
||||
|
||||
|
||||
|
||||
You configure your container with the components it requires. A container component is called a **layer**. A layer is a container image. (You’ll read more about container images in the following section.). You start with a base layer which typically the type of operating system you want in your container. (The container manager will provides only the parts of your desired operating system that is not in the host OS) As you construct the configuration of your container, you’ll add layers, say Apache if you want a web server, PHP or Python runtimes, if your container is running scripts.
|
||||
|
||||
Layering is very versatile. If you application or service container requires PHP 5.2, you configure that container accordingly. If you have another application or service that requires PHP 5.6, no problem. You configure that container to use PHP.5.6. Unlike VMs, where you need to go through a lot of provisioning and installation hocus pocus to change a version of a runtime dependency; with containers you just redefine the layer in the container configuration file.
|
||||
|
||||
All of the container versatility described previously is controlled by the a piece of software called a container manager. Presently, the most popular container managers are [Docker][5] and [Rocket][6]. The figure above shows a host scenario is which Docker is the container manager and CoreOS is the host operating system.
|
||||
|
||||
### Containers are Built with Images ###
|
||||
|
||||
When it comes time for you to build our application into a container, you are going to assemble images. An image represents a template of a container that your container needs to do its work. (I know, containers within containers. Go figure.) Images are stored in a registry. Registries live on the network.
|
||||
|
||||
Conceptually, a registry is similar to a [Maven][7] repository, for those of you from the Java world, or a [NuGet][8] server, for you .NET heads. You’ll create a container configuration file that lists the images your application needs. The you’ll use the container manager to make a container that includes your application’s code as well as constituent resources downloaded from a container registry. For example, if your application is made up of some PHP files, your container configuration file will declare that you get the PHP runtime from a registry. Also, you’ll use the container configuration file to declare the .php files to copy into the container’s file system. The container manager encapsulates all your application stuff into a distinct container that you’ll run on a host computer, under a container manager.
|
||||
|
||||
Here’s a diagram that illustrates the concepts behind container creation:
|
||||
|
||||
|
||||
|
||||
Let’s take a detailed look at this diagram.
|
||||
|
||||
Here, (1) indicates there is a container configuration file that defines the stuff your container needs, as well as how your container is to be constructed. When you run your container on the host, the container manager will read the configuration file to get the container images you need from a registry on the cloud (2) and add the images as layers in your container.
|
||||
|
||||
Also, if that constituent image requires other images, the container manager will get those images too and layer them in. At (3) the container manager will copy in files to your container as is required.
|
||||
|
||||
If you use a provisioning service, such as [Deis][9], the application container you just created exists as an image (4) which the provisioning service will deploy to a cloud provider of your choice. Examples of cloud providers are AWS and Rackspace.
|
||||
|
||||
### Containers in a Cluster ###
|
||||
|
||||
Okay. So we can say there is a good case to be made that containers provide a greater degree of configuration flexibility and resource utilization than virtual machines. Still, this is not the all of it.
|
||||
|
||||
Where containers get really flexible is when they’re clustered. Remember, a container has a distinct IP address. Thus, it can be put behind a load balancer. Once a container goes behind a load balancer, the game goes up a level.
|
||||
|
||||
You can run a cluster of containers behind a load balancer container to achieve high performance, high availability computing. Here’s one example setup:
|
||||
|
||||
|
||||
|
||||
Let’s say you’ve made an application that does some resource intensive work. Photograph processing, for example. Using a container provisioning technology such as [Deis][9], you can create a container image that has your photo processing application configured with all the resources upon which your photo processing application depends. Then, you can deploy one or many instances of your container image to under a load balancer that reside on the host. Once the container image is made, you can keep it on the sidelines for introduction later on when the system becomes maxed out and more instances of your container are required in the cluster to meet the workload at hand.
|
||||
|
||||
There is more good news. You don’t have manually configure the load balancer to accept your container image every time you add more instances into the environment. You can use service discovery technology to make it so that your container announces its availability to the balancer. Then, once informed, the balancer can start to route traffic to the new node.
|
||||
|
||||
### Putting It All Together ###
|
||||
|
||||
Container technology picks up where the virtual machine has left off. Host operating systems such as CoreOS, RHEL Atomic, and Ubuntu’s Snappy, in conjunction with container management technologies such as Docker and Rocket, are making containers more popular everyday.
|
||||
|
||||
While containers are becoming more prevalent, they do take a while to master. However, once you get the hang of them, you can use provisioning technologies such as [Deis][9] to make container creation and deployment easier.
|
||||
|
||||
Getting a conceptual understanding of containers is important as we move forward to actually doing some work with them. But, I imagine the concepts are hard to grasp without the actual hands-on experience to accompany the ideas in play. So, this is what we’ll do in the next segment of this series: make some containers.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://deis.com/blog/2015/developer-journey-linux-containers
|
||||
|
||||
作者：[Bob Reselman][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://deis.com/blog
|
||||
[1]:https://en.wikipedia.org/wiki/Virtual_machine
|
||||
[2]:https://coreos.com/using-coreos/
|
||||
[3]:http://www.projectatomic.io/
|
||||
[4]:https://developer.ubuntu.com/en/snappy/
|
||||
[5]:https://www.docker.com/
|
||||
[6]:https://coreos.com/blog/rocket/
|
||||
[7]:https://en.wikipedia.org/wiki/Apache_Maven
|
||||
[8]:https://www.nuget.org/
|
||||
[9]:http://deis.com/learn
|
||||
@ -0,0 +1,128 @@
|
||||
开发者的 Linux 容器之旅
|
||||
================================================================================
|
||||
|
||||
|
||||
我告诉你一个秘密：使得我的应用程序进入到全世界的所有云计算的东西，对我来说仍然有一点神秘。但随着时间流逝，我意识到理解大规模机器配置和应用程序部署的来龙去脉对一个开发者来说是非常重要的知识。这类似于成为一个专业的音乐家。你当然需要知道如何使用你的乐器。但是，如果你不知道一个录音室是如何工作的，或者你如何适应一个交响乐团，你在这样的环境中工作会变得非常困难。
|
||||
|
||||
在软件开发的世界里，使你的代码进入我们更大的世界正如写出它来一样重要。开发重要，而且是很重要。
|
||||
|
||||
因此，为了弥合开发和部署之间的间隔，我会从头开始介绍容器技术。为什么是容器？因为有强有力的证据表明，容器是机器抽象的下一步：使计算机成为场所而不再是一个东西。理解容器是我们共同的旅程。
|
||||
|
||||
在这篇文章中，我会介绍容器化背后的概念。容器和虚拟机的区别。以及容器构建背后的逻辑以及它是如何适应应用程序架构的。我会探讨轻量级的 Linux 操作系统是如何适应容器生态系统。我还会讨论使用镜像创建可重用的容器。最后我会介绍容器集群如何使你的应用程序可以快速扩展。
|
||||
|
||||
在后面的文章中，我会一步一步向你介绍容器化一个事例应用程序的过程，以及如何为你的应用程序容器创建一个托管集群。同时，我会向你展示如何使用 Deis 将你的事例应用程序部署到你本地系统以及多种云供应商的虚拟机上。
|
||||
|
||||
让我们开始吧。
|
||||
|
||||
### 虚拟机的好处 ###
|
||||
|
||||
为了理解容器如何适应事物发展，你首先要了解容器的前者：虚拟机
|
||||
|
||||
[虚拟机][1] 是运行在物理宿主机上的软件抽象。配置一个虚拟机就像是购买一台计算机：你需要定义你想要的 CPU 数目，RAM 和磁盘存储容量。配置好了机器后，你把它加载到操作系统，然后是你想让虚拟机支持的任何服务器或者应用程序。
|
||||
|
||||
虚拟机允许你在一台硬件主机上运行多个模拟计算机。这是一个简单的示意图：
|
||||
|
||||
|
||||
|
||||
虚拟机使得能充分利用你的硬件资源。你可以购买一台大型机然后在上面运行多个虚拟机。你可以有一个数据库虚拟机以及很多运行相同版本定制应用程序的虚拟机构成的集群。你可以在有限的硬件资源获得很多的扩展能力。如果你觉得你需要更多的虚拟机而且你的宿主硬件还有容量，你可以添加任何你想要的。或者，如果你不再需要一个虚拟机，你可以关闭该虚拟机并删除虚拟机镜像。
|
||||
|
||||
### 虚拟机的局限 ###
|
||||
|
||||
但是，虚拟机确实有局限。
|
||||
|
||||
如上面所示，假如你在一个主机上创建了三个虚拟机。主机有 12 个 CPU，48 GB 内存和 3TB 的存储空间。每个虚拟机配置为有 4 个 CPU，16 GB 内存和 1TB 存储空间。到现在为止，一切都还好。主机有这个容量。
|
||||
|
||||
但这里有个缺陷。所有分配给一个虚拟机的资源，无论是什么，都是专有的。每台机器都分配了 16 GB 的内存。但是，如果第一个虚拟机永不会使用超过 1GB 分配的内存，剩余的 15 GB 就会被浪费在那里。如果第三天虚拟机只使用分配的 1TB 存储空间中的 100GB，其余的 900GB 就成为浪费空间。
|
||||
|
||||
这里没有资源的流动。每台虚拟机拥有分配给它的所有资源。因此，在某种方式上我们又回到了虚拟机之前，把大部分金钱花费在未使用的资源上。
|
||||
|
||||
虚拟机还有*另一个*缺陷。扩展他们需要很长时间。如果你处于基础设施需要快速增长的情形，即使虚拟机配置是自动的，你仍然会发现你的很多时间都浪费在等待机器上线。
|
||||
|
||||
### 来到：容器 ###
|
||||
|
||||
概念上来说，容器是 Linux 中认为只有它自己的一个进程。该进程只知道告诉它的东西。另外，在容器化方面，该容器进程也分配了它自己的 IP 地址。这点很重要，我会再次重复。**在容器化方面，容器进程有它自己的 IP 地址**。一旦给予了一个 IP 地址，该进程就是宿主网络中可识别的资源。然后，你可以在容器管理器上运行命令，使容器 IP 映射到主机中能访问公网的 IP 地址。该映射发生时，对于任何意图和目的，一个容器就是网络上一个可访问的独立机器，概念上类似于虚拟机。
|
||||
|
||||
再次说明，容器是拥有不同 IP 地址从而使其成为网络上可识别的独立 Linux 进程。下面是一个示意图：
|
||||
|
||||
|
||||
|
||||
容器/进程以动态合作的方式共享主机上的资源。如果容器只需要 1GB 内存，它就只会使用 1GB。如果它需要 4GB，就会使用 4GB。CPU 和存储空间利用也是如此。CPU，内存和存储空间的分配是动态的，和典型虚拟机的静态方式不同。所有这些资源的共享都由容器管理器管理。
|
||||
|
||||
最后，容器能快速启动。
|
||||
|
||||
因此，容器的好处是：**你获得了虚拟机独立和封装的好处而抛弃了专有静态资源的缺陷**。另外，由于容器能快速加载到内存，在扩展到多个容器时你能获得更好的性能。
|
||||
|
||||
### 容器托管、配置和管理 ###
|
||||
|
||||
托管容器的计算机运行着被剥离的只剩下主要部分的 Linux 版本。现在，宿主计算机流行的底层操作系统是上面提到的 [CoreOS][2]。当然还有其它，例如 [Red Hat Atomic Host][3] 和 [Ubuntu Snappy][4]。
|
||||
|
||||
所有容器之间共享Linux 操作系统，减少了容器足迹的重复和冗余。每个容器只包括该容器唯一的部分。下面是一个示意图：
|
||||
|
||||
|
||||
|
||||
你用它所需的组件配置容器。一个容器组件被称为**层**。一层是一个容器镜像，（你会在后面的部分看到更多关于容器镜像的介绍）。你从一个基本层开始，这通常是你想在容器中使用的操作系统。（容器管理器只提供你想要的操作系统在宿主操作系统中不存在的部分。）当你构建配置你的容器时，你会添加层，例如你想要添加网络服务器 Apache，如果容器要运行脚本，则需要添加 PHP 或 Python 运行时。
|
||||
|
||||
分层非常灵活。如果应用程序或者服务容器需要 PHP 5.2 版本，你相应地配置该容器即可。如果你有另一个应用程序或者服务需要 PHP 5.6 版本，没问题，你可以使用 PHP 5.6 配置该容器。不像虚拟机，更改一个版本的运行时依赖时你需要经过大量的配置和安装过程；对于容器你只需要在容器配置文件中重新定义层。
|
||||
|
||||
所有上面描述的容器多功能性都由一个称为容器管理器的软件控制。现在，最流行的容器管理器是 [Docker][5] 和 [Rocket][6]。上面的示意图展示了容器管理器是 Docker，宿主操作系统是 CentOS 的主机情景。
|
||||
|
||||
### 容器由镜像构成 ###
|
||||
|
||||
当你需要将我们的应用程序构建到容器时，你就会编译镜像。镜像代表了需要完成容器工作的容器模板。（容器里的容器）。镜像被保存在网络上的注册表里。
|
||||
|
||||
从概念上讲，注册表类似于一个使用 Java 的人眼中的 [Maven][7] 仓库，使用 .NET 的人眼中的 [NuGet][8] 服务器。你会创建一个列出了你应用程序所需镜像的容器配置文件。然后你使用容器管理器创建一个包括了你应用程序代码以及从注册表中下载的构成资源的容器。例如，如果你的应用程序包括了一些 PHP 文件，你的容器配置文件会声明你会从注册表中获取 PHP 运行时。另外，你还要使用容器配置文件声明需要复制到容器文件系统中的 .php 文件。容器管理器会封装你应用程序的所有东西为一个独立容器。该容器将会在容器管理器的管理下运行在宿主计算机上。
|
||||
|
||||
这是一个容器创建背后概念的示意图：
|
||||
|
||||
|
||||
|
||||
让我们仔细看看这个示意图。
|
||||
|
||||
（1）表示一个定义了你容器所需东西以及你容器如何构建的容器配置文件。当你在主机上运行容器时，容器管理器会读取配置文件从云上的注册表中获取你需要的容器镜像，（2）作为层将镜像添加到你的容器。
|
||||
|
||||
另外，如果组成镜像需要其它镜像，容器管理器也会获取这些镜像并把它们作为层添加进来。（3）容器管理器会将需要的文件复制到容器中。
|
||||
|
||||
如果你使用了配置服务，例如 [Deis][9]，你刚刚创建的应用程序容器作为镜像存在（4）配置服务会将它部署到你选择的云供应商上。类似 AWS 和 Rackspace 云供应商。
|
||||
|
||||
### 集群中的容器 ###
|
||||
|
||||
好了。这里有一个很好的例子说明了容器比虚拟机提供了更好的配置灵活性和资源利用率。但是，这并不是全部。
|
||||
|
||||
容器真正灵活是在集群中。记住，每个容器有一个独立的 IP 地址。因此，能把它放到负载均衡器后面。将容器放到负载均衡器后面，就上升了一个层次。
|
||||
|
||||
你可以在一个负载均衡容器后运行容器集群以获得更高的性能和高可用计算。这是一个例子：
|
||||
|
||||
|
||||
|
||||
假如你开发了一个进行资源密集型工作的应用程序。例如图片处理。使用类似 [Deis][9] 的容器配置技术，你可以创建一个包括了你图片处理程序以及你图片处理程序需要的所有资源的容器镜像。然后，你可以部署一个或多个容器镜像到主机上的负载均衡器。一旦创建了容器镜像，你可以在系统快要刷爆时把它放到一边，为了满足手中的工作时添加更多的容器实例。
|
||||
|
||||
这里还有更多好消息。你不需要每次添加实例到环境中时手动配置负载均衡器以便接受你的容器镜像。你可以使用服务发现技术告知均衡器你容器的可用性。然后，一旦获知，均衡器就会将流量分发到新的结点。
|
||||
|
||||
### 全部放在一起 ###
|
||||
|
||||
容器技术完善了虚拟机不包括的部分。类似 CoreOS、RHEL Atomic、和 Ubuntu 的 Snappy 宿主操作系统，和类似 Docker 和 Rocket 的容器管理技术结合起来，使得容器变得日益流行。
|
||||
|
||||
尽管容器变得更加越来越普遍，掌握它们还是需要一段时间。但是，一旦你懂得了它们的窍门，你可以使用类似 [Deis][9] 的配置技术使容器创建和部署变得更加简单。
|
||||
|
||||
概念上理解容器和进一步实际使用它们完成工作一样重要。但我认为不实际动手把想法付诸实践，概念也难以理解。因此，我们该系列的下一阶段就是：创建一些容器。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://deis.com/blog/2015/developer-journey-linux-containers
|
||||
|
||||
作者：[Bob Reselman][a]
|
||||
译者：[ictlyh](http://www.mutouxiaogui.cn/blog/)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://deis.com/blog
|
||||
[1]:https://en.wikipedia.org/wiki/Virtual_machine
|
||||
[2]:https://coreos.com/using-coreos/
|
||||
[3]:http://www.projectatomic.io/
|
||||
[4]:https://developer.ubuntu.com/en/snappy/
|
||||
[5]:https://www.docker.com/
|
||||
[6]:https://coreos.com/blog/rocket/
|
||||
[7]:https://en.wikipedia.org/wiki/Apache_Maven
|
||||
[8]:https://www.nuget.org/
|
||||
[9]:http://deis.com/learn
|
||||
Loading…
Reference in New Issue
Block a user