Deployment multicloud per GitOps tramite GitLab: demo
Scopri come la compatibilità multicloud supporta i flussi di lavoro GitOps. Questa demo mostra come eseguire il deployment delle applicazioni su tre server Kubernetes utilizzando un flusso di lavoro comune.
I flussi di lavoro GitOps utilizzano un repository Git come unica fonte di riferimento per promuovere la collaborazione fra i team dell'infrastruttura e accelerare lo sviluppo e la distribuzione del software. Quando i team delle operazioni utilizzano i flussi di lavoro GitOps, scegliere GitLab come repository principale comporta vantaggi che vanno ben oltre il controllo della versione. I team si affidano a GitLab per la natura collaborativa della sua piattaforma, per la facilità di deployment dell'infrastruttura e per la compatibilità multicloud.
Questa demo mostra come eseguire il deployment delle applicazioni su tre server Kubernetes utilizzando un flusso di lavoro comune. I team scopriranno come eseguire con successo il deployment delle applicazioni utilizzando Auto DevOps, una suite di funzionalità basata sulla CI di GitLab, con Helm e Kubernetes.
Per prima cosa, è necessario aprire il file README.md del gruppo gitops-demo, di cui ne mostra la struttura. Oltre ad alcuni progetti, vi sono due sottogruppi: infrastruttura e applicazioni.
In questa demo sono presenti quattro applicazioni (my-asp-net-app1, my-spring-app2, my-ruby-app3, my-python-app4) e tre cluster Kubernetes, ciascuno dei quali corrispondente a un diverso ambiente cloud: Microsoft Azure (AKS), Amazon (EKS) e Google Cloud (GKE).
Cliccando sul pulsante Kubernetes nell'angolo sinistro, si può vedere che tutti i cluster sono registrati su GitLab. Gli ambiti ambientali specificano l'applicazione di cui viene eseguito il deployment in ogni cloud.
AutoDevOps in funzione
Il primo esempio è un'applicazione ASP.NET, ovvero l'equivalente di un'app Hello World. Alcune modifiche sono specifiche per il tipo di deployment di questa applicazione e si trovano nel file di CI dell'applicazione.
Per prima cosa, è necessario importare il modello Auto DevOps principale impostando un paio di variabili. Quindi, è importante sovrascrivere alcuni comandi per le fasi più pertinenti al codice .NET. Infine, bisogna impostare automaticamente l'ambiente per eseguire il deployment della produzione in AKS.
include:
-template: Auto-DevOps.gitlab-ci.yml
variables:
DEPENDENCY_SCANNING_DISABLED: "true"
test:
stage: test
image: microsoft/dotnet:latest
script:
-'dotnet test --no-restore'
license_management:
stage: test
before_script:
-sudo apt-get update
-sudo apt-get install -y dotnet-runtime-2.2 dotnet-sdk-2.2
production:
environment:
name: aks/production
url: http://$CI_PROJECT_PATH_SLUG.$KUBE_INGRESS_BASE_DOMAIN
La pipeline verrà eseguita automaticamente e il deployment avrà esito positivo. Visualizzando la pipeline, è possibile scoprire come funziona il deployment.
Si possono inoltre consultare le fasi della pipeline, dallo sviluppo alla produzione per l'applicazione ASP.NET.
Una rapida occhiata all'interno della pipeline mostra che tutti i job sono stati completati correttamente. La funzionalità Auto DevOps ha avviato la fase di sviluppo, che crea un container Docker e lo carica nel registro Docker integrato. La fase di test è completa e include la scansione dei container, la gestione delle licenze, il SAST e i test unitari. Per approfondire i risultati dei test, clicca sulle schede Sicurezza e Licenza. Il deployment dell'applicazione viene eseguito in produzione nella fase finale della pipeline.
All'interno del cluster AKS
L'applicazione ASP.NET è in fase di deployment nel cluster AKS. Vai su Operazioni > Ambienti per visualizzare l'ambiente configurato per questa applicazione. Sono disponibili metriche come i tassi di errore HTTP, i tassi di latenza e la portata, in quanto Prometheus è già integrato nei cluster Kubernetes di GitLab.
L'ambiente può essere avviato direttamente cliccando sull'URL alla versione live per visualizzare l'applicazione in esecuzione su AKS. Non c'è molto codice aggiuntivo oltre a quello già configurato in GitLab che dice all'applicazione come eseguire il deployment. La funzione Auto DevOps crea un grafico Helm ed esegue il deployment su Kubernetes e AKS.
Nella demo, imparerai come configurare l'applicazione Spring in modo simile all'applicazione ASP.NET utilizzando un Dockerfile. Il Dockerfile viene inserito nella directory principale del repository.
ROM maven:3-jdk-8-alpine
WORKDIR /usr/src/app
COPY . /usr/src/app
RUN mvn package
ENV PORT 5000
EXPOSE $PORT
CMD [ "sh", "-c", "mvn -Dserver.port =${PORT} spring-boot:run" ]
Il deployment dell'applicazione Spring differisce dall'applicazione ASP.NET in un modo: non ha bisogno di override nel modello AutoDevOps, perché utilizza il modello predefinito, eseguendo il deployment su GKE anziché su AKS. Il flusso di lavoro per il deployment delle applicazioni è identico indipendentemente dal cloud su cui viene eseguito il deployment dell'applicazione. Questo rende facile il multicloud.
È importante produrre una build, un test e un ciclo di produzione simili in questo ambiente. In questo modo, i team possono ottenere le stesse metriche, i tassi di errore, le latenze e le portate. In questo caso, l'applicazione viene eseguita automaticamente in un container su Kubernetes nel cluster GKE.
L'ultimo esempio è un'applicazione Python che esegue il deployment su EKS. I componenti sono simili agli esempi precedenti e utilizzano gitlab-ci.yml per modificare l'ambiente di produzione in EKS e un Dockerfile per preparare il grafico Helm. Ci sono anche alcuni override.
include:
- template: Auto-DevOps.gitlab-ci.yml
test:
image: python:3.7
script:
- pip install -r requirements.txt
- pip install pylint
- pylint main.py
produzione:
ambiente:
nome: eks/produzione
url: http://$CI_PROJECT_PATH_SLUG.$KUBE_INGRESS_BASE_DOMAIN
Il file CI di GitLab indica all'applicazione di eseguire il deployment su EKS.
FROM python:3.7
WORKDIR /app
ADD . /app/
RUN pip install -r requirements.txt
EXPOSE 5000
CMD ["pitone", "/app/main.py"
Il Dockerfile prepara il grafico Helm.
Proprio come negli esempi precedenti, la pipeline funziona allo stesso modo delle altre applicazioni con fasi di compilazione, test e produzione. Una volta eseguito il deployment dell'applicazione su EKS, è possibile aprire il collegamento live e vedere l'applicazione Python nella finestra del browser.
GitLab è una vera soluzione multicloud che consente alle aziende di prendere decisioni sul provider di servizi cloud che desiderano utilizzare, senza flussi di lavoro disparati, pur mantenendo buone pratiche GitOps. Tutto questo è un'interfaccia coerente con lo stesso flusso di lavoro, che semplifica il deployment su qualsiasi cloud principale che esegue Kubernetes integrato con GitLab.
Una buona pratica GitOps consiste nel rendere un repository Git l'unica fonte di riferimento per tutto il codice. Sebbene qualsiasi repository Git possa essere sufficiente per una buona procedura GitOps, ci sono pochi strumenti DevOps che racchiudono veramente i pilastri fondamentali di GitOps: collaborazione, trasparenza nel processo e controllo della versione.
Strumenti come epic, ticket e richieste di merge, che sono il punto cruciale di GitLab, promuovono la comunicazione e la trasparenza tra i team. I team dell'infrastruttura possono creare codice utilizzando template Terraform o Ansible in GitLab ed eseguire il deployment nel cloud utilizzando GitLab CI. GitLab è la vera soluzione multicloud, che consente ai team di effettuare il deployment di un'applicazione su qualsiasi servizio cloud utilizzando GitLab CI e Kubernetes senza dover aumentare significativamente i flussi di lavoro.
Vuoi iniziare?
Scopri cosa è capace di fare il tuo team grazie a una piattaforma DevSecOps unificata.