Ansible 테스트를 시작하고 XNUMX년 안에 프로젝트를 리팩토링하며 당황하지 않는 방법

이것은 대본입니다 공연 에 DevOps-40 2020-03-18:

두 번째 커밋부터 모든 코드는 레거시가 됩니다. 초기 아이디어는 가혹한 현실과 달라지기 시작합니다. 이것은 좋은 것도 나쁜 것도 아니며, 논쟁하기 어렵고 받아들여야 하는 당연한 사실입니다. 이 프로세스의 일부는 리팩토링입니다. 인프라를 코드로 리팩터링. XNUMX년 안에 Ansible을 리팩터링하는 방법에 대한 이야기를 시작해 보세요.

유산의 탄생

1일 차: 최초의 환자

옛날 옛적에 조건부 프로젝트가있었습니다. Dev 개발팀과 Ops 엔지니어가 있었습니다. 그들은 동일한 문제, 즉 서버를 배포하고 애플리케이션을 실행하는 방법을 해결하고 있었습니다. 문제는 각 팀이 각자의 방식으로 이 문제를 해결했다는 점이다. 프로젝트에서는 Ansible을 사용하여 Dev 팀과 Ops 팀 간의 지식을 동기화하기로 결정했습니다.

Day #89: 유산의 탄생

스스로도 눈치 채지 못한 채 최선을 다하고 싶었지만 유산으로 판명되었습니다. 어떻게 이런 일이 발생하나요?

• 여기서 긴급한 작업이 있습니다. 지저분한 해킹을 한 다음 고치겠습니다.
• 문서를 작성할 필요가 없으며 여기서 무슨 일이 일어나고 있는지 모든 것이 명확합니다.
• 저는 Ansible/Python/Bash/Terraform을 알고 있습니다! 내가 어떻게 피할 수 있는지 보세요!
• 저는 풀 스택 오버플로 개발자이고 이것을 stackoverflow에서 복사했습니다. 어떻게 작동하는지 모르겠지만 멋져 보이고 문제가 해결됩니다.

결과적으로 문서가 없고 기능이 무엇인지, 필요한지 여부가 명확하지 않은 이해할 수 없는 유형의 코드를 얻을 수 있지만 문제는 코드를 개발하고 수정하고 목발과 지지대를 추가해야 한다는 것입니다. , 상황을 더욱 악화시킵니다.

- hosts: localhost
  tasks:
    - shell: echo -n Z >> a.txt && cat a.txt
      register: output
      delay: 1
      retries: 5
      until: not output.stdout.find("ZZZ")

Day #109: 문제 인식

처음에 구상하고 구현한 IaC 모델은 더 이상 사용자/비즈니스/다른 팀의 요구 사항을 충족하지 않으며 인프라 변경 시간이 더 이상 허용되지 않습니다. 이 순간, 조치를 취해야 할 때라는 것을 이해하게 됩니다.

IaC 리팩토링

Day #139: 리팩토링이 정말 필요한가요?

서둘러 리팩토링을 시작하기 전에 다음과 같은 몇 가지 중요한 질문에 답해야 합니다.

1. 이 모든 것이 왜 필요합니까?
2. 시간 있어요?
3. 지식은 충분합니까?

질문에 대답하는 방법을 모른다면 리팩토링이 시작되기도 전에 종료되거나 상황이 더 악화될 수 있습니다. 왜냐하면 경험이 있었습니다( 200줄의 인프라 코드를 테스트하면서 배운 것) 그런 다음 프로젝트는 역할을 수정하고 테스트를 통해 이를 다루기 위한 도움 요청을 받았습니다.

Day #149: 리팩토링 준비

가장 먼저 준비하는 것이 있습니다. 우리가 무엇을 할 것인지 결정하십시오. 이를 위해 우리는 소통하고 문제 영역을 찾아 해결 방법을 모색합니다. 우리는 결과 개념을 어떻게든 기록합니다(예: 합류 기사). 그래서 질문이 발생할 때 "무엇이 가장 좋은가?" 또는 "어느 것이 맞나요?" 우리는 길을 잃지 않았습니다. 우리의 경우에는 이 아이디어를 고수했습니다. 나누고 지배하다: 인프라를 작은 조각/벽돌로 나눕니다. 이 접근 방식을 사용하면 인프라의 격리된 부분을 가져와서 그것이 수행하는 작업을 이해하고 테스트를 통해 다루며 손상될 염려 없이 변경할 수 있습니다.

인프라 테스트가 초석이 되는 것으로 나타났으며 여기서는 인프라 테스트 피라미드를 언급할 가치가 있습니다. 개발 중인 아이디어와 정확히 동일하지만 인프라에 대한 것입니다. 들여쓰기와 같은 간단한 사항을 확인하는 값싸고 빠른 테스트에서 전체 인프라를 배포하는 값비싼 본격적인 테스트로 전환하고 있습니다.

Ansible 테스트 시도

프로젝트에서 Ansible 테스트를 어떻게 다루었는지 설명하기 전에, 내린 결정의 맥락을 이해하기 위해 이전에 사용할 기회가 있었던 시도와 접근 방식을 설명하겠습니다.

-997일차: SDS 제공

처음 Ansible을 테스트한 것은 SDS(Software Defined Storage)를 개발하는 프로젝트에서였습니다. 이 주제에 대한 별도의 기사가 있습니다.
배포판을 테스트할 때 목발 위에 자전거를 부수는 방법, 그러나 간단히 말해서 우리는 역전된 테스트 피라미드로 끝나고 테스트는 한 역할에 60~90분을 소비했는데 이는 오랜 시간입니다. 기초는 e2e 테스트였습니다. 우리는 완전한 설치를 배포한 다음 테스트했습니다. 더욱 더 괴로운 것은 자신이 만든 자전거였다. 하지만 이 솔루션이 효과가 있었고 안정적인 릴리스가 가능했다는 점은 인정해야 합니다.

Day # -701: Ansible 및 테스트 주방

Ansible 테스트 아이디어의 개발은 바로 test kitchen/kitchen-ci 및 inspec과 같은 기성 도구를 사용하는 것이었습니다. 선택은 Ruby에 대한 지식에 따라 결정되었습니다(자세한 내용은 Habré에 대한 기사를 참조하세요: YML 프로그래머는 Ansible 테스트를 꿈꾸나요?) 40개 역할에 대해 약 10분 정도 더 빠르게 작업했습니다. 우리는 가상 머신 팩을 만들고 내부에서 테스트를 실행했습니다.

일반적으로 솔루션은 효과가 있었지만 이질성으로 인해 일부 침전물이 발생했습니다. 테스트 대상자가 기본 역할 13개와 작은 역할을 결합한 메타 역할 2개로 늘어나자 갑자기 테스트가 거의 70배 더 길어진 2분 동안 실행되기 시작했습니다. XP(익스트림 프로그래밍) 방식에 대해 이야기하기가 어려웠습니다. 왜냐하면... 아무도 70분을 기다리고 싶어하지 않습니다. 이것이 접근 방식을 변경한 이유였습니다.

Day # -601: Ansible 및 분자

개념적으로 이는 testkitchen과 유사하지만 역할 테스트를 docker로 이동하고 스택을 변경했습니다. 그 결과 20개 역할에 대한 시간이 25~7분 정도로 안정적으로 단축됐다.

테스트된 역할 수를 17개로 늘리고 45개 역할을 린팅함으로써 28개의 젠킨스 슬레이브에서 2분 만에 이를 실행했습니다.

Day #167: 프로젝트에 Ansible 테스트 추가

아마도 리팩토링 작업을 서둘러 수행하는 것은 불가능할 것입니다. 작업은 작은 조각으로 나누어 티스푼으로 코끼리를 한 조각씩 먹을 수 있도록 측정 가능해야 합니다. 올바른 방향으로 움직이고 있는지, 얼마나 가야 하는지에 대한 이해가 있어야 합니다.

일반적으로 어떻게 하든 상관없이 종이에 글을 써도 되고, 옷장에 스티커를 붙여도 되고, Jira에서 작업을 생성해도 되고, Google Docs를 열어서 현재 상태를 적어도 됩니다. 거기. 그 과정이 즉각적이지 않고 길고 지루할 것이라는 사실 때문에 다리가 자랍니다. 리팩토링 중에 아이디어가 고갈되고, 피곤해지고, 압도당하는 것을 누구도 원하지 않을 것입니다.

리팩토링은 간단합니다.

• 먹다.
• 자.
• 코드
• IaC 테스트.
• 반복

그리고 우리는 의도한 목표에 도달할 때까지 이것을 반복합니다.

모든 것을 즉시 테스트하는 것은 불가능할 수 있으므로 첫 번째 작업은 Linting과 구문 확인부터 시작하는 것이었습니다.

181일차: 그린 빌드 마스터

Linting은 Green Build Master를 향한 작은 첫걸음입니다. 거의 모든 것이 중단되지는 않지만 Jenkins에서 프로세스를 디버깅하고 친환경 빌드를 만들 수 있습니다. 아이디어는 팀 간의 습관을 개발하는 것입니다.

• 빨간색 테스트는 나쁘다.
• 나는 뭔가를 고치는 동시에 코드를 이전보다 조금 더 좋게 만들기 위해 왔습니다.

Day #193: Linting부터 단위 테스트까지

코드를 마스터로 가져오는 프로세스를 구축하면 단계별 개선 프로세스를 시작할 수 있습니다. Linting을 시작 역할로 대체하면 멱등성 없이도 수행할 수 있습니다. 역할을 적용하는 방법과 작동 방식을 이해해야 합니다.

Day #211: 단위 테스트부터 통합 테스트까지

대부분의 역할이 단위 테스트로 처리되고 모든 것이 린트되면 통합 테스트 추가로 넘어갈 수 있습니다. 저것들. 인프라의 단일 브릭이 아니라 전체 인스턴스 구성과 같은 브릭의 조합을 테스트합니다.

jenkins를 사용하여 역할/플레이북을 병렬로 연결한 다음 컨테이너의 단위 테스트, 마지막으로 통합 테스트를 수행하는 여러 단계를 생성했습니다.

Jenkins + Docker + Ansible = 테스트

1. 저장소를 체크아웃하고 빌드 단계를 생성하세요.
2. Lint 플레이북 단계를 병렬로 실행합니다.
3. 린트 역할 단계를 병렬로 실행합니다.
4. 구문 검사 역할 단계를 병렬로 실행합니다.
5. 테스트 역할 단계를 병렬로 실행합니다.
   1. 린트 역할.
   2. 다른 역할에 대한 종속성을 확인하세요.
   3. 구문을 확인하세요.
   4. 도커 인스턴스 생성
   5. 분자/기본/playbook.yml을 실행합니다.
   6. 멱등성을 확인하세요.
6. 통합 테스트 실행
7. 마감재

Day #271: 버스 팩터

처음에는 리팩토링을 XNUMX~XNUMX명의 소규모 그룹으로 진행했습니다. 그들은 마스터에서 코드를 검토했습니다. 시간이 지남에 따라 팀은 코드 작성 방법에 대한 지식을 개발하고 코드 검토를 통해 인프라와 작동 방식에 대한 지식을 전파하는 데 기여했습니다. 여기서 하이라이트는 일정에 따라 리뷰어를 한 명씩 선정했다는 것입니다. 어느 정도 확률로 새로운 기반 시설로 올라갈 수 있습니다.

그리고 여기는 편안해야 해요. 검토하고, 어떤 작업이 수행되었는지, 토론 내역을 프레임워크 내에서 확인하는 것이 편리합니다. 우리는 jenkins + bitbucket + jira를 통합했습니다.

그러나 리뷰는 만병통치약이 아니며, 어쩌다 보니 우리는 마스터 코드에 들어가 실패 테스트를 하게 되었습니다.

- get_url:
    url: "{{ actk_certs }}/{{ item.1 }}"
    dest: "{{ actk_src_tmp }}/"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ item.1 }}"
    dest: "{{ actk_dst_tmp }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"

그런 다음 그들은 그것을 고쳤지만 잔여물은 남아 있었습니다.

get_url:
    url: "{{ actk_certs }}/{{ actk_item }}"
    dest: "{{ actk_src_tmp }}/{{ actk_item }}"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ actk_item }}"
    dest: "{{ actk_dst_tmp }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"

Day #311: 테스트 속도 향상

시간이 지남에 따라 더 많은 테스트가 있었고 빌드는 최악의 경우 최대 XNUMX시간까지 느리게 실행되었습니다. 레트로 중 하나에는 "테스트가 있으면 좋지만 느리다"라는 문구가 있습니다. 결과적으로 우리는 가상 머신에 대한 통합 테스트를 포기하고 Docker에 맞게 조정하여 더 빠르게 만들었습니다. 또한 사용되는 도구 수를 줄이기 위해 testinfra를 ansible 검증자로 교체했습니다.

엄밀히 말하면 일련의 조치가 있었습니다.

1. 도커로 전환하세요.
2. 종속성으로 인해 중복되는 역할 테스트를 제거합니다.
3. 노예의 수를 늘리십시오.
4. 테스트 실행 순서.
5. 린트 능력 모두 하나의 명령으로 로컬로.

그 결과 젠킨스의 파이프라인도 통합되었습니다.

1. 빌드 단계를 생성합니다.
2. 모두 병렬로 린트합니다.
3. 테스트 역할 단계를 병렬로 실행합니다.
4. 마침.

교훈

전역 변수 피하기

Ansible은 전역 변수를 사용합니다. 다음 형식의 부분 해결 방법이 있습니다. private_role_vars, 그러나 이것은 만병 통치약이 아닙니다.

예를 들어 보겠습니다. 우리가 가지자 role_a и role_b

# cat role_a/defaults/main.yml
---
msg: a

# cat role_a/tasks/main.yml
---
- debug:
    msg: role_a={{ msg }}

# cat role_b/defaults/main.yml
---
msg: b

# cat role_b/tasks/main.yml
---
- set_fact:
    msg: b
- debug:
    msg: role_b={{ msg }}

- hosts: localhost
  vars:
    msg: hello
  roles:
    - role: role_a
    - role: role_b
  tasks:
    - debug:
        msg: play={{msg}}

재미있는 점은 역할이 나열된 순서와 같이 항상 명확하지 않은 사항에 따라 플레이북의 결과가 달라진다는 것입니다. 불행히도 이것이 Ansible의 특성이며 수행할 수 있는 가장 좋은 방법은 일종의 합의를 사용하는 것입니다. 예를 들어 역할 내에서는 이 역할에 설명된 변수만 사용합니다.

BAD: 전역 변수를 사용합니다.

# cat roles/some_role/tasks/main.yml
---
debug:
  var: java_home

좋은: V defaults 필요한 변수를 정의하고 나중에 해당 변수만 사용하십시오.

# cat roles/some_role/defaults/main.yml
---
r__java_home:
 "{{ java_home | default('/path') }}"

# cat roles/some_role/tasks/main.yml
---
debug:
  var: r__java_home

접두사 역할 변수

BAD: 전역 변수를 사용합니다.

# cat roles/some_role/defaults/main.yml
---
db_port: 5432

좋은: 변수에 대한 역할에서는 역할 이름 앞에 변수를 사용하십시오. 이렇게 하면 인벤토리를 보면 무슨 일이 일어나고 있는지 더 쉽게 이해할 수 있습니다.

# cat roles/some_role/defaults/main.yml
---
some_role__db_port: 5432

루프 제어 변수 사용

BAD: 루프에서 표준 변수 사용 item, 이 작업/플레이북이 어딘가에 포함되어 있으면 예기치 않은 동작이 발생할 수 있습니다.

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item }}"
      loop:
        - item1
        - item2

좋은: 다음을 통해 루프의 변수를 재정의합니다. loop_var.

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item_name }}"
      loop:
        - item1
        - item2
      loop_control:
        loop_var: item_name

입력변수 확인

우리는 변수 접두사를 사용하는 데 동의했습니다. 예상대로 정의되었는지, 예를 들어 빈 값으로 재정의되지 않았는지 확인하는 것은 불필요한 일이 아닙니다.

좋은: 변수를 확인합니다.

- name: "Verify that required string variables are defined"
  assert:
    that: ahs_var is defined and ahs_var | length > 0 and ahs_var != None
    fail_msg: "{{ ahs_var }} needs to be set for the role to work "
    success_msg: "Required variables {{ ahs_var }} is defined"
  loop_control:
    loop_var: ahs_var
  with_items:
    - ahs_item1
    - ahs_item2
    - ahs_item3

해시 사전을 피하고 평면 구조를 사용하세요.

역할의 매개변수 중 하나에 해시/사전이 필요한 경우 하위 매개변수 중 하나를 변경하려면 전체 해시/사전을 재정의해야 하므로 구성이 복잡해집니다.

BAD: 해시/사전을 사용합니다.

---
user:
  name: admin
  group: admin

좋은: 플랫 변수 구조를 사용합니다.

---
user_name: admin
user_group: "{{ user_name }}"

멱등성 플레이북 및 역할 만들기

역할과 플레이북은 멱등원이어야 합니다. 구성 드리프트와 무언가 손상에 대한 두려움을 줄입니다. 그러나 분자를 사용하면 이것이 기본 동작입니다.

명령 셸 모듈을 사용하지 마세요.

쉘 모듈을 사용하면 Ansible의 핵심인 선언적 패러다임 대신 명령형 설명 패러다임이 생성됩니다.

분자를 통해 역할 테스트

분자는 매우 유연한 존재입니다. 몇 가지 시나리오를 살펴보겠습니다.

분자 다중 인스턴스

В molecule.yml 섹션에서 platforms 배포할 수 있는 많은 호스트를 설명할 수 있습니다.

---
    driver:
      name: docker
    platforms:
      - name: postgresql-instance
        hostname: postgresql-instance
        image: registry.example.com/postgres10:latest
        pre_build_image: true
        override_command: false
        network_mode: host
      - name: app-instance
        hostname: app-instance
        pre_build_image: true
        image: registry.example.com/docker_centos_ansible_tests
        network_mode: host

따라서 이러한 호스트는 다음과 같습니다. converge.yml 사용:

---
- name: Converge all
  hosts: all
  vars:
    ansible_user: root
  roles:
    - role: some_role

- name: Converge db
  hosts: db-instance
  roles:
    - role: some_db_role

- name: Converge app
  hosts: app-instance
  roles:
    - role: some_app_role

Ansible 검증자

분자에서는 ansible을 사용하여 인스턴스가 올바르게 구성되었는지 확인할 수 있으며, 이는 릴리스 3부터 기본값이었습니다. testinfra/inspec만큼 유연하지는 않지만 파일 내용이 예상과 일치하는지 확인할 수 있습니다.

---
- name: Verify
  hosts: all
  tasks:
    - name: copy config
      copy:
        src: expected_standalone.conf
        dest: /root/wildfly/bin/standalone.conf
        mode: "0644"
        owner: root
        group: root
      register: config_copy_result

    - name: Certify that standalone.conf changed
      assert:
        that: not config_copy_result.changed

또는 서비스를 배포하고 사용할 수 있을 때까지 기다린 후 연기 테스트를 수행합니다.

---
  - name: Verify
    hosts: solr
    tasks:
      - command: /blah/solr/bin/solr start -s /solr_home -p 8983 -force
      - uri:
          url: http://127.0.0.1:8983/solr
          method: GET
          status_code: 200
        register: uri_result
        until: uri_result is not failed
        retries: 12
        delay: 10
      - name: Post documents to solr
        command: /blah/solr/bin/post -c master /exampledocs/books.csv

모듈과 플러그인에 복잡한 로직을 넣습니다.

Ansible은 선언적 접근 방식을 옹호하므로 코드 분기, 데이터 변환, 셸 모듈을 수행할 때 코드를 읽기가 어려워집니다. 이 문제를 해결하고 이해하기 쉽게 유지하려면 자신만의 모듈을 만들어 이러한 복잡성을 해결하는 것이 불필요한 것은 아닙니다.

팁과 요령 요약

1. 전역 변수를 피하세요.
2. 접두사 역할 변수.
3. 루프 제어 변수를 사용합니다.
4. 입력변수를 확인하세요.
5. 해시 사전을 피하고 평면 구조를 사용하십시오.
6. 멱등성 플레이북 및 역할을 만듭니다.
7. 명령 셸 모듈을 사용하지 마세요.
8. 분자를 통해 역할을 테스트하세요.
9. 모듈과 플러그인에 복잡한 로직을 추가하세요.

결론

IaC가 있더라도 프로젝트의 인프라를 그냥 리팩터링할 수는 없습니다. 이는 인내와 시간, 지식이 필요한 긴 과정입니다.

링크

• 슬라이드 Ansible을 테스트하고 미쳐버리지 않는 방법
• Video Ansible을 테스트하고 미쳐버리지 않는 방법
• 200줄의 인프라 코드를 테스트하면서 배운 것
• Ansible: 120개월 만에 Coreos에서 Centos로 18개의 VM 구성 마이그레이션
• 배포판을 테스트할 때 목발 위에 자전거를 부수는 방법
• 가능하다면 저를 테스트해 보세요. 아니면 YML 프로그래머가 Ansible 테스트를 꿈꾸나요?
• 멋진 IaC 테스트 기사, 연설 및 링크 목록
• 크로스 포스트
• Angielski 버전

UPD1 2020.05.01 20:30 — 플레이북의 기본 프로파일링을 위해 다음을 사용할 수 있습니다. callback_whitelist = profile_tasks 오랫동안 정확히 무엇이 작동하는지 이해합니다. 그런 다음 우리는 Ansible 가속 클래식. 당신은 또한 시도할 수 있습니다 미토겐
UPD2 2020.05.03 16:34 - Angielski 버전

출처 : habr.com