실행되는 것과 시점
모든 Linux 이미지에는 cloud-init이 포함됩니다. 첫 부팅 시 주문에 첨부된 user-data를 읽고 한 번 적용한 후, 다시 실행되지 않도록 마커를 기록합니다. 이 모든 작업은 사용자가 아무것도 입력하기 전에 이루어집니다. 이것이 핵심입니다: 인스턴스가 존재하는 순간과 구성되는 순간 사이의 창(window)은 존재하지 않아야 하는 창입니다.
주문 전에 문서를 검증하십시오. 스키마 검사기가 재구축 비용을 초래할 들여쓰기 오류를 잡아냅니다:
cloud-init schema --config-file user-data.yaml --annotate유용한 작업을 수행하는 user-data
#cloud-config
hostname: edge-01
fqdn: edge-01.example.com
timezone: UTC
users:
- name: deploy
groups: [sudo]
shell: /bin/bash
sudo: "ALL=(ALL) NOPASSWD:ALL"
ssh_authorized_keys:
- ssh-ed25519 AAAAC3Nza... deploy@laptop
ssh_pwauth: false
disable_root: true
package_update: true
package_upgrade: true
packages:
- nftables
- vnstat
- mtr-tiny
write_files:
- path: /etc/ssh/sshd_config.d/10-local.conf
permissions: "0644"
content: |
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
runcmd:
- [systemctl, enable, --now, nftables]
- [systemctl, restart, ssh]첫 번째 줄은 주석도 선택 사항도 아닙니다. #cloud-config이 없으면 문서는 조용히 무시되고 인스턴스는 아무것도 첨부하지 않은 것처럼 부팅됩니다.
AlmaLinux에서는 groups: [sudo]이 groups: [wheel]이 되고 재시작할 서비스는 sshd입니다. 나머지는 모두 동일합니다.
작동 확인
cloud-init status --long
journalctl -u cloud-final -b
less /var/log/cloud-init-output.log저널(journal)은 어떤 단계가 실패했는지 알려줍니다. cloud-init-output.log에는 runcmd 항목의 실제 출력이 저장되어 있으며, 여기에서 원인을 찾을 수 있습니다.
비밀 정보를 넣지 마십시오
User-data는 인스턴스 수명 기간 동안 내부에서 읽을 수 있는 상태로 유지됩니다:
cloud-init query userdata이 안의 모든 것은 root 권한에 도달하는 모든 프로세스와 디스크 스냅샷을 복원하는 모든 사람이 접근할 수 있습니다. 비밀 정보를 직접 포함하지 말고, 비밀 정보를 가져오는 자격 증명을 설치하는 데 사용하십시오.
인스턴스를 소모하지 않고 테스트하기
cloud-init clean --logs --reboot이것은 마커, 로그 및 캐시된 데이터 소스를 제거한 후 재부팅하여 새로운 첫 부팅을 수행합니다. 테스트용 인스턴스에서 실행하십시오. 프로덕션에서 실행하면 runcmd가 두 번째 실행에서 실제로 수행하는 작업을 발견하게 될 것이며, 이는 첫 번째 실행과 거의 같지 않습니다.
중단 지점
cloud-init은 부트스트래핑을 위한 것이며 머신이 내일 어떤 상태여야 하는지 알지 못합니다. 실제 도구가 인계받을 수 있는 지점에 도달하는 데 사용하십시오: 키, 네트워크, 에이전트. 거기서 멈추십시오. 60줄은 적절한 user-data이며, 600줄은 수렴할 방법이 없는 구성 관리 시스템입니다.
cloud-init query -a
cloud-init query ds.meta_data인스턴스 ID, 사이트 코드, 호스트 이름 및 부팅 시 할당된 주소가 모두 여기에 있으며, 스크립트가 어딘가에 자신을 등록해야 하고 자신이 어디에서 시작되었는지 아직 모를 때 필요한 정보입니다.