서비스
레시피 서비스에는 정식 필드가 세 개뿐입니다. name, enabled, 그리고 열린
config 객체입니다. 형태는 구조적으로 검증되지만, 구성 키가 효과를 갖는 것은
선택한 빌드 워커나 기능 훅이 이를 구현한 경우뿐입니다. 검증은 데몬이
설치되었거나 구성되었음을 증명하지 않습니다.
{
"services": [
{
"name": "ssh",
"enabled": true,
"config": {
"port": 2222,
"allow_root": false,
"disable_password_auth": true,
"authorized_keys": ["ssh-ed25519 AAAA... operator@example"]
}
}
]
}SSH 구성
일반 Linux 빌드 경로는 다음 SSH 설정을 인식합니다.
| 레시피 키 | 효과 |
|---|---|
port 또는 listen_port | OpenSSH 포트, 1–65,535 |
allow_root | PermitRootLogin에 매핑됩니다 |
disable_password_auth | 반전되어 PasswordAuthentication이 됩니다 |
password_authentication | OpenSSH 토큰 값을 직접 지정합니다 |
pubkey_authentication | OpenSSH 토큰 값을 직접 지정합니다 |
client_alive_interval | 상한이 있는 ClientAliveInterval |
client_alive_attempts | 상한이 있는 ClientAliveCountMax |
authentication_retries | 상한이 있는 MaxAuthTries |
timeout | 상한이 있는 로그인 유예 시간 |
x11_forwarding, allow_agent_forwarding, allow_tcp_forwarding | OpenSSH 토큰 값을 직접 지정합니다 |
authorized_keys | 지원되는 경우 제공된 공개 키를 설치합니다 |
워커별 경로는 더 작은 집합만 지원할 수 있습니다. 특히 하드웨어, Proxmox, Raspberry Pi 빌더는 자체 어댑터를 가집니다. 선택한 대상의 정규화된 레시피와 빌드 경고를 확인하세요.
암호 인증을 끈 경우, 하드웨어에 배포하기 전에 유효한 공개 키를 적어도 하나 포함하고 독립적으로 테스트하세요. 개인 키나 암호를 레시피 서비스 구성에 넣지 마세요.
기타 서비스
nginx, wireguard, DNS, DHCP, 방화벽 구성 요소 같은 이름은 범용 구성 API가 아닙니다.
패키지와 구성은 선택한 베이스에 해당하는 기능, 훅, 패키지 목록, 또는 시작 스크립트에서 옵니다.
config.sites 같은 임의의 객체는 스키마가 받아들여도 무시될 수 있습니다.
이 순서를 사용하세요.
- 베이스 이미지를 선택하고 구체적인 기능 또는 패키지를 켭니다.
- 해당 능력에 구현된 구성 키만 추가합니다.
- 정규화된 레시피와 생성된 경고를 검사합니다.
- 패키지 존재, 서비스 활성화, 수신 포트, 구성 파일, 애플리케이션 수준 응답에 대한 어설션을 추가합니다.
- 하드웨어 또는 프로덕션으로 올리기 전에 아티팩트를 부팅하고 테스트합니다.