在ECS上对jenkins进行容器化部署比在EC2实例中运行jenkins来保护管道信息更好吗？

Question

我是AWS码头和詹金斯的新手。我想运行jenkins构建管道，我尝试在AWS上使用以下两种方法：

1. 在EC2实例中运行jenkins，按照这个AWS 链接上的步骤执行。我创建了一个新的EC2实例，并将jenkins安装在ec2实例中(ssh到实例中)。我配置了jenkins并成功地运行了一个构建管道。
2. 按照这个AWS链路上的步骤在ECS集群中运行jenkins。我为Jenkins和数据卷创建了两个容器实例，jenkins在其中一个实例中安装并运行。(由于无法找到jenkins的初始密码，我无法推进这一点)

在互联网上，我找不到太多关于集装箱部署的第二个过程的信息。当我在这个过程中前进时，我无法理解哪个进程更好地安全地运行构建管道。

Answer 1

在EC2上运行Jenkins是更好的选择。最好将管理容器的函数与容器本身分开。我知道这和库伯内特斯不一样，但这不是库伯内特斯。

在EC2上构建一个ELK，并将您的构建日志发送到该实例，这样您就可以在故障排除时查看它们。听起来你的设置很好的处理数据卷之类的东西。不过，我建议您对员工使用Fargate而不是EC2节点。不清楚你在用哪种。

还有比Jenkins更简单的解决方案。您可能需要考虑CircleCI、GitLab Runner、TeamCity、竹类等。詹金斯被要求做所有的事情，是一个学习过程的好地方，但如果另一种方法做得同样好，而且更容易，那就试试吧。我现在最喜欢的是GitLab跑步者。它只是简单，它集成了你的Git回购与CI工具，除了有自己的图像回购供您使用(在某些版本)。

你也可以给EKS一个机会。我还没试过，但是库伯奈特斯是个很好的产品。它要复杂得多，但绝对是一个更好的编排工具。

Answer 2

还有其他选择-- EC2上的容器是我们要做的。他们说，许多人对ECS不感兴趣，EKS正逐渐成熟，成为更好的替代方案。

如果不将持久配置视为一个大型的持久文件系统，就很难真正开发当前的Jenkins。在您安装了作业、插件、凭据和配置之后，您还可以维护整个指定的存储文件系统，将其备份到S3，并在您运行对接程序时将其附加到容器中。此实践独立于容器业务流程选择。

另一个困扰我们的问题是/正在维护构建日志。Jenkins电子邮件以纯文本构建日志，但我还没有弄清楚如何将它们发送到一个文件系统，在调试时我可以通过这些文件系统实现grep。我们目前的做法只值几个星期。也许我漏掉了什么？请纠正我！

有一个新的JenkinsX针对库伯内特斯，但还没有准备好在2019年2月。

也就是说，在GitHub中保持jenkinsfiles的工作非常有效。