金鱼哥RHCA回忆录:DO447使用Ansible Tower创建简单的CI/CD流水线

简介: 第十三章 使用Ansible Tower创建简单的CI/CD流水线
🎹 个人简介:大家好,我是 金鱼哥,CSDN运维领域新星创作者,华为云·云享专家,阿里云社区专家博主
📚个人资质: CCNA、HCNP、CSNA(网络分析师),软考初级、中级网络工程师、RHCSA、RHCE、RHCA、RHCI、ITIL😜
💬格言:努力不一定成功,但要想成功就必须努力🔥

🎈支持我:可点赞👍、可收藏⭐️、可留言📝


13.1.1 持续集成(continuous integration)

持续集成是使用自动化将单个开发人员的贡献集成到共享代码存储库中的DevOps实践。持续交付将重点放在更快速、更频繁地执行过程上,通过将它们合并并执行它们。

这种实践鼓励更频繁地提交小的变更,而不是不频繁地提交大的变更。
在这里插入图片描述

自动化例程被分组到作业中,作业被放置在一个流水线中。流水线定义了作业执行的顺序。

对于流水线的内容没有规则,但基本前提是流水线有助于自动化质量控制。这种自动化以可靠的可重复的方式消除了人工干预的需要。

一些正在做的工作的例子包括:

  • 语法检查,以确保代码不包含任何阻止代码编译的语法错误。
  • “Linting”(运行一个程序来分析你的代码)来检测可能被改进的行为和实践。
  • 调用必要的步骤来构建代码以生成可部署的构件。
  • 在服务器上部署和安装代码。
  • “冒烟测试”的形式是粗略的、有限的测试,以确保最重要的功能工作。
  • 单元测试用于验证单个代码单元(函数)是否按预期工作。
  • 集成测试,以验证代码(功能)的各个单元是否如预期的那样协同工作。
  • 回归测试来验证新的或最近修改的代码不会对现有的特性(功能)产生负面影响。

这种做法有许多好处:

  • 一旦代码提交,关于代码运行状态的快速反馈。
  • 当代码被检入时,代码的端到端测试是自动化的,从而在处理代码的开发人员之间产生更快的反馈循环。
  • 方便集成来自不同开发人员的代码。
  • 为代码协作的开发人员提供更好的可视性。
  • 在同一个sprint中,开发人员和测试人员能够更快地失败,从而进一步减少反馈循环。
  • 减少长时间冲刺结束时的调试会话。

为了开始使用CI/CD流水线,需要:

  • 对分布式版本控制服务的访问
  • 对代码的测试
  • 访问CI/CD服务以运行测试

注意:可以将Red Hat Ansible Tower与各种CI/CD平台结合起来,为Ansible Playbook项目创建一个流水线。在本课程中,我们使用GitLab的一个课堂实例,它可以提供存储库管理和CI/CD平台服务。其他替代方案也可能具有不同的优点,但此配置提供了一个很好的示例。


13.1.2 使用gitlab构建CI/ CD流水线

在CI/CD流水线中,GitLab使用运行器在流水线中运行作业。运行程序提供了执行流水线的环境。执行者可以特定于一个项目,也可以在所有项目中共享。

运行执行器在作业中执行命令。

执行器可以:

  • 容器
  • 虚拟机
  • 本地shell(作业在GitLab机器本身的shell中执行)
  • SSH连接到另一台机器执行作业

理想情况下,运行程序独立于任何连接的系统,执行流水线中定义的代码。
在这里插入图片描述


13.1.3 CI/CD和Ansible Tower

使用CI/CD流水线,与Red Hat Ansible Tower集成,对Ansible Playbook项目的每个提交执行自动化例程。

典型的流水线执行以下步骤:

  1. 从开发分支提取剧本的最新版本。
  2. 执行语法检查以确保代码的完整性,并进行Linting以确保它遵循一组最佳实践规则。
  3. 同步从开发分支到Ansible Tower项目的剧本。
  4. 根据Ansible Tower中的开发目录执行作业模板,使用开发分支中的代码。
  5. 以单元测试的形式验证关键组件的功能在开发目录中的主机。
  6. 将dev分支合并到主分支
  7. 同步从主分支到Ansible Tower的一个项目的剧本。
  8. 使用来自主分支的代码,针对Ansible Tower中的Prod清单执行作业模板。
  9. 在Prod清单中以主机单元测试的形式验证关键组件的功能
  10. 发送通知通知开发人员工作的状态

该流水线将必须手动执行的流程自动化。自动化允许开发人员使用他们选择的工具专注于创建和编辑剧本。开发人员可以简单地提交他们的工作,知道使用Cl流水线的自动化是与Red Hat Ansible Tower集成的。


13.1.4 Ansible LINT

Ansible Lint是一个命令行工具,用于检测可能被改进的错误、bug、可疑代码结构和样式错误。

它被Ansible Galaxy项目用于lint和计算为Galaxy Hub贡献的内容的质量分数。

重要:ansible-lint命令目前没有随Red Hat Ansible Automation一起发布,也没有得到Red Hat的官方支持,但是由上游的Ansible社区开发。这个命令包含在Red Hat Enterprise Linux 7和Fedora当前版本的EPEL中。在其他操作系统上的安装说明可以在https://docs.ansible.com/ansible-lint/上找到

Ansible Lint以Python模块的形式使用来自${PYTHON_ PATH}/site-packages/ansiblelint/rules/的规则,这些规则可以原样使用,也可以编辑以满足你自己的需要。其他的用户定义规则可以与默认规则一起创建和使用,如下所示:

下面是一个写得很糟糕的剧本的例子。

[student@demo examples]$ cat playbook.yml
---
- name: A bad play
  hosts: demo.lab.example.com

tasks:
- command: systemctl mask iptables.service
...

语法上,剧本是没有任何错误的。

[student@demo examples]$ ansible-playbook playbook.yml --syntax-check

playbook: playbook.yml

ansible-lint揭示了这不是一个写得很好的剧本。

[student@demo examples]$ ansible-lint playbook.yml
[301] Commands should not change things if nothing needs doing   # 方括号中的数字告诉我们匹配了哪些linting规则(标记),以及对问题的简短描述。
playbook.yml:6       # 发现问题的文件名和行号。
Task/Handler: command systemctl mask iptables.service    # 有问题的任务的名称。

[303] systemctl used in place of systemd module
playbook.yml:6
Task/Handler: command systemctl mask iptables.service

[502] All tasks should be named
playbook.yml:6
Task/Handler: command systemctl mask iptables.service

ansible-lint中的规则作为Python模块实现,并存储在${Python-path}/site-packages/ansiblelint/ Rules /中。

由于ansible-lint,这些问题的补救被简化了。
在这里插入图片描述

注意:与ansible-playbook --syntax-check命令相比,ansible-lint命令更能验证剧本的完整性。因此。在使用ansible-lint命令时,不需要使用ansible-playbook --syntax-check

许多组织实施了风格指南,它定义了编写剧本的标准。例如,布尔值的声明方式可以是不同的: True vs true vs Yes vs yes vs 1。虽然所有这些值都意味着相同的思路,但是一致使用样式有助于剧本的可读性,从而进一步帮助排除剧本中的错误。
在这里插入图片描述

ansible-lint命令将规则实现为Python模块,您自己的规则可以用于默认规则之外。

[student@demo ~]$ ansible-lint -R ~/ansible-lint/custom_rules/ playbook.yml

覆盖$fPYTHON- PATH}/site-packages/ansiblelint/rules/中的默认规则。而只使用你的自定义规则,使用ansible-lint命令如下:

[student@demo ~]$ ansible-lint -r ~/ansible-lint/custom_rules/ playbook.yml

Ansible Lint规则检查变量名之前和之后的空格
在这里插入图片描述


13.1.5 课本练习

[student@workstation ~]$ lab cicd-tower start

1. 拉取实验代码。

[student@workstation ~]$ mkdir -p /home/student/git-repos
[student@workstation ~]$ cd /home/student/git-repos
[student@workstation git-repos]$ git clone \
http://git.lab.example.com:8081/git/cicd-tower.git
[student@workstation git-repos]$ cd cicd-tower

2. 检查存储库的master和dev分支中的文件。

[student@workstation cicd-tower]$ git branch 
* master
[student@workstation cicd-tower]$ ll
total 8
-rw-rw-r--. 1 student student 609 May 20 14:30 playbook.yml
-rw-rw-r--. 1 student student  19 May 20 14:30 README.md
[student@workstation cicd-tower]$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/dev
  remotes/origin/master
[student@workstation cicd-tower]$ git checkout dev
Branch 'dev' set up to track remote branch 'dev' from 'origin'.
Switched to a new branch 'dev'
[student@workstation cicd-tower]$ git branch
* dev
  master
[student@workstation cicd-tower]$ ls -la
total 12
drwxrwxr-x.  3 student student   77 May 20 14:32 .
drwxrwxr-x. 15 student student  277 May 20 14:30 ..
drwxrwxr-x.  8 student student  163 May 20 14:32 .git
-rw-rw-r--.  1 student student 1167 May 20 14:32 .gitlab-ci.yml
-rw-rw-r--.  1 student student  869 May 20 14:32 playbook.yml
-rw-rw-r--.  1 student student   19 May 20 14:30 README.md

3. 使用ansible-lint命令识别剧本中的任何问题。可以使用这个剧本来部署测试和生产web服务器。

[student@workstation cicd-tower]$ ansible-lint playbook.yml
Couldn't parse task at playbook.yml:21 (no action detected in task. This often indicates a misspelled module name, or incorrect module path.

The error appears to be in '<unicode string>': line 21, column 7, but may
be elsewhere in the file depending on the exact syntax problem.

(could not open file to display line))
{ 'firewall': { '__file__': 'playbook.yml',
                '__line__': 22,
                'immediate': True,
                'permanent': True,
                'service': 'http',
                'state': 'enabled'},
  'name': 'Open the port in the firewall'}

修改正确的模块名:
    - name: Open the port in the firewall
      firewalld:
        service: http
        state: enabled
        immediate: true
        permanent: true

[student@workstation cicd-tower]$ ansible-lint playbook.yml
[206] Variables should have spaces before and after: {{ var_name }}
playbook.yml:12
        name: "{{packages}}"

[502] All tasks should be named
playbook.yml:28
Task/Handler: copy content=Hello world
 dest=/var/www/html/index.html __line__=28 __file__=playbook.yml

4. 处理再次检查到的错误。

 10     - name: Install the webserver software
 11       yum:
 12         name: "{{ packages }}"
 13         state: installed

 28     - name: Install sample web content
 29       copy:
 30         content: "Hello world\n"
 31         dest: /var/www/html/index.html

5. 验证ansible-lint命令没有识别出任何其他问题。

如果剧本没有问题或错误,ansiblelint命令不会返回任何输出。

[student@workstation cicd-tower]$ ansible-lint playbook.yml
[student@workstation cicd-tower]$ echo $?
0

6. 如果GitLab项目包含 .gitlab-ci.yml文件,GitLab为项目创建一个CI/CD流水线。

该文件定义了一系列阶段,每个阶段执行一个或多个作业。阶段控制作业执行的顺序。如果某个作业失败,后续的阶段和作业就不会执行。

GitLab流水线作业在一个可用的GitLab Runner实例上执行。您可以配置一个GitLab Runner来在任何机器上执行您的CI/CD流水线。配置GitLab runner超出了本课程的范围。

在教室环境中,在GitLab服务器上配置一个GitLab Runner实例。使用这个运行程序执行简单的bash命令来实现Cl/CD流水线。

回顾 .gitlab-ci.yml文件定义了这个项目的Cl/CD流水线:

[student@workstation cicd-tower]$ cat .gitlab-ci.yml 
variables:
  LAUNCH_TOWER_JOB: tower-cli job launch --monitor --insecure
  TOWER_CREDENTIALS: -u admin -p redhat -h tower.lab.example.com
  GIT_REPO: http://git:redhat321@git.lab.example.com:8081/git/cicd-tower.git

stages:
  - lint
  - deploy
  - auto_merge

# First stage; all branches
syntax check and linting:
  stage: lint
  script:
    - if ls *.yml; then true; else echo "No playbooks found!"; exit 1; fi
    - ansible-lint *.yml

#Second stage; only dev branch
launch test job:
  stage: deploy
  script:
    - tower-cli config verify_ssl false
    - $LAUNCH_TOWER_JOB $TOWER_CREDENTIALS -J "Deploy Test WebServers"
    - echo $?
  only:
    - dev

#Second stage; only the master branch
launch prod job:
  stage: deploy
  script:
    - tower-cli config verify_ssl false
    - $LAUNCH_TOWER_JOB $TOWER_CREDENTIALS -J "Deploy Prod WebServers"
    - echo $?
  only:
    - master

#Third stage; only applies to the dev branch
push to master:
  stage: auto_merge
  script:
    - git remote set-url origin $GIT_REPO
    - git checkout dev && git pull
    - git checkout master && git pull
    - git merge --no-ff dev
    - git push origin master
  only:
    - dev

这个流水线配置文件定义了一个有三个阶段的流水线: lint、deploy和auto_merge。

lint阶段包含单个作业,名称为syntax check and linting。该作业对每个YAML文件执行ansible-lint命令。如果存储库中不存在YAML文件,那么作业将失败。

deploy阶段触发Ansible Tower作业模板的执行。对于dev分支,执行Deploy Test Web Servers作业模板,而主分支执行Deploy Prod Web Servers模板。

auto_merge阶段仅为dev分支定义了一个作业。此作业将dev分支中的更改合并到主分支中,并推送到远程存储库。


7. 在Ansible Tower中测试资源。

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

Prod对象也有类似的资源。剧本首先根据我们的测试目录进行测试,如果冒烟测试通过,剧本将从开发分支合并到主分支。通过在您的流水线中执行测试,此过程可以保护我们的生产服务器免受剧本中发现的错误的负面影响。


8. 提交代码。

[student@workstation cicd-tower]$ git add .
[student@workstation cicd-tower]$ git commit -m "Implemented CI pipeline"
[student@workstation cicd-tower]$ git push

9. 查看最近的流水线执行。

这些执行是由于在上一步中推送到开发分支的更改而被三分之一化的。流水线在第二个阶段中失败。确定导致管道失败的错误。

在这里插入图片描述

当您看到管道作业完成时,第二个阶段的状态为失败。
在这里插入图片描述

因此,第三个阶段不会执行,代码也不会自动从dev分支合并到主分支。点击失败阶段的图标查看失败的作业的名称。单击launch_test_job打开一个新的Firefox选项卡,其中显示作业的输出。
在这里插入图片描述

测试环境web服务器冒烟测试失败。根据冒烟测试,测试服务器上的内容没有正确大写。web服务器上的消息应该是Hello World,而不是Hello world。这意味着名为Deploy Prod Webservers的Ansible Tower作业模板从未从流水线中调用过。

[student@workstation cicd-tower]$ curl http://servera
This is a test message RedHat 8.0 <br>
Current Host: servera <br>
Server list: <br>
servera.lab.example.com <br>
serverb.lab.example.com <br>

[student@workstation cicd-tower]$ curl http://serverb
This is a test message RedHat 8.0 <br>
Current Host: serverb <br>
Server list: <br>
servera.lab.example.com <br>
serverb.lab.example.com <br>

[student@workstation cicd-tower]$ curl http://serverc
Hello world
[student@workstation cicd-tower]$ curl http://serverd
Hello world

10. 查看Ansible Tower中的报错。

在这里插入图片描述


11. 纠正剧本的内容。

playbook.yml部署到每个web服务器上。提交并推动更改。验证您对开发分支的代码更改已集成到主分支中,并且生产服务器已使用这些更改进行更新。

[student@workstation cicd-tower]$ vim playbook.yml
    - name: Install sample web content
      copy:
        content: "Hello World\n"
        dest: /var/www/html/index.html

[student@workstation cicd-tower]$ git branch 
* dev
  master
[student@workstation cicd-tower]$ git add .
[student@workstation cicd-tower]$ git commit -m "Fixes content error."
[student@workstation cicd-tower]$ git push

12. 验证最近对存储库的推送是否触发了两次管道执行,从而导致对生产服务器的更新。

在这里插入图片描述

[student@workstation cicd-tower]$ curl http://servera
Hello World
[student@workstation cicd-tower]$ curl http://serverb
Hello World

在这里插入图片描述


13. 清除实验。

[student@workstation $ lab cicd-tower finish

💡总结

RHCA认证需要经历5门的学习与考试,还是需要花不少时间去学习与备考的,好好加油,可以噶🤪。

以上就是【金鱼哥】对 第十三章 使用Ansible Tower创建简单的CI/CD流水线 的简述和讲解。希望能对看到此文章的小伙伴有所帮助。

💾 红帽认证专栏系列:
RHCSA专栏: 戏说 RHCSA 认证
RHCE专栏: 戏说 RHCE 认证
此文章收录在RHCA专栏: RHCA 回忆录

如果这篇【文章】有帮助到你,希望可以给【金鱼哥】点个赞👍,创作不易,相比官方的陈述,我更喜欢用【通俗易懂】的文笔去讲解每一个知识点。

如果有对【运维技术】感兴趣,也欢迎关注❤️❤️❤️ 【金鱼哥】❤️❤️❤️,我将会给你带来巨大的【收获与惊喜】💕💕!

目录
相关文章
|
2月前
|
JavaScript 前端开发 持续交付
Prettier 高级应用:集成 CI/CD 流水线与插件开发
【10月更文挑战第18天】Prettier 是一款流行的代码格式化工具,它能够自动将代码格式化成一致的风格,从而提高代码的可读性和维护性。对于希望进一步发挥 Prettier 潜力的高级用户而言,将 Prettier 集成到持续集成(CI)和持续部署(CD)流程中,确保每次提交的代码都符合团队标准,是非常重要的。此外,通过开发自定义插件来支持更多语言或扩展 Prettier 的功能也是值得探索的方向。本文将详细介绍这两方面的内容。
55 2
|
2月前
|
jenkins 测试技术 持续交付
Docker最佳实践:构建高效的CI/CD流水线
【10月更文挑战第17天】在现代软件开发实践中,持续集成(Continuous Integration, CI)和持续部署(Continuous Deployment, CD)已成为提高开发效率和软件质量的重要手段。Docker作为一种容器技术,为构建一致且隔离的开发环境提供了强有力的支撑。本文将探讨如何利用Docker来优化CI/CD流程,包括构建环境的标准化、镜像管理以及与CI/CD工具(如Jenkins、GitLab CI)的集成。
79 5
|
2月前
|
运维 jenkins 持续交付
自动化运维之路:构建高效CI/CD流水线
在软件开发的快节奏中,持续集成和持续部署(CI/CD)流水线是提升效率、保障质量的关键。本文将引导你理解CI/CD流水线的重要性,并手把手教你如何搭建一个高效的自动化运维系统。通过实际代码示例,我们将一步步实现从代码提交到自动测试、部署的全流程自动化,确保软件交付过程既快速又可靠。
|
3月前
|
Kubernetes 持续交付 Go
创建一个基于Go程序的持续集成/持续部署(CI/CD)流水线
创建一个基于Go程序的持续集成/持续部署(CI/CD)流水线
|
4月前
|
jenkins Java 测试技术
CI/CD 流水线的设计与实施
【8月更文第30天】持续集成(Continuous Integration, CI)和持续交付(Continuous Delivery, CD)是现代软件开发中的重要组成部分。CI/CD 不仅可以加速产品的发布周期,还能提高软件的质量并减少部署过程中的风险。本文将详细介绍 CI/CD 流水线的设计与实施,并提供一些实用的工具和最佳实践。
428 2
|
4月前
|
Java Spring 传感器
AI 浪潮席卷,Spring 框架配置文件管理与环境感知,为软件稳定护航,你还在等什么?
【8月更文挑战第31天】在软件开发中,配置文件管理至关重要。Spring框架提供强大支持,便于应对不同环境需求,如电商项目的开发、测试与生产环境。它支持多种格式的配置文件(如properties和YAML),并能根据环境加载不同配置,如数据库连接信息。通过`@Profile`注解可指定特定环境下的配置生效,同时支持通过命令行参数或环境变量覆盖配置值,确保应用稳定性和可靠性。
68 0
|
4月前
|
Devops 持续交付 开发者
.NET自动化之旅:是Azure DevOps还是GitHub Actions能够打造完美的CI/CD流水线?
【8月更文挑战第28天】在现代软件开发中,持续集成(CI)与持续部署(CD)是提升代码质量和加速交付的关键实践。对于 .NET 应用,Azure DevOps 和 GitHub Actions 等工具可高效构建 CI/CD 流水线,提升开发效率并确保软件稳定可靠。Azure DevOps 提供一站式全流程管理,支持 YAML 定义的自动化构建、测试和部署;GitHub Actions 则以简洁灵活著称,适用于 .NET 项目的自动化流程。选择合适的工具可显著提高开发效率并确保高质量标准。
29 0
|
1月前
|
运维 应用服务中间件 Linux
自动化运维的利器:Ansible在配置管理中的应用
【10月更文挑战第39天】本文旨在通过深入浅出的方式,向读者展示如何利用Ansible这一强大的自动化工具来优化日常的运维工作。我们将从基础概念讲起,逐步深入到实战操作,不仅涵盖Ansible的核心功能,还会分享一些高级技巧和最佳实践。无论你是初学者还是有经验的运维人员,这篇文章都会为你提供有价值的信息,帮助你提升工作效率。
|
20天前
|
运维 Ubuntu 应用服务中间件
自动化运维之路:使用Ansible进行服务器管理
在现代IT基础设施中,自动化运维已成为提高效率和可靠性的关键。本文将引导您通过使用Ansible这一强大的自动化工具来简化日常的服务器管理任务。我们将一起探索如何配置Ansible、编写Playbook以及执行自动化任务,旨在为读者提供一条清晰的路径,从而步入自动化运维的世界。
|
18天前
|
运维 网络安全 Python
自动化运维:使用Ansible实现批量服务器配置
在快速迭代的IT环境中,高效、可靠的服务器管理变得至关重要。本文将介绍如何使用Ansible这一强大的自动化工具,来简化和加速批量服务器配置过程。我们将从基础开始,逐步深入到更复杂的应用场景,确保即使是新手也能跟上节奏。文章将不包含代码示例,而是通过清晰的步骤和逻辑结构,引导读者理解自动化运维的核心概念及其在实际操作中的应用。