Documentazione dell'architettura dell'ambiente
Come procedura ottimale, crea diagrammi di architettura per le tue applicazioni. Questi diagrammi possono essere utilizzati come parte del lavoro di progettazione iniziale, come formazione di nuovi membri del team o come formazione di membri del team nuovi ed esistenti. Mantenendo diagrammi come questo aggiornati si risparmia tempo quando i problemi devono essere esaminati rapidamente.
Documentando l'architettura della tua app, potrai assicurarti che tu e il tuo team comprendiate appieno tutti i componenti che compongono la vostra architettura.
È possibile creare un diagramma dell'architettura come parte della pianificazione dell'ambiente iniziale o dopo che l'ambiente è attivo e in esecuzione. Esamina la seguente procedura per documentare il tuo ambiente. Gli esempi forniti sono basati sulle applicazioni del mondo reale.
Passo 1: Comprendi la tua applicazione e architettura
La risoluzione dei problemi delle applicazioni nei cluster Red Hat OpenShift on IBM Cloud può essere complicata, soprattutto se il problema riguarda un flusso di rete che si estende a diversi cluster, componenti, pod o servizi. Documentare l'architettura della tua applicazione può aiutare il tuo team a comprendere a fondo tutti i componenti nella configurazione.
Per un'applicazione con un semplice flusso di rete, l'architettura può essere descritta in testo. Per scenari più complessi, è utile un diagramma dell'architettura dettagliato in modo che vari team coinvolti nella risoluzione dei problemi possano comprendere il flusso. È anche importante assicurarsi che la documentazione dell'architettura rimanga aggiornata se la configurazione viene modificata.
La risoluzione dei problemi delle applicazioni nei cluster Red Hat OpenShift on IBM Cloud può essere difficile, specialmente se si verificano una o più delle seguenti condizioni.
- L'app non è ben compresa o non ha una buona registrazione.
- Il problema è intermittente o non si verifica spesso.
- Il problema riguarda un flusso di rete che si estende a diversi cluster, componenti, pod o servizi.
I seguenti diagrammi di architettura di esempio sono tratti da scenari reali. È possibile utilizzare questi esempi come guida durante la creazione dei propri diagrammi di architettura.
Esempio 1: un'applicazione di base in esecuzione in un singolo cluster OpenShift
In questo esempio, tutta l'applicazione è in esecuzione all'interno di un singolo cluster OpenShift. È un'applicazione semplice in cui un singolo pod client effettua una richiesta a un servizio in cluster, che si connette quindi a un'istanza etcd gestita da tre pod.
Client Application Service Etcd Instance
|------> [Etcd Pod 1]
|---> [Application Pod 1] ---|
| |
[Client pod] ---| |------> [Etcd Pod 2]
| |
|---> [Application Pod 2] ---|
|------> [Etcd Pod 3]
Esempio 2: un'architettura a più cluster con un programma di bilanciamento del carico globale e un servizio Cloudant
Nel seguente diagramma, la connessione viene avviata da uno dei tre pod client in un cluster nella regione eu-de. I pod del client si collegano a un GLB (global load balancer) che, quindi, bilancia il carico della connessione
a uno dei due ALB (application load balancer) VPC pubblici in eu-de e eu-gb.
Ciascuno di questi VPC ALB fa parte di un cluster separato nelle rispettive regioni. Questi ALB instradano il traffico ai pod del router OpenShift, che quindi inoltrano tale traffico ai pod di backend nel cluster. Questi pod di backend si connettono a un database Cloudant per gestire la richiesta.
Notare che alcune di queste connessioni si trovano sulla rete pubblica. Alcuni si trovano su una rete privata nello stesso VPC e altri utilizzano la rete privata in IBM Cloud tra i componenti in un VPC e un servizio in IBM Cloud.
Esempio 3: un client VSI che contatta un programma di bilanciamento del carico di rete VPC con un back-end del servizio esterno
Nel seguente esempio, il client è una VSI classica in IBM Cloud. La VSI si connette tramite la rete privata a un NLB (network load balancer) VPC privato creato per un cluster VPC. Questo NLB bilancia il traffico a uno dei tre nodi di lavoro VPC tramite la NodePort per il servizio del programma di bilanciamento del carico del cluster. Il servizio Load Balancer del cluster invia quindi il traffico a uno dei pod dell'applicazione che si connette a un servizio cloud esterno a IBM Cloud sulla rete pubblica.
{: caption="esternoNLB con un " caption-side="bottom"} esterno
Passo 2: Scegli uno strumento
È possibile utilizzare uno dei seguenti strumenti per creare il diagramma dell'architettura.
Ci sono molti strumenti di diagrammi disponibili. Scegli lo strumento che funziona meglio per te.
Fase 3: Creare il diagramma
È possibile utilizzare uno degli esempi menzionati in precedenza come riferimento oppure creare un diagramma da zero.
Per ulteriori informazioni e architetture di riferimento, consultare IBM Architectures.