web容器 ejb容器_容器实用指南

web容器 ejb容器

by Julius Zerwick

朱利叶斯·泽维克(Julius Zerwick)

容器实用指南 (A practical guide to containers)

Containers have taken over the software world by storm — and for good reason.

容器已经席卷了软件界，这是有充分理由的。

They’ve proven vital for DevOps and deployment, and have a multitude of uses for developers. And this goes not only for large companies, but for independent developers as well. In fact, containers played a vital role in the development and deployment of our project SpaceCraft.

它们已被证明对于DevOps和部署至关重要，并且对开发人员具有多种用途。 这不仅适用于大型公司，还适用于独立开发商。 实际上，容器在我们的SpaceCraft项目的开发和部署中起着至关重要的作用。

In this article, we’re going to give an introduction to containers and explain their core features. We’ll then showcase their uses in software development and cover some important topics regarding security and resource management. Along the way, we’ll give a peek into how containers were utilized in SpaceCraft. Let’s dive in!

在本文中，我们将对容器进行介绍并解释其核心功能。 然后，我们将展示它们在软件开发中的用途，并涵盖有关安全性和资源管理的一些重要主题。 在此过程中，我们将窥视一下SpaceCraft中如何使用容器 。 让我们潜入吧！

什么是容器？ (What Is A Container?)

So what exactly is a container?

那么容器到底是什么？

At its core, a container can be described as a single unit of encapsulated software. It’s essentially a box in which you can place all of your project dependencies and run a single service or an entire development environment, while keeping everything inside the box isolated from the host system.

容器的核心可以描述为封装软件的单个单元。 实际上，它是一个盒子，您可以在其中放置所有项目依赖项并运行单个服务或整个开发环境，同时将盒子中的所有内容与主机系统隔离。

As an example, imagine that you need to work on a new project and know all of the needed dependencies. But some of these dependencies may conflict with what you already have installed on your computer, like a language version number.

例如，假设您需要处理一个新项目并知道所有需要的依赖项。 但是其中一些依赖项可能与您计算机上已经安装的依赖项(例如语言版本号)冲突。

If you were to work on the project on your computer, you’d have to go through the tedious process of managing your dependencies and deactivating versions while activating the versions that you need.

如果要在计算机上处​​理项目，则必须经过繁琐的过程来管理依赖项并停用版本，同时激活所需的版本。

This issue is compounded when it’s a whole team of developers working on the same project, and no two developers have the same configurations on their computer.

如果整个开发团队都在同一项目上工作，并且没有两个开发人员在其计算机上具有相同的配置，则此问题会更加复杂。

With a container, you can simply put all your needed dependencies inside it and then work on your project from within the container. This saves a ton of a headache by eliminating the dependency management issues and instead providing us with an isolated area to work in.

使用容器，您可以简单地将所有需要的依赖项放入其中，然后从容器中进行项目。 通过消除依赖项管理问题，而为我们提供了一个隔离的工作区域，这省去了很多麻烦。

容器是如何制成的？ (How are containers made?)

So we now know what a container is. But how exactly do we create them?

现在我们知道了什么是容器。 但是我们如何精确地创建它们呢？

Well, to start we need to create an image. This is simply a package that includes all of the dependencies that should exist in our container. It’s a snapshot of everything that should be inside our container when we run it.

好吧，首先，我们需要创建一个图像。 这只是一个包，其中包含应该存在于我们容器中的所有依赖项。 它是运行容器时应包含在容器中的所有内容的快照。

An easy way to visualize this is to think of an image as a class and a container as an object that is instantiated from that class. So our image will serve as a blueprint for creating our containers, and we can create any number of identical containers from the same image.

一种简单的可视化方法是将图像视为一个类，将容器视为从该类实例化的对象。 因此，我们的图像将用作创建容器的蓝图，并且我们可以从同一图像中创建任意数量的相同容器。

如何构建图像？ (How are images built?)

Images are built by executing a set of commands. In Docker, the set of commands are written in a text file called Dockerfile.

通过执行一组命令来构建图像。 在Docker中，命令集被写入称为Dockerfile的文本文件中。

When the image build process starts, each command forms a layer that comprises the final image. The last layer specifies what command to run within a container when a container is started.

当映像构建过程开始时，每个命令形成一个包含最终映像的层 。 最后一层指定启动容器时在容器中运行什么命令。

In SpaceCraft, we bundled a modified version of Ubuntu, our language runtimes, and a copy of our application code into an image to start multiple containers that each run an instance of our application.

在SpaceCraft中 ，我们将Ubuntu的修改版 ，语言运行时和应用程序代码的副本捆绑到一个映像中，以启动多个容器，每个容器都运行我们的应用程序实例。

Images do not necessarily need to be stored or built on just your local machine. Containers are meant to be deployable anywhere and thus we should be able to access our images from any physical machine. This is accomplished through registries, which are essentially a place to remotely store and access images.

图像不必仅在本地计算机上存储或构建。 容器可以在任何地方部署，因此我们应该能够从任何物理机访问映像。 这是通过注册表完成的， 注册表实际上是远程存储和访问图像的地方。

为什么要使用容器？ (Why should we use containers?)

Now we can dive into the many use cases of containers.

现在，我们可以深入研究容器的许多用例。

Remember how we said that containers can provide us with an isolated box to hold a development environment with a specific set of dependencies? Each developer can simply download the needed image from a registry onto their local computer and then create a container from that image.

还记得我们怎么说容器可以为我们提供一个隔离的盒子来容纳具有特定依赖关系的开发环境吗？ 每个开发人员可以简单地将所需的图像从注册表下载到其本地计算机上，然后从该图像创建容器。

This way, they can start contributing to existing projects in no time.

这样，他们可以立即开始为现有项目做出贡献。

易于部署 (Ease of deployment)

As you can see, one of the biggest advantages of containers is that they are easily deployable on a variety of systems, due to their isolation. This allows developers to uncouple their software from their physical machines and launch a container from anywhere.

如您所见，容器的最大优点之一是，由于其隔离性，它们可以轻松部署在各种系统上。 这使开发人员可以将其软件与物理计算机脱钩，并从任何地方启动容器。

在一台机器上运行多种服务 (Run multiple services on one machine)

Another use case involves placing a single service in a container and then communicating with that service.

另一个用例涉及将单个服务放在容器中，然后与该服务进行通信。

In this situation, you can build a system that houses individual services in separate containers. This allows you to isolate each piece of your system architecture and run multiple services on the same host while making it easy to swap services in and out of your system as needed.

在这种情况下，您可以构建一个在单独的容器中容纳各个服务的系统。 这使您能够隔离系统架构的每个部分，并在同一主机上运行多个服务，同时可以轻松地根据需要在系统内外交换服务。

To demonstrate how this works, each service can communicate with each other through Docker container networking by their IP addresses. With this, containers can, for instance, send HTTP requests with the destination container’s IP address as part of the URL.

为了演示其工作原理，每个服务都可以通过Docker容器网络的IP地址相互通信。 这样，容器可以例如使用目标容器的IP地址作为URL的一部分发送HTTP请求。

In fact, we use this technique in SpaceCraft. We’ve built a reverse proxy server that forwards clients’ requests to the appropriate containers. To enable communication between our reverse proxy server and the containers, we retrieve the containers’ IP addresses during initialization and use them as destinations for proxying.

实际上，我们在SpaceCraft中使用了此技术。 我们已经建立了一个反向代理服务器 ，该服务器将客户的请求转发到适当的容器。 为了启用反向代理服务器和容器之间的通信，我们在初始化期间检索容器的IP地址，并将它们用作代理的目标。

安全隔离 (Isolation for Security)

Another important use case is that containerized applications are isolated from the host system. This prevents unwanted user access to the host’s file system. This is important, especially for an application like SpaceCraft that gives users the ability to execute code.

另一个重要的用例是容器化应用程序与主机系统隔离。 这样可以防止不必要的用户访问主机的文件系统。 这一点很重要，特别是对于像SpaceCraft这样的使用户能够执行代码的应用程序而言。

We can also add security measures to strengthen the isolation and further prevent malicious activity from reaching our host system. We’ll explore these strategies in the following section.

我们还可以添加安全措施来加强隔离，并进一步防止恶意活动进入我们的主机系统。 我们将在下一部分中探讨这些策略。

容器与虚拟机 (Containers versus Virtual Machines)

At this point, we want to make clear the distinction between containers and virtual machines, as this can heavily impact your decision on which to use.

在这一点上，我们想弄清楚容器与虚拟机之间的区别，因为这会严重影响您决定使用哪种容器。

Virtual machines came before containers, and were used to address the same pain points as containers. Essentially, they provide an isolated environment for services and development and are deployable on multiple systems.

虚拟机先于容器，然后用来解决与容器相同的难题。 本质上，它们为服务和开发提供了隔离的环境，并且可以在多个系统上部署。

However, there are some significant differences between them and containers.

但是，它们与容器之间存在一些显着差异。

容器更轻巧，旋转起来更快 (Containers are more lightweight, and faster to spin up)

First, containers are more lightweight in memory requirements than virtual machines. Depending on what you place in a container, they generally run in the tens to hundreds of MBs for memory size.

首先，容器在内存方面的需求比虚拟机轻。 根据您在容器中放置的内容，它们的内存大小通常在几十到几百MB之间。

Virtual machines are far heavier and run into the GBs. This is mainly due to one big inclusion: the operating system kernel.

虚拟机要重得多，并且要运行到GB中。 这主要是由于一个大的包容：操作系统内核。

Virtual machines contain not only all of your dependencies for your service or environment, but also a full copy of an operating system kernel to run all of your dependencies. This addition can add a lot of memory to an instance of a virtual machine.

虚拟机不仅包含您对服务或环境的所有依赖关系，而且还包含用于运行所有依赖关系的操作系统内核的完整副本。 此添加可以为虚拟机实例添加大量内存。

On the other hand, containers don’t contain a kernel and instead make system calls to the host system kernel. This dramatically lowers their memory footprint. It allows for more containers to be created and used on a system, as opposed to the number of virtual machines you can run on the same system.

另一方面，容器不包含内核，而是对主机系统内核进行系统调用。 这大大减少了他们的内存占用。 与可以在同一系统上运行的虚拟机数量相比，它允许在系统上创建和使用更多容器。

In addition to a smaller memory footprint, the lack of a kernel in a container makes their startup time a lot faster. Container startup can happen in seconds, whereas virtual machines will take much longer.

除了较小的内存占用空间外，容器中缺少内核也使其启动时间快得多。 容器启动可以在几秒钟内完成，而虚拟机则需要更长的时间。

虚拟机默认更安全 (VMs are more secure by default)

However, there are always tradeoffs. When it comes to virtual machines versus containers, the big tradeoff is security.

但是，总会有一些折衷。 在虚拟机与容器之间，最大的折衷是安全性。

Because containers need access to the host system kernel to make system calls, they are not as airtight on security as a virtual machine.

因为容器需要访问主机系统内核才能进行系统调用，所以它们在安全性方面不如虚拟机那么紧密。

In fact, resourceful malicious users can find ways to use this security disadvantage to break out of a container and gain access to the host system.

实际上，足智多谋的恶意用户可以找到利用此安全缺陷的方法来突破容器并获得对主机系统的访问权限。

With virtual machines, this risk is mitigated because each instance of a virtual machine contains a kernel for its system calls. Thus there is stronger isolation between a virtual machine and the host system than with a container.

使用虚拟机，由于虚拟机的每个实例都包含一个用于其系统调用的内核，因此可以减轻这种风险。 因此，虚拟机与主机系统之间的隔离度比容器高。

However, the security risks of containers can be addressed by implementing a few security measures that we incorporated into SpaceCraft, which we will look at now.

但是，可以通过实施我们纳入到SpaceCraft中的一些安全措施来解决容器的安全风险，我们现在将对其进行研究。

安防措施 (Security measures)

One huge security issue that you should know about is that users generally run as root users in containers by default.

您应该知道的一个巨大的安全问题是，默认情况下，用户通常在容器中以root用户身份运行。

This means that anyone who works inside a container, whether a developer on your team or a user who is using an application that is housed in a container on the back end, will have privileged access to the container file system.

这意味着在容器内工作的任何人，无论您的团队中的开发人员还是正在使用后端容器中包含的应用程序的用户，都将有权访问容器文件系统。

If you’re concerned about giving this level of control over to the container user, then you should consider ways to limit their privileges.

如果您担心将这种级别的控制权交给容器用户，则应考虑限制其特权的方法。

This issue can be addressed by creating an unprivileged user profile in the container filesystem, and having users run as that user profile while in the container.

可以通过在容器文件系统中创建非特权用户配置文件并让用户在容器中作为该用户配置文件运行来解决此问题。

This will restrict their ability to access the container filesystem and run commands that could harm your container environment and any services running inside it.

这将限制他们访问容器文件系统和运行可能损害容器环境以及其中运行的任何服务的命令的能力。

Another security issue that can rear its head is the ability for users to break out of containers and access the file system of the host system.

另一个可能引起人们注意的安全问题是用户能否脱离容器并访问主机系统的文件系统。

As we mentioned before, containers make system calls to the host system kernel in order to run processes. This opens the door for malicious users to break out of a container and attach the host system.

如前所述，容器对主机系统内核进行系统调用以运行进程。 这为恶意用户打开容器并连接主机系统打开了大门。

One of the methods we use to prevent this situation is to use a container runtime sandbox to intercept the system calls made by a container. The sandbox acts as a guest kernel and creates a strong level of isolation between the container and host kernel. This prevents malicious users from attacking our host system.

我们用来防止这种情况的方法之一是使用容器运行时沙箱来拦截容器进行的系统调用。 沙箱充当来宾内核，并在容器和主机内核之间创建高度隔离。 这样可以防止恶意用户攻击我们的主机系统。

If you’re interested in using a container runtime sandbox, check out gVisor which is an open-source solution provided by Google that we utilized with SpaceCraft.

如果您有兴趣使用一个容器运行时沙盒，检查出gVisor这是我们与使用谷歌提供的开源解决方案的航天器 。

容器资源控制 (Container resource control)

One more issue that we want to address pertains to potential abuse of a container’s resources.

我们要解决的另一个问题与容器资源的潜在滥用有关。

Since a container runs on a host system and uses the host kernel, it essentially consumes CPU and memory resources from the host system to complete its processes and tasks.

由于容器在主机系统上运行并使用主机内核，因此它实际上会消耗主机系统中的CPU和内存资源以完成其过程和任务。

While this is usually not a problem on an individual level with developers using containers, it does become a bigger problem once we use containers to deploy applications to be used by external users.

尽管对于使用容器的开发人员而言，这通常不是单个问题，但是一旦我们使用容器来部署供外部用户使用的应用程序，这确实成为一个更大的问题。

Let’s say that your system architecture includes using containers to run separate instances of your application that users can access. And something happens with one of those containerized instances that requires more CPU and memory from the host system than expected.

假设您的系统架构包括使用容器来运行用户可以访问的应用程序的单独实例。 这些容器化实例之一发生了一些事情，这些问题需要主机系统提供比预期更多的CPU和内存。

What this can result in is that one instance hogs system resources away from the other instances which causes their performances to drop and create a poor user experience.

这可能会导致一个实例将系统资源浪费在其他实例之外，从而导致其性能下降并带来不良的用户体验。

Obviously, this is a situation that we want to avoid if possible. Thankfully we can do so with cgroups, which is short for ‘control groups’.

显然，这是我们希望避免的情况。 幸运的是，我们可以使用cgroups做到这一点，而cgroups是“控制组”的缩写。

With cgroups, you can limit the amount of system resources used by a container and thereby prevent the situation we just described.

使用cgroups，可以限制容器使用的系统资源量，从而避免我们刚才描述的情况。

For example, you can set the cgroups on a container to be a maximum of 100MB of memory and 20% of CPU. With those limits set, that container will never be able to use more than 100MB of memory or utilize more than 20% of CPU from the host system for its lifetime. You can rest easy knowing that the performance of your other containerized application instances will not drop.

例如，您可以将容器上的cgroup设置为最大100MB内存和20％CPU。 设置了这些限制后，该容器在其生命周期内将永远无法使用超过100MB的内存或使用主机系统中超过20％的CPU。 您可以放心地知道其他容器化应用程序实例的性能不会下降。

In SpaceCraft, we utilized cgroups to limit the maximum amount of memory and CPU that a single session can consume. If a session happens to run an expensive computation and consume all available resource within that container, only that session will be affected.

在SpaceCraft中，我们利用cgroups限制了单个会话可以消耗的最大内存和CPU数量。 如果会话恰巧运行昂贵的计算并消耗了该容器中的所有可用资源，则仅该会话将受到影响。

我可以从哪里开始？ (Where can I get started?)

There are many container services that you can choose from. We used Docker for SpaceCraft due to its ease of use and excellent documentation. We highly recommend it for your next project.

您可以选择许多容器服务。 由于其易用性和出色的文档，我们将Docker用于SpaceCraft 。 我们强烈建议您在下一个项目中使用它。

Other options include:

其他选项包括：

• Redhat OpenShift
  红帽OpenShift
• Amazon EC2 Container Service
  Amazon EC2容器服务
• AWS Elastic Container Registry
  AWS Elastic Container Registry
• Google Cloud Container Registry
  Google云端容器注册表
• Azure Kubernetes
  Azure Kubernetes
• HashiCorp
  哈希公司
• Quay
  码头

与Node.js集成 (Integration with Node.js)

If you use Node.js primarily for your development, Dockerode can help you to interact with Docker from within a Node.js environment. We leveraged Dockerode to help us perform some important container actions, including:

如果您主要在开发中使用Node.js， 那么Doc​​kerode可以帮助您从Node.js环境中与Docker进行交互。 我们利用Dockerode帮助我们执行了一些重要的容器操作，包括：

• Starting and destroying a container
  启动和销毁容器
• Reading a container’s IP address
  读取容器的IP地址
• Placing limits on a container’s memory and CPU usage
  限制容器的内存和CPU使用率

Those operations are important to help us handle multiple sessions and scale our application.

这些操作对于帮助我们处理多个会话并扩展应用程序非常重要。

结论 (Conclusion)

Containers are an extremely useful tool in your arsenal as a software developer to simplify and speed up your project deployment.

容器作为软件开发人员，在您的工具库中是一个非常有用的工具，可简化并加速您的项目部署。

Whether it’s creating an isolated development environment for building projects, setting up a microservices architecture, or helping to onboard a new team member, the utility of containers continues to grow over time. Give it a try in your next project and see how they can benefit you!

无论是创建用于构建项目的隔离开发环境，建立微服务架构还是帮助新的团队成员，容器的实用性都会随着时间的推移而不断增长。 在您的下一个项目中尝试一下，看看它们如何使您受益！

If you enjoyed reading this article, we’ve also written a detailed case study on how we built SpaceCraft and the challenges that we faced. You can read it here.

如果您喜欢阅读本文，我们还写了一篇 详细的案例研究，说明了我们如何构建“太空飞船”以及我们面临的挑战。 您可以在这里阅读 。

Co-written by Julius, Gooi, and Nick of the SpaceCraft Team.

由航天飞机小组的朱利叶斯，古埃和尼克共同撰写。

参考文献 (References)

- What is a container- I am a Developer: why should I use Docker?- Docker Security Best-Practices- Open-sourcing gVisor, a sandboxed container runtime- Why it is recommended to run only one process in a container?- Processes In Containers Should Not Run As Root- Security and Virtual Machines

- 什么是容器 - 我是开发人员：为什么应该使用Docker？ -Docker 安全最佳实践 - 开源gVisor，一个沙盒容器运行时 - 为什么建议在容器中仅运行一个进程？ - 容器中的进程不应作为根运行 - 安全和虚拟机

翻译自: https://www.freecodecamp.org/news/a-practical-guide-to-containers-dfa66d37ac30/

web容器 ejb容器