Ansible의 변수에 대한 시스템 접근 방식

앤서블 데브옵스 코드스타일

여기요! 내 이름은 데니스 칼류즈니 저는 개발 프로세스 자동화 부서에서 엔지니어로 일하고 있습니다. 매일 수백 대의 캠페인 서버에 새로운 애플리케이션 빌드가 출시됩니다. 그리고 이 기사에서는 이러한 목적으로 Ansible을 사용한 경험을 공유합니다.

이 가이드는 배포 시 변수를 구성하는 방법을 제공합니다. 이 가이드는 이미 플레이북에서 역할을 사용하고 있고 다음 내용을 읽어본 사용자를 대상으로 합니다. 모범 사례, 그러나 비슷한 문제에 직면합니다.

• 코드에서 변수를 찾았다면 그 변수가 무엇을 담당하는지 즉시 이해하는 것은 불가능합니다.
• 여러 역할이 있고 변수는 하나의 값과 연결되어야 하지만 작동하지 않습니다.
• 플레이북의 변수 논리가 어떻게 작동하는지 다른 사람에게 설명하는 데 어려움이 있습니다.

우리는 회사의 프로젝트에서 이러한 문제에 직면했고 그 결과 플레이북의 변수 설계 규칙을 작성하여 이러한 문제를 어느 정도 해결했습니다.

역할의 변수

역할은 배포 시스템의 별도 개체입니다. 모든 시스템 개체와 마찬가지로 시스템의 나머지 부분과 상호 작용할 수 있는 인터페이스가 있어야 합니다. 이러한 인터페이스는 역할 변수입니다.

예를 들어 역할을 생각해 봅시다. api, 서버에 Java 애플리케이션을 설치합니다. 어떤 변수가 있을 수 있나요?

가변 역할은 유형에 따라 두 가지 유형으로 나눌 수 있습니다.

1. Свойства
    a) независимые от среды
    б) зависимые от среды
2. Связи
    a) слушатели 
    б) запросы внутри системы
    в) запросы в среду

변수 속성 역할의 행동을 결정하는 변수입니다.

쿼리 변수 - 역할 외부의 리소스를 지정하는 데 사용되는 값을 갖는 변수입니다.

변수 리스너 - 요청 변수를 형성하는 데 사용되는 값을 갖는 변수입니다.

반면, 1a, 2a, 2b는 환경(하드웨어, 외부자원 등)에 의존하지 않는 변수로 defaults 역할에 기본값을 채울 수 있다. 다만, 1.b, 2.c 타입의 변수는 환경에 따라 스탠드에서 스탠드로 바뀌기 때문에 'example' 이외의 값으로 채우는 것은 불가능하다.

코드 스타일

• 변수 이름은 역할 이름으로 시작해야 합니다. 이렇게 하면 나중에 변수가 어떤 역할을 하는지, 무엇을 담당하는지 쉽게 파악할 수 있습니다.
• 역할에서 변수를 사용할 때는 캡슐화 원칙을 따르고 역할 자체 또는 현재 역할이 의존하는 역할에 정의된 변수를 사용해야 합니다.

• 변수에 사전을 사용하지 마십시오. Ansible에서는 사전의 개별 값을 편리하게 재정의하는 것을 허용하지 않습니다.

  잘못된 변수의 예:

  myrole_user:
      login: admin
      password: admin

  여기서 로그인은 독립변수이고, 비밀번호는 종속변수입니다. 하지만
  그것들은 사전으로 결합되어 있으므로 완전히 지정해야 합니다.
  언제나. 매우 불편합니다. 이 방법이 더 좋습니다:

  myrole_user_login: admin
  myrole_user_password: admin

배포 플레이북의 변수

배포 플레이북(이하 플레이북)을 컴파일할 때 별도의 저장소에 배치해야 한다는 규칙을 준수합니다. 역할과 동일합니다. 각 역할은 자체 git 저장소에 있습니다. 이를 통해 역할과 플레이북은 배포 시스템의 서로 다른 독립적 개체이며 한 개체의 변경 사항이 다른 개체의 작동에 영향을 주어서는 안 된다는 점을 이해할 수 있습니다. 이는 변수의 기본값을 변경하여 달성됩니다.

요약하면 플레이북을 컴파일할 때 플레이북 변수와 인벤토리 변수 두 곳에서 역할 변수의 기본값을 재정의하는 것이 가능합니다.

mydeploy                        # Каталог деплоя
├── deploy.yml                  # Плейбук деплоя
├── group_vars                  # Каталог переменных плейбука
│   ├── all.yml                 # Файл для переменных связи всей системы
│   └── myapi.yml               # Файл переменных свойств группы myapi
└── inventories                 #
    └── prod                    # Каталог окружения prod
        ├── prod.ini            # Инвентори файл
        └── group_vars          # Каталог для переменных инвентори
            └── myapi           #
                ├── vars.yml    # Средозависимые переменные группы myapi
                └── vault.yml   # Секреты (всегда средозависимы) *

* - 변수 및 Vault

차이점은 플레이북 변수는 동일한 레벨에 있는 플레이북을 호출할 때 항상 사용된다는 것입니다. 이는 이러한 변수가 환경 독립적 변수의 기본값을 변경하는 데 유용하다는 것을 의미합니다. 반대로, 인벤토리 변수는 특정 환경에만 사용되며 이는 환경별 변수에 이상적입니다.

변수 우선순위를 사용하면 먼저 플레이북 변수에서 변수를 재정의한 다음 하나의 인벤토리에서 별도로 변수를 재정의할 수 없다는 점에 유의하는 것이 중요합니다.

이는 이미 이 단계에서 변수가 환경에 종속적인지 여부를 결정하고 적절한 위치에 배치해야 함을 의미합니다.

예를 들어, 한 프로젝트에서 SSL 활성화를 담당하는 변수는 오랫동안 환경에 따라 달라졌습니다. 스탠드 중 하나에서 통제할 수 없는 이유로 SSL을 활성화할 수 없었기 때문입니다. 이 문제를 해결한 후에는 환경 독립적이 되어 플레이북 변수로 이동했습니다.

그룹의 속성 변수

Java 애플리케이션은 다르지만 설정이 다른 1개의 서버 그룹을 추가하여 그림 2의 모델을 확장해 보겠습니다.

이 경우 플레이북이 어떻게 보일지 상상해 봅시다.

- hosts: myapi
  roles:
    - api

- hosts: bbauth
  roles:
    - auth

- hosts: ghauth
  roles:
    - auth

플레이북에는 세 개의 그룹이 있으므로, group_vars 인벤토리 변수와 플레이북 변수에 동일한 수의 그룹 파일을 생성하는 것이 즉시 권장됩니다. 이 경우 하나의 그룹 파일은 플레이북에 있는 위 애플리케이션의 한 구성 요소에 대한 설명입니다. 플레이북 변수에서 그룹 파일을 열면 그룹에 설치된 역할의 기본 동작과의 모든 차이점을 즉시 확인할 수 있습니다. 재고 변수: 서 있을 때마다 그룹 행동의 차이가 있습니다.

코드 스타일

• host_vars 변수는 시스템을 설명하지 않고 특수한 경우이므로 나중에 "이 호스트가 다른 호스트와 다른 이유는 무엇입니까?"라는 질문으로 이어질 수 있으므로 전혀 사용하지 마십시오. 이에 대한 대답은 다음과 같습니다. 항상 쉽게 찾을 수 있습니다.

통신 변수

그러나 이것이 속성 변수의 전부입니다. 그런데 통신 변수는 어떻습니까?
차이점은 서로 다른 그룹에서 동일한 의미를 가져야 한다는 것입니다.

처음에는 그랬어요 생각 다음과 같은 괴물 같은 구조를 사용하십시오.
hostvars[groups['bbauth'][0]]['auth_bind_port']그러나 그들은 즉시 이를 거부했다.
단점이 있기 때문이죠. 첫째, 부피감. 둘째, 그룹의 특정 호스트에 대한 의존성입니다. 셋째, 정의되지 않은 변수의 오류를 발생시키지 않으려면 배포를 시작하기 전에 모든 호스트에서 사실을 수집해야 합니다.

그 결과 통신변수를 사용하기로 결정하였다.

통신 변수 - 플레이북에 속하며 시스템 개체를 연결하는 데 필요한 변수입니다.

통신 변수는 일반 시스템 변수에 채워집니다. group_vars/all/vars 각 그룹에서 모든 리스너 변수를 제거하고 변수의 시작 부분에 리스너가 제거된 그룹의 이름을 추가하여 구성됩니다.

이렇게 하면 이름이 통일되고 중복되지 않습니다.

위 예제의 변수를 바인딩해 보겠습니다.

서로 의존하는 변수가 있다고 가정해 봅시다.

# roles/api/defaults:
# Переменная запроса
api_auth1_address: "http://example.com:80"
api_auth2_address: "http://example2.com:80"

# roles/auth/defaults:
# Переменная слушатель
auth_bind_port: "20000"

공통변수에 넣어보자 group_vars/all/vars 모든 청취자를 선택하고 제목에 그룹 이름을 추가합니다.

# group_vars/all/vars
bbauth_auth_bind_port: "20000"
ghauth_auth_bind_port: "30000"

# group_vars/bbauth/vars
auth_bind_port: "{{ bbauth_auth_bind_port }}"

# group_vars/ghauth/vars
auth_bind_port: "{{ ghauth_auth_bind_port }}"

# group_vars/myapi/vars
api_auth1_address: "http://{{ bbauth_auth_service_name }}:{{ bbauth_auth_bind_port }}"
api_auth2_address: "http://{{ ghauth_auth_service_name }}:{{ ghauth_auth_bind_port }}"

이제 커넥터 값을 변경하여 요청이 포트가 있는 동일한 위치로 이동하는지 확인합니다.

코드 스타일

• 역할과 그룹은 서로 다른 시스템 개체이므로 서로 다른 이름을 가져야 하며, 링크 변수는 이들이 시스템의 역할이 아닌 특정 서버 그룹에 속해 있음을 정확하게 나타냅니다.

환경 종속 파일

역할은 환경에 따라 다른 파일을 사용할 수 있습니다.

이러한 파일의 예로는 SSL 인증서가 있습니다. 텍스트 형식으로 저장
변수에서는 그다지 편리하지 않습니다. 하지만 경로를 변수 안에 저장하는 것이 편리합니다.

예를 들어, 우리는 변수를 사용합니다 api_ssl_key_file: "/path/to/file".

환경에 따라 키 인증서가 변경될 것이 분명하므로 이는 환경 종속 변수이므로 파일에 위치해야 함을 의미합니다.
group_vars/myapi/vars 변수 목록이며 '예를 들어' 값을 포함합니다.

이 경우 가장 편리한 방법은 경로를 따라 플레이북 저장소에 키 파일을 넣는 것입니다.
files/prod/certs/myapi.key이면 변수 값은 다음과 같습니다.
api_ssl_key_file: "prod/certs/myapi.key". 편리함은 특정 스탠드에서 시스템 배포를 담당하는 사람들이 저장소에 파일을 저장할 전용 공간을 가지고 있다는 사실에 있습니다. 동시에 다른 시스템에서 인증서를 제공하는 경우 서버의 인증서에 대한 절대 경로를 지정할 수 있습니다.

하나의 환경에 여러 스탠드

동일한 환경에서 차이를 최소화하면서 거의 동일한 여러 스탠드를 배포해야 하는 경우가 종종 있습니다. 이 경우 환경 종속 변수를 해당 환경 내에서 변경되지 않는 변수와 변경되는 변수로 나눕니다. 그리고 후자를 재고 파일 자체로 직접 전송합니다. 이 조작 후에는 환경 디렉터리에 직접 다른 인벤토리를 생성하는 것이 가능해집니다.

group_vars 인벤토리를 재사용하고 일부 변수를 직접 재정의할 수도 있습니다.

배포 프로젝트의 최종 디렉터리 구조는 다음과 같습니다.

mydeploy                        # Каталог деплоя
├── deploy.yml                  # Плейбук деплоя
├── files                       # Каталог для файлов деплоя
│   ├── prod                    # Католог для средозависимых файлов стенда prod
│   │   └── certs               # 
│   │       └── myapi.key       #
│   └── test1                   # Каталог для средозависимых файлов стенда test1
├── group_vars                  # Каталог переменных плейбука
│   ├── all.yml                 # Файл для переменных связи всей системы
│   ├── myapi.yml               # Файл переменных свойств группы myapi
│   ├── bbauth.yml              # 
│   └── ghauth.yml              #
└── inventories                 #
    ├── prod                    # Каталог окружения prod
    │   ├── group_vars          # Каталог для переменных инвентори
    │   │   ├── myapi           #
    │   │   │   ├── vars.yml    # Средозависимые переменные группы myapi
    │   │   │   └── vault.yml   # Секреты (всегда средозависимы)
    │   │   ├── bbauth          # 
    │   │   │   ├── vars.yml    #
    │   │   │   └── vault.yml   #
    │   │   └── ghauth          #
    │   │       ├── vars.yml    #
    │   │       └── vault.yml   #
    │   └── prod.ini            # Инвентори стенда prod
    └── test                    # Каталог окружения test
        ├── group_vars          #
        │   ├── myapi           #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   ├── bbauth          #
        │   │   ├── vars.yml    #
        │   │   └── vault.yml   #
        │   └── ghauth          #
        │       ├── vars.yml    #
        │       └── vault.yml   #
        ├── test1.ini           # Инвентори стенда test1 в среде test
        └── test2.ini           # Инвентори стенда test2 в среде test

합산

기사에 따라 변수를 구성한 후 각 변수 파일은 특정 작업을 담당합니다. 그리고 파일에는 특정 작업이 있으므로 각 파일의 정확성을 담당하는 사람을 할당하는 것이 가능해졌습니다. 예를 들어, 시스템 배포 개발자는 플레이북 변수를 올바르게 채울 책임이 있는 반면, 인벤토리에 설명된 입장을 가진 관리자는 변수 인벤토리를 직접 채울 책임이 있습니다.

역할은 자체 인터페이스를 갖춘 자체 개발 단위가 되었으며, 이를 통해 역할 개발자는 역할을 시스템에 맞춰 조정하기보다는 기능을 개발할 수 있었습니다. 이 문제는 특히 캠페인 내 모든 시스템의 공통 역할과 관련이 있습니다.

시스템 관리자는 더 이상 배포 코드를 이해할 필요가 없습니다. 성공적인 배포를 위해 필요한 것은 환경 종속 변수 파일을 채우는 것뿐입니다.

문학

1. Документация

저자

칼류즈니 데니스 알렉산드로비치

출처 : habr.com