.NET Core op Linux, DevOps op Päerd

Mir hunn DevOps sou gutt wéi méiglech entwéckelt. Et waren 8 vun eis, an de Vasya war déi coolst a Windows. Op eemol ass de Vasya fortgaang, an ech hat d'Aufgab fir en neie Projet ze lancéieren deen duerch Windows Entwécklung geliwwert gouf. Wann ech de ganze Windows Entwécklungsstapel op den Dësch dumpen, hunn ech gemierkt datt d'Situatioun e Péng war ...

Sou fänkt d'Geschicht un Alexandra Sinchinova op DevOpsConf. Wéi de féierende Windows Spezialist d'Firma verléisst, huet den Alexander sech gefrot wat elo ze maachen. Wiesselt op Linux, natierlech! Den Alexander wäert Iech soen wéi hien et fäerdeg bruecht huet e Präzedenz ze kreéieren an en Deel vun der Windows Entwécklung op Linux ze transferéieren mam Beispill vun engem fäerdege Projet fir 100 Endbenotzer.

.NET Core op Linux, DevOps op Päerd

Wéi einfach an ouni Ustrengung e Projet op RPM mat TFS, Puppet, Linux .NET Kär ze liwweren? Wéi ënnerstëtzen d'Versionéierung vun enger Projektdatabase wann d'Entwécklungsteam d'Wierder Postgres a Flyway fir d'éischte Kéier héiert, an d'Deadline ass iwwermuer? Wéi integréieren ech mat Docker? Wéi motivéiere .NET Entwéckler Windows a Smoothies opzeginn zugonschte vu Puppet a Linux? Wéi ideologesch Konflikter ze léisen wann et weder d'Kraaft, nach de Wonsch, nach d'Ressourcen ass fir Windows an der Produktioun z'erhalen? Iwwer dëst, wéi och iwwer Web Deploy, Testen, CI, iwwer d'Praktiken fir TFS an existente Projeten ze benotzen, an natierlech iwwer gebrochene Krutzen an Aarbechtsléisungen, am Transkript vum Alexander Bericht.


Also, Vasya lénks, d'Aufgab ass op mech, d'Entwéckler waarden ongedëlleg mat Pitchforks. Wéi ech endlech gemierkt hunn datt Vasya net zréckkoum, sinn ech op d'Geschäft komm. Fir unzefänken, hunn ech de Prozentsaz vu Win VMs an eiser Flott bewäert. De Score war net zugonschte vu Windows.

.NET Core op Linux, DevOps op Päerd

Well mir aktiv DevOps entwéckelen, hunn ech gemierkt datt eppes muss geännert ginn an der Approche fir eng nei Applikatioun ze liwweren. Et gouf nëmmen eng Léisung - wa méiglech, alles op Linux iwwerdroen. Google huet mir gehollef - zu där Zäit war .Net schonn op Linux portéiert ginn, an ech hu gemierkt datt dëst d'Léisung war!

Firwat .NET Kär a Verbindung mat Linux?

Et waren e puer Grënn dofir. Tëscht "Suen bezuelen" an "net bezuelen", wäert d'Majoritéit déi zweet wielen - wéi ech. Eng Lizenz fir MSDB kascht ongeféier $ 1 fir eng Flott vu Windows virtuelle Maschinnen z'erhalen, kascht Honnerte vun Dollar. Fir eng grouss Firma ass dëst eng grouss Ausgab. Dat ass wouvir spueren - éischte Grond. Net déi wichtegst, awer ee vun de bedeitendsten.

Windows virtuelle Maschinnen huelen méi Ressourcen op wéi hir Linux Bridder - si schwéier. Wéinst der Skala vun der grousser Firma hu mir Linux gewielt.

De System ass einfach an existéierend CI integréiert. Mir betruechten eis progressiv DevOps, mir benotzen Bamboo, Jenkins a GitLab CI, sou datt déi meescht vun eiser Aarbecht op Linux leeft.

De leschte Grond ass bequem Begleedung. Mir mussen d'Barriär fir d'Entrée fir "Eskort" erofsetzen - d'Jongen, déi den techneschen Deel verstoen, onënnerbrach Service garantéieren an d'Servicer vun der zweeter Linn erhalen. Si ware scho vertraut mam Linux Stack, sou datt et vill méi einfach ass fir si en neit Produkt ze verstoen, z'ënnerstëtzen an z'erhalen wéi zousätzlech Ressourcen ze verbréngen fir déiselwecht Funktionalitéit vu Software fir d'Windows Plattform ze verstoen.

Ufuerderunge

Éischtens a virun allem - Komfort vun der neier Léisung fir Entwéckler. Net all vun hinnen ware prett fir Ännerung, besonnesch nodeems d'Wuert Linux geschwat gouf. Entwéckler wëllen hire Liiblings Visual Studio, TFS mat Autotester fir Assembléeën a Smoothies. Wéi d'Liwwerung an d'Produktioun geschitt ass net wichteg fir si. Dofir hu mir décidéiert den übleche Prozess net z'änneren an alles fir Windows Entwécklung onverännert ze loossen.

Neie Projet gebraucht integréieren an bestehend CI. D'Schinne ware schonn do an all d'Aarbechte musse gemaach ginn andeems d'Parameteren vum Konfiguratiounsmanagementsystem, akzeptéierte Liwwernormen an Iwwerwaachungssystemer berücksichtegt ginn.

Einfachheet vun Ënnerstëtzung an Operatioun, als Konditioun fir de Minimum Entrée Schwell fir all nei Participanten aus verschiddenen Divisiounen an der Ënnerstëtzung Departement.

Frist - gëschter.

Gewënn Entwécklung Group

Mat wat huet d'Windows Team dann geschafft?

.NET Core op Linux, DevOps op Päerd

Elo kann ech dat zouversiichtlech soen IdentitéitServer 4 ass eng cool gratis Alternativ zu ADFS mat ähnlechen Fäegkeeten, oder wat Entity Framework Core - e Paradäis fir en Entwéckler, wou Dir net braucht fir SQL Scripten ze schreiwen, awer Ufroen an der Datebank an OOP Begrëffer beschreiwen. Awer dann, während der Diskussioun vum Aktiounsplang, hunn ech dëse Stack gekuckt wéi wann et sumeresch Spëtzeform wier, nëmmen PostgreSQL a Git erkennen.

Deemools hu mir aktiv benotzt Puppelchen als Configuratioun Gestioun System. An de meeschte vun eise Projeten hu mir benotzt GitLab CI, elastesche, equilibréiert héich-Laascht Servicer benotzt HAProxy iwwerwaacht alles mat Zabbix, Bänner grafana и Prometheus, Jaeger, an dat alles huet op Eisenstécker gedréint HPESXi op Dialekter. Jidderee weess et - e Klassiker vum Genre.

.NET Core op Linux, DevOps op Päerd

Loosst eis kucken a probéieren ze verstoen wat geschitt ass ier mer all dës Interventiounen ugefaang hunn.

Wat ass geschitt

TFS ass e zimmlech mächtege System deen net nëmmen Code vum Entwéckler op déi lescht Produktiounsmaschinn liwwert, awer och e Set huet fir ganz flexibel Integratioun mat verschiddene Servicer - fir CI op engem Cross-Plattform Niveau ze bidden.

.NET Core op Linux, DevOps op Päerd
Virdrun waren dat zolidd Fënsteren. TFS huet verschidde Build Agenten benotzt, déi benotzt gi fir vill Projeten ze sammelen. All Agent huet 3-4 Aarbechter fir Aufgaben ze paralleliséieren an de Prozess ze optimiséieren. Dann, laut Verëffentlechungspläng, huet TFS de frësch gebakene Build op de Windows Applikatiounsserver geliwwert.

Wat wollte mir erreechen?

Mir benotzen TFS fir Liwwerung an Entwécklung, a lafen der Applikatioun op engem Linux Applikatioun Server, an et gëtt eng Zort Magie tëscht hinnen. Dëst Magic Box an do ass d'Salz vun der Aarbecht virun. Ier ech et auserneen huelen, huelen ech e Schrëtt op der Säit a soen e puer Wuert iwwer d'Applikatioun.

De Projet

D'Applikatioun bitt Funktionalitéit fir Prepaid Kaarten ze handhaben.

.NET Core op Linux, DevOps op Päerd

Client

Et waren zwou Zorte vu Benotzer. Déi éischt krut Zougang andeems Dir en SSL SHA-2 Zertifika benotzt. U déi zweet et gouf Zougang mat engem Login a Passwuert.

HAProxy

Dunn ass d'Client Ufro un HAProxy gaang, wat déi folgend Probleemer geléist huet:

  • primär Autorisatioun;
  • SSL Terminatioun;
  • Tuning HTTP-Ufroen;
  • Emissioun Ufroen.

De Client Zertifika gouf laanscht d'Kette verifizéiert. Mir - Autoritéit a mir kënnen dat leeschten, well mir selwer Certificaten un Service Clienten erausginn.

Opgepasst op den drëtte Punkt, mir kommen e bësse méi spéit drop zréck.

Backend

Si hu geplangt de Backend op Linux ze maachen. De Backend interagéiert mat der Datebank, lued déi néideg Lëscht vu Privilegien an dann, ofhängeg vu wéi eng Privilegien den autoriséierte Benotzer huet, Zougang fir finanziell Dokumenter z'ënnerschreiwen an se fir d'Ausféierung ze schécken oder eng Zort Bericht ze generéieren.

Spueren mat HAProxy

Zousätzlech zu den zwee Kontexter, déi all Client navigéiert huet, gouf et och en Identitéitskontext. IdentitéitServer 4 erlaabt Iech just aloggen, dëst ass e gratis a mächtege Analog fir ADFS - Active Directory Federatiounsservicer.

D'Identitéitsufro gouf a verschiddene Schrëtt veraarbecht. Éischt Schrëtt - Client koum an de Backend, déi mat dësem Server kommunizéiert an d'Präsenz vun engem Token fir de Client iwwerpréift huet. Wann et net fonnt gouf, gouf d'Ufro zréck an de Kontext zréckginn, aus deem se koum, awer mat engem Viruleedung, a mat der Viruleedung ass et op d'Identitéit gaangen.

Zweete Schrëtt - d'Demande gouf kritt op d'Autorisatiounssäit am IdentityServer, wou de Client sech registréiert huet, an dee laang erwaarde Token an der IdentityServer Datebank erschéngt.

Drëtte Schrëtt - de Client gouf zréckgeleet zum Kontext aus deem et koum.

.NET Core op Linux, DevOps op Päerd

IdentityServer4 huet eng Feature: et gëtt d'Äntwert op d'Retour Ufro iwwer HTTP zréck. Egal wéi vill mir mat der Opstellung vum Server gekämpft hunn, egal wéi vill mir eis mat der Dokumentatioun opgekläert hunn, all Kéier hu mir eng initial Clientsufro mat enger URL kritt déi iwwer HTTPS koum, an IdentityServer huet deeselwechte Kontext zréckginn, awer mat HTTP. Mir waren schockéiert! A mir hunn dat alles duerch den Identitéitskontext op HAProxy transferéiert, an an den Header hu mir den HTTP Protokoll op HTTPS geännert.

Wat ass d'Verbesserung a wou hutt Dir gespuert?

Mir hunn Sue gespuert andeems Dir eng gratis Léisung benotzt fir e Grupp vu Benotzer, Ressourcen ze autoriséieren, well mir IdentityServer4 net als separat Node an engem separaten Segment gesat hunn, awer et zesumme mam Backend um selwechte Server benotzt hunn wou de Backend vun der Applikatioun leeft .

Wéi soll et funktionéieren

Also, wéi ech versprach hunn - Magic Box. Mir verstinn schonn datt mir garantéiert sinn a Richtung Linux ze bewegen. Loosst eis spezifesch Aufgaben formuléieren déi Léisungen erfuerderen.

.NET Core op Linux, DevOps op Päerd

Puppet manifestéiert. Fir Service- an Applikatiounskonfiguratioun ze liwweren an ze verwalten, hu cool Rezepter misse geschriwwe ginn. A Rouleau Bläistëft Éloquently weist wéi séier an efficace et gemaach gouf.

Liwwerung Method. De Standard ass RPM. Jiddereen versteet datt am Linux Dir net ouni et maache kënnt, awer de Projet selwer, no der Assemblée, war eng Rei vun ausführbaren DLL-Dateien. Et waren ongeféier 150 vun hinnen, de Projet war zimlech schwéier. Déi eenzeg harmonesch Léisung ass dës Binär an RPM ze packen an d'Applikatioun dovun ofzesetzen.

Versionéierung. Mir hu ganz dacks misse fräiginn, a mir hu missen entscheeden wéi de Package Numm ze bilden. Dëst ass eng Fro vum Niveau vun der Integratioun mat TFS. Mir haten e Build Agent op Linux. Wann TFS eng Aufgab un en Handler - Aarbechter - un de Build Agent schéckt, passéiert et och eng Rëtsch Variabelen déi an der Ëmfeld vum Handlerprozess ophalen. Dës Ëmfeldvariablen enthalen de Build Numm, Versiounsnumm an aner Variablen. Liest méi iwwer dëst an der Rubrik "En RPM Package bauen".

TFS Ariichten koum erof fir Pipeline opzestellen. Virdrun hu mir all Windows Projeten op Windows Agenten gesammelt, awer elo erschéngt e Linux Agent - e Build Agent, dee muss an der Build Grupp abegraff sinn, mat e puer Artefakte beräichert, a gesot wéi eng Zort vu Projeten op dësem Build Agent gebaut ginn , an iergendwéi d'Pipeline änneren.

IdentityServer. ADFS ass net eise Wee, mir gi fir Open Source.

Loosst eis duerch d'Komponente goen.

Magic Box

Besteet aus véier Deeler.

.NET Core op Linux, DevOps op Päerd

Linux Build Agent. Linux, well mir dofir bauen - et ass logesch. Dësen Deel gouf an dräi Schrëtt gemaach.

  • Aarbechter konfiguréieren an net eleng, zënter verdeelt Aarbecht op de Projet war erwaart.
  • Installéiert .NET Core 1.x. Firwat 1.x wann 2.0 schonn am Standard Repository verfügbar ass? Well wa mir d'Entwécklung ugefaang hunn, war déi stabil Versioun 1.09, an et gouf decidéiert de Projet op der Basis ze maachen.
  • Gitt 2.x.

RPM-Repository. RPM Packagen mussen iergendwou gelagert ginn. Et gouf ugeholl datt mir dee selwechte Firmen-RPM-Repository benotzen deen fir all Linux Hosten verfügbar ass. Dat ass wat se gemaach hunn. De Repository Server ass konfiguréiert Webhook deen den erfuerderleche RPM Package vun der spezifizéierter Plaz erofgelueden huet. D'Package Versioun gouf dem Webhook vum Build Agent gemellt.

GitLab. Opgepasst! GitLab hei gëtt net vun Entwéckler benotzt, mee vun der Operatiounsdepartement fir Applikatiounsversioune, Package Versiounen ze kontrolléieren, de Status vun all Linux Maschinnen ze iwwerwaachen, an et späichert d'Rezept - all Puppet Manifestatiounen.

Puppelchen - léist all kontrovers Themen a liwwert genau d'Konfiguratioun déi mir vu Gitlab wëllen.

Mir fänken un ze tauchen. Wéi funktionnéiert DLL Liwwerung op RPM?

Liwwerung DDL zu RPM

Loosst d'soen mir hunn eng .NET Entwécklung Rock Star. Et benotzt Visual Studio a erstellt eng Verëffentlechungszweig. Duerno lued et op Git erop, a Git hei ass eng TFS Entitéit, dat heescht, et ass den Applikatiounsrepository mat deem den Entwéckler schafft.

.NET Core op Linux, DevOps op Päerd

Duerno gesäit den TFS datt en neien Engagement ukomm ass. Wéi eng App? An den TFS Astellunge gëtt et e Label deen ugeet wéi eng Ressourcen e bestëmmte Build Agent huet. An dësem Fall gesäit hien datt mir en .NET Core Projet bauen a wielt e Linux Build Agent aus dem Pool.

De Build Agent kritt d'Quellen an luet déi néideg erof Ofhängegkeeten aus dem .NET Repository, npm, etc. an no der Bau vun der Applikatioun selwer a spéider Verpakung, schéckt de RPM Package un de RPM Repository.

Op der anerer Säit geschitt déi folgend. Den Operatiounsdepartementingenieur ass direkt an der Ausrollung vum Projet involvéiert: hien ännert d'Versioune vu Packagen an Hiera am Repository wou d'Applikatiounsrezept gespäichert ass, duerno Puppet ausléist probéiere, hëlt den neie Package aus dem Repository, an déi nei Versioun vun der Applikatioun ass prett fir ze benotzen.

.NET Core op Linux, DevOps op Päerd

Alles ass einfach a Wierder, awer wat geschitt am Build Agent selwer?

Verpakung DLL RPM

Kritt Projet Quellen a bauen Aufgab vun TFS. Bauen Agent fänkt de Projet selwer aus Quellen ze bauen. De zesummegebaute Projet ass verfügbar als Set DLL Dateien, déi an engem Zip-Archiv verpackt sinn fir d'Laascht op de Dateiesystem ze reduzéieren.

Den ZIP Archiv gëtt ewechgehäit an de RPM Package Build Verzeechnes. Als nächst initialiséiert de Bash Skript d'Ëmfeldvariablen, fënnt d'Build Versioun, d'Projet Versioun, de Wee zum Build Verzeechnes, a leeft RPM-build. Wann de Bau fäerdeg ass, gëtt de Package publizéiert lokal Repository, déi um Build Agent läit.

Als nächst, vum Build Agent op de Server am RPM Repository JSON Ufro gëtt geschéckt uginn den Numm vun der Versioun a bauen. Webhook, iwwer deen ech virdru geschwat hunn, luet dëse ganz Package vum lokalen Repository um Build Agent erof a mécht déi nei Versammlung fir d'Installatioun verfügbar.

.NET Core op Linux, DevOps op Päerd

Firwat dëse spezielle Package Liwwerung Schema an de RPM Repository? Firwat kann ech net direkt de versammelt Pak an de Repository schécken? De Fakt ass datt dëst eng Bedingung ass fir d'Sécherheet ze garantéieren. Dëst Szenario limitéiert d'Méiglechkeet vun onerlaabten Leit déi RPM Packagen op e Server eropluede deen fir all Linux Maschinnen zougänglech ass.

Datebank Versioun

Bei enger Konsultatioun mam Entwécklungsteam huet et sech erausgestallt datt d'Kärelen méi no bei MS SQL waren, awer an de meeschte net-Windows-Projeten hu mir PostgreSQL scho mat all hirer Kraaft benotzt. Well mir scho beschloss hunn alles bezuelt opzeginn, hu mir och ugefaang PostgreSQL hei ze benotzen.

.NET Core op Linux, DevOps op Päerd

An dësem Deel wëll ech Iech soen wéi mir d'Datebank Versioun Versioun hunn a wéi mir tëscht Flyway an Entity Framework Core gewielt hunn. Loosst eis hir Virdeeler an Nodeeler kucken.

Минусы

Flyway geet nëmmen ee Wee, mir mir kënnen net zréckrollen - dëst ass e wesentlechen Nodeel. Dir kënnt et mat Entity Framework Core op aner Manéier vergläichen - wat d'Entwécklerkomfort ugeet. Dir erënnert Iech drun datt mir dëst an der Spëtzt gesat hunn, an den Haaptcritère war näischt fir Windows Entwécklung z'änneren.

Fir Flyway eis eng Zort Wrapper war gebrauchtfir datt d'Jongen net schreiwen SQL Ufroen. Si si vill méi no bei der Operatioun an OOP Begrëffer. Mir hunn Instruktioune geschriwwen fir mat Datebankobjekter ze schaffen, eng SQL Ufro generéiert an se ausgefouert. Déi nei Versioun vun der Datebank ass prett, getest - alles ass gutt, alles funktionnéiert.

Entity Framework Core huet e Minus - ënner schwéiere Lasten et baut suboptimal SQL Ufroen, an de Réckzuch an der Datebank ka bedeitend sinn. Awer well mir keen High-load-Service hunn, berechene mir d'Laascht net an Honnerte vu RPS, mir hunn dës Risiken ugeholl an de Problem un eis zukünfteg delegéiert.

Plus

Entity Framework Core funktionnéiert aus der Këscht an ass einfach ze entwéckelen, an Flyway Einfach integréiert an bestehend CI. Awer mir maachen et bequem fir Entwéckler :)

Roll-up Prozedur

Puppet gesäit datt eng Ännerung an der Package Versioun kënnt, och déi, déi fir Migratioun verantwortlech ass. Als éischt installéiert et e Package deen Migratiounsskripter an Datebank-verbonne Funktionalitéit enthält. Duerno gëtt d'Applikatioun, déi mat der Datebank funktionnéiert, nei gestart. Als nächst kënnt d'Installatioun vun de verbleiwen Komponenten. D'Uerdnung an där Packagen installéiert sinn an Uwendungen lancéiert ginn ass am Puppet Manifest beschriwwen.

Uwendungen benotzen sensibel Donnéeën, wéi Tokens, Datebank Passwierder, all dat gëtt an d'Konfiguratioun vum Puppet Master gezunn, wou se a verschlësselte Form gespäichert ginn.

TFS Problemer

Nodeems mir décidéiert hunn a gemierkt hunn datt alles wierklech fir eis fonctionnéiert, hunn ech beschloss ze kucken wat mat den Assembléeën am TFS als Ganzt lass ass fir d'Win Entwécklung Departement op aner Projeten - ob mir séier bauen / fräiginn oder net, an entdeckt bedeitend Problemer mat Geschwindegkeet.

Ee vun den Haaptprojeten dauert 12-15 Minutten fir ze montéieren - dat ass eng laang Zäit, Dir kënnt net sou liewen. Eng séier Analyse huet e schreckleche Réckzuch am I / O gewisen, an dëst war op Arrays.

Nodeems ech et Komponent fir Komponent analyséiert hunn, hunn ech dräi Foci identifizéiert. Éischten - "Kaspersky Antivirus", déi Quellen op all Windows Build Agenten scannt. Zweeten - Windows Indexer. Et war net behënnert, an alles gouf an Echtzäit op de Build Agenten während dem Détachementprozess indexéiert.

Drëtten - Npm installéieren. Et huet sech erausgestallt datt mir an de meeschte Pipelines dëse genee Szenario benotzt hunn. Firwat ass hien schlecht? D'Npm Installatiounsprozedur gëtt ausgeführt wann den Ofhängegkeetsbaum geformt gëtt package-lock.json, wou d'Versioune vu Packagen déi benotzt gi fir de Projet ze bauen opgeholl ginn. Den Nodeel ass datt d'Npm Installatioun all Kéier déi lescht Versioune vu Packagen aus dem Internet zitt, an dëst hëlt vill Zäit am Fall vun engem grousse Projet.

Entwéckler experimentéieren heiansdo op enger lokaler Maschinn fir ze testen wéi e bestëmmten Deel oder e ganze Projet funktionnéiert. Heiansdo huet sech erausgestallt datt alles lokal cool war, awer si hunn et zesummegesat, erausgeréckelt an näischt huet geschafft. Mir fänken un erauszefannen wat de Problem ass - jo, verschidde Versioune vu Packagen mat Ofhängegkeeten.

Decisioun

  • Quellen an AV Ausnahmen.
  • Indexéierung auszeschalten.
  • Géi op npm ci.

D'Virdeeler vun npm ci sinn, datt mir Mir sammelen der Ofhängegkeet Bam eemol, a mir kréien d'Méiglechkeet den Entwéckler ze bidden aktuell Lëscht vu Packagen, mat deem hien lokal sou vill experimentéiere kann, wéi hie wëll. Dëst spuert Zäit Entwéckler déi Code schreiwen.

Configuratioun

Elo e bëssen iwwer d'Repository Konfiguratioun. Historesch benotze mir Nexus fir Gestioun vun Repositories, dorënner Intern REPO. Dësen internen Repository enthält all d'Komponenten déi mir fir intern Zwecker benotzen, zum Beispill, selbstgeschriwwe Iwwerwaachung.

.NET Core op Linux, DevOps op Päerd

Mir benotzen och NuGet, well et besser Caching am Verglach mat anere Package Manager huet.

Resultat

Nodeems mir d'Build Agents optimiséiert hunn, gouf déi duerchschnëttlech Bauzäit vun 12 Minutten op 7 reduzéiert.

Wa mir all d'Maschinnen zielen, déi mir fir Windows benotzt hätten, awer an dësem Projet op Linux gewiesselt sinn, hu mir ongeféier $ 10 gespuert An dat ass just op Lizenzen, a méi wa mir den Inhalt berücksichtegen.

Pläng

Fir den nächste Véierel hu mir geplangt un der Optimisatioun vun der Code Liwwerung ze schaffen.

Wiesselt op e Prebuild Docker Bild. TFS ass eng cool Saach mat ville Plugins, déi Iech erlaben an Pipeline z'integréieren, inklusiv Trigger-baséiert Assemblée vun, soen, engem Docker Bild. Mir wëllen dësen Ausléiser fir dee selwechte maachen package-lock.json. Wann d'Zesummesetzung vun de Komponente benotzt fir de Projet ze bauen iergendwéi ännert, bauen mir en neit Docker-Bild. Et gëtt spéider benotzt fir de Container mat der versammelter Applikatioun z'installéieren. Dëst ass elo net de Fall, awer mir plangen op eng Mikroservicearchitektur zu Kubernetes ze wiesselen, déi aktiv an eiser Firma entwéckelt a fir eng laang Zäit Produktiounsléisungen servéiert.

Summary

Ech encouragéieren jiddereen Windows ewech ze geheien, mee et ass net well ech weess net wéi et ze kachen. De Grond ass datt déi meescht Opensource Léisunge sinn Linux Stack. bass du ok spueren op Ressourcen. Menger Meenung no gehéiert d'Zukunft zu Open Source Léisungen op Linux mat enger mächteger Gemeinschaft.

Speaker Profil vum Alexander Sinchinov op GitHub.

DevOps Conf ass eng Konferenz iwwer d'Integratioun vun Entwécklung, Testen an Operatioun Prozesser fir Fachleit duerch professionell. Dofir ass de Projet iwwer deen den Alexander geschwat huet? ëmgesat a funktionéiert, an den Dag vun der Leeschtung goufen et zwee erfollegräich Verëffentlechungen. Op DevOps Conf bei RIT++ De 27. an 28. Mee ginn et nach méi ähnlech Fäll vu Praktiker. Dir kënnt nach an déi lescht Kutsch sprangen an e Rapport ofginn oder huelt Är Zäit ze buchen Ticket. Trefft eis zu Skolkovo!

Source: will.com

Setzt e Commentaire