本文来自：红帽

任何环境的变化都可能带来风险。然而，在最新版本的操作系统上运行管理和外围服务有助于建立组织内部的知识和信心。通过在红帽企业 Linux (RHEL) 系统的全面支持阶段（即十年支持生命周期的前五年）使用，将享受到应有的全面支持体验。将应用和服务迁移到 RHEL 上最好尽早进行，做起来也很简单。

本文，我将演示在 RHEL 9 系统上部署 GitLab 有多么容易。除了使用最新版本的 RHEL 外，我还将展示如何使用 Ansible 将部署过程自动化。这意味着将来，您可以使用 Ansible 自动化将 GitLab 部署到发布的新版本 RHEL 上。

创建Ansible角色

首先，根据 GitLab 的安装说明设置一个安装 GitLab 的角色。以下是角色中包含的目录和文件的列表：

install_gitlab
├── defaults
│   └── main.yml
├── handlers
│   └── main.yml
├── tasks
│   ├── install-gitlab.yml
│   ├── install-prerequisites.yml
│   ├── main.yml
│   ├── set-ce-edition.yml
│   ├── set-ee-edition.yml
│   └── setup-gitlab-repo.yml
└── templates
    └── gitlab.repo.j2

创建Ansible任务

有 5 个任务文件，从 main.yml 开始：

---
- name: set vars for community edition
  ansible.builtin.include_tasks:
    file: set-ce-edition.yml
  when:
    - gitlab_edition == 'community'
- name: set vars for enterprise edition
  ansible.builtin.include_tasks:
    file: set-ee-edition.yml
  when:
    - gitlab_edition == 'enterprise'

- name: import pre-tasks
  ansible.builtin.import_tasks: install-prerequisites.yml

- name: setup gitlab repo
  ansible.builtin.import_tasks: setup-gitlab-repo.yml

- name: install gitlab
  ansible.builtin.import_tasks: install-gitlab.yml

主任务文件控制流程，并导入其他任务文件。首先，任务文件评估要部署的 GitLab 版本，社区版本（CE）或企业版（EE），然后设置适当的变量。

接下来的一组任务文件根据目标 GitLab 版本定义一些变量。我正在使用社区版，但同时包含两个版本以供您参考。这是 set-ce-edition.yml 文件的内容：

---
- name: set CE vars
  ansible.builtin.set_fact:
    edition_abbreviation: ce
    gitlab_package: gitlab-ce

set-ee-edition.yml 文件具有完全相同的逻辑，但是它指的是企业版：

---
- name: set EE vars
  ansible.builtin.set_fact:
    edition_abbreviation: ee
    gitlab_package: gitlab-ee

接下来，在 install-prerequisites.yml 文件中处理一些 GitLab 的先决条件：

---
- name: install prerequisites
  ansible.builtin.yum:
    name:
      - yum-utils
      - policycoreutils
      - openssh-server
      - openssh-clients
      - postfix
  register: packages_installed

- name: start/enable services
  ansible.builtin.systemd:
    name: "{{ service }}"
    enabled: yes
    state: started
  loop_control:
    loop_var: service
  loop:
    - sshd
    - postfix
  when:
    - packages_installed.changed

很可能已经安装了一些先决条件的软件包，但是 Ansible 会跳过在给定系统上不需要的步骤。

接着，使用 setup-gitlab-repo.yml 文件在系统上设置  GitLab 的软件包仓库。

---
- name: push gitlab repo file
  ansible.builtin.template:
    src: templates/gitlab.repo.j2
    dest: "/etc/yum.repos.d/gitlab_gitlab-{{ edition_abbreviation }}.repo"
    owner: root
    group: root
    mode: '0644'
  register: repo_file_pushed

- name: clear yum cache
  ansible.builtin.shell:
    cmd: yum clean all
  when:
    - repo_file_pushed.changed

最后，使用 install-gitlab.yml 文件安装 GitLab：

---
- name: install gitlab
  ansible.builtin.yum:
    name: "{{ gitlab_package }}"
  environment:
    EXTERNAL_URL: "https://{{ inventory_hostname }}"
    GITLAB_ROOT_PASSWORD: "{{ gitlab_admin_password }}"
  notify:
    - setup_api_token

在这个文件中，创建了一些环境变量供 GitLab 使用，这样在 RPM 事务完成后就不需要重新配置应用。

默认值和模板

为了支持这些 Ansible 任务，需要设置一些其他的东西。

➤ 默认值

默认值通常被设置为最后的备选值。这意味着只要变量在其他地方没有被覆盖，就会使用默认值。对于这个角色，设置 GitLab 版本的默认值。在许多其他具有更高优先级的位置可以定义它，但在这里定义它是有效的。

---
gitlab_edition: 'community'

➤ 模板

为 GitLab 仓库设置一个名为 gitlab.repo.j2 的模板：

[gitlab_gitlab-{{ edition_abbreviation }}]
name=gitlab_gitlab-{{ edition_abbreviation }}
baseurl=https://packages.gitlab.com/gitlab/gitlab-{{ edition_abbreviation }}/el/8/$basearch
repo_gpgcheck=1
gpgcheck=1
enabled=1
gpgkey=https://packages.gitlab.com/gitlab/gitlab-{{ edition_abbreviation }}/gpgkey
       https://packages.gitlab.com/gitlab/gitlab-{{ edition_abbreviation }}/gpgkey/gitlab-gitlab-{{ edition_abbreviation }}-3D645A26AB9FBD22.pub.gpg
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300

[gitlab_gitlab-{{ edition_abbreviation }}-source]
name=gitlab_gitlab-{{ edition_abbreviation }}-source
baseurl=https://packages.gitlab.com/gitlab/gitlab-{{ edition_abbreviation }}/el/8/SRPMS
repo_gpgcheck=1
gpgcheck=1
enabled=1
gpgkey=https://packages.gitlab.com/gitlab/gitlab-{{ edition_abbreviation }}/gpgkey
       https://packages.gitlab.com/gitlab/gitlab-{{ edition_abbreviation }}/gpgkey/gitlab-gitlab-{{ edition_abbreviation }}-3D645A26AB9FBD22.pub.gpg
sslverify=1
sslcacert=/etc/pki/tls/certs/ca-bundle.crt
metadata_expire=300

请注意，这个模板中硬编码了数字 8，因为 GitLab 目前尚未为 RHEL 9 设置仓库。将来，可以用 Ansible 变量替换它，比如{{ ansible_distribution_major_version }}。

➤ 处理程序

在 GitLab 正常运行之后，我喜欢使用个人访问令牌启用 API 访问。因为您正在安装一个全新的实例，可以在处理程序文件中添加一个任务，为根用户设置访问令牌：

---
- name: set access token for API access
  ansible.builtin.shell:
    cmd: >
      gitlab-rails runner "token = User.find_by_username('root').personal_access_tokens.create(scopes: [:api], name: 'Ansible Automation token'); token.set_token('{{ gitlab_admin_password }}'); token.save!"
  register: token_create_output
  listen:
    - setup_api_token

设置此令牌允许通过 GitLab 的 API 或使用 community.general 中的 Ansible 模块进行配置，一旦此角色成功运行。

角色现在已经完成。快速编写一个 playbook，并将其保存为 ???.yml：

---
- name: install gitlab
  hosts:
    - all
  roles:
    - roles/install_gitlab

创建一个清单文件，将 Ansible 指向我们的 RHEL9 系统，并将其保存为 ???.ini：

---
all:
  children:
    gitlab:
      hosts:
        gitlab.example.com:
          ansible_user: tux
          ansible_password: 'change_me'
          ansible_become: yes
          ansible_become_password: 'change_me'
          gitlab_admin_password: 'change_me'

运行Playbook

一切准备就绪。现在是时候运行您的 Ansible Playbook 了：

当 Playbook 完成后，访问新 GitLab 实例的网址，并使用管理员密码登录。

总结

您刚刚使用 Ansible 在 RHEL 9 系统上安装了 GitLab ！尽管这是一个简单直接的过程，但已经完成了一些重要的步骤。您开发了一个可重复使用的 Ansible 角色，在RHEL 的主要版本之间可以轻松移植，而且几乎不需要修改。还将一个重要的工作负载放在了全球领先的企业 Linux 平台的最新版本上：红帽企业 Linux。