magento_在kubernetes第2部分中运行magento2构建Docker映像

magento

前言 (Preface)

This article explains how to build a Docker image from scratch or existing projects in three simple steps. It starts with an overview for readers whose daily work might not be related to build pipelines and deployment processes. For admins and seniors, who already opened their shell, jump to the “DevOps time” chapter to get the practical takeaway of the article.

本文介绍了如何通过三个简单步骤从头开始或现有项目中构建Docker映像。 它从读者的概述开始，这些读者的日常工作可能与构建管道和部署过程无关。 对于已经打开外壳的管理员和前辈，请转至“ DevOps时间 ”一章以实际了解本文。

构建和部署 (Build and deploy)

Docker has two critical phases: An image build phase and the startup of the container. Usually they are timely and physically separated. The build process runs on a build server (Gitlab, Jenkins). Generated images are pushed to a Docker registry (e.g. Gitlab, Google Container Registry or Docker Hub). On deployment they get pulled from the registry on the target machine.

Docker有两个关键阶段：映像构建阶段和容器启动。 通常他们是及时的，身体上分开的。 构建过程在构建服务器(Gitlab，Jenkins)上运行。 生成的图像被推送到Docker注册表(例如Gitlab，Google Container Registry或Docker Hub)。 在部署时，它们会从目标计算机上的注册表中拉出。

什么是Magento构建过程？ (What is a Magento build process?)

Back in the days of Magento1 a build phase basically didn’t exist. Magento1 did everything for the developers (like merging CSS and JS files) on the fly. When Less/Sass became more popular some developers started to use Grunt to compile their CSS and minify JavaScript files. The cool kids even used Composer and Modman to install dependencies and libraries. Some of these steps could be already considered as “build phase”. They installed dependencies and prepared the code in the Git repository for optimal execution in a production environment.

在Magento1的年代，基本上不存在构建阶段。 Magento1即时为开发人员完成了所有工作(例如合并CSS和JS文件)。 当Less / Sass变得更流行时，一些开发人员开始使用Grunt来编译他们CSS并最小化JavaScript文件。 很棒的孩子甚至使用Composer和Modman来安装依赖项和库。 其中一些步骤可能已经被视为“构建阶段”。 他们安装了依赖项，并在Git存储库中准备了代码，以在生产环境中实现最佳执行。

When switching from developer to production mode (bin/magento deploy:mode:set production) at least setup:di:compile and setup:static-content:deploy get executed. The Magento DevDocs has a diagram which explains the detailed steps. It also mentions the configuration as an important ingredient for Magento’s build phase. In our approach the last step of the process „Check the compiled and static view files into repository” is the phase where the built Docker image is saved in the Docker registry.

从开发人员切换到生产模式( bin / magento deploy：mode：set production )时，至少要执行setup：di：compile和setup：static-content：deploy 。 Magento DevDocs的图表说明了详细步骤。 它还提到该配置是Magento构建阶段的重要组成部分。 在我们的方法中，过程的最后一步“ 将已编译的静态视图文件和静态视图文件检入到存储库中 ”是将构建的Docker映像保存在Docker注册表中的阶段。

如何配置您的构建阶段？ (How to configure your build phase?)

Since Magento 2.1 a database connection isn’t necessary anymore to run SCD (static content deployment). This is possible by adding information about stores, settings and modules to the “shared configuration”, located at app/etc/config.php. In the build phase also Composer dependencies get resolved based on the composer.lock file.

从Magento 2.1开始，运行SCD(静态内容部署)不再需要数据库连接。 通过将有关存储，设置和模块的信息添加到位于pp / etc / config.php的“共享配置”中，这是可能的。 在构建阶段，还将基于c omposer.lock文件解析Composer依赖项 。

There are several approaches to execute all these steps in an automated way. Some developers prefer Capistrano and other “zero downtime” scripts to execute the build phase on the target system before switching the symlink of the web root. Magento provides a tool which is rarely mentioned outside of the Magento Cloud documentation although it is available on Github already since three years: The Magento Commerce Cloud Deployment Tools, in short: ECE-Tools. With the 2002.1 release in February ECE-Tools introduced “scenarios” which allows easy customization and enhancements of each step. We highly recommend ECE-Tools as it provides much of what is needed to configure the Docker build and deploy process.

有几种方法可以自动执行所有这些步骤。 一些开发人员更喜欢Capistrano和其他“零停机时间”脚本来在切换Web根目录的符号链接之前在目标系统上执行构建阶段。 Magento提供了一个在Magento Cloud文档之外很少提及的工具，尽管该工具自三年以来就已经在Github上提供：Magento Commerce Cloud部署工具，简称： ECE-Tools 。 在2月的2002.1版本中，ECE-Tools引入了“ 场景 ”，可以轻松自定义和增强每个步骤。 我们强烈推荐ECE-Tools，因为它提供了配置Docker构建和部署过程所需的大部分功能。

The ECE-Tools documentation might look a bit confusing at first, since it is woven into the Magento Cloud documentation, but it helps to understand how to configure themes and languages (see https://devdocs.magento.com/cloud/project/magento-env-yaml.html) and how to export your website and store configuration (see https://devdocs.magento.com/cloud/live/sens-data-over.html). But lean back, we’ll make the usage of ECE-Tools easy for you!

由于ECE-Tools文档已编入Magento Cloud文档，因此起初可能看起来有些混乱，但它有助于了解如何配置主题和语言(请参阅h ttps：//devdocs.magento.com/cloud/project /magento-env-yaml.html)以及如何导出网站和存储配置(请参阅h ttps：//devdocs.magento.com/cloud/live/sens-data-over.html) 。 但是向后倾斜，我们将为您简化ECE-Tools的使用！

部署阶段 (The deployment phase)

For Magento2 there is one, maybe two important commands executed during deployment: The predominant is bin/magento setup:upgrade –keep-generated to update the database. The other one, which is maybe less known, is app:config:import. It imports the shared configuration file into the database which is very powerful if you want to maintain Magento’s configuration in Git. This command can even create new stores and websites – or remove them.

对于Magento2，在部署期间执行一个，也许两个重要的命令：主要是bin / magento setup：upgrade-保持生成以更新数据库。 另一个可能不太为人所知的是app：config：import 。 它将共享的配置文件导入数据库，如果您想在Git中维护Magento的配置，该文件将非常强大。 该命令甚至可以创建新的商店和网站-或将其删除。

Putting these two commands in a Docker startup script could already do the job, but ECE-Tools does much more for you: If there are no tables in the database it starts Magento’s installation routine which sets a base domain, creates an admin user etc. It creates and updates the app/etc/env.php from environment variables. The command also flushes the cache and can take care of basic cache heating after the deployment has completed. For convenience there are lot of little commands executed, check the deploy scenario for details.

将这两个命令放在Docker启动脚本中已经可以完成这项工作，但是ECE-Tools可以为您做更多的工作：如果数据库中没有表，它将启动Magento的安装例程，该例程设置基本域，创建admin用户等。它从环境变量创建和更新app / etc / env.php 。 该命令还刷新缓存，并可以在部署完成后处理基本的缓存加热。 为了方便起见，执行了许多小命令，请查看部署方案以了解详细信息。

When executing this standard scenario on container start in an environment with multiple instances it can become troublesome: Because ECE-Tools enables the maintenance mode when starting the setup:upgrade command, your site might be unreachable several times. The maintenance mode puts a file in the var folder, which has to be shared across all Magento instances, and therefore shuts down all running instances at once. Flushing the cache every time the number of Magento instances is scaled up can become a nightmare on traffic peaks. We tried to balance consistency, zero-downtime and production issues in our modified scenarios, which will get explained in another article when talking about K8S deployment.

在具有多个实例的环境中在容器启动时执行此标准方案时，可能会变得很麻烦：由于ECE-Tools在启动setup：upgrade命令时启用了维护模式，因此您的站点可能多次无法访问。 维护模式将文件放入var文件夹，该文件必须在所有Magento实例之间共享，因此会立即关闭所有正在运行的实例。 每当Magento实例的数量增加时，刷新缓存都会成为流量高峰​​的噩梦。 我们试图在修改后的场景中平衡一致性，零停机时间和生产问题，这将在另一篇有关K8S部署的文章中进行解释。

项目布局 (Project layout)

Each command in a Dockerfile creates a new layer in the image’s filesystem. Docker caches them to re-use it on the next build if the files and the command hasn’t changed. Magento Commerce Cloud projects require to have the Magento source code in the Git repository root. To leverage Docker’s build cache on simple configuration changes it is beneficial to move config files out of the Magento root directory. We therefore recommend to move Magento to a “src” directory and keep the container and deployment related files outside of it.

Dockerfile中的每个命令都会在映像的文件系统中创建一个新层。 如果文件和命令未更改，则Docker缓存它们以在下一个版本上重新使用它。 Magento Commerce Cloud项目需要在Git存储库根目录中具有Magento源代码。 要将Docker的构建缓存用于简单的配置更改，将配置文件移出Magento根目录是有益的。 因此，我们建议将Magento移至“ src ”目录，并将容器和与部署相关的文件保留在该目录之外。

Frankly, we use both project layouts for client projects, but the afore mentioned is recommended as the build time is much faster on simple K8S adjustments. You can keep the existing layout but will have to adjust some paths in the bundled files described in the next chapter.

坦率地说，我们将两种项目布局都用于客户项目，但建议使用上述布局，因为在简单的K8S调整中，构建时间要快得多。 您可以保留现有布局，但是必须调整下一章中描述的捆绑文件中的某些路径。

DevOps时间 (DevOps time)

After all the theory let’s get practical and see it all in action.

毕竟，理论让我们开始实践起来，看看它们在起作用。

步骤1：安装Magento2或准备现有项目 (Step 1: Install Magento2 or prepare your existing project)

First, install Magento via composer:

首先，通过作曲家安装Magento：

composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition src

The command will take several minutes. When finished Magento’s source code is installed in the src directory.

该命令将花费几分钟。 完成后，将Magento的源代码安装在src目录中。

For existing projects move them to a src directory to follow the next steps in this tutorial:

对于现有项目，将它们移动到src目录，以遵循本教程中的后续步骤：

export MAGENTO_ROOT="$(pwd)"
cd ..
mkdir magento-project
mv $MAGENTO_ROOT magento-project/src
cd magento-project
unset $MAGENTO_ROOT

步骤2：安装Docker构建工具 (Step 2: Install the Docker build tools)

For convenience we bundled our Docker build tools in a Composer package. To install it switch to the src directory and execute:

为了方便起见，我们将Docker构建工具捆绑在Composer软件包中。 要安装它，请切换到src目录并执行：

composer require phoenix-media/magento2-cloud-build --no-update
composer update

This will install a Dockerfile, some helper scripts, basic configuration files (for nginx, PHP, Supervisord), Magento’s ECE-Tools and our enhanced ECE-Tools deployment scenarios. For package details visit https://github.com/PHOENIX-MEDIA/magento2-cloud-build.

这将安装一个Dockerfile，一些帮助脚本，基本配置文件(用于nginx，PHP，Supervisord)，Magento的ECE-Tools和我们增强的ECE-Tools部署方案。 有关软件包的详细信息，请访问https://github.com/PHOENIX-MEDIA/magento2-cloud-build 。

Since Composer doesn’t execute shell commands automatically execute this command to copy the sample files to their target location:

由于Composer不会执行shell命令，因此会自动执行以下命令将示例文件复制到其目标位置：

vendor/bin/px-cloud-build-install

Your project root should now have the following file structure:

您的项目根目录现在应该具有以下文件结构：

.dockerignore
.gitignore
Dockerfile
bin
docker
docker-compose.yml
helm
src

You most likely want to customize these files and src/bin/deploy for each project. The intention of the Composer package is to help you installing and update the files. A simple git diff will help you to identify necessary changes after you pulled a new version of the package and executed vendor/bin/px-cloud-build-install.

您最有可能想要自定义这些文件，并为每个项目定制src / bin / deploy 。 Composer软件包的目的是帮助您安装和更新文件。 简单的git diff可以帮助您在拉出新版本的软件包并执行vendor / bin / px-cloud-build-install之后确定必要的更改。

If you have an existing project it is recommended to do three things now:

如果您有现有项目，建议立即做三件事：

1. Execute vendor/bin/ece-tools config:dump in an environment with a recent database. It will write store configuration and settings about SCD to app/etc/config.php. Add it to the Git repo. Having this information is important for the ECE-Tool’s build and deployment process.

1.在具有最新数据库的环境中执行vendor / bin / ece-tools config：dump 。 它将关于SCD的存储配置和设置写入app / etc / config.php 。 将其添加到Git仓库中。 拥有此信息对于ECE-Tool的构建和部署过程很重要。

2. Review src/.magento.env.yaml, especially the SCD_MATRIX regarding themes and languages. Without listing your theme, it won’t be generated during SCD execution which will cause errors in the frontend later.

2.查看src / .magento.env.yaml ，尤其是有关主题和语言的SCD_MATRIX 。 如果不列出您的主题，它将不会在SCD执行期间生成，这将在以后导致前端错误。

3. Compare the .gitignore file in the Magento root with the one which just has been installed to the project root to make sure it fits your needs.

3.将Magento根目录中的.gitignore文件与刚刚安装到项目根目录中的文件进行比较，以确保它适合您的需求。

One important note: Although some developers might consider this as a sacrilege, at PHOENIX MEDIA we prefer to commit the vendor directory to the Git repo. This helps to trace all code changes on updates and it will also speed up build time of the Docker container. But it is just a matter of taste and philosophy. If you prefer to not have the Composer packages in Git just remove the exclamation mark in .gitignore for these two lines:

重要提示 ：尽管有些开发人员可能将其视为牺牲品，但在PHOENIX MEDIA，我们更愿意将供应商目录提交到Git存储库。 这有助于跟踪更新时的所有代码更改，还可以加快Docker容器的构建时间。 但这只是品味和哲学问题。 如果您不希望Git中包含Composer软件包，只需删除.gitignore中这两行的感叹号：

!/**/vendor
!/src/update/vendor

步骤3：收拾行装 (Step 3: Pack your bags)

The Dockerfile uses phoenixmedia/nginx-php. It is an Alpine based Docker image which installs PHP, nginx, Postfix and Supervisord, to start all daemons in parallel. The image has only half the size of the official PHP image and supports PHP 7.2–7.4. You can change the PHP version by simply editing the image tag in the Dockerfile located in the project root.

Dockerfile使用phoenixmedia / nginx-php 。 这是一个基于Alpine的 Docker映像，它安装PHP，nginx，Postfix和Supervisord来并行启动所有守护程序。 该映像只有官方PHP映像的一半大小，并支持PHP 7.2–7.4。 您可以通过简单地在项目根目录下的Dockerfile中编辑image标签来更改PHP版本。

Before you start the build in the next step make sure you have a local Docker instance running. We recommend to configure it for 4 cores and 4 GB memory — or more.

在下一步开始构建之前，请确保您正在运行本地Docker实例。 我们建议为4核和4 GB内存(或更多)配置它。

Now you should be good to build your first Magento container. You have the option to just build the container with “docker build .” or to directly build and run it with “docker-compose up”. Once finished check the running instance in the browser: http://localhost. Carefully read the output and verify there are no errors.

现在，您应该可以构建第一个Magento容器了。 您可以选择仅使用“ docker build。 ” 构建容器。 ”或使用“ docker-compose up ”直接构建并运行它。 完成后，在浏览器中检查正在运行的实例： http：// localhost。 仔细阅读输出并确认没有错误。

In case you need to adjust something just start over by executing “docker-compose down -v --rmi local” and “docker-compose up” again.

如果您需要调整某些内容，只需重新执行“ docker-compose down -v --rmi local ”和“ docker -compose up ”即可重新开始。

环境和神秘变量 (Environments and mysterious variables)

When investigating the bundled docker-compose.yml file, you will notice that the container requires three environment variables:

在调查捆绑的docker-compose.yml文件时，您会注意到该容器需要三个环境变量：

- MAGENTO_CLOUD_ROUTES
- MAGENTO_CLOUD_VARIABLES
- MAGENTO_CLOUD_RELATIONSHIPS

They provide information for the “vendor/bin/ece-tools deploy” command to generate app/etc/env.php during container startup. You can google for the environment variables, but you won’t find much details about their values. The Magento Cloud documentation just gives a hint: It is a base64-encoded JSON object used to provide service configuration and credentials.

它们为“ vendor / bin / ece-tools deploy ”命令提供了信息，以在容器启动期间生成app / etc / env.php 。 您可以在Google上搜索环境变量，但是找不到有关它们的值的详细信息。 Magento Cloud文档只是提供了一个提示：它是用于提供服务配置和凭据的base64编码的JSON对象。

Use this command to decode the example value of MAGENTO_CLOUD_VARIABLES:

使用此命令来解码MAGENTO_CLOUD_VARIABLES的示例值：

echo "yJBRE1JTl9GSVJTVE5BTUUiOiJZb3VyIEZpcnN0bmFtZSIsIkFETUlOX0xBU1ROQU1FIjoiWW91ciBMYXN0bmFtZSIsIkFETUlOX0VNQUlMIjoiYWNjb3VudEBtYWlsLmNvbSIsIkFETUlOX1VTRVJOQU1FIjoiYWRtaW5pc3RyYXRvciIsIkFETUlOX1BBU1NXT1JEIjoidG9wQFNlY3JlMSIsIkFETUlOX1VSTCI6ImFkbWluIiwiQ1JZUFRfS0VZIjoiNmZnMzdqYzUyOWUwZDlmMDY5NjY1Y2JjOWZlMTcwYjIifQ" | base64 -d

Output:

输出：

{
  “ADMIN_FIRSTNAME”: “Your Firstname”,
  “ADMIN_LASTNAME”: “Your Lastname”,
  “ADMIN_EMAIL”: “account@mail.com”,
  “ADMIN_USERNAME”: “administrator”,
  “ADMIN_PASSWORD”: “top@Secre1”,
  “ADMIN_URL”: “admin”,
  “CRYPT_KEY”: “6fg37jc529e0d9f069665cbc9fe170b2”
}

And another one for MAGENTO_CLOUD_RELATIONSHIPS:

还有另一个用于MAGENTO_CLOUD_RELATIONSHIPS ：

echo "eyJkYXRhYmFzZSI6W3siaG9zdCI6Im15c3FsIiwicGF0aCI6Im1hZ2VudG8iLCJwYXNzd29yZCI6InRvcFNlY3JldCIsInVzZXJuYW1lIjoibWFnZW50byIsInBvcnQiOiIzMzA2In1dLCJyZWRpcyI6W3siaG9zdCI6InJlZGlzIiwgInBvcnQiOiAiNjM3OSJ9XSwiZWxhc3RpY3NlYXJjaCI6W3siaG9zdCI6ImVsYXN0aWNzZWFyY2giLCAicG9ydCI6ICI5MjAwIiwgInNjaGVtZSI6Imh0dHAifV0sInJhYmJpdG1xIjpbeyJob3N0IjoicmFiYml0bXEiLCAidXNlcm5hbWUiOiJwaG9lbml4IiwgInBhc3N3b3JkIjoiTWFnZW50bzEyMyIsICJzY2hlbWUiOiJhbXFwIiwgInBvcnQiOiAiNTY3MiJ9XX0=" | base64 -d

Output:

输出：

{
  “database”: [
    “host”: “mysql”,
    “path”: “magento”,
    “password”: “topSecret”,
    “username”: “magento”,
    “port”: “3306”
  }],
  “redis”: [{
    “host”: “redis”,
    “port”: “6379”
  }],
  “elasticsearch”: [{
    “host”: “elasticsearch”,
    “port”: “9200”,
    “scheme”: “http”
  }],
  “rabbitmq”: [{
    “host”: “rabbitmq”,
    “username”: “phoenix”,
    “password”: “Magento123”,
    “scheme”: “amqp”,
    “port”: “5672”
  }]
}

You can modify these values and base64 encode them again. Those values will be later stored in a Kubernetes Secret and injected into the pod.

您可以修改这些值，并再次对base64进行编码。 这些值将稍后存储在Kubernetes Secret中，并注入到pod中。

下一步是什么？ (What’s next?)

After everything is working commit all files to Git. To trigger the Docker build process on every commit you should include it in your build Pipeline. The image can then be pushed to a registry. Gitlab users find a great tutorial in the documentation. Google Cloud users can follow this steps: https://cloud.google.com/cloud-build/docs/building/build-containers.

一切正常后，将所有文件提交到Git。 要在每次提交时触发Docker构建过程，应将其包含在构建管道中。 然后可以将映像推送到注册表。 Gitlab用户可以在文档中找到相关的教程。 Google Cloud用户可以执行以下步骤：h ttps：//cloud.google.com/cloud-build/docs/building/build-containers。

From there we’ll continue in the next article and lay the foundation for the Kubernetes deployment. Meanwhile get familiar with some K8S concepts and evaluate options to setup a K8S cluster.

从那里开始，我们将继续下一篇文章，并为Kubernetes部署奠定基础。 同时，熟悉一些K8S概念并评估设置K8S集群的选项。

摘要 (Summary)

Magento’s ECE-Tools is a set of powerful modules to streamline build and deployment processes. It has a steep learning curve, but it is recommended to get familiar with it if you plan work with Magento Commerce Cloud or the approach described in this series.

Magento的ECE-Tools是一组功能强大的模块，可简化构建和部署过程。 它具有陡峭的学习曲线，但是如果您计划使用Magento Commerce Cloud或本系列中介绍的方法，建议您熟悉它。

The magento2-cloud-build Composer package provides all necessary files to build and run existing projects in a Docker container. The build and deployment will require adjustments to meet project requirements.

magento2-cloud-build Composer软件包提供了在Docker容器中构建和运行现有项目的所有必需文件。 构建和部署将需要进行调整以满足项目要求。

We appreciate your valuable feedback and looking forward to contributions to our Github repos.

感谢您提供宝贵的反馈意见，并期待为我们的Github回购做出贡献。

Continue reading:

继续阅读：

• Running Magento2 in Kubernetes — Part 1: Basic concepts and best practices

  在Kubernetes中运行Magento2 —第1部分：基本概念和最佳实践

• Running Magento2 in Kubernetes —

  在Kubernetes中运行Magento2 —

  Part 2: Building the Docker image (this article)

  第2部分：构建Docker映像(本文)

翻译自: https://medium.com/swlh/running-magento2-in-kubernetes-part-2-building-the-docker-image-8516c0ed7d48

magento