自从我开始使用研究Jenkins以来,已经有一段时间了。我使用此工具的日常工作从监督旧工作的执行到维护和增强声明性多分支管道，始终尝试实现持续集成和持续交付实践，以在许多环境中推广打包的软件，直至获得客户的支持。
达到这样的自动化水平需要时间，团队和流程。根据我的经验，这是一项需要大量时间和精力的任务，并且软件开发和交付过程中涉及的每个人都必须采用这种新的思维方式和工作方式并加以适应。
在传播了关于DevOps文化的一些想法之后，我想再次关注Jenkins主题。我将大部分时间都花在各种环境之间，而对于每种环境，我都在一个完全不同的Jenkins上工作。我测试了高级插件中的新功能，这些新功能可以改善和阐明开发环境中的软件交付过程。确认新功能正常运行后，我将花费更多时间将其推广到其他环境。这听起来像是一项重复性的任务，但实际上，我多年来倾向于避免采用此类任务，因为多年来我一直在追求采用EaC，“一切都作为代码”，但是由于某种原因，我还没有机会将其应用于Jenkins安装范围。
目标我想要达到的理想状态是能够构建一个Jenkins实例，在该实例中，其所有配置和作业定义都将进入声明性文件。这样，我们就可以将不可变的Jenkins实例部署在任何环境中，无论何时添加插件或作业，或修改配置，它都会在Git上存储和版本化。这样，任何未知的配置都无法再破坏实例的所需状态，并且任何人都可以在其本地主机上部署确切的状态，例如，出于测试目的。
思路我决定将项目构造为两个存储库。
有一个初始项目用于在Jenkins实例级别设置配置。在文件上，我们添加了插件来安装和锁定它们的版本。其中一个插件，即Jenkins配置为代码，使我们可以预先定义Jenkins和其余插件的全局配置，而无需与Jenkins UI进行交互，最后使用Dockerfile构建包含所有初始化文件的Docker映像。
第二个项目用于与Jenkins DSL插件进行交互。目标是将作业，文件夹和视图作为代码存储在groovy文件中，因此只有我们在Git存储库中定义的内容才适用于Jenkins实例。
构建Docker镜像
容器软件抽象的一种广为人知的实现用于打包，收集依赖关系并自动进行部署。我们将使用Dockerfile构建Jenkins实例。
FROM jenkins/jenkins:ltsCOPY init-scripts /usr/share/jenkins/ref/init.groovy.dADD plugins.txt /usr/share/jenkins/ref/ADD jenkins.yaml /usr/share/jenkins/ref/RUN /usr/local/bin/ < /usr/share/jenkins/ref/plugins.txtENV CASC_JENKINS_CONFIG /usr/share/jenkins/ref/VOLUME /var/jenkins_home
以下shell脚本可以作为启动构建阶段的有用资源。有两个阶段，一个阶段是构建容器映像，另一个阶段是运行容器映像。
#!/usr/bin/env bashdocker build -t jenkins_as_code:0.1.0 .
插件安装
为了自动化所需插件的安装，我们将使用Jenkins中包含的现有Shell脚本。该脚本位于容器内的/ usr / local / bin /处，名称为，用于安装插件，将其保存在文件中，并使用文件作为参数调用脚本。现在，我们可以存储需要安装的插件并锁定其版本。
workflow-aggregator:2.6configuration-as-code:1.30configuration-as-code-support:1.18credentials:2.3.0blueocean:1.19.0job-dsl:1.74
JCaC Jenkins插件
在Jenkins上工作涉及许多插件安装，并且必须为每个插件设置特定的配置。所有这些配置更改随着时间的推移加总。Jenkins实例往往会根据软件交付过程的需求而发展。GUI用于配置Jenkins。事实是，除了通过Web浏览之外，没有地方可以集中和存储应用了哪些配置。大多数人已经使用Groovy初始化脚本解决了这个问题。它可以工作，但是由于涉及一些编码，因此不如所需的友好和可读性。好消息是存在一个插件，您可以通过YAML文件定义全局配置和插件配置。很棒是因为它可以处理配置更改，并且我们可以使用所有已应用的配置来部署初始的Jenkins安装。因此，我们可以朝着主要目标前进，由版本化配置文件定义不可变Jenkins实例的部署。这个插件甚至可以让您定义一个种子作业，它是一个获取DSL文件并应用更改以创建其他作业，视图以及更多功能的作业。在我们的情况下，以下jenkins.yaml文件用于提供配置。种子作业从Github获取另一个项目，该项目包含一些基于DSL的对象来创建资源。jenkins:systemMessage: "Jenkins As Code Concept."views:- myView:name: "Jobs Config as Code"security:globalJobDslSecurityConfiguration:useScriptSecurity: falsejobs:- script: >freeStyleJob("Jobs Generator") {scm {github('imanol-dev/jenkins_as_code_jobs', 'master')}steps {dsl {external('*.groovy')}}}
关于此插件的一个很棒的事情是，您可以修改YAML文件并重新加载新配置，应用所有更改，而无需重新创建Jenkins实例。
默认用户
在处理此问题时，我遇到了一个尝试通过配置文件自动创建默认管理员用户的问题。为了解决这个问题，我进行了一些研究，发现了一个使用Groovy初始化脚本的存储库。该脚本位于*/usr/share/jenkins/ref/init.groovy.d*目录中的容器内。
这样，创建用户，我们只需要填充以下环境变量：
ADMIN_USERNAME=ADMIN_PASSWORD=
跳过向导
每次部署新的Jenkins实例时，第一次登录时，系统都会提示您配置向导，该向导可帮助您设置一些初始参数并安装一些建议的插件。
对于新手来说，这可能会有所帮助，但是我们正在尝试实现自动化功能，该功能可以部署配置文件中编写的内容，因此我们不需要此功能。
避免这种情况的方法是使用以下环境变量运行容器。
JAVA_OPTS=”-Djenkins.install.runSetupWizard=false”
作业DSL插件和作业定义
我找到了一些创建Jenkins项目的方法。您可以通过Web界面手动创建它们，使用Jenkins CLI在XML文件上定义它们以导入它们或使用DSL插件。
在DSL插件可以让你定义工作的声明形式，可读性更强。
我已经在单独的存储库中定义了一些作业，使用种子作业，我引用了该存储库，因此在执行它之后，所有新作业都会自动出现。可以通过git更改触发种子作业，因此，如果您通过代码删除或修改作业，则无需手动执行即可在Jenkins实例上对其进行更新。
结论
对于多环境部署问题，有很多更好的方法。跨所有环境的单个Jenkins都能胜任，但有时不仅是最佳技术解决方案。
就我而言，有时候，我必须适应完全隔离的环境，为同一项目使用独立的数据中心和不同的网络设置。在商业世界中已经有几年的经验告诉我，可能有些事情比我已经运行的想法更重要，我必须适应它。
我喜欢这项研究；我想找到一种自动执行一些重复性和手动任务的方法，以便我可以使用相同的配置但使用不同的Jobs部署多个Jenkins实例。
测试项目：https:///imanol-dev
