App Cloud
Il networking da contenitore a contenitore in Swisscom Application Cloud consente una comunicazione TCP e UDP diretta, sicura e veloce tra le tue applicazioni. Inoltre, grazie all'Application Service Discovery integrato, i container delle tue applicazioni si trovano facilmente tra loro.
Swisscom Application Cloud utilizza la distribuzione open source di Cloud Foundry come base per offrirti una piattaforma-as-a-service.Dal rilascio ufficiale della nostra piattaforma, abbiamo continuamente aggiunto e implementato nuove funzionalità, tra cui il networking da container a container.
Container Networking consente una comunicazione diretta e guidata da policy tra le tue istanze applicative su Cloud Foundry.
In base alle politiche che puoi impostare tramite la CF CLI, le tue applicazioni hanno ora una connessione diretta tra loro, sia via TCP che UDP. La scelta è tua! Ovviamente questo comporta molti vantaggi, come una latenza più bassa e un throughput più elevato grazie alla comunicazione diretta invece che attraverso il GoRouter o un load balancer esterno. Come sviluppatore, puoi anche utilizzare questi criteri da app ad app per definire controlli di accesso a grana fine. Le tue app diventano più sicure perché comunicano tra loro direttamente attraverso gli IP del container invece di utilizzare un percorso pubblico. Questo ti dà anche la possibilità di nascondere le applicazioni dal mondo esterno e di accedervi senza aggiungere un percorso.
Il networking da contenitore a contenitore utilizza una rete interna in overlay per gestire e consentire la comunicazione tra le istanze delle tue app. A tutti i container delle app viene assegnato un indirizzo IP privato unico, che possono utilizzare per comunicare tra loro.La rete overlay non può essere instradata all'esterno e il traffico inviato tra i container non lascia la rete overlay.
Puoi dare un'occhiata dettagliata all'architettura dietro le quinte qui su GitHub: https://github.com/cloudfoundry/cf-networking-release/blob/develop/docs/arch.md(apre una nuova finestra)
Per utilizzare il networking da container a container, devi creare dei criteri di rete per le tue app. Questi criteri specificano un'app di origine, un'app di destinazione, un protocollo e una porta in modo che le istanze delle app possano comunicare direttamente tra loro senza passare attraverso il GoRouter, un bilanciatore di carico o un firewall. La rete da contenitore a contenitore supporta sia TCP che UDP e puoi configurare i criteri per più porte o intervalli di porte. I criteri di rete vengono applicati immediatamente senza dover riavviare o cambiare l'applicazione. Il seguente diagramma mostra come le istanze delle app comunicano in un'installazione client con rete container-to-container e criteri di rete abilitati.In questo esempio, lo sviluppatore dell'app ha creato delle policy per controllare il flusso di traffico tra App A, App B e App C per regolare.
Se il traffico e la sua direzione non sono esplicitamente consentiti, viene negato per impostazione predefinita. Ad esempio, l'applicazione B non può inviare traffico all'applicazione C.
Usa i comandi CF CLI per impostare questi criteri di rete:
Di queste tre app, solo l'app A è esposta al mondo esterno con un percorso mappato:
Possiamo visualizzare i criteri configurati con il comando network-policies:
Creiamo un criterio aggiuntivo con add-network-policy per consentire anche la comunicazione TCP diretta sulla porta 4567 dall'app C all'app B (ma non viceversa!):
Se in seguito ci rendiamo conto che è stato un errore concedere all'App C l'accesso all'App B, possiamo semplicemente rimuovere nuovamente il criterio di rete utilizzando remove-network-policy:
Ora l'app C non ha più accesso diretto alla comunicazione con l'app B come prima.
Quindi è chiaro come impostare la tua rete privata di container, ma come fanno le tue applicazioni a scoprire gli indirizzi IP interni degli altri?
In passato, dovevi utilizzare un servizio di discovery personalizzato come Eureka o scriverne uno tuo, ad esempio utilizzando un'istanza di servizio Redis a cui ogni app inviava l'IP del proprio container. Un esempio di questa tecnica tra un'applicazione frontend e una backend può essere visto qui su GitHub: c2cn_demo/redis_discovery(apre una nuova finestra)
Ma recentemente è stato introdotto un modo migliore e molto più semplice per trovare i servizi, integrato nella piattaforma stessa e disponibile di default per tutte le app.
L'Application Cloud di Swisscom supporta la service discovery basata su DNS, che consente alle tue applicazioni di trovare gli indirizzi IP interni delle altre. Ad esempio, un'istanza di app front-end può utilizzare il meccanismo di service discovery per stabilire una comunicazione con un'istanza di app back-end.
Il rilevamento dei servizi app da contenitore a contenitore non prevede il bilanciamento del carico lato client o l'interruzione del circuito. Permette semplicemente alle tue app di passare gli endpoint dei servizi l'uno all'altro senza alcuna commutazione.
Con l'App Service Discovery, le tue applicazioni che vengono inviate all'Application Cloud di Swisscom possono stabilire una comunicazione diretta da container a container attraverso un percorso noto che viene servito dal nostro DNS interno. A questo scopo è stato messo a disposizione il dominio speciale "apps.internal".
Con questo dominio, le tue applicazioni front-end possono trovare e connettersi facilmente a tutte le applicazioni back-end di cui hanno bisogno.
Per stabilire una comunicazione da contenitore a contenitore tra un'applicazione frontend e una backend, devi solo fare quanto segue:
L'applicazione frontend è ora in grado di trovare l'applicazione backend risolvendo i DNS da backend-app.apps.internal.
Gli IP risultanti sono gli IP di overlay interni di tutti i container delle app di backend e possono essere utilizzati per la comunicazione diretta.
Immagina la situazione in questo modo:
Puoi trovare un esempio che utilizza l'applicazione Service Discovery qui: Cats and Dogs with Service Discovery su GitHub, che dimostra la comunicazione tra le applicazioni frontend e backend su Cloud Foundry.
Se segui l'esempio, ti imbatterai in una situazione simile a questa:
Le app sono entrambe installate e hanno una politica di rete che consente al frontend di accedere al backend, di cui sono in esecuzione 4 istanze. L'elemento chiave è la rotta speciale dogs-backend.apps.internal, che è stata assegnata all'app di backend:
Il frontend può ora utilizzare questa rotta per interrogare tutti gli IP dei container dell'applicazione di backend tramite DNS:
Success!!!😀
Puoi trovare maggiori informazioni sull'applicazione Service Discovery qui: https://www.cloudfoundry.org/blog/polyglot-service-discovery-container-networking-cloud-foundry/ (apre una nuova finestra)
Provalo subito! https://developer.swisscom.com/(apre una nuova finestra)
Senior Cloud Engineer
Trova il posto di lavoro o il percorso di carriera che fa per te. Dove dare il tuo contributo e crescere professionalmente.
Ciò che tu fai, è ciò che siamo.
