솔트 플러그-인
솔트 접근법에 대한 어떤 논의도 플러그인에 대한 논의 없이는 불완전할 것이다. 플러그인과 솔트의 플러그형 아키텍처를 이해하는 것은 종종 솔트 수사관을 솔트 전도사로 바꾸는 “유레카”의 순간이다.
기본적인 설명은 이렇다: 솔트의 핵심 프레임워크는 고속 통신과 이벤트 버스를 제공한다. 이 프레임워크는 관리되는 시스템을 연결하고 인증하며 이러한 시스템에서 알림을 보낼 수 있는 방법을 제공합니다.
이 코어 프레임워크 위에 Salt의 나머지 기능은 느슨하게 결합된 플러그형 하위 시스템의 집합으로 노출된다.
플러그형 하위 시스템
Salt에는 20개 이상의 플러그형 하위 시스템이 포함되어 있지만 대부분의 사용자는 시스템을 직접 관리하는 데 사용되는 소수의 하위 시스템에만 관심이 있습니다. 다음 표에는 Salt에서 가장 일반적인 일부 하위 시스템의 목록이 나와 있습니다.
| Authentication | 작업을 실행하기 전에 사용자에게 권한을 부여합니다. |
| File server | 파일을 배포합니다. |
| Secure data store | 사용자 정의 변수 및 기타 데이터를 안전하게 사용할 수 있도록 합니다. |
| State representation | 인프라 및 시스템 구성을 설명합니다. |
| Return formatter | 작업 결과를 표준화된 데이터 구조로 포맷합니다. |
| Result cache | 작업 결과를 장기 저장소로 보냅니다. |
| Remote execution | 소프트웨어 설치, 파일 배포 및 시스템 관리에 필요한 기타 작업을 광범위하게 실행합니다. |
| Configuration | 대상 시스템을 원하는 상태와 일치하도록 구성합니다. |
다음 다이어그램은 각 하위 시스템에 대해 가장 일반적인 플러그인과 함께 몇 개의 공통 하위 시스템을 보여줍니다.
이 다이어그램은 사용 가능한 하위 시스템과 플러그 인 중 일부만 보여주지만, Salt의 일반적인 아키텍처에 대한 감각을 제공합니다.
"플러그블(PLUGGABLE)"은 무엇을 의미합니까?
Salt는 하위 시스템에 대해 작업을 수행하는 기본 제공 방식을 정의하지 않으며 각 하위 시스템은 작업을 플러그인으로 위임하기만 합니다. Salt는 각 시스템에 기본 플러그인을 제공하지만 대부분의 경우 플러그인을 변경하는 것은 구성 파일을 업데이트하는 것만큼 간단합니다. 이 신축성이 솔트를 매우 유연하게 만드는 것이다.
작업 실행 중 하위 시스템
작업이 실행될 때 작업을 처리하기 위해 여러 Salt 하위 시스템이 호출됩니다. 다음 다이어그램은 일반적인 상태 실행 또는 원격 실행 작업의 하위 시스템 흐름을 보여 줍니다.
각 단계에서 서브시스템은 구성된 플러그인으로 작업을 위임합니다. 예를 들어 7단계의 작업 반환 장치 플러그인은 MySQL을 포함하여 30개의 플러그인 중 하나이거나, 다시 사용하거나, 전혀 구성되지 않을 수 있습니다(4단계 이후 작업 반환 장치 플러그인도 관리되는 시스템에서 직접 실행할 수 있습니다).
각 단계마다 작업을 수행하는 데 사용할 수 있는 많은 플러그인이 있으므로 수백 개의 Salt 구성 및 워크플로가 가능합니다.
플러그인? 소금 모듈에 대해 말하는 것처럼 들리네요! 솔트에서 플러그인은 파이썬 이름인 모듈로 알려져 있다. 각 플러그인은 파이썬 모듈이기 때문에 대부분의 경우 단순히 모듈, 또는 더 정확하게 Salt 하위 시스템 모듈(Salt auth 모듈, Salt files 서버 모듈 등)이라고 불린다. 각 Salt 모듈이 Salt의 많은 하위 시스템 중 하나를 확장하는 플러그인이라는 것을 이해한다면, 여러분은 이 관계를 충분히 이해할 수 있을 것입니다.
유연성
이러한 유연성은 솔트를 매우 강력하고 사용자 정의가 가능한 도구로 만들지만, 도구에 대해 배울 때 표준 질문에 답하는 것도 약간 어렵게 만듭니다.
재미를 위해, “기술적으로 정확한” 접근 방식을 취하고 Salt에 대한 몇 가지 일반적인 질문에 대답해 봅시다.
- Salt 작업은 어떻게 시작합니까? – Python, REST API, 명령줄 또는 Salt의 내장 스케줄러를 사용하여 호출할 수 있는 모든 인터페이스에서 시작합니다.
- Salt 형식은 어떻게 됩니까? – YAML, JSON, 일반 텍스트, Python 데이터 구조 및 기타 여러 형식이며, 단일 인수를 사용하여 언제든지 형식을 변경할 수 있습니다.
- Salt는 구성 선언에 어떤 형식을 사용합니까? – 사용 사례에 따라 지원되는 15가지 형식 중 하나를 선택할 수 있으며, 사용자가 선택할 수도 있습니다. 형식은 파일 단위로 지정되므로 여러 형식을 동시에 사용할 수 있습니다.
- 결과는 어디에 저장됩니까? 원하는 곳에 30가지 옵션이 있습니다!
대화에 있어서 여러분을 매우 성가시게 하는 것 외에도, 이런 식으로 질문에 대답하는 것은 경영에 대한 솔트 접근법에 대해 뭔가를 말해줍니다. 인프라를 잘 아시겠지만, 오늘날의 복잡한 환경에서는 어떤 작업도 수행할 수 있는 최선의 방법이 없습니다.
Salt는 대부분의 Salt 사용자가 사용하는 탁월한 기본 설정으로 즉시 제공됩니다. 요점은 언제, 필요할 때 유연성이 있다는 것이다.
솔트 구성요소
Salt의 플러그형 하위 시스템에 대한 새로운 지식을 통해 각 Salt 구성 요소가 해당 플러그인이 포함된 Salt의 플러그형 하위 시스템이라는 사실을 이해하게 되었습니다. 솔트 그레인? 솔트 필라? 솔트 러너? 소금 주자등은요? 모든 플러그형 하위 시스템은 쉽게 확장할 수 있습니다.
가상 모듈
여기서 많은 내용을 다루었지만, 모듈 관련해서는 추가로 해결해야 할 사항이 하나 더 있습니다. 앞서 솔트가 운영 체제의 기본 세부 정보를 어떻게 추상화하는지 설명했던 것 기억하십니까? 솔트가 이러한 추상화를 달성하는 한 가지 방법은 가상 모듈을 사용하는 것입니다.
일부 관리 작업은 운영 체제 간에 매우 다르게 수행되므로 플러그인을 작성할 때 이들 간에 재사용할 수 있는 코드가 거의 없습니다.
예를 들어, 데비안 시스템의 패키지 관리는 aptpkg이라는 실행 모듈을 사용하여 수행됩니다. Redhat에서는 yumpkg이라는 실행 모듈을 사용하여 수행됩니다(분명한 이유로). Salt를 사용한 적이 있다면 Salt가 pkg 원격 실행 모듈을 호출하여 패키지 관리를 수행하며 모든 OS에서 작동한다는 것을 알 수 있습니다.
이러한 유형의 추상화를 사용하도록 설정하려면 Salt는 가상 모듈 이름을 사용하여 이러한 유형의 모듈을 로드합니다. aptpkg 모듈에는 기본적으로 “Debian 시스템인 경우 이 모듈을 pkg로 로드하십시오. 그렇지 않으면, 이걸 로드하지 마세요!” Redhat 또는 CentOS에 대한 확인과 함께 yumpkg에도 유사한 코드가 있습니다. 이렇게 하면 동일한 작업을 수행하기 위해 여러 모듈이 존재할 수 있지만 가상 이름은 하나만 로드됩니다.
비가상 모듈이 동작을 이해하려면 설명서를 읽어야 하는 경우가 많으므로 모듈 설명서를 읽을 때는 이 점을 유념하십시오. 솔트 모듈 내에서 __virtualname__을 검색하여 솔트가 해당 모듈을 로드할 때 사용하는 이름을 확인할 수 있습니다.
아직도 나랑 같이 있어? 좋아요. 그럼 이제 솔트가 와이어에서 어떻게 소통하는지 얘기해보죠.
출처 : https://docs.saltproject.io/en/getstarted/system/plugins.html
