Deployment di Red Hat OpenShift Service on AWS

Molte aziende scelgono Red Hat OpenShift come piattaforma condivisa per lo sviluppo e l'esecuzione di tutte le applicazioni. In questo modo, si evita la creazione di un ambiente eterogeneo che può risultare molto complesso. Oltre a creare ed eseguire nuove applicazioni cloud native su Red Hat OpenShift, si può anche eseguire la migrazione di quelle esistenti.

Uno dei principali vantaggi dell'utilizzo di OpenShift è che gli sviluppatori devono apprendere il funzionamento di un'interfaccia sola, senza doversi preoccupare dei dettagli alla base della piattaforma. In questo modo, la produttività può aumentare notevolmente.

Red Hat OpenShift Service on AWS (ROSA)

Alcuni dei clienti che decidono di adottare OpenShift desiderano semplificare ulteriormente e preferiscono non preoccuparsi di fornire l'infrastruttura per i propri cluster e di gestirli. Vogliono che i loro team siano produttivi fin da subito e che si concentrino solo sullo sviluppo delle applicazioni. Una delle opzioni che hanno a disposizione è Red Hat OpenShift Service on AWS (ROSA).

ROSA è integralmente in hosting nel cloud pubblico di Amazon Web Services (AWS). È gestito congiuntamente da Red Hat e AWS, il che significa che il piano di controllo e i nodi di elaborazione sono sotto il pieno controllo di un team Red Hat di site reliability engineering (SRE) con il supporto congiunto di Red Hat e Amazon. Le attività coperte includono l'installazione, la gestione, la manutenzione e gli aggiornamenti su tutti i nodi.

Opzioni di deployment per ROSA

Esistono due modi principali per eseguire il deployment di ROSA: in un cluster pubblico e in uno con collegamento privato. In entrambi i casi si consiglia di distribuirli in più zone di disponibilità per garantirne la resilienza e la maggior disponibilità. 

I cluster pubblici vengono utilizzati principalmente per i carichi di lavoro che non hanno requisiti di sicurezza rigorosi. Il cluster viene distribuito in un cloud privato virtuale (VPC) all'interno di una sottorete privata (che contiene i nodi del piano di controllo, dell'infrastruttura e di lavoro in cui vengono eseguite le applicazioni). Tuttavia, resta accessibile da Internet, quindi è necessaria una sottorete pubblica oltre al VPC. 

I servizi di bilanciamento del carico di AWS (Elastic and Network Load Balancer) distribuiti su questa sottorete pubblica consentono al team SRE e agli utenti che accedono alle applicazioni (ovvero al traffico in ingresso al cluster) di connettersi. Nel caso degli utenti, un sistema di bilanciamento del carico reindirizza il traffico al servizio router in esecuzione sui nodi dell'infrastruttura e da lì viene inoltrato all'applicazione desiderata in esecuzione su uno dei nodi di lavoro. Il team SRE utilizza un account AWS dedicato per connettersi ai nodi di controllo e dell'infrastruttura tramite diversi sistemi di bilanciamento del carico. 

Figura 1 - Cluster pubblico ROSA

Per i carichi di lavoro di produzione con esigenze di sicurezza più rigide, consigliamo di eseguire il deployment di un cluster PrivateLink. In questo caso, il VPC all'interno del quale risiede il cluster ha solo una sottorete privata, per cui non è possibile accedervi dalla rete Internet pubblica. 

Il team SRE utilizza un account AWS dedicato che si connette a un Load Balancer AWS tramite un endpoint AWS PrivateLink. Il sistema di bilanciamento del carico reindirizza il traffico ai nodi di controllo o dell'infrastruttura in base alle esigenze. Dopo aver creato AWS PrivateLink, il cliente deve approvare l'accesso dall'account AWS del team SRE. Gli utenti si connettono a un AWS Load Balancer che li reindirizza al servizio router sui nodi dell'infrastruttura. Da lì vengono inviati al nodo di lavoro in cui è in esecuzione l'applicazione a cui desiderano accedere.

Nelle implementazioni di cluster PrivateLink è normale che i clienti desiderino reindirizzare il traffico in uscita dal cluster all'infrastruttura on premise o ad altri VPC nel cloud AWS. A tale scopo possono utilizzare un AWS Transit Gateway o AWS Direct Connect in modo da non dover eseguire il deployment di una sottorete pubblica nel VPC in cui risiede il cluster. Anche se devono indirizzare il traffico in uscita a Internet, possono connettersi (tramite AWS Transit Gateway) a un VPC che dispone di una sottorete pubblica con un AWS NAT Gateway e un AWS Internet Gateway.

Figura 2 - Cluster privato ROSA con PrivateLink

Sia nelle implementazioni pubbliche che in quelle PrivateLink, il cluster può interagire con altri servizi AWS utilizzando gli endpoint AWS VPC per comunicare con il VPC in cui si trova il cluster utilizzando i servizi desiderati.

Connessione al cluster

Il metodo consigliato dal team SRE per accedere ai cluster ROSA ed eseguire attività di amministrazione è utilizzare AWS Security Token Service (STS). Si dovrebbe applicare il concetto di privilegio minimo, in modo che vengano assegnati solo i ruoli strettamente necessari per svolgere un'attività. Il token è temporaneo e monouso, quindi, se occorre ripetere un'attività simile dopo la scadenza, è necessario richiederne uno nuovo.

L'utilizzo di STS è esteso alla connessione del cluster ROSA ad altri servizi AWS come EC2 (ad esempio se è necessario avviare nuovi server per il cluster) o EBS (se è necessario lo storage permanente).

Riepilogo

L'adozione delle metodologie DevOps e la modernizzazione del deployment delle applicazioni tramite una piattaforma Kubernetes di livello enterprise come OpenShift è applicabile a tutti i tipi di clienti. Possono scegliere di tenerlo in hosting on premise e gestirlo autonomamente, ma se preferiscono non farlo, ROSA è una delle opzioni disponibili. L'elevato numero di servizi AWS che possono interagire con i cluster ROSA aiuta i clienti a ottenere il massimo dalla piattaforma.

Scopri di più

• Implementazione di Red Hat OpenShift Service on AWS