백엔드 플러그인
플러그인은 Backstage 백엔드의 실제 기본 기능을 제공해요.
출처: 문서
본문
플러그인은 Backstage 백엔드의 실제 기본 기능을 제공해요. 각 플러그인은 다른 모든 플러그인과 완전히 독립적으로 작동하며 네트워크 호출을 통해서만 서로 통신해요. 이는 플러그인 사이에 강한 격리가 있고 각 플러그인을 별도의 마이크로서비스로 간주할 수 있음을 의미해요. 기본 Backstage 프로젝트는 모든 플러그인을 단일 백엔드 안에 설치하지만, 이 설정을 여러 백엔드로 나누고 각 백엔드에 하나 이상의 플러그인을 두는 것도 가능해요.
플러그인 정의
플러그인은 createBackendPlugin 함수로 만들어지며, 일반적으로 플러그인 패키지에서 내보내야 해요. 모든 플러그인은 ID와 register 메서드를 가져야 하며, ID는 패키지 이름의 플러그인 ID와 -backend 접미사 없이 일치해요. 적절한 명명 패턴에 관한 전용 섹션도 참고하세요.
// plugins/example-backend/src/plugin.tsimport { coreServices, createBackendPlugin,} from '@backstage/backend-plugin-api';export const examplePlugin = createBackendPlugin({ pluginId: 'example', register(env) { env.registerInit({ deps: { logger: coreServices.logger, }, async init({ logger }) { logger.info('Hello from example plugin'); }, }); },});
register 콜백에 전달되는 env 객체는 플러그인의 외부 표면을 선언하는 여러 메서드를 포함해요. env.registerInit 메서드는 백엔드가 시작될 때 실행되는 초기화 함수를 등록하는 데 사용돼요. deps 인자는 서비스 의존성을 선언하는 데 사용되며, init 콜백은 해결된 의존성을 가진 객체를 전달받아요. 이 경우 모든 Backstage 백엔드 플러그인에 사용 가능한 핵심 서비스 중 하나인 logger 서비스에 의존을 선언해요. 핵심 서비스의 전체 목록과 각 서비스 문서는 핵심 서비스 섹션을 참고하세요. 플러그인은 물론 다른 라이브러리가 내보내는 서비스에도 의존할 수 있어요.
createBackendPlugin 반환 값은 실제 플러그인 인스턴스를 만드는 데 사용되는 팩토리 함수인 examplePlugin으로 내보내져요. 예를 들어 백엔드 인스턴스에 플러그인을 설치하려면 다음과 같이 합니다:
import { examplePlugin } from 'backstage-plugin-example-backend';backend.add(examplePlugin);
관례상 모든 플러그인 패키지는 플러그인 인스턴스를 패키지의 기본 내보내기로 내보내야 해요:
// plugins/example-backend/src/index.tsexport { examplePlugin as default } from './plugin.ts';
이를 통해 패키지를 참조하기만 하면 백엔드 인스턴스에 플러그인을 설치할 수 있어요:
backend.add(import('backstage-plugin-example-backend'));
플러그인을 사용자 지정 가능하게 만들려면 일반적으로 정적 구성을 선호해야 해요. 관례상 플러그인은 플러그인 ID와 일치하는 최상위 구성 키 아래에 구성을 배치해야 해요. 예를 들어 예시 플러그인은 다음과 같이 구성할 수 있어요:
example: message: Welcome to the example plugin
정적 구성이 너무 제한적인 상황에서는 대신 플러그인에 확장 지점을 등록할 수 있어요. 확장 지점은 다음 섹션에서 다뤄요.
플러그인의 규칙
다음 규칙은 더 넓은 Backstage 플러그인 생태계에서 Backstage 플러그인의 프로덕션 설정에 적용돼요. @backstage 패키지 네임스페이스 아래에서 유지 관리되는 모든 플러그인은 이 규칙을 따라야 하며, 널리 배포되는 모든 플러그인도 이 규칙을 따르는 것이 권장돼요.
이 규칙의 예외는 개발 또는 테스트 설정에 적용되며, 개발을 간소화하고 단순하게 유지하기 위해 지름길을 택할 수 있어요.
확장 가능
플러그인은 항상 수평 확장이 가능하도록 설계되어야 해요. 이는 메모리에 상태를 유지하지 않거나, 이 상태를 여러 인스턴스에 복제하는 것이 문제가 되지 않도록 해야 함을 의미해요. 플러그인은 무상태(stateless)이거나, 상태를 데이터베이스 같은 외부 서비스에 저장해야 해요.
격리됨
플러그인은 절대 코드를 통해 서로 직접 통신해서는 안 되며, 네트워크를 통해서만 통신할 수 있어요. 다른 플러그인과 모듈이 사용할 외부 인터페이스를 노출하려는 플러그인은 node-library 패키지를 통해 그렇게 하는 것이 권장돼요. 라이브러리는 플러그인에 호출을 하기 위한 API 클라이언트 서비스 또는 유사한 구성을 내보내야 해요.