Cu toții am auzit despre concept, o definiție cât mai scurtă ar fi "Accesarea la cerere, de resurse hardware și software, prin internet oferite de către un furnizor". Un Cloud Hibrid nu este altceva decât o combinație într-un Cloud Public de genul Microsoft Azure și resursele hardware locale.
Prin anii 80 și până la explozia Dot Com din anul 2000 majoritatea corporațiilor își țineau ocupate etaje, subsoluri cu echipamente hardware care valorau sute de milioane de dolari constând în mainframe-uri de ultima generație, switch-uri, routere și ehipamente de răcire.
Conceptul de Cloud există încă din anii 80 când corporațiile gigant închiriau resursele hardware companiilor mai mici, odată cu intrarea pe piață a jucătorilor mari de Cloud Computing multe din subsolurile cu echipamente hardware ale corporațiilor dispăreau.
După cum ziceam mai sus tot mai multe companii se "mută" în Cloud din diferite motive unul și cel mai evident este acela de cost dar și renunțarea la mentenanța echipamentelor hardware. Pe lângă cost și mentenanță un alt factor este scalabilitatea, este mult mai ușor într-un Cloud să adaugi resurse hardware bazate pe nevoile de consum decât într-un mediu local unde adăugarea de resurse hardware poate fi mult mai costisitoare și consumatoare de timp. Un Cloud Hibrid poate fi găzduit fie în locația unde compania își desfășoară activitatea fie de către un terț.
Un Public Cloud de genul Microsoft Azure nu este întotdeauna soluția cea mai optimă pentru multe din companii și asta din varii motive, unul din ele și cel mai frecvent întâlnit de noi a fost acela al securități și reglementărilor guvernamentale și atunci soluția unui Cloud Hibrid este mult mai plauzibilă fie el local sau printr-un terț.
Într-o astfel de situație am fost și noi implicați, în a găsii ceea mai optimă varianta de livrare a soluțiilor dezvoltate într-un Cloud Public - Microsoft Azure și un Cloud Hibrid printr-un terț.
Tehnologiile care sunt aprobate pentru conceperea acestui plan sunt Visual Studio Team Services (Recent sub numele de Azure DevOps) Microsoft Azure că și mediu Dev/Qa și SonarQube.
De ce Visual Studio Team Services (VSTS), pentru că este gratis pentru firmele care au încheiat un parteneriat cu Microsoft prin intermediul MSDN (Microsoft Developer Network) plus zero costuri cu mentenanță fiind un serviciu SaaS (Software-as-a-Service).
Cu toate astea că și cerință am început a elabora un concept și varianta din graficul de mai jos este și cea finală:
Pentru că totul să fie posibil în diagrama propusă ne vom folosi de un concept din VSTS numit Self Hosted Agents. De obicei un Cloud Hibrid se află în spatele unor firewall-uri și are conexiune limitată la internet sau internetul este deservit printr-un proxy.
Agentul de care ne vom folosi nu este altceva decât un serviciu de Windows (sau Linux, MacOS) care orchestrează toate acțiunile în Cloud-ul Hibrid, fie ele Deployments, rulări de teste automate sau Code Builds.
Funcționalitatea din spatele unui Agent Self Hosted este destul de simplă, el trebuie instalat pe o mașină dedicată în cazul nostru un Windows Server 2012R2 cu conexiune prin proxy la internet pe lângă asta mai este necesar că toate dependințele software să fie instalate pe mașină dedicată, aici depinde în funcție de tehnologia proiectului ce dependințe trebuie instalate.
Proiectul nostru este unul .NET 4.6.1 deci avem nevoie de Visual Build Tools.
Înainte de a conecta un Self Hosted Agent este necesar crearea unui nou Pool în secțiunea Agent Pools din VSTS pe care îl vom numi "DeploymentAgents" în acest fel vom știi că toți agenți care fac parte din acest Pool sunt doar Deployment Agents:
Imaginea de mai jos reprezintă pași de instalare a unui Self Hosted Agent:
Dacă mașină pe care se instalează agentul este conectată la internet printr-un proxy este nevoie de crearea unui fișier cu extensia .proxy unde se va specifică adresa de proxy sub formă de http://IP:(Port) , după ce fișierul .proxy a fost creat se poate rula scriptul config.cmd unde se specifică următoarele detalii:
Server URL - Adresa instanței de VSTS pentru care vrem să conectăm Self Hosted Agent și care are formatul https://dev.azure.com/(NumeCont)
Authentication Type- Se va specifică metoda de autentificare între Self Hosted Agent și instanța de VSTS. Implicit ceea mai bună opțiune este PAT sau Personal Access Token care se generează de către un administrator al instanței de VSTS.
Agent Pool - Dacă în instanța de VSTS există deja un Pool creat se va specifică acel Pool sau se va lăsa valoarea implicită care este Default.
Agent Name - Se va specifica un nume de identificare al agentului.
Work Folder - Locația de lucru pe disk, aici se vor găsi artefactele provenite din VSTS și codul sursă dacă Self Hosted Agent va fi folosit și pentru a compila cod.
Run Agent As Service - Se va specifica dacă se dorește rularea agentului că și serviciu Windows. Se recomandă rularea ca și serviciu, în acest fel se elimină posibilitatea unei întreruperi între Self Hosted Agent.
Dacă toate opțiunile au fost valide agentul se va înregistra în instanța de VSTS în grupul DeploymentAgents:
Avem așadar un Self Hosted Agent conectat la instanța noastră de VSTS el este disponibil pentru toate proiectele existente și nou create.
Mai urmează acum să configurăm planul de deployment în așa fel încât să se folosească de agentul nou adăugat în VSTS în acest fel avem scenariul din digrama propusă.
Pentru fiecare plan de deployment va fi nevoie schimbarea grupului sub Agent Pool cu cel sorespunzator Cloud-ului Hibrid, în cazul nostru grupul este "DeploymentAgents":
Am reușit cu ajutorul lui Visual Studio Team Services să implementăm o soluție de Continuous Delivery prin intermediul unui Self Hosted Agent care orchestrează livrarea artefactului între un Cloud Public - Microsoft Azure și un Cloud Hibrid care se află în spatele unui firewall și cu internet printr-un proxy server. Soluția este una fiabilă deoarece nu se modifică structura artefactului.
de Eugen Bușoiu
de Peter Lawrey
