Cum să utilizați HashiCorp Waypoint pentru colaborare cu GitLab CI/CD

HashiCorp a prezentat un nou proiect Waypoint pe HashiCorp Digital. Folosește un fișier bazat pe HCL pentru a descrie construirea, livrarea și lansarea aplicațiilor pe diverse platforme cloud, de la Kubernetes la AWS și Google Cloud Run. Poate fi văzut ca o combinație între Terraform și Vagrant pentru a descrie procesul de construire, livrare și lansare a aplicațiilor dumneavoastră.

Fără a se schimba, HashiCorp a lansat Waypoint ca un proiect open-source, venind și cu o mulțime de exemple. Nivelul orchestratorului rămâne la alegerea dumneavoastră, Waypoint fiind livrat sub forma unui executabil pe care îl puteți rula direct de pe laptopul dumneavoastră sau din instrumentul de orchestrare CI/CD ales. Scopul pentru desfășurarea aplicațiilor este, de asemenea, ales de dumneavoastră, întrucât Waypoint suportă Kubernetes, Docker, Google Cloud Run, AWS ECS și altele.

După ce am citit documentație și cele mai impresionate exemple aplicații furnizate de HashiCorp, am decis să aruncăm o privire mai atentă asupra orchestration-ului Waypoint folosind GitLab CI/CD. Pentru aceasta, vom lua o aplicație simplă Node.js, care rulează pe AWS ECS, din repository-ul de exemple.

După clonarea repository-ului, vom analiza structura aplicației, care afișează o singură pagină:

Așa cum ați observat, în acest proiect nu există un Dockerfile. Acestea nu au fost incluse în exemplu, deoarece nu ne sunt necesare, deoarece Waypoint se va ocupa de ele pentru noi. Să analizăm mai în detaliu fișierul waypoint.hcl, pentru a înțelege ce va face:

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"
    }
  }
}

În etapa de construire, Waypoint folosește Cloud Native Buildpacks (CNB), pentru a determina limbajul de programare al proiectului și a crea o imagine pentru Docker fără a folosi Dockerfile. În esență, aceasta este aceeași tehnologie care este utilizată de GitLab în secțiunea Auto DevOps la pasul Auto Build. Este plăcut să vedem că CNB de la CNCF câștigă o popularitate tot mai mare printre utilizatori din industrie.

Odată ce imaginea a fost construită, Waypoint o va încărca automat în registrul nostru AWS ECR, pentru a fi gata pentru livrare. La finalizarea construcției, pasul de livrare utilizează complementul AWS ECS pentru a desfășura aplicația noastră în contul nostru AWS.

De pe laptopul meu – totul este simplu. Instalăm Waypoint, care este deja autentificat în contul meu AWS, și „pur și simplu funcționează”. Dar ce se întâmplă dacă vreau să ieș să depășesc laptopul meu? Sau, la un moment dat, vreau să automatizez acest proces de desfășurare ca parte a întregului meu pipeline CI/CD, unde se rulează testele mele de integrare, testele de securitate și altele? Aceasta este partea poveștii în care intră GitLab CI/CD!

N.B. Dacă abia planificați implementarea CI/CD sau doriți să începeți să aplicați cele mai bune practici pentru construirea pipeline-urilor, aruncați o privire asupra noului curs oferit de Slyrma. „CI/CD prin exemplul Gitlab CI”. Acum este disponibil la un preț de precomandă.

Waypoint în GitLab CI/CD

Pentru orchestrarea tuturor acestora în GitLab CI/CD, să vedem ce ne va fi necesar în fișierul nostru. .gitlab-ci.yml:

• În primul rând, avem nevoie de o imagine de bază pentru a rula. Waypoint funcționează pe orice distribuție Linux, necesită doar Docker, astfel încât putem să începem cu o imagine generică Docker.
• Apoi, trebuie să instalăm Waypoint în această imagine. În viitor, putem construi imaginea build meta și să containerizăm acest proces pentru noi.
• În cele din urmă, vom rula comenzile Waypoint.

Mai sus este descris tot ce va avea nevoie pipeline-ul nostru pentru a rula scripturile necesare desfășurării, dar pentru desfășurarea în AWS ne va mai trebui un lucru: trebuie să ne autentificăm în contul nostru AWS. În documentația Waypoint există planuri despre autentificare și autorizare. HashiCorp a lansat săptămâna aceasta un proiect impresionant Boundary. Dar în acest moment, putem pur și simplu să gestionăm noi autentificarea și autorizarea.

Pentru autentificarea GitLab CICD în AWS există mai multe opțiuni. Prima opțiune este utilizarea integrată HashiCorp Vault. Aceasta este potrivită dacă echipa ta deja folosește Vault pentru gestionarea credențialelor. O altă metodă, care este potrivită dacă echipa ta gestionează autorizarea prin AWS IAM – asigurați-vă că sarcinile de desfășurare se execută prin GitLab Runner, autorizat să ruleze desfășurarea prin IAM. Dar dacă doriți doar să explorați Waypoint și doriți să o faceți mai repede, există o ultimă opțiune – să adăugați cheile tale AWS API și Secret în variabilele de mediu GitLab CI/CD AWS_ACCESS_KEY_ID și AWS_SECRET_ACCESS_KEY.

Adunăm totul laolaltă

Odată ce ne-am ocupat de autentificare, putem începe! Rezultatul nostru final .gitlab-ci.yml arată astfel:

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

Vedeți că începem cu imaginea docker:latest și setăm câteva variabile de mediu necesare pentru Waypoint. În secțiunea script descărcăm cea mai recentă versiune a fișierului executabil Waypoint și îl instalăm în /usr/local/bin. Deoarece runner-ul nostru este deja autentificat în AWS, continuăm pur și simplu cu comanda waypoint init, build, deploy și release.

Ieşirea din sarcina de construire ne va arăta endpoint-ul la care am distribuit aplicația:

Waypoint este una dintre multe soluții HashiCorp, care funcționează excelent cu GitLab. De exemplu, pe lângă livrarea aplicației, putem orchestri infrastructura subiacente cu ajutorul Terraform în GitLab. Pentru standardizarea securității SDLC, putem, de asemenea, integra GitLab cu Vault pentru gestionarea secretelor și token-urilor în pipe-urile CI/CD, oferind o soluție completă pentru dezvoltatori și administratori, care depind de gestionarea secretelor în timpul dezvoltării, testării și utilizării în medii de producție.

Soluțiile comune dezvoltate de HashiCorp și GitLab ajută companiile să găsească cea mai bună modalitate de a dezvolta aplicații, asigurând un management coerent al fluxurilor de livrare și infrastructurii. Waypoint a făcut un alt pas în direcția corectă și așteptăm cu nerăbdare dezvoltarea ulterioară a proiectului. Puteți afla mai multe despre Waypoint aici, ar trebui să explorați și documentație și plan de dezvoltare proiectului. Am adăugat cunoștințele obținute în documentația GitLab CICD. Dacă doriți să încercați totul în acțiune pe cont propriu, puteți lua un exemplu complet funcțional în acest depozit.

Înțelegerea principiilor CI/CD, stăpânirea tuturor subtilităților lucrului cu Gitlab CI și începerea aplicării celor mai bune practici pot fi realizate parcurgând cursul video „CI/CD prin exemplul Gitlab CI”. Alăturați-vă!

Sursa: habr.com