Come utilizzare HashiCorp Waypoint per collaborare con GitLab CI/CD

Come utilizzare HashiCorp Waypoint per collaborare con GitLab CI/CD

HashiCorp ha mostrato un nuovo progetto Waypoint su HashiCorp Digital. Utilizza un file basato su HCL per descrivere la creazione, la spedizione e il rilascio di applicazioni per varie piattaforme cloud che vanno da Kubernetes ad AWS e Google Cloud Run. Pensa a Waypoint come a Terraform e Vagrant messi insieme per descrivere il processo di creazione, spedizione e rilascio delle tue applicazioni.

Fedele alla forma, HashiCorp ha rilasciato Waypoint come open source e include molti esempi. Il livello dell'orchestratore dipende da te, Waypoint si presenta come un eseguibile che puoi eseguire direttamente sul tuo laptop o dallo strumento di orchestrazione CI/CD che preferisci. Anche l'obiettivo di distribuzione dell'applicazione dipende da te, poiché Waypoint supporta Kubernetes, Docker, Google Cloud Run, AWS ECS e altro ancora.

Dopo aver letto il fantastico documentazione e il più chic esempi applicazioni fornite da HashiCorp, abbiamo deciso di dare un'occhiata più da vicino all'orchestrazione di Waypoint con GitLab CI/CD. Per fare ciò, prenderemo una semplice applicazione Node.js in esecuzione su AWS ECS dal repository di esempio.

Dopo aver clonato il repository, diamo un'occhiata alla struttura dell'applicazione che visualizza una pagina:

Come utilizzare HashiCorp Waypoint per collaborare con GitLab CI/CD

Come avrai notato, non è presente alcun Dockerfile in questo progetto. Non vengono aggiunti nell'esempio perché non ne abbiamo realmente bisogno, perché Waypoint se ne occuperà per noi. Diamo un'occhiata più da vicino al dossier waypoint.hclper capire cosa farà:

project = "example-nodejs"

app "example-nodejs" {
  labels = {
    "service" = "example-nodejs",
    "env" = "dev"
  }

  build {
    use "pack" {}
    registry {
    use "aws-ecr" {
        region = "us-east-1"
        repository = "waypoint-gitlab"
        tag = "latest"
    }
    }
  }

  deploy {
    use "aws-ecs" {
    region = "us-east-1"
    memory = "512"
    }
  }
}

Durante la fase di creazione, Waypoint utilizza Buildpack Cloud Native (CNB) per determinare il linguaggio di programmazione del progetto e creare un'immagine Docker senza utilizzare un Dockerfile. In linea di principio si tratta della stessa tecnologia utilizzata in parte da GitLab DevOps automatico nella fase di creazione automatica. È bello vedere che il CNB di CNCF sta guadagnando sempre più adozione tra gli utenti del settore.

Una volta creata l'immagine, Waypoint la caricherà automaticamente nel nostro registro AWS ECR in modo che sia pronta per la spedizione. Al termine dell'assemblaggio, viene utilizzata la fase di consegna Componente aggiuntivo AWS ECS per distribuire la nostra applicazione sul nostro account AWS.

Dal mio portatile è facile. Ho inserito Waypoint che è già autenticato nel mio account AWS e "funziona e basta". Ma cosa succede se voglio andare oltre il mio laptop? O forse voglio automatizzare questa distribuzione come parte della mia pipeline CI/CD complessiva in cui vengono eseguiti i miei attuali test di integrazione, test di sicurezza e altri? Questa è la parte della storia in cui entra in gioco GitLab CI/CD!

NB Se stai solo pianificando di implementare CI/CD o vuoi iniziare ad applicare le migliori pratiche per la costruzione di pipeline, presta attenzione al nuovo corso Slurm. "CI/CD sull'esempio di Gitlab CI". È ora disponibile al prezzo di preordine.

Waypoint in GitLab CI/CD

Per orchestrare tutto questo in GitLab CI/CD, vediamo cosa ci serve nel nostro file .gitlab-ci.yml:

  • Prima di tutto, hai bisogno di un'immagine di base da eseguire al suo interno. Waypoint funziona su qualsiasi distribuzione Linux, necessita solo di Docker, quindi possiamo eseguire con un'immagine Docker generica.
  • Successivamente, è necessario installare Waypoint in questa immagine. In futuro potremmo raccogliere immagine di meta-creazione e containerizzare questo processo per te stesso.
  • Infine eseguiremo i comandi Waypoint

Sopra c'è tutto ciò di cui la nostra pipeline avrà bisogno per eseguire gli script necessari per eseguire la distribuzione, ma per distribuire su AWS abbiamo bisogno di un'altra cosa: dobbiamo accedere al nostro account AWS. Nella descrizione del waypoint avere dei piani sull'autenticazione e l'autorizzazione. HashiCorp ha anche rilasciato un progetto impressionante questa settimana Boundary. Ma per ora possiamo semplicemente prendere e gestire noi stessi l'autenticazione e l'autorizzazione.

Sono disponibili diverse opzioni per l'autenticazione CICD GitLab su AWS. La prima opzione è utilizzare il built-in Volta HashiCorp. Non è un problema se il tuo team utilizza già Vault per la gestione delle credenziali. Un altro metodo che funziona se il tuo team gestisce l'autorizzazione utilizzando AWS IAM è verificare che le attività di consegna vengano attivate tramite Corridore di GitLabA autorizzato ad avviare la distribuzione tramite IAM. Ma se vuoi solo acquisire familiarità con Waypoint e vuoi farlo rapidamente, l'ultima opzione è aggiungere l'API AWS e le chiavi segrete a Variabili di ambiente CI/CD GitLab AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY.

Mettendo tutto insieme

Una volta individuata l'autenticazione, possiamo iniziare! La nostra finale .gitlab-ci.yml Ecco come si presenta:

waypoint:
  image: docker:latest
  stage: build
  services:
    - docker:dind
  # Define environment variables, e.g. `WAYPOINT_VERSION: '0.1.1'`
  variables:
    WAYPOINT_VERSION: ''
    WAYPOINT_SERVER_ADDR: ''
    WAYPOINT_SERVER_TOKEN: ''
    WAYPOINT_SERVER_TLS: '1'
    WAYPOINT_SERVER_TLS_SKIP_VERIFY: '1'
  script:
    - wget -q -O /tmp/waypoint.zip https://releases.hashicorp.com/waypoint/${WAYPOINT_VERSION}/waypoint_${WAYPOINT_VERSION}_linux_amd64.zip
    - unzip -d /usr/local/bin /tmp/waypoint.zip
    - rm -rf /tmp/waypoint*
    - waypoint init
    - waypoint build
    - waypoint deploy
    - waypoint release

Vedi, iniziamo con un'immagine docker:latest e impostare alcune variabili di ambiente richieste da Waypoint. Nel capitolo script scarichiamo l'ultimo eseguibile di Waypoint e lo inseriamo /usr/local/bin. Poiché il nostro corridore è già autorizzato in AWS, corriamo semplicemente waypoint init, build, deploy и release.

L'output dell'attività di compilazione ci mostrerà l'endpoint in cui abbiamo eseguito il rolling dell'applicazione:

Come utilizzare HashiCorp Waypoint per collaborare con GitLab CI/CD

Punto di passaggio uno di numerose soluzioni HashiCorp, che funzionano benissimo con GitLab. Ad esempio, oltre a fornire l'applicazione, possiamo orchestrare l'infrastruttura sottostante Terraformare in GitLab. Per standardizzare la sicurezza SDLC, possiamo anche implementare GitLab con Vault per la gestione di segreti e token nelle pipeline CI/CD, fornendo una soluzione completa per sviluppatori e amministratori che si affidano alla gestione dei segreti per lo sviluppo, il test e l'utilizzo in produzione.

Le soluzioni congiunte sviluppate da HashiCorp e GitLab aiutano le aziende a trovare il modo migliore per sviluppare applicazioni garantendo una gestione coerente della catena di fornitura e dell'infrastruttura. Waypoint ha fatto un altro passo nella giusta direzione e non vediamo l'ora di sviluppare ulteriormente il progetto. Puoi saperne di più su Waypoint quivale anche la pena esplorare documentazione и piano di sviluppo progetto. Abbiamo aggiunto la nostra conoscenza a Documentazione GitLab CICD. Se vuoi provarlo tu stesso, puoi controllare l'esempio funzionante completo su questo deposito.

Puoi comprendere i principi di CI/CD, padroneggiare tutte le sottigliezze del lavoro con Gitlab CI e iniziare ad applicare le migliori pratiche completando il video corso "CI/CD sull'esempio di Gitlab CI"... Unisciti a noi!

Fonte: habr.com

Aggiungi un commento