플러그인 개념

기존 플러그인을 사용하건, 사용자 정의 플러그인을 개발하건 플러그인의 컨텐츠와 개념을 자세히 아는 것이 좋습니다.

플러그인은 패턴 빌더에 표시되는 컴포넌트, 링크 및 정책을 제공합니다. 패턴 빌더에서 가상 애플리케이션 빌더는 패턴 유형의 플러그인이 표시하는 컴포넌트, 링크 및 정책에서 선택할 수 있습니다. 컴포넌트나 링크에 기여하는 플러그인이 구성될 수 있는 설정, 배치 방법, 가상 애플리케이션의 라이프사이클을 통해 관리되고 구성되는 방법을 비롯한 시맨틱 및 조작을 완전히 결정합니다.

플러그인의 개념

플러그인은 .tgz 아카이브 파일로 패키징되는 파일 콜렉션입니다. 각 플러그인에는 config.json 구성 파일이 포함되어 있어야 합니다. 모델링, 배치, 런타임 및 관리에 사용되는 확장기능을 구현하는 추가 파일은 선택적이며 규칙에 따라 아카이브 파일의 디렉토리 구조에 구성됩니다.

다음 목록은 플러그인 컨텐츠 및 확장기능을 설명합니다.

config.json: 플러그인 구성 파일을 지정하십시오. 플러그인에 필요한 유일한 파일입니다.
appmodel/metadata.json: 가상 애플리케이션의 모델을 빌드하기 위해 패턴 빌더 에서 사용자에게 표시되는 플러그인의 컴포넌트, 링크 및 정책을 지정합니다.
appmodel/tweak.json and appmodel/operation.json: 콘솔의 배치 인렛에서 배치된 가상 애플리케이션 인스턴스 를 변경하기 위한 코드를 제공합니다.
bundles/{name}.jar: 플러그인의 스캐너, 변환기 및 프로비저너를 포함하는 Java™ 아카이브 (JAR) 파일을 지정합니다.
nodeparts/{name}.tgz: 활성화 스크립트가 설치하는 아티팩트를 지정합니다. 워크로드 에이전트는 노드 파트입니다.
parts/{name}.tgz: 워크로드 에이전트가 설치하는 아티팩트를 지정합니다. 이러한 확장 파일은 가상 애플리케이션이 배치된 가상 머신에서 가상 애플리케이션을 모델링, 배치 및 관리하는 방법을 콘솔 과 통신하기 위해 플러그인에 포함되어 있습니다.

플러그인의 컨텐츠가 작동하는 방법에 대한 자세한 정보는 "플러그인 개발 안내서"를 참조하십시오.

파트, 노드 파트 및 패키지

노드 파트는 다른 파트에서 사용할 수 있는 가상 머신의 데이터(예: 스크립트)입니다. 예를 들어, 방화벽 노드 파트는 방화벽의 포트를 열고 닫습니다.

파트는 더 복잡해졌습니다. 샘플 Java Platform, Enterprise Edition 애플리케이션인 tradelite를 고려하십시오. WebSphere® Application Server 의 애플리케이션은 배치된 DB2® 데이터베이스에 액세스합니다. WebSphere Application Server 는 IP 주소, 포트 번호, 사용자 ID및 암호와 같은 정보와 함께 데이터베이스를 사용하도록 구성되어야 합니다. 또한 WebSphere Application Server 가 사용하기 전에 데이터베이스 및 해당 노드를 시작해야 합니다. 이와 같은 복잡한 과정을 관리하기 위해 파트는 역할을 사용하여 배치 과정에서 모든 가상 머신과 소프트웨어의 시작을 조정합니다. 역할은 상태를 가지며 각 상태로 들어갈 때 라이프사이클 스크립트가 있을 수 있습니다.

패키지는 파트, 노드 파트 또는 이 둘의 조합으로 구성되는 콜렉션입니다. 이러한 메커니즘은 플러그인 개발자에게 유용한 메커니즘입니다. 예를 들어, WebSphere Application Server 패키지에는 두 개의 파트가 있습니다. 파트는 PowerPC® 의 AIX® 및 Intel™의 Linux® 와 32비트및 64비트하드웨어 아키텍처에 대해 다릅니다. 두 개의 파트로 구성된 서로 다른 네 개의 세트가 있으므로 파트는 총 8개입니다. 단일 패키지 안에 있는 각 세트에는 운영 체제와 하드웨어 요구사항을 식별하는 고유한 requires 블록이 있습니다. 메가바이트 단위로 최소 메모리 요구사항을 지정하고 기가바이트 단위로 최소 디스크 요구사항을 지정하십시오. 그런 다음 컴포넌트 또는 링크 변환에서 WebSphere Application Server 파트를 포함하고 변환은 사용할 파트 세트를 판별합니다.

패키지에는 이름이 있으며 그 이름은 하나를 제외하고는 모두 고유해야 합니다. default 의 패키지 이름은 특수합니다. default 패키지는 배치의 모든 가상 머신에 자동으로 포함되므로 컴포넌트 또는 링크 변환에 명시적으로 포함되지 않아야 합니다. 이외에도 다수의 플러그인이 기본 패키지를 정의할 수 있습니다. 이 경우에는 모든 기본 정의가 논리적 OR 유니온으로 축적되어 하나의 통합된 기본 패키지를 작성합니다.

파트, 노드 파트 및 패키지가 구현을 구성하기 때문에 사용자는 백그라운드에서 자동화되는 구현에 대한 세부사항 및 의사결정을 몰라도 됩니다.

역할

역할은 가상 머신에서 소프트웨어의 시작을 조정하는 라이프사이클 스크립트를 제공합니다. 파트에서는 역할이 이벤트 알림을 제공합니다. tradelite 샘플 애플리케이션에서와 같이 두 개의 가상 머신을 동기화할 수도 있습니다. WebSphere Application Server 는 DB2 인스턴스가 실행될 때까지 완전히 시작되어 작동할 수 없습니다. 실제로 WebSphere Application Server 인스턴스에는 성공적으로 액세스하기 위해 포트 및 IP 주소와 같은 정보와 DB2 노드의 사용자 ID및 암호가 필요합니다. 연결을 처리하는 데 두 가지 역할이 사용됩니다. WebSphere Application Server 가상 머신의 WebSphere Application Server 역할과 DB2 가상 머신의 DB2 역할입니다. wasdb2 플러그인은 WebSphere Application Server 및 DB2 구성요소 사이의 링크를 제공하며 해당 링크 변환은 DB2 역할에 대한 WAS 역할의 종속성을 작성합니다. DB2 역할이 활성화되면 필수 데이터를 공유 인프라 maestro 데이터 저장소의 역할 네임스페이스로 내보냅니다. 종속성으로 인해 WAS/DB2/changed.py 스크립트가 시작됩니다. 이 스크립트는 DB2 역할에서 내보낸 데이터를 추출하고 이를 사용하여 링크된 DB2 인스턴스를 사용하도록 WebSphere Application Server 인스턴스를 구성한 후 WAS 노드의 상태를 RUNNING로 설정합니다.

애플리케이션 모델 ( 패턴 빌더에서 구성됨) 에서 컴포넌트는 일반적으로 배치된 가상 머신에 해당하며 링크는 일반적으로 이들 간의 종속성에 해당하지만 항상 해당되지는 않습니다. 애플리케이션 모델과 토폴로지 문서는 독립적입니다. 플러그인은 패턴 빌더 분할창에 컴포넌트, 링크 및 정책을 제공합니다. 사용자는 애플리케이션의 논리 보기를 빌드하고 속성 값을 제공합니다. 플러그인에서 제공하는 개념 및 기능을 사용하여 사용자가 작성한 것과 일치하는 배치를 실현하는 데 사용되는 토폴로지 문서 단편을 생성하는 것은 컴포넌트 및 링크 변환에 달려있습니다. 배치되는 가상 머신을 생성하기 위해 컴포넌트 변환은 vm-templates JSON 배열에 vm-template 요소를 생성합니다. 배열 값에서 알 수 있듯이 다수의 템플리트가 생성될 수 있습니다. 종속성을 위해 링크 변환은 역할 depends 요소를 생성할 것으로 예상됩니다. 링크 변환을 통해 소스 및 대상 역할을 식별해야 합니다. 링크 변환에서 리턴하는 JSON은 식별된 소스 역할의 depends 요소로 소스 vm-template에 삽입됩니다.

컴포넌트에 대한 정보와 애플리케이션 모델에서 컴포넌트가 정의되는 방법에 대한 정보는 "애플리케이션 모델링"을 참조하십시오.

토폴로지 문서

두 가지 주요 토폴로지 문서 기능이 컴포넌트 및 링크 변환에서 수행해야 하는 작업을 이해하는 데 중요합니다.

vm-templates
역할

토폴로지 문서는 JSON 오브젝트입니다. 토폴로지 문서에 있는 vm-templates 요소는 vm-template 요소의 JSON 배열입니다. 이 배열에 있는 각 요소는 배치될 가상 머신을 나타냅니다. 컴포넌트는 vm-templates에 해당하고 링크는 컴포넌트 사이의 링크 또는 종속성에 해당합니다. 그러나 컴포넌트는 vm-template를 생성하지 않아도 되며 둘 이상을 생성할 수도 있습니다. 따라서 컴포넌트는 0개 이상의 vm-templates를 생성할 것으로 예상됩니다.

패턴 유형의 다음 태스크는 배치된 각 가상 머신에 적절한 소프트웨어를 설치 및 구성하고 시작하는 것입니다. 먼저, 각 가상 머신에 소프트웨어를 배치해야 합니다. 소프트웨어는 파트 및 노드 파트 요소에 패키징되고 이러한 요소는 플러그인에 포함된 config.json 파일에 정의됩니다. 이러한 parts 는 config.json의 packages 에 추가로 패키지되며, 파트 및 노드 파트를 특정 가상 유형 (예: Intel x86 또는 PowerPC 아키텍처, 32비트또는 64비트프로세서, Linux 또는 AIX 운영 체제) 에 연관시키기 위해 requires 요소로 추가 규정될 수 있습니다. 가상 머신 프로세서, 메모리 및 디스크 요구사항도 지정할 수 있습니다. 변환 과정에서 vm-template 오브젝트의 packages 요소에 패키지 이름을 삽입하여 가상 머신에 설치할 소프트웨어를 지정합니다. packages 요소는 JSON 배열입니다.

다음으로 구현에 파트 또는 노드 파트를 사용할지 여부를 결정해야 합니다.

노드 파트는 활성화 스크립트에 의해 설치되며 일반적으로 운영 체제를 기능 보강하기 위한 2진 파일 및 스크립트를 포함합니다. 노드 파트는 setup.py 스크립트를 포함하며 .py 또는 .sh 스크립트를 설치하고 시작할 수 있습니다. 이 활동은 에이전트가 시작되기 전에 발생합니다. 예를 들어, 방화벽 노드 파트는 쉘 스크립트 및 Python 스크립트가 가상 머신에서 방화벽 설정을 조작하는 데 사용할 일반 API를 정의합니다. 활성화 동안 각 노드 파트가 /0config에 다운로드되고 압축이 풀린 후 해당 setup/setup.py 스크립트(있는 경우)가 시작됩니다. 모든 노드 파트가 설정된 후에는 공통/설치의 설치 스크립트가 영숫자 순서로 시작됩니다 (0_install1.sh, 1_install1.py, ...)마지막으로 common/start 의 시작 스크립트가 영숫자 순서로 시작됩니다. 워크로드 에이전트에서 제공하는 지원이 필요 없는 경우에는 노드 파트를 사용하십시오.

파트는 워크로드 에이전트에 의해 설치되며 일반적으로 역할 및 종속 항목과 연관된 2진 파일과 라이프사이클 스크립트를 포함합니다. 먼저, 각 파트가 다운로드되고 압축이 풀리며 해당 install.py 스크립트(있는 경우)가 실행됩니다.

역할은 가상 애플리케이션 인스턴스에서 관리되는 엔티티를 나타냅니다. 각 role 는 해당 vm-template내에 포함된 JSON 오브젝트에 의해 토폴로지 문서에 설명되어 있습니다.

역할은 각 역할의 라이프사이클 스크립트를 실행하여 병렬로 시작됩니다. 역할은 상태를 가지며 역할의 일반적인 상태 진행은 다음과 같습니다.

INITIAL: 역할이 초기 상태에서 시작됩니다. 각 역할의 install.py 스크립트가 시작됩니다. 이 스크립트가 완료되면 역할이 자동으로 INSTALLED 상태로 진행됩니다. install.py 스크립트가 실패하면 역할이 ERROR 상태로 이동하고 배치가 실패합니다.
INSTALLED: 이 상태에서 configure.py 스크립트(있는 경우)가 실행됩니다.
CONFIGURING: 이 상태에서 start.py 스크립트(있는 경우)가 실행됩니다.
STARTING: 자동 상태 설정이 중지합니다. 라이프사이클 스크립트가 명시적으로 역할 상태를 RUNNING으로 설정해야 합니다.
RUNNING

라이프사이클 스크립트에는 maestro 모듈에서 액세스할 수 있는 상태가 다수 있습니다. 이러한 상태에는 토폴로지 문서에 있는 대부분의 관련 데이터가 포함되어 있으며, 이것이 컴포넌트 및 링크 변환을 통해 속성과 데이터가 배치된 가상 머신의 라이프사이클 스크립트에 전달되는 방법입니다.

역할은 가상 머신의 시작, 시스템 종료 및 라이프사이클 관리에 참여할 뿐만 아니라 이벤트에도 반응합니다. 역할은 주로 애플리케이션 모델에서 컴포넌트 간에 링크를 구현하는 데 사용됩니다. wasdb2 플러그인은 WebSphere Application Server 노드에서 실행 중인 WAR, EAR 또는 OSGiEBA 파일과 여기에서 액세스하는 데이터베이스 인스턴스 간의 링크를 구현합니다. DB2 데이터베이스 인스턴스에는 DB2를 시작하는 데 사용되는 DB2 역할이 있으며 라이프사이클 스크립트에서 적절한 시간에 속성 및 데이터를 전달하고 사용합니다. DB2 역할이 RUNNING 상태로 이동하면 start.py 스크립트에서 일부 유용한 데이터 항목 (IP 주소, 포트 번호, 데이터베이스 이름, 사용자 ID및 비밀번호) 을 내보냅니다. wasdb2 플러그인은 응용프로그램 모델에서 링크 구현의 일부로 DB2 노드의 DB2 역할에 종속되도록 WebSphere Application Server 노드에서 WebSphere Application Server 역할을 설정합니다. WebSphere Application Server 및 DB2 역할이 모두 RUNNING 상태로 이동하면 WAS/DB2/changed.py 스크립트가 시작됩니다. 그런 다음 해당 스크립트는 DB2 역할이 DB2 노드에서 익스포트한 데이터를 읽고 이를 사용하여 응용프로그램 모델에서 링크된 DB2 데이터베이스에 액세스하도록 WebSphere Application Server 노드를 구성합니다. 따라서 서로 종속되도록 역할을 설정하는 것이 시작 과정에서 종속성을 처리하고 동기화하는 데 중요합니다. 시작 과정에서 배치된 가상 머신 간에 정보를 전달해야 하는 경우 구현에 역할 및 종속 역할을 사용하십시오.