释放DevOps!

DevOps的工具走过了很长的路。从开发和QA环境中的虚拟机到生产环境中的虚拟机，再到现在的Docker。我们越是被硬件作为一种代码的想法所吸引，我们就越想用它做一些疯狂的事情。取“不可变服务器”模式举个例子。在2000年，仅仅因为配置改变就抛弃一台完美的服务器的想法是多么疯狂啊!今天，我们明白状态变化是不可维持的;它们是万恶之源，(多亏了硬件即代码)抛弃服务器而不是改变它是正确的做法。但是一个呢?不可变数据中心？我是说，为什么不呢?这是合乎逻辑的下一步，不是吗?每次配置发生变化时，与其重新配置负责构建新服务器的任何东西(我的意思是CI服务器、工件存储库和供应服务器)，为什么不扔掉它并启动一个新的服务器呢?

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

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

你如何运用这种美呢?通过使用Docker Compose(或以任何其他方式启动Artifactory)启动一个Artifactory服务器，包括数据库、nginx和所有的东西这个yaml文件在你的$ ARTIFACTORY_HOME /等文件夹．很酷?超级酷!

说到权限和安全性，随着Artifactory越来越多地由机器人而不是人来管理，用户管理已经没有意义了。机器人没有电子邮件地址，也不能登录他们的个人资料来更改密码。用户名和密码是过去，访问令牌都是未来。它们足够灵活，可以包含所有权限信息，提供对正确资源的正确访问;它们可以根据使用和/或时间过期，它们由其他机器人创建、管理和销毁。这是多么酷啊(也有点奇怪)!

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

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

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

这是开发运维的兴奋剂吗?