Bottlerocket FAQ

AWS는 AWS Console, CLI 및 SDK를 통해 지원되는 EC2 인스턴스 유형에서 실행하는 데 사용할 수 있는 Bottlerocket용 Amazon Machine Image(AMI)를 제공합니다. AWS는 EKS, ECS, VMware 및 베어 메탈의 EKS Anywhere에서 사용하도록 미리 구성된 Bottlerocket 빌드를 제공합니다. 오케스트레이터를 사용하여 각 OS 인스턴스에 로그인하지 않고도 최소한의 가동 중단으로 OS를 업데이트하고 관리할 수 있습니다.

오케스트레이터를 통해 Bottlerocket 인스턴스에서 컨테이너식 애플리케이션을 시작할 수 있습니다. 또한, 이미지 사용자 지정 중에 Bottlerocket에 소프트웨어 및 시작 스크립트를 포함하고 사용할 수도 있습니다. 자세한 내용은 Bottlerocket 설명서를 참조하세요.

다음 단계를 사용하여 Bottlerocket을 배포하고 지원할 수 있습니다.

• 1단계: 가상 머신에서 다른 OS와 동일한 방식으로 Bottlerocket을 배포할 수 있습니다. AWS에서는 AWS Management Console, API 또는 AWS CLI를 통해 Bottlerocket을 EC2 인스턴스에 배포할 수 있습니다. Amazon EKS 클러스터에 등록하려면 각 Bottlerocket 인스턴스에 대한 사용자 데이터를 통해 구성 세부 정보를 제공해야 합니다.
• 2단계: 오케스트레이터로 Bottlerocket을 운영하려면 클러스터에 통합 구성 요소를 배포해야 합니다. 통합 구성 요소를 통해 오케스트레이터는 롤링 업데이트를 위해 가동 중단을 최소화하는 방식으로 재부팅을 시작하고 업데이트를 롤백하며 컨테이너를 대체할 수 있습니다.

Bottlerocket 업데이트는 사용 가능할 경우 사전 구성된 AWS 리포지토리에서 자동으로 다운로드됩니다. 업데이트를 적용하려면 Bottlerocket을 재부팅해야 하며, Kubernetes와 같은 오케스트레이터에서 수동으로 시작하거나 관리할 수 있습니다. 재부팅에 대한 애플리케이션의 허용 범위와 운영 요구 사항에 따라 재부팅을 처리할 적절한 메커니즘을 선택해야 합니다. 애플리케이션이 무상태이고 재부팅에 탄력적인 경우 업데이트가 다운로드된 후 재부팅이 즉시 수행될 수 있습니다. 재부팅에 탄력적이지 않은 컨테이너에서 기존의 상태 유지 워크로드(예: 데이터베이스, 장기 실행 LOB 앱 등)를 실행하는 경우 재부팅 전에 상태가 유지되도록 해야 합니다.

Bottlerocket 재부팅은 중단을 줄이기 위해 클러스터에서 업데이트 롤링을 지원하도록 호스트에서 컨테이너를 드레이닝하고 다시 시작하여 오케스트레이터에서 관리할 수 있습니다. Bottlerocket에 대한 업데이트는 실패할 경우 지원되는 오케스트레이터 또는 수동 작업을 통해 안전하게 롤백할 수도 있습니다. Amazon EKS 클러스터 및 Amazon ECS 클러스터에서 ‘Bottlerocket 업데이트 운영자’를 배포하고 사용하는 단계는 Bottlerocket 설명서를 참조하세요.

AWS에서 제공하는 Bottlerocket 빌드는 ‘major.minor.patch’ 의미 체계 버전 관리 체계를 따릅니다. Bottlerocket의 마이너 버전은 1년에 여러 번 출시됩니다(예: 새로운 EC2 플랫폼에 대한 지원, 새 오케스트레이터 에이전트에 대한 지원, 오픈 소스 구성 요소에 대한 업데이트). 버전 구성표에는 업데이트에 중단되는 변경 사항이 포함되어 있는지 여부가 표시됩니다.

변형은 다른 기능 또는 통합 특성을 지원하는 Bottlerocket 빌드입니다. AWS는 EC2, VMware 및 베어 메탈의 Kubernetes 워커 노드를 지원하는 Bottlerocket 변형을 제공합니다. 또한 EC2의 ECS를 위한 Bottlerocket 변형도 제공합니다. 모든 AWS 제공 변형 목록을 확인할 수 있습니다.

예. Bottlerocket에는 Amazon Elastic Container Services(Amazon ECS)와 EC2의 Kubernetes 워커 노드에서 NVIDIA GPU 기반 Amazon EC2 인스턴스 유형을 지원하는 Bottlerocket 변형이 있습니다. ECS 및 EKS에서 이러한 변형을 사용하는 방법에 대한 블로그 게시물을 참조하세요.

Bottlerocket 기능 릴리스(마이너 버전, 예: 1.10.0, 1.11.0)는 일반적으로 6~8주 간격으로 출시됩니다. 버그 및 CVE 수정(패치 버전, 예: 1.10.1, 1.11.1)은 필요에 따라 제공되며 릴리스 주기는 문제의 심각도에 따라 달라집니다. 모든 Bottlerocket 릴리스를 일정과 함께 보여주는 CHANGELOG를 참조하세요.

AWS에서 제공하는 Bottlerocket 빌드는 보안 업데이트, 버그 수정 사항을 수신하며, AWS Support 플랜에서 지원합니다. 지정된 빌드의 지원 기간은 사용하는 컨테이너 오케스트레이터 버전에 따라 달라집니다. 상응하는 오케스트레이터 버전이 더 이상 사용되지 않으면 Bottlerocket 빌드는 더 이상 사용되지 않습니다. 예를 들어 aws-k8s-1.19는 더 이상 지원되지 않으며, 이는 Kubernetes 1.19에 대한 Bottlerocket 빌드입니다. 이는 업스트림에서 더 이상 지원을 받지 못하는 Kubernetes 1.19와 일치합니다. 따라서 고객에게 aws-k8s-1.19 노드를 클러스터에서 지원하는 최신 빌드로 교체할 것을 권장하고 있습니다. 또한 Bottlerocket에 대한 커뮤니티 지원은 GitHub에서 이용 가능합니다. 여기에서는 질문을 올리고 기능을 요청하며 버그를 신고할 수 있습니다. CVE에 대한 수정 사항 및 릴리스에 대한 세부 정보는 Bottlerocket changelog에 게시됩니다.

Amazon Linux에 기반한 최신 EKS에 최적화된 AMI가 지원될 예정이며, 계속해서 보안 업데이트를 수신할 수 있습니다. 지원 수명에 대한 자세한 내용은 EKS에 최적화된 Amazon Linux 2 AMI 및 ECS에 최적화된 AMI를 참조하세요.

AWS의 Bottlerocket 빌드는 HVM 및 EC2 베어 메탈 인스턴스 패밀리에서 지원됩니다(F, G4ad, INF 인스턴스 유형은 제외).

예. 자세한 내용은 이 블로그 게시물을 참조하세요.

AWS는 단일 단계로 적용되는 Bottlerocket에 대한 사전 테스트된 업데이트를 제공합니다. 이 업데이트는 단일 단계를 통해 알려진 양호한 상태로 롤백할 수도 있습니다. 결과적으로 일관되지 않은 상태로 인해 시스템을 사용할 수 없게 만드는 ‘잘못된’ 업데이트는 수동 수리가 필요하지만, Bottlerocket에서는 발생하지 않습니다. 단일 단계 원자 업데이트를 사용하면 복잡성이 줄어들고 업데이트 실패도 줄어듭니다.

AWS에서 제공하는 Bottlerocket 빌드에 대한 업데이트는 사용 가능하면 사전 구성된 AWS 리포지토리에서 자동으로 다운로드됩니다. 업데이트를 적용하려면 Bottlerocket을 재부팅해야 하며, Kubernetes와 같은 오케스트레이터에서 수동으로 시작하거나 관리할 수 있습니다. 재부팅에 대한 애플리케이션의 허용 범위와 운영 요구 사항에 따라 재부팅을 처리할 적절한 메커니즘을 선택해야 합니다. 애플리케이션이 무상태이고 재부팅에 탄력적인 경우 업데이트가 다운로드된 후 재부팅이 즉시 수행될 수 있습니다. 재부팅에 복원력이 없는 컨테이너에서 기존의 상태 유지 워크로드(예: 데이터베이스 또는 장기 실행 LOB 앱)를 실행하는 경우 재부팅 전에 상태가 유지되도록 해야 합니다.

Bottlerocket 재부팅은 중단을 줄이기 위해 클러스터에서 업데이트 롤링을 지원하도록 호스트에서 컨테이너를 드레이닝하고 다시 시작하여 Kubernetes와 같은 오케스트레이터에서 관리 가능합니다. 기본적으로 Bottlerocket은 부팅 시 최신 보안 버전으로 자동 업데이트됩니다. Bottlerocket에 대한 업데이트가 실패할 경우 지원되는 오케스트레이터 또는 수동 작업을 통해 안전하게 롤백할 수도 있습니다.

Kubernetes와 같은 오케스트레이터와 Bottlerocket의 통합은 업데이트 시 가동 중단을 최소화하는 데 도움이 됩니다. 업데이트 프로세스 중에 오케스트레이터는 업데이트하는 호스트에서 컨테이너를 드레이닝하고 클러스터에서 다른 빈 호스트에 배치합니다. 또한 업데이트에 실패하면 오케스트레이터는 Bottlerocket의 이전 버전으로 호스트를 롤백합니다.

Bottlerocket은 OCI 이미지 형식 사양 및 Docker 이미지를 충족하는 모든 컨테이너 이미지를 실행할 수 있습니다.

예. 수정하지 않고 Amazon Linux 2 및 Bottlerocket에서 컨테이너를 이동할 수 있습니다.

컨테이너를 실행하는 운영 워크플로가 yum을 사용하여 호스트 OS에서 소프트웨어 설치, 직접 인스턴스에 ssh로 연결, 개별적으로 각 인스턴스 사용자 지정 또는 컨테이너식이 아닌 서드 파티 ISV 소프트웨어 실행(예: 로깅 및 모니터링을 위한 에이전트)을 포함하는 경우 Amazon Linux 2가 더 적합할 수 있습니다. Bottlerocket은 컨테이너식 대규모 배포를 실행하고 관리하는 데 최적화되었으며, 위와 같은 많은 활동은 쉽게 허용되지 않습니다.

사용자 데이터 또는 AWS Systems Manager를 통해 호출되는 Bottlerocket의 API를 사용하여 ‘관리 컨테이너’를 실행하고 승격된 권한으로 고급 디버깅 및 문제 해결을 위해 SSH로 로그인할 수 있습니다. AWS는 sosreport, traceroute, strace, tcpdump와 같은 디버깅 도구를 설치 및 사용할 수 있도록 지원하는 관리 컨테이너를 제공합니다. 고급 디버깅 및 문제 해결을 위해 개별 Bottlerocket 인스턴스에는 자주 로그인하지 않아도 되도록 설계되었습니다.

관리 컨테이너는 Bottlerocket 문제 해결 및 디버깅을 위한 Amazon Linux 컨테이너 이미지 포함 유틸리티이며, 승격된 권한으로 실행됩니다. 관리 컨테이너 사용 방법에 대한 자세한 내용을 참조하세요.

Bottlerocket은 자동 보안 업데이트를 지원하며, 컨테이너 호스팅을 위한 핵심 소프트웨어만 포함하므로 보안 공격에 대한 노출 위험을 줄입니다. Bottlerocket은 컨테이너 간 격리를 위해 컨테이너 제어 그룹(cgroups) 및 커널 네임스페이스를 사용합니다. 또한 시행 모드 및 seccomp에서 Security-Enhanced Linux(SELinux)도 제공합니다. 커널의 eBPF는 I/O, 파일 시스템 작업, CPU 사용, 침임 탐지 및 문제 해결을 추적하기 위해 오버헤드가 적은 추적 프레임워크를 제공하여 많은 하위 수준의 시스템 작업을 위해 커널 모듈의 필요성을 줄여줍니다. Bottlerocket은 device-mapper-verity(dm-verity)를 사용합니다. 이는 Linux 커널 기능으로, 루트 권한을 보유하고 있을 수 있는 루트킷을 방지할 수 있도록 무결성 검사를 제공합니다.

여러 옵션을 사용하여 Bottlerocket 노드에서 로그를 수집할 수 있습니다. 예를 들어 CloudWatch Container Insights 또는 Fluent Bit with OpenSearch를 사용할 수 있습니다.

예. Bottlerocket에는 CIS 벤치마크가 있습니다. CIS 벤치마크는 Bottlerocket 고객이 간단하고 효율적으로 구성하거나 규정 미준수 구성을 문서화하는 데 도움이 되는 보안 중심 구성 설정의 카탈로그입니다. Bottlerocket용 CIS 벤치마크에는 레벨 1 및 레벨 2 구성 프로파일이 모두 포함되며 CIS 웹 사이트에서 액세스할 수 있습니다.

아니요. Bottlerocket에는 아직 FIPS 인증이 없습니다. Bottlerocket의 FIPS 인증은 로드맵에 있지만 지금은 제공 시기를 예상할 수 없습니다.

예. Bottlerocket을 사용하여 PCI 규정 준수를 달성할 수 있습니다. Bottlerocket 인스턴스는 기능 세트를 최적화하고 공격 표면을 축소했기 때문에 더 적은 구성으로 PCI DSS 요구 사항을 충족할 수 있습니다. Bottlerocket의 CIS 벤치마크는 하드닝 지침을 제공하는 탁월한 리소스이며 PCI DSS 요구 사항 2.2에 따른 보안 구성 표준에 대한 고객 요구 사항을 지원합니다. 또한 고객은 Fluent Bit를 활용하여 PCI DSS 요구 사항 10.2에 따른 시스템 레벨 감사 로깅 운영에 대한 고객 요구 사항을 지원할 수 있습니다. AWS는 신규(패치) Bottlerocket 인스턴스를 주기적으로 게시하여 PCI DSS 요구 사항 6.2(v3.2.1의 경우) 및 요구 사항 6.3.3(v4.0의 경우)을 충족할 수 있도록 지원합니다.

예. Bottlerocket은 Amazon EC2 및 Amazon EKS 모두에 대한 규제 대상 워크로드에 사용할 수 있도록 인증된 HIPAA 적격 기능입니다. Amazon EKS와 관련된 구성 지침은 이 백서에서 자세한 내용을 참조하세요.

Amazon EKS와 함께 사용할 때의 Bottlerocket 하드닝 및 검증에 대한 지침을 참조하세요.

예. Amazon Inspector는 EC2 및 컨테이너 워크로드를 스캔하여 소프트웨어 취약성 및 의도하지 않은 네트워크 노출을 확인하는 취약성 관리 서비스입니다. Amazon Inspector는 AWS System Manager(SSM) 에이전트를 활용하여 취약성을 스캔합니다. SSM 에이전트는 Bottlerocket 호스트의 제어 호스트 컨테이너 내에서 실행되므로 호스트에서 SSM 에이전트가 활성화되어 있는지 확인해야 합니다.

Bottlerocket 코드는 Apache 2.0 OR MIT에서 라이선스가 부여되었습니다. Amazon은 Rust에서 해당 Bottlerocket을 작성했습니다. 그래서 커뮤니티에 적합한 라이선스를 선택했습니다. Linux 커널과 같은 기본 서드 파티 코드는 원래 라이선스에 따릅니다.

Bottlerocket은 GitHub에 호스팅된 오픈 소스 프로젝트로 출시되었습니다. 설계 문서, 코드, 빌드 도구, 테스트 및 문서는 GitHub에 호스팅됩니다. 프로젝트 관리를 위해 GitHub의 버그 및 기능 추적 시스템을 사용합니다. 표준 GitHub 워크플로를 사용하여 Bottlerocket 소스 코드를 보고 적용할 수 있습니다.

GitHub 리포지토리를 분기하고 변경 사항을 생성한 후 구축 가이드의 지침을 따를 수 있습니다.

예. 수정되지 않은 소스에서 Bottlerocket을 빌드하고 결과를 재배포하는 경우 사용자 배포 이름 및 빌드와 연결된 콘텐츠 모두에서 배포가 정식 빌드가 아닌 Amazon Bottlerocket의 사용자 빌드임을 명확히 알리는 경우에만 ‘Bottlerocket’을 사용할 수 있으며, 커밋 날짜를 포함하여 구축된 커밋을 식별해야 합니다.

os-release 파일을 수정하여 이 정책에 따라 Bottlerocket을 사용하거나 Bottlerocket 상표를 제거해야 합니다. packages/release/release.spec 및 tools/rpm2img를 둘 다 수정하여 이 작업을 수행할 수 있습니다. 이 정책을 준수하기 위해 시스템 루트 이름(/x86_64-bottlerocket-linux-gnu/sys-root), 파티션 레이블, 디렉터리 경로 및 서비스 파일 설명은 변경하지 않아도 됩니다.

Bottlerocket 상표에 대한 혼란, 오용 또는 기타 남용을 알게 된 경우 위에 설명된 대로 trademarks@amazon.com 으로 문의하면 추가 조사가 진행됩니다.