摘要
有很多方法可以使用AppDynamics代理来检测Docker容器。 这里是一些在大型Docker环境中很好的最佳实践。 在本博客中，我将展示一些使用docker-compose和一些流行的AppDynamics应用程序代理类型来检测Docker容器的最佳实践。 这样做的目的是避免在代理升级时避免重建应用程序容器，或避免将AppDynamics配置硬编码到容器映像中。
作为AppDynamics生产环境上的DevOps工程师，我使用这些技术来简化我们的容器化部署。 我将介绍二进制代理（如Java代理）的安装，以及通过诸如Node.js或Python之类的存储库安装的代理。
在探讨最佳实践之前，让我们回顾一下最常见的部署模式-这根本不是最佳实践。
常见（但不是最佳实践）模式：在容器映像构建期间安装代理
我们将介绍的第一种方法是通过Dockerfile安装代理，作为应用程序容器构建的一部分。 这样做的好处是遵循常规做法，即轻松地在源文件中进行复制，并在Dockerfile中提供构建的透明性，从而使采用变得更简单，更直观。 但是，AppDynamics不建议使用此方法，因为每次代理程序需要升级时，它都需要重建应用程序映像的新副本。 这是低效且不必要的，因为代理不是应用程序代码的中心部分。 此外，当您使构建和部署自动化时，以这种方式对安装的代理进行硬编码可能会变得更加困难。
Java示例
在此用于安装Java代理的Dockerfile示例中，我们将二进制文件存储在AWS S3中，并仅在应用程序映像的构建期间通过代理进行复制。
Dockerfile片段：从S3复制
这是我们在本地复制代理的类似步骤。
Dockerfile代码段：本地复制
Node.js示例
在此示例中，我们使用npm在构建期间安装特定的Node.js代理版本。
Dockerfile代码段
Python示例
在此示例中，我们使用pip在构建期间安装特定的Python代理版本。
Dockerfile代码段
最佳实践模式：使用环境变量和Sidecar容器在运行时安装代理
以下示例根据代理类型涵盖两种不同的模式。 对于Java和类似打包的代理，我们将使用称为“ sidecar容器”的东西在容器运行时安装代理。 对于Node.js和Python等存储库安装的代理，我们将使用环境变量和启动脚本，这些脚本将在容器运行时安装代理。
Java示例
对于sidecar容器模式，我们使用要安装的代理二进制文件构建容器映像。 然后，我们将包含代理的目录卷安装，因此我们的应用程序容器可以在容器运行时复制代理，然后进行安装。 可以通过在sidecar容器中解压缩代理程序，将新包装的代理程序目录卷安装，然后使应用程序容器指向已安装卷的目录并将其用作其代理程序目录来简化此操作。 我们将在下面介绍两个示例，首先介绍如何创建sidecar容器或“ agent-repo”。
在Java代理的Dockerfile示例中，我们将二进制文件存储在AWS S3中（在特定于代理版本的存储桶中），并仅在构建期间复制该代理。 然后，我们将代理解压缩，从而允许我们将代理复制到应用程序容器中，然后解压缩，或者仅指向解压缩后的代理目录。 注意，我们使用了构建ARG，它允许使用构建脚本进行更自动化的构建。
代理回购Dockerfile：从S3复制
这是与上面相同的示例，但是我们在本地复制代理而不使用构建ARG的示例。
代理回购Dockerfile：本地复制
构建脚本利用构建ARG。 如果您使用的是上述S3模式，则可以传入您喜欢的代理版本。
build.sh
现在我们已经构建了sidecar容器映像，让我们介绍如何构建Java代理容器映像以利用该代理部署模式。 在下面的Docker片段中，我们复制了两个新脚本， extractAgent.sh和startup.sh 。 extractAgent.s h脚本将代理程序从卷安装目录/ sharedFiles /复制并提取到应用程序容器。 startup.sh脚本用作我们的ENTRYPOINT。 该脚本将调用extractAgent.sh并启动应用程序。
Java Dockerfile代码段
extractAgent.sh
startup.sh脚本（如下所示）调用extractAgent.sh ，该脚本将代理复制并解压缩到$ CATALINA_HOME目录中。 然后，在application-startup命令中，将该目录作为Java选项的一部分传入。
startup.sh代码段
在docker-compose.yml中 ，我们只需添加具有卷挂载的agent-repo容器即可。 我们的Tomcat容器引用了agent-repo容器和卷，但是也使用了依赖于代理的环境变量，因此我们不必编辑任何配置文件。 这使部署更加自动化和可移植/可重用。
docker-compose.yml
在下面的示例中，我们显示了另一种方法。 我们跳过了添加extractAgent.sh和startup.sh脚本的整个过程，而是选择复制自定义的catalina.sh脚本并将其用作我们的CMD。 此模式仍使用agent-repo sidecar容器，但指向$ CATALINA_OPTS的一部分，该卷挂载了未压缩的代理目录。
Java Dockerfile代码段
catalina.sh片段
好的，这涵盖了sidecar容器代理部署模式。 那么利用存储库安装代理的代理又如何呢？ 我们如何实现该过程的自动化，从而不必在每次要将代理升级到特定版本时都重建应用程序容器映像？ 答案很简单，与上面的示例相似。 我们添加一个startup.sh脚本（用作我们的ENTRYPOINT），然后使用docker-compose.yml中设置的环境变量来安装特定版本的代理。
Node.js示例
Dockerfile代码段
在复制的index.js中（上述Dockerfile片段中未显示），我们引用依赖于代理的环境变量，该变量在docker-compose.yml中设置。
index.js片段
在startup.sh脚本中，我们使用npm安装代理。 安装的版本取决于我们是否在docker -compose.yml中专门设置了$ AGENT_VERSION变量。 如果设置，将安装变量中设置的版本。 否则，将安装最新版本。
启动文件
在docker-compose.yml中 ，我们将$ AGENT_VERSION设置为要安装npm的代理版本。 我们还设置了依赖代理的环境变量，从而避免了对这些值进行硬编码。 这使部署更加自动化和可移植/可重用。
docker-compose.yml
Python示例
此示例与Node.js示例非常相似，不同之处在于，我们使用pip来安装代理。
Dockerfile代码段
在startup.sh脚本中，我们使用pip安装代理。 安装的版本取决于我们是否在docker -compose.yml中专门设置了$ AGENT_VERSION变量。 如果设置，将安装变量中设置的版本。 否则，将安装最新版本。
启动文件
在docker-compose.yml中 ，我们将$ AGENT_VERSION设置为我们希望pip安装的代理版本。 我们还设置了依赖代理的环境变量，从而避免了对这些值进行硬编码。 这使部署更加自动化和可移植/可重用。
docker-compose.yml
选择最佳模式
有很多方法可以使用AppDynamics代理来检测Docker容器。 我们已经介绍了一些模式，并显示了在管理大型Docker环境时对我的团队有效的方法。
在“ 通用模式” （但不是最佳实践）示例中，我展示了每次要升级代理版本时都必须重新构建应用程序容器的方法-这不是理想的方法。
但是，通过“ 最佳实践模式” ，您可以将代理程序的详细信息与应用程序容器映像分离开，并将该职责分配给sidecar容器和docker-compose环境变量。
只要有可能，自动化始终是一个值得追求的目标。 遵循最佳实践模式将使您能够改善脚本部署，利用版本控制和配置管理，并将它们全部插入CI / CD管道。
有关相关技术的深入信息，请阅读以下AppDynamics博客：
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
