释放DevOps !

DevOps的工具已经走过了很长的路。从开发和QA环境中的虚拟机到生产环境中的虚拟机，再到现在的Docker。我们越是被硬件作为代码的想法所吸引，我们就越是试图用它做一些疯狂的事情。取“不可变的服务器”模式作为一个例子。在2000年，因为配置的改变而丢弃一个非常好的服务器是多么疯狂的想法啊!今天，我们知道状态变化是不可维护的;它们是万恶之源，(感谢硬件作为代码)丢弃服务器而不是更改它是正确的做法。但是如果是不可变的数据中心？我是说，为什么不呢?这是顺理成章的下一步，不是吗?与其在每次配置更改时重新配置负责烘焙新服务器的任何东西(我指的是CI服务器、工件存储库和供应服务器)，为什么不将其丢弃并创建一个新的服务器呢?

(来源:https://martinfowler.com/bliki/ImmutableServer.html)

现在，从Artifactory 5开始，你就可以了!它可以完全由机器人自动化;不仅是基本操作(我们一直知道与Artifactory的95%的交互是由机器人完成的)，还包括供应、配置和退役。一个Artifactory服务器集群可以被拆分(包括许可证池管理)，配置正确的存储库、配置和权限，弹性伸缩，然后在销毁该数据中心(而不是更改该数据中心)(许可证将返回到池中重用)时终止。因此，以下是如何使用有效的许可证、自定义Base URL、Docker支持的反向代理和完全配置的存储库集来完全配置Artifactory的码头工人、npm、Maven和RPM。

你如何利用这种美呢?通过旋转一个Artifactory服务器，完成数据库，nginx和使用Docker Compose(或以任何其他方式启动Artifactory)的整个shebang这个yaml文件在你的$ ARTIFACTORY_HOME /等文件夹．很酷?超级酷!

谈到权限和安全，随着Artifactory越来越多地由机器人而不是人来管理，用户管理不再有意义。机器人没有电子邮件地址，也不能登录自己的个人资料修改密码。用户名和密码已成为过去，访问令牌是未来的发展趋势。它们足够灵活，可以包含所有许可信息，提供对正确资源的正确访问;它们根据使用和/或时间可被使用，它们由其他机器人为机器人创建、管理和销毁。这真是太酷了(也有点怪异)!

回到DevOps工具和作为代码的硬件的扩散，这个市场的两个主要参与者是Chef和Puppet。他们的菜谱和模块分别是创建服务器和完整数据中心的代码有关。它们是我们交付那些包含服务器的数据中心的管道的一部分，作为管道的一部分，它们必须与管道的其他部分相关联。例如，哪个服务器是由特定的烹饪书创建的。菜谱中的更改会导致服务器的更改，但通常还会添加其他更改。如何将jar文件的新版本(来自管道的Java构建部分)与该jar文件兼容的JDK新版本(来自烹饪书)关联起来?

将管道的所有这些部分放到一个工具中，就可以用可引用的元数据对它们进行注释。通过Artifactory 5.1及其对Chef cookbooks和Puppet模块的支持，您可以标记一个用新版本的JDK设置服务器的模块，该模块与生成需要该JDK版本的jar文件的java构建兼容。

神奇的是——你可以搜索它们。使用Artifactory查询语言您现在可以分离一个数据中心，该数据中心具有正确配置的CI服务器(slave具有正确的JVM版本)、正确配置的工件存储库(所有存储库都是预先配置的，并且生成了正确的访问令牌)和正确配置的服务器
对于管道的每个阶段，同样，使用正确生成的服务器和正确的JVM版本，所有这一切都只需要使用正确的Puppet模块或Chef烹饪书。如何知道哪些模块是正确的?通过查询Artifactory，根据目标环境提供正确的文件(模块、烹饪书、docker映像和应用程序文件)。

这是嗑了药的DevOps吗!