Domande frequenti su Bottlerocket

AWS fornisce un'Amazon Machine Image (AMI) per Bottlerocket che puoi utilizzare per l'esecuzione su tipi di istanza EC2 supportati dalla Console, dalla CLI e dall'SDK AWS. AWS fornirà build Bottlerocket preconfigurate per l'uso con EKS, ECS, VMware ed EKS Anywhere su bare metal. Puoi usare l'orchestratore per aggiornare e gestire il sistema operativo con interruzioni minime senza dover accedere a ogni istanza del sistema operativo.

È possibile avviare applicazioni containerizzate su un'istanza di Bottlerocket attraverso l'orchestratore. È anche possibile includere il software e gli script di avvio in Bottlerocket durante la personalizzazione dell'immagine. Consulta la documentazione di Bottlerocket per conoscere maggiori dettagli.

Puoi implementare e utilizzare Bottlerocket utilizzando la seguente procedura:

• Fase 1: puoi implementare Bottlerocket come qualsiasi altro sistema operativo in una macchina virtuale. Su AWS, Bottlerocket può essere implementato sulle istanze EC2 dalla Console di gestione AWS, attraverso API o AWS CLI. È necessario fornire i dettagli di configurazione mediante dati utente per ogni istanza di Bottlerocket per registrarsi in un cluster Amazon EKS.
• Fase 2: per utilizzare Bottlerocket con il tuo orchestratore, dovrai distribuire un componente di integrazione nel tuo cluster. Il componente di integrazione consente all'orchestratore di iniziare riavvii, eseguire il rollback di aggiornamenti e sostituire i container in modo minimamente invasivo per gli aggiornamenti in sequenza.

Gli aggiornamenti a Bottlerocket vengono scaricati automaticamente da repository AWS preconfigurati non appena sono disponibili. Per applicare gli aggiornamenti è necessario un riavvio di Bottlerocket, che può essere iniziato manualmente o gestito dall'orchestratore, ad esempio Kubernetes. È necessario selezionare il meccanismo appropriato per gestire i riavvii in base alla tolleranza delle applicazioni ai riavvii e alle esigenze operative. Se l'applicazione è stateless e resiliente ai riavvii, i riavvii possono essere eseguiti immediatamente dopo il download degli aggiornamenti. Se stai eseguendo carichi di lavoro stateful tradizionali (ad esempio database, applicazioni line-of-business di lunga durata e così via) in container che non sono resilienti ai riavvii, dovrai assicurarti che lo stato sia preservato prima del riavvio.

I riavvii di Bottlerocket possono essere gestiti da orchestratori svuotando e riavviando i container tra gli host per consentire aggiornamenti in sequenza in un cluster, in modo da ridurre le interruzioni. In caso di errore, è inoltre possibile eseguire il rollback degli aggiornamenti a Bottlerocket in modo sicuro mediante agenti di orchestrazione supportati o con un'azione manuale. Consulta la documentazione di Bottlerocket per conoscere le fasi di implementazione e uso dell'"operatore di aggiornamento Bottlerocket" sui cluster Amazon EKS e sui cluster Amazon ECS.

Le build di Bottlerocket fornite da AWS seguono uno schema semantico di controllo delle versioni con semantica di tipo "principale.secondaria.patch". Versioni secondarie di Bottlerocket verranno pubblicate più volte durante l'anno con modifiche come supporto per nuove piattaforme EC2, supporto per nuovi orchestratori e aggiornamenti ai componenti open source. Lo schema di versione indica se gli aggiornamenti contengono modifiche sostanziali.

Una variante è una build di Bottlerocket che supporta funzionalità o caratteristiche di integrazione diverse. AWS fornisce varianti di Bottlerocket che supportano i nodi worker di Kubernetes in EC2, in VMware e su bare metal. AWS fornisce inoltre varianti di Bottlerocket per ECS in EC2. Puoi consultare la lista di tutte le varianti fornite da AWS.

Sì. Bottlerocket offre varianti che supportano tipi di istanza di Amazon EC2 basati su GPU NVIDIA su Amazon Elastic Container Service (Amazon ECS) e sui nodi worker di Kubernetes in EC2. Consulta i post di blog per conoscere l'utilizzo di tali varianti su ECS e su EKS.

Le release delle funzionalità di Bottlerocket (versioni secondarie, ad esempio 1.10.0, 1.11.0) generalmente avvengono con una cadenza che varia tra le 6 e le 8 settimane. Le correzioni di bug e CVE (versioni patch, ad esempio 1.10.1, 1.11.1) vengono eseguite quando necessario e la cadenza delle release dipende dalla gravità del problema. Si prega di fare riferimento al CHANGELOG che mostra tutte le versioni di Bottlerocket con le relative tempistiche.

Le build di Bottlerocket fornite da AWS riceveranno aggiornamenti di sicurezza, correzioni di bug e sono coperte dai piani di supporto AWS. Il periodo di supporto per una determinata build dipenderà dalla versione dell'orchestratore di container in uso. Le build di Bottlerocket diventeranno obsolete quando la versione dell'orchestratore corrispondente diventerà obsoleta. Ad esempio, aws-k8s-1.19, che è la build Bottlerocket per Kubernetes 1.19, non è più supportata. Ciò è correlato al fatto che Kubernetes 1.19 non riceve più supporto a monte. Consigliamo ai clienti di sostituire i nodi aws-k8s-1.19 con una build più recente supportata dal cluster. Inoltre, il supporto della community per Bottlerocket è disponibile su GitHub, dove si possono pubblicare domande, richieste di funzionalità e segnalare bug. I dettagli sui rilasci e sulle correzioni ai CVE saranno pubblicati nel log delle modifiche di Bottlerocket.

Le attuali AMI ottimizzate per EKS basate su Amazon Linux saranno supportate e continueranno a ricevere aggiornamenti di sicurezza. Per avere maggiori dettagli sulla durata del supporto, consulta AMI Amazon Linux 2 ottimizzate per EKS e AMI ottimizzate per ECS.

Le build di Bottlerocket fornite da AWS sono supportate su famiglie di istanze HVM ed EC2 Bare Metal, ad eccezione dei tipi di istanza F, G4ad e INF.

Sì. Leggi questo post del blog per avere maggiori dettagli.

AWS fornisce aggiornamenti pre-testati per Bottlerocket che vengono applicati in un unico passaggio. Questi aggiornamenti possono anche essere ripristinati in un unico passaggio a uno stato valido noto. Di conseguenza, gli aggiornamenti "falliti" che possono rendere il sistema inutilizzabile a causa di stati incoerenti che richiedono una riparazione manuale non si verificano con Bottlerocket. Con gli aggiornamenti atomici in un unico passaggio, la complessità è inferiore, il che riduce gli errori di aggiornamento.

Gli aggiornamenti alle build di Bottlerocket fornite da AWS vengono scaricati automaticamente dai repository AWS preconfigurati non appena sono disponibili. Per applicare gli aggiornamenti è necessario un riavvio di Bottlerocket, che può essere iniziato manualmente o gestito dall'orchestratore, ad esempio Kubernetes. È necessario selezionare il meccanismo appropriato per gestire i riavvii in base alla tolleranza delle applicazioni ai riavvii e alle esigenze operative. Se l'applicazione è stateless e resiliente ai riavvii, questi possono essere eseguiti immediatamente dopo il download degli aggiornamenti. Se stai eseguendo carichi di lavoro stateful tradizionali (ad esempio database o applicazioni line-of-business di lunga durata) in container che non sono resilienti ai riavvii, dovrai assicurarti che lo stato sia preservato prima del riavvio.

I riavvii di Bottlerocket possono essere gestiti dagli orchestratori, ad esempio Kubernetes, svuotando e riavviando i container tra gli host per consentire aggiornamenti in sequenza in un cluster, in modo da ridurre le interruzioni. Per impostazione predefinita, Bottlerocket si aggiornerà automaticamente all'ultima versione sicura all'avvio. In caso di errore, è inoltre possibile eseguire il rollback degli aggiornamenti a Bottlerocket in modo sicuro mediante agenti di orchestrazione supportati o con un'azione manuale.

Le integrazioni con orchestratori come Kubernetes aiutano a rendere gli aggiornamenti a Bottlerocket invasivi al minimo. Durante il processo di aggiornamento, l'orchestratore scarica i container sugli host in fase di aggiornamento e li posiziona su altri host liberi nel cluster. Inoltre, se gli aggiornamenti hanno esito negativo, l'orchestratore esegue il rollback degli host alla versione precedente di Bottlerocket.

Bottlerocket può eseguire tutte le immagini di container che soddisfano la specifica del formato immagine OCI e le immagini Docker.

Sì, puoi spostare i tuoi container su Amazon Linux 2 e Bottlerocket senza modifiche.

Se i flussi di lavoro operativi per l'esecuzione dei container comportano l'installazione di software sul sistema operativo host con yum, l'invio diretto di ssh nelle istanze, la personalizzazione di ogni singola istanza o l'esecuzione di software ISV di terze parti non containerizzato (ad esempio, agenti per la registrazione e il monitoraggio), Amazon Linux 2 potrebbe essere più adatto. Bottlerocket è ottimizzato per eseguire e gestire grandi distribuzioni containerizzate e non consente di eseguire facilmente molte di tali attività.

Puoi eseguire un "container di amministrazione" utilizzando l'API di Bottlerocket (richiamata mediante i dati utente o AWS Systems Manager) e quindi accedere con SSH per il debug e la risoluzione dei problemi avanzati con privilegi elevati. AWS fornisce il container di amministrazione che consente di installare e utilizzare strumenti di debug come sosreport, traceroute, strace, tcpdump. L'accesso a singole istanze di Bottlerocket è destinato a essere un'operazione rara per il debug e la risoluzione dei problemi avanzati.

Un container di amministrazione è un'immagine del container Amazon Linux che contiene utilità per la risoluzione dei problemi e il debug di Bottlerocket e che viene eseguito con privilegi elevati. Per informazioni sull'uso del container di amministrazione, consulta i dettagli.

Bottlerocket consente aggiornamenti di sicurezza automatici e riduce l'esposizione agli attacchi di sicurezza includendo solo il software essenziale per ospitare i container. Bottlerocket utilizza i gruppi di controllo dei container (cgroup) e gli spazi dei nomi del kernel per l'isolamento tra i container. Viene fornito anche con Security-Enhanced Linux (SELinux) in modalità di applicazione e seccomp. eBPF nel kernel riduce la necessità di moduli del kernel per molte operazioni di sistema di basso livello fornendo un framework di traccia a basso sovraccarico per tracciare I/O, operazioni del file system, utilizzo della CPU, rilevamento delle intrusioni e risoluzione dei problemi. Bottlerocket utilizza device-mapper-verity (dm-verity), una funzionalità del kernel Linux che fornisce il controllo dell'integrità per aiutare a prevenire i rootkit che possono trattenere i privilegi root.

Esistono diverse opzioni per raccogliere i registri dei nodi di Bottlerocket. Ad esempio, è possibile utilizzare CloudWatch Container Insights o Fluent Bit con OpenSearch.

Sì, Bottlerocket dispone di un benchmark CIS. Il benchmark CIS è un catalogo di impostazioni di configurazione incentrate sulla sicurezza che aiutano i clienti di Bottlerocket a configurare o documentare eventuali configurazioni non conformi in maniera semplice ed efficiente. Il benchmark CIS per Bottlerocket include profili di configurazione di livello 1 e 2 ed è accessibile dal sito Web di CIS.

No, Bottlerocket non dispone ancora di certificazione FIPS. La certificazione FIPS per Bottlerocket è nella nostra roadmap, ma al momento non abbiamo una stima di quando sarà disponibile.

Sì, è possibile ottenere la conformità PCI con Bottlerocket. Il set di funzionalità ottimizzato e la superficie di attacco ridotta fanno sì che le istanze di Bottlerocket richiedano meno configurazione per soddisfare i requisiti PCI DSS. Il benchmark CIS per Bottlerocket è un'ottima risorsa di guida per l'hardening e supporta i requisiti del cliente per standard di configurazione sicuri come da requisito PCI DSS 2.2. I clienti possono inoltre sfruttare Fluent Bit per supportare i requisiti del cliente per la registrazione di audit a livello di sistema operativo come da requisito PCI DSS 10.2. AWS pubblica periodicamente nuove istanze di Bottlerocket (con patch) per aiutare i clienti a soddisfare il requisito PCI DSS 6.2 (per v3.2.1) e il requisito 6.3.3 (per v4.0).

Sì, Bottlerocket è una funzionalità HIPAA autorizzata all'utilizzo con carichi di lavoro regolamentati sia per Amazon EC2 che per Amazon EKS. Per indicazioni sulla configurazione relativa ad Amazon EKS, consulta questo whitepaper, dove troverai maggiori informazioni.

Consulta la guida su hardening e convalida  di Bottlerocket quando viene utilizzato con Amazon EKS.

Sì. Amazon Inspector è un servizio di gestione delle vulnerabilità che esegue la scansione dei carichi di lavoro di EC2 e container alla ricerca di vulnerabilità del software e le esposizioni impreviste del network. Amazon Inspector sfrutta l'agente AWS System Manager (SSM) per la scansione delle vulnerabilità. Negli host Bottlerocket, l'agente SSM viene eseguito all'interno del container dell'host di controllo, quindi è necessario assicurarsi che sia abilitato nei propri host.

Il codice di Bottlerocket è concesso su licenza con Apache 2.0 OR MIT. Amazon ha scritto il suo Bottlerocket in Rust, quindi abbiamo scelto una licenza che si adatta facilmente a quella community. Il codice di terze parti sottostante, come il kernel Linux, rimane soggetto alla sua licenza originale.

Bottlerocket è rilasciato come progetto open source su GitHub. Documenti di progettazione, codice, strumenti di compilazione, test e documentazione saranno ospitati su GitHub. Utilizzeremo i sistemi di tracciamento dei bug e delle funzionalità di GitHub per la gestione del progetto. Puoi visualizzare e contribuire al codice sorgente di Bottlerocket utilizzando i flussi di lavoro GitHub standard.

Puoi effettuare il fork del repository GitHub, apportare le modifiche e seguire la nostra guida alla compilazione.

Sì. Se crei Bottlerocket da un'origine non modificata e ridistribuisci i risultati, puoi utilizzare "Bottlerocket" solo se è chiaro, sia nel nome della tua distribuzione che nel contenuto ad essa associato, che la tua distribuzione è la tua build di Bottlerocket di Amazon e non la build ufficiale e devi identificare il commit da cui è stato creato, inclusa la data di commit.

Per utilizzare Bottlerocket in base a questa policy o per rimuovere i marchi Bottlerocket, è necessario modificare il file os-release. Questo può essere fatto modificando packages/release/release.spec e tools/rpm2img. Per essere conformi a questa policy, i nomi della root di sistema (/x86_64-bottlerocket-linux-gnu/sys-root), le etichette delle partizioni, i percorsi delle directory e le descrizioni dei file di servizio non devono essere modificati.

Se sei a conoscenza di un uso confuso, fuorviante o in altro modo improprio dei marchi Bottlerocket, puoi contattarci come descritto sopra all'indirizzo trademarks@amazon.com in modo che possiamo indagare ulteriormente.