Linux પર .NET કોર, ઘોડેસવાર પર DevOps

અમે શક્ય તેટલું શ્રેષ્ઠ DevOps વિકસાવ્યું. અમારામાંથી 8 હતા, અને વાસ્યા વિન્ડોઝમાં સૌથી શાનદાર હતા. અચાનક વાસ્યા ચાલ્યા ગયા, અને મારી પાસે એક નવો પ્રોજેક્ટ શરૂ કરવાનું કાર્ય હતું જે વિન્ડોઝ ડેવલપમેન્ટ દ્વારા પૂરું પાડવામાં આવ્યું હતું. જ્યારે મેં સમગ્ર વિન્ડોઝ ડેવલપમેન્ટ સ્ટેકને ટેબલ પર ફેંકી દીધું, ત્યારે મને સમજાયું કે પરિસ્થિતિ પીડાદાયક હતી...

આ રીતે વાર્તા શરૂ થાય છે એલેક્ઝાન્ડ્રા સિંચિનોવા પર DevOpsConf. જ્યારે અગ્રણી વિન્ડોઝ નિષ્ણાતે કંપની છોડી દીધી, ત્યારે એલેક્ઝાંડરે વિચાર્યું કે હવે શું કરવું. લિનક્સ પર સ્વિચ કરો, અલબત્ત! એલેક્ઝાન્ડર તમને જણાવશે કે તેણે 100 અંતિમ વપરાશકર્તાઓ માટે પૂર્ણ થયેલ પ્રોજેક્ટના ઉદાહરણનો ઉપયોગ કરીને વિન્ડોઝ ડેવલપમેન્ટનો એક દાખલો કેવી રીતે બનાવ્યો અને લિનક્સ પર ટ્રાન્સફર કર્યો.

Linux પર .NET કોર, ઘોડેસવાર પર DevOps

TFS, Puppet, Linux .NET કોરનો ઉપયોગ કરીને પ્રોજેક્ટને સરળતાથી અને વિના પ્રયાસે RPM પર કેવી રીતે પહોંચાડવો? જો ડેવલપમેન્ટ ટીમ પ્રથમ વખત પોસ્ટગ્રેસ અને ફ્લાયવે શબ્દો સાંભળે અને સમયમર્યાદા આવતીકાલે પરસેવો હોય તો પ્રોજેક્ટ ડેટાબેઝના સંસ્કરણને કેવી રીતે સમર્થન આપવું? ડોકર સાથે કેવી રીતે સંકલિત કરવું? પપેટ અને લિનક્સની તરફેણમાં .NET વિકાસકર્તાઓને વિન્ડોઝ અને સ્મૂધીઝને છોડી દેવા માટે કેવી રીતે પ્રેરિત કરવું? જો ઉત્પાદનમાં વિન્ડોઝને જાળવવા માટે ન તો તાકાત, ન ઇચ્છા કે સંસાધનો ન હોય તો વૈચારિક સંઘર્ષો કેવી રીતે ઉકેલવા? આ વિશે, તેમજ વેબ ડિપ્લોય, ટેસ્ટિંગ, CI વિશે, હાલના પ્રોજેક્ટ્સમાં TFS નો ઉપયોગ કરવાની પ્રેક્ટિસ વિશે, અને અલબત્ત, એલેક્ઝાંડરના અહેવાલની ટ્રાન્સક્રિપ્ટમાં, તૂટેલી ક્રેચ અને કાર્યકારી ઉકેલો વિશે.


તેથી, વાસ્યા ચાલ્યા ગયા, કાર્ય મારા પર છે, વિકાસકર્તાઓ પિચફોર્ક્સ સાથે અધીરાઈથી રાહ જોઈ રહ્યા છે. જ્યારે મને આખરે સમજાયું કે વાસ્યા પાછા આવી શકશે નહીં, ત્યારે હું વ્યવસાયમાં ઉતર્યો. શરૂઆતમાં, મેં અમારા કાફલામાં Win VM ની ટકાવારીનું મૂલ્યાંકન કર્યું. સ્કોર વિન્ડોઝની તરફેણમાં ન હતો.

Linux પર .NET કોર, ઘોડેસવાર પર DevOps

અમે સક્રિયપણે DevOps વિકસાવી રહ્યા હોવાથી, મને સમજાયું કે નવી એપ્લિકેશન પહોંચાડવાના અભિગમમાં કંઈક બદલવાની જરૂર છે. એક જ ઉકેલ હતો - જો શક્ય હોય તો, બધું Linux માં સ્થાનાંતરિત કરો. Google એ મને મદદ કરી - તે સમયે .Net પહેલેથી જ Linux પર પોર્ટ કરવામાં આવ્યું હતું, અને મને સમજાયું કે આ ઉકેલ છે!

શા માટે Linux સાથે જોડાણમાં .NET કોર?

આના ઘણા કારણો હતા. "પૈસા ચૂકવો" અને "ચુકવણી ન કરો" વચ્ચે, બહુમતી બીજાને પસંદ કરશે - મારી જેમ. MSDB માટે લાયસન્સની કિંમત લગભગ $1 છે; Windows વર્ચ્યુઅલ મશીનોના કાફલાને જાળવવા માટે સેંકડો ડોલરનો ખર્ચ થાય છે. મોટી કંપની માટે આ એક મોટો ખર્ચ છે. એ કારણે બચત - પ્રથમ કારણ. સૌથી મહત્વપૂર્ણ નથી, પરંતુ એક મહત્વપૂર્ણ છે.

વિન્ડોઝ વર્ચ્યુઅલ મશીનો તેમના લિનક્સ ભાઈઓ કરતાં વધુ સંસાધનો લે છે - તેઓ ભારે છે. મોટી કંપનીના સ્કેલને જોતાં, અમે Linux પસંદ કર્યું.

સિસ્ટમ ફક્ત હાલના CI માં સંકલિત છે. અમે અમારી જાતને પ્રગતિશીલ DevOps માનીએ છીએ, અમે Bamboo, Jenkins અને GitLab CI નો ઉપયોગ કરીએ છીએ, તેથી અમારું મોટા ભાગનું કામ Linux પર ચાલે છે.

છેલ્લું કારણ છે અનુકૂળ સાથ. અમારે "એસ્કોર્ટ્સ" માટે પ્રવેશ માટેના અવરોધને ઘટાડવાની જરૂર હતી - જે લોકો તકનીકી ભાગને સમજે છે, અવિરત સેવાની ખાતરી કરે છે અને બીજી લાઇનથી સેવાઓ જાળવી રાખે છે. તેઓ પહેલાથી જ Linux સ્ટેકથી પરિચિત હતા, તેથી તેમના માટે Windows પ્લેટફોર્મ માટે સોફ્ટવેરની સમાન કાર્યક્ષમતાને સમજવા માટે વધારાના સંસાધનો ખર્ચવા કરતાં નવા ઉત્પાદનને સમજવું, સમર્થન કરવું અને જાળવવું વધુ સરળ છે.

જરૂરીયાતો

પ્રથમ અને અગ્રણી - વિકાસકર્તાઓ માટે નવા ઉકેલની સુવિધા. તે બધા ફેરફાર માટે તૈયાર ન હતા, ખાસ કરીને Linux શબ્દ બોલ્યા પછી. વિકાસકર્તાઓ તેમના મનપસંદ વિઝ્યુઅલ સ્ટુડિયો, એસેમ્બલી અને સ્મૂધી માટે ઓટોટેસ્ટ સાથે TFS ઇચ્છે છે. ઉત્પાદન માટે ડિલિવરી કેવી રીતે થાય છે તે તેમના માટે મહત્વનું નથી. તેથી, અમે સામાન્ય પ્રક્રિયામાં ફેરફાર ન કરવાનો અને Windows વિકાસ માટે બધું યથાવત રાખવાનું નક્કી કર્યું.

નવા પ્રોજેક્ટની જરૂર છે હાલના CI માં એકીકૃત કરો. રેલ પહેલેથી જ ત્યાં હતી અને તમામ કામ કન્ફિગરેશન મેનેજમેન્ટ સિસ્ટમ, સ્વીકૃત ડિલિવરી ધોરણો અને મોનિટરિંગ સિસ્ટમ્સના પરિમાણોને ધ્યાનમાં લઈને કરવાનું હતું.

આધાર અને કામગીરીમાં સરળતા, વિવિધ વિભાગો અને સપોર્ટ વિભાગના તમામ નવા સહભાગીઓ માટે લઘુત્તમ પ્રવેશ થ્રેશોલ્ડ માટેની શરત તરીકે.

અંતિમ તારીખ - ગઈકાલે.

વિન ડેવલપમેન્ટ ગ્રુપ

ત્યારે વિન્ડોઝ ટીમ શેની સાથે કામ કરી રહી હતી?

Linux પર .NET કોર, ઘોડેસવાર પર DevOps

હવે હું વિશ્વાસપૂર્વક કહી શકું છું આઇડેન્ટિટી સર્વર4 સમાન ક્ષમતાઓ સાથે ADFS માટે એક સરસ મફત વિકલ્પ છે, અથવા શું એન્ટિટી ફ્રેમવર્ક કોર - ડેવલપર માટે સ્વર્ગ, જ્યાં તમારે SQL સ્ક્રિપ્ટ્સ લખવાની પરેશાન કરવાની જરૂર નથી, પરંતુ OOP શરતોમાં ડેટાબેઝમાં ક્વેરીનું વર્ણન કરો. પરંતુ તે પછી, એક્શન પ્લાનની ચર્ચા દરમિયાન, મેં આ સ્ટેકને એવું જોયું કે જાણે તે સુમેરિયન ક્યુનિફોર્મ હોય, માત્ર PostgreSQL અને Git ને ઓળખતા.

તે સમયે અમે સક્રિયપણે ઉપયોગ કરતા હતા પપેટ રૂપરેખાંકન વ્યવસ્થાપન સિસ્ટમ તરીકે. અમારા મોટાભાગના પ્રોજેક્ટ્સમાં અમે તેનો ઉપયોગ કર્યો છે ગિટલેબ સી.આઈ., સ્થિતિસ્થાપક, સંતુલિત ઉચ્ચ-લોડ સેવાઓનો ઉપયોગ કરીને HAProxy સાથે દરેક વસ્તુનું નિરીક્ષણ કર્યું ઝબ્બીક્સ, અસ્થિબંધન ગ્રાફના и પ્રોમિથિયસ, જાગર, અને આ બધું લોખંડના ટુકડા પર ફરતું હતું HPESXi પર વીએમવેર. દરેક વ્યક્તિને તે જાણે છે - શૈલીની ક્લાસિક.

Linux પર .NET કોર, ઘોડેસવાર પર DevOps

ચાલો જોઈએ અને સમજવાનો પ્રયત્ન કરીએ કે આપણે આ બધી હસ્તક્ષેપ શરૂ કરીએ તે પહેલાં શું થયું.

શું થયું

TFS એ એકદમ શક્તિશાળી સિસ્ટમ છે જે ડેવલપર પાસેથી અંતિમ પ્રોડક્શન મશીન સુધી માત્ર કોડ જ પહોંચાડતી નથી, પરંતુ વિવિધ સેવાઓ સાથે ખૂબ જ લવચીક એકીકરણ માટેનો સેટ પણ ધરાવે છે - ક્રોસ-પ્લેટફોર્મ સ્તરે CI પ્રદાન કરવા માટે.

Linux પર .NET કોર, ઘોડેસવાર પર DevOps
પહેલાં, આ નક્કર બારીઓ હતી. TFS એ ઘણા બિલ્ડ એજન્ટોનો ઉપયોગ કર્યો, જેનો ઉપયોગ ઘણા પ્રોજેક્ટ્સને એસેમ્બલ કરવા માટે થતો હતો. દરેક એજન્ટ પાસે કાર્યોને સમાંતર બનાવવા અને પ્રક્રિયાને ઑપ્ટિમાઇઝ કરવા માટે 3-4 કામદારો હોય છે. પછી, પ્રકાશન યોજનાઓ અનુસાર, TFS એ તાજી બેક કરેલી બિલ્ડને Windows એપ્લિકેશન સર્વર પર પહોંચાડી.

આપણે શું હાંસલ કરવા માગતા હતા?

અમે ડિલિવરી અને વિકાસ માટે TFS નો ઉપયોગ કરીએ છીએ, અને Linux એપ્લિકેશન સર્વર પર એપ્લિકેશન ચલાવીએ છીએ, અને તેમની વચ્ચે એક પ્રકારનો જાદુ છે. આ મેજિક બોક્સ અને આગળ કામનું મીઠું છે. હું તેને અલગ કરું તે પહેલાં, હું એક પગલું બાજુએ લઈ જઈશ અને એપ્લિકેશન વિશે થોડાક શબ્દો કહીશ.

આ પ્રોજેક્ટ

એપ્લિકેશન પ્રીપેડ કાર્ડને હેન્ડલ કરવા માટે કાર્યક્ષમતા પ્રદાન કરે છે.

Linux પર .NET કોર, ઘોડેસવાર પર DevOps

ક્લાઈન્ટ

ત્યાં બે પ્રકારના વપરાશકર્તાઓ હતા. પ્રથમ SSL SHA-2 પ્રમાણપત્રનો ઉપયોગ કરીને લૉગ ઇન કરીને ઍક્સેસ મેળવ્યો. યુ બીજા લૉગિન અને પાસવર્ડનો ઉપયોગ કરીને ઍક્સેસ હતી.

HAPROXY

પછી ક્લાયંટની વિનંતી HAProxy પર ગઈ, જેણે નીચેની સમસ્યાઓ હલ કરી:

  • પ્રાથમિક અધિકૃતતા;
  • SSL સમાપ્તિ;
  • HTTP વિનંતીઓ ટ્યુનિંગ;
  • પ્રસારણ વિનંતીઓ.

ક્લાયન્ટ પ્રમાણપત્ર સાંકળ સાથે ચકાસવામાં આવ્યું હતું. અમે - સત્તા અને અમે આ પરવડી શકીએ છીએ, કારણ કે અમે પોતે સેવા ગ્રાહકોને પ્રમાણપત્રો આપીએ છીએ.

ત્રીજા મુદ્દા પર ધ્યાન આપો, અમે થોડી વાર પછી તેના પર પાછા આવીશું.

પાશ્વભાગ

તેઓએ Linux પર બેકએન્ડ બનાવવાની યોજના બનાવી. બેકએન્ડ ડેટાબેઝ સાથે ક્રિયાપ્રતિક્રિયા કરે છે, વિશેષાધિકારોની આવશ્યક સૂચિ લોડ કરે છે અને પછી, અધિકૃત વપરાશકર્તા પાસે કયા વિશેષાધિકારો છે તેના આધારે, નાણાકીય દસ્તાવેજો પર હસ્તાક્ષર કરવાની ઍક્સેસ પ્રદાન કરે છે અને તેને અમલ માટે મોકલે છે અથવા કોઈ પ્રકારનો રિપોર્ટ જનરેટ કરે છે.

HAProxy સાથે બચત

દરેક ક્લાયન્ટે નેવિગેટ કરેલા બે સંદર્ભો ઉપરાંત, એક ઓળખ સંદર્ભ પણ હતો. આઇડેન્ટિટી સર્વર4 ફક્ત તમને લૉગ ઇન કરવાની મંજૂરી આપે છે, આ એક મફત અને શક્તિશાળી એનાલોગ છે ADFS - સક્રિય ડિરેક્ટરી ફેડરેશન સેવાઓ.

ઓળખ વિનંતિ પર ઘણા પગલાઓમાં પ્રક્રિયા કરવામાં આવી હતી. પ્રથમ પગલું - ગ્રાહક બેકએન્ડમાં પ્રવેશ કર્યો, જેણે આ સર્વર સાથે વાતચીત કરી અને ક્લાયન્ટ માટે ટોકનની હાજરી તપાસી. જો તે મળ્યું ન હતું, તો વિનંતી તે સંદર્ભમાં પાછી આપવામાં આવી હતી જ્યાંથી તે આવી હતી, પરંતુ રીડાયરેક્ટ સાથે, અને રીડાયરેક્ટ સાથે તે ઓળખ પર ગઈ હતી.

બીજું પગલું - વિનંતી પ્રાપ્ત થઈ IdentityServer માં અધિકૃતતા પૃષ્ઠ પર, જ્યાં ક્લાયંટ નોંધાયેલ છે, અને તે લાંબા સમયથી રાહ જોવાતું ટોકન IdentityServer ડેટાબેઝમાં દેખાય છે.

ત્રીજું પગલું - ક્લાયન્ટને પાછું રીડાયરેક્ટ કરવામાં આવ્યું હતું જે સંદર્ભમાંથી તે આવ્યો હતો.

Linux પર .NET કોર, ઘોડેસવાર પર DevOps

IdentityServer4 પાસે એક વિશેષતા છે: તે HTTP દ્વારા રીટર્ન વિનંતીનો પ્રતિસાદ આપે છે. સર્વર સેટઅપ કરવા માટે અમે ગમે તેટલો સંઘર્ષ કર્યો હોય, પછી ભલેને અમે દસ્તાવેજોથી અમારી જાતને કેટલું પ્રબુદ્ધ કર્યું હોય, દરેક વખતે અમને HTTPS દ્વારા આવતા URL સાથે પ્રારંભિક ક્લાયન્ટ વિનંતી મળી, અને IdentityServer એ સમાન સંદર્ભ પરત કર્યો, પરંતુ HTTP સાથે. અમે ચોંકી ગયા! અને અમે આ બધું ઓળખ સંદર્ભ દ્વારા HAProxy માં સ્થાનાંતરિત કર્યું, અને હેડરમાં અમારે HTTP પ્રોટોકોલને HTTPS માં સંશોધિત કરવાનો હતો.

સુધારો શું છે અને તમે ક્યાં બચાવ્યા?

અમે વપરાશકર્તાઓ, સંસાધનોના જૂથને અધિકૃત કરવા માટે મફત ઉકેલનો ઉપયોગ કરીને નાણાં બચાવ્યા, કારણ કે અમે IdentityServer4 ને અલગ સેગમેન્ટમાં અલગ નોડ તરીકે મૂક્યું નથી, પરંતુ તેનો ઉપયોગ એ જ સર્વર પર બેકએન્ડ સાથે કર્યો છે જ્યાં એપ્લિકેશનનો બેકએન્ડ ચાલે છે. .

તે કેવી રીતે કામ કરવું જોઈએ

તેથી, જેમ મેં વચન આપ્યું હતું - મેજિક બોક્સ. અમે પહેલેથી જ સમજીએ છીએ કે અમે Linux તરફ આગળ વધવાની ખાતરી આપીએ છીએ. ચાલો ચોક્કસ કાર્યો ઘડીએ કે જેને ઉકેલની જરૂર હોય.

Linux પર .NET કોર, ઘોડેસવાર પર DevOps

કઠપૂતળી પ્રગટ થાય છે. સેવા અને એપ્લિકેશન રૂપરેખાંકન પહોંચાડવા અને તેનું સંચાલન કરવા માટે, સરસ વાનગીઓ લખવાની હતી. પેન્સિલનો રોલ છટાદાર રીતે બતાવે છે કે તે કેટલી ઝડપથી અને અસરકારક રીતે કરવામાં આવ્યું હતું.

વિતરણની પદ્ધતિ. ધોરણ RPM છે. દરેક વ્યક્તિ સમજે છે કે લિનક્સમાં તમે તેના વિના કરી શકતા નથી, પરંતુ પ્રોજેક્ટ પોતે, એસેમ્બલી પછી, એક્ઝિક્યુટેબલ DLL ફાઇલોનો સમૂહ હતો. તેમાંના લગભગ 150 હતા, પ્રોજેક્ટ તદ્દન મુશ્કેલ હતો. એકમાત્ર સુમેળભર્યો ઉકેલ એ છે કે આ દ્વિસંગીને RPM માં પૅકેજ કરો અને તેમાંથી એપ્લિકેશનનો ઉપયોગ કરો.

વર્ઝનીંગ. અમારે ઘણી વાર રીલિઝ કરવું પડતું હતું, અને પેકેજનું નામ કેવી રીતે બનાવવું તે અમારે નક્કી કરવાનું હતું. આ TFS સાથે એકીકરણના સ્તરનો પ્રશ્ન છે. અમારી પાસે Linux પર બિલ્ડ એજન્ટ હતો. જ્યારે TFS હેન્ડલર - વર્કર - બિલ્ડ એજન્ટને કાર્ય મોકલે છે, ત્યારે તે તેને ચલોનો સમૂહ પણ પસાર કરે છે જે હેન્ડલર પ્રક્રિયાના વાતાવરણમાં સમાપ્ત થાય છે. આ પર્યાવરણ ચલોમાં બિલ્ડ નામ, સંસ્કરણનું નામ અને અન્ય ચલો છે. "RPM પેકેજ બનાવવું" વિભાગમાં આ વિશે વધુ વાંચો.

TFS સેટ કરી રહ્યું છે પાઈપલાઈન ગોઠવવા માટે નીચે આવ્યા હતા. અગાઉ, અમે વિન્ડોઝ એજન્ટ્સ પર તમામ વિન્ડોઝ પ્રોજેક્ટ્સ એકત્રિત કર્યા હતા, પરંતુ હવે એક Linux એજન્ટ દેખાય છે - એક બિલ્ડ એજન્ટ, જેને બિલ્ડ જૂથમાં સમાવિષ્ટ કરવાની જરૂર છે, જે કેટલીક આર્ટિફેક્ટ્સથી સમૃદ્ધ છે, અને જણાવ્યું છે કે આ બિલ્ડ એજન્ટ પર કયા પ્રકારના પ્રોજેક્ટ્સ બનાવવામાં આવશે. , અને કોઈક રીતે પાઇપલાઇનમાં ફેરફાર કરો.

આઇડેન્ટિટી સર્વર. ADFS એ અમારી રીત નથી, અમે ઓપન સોર્સ માટે જઈ રહ્યા છીએ.

ચાલો ઘટકોમાંથી પસાર થઈએ.

મેજિક બોક્સ

ચાર ભાગો સમાવે છે.

Linux પર .NET કોર, ઘોડેસવાર પર DevOps

Linux બિલ્ડ એજન્ટ. Linux, કારણ કે અમે તેના માટે બનાવીએ છીએ - તે તાર્કિક છે. આ ભાગ ત્રણ પગલામાં કરવામાં આવ્યો હતો.

  • કામદારોને ગોઠવો અને એકલા નહીં, કારણ કે પ્રોજેક્ટ પર વિતરિત કાર્ય અપેક્ષિત હતું.
  • .NET કોર 1.x ઇન્સ્ટોલ કરો. શા માટે 1.x જ્યારે 2.0 સ્ટાન્ડર્ડ રિપોઝીટરીમાં પહેલેથી જ ઉપલબ્ધ છે? કારણ કે જ્યારે અમે ડેવલપમેન્ટ શરૂ કર્યું ત્યારે સ્ટેબલ વર્ઝન 1.09 હતું અને તેના આધારે પ્રોજેક્ટ બનાવવાનું નક્કી કરવામાં આવ્યું હતું.
  • Git 2.x.

RPM-રિપોઝીટરી. RPM પેકેજોને ક્યાંક સંગ્રહિત કરવાની જરૂર છે. એવું માનવામાં આવતું હતું કે અમે એ જ કોર્પોરેટ RPM રીપોઝીટરીનો ઉપયોગ કરીશું જે બધા Linux હોસ્ટ્સ માટે ઉપલબ્ધ છે. તે તેઓએ કર્યું. રીપોઝીટરી સર્વર ગોઠવેલ છે વેબહુક જે નિર્દિષ્ટ સ્થાન પરથી જરૂરી RPM પેકેજ ડાઉનલોડ કરે છે. પેકેજ વર્ઝનની જાણ બિલ્ડ એજન્ટ દ્વારા વેબહૂકને કરવામાં આવી હતી.

ગિટલેબ. ધ્યાન આપો! અહીં ગિટલેબનો ઉપયોગ વિકાસકર્તાઓ દ્વારા નહીં, પરંતુ ઓપરેશન્સ વિભાગ દ્વારા એપ્લિકેશન સંસ્કરણો, પેકેજ સંસ્કરણોને નિયંત્રિત કરવા, તમામ Linux મશીનોની સ્થિતિનું નિરીક્ષણ કરવા માટે થાય છે, અને તે રેસીપી સંગ્રહિત કરે છે - તમામ પપેટ મેનિફેસ્ટ.

પપેટ - તમામ વિવાદાસ્પદ મુદ્દાઓનું નિરાકરણ લાવે છે અને અમને ગિટલેબમાંથી જોઈએ છે તે બરાબર ગોઠવણી કરે છે.

અમે ડાઇવ કરવાનું શરૂ કરીએ છીએ. RPM પર DLL ડિલિવરી કેવી રીતે કાર્ય કરે છે?

ડીડીએલને આરપીએમ સુધી પહોંચાડો

ચાલો કહીએ કે અમારી પાસે .NET ડેવલપમેન્ટ રોક સ્ટાર છે. તે વિઝ્યુઅલ સ્ટુડિયોનો ઉપયોગ કરે છે અને પ્રકાશન શાખા બનાવે છે. તે પછી, તે તેને Git પર અપલોડ કરે છે, અને Git અહીં એક TFS એન્ટિટી છે, એટલે કે, તે એપ્લિકેશન રિપોઝીટરી છે જેની સાથે ડેવલપર કામ કરે છે.

Linux પર .NET કોર, ઘોડેસવાર પર DevOps

જે પછી TFS જુએ છે કે એક નવી કમિટ આવી છે. કઈ એપ? TFS સેટિંગ્સમાં એક લેબલ છે જે દર્શાવે છે કે ચોક્કસ બિલ્ડ એજન્ટ પાસે કયા સંસાધનો છે. આ કિસ્સામાં, તે જુએ છે કે અમે .NET કોર પ્રોજેક્ટ બનાવી રહ્યા છીએ અને પૂલમાંથી Linux બિલ્ડ એજન્ટ પસંદ કરે છે.

બિલ્ડ એજન્ટ સ્ત્રોતો મેળવે છે અને જરૂરી ડાઉનલોડ કરે છે નિર્ભરતા .NET રીપોઝીટરી, npm, વગેરેમાંથી. અને એપ્લિકેશન પોતે અને અનુગામી પેકેજીંગ બનાવ્યા પછી, RPM પેકેજને RPM રીપોઝીટરીમાં મોકલે છે.

બીજી બાજુ, નીચેના થાય છે. ઓપરેશન્સ ડિપાર્ટમેન્ટ એન્જિનિયર પ્રોજેક્ટના રોલઆઉટમાં સીધો જ સામેલ છે: તે પેકેજની આવૃત્તિઓમાં ફેરફાર કરે છે હીરા રીપોઝીટરીમાં જ્યાં એપ્લિકેશન રેસીપી સંગ્રહિત છે, જે પછી પપેટ ટ્રિગર થાય છે Yum, રીપોઝીટરીમાંથી નવું પેકેજ મેળવે છે, અને એપ્લિકેશનનું નવું સંસ્કરણ ઉપયોગ માટે તૈયાર છે.

Linux પર .NET કોર, ઘોડેસવાર પર DevOps

શબ્દોમાં બધું સરળ છે, પરંતુ બિલ્ડ એજન્ટની અંદર શું થાય છે?

પેકેજિંગ DLL RPM

TFS તરફથી પ્રોજેક્ટ સ્ત્રોતો અને બિલ્ડ ટાસ્ક પ્રાપ્ત કર્યા. બિલ્ડ એજન્ટ સ્ત્રોતોમાંથી જ પ્રોજેક્ટ બનાવવાનું શરૂ કરે છે. એસેમ્બલ પ્રોજેક્ટ સેટ તરીકે ઉપલબ્ધ છે DLL ફાઇલો, જે ફાઇલ સિસ્ટમ પરનો ભાર ઘટાડવા માટે ઝિપ આર્કાઇવમાં પેક કરવામાં આવે છે.

ઝીપ આર્કાઇવ ફેંકી દેવામાં આવે છે RPM પેકેજ બિલ્ડ ડિરેક્ટરીમાં. આગળ, Bash સ્ક્રિપ્ટ પર્યાવરણ ચલોને આરંભ કરે છે, બિલ્ડ વર્ઝન, પ્રોજેક્ટ વર્ઝન, બિલ્ડ ડાયરેક્ટરીનો પાથ શોધે છે અને RPM-build ચલાવે છે. એકવાર બિલ્ડ પૂર્ણ થઈ જાય, પેકેજને પ્રકાશિત કરવામાં આવે છે સ્થાનિક ભંડાર, જે બિલ્ડ એજન્ટ પર સ્થિત છે.

આગળ, બિલ્ડ એજન્ટથી RPM રીપોઝીટરીમાં સર્વર સુધી JSON વિનંતી મોકલવામાં આવી છે સંસ્કરણ અને બિલ્ડનું નામ સૂચવે છે. વેબહૂક, જેના વિશે મેં અગાઉ વાત કરી હતી, તે બિલ્ડ એજન્ટ પરના સ્થાનિક રિપોઝીટરીમાંથી આ ખૂબ જ પેકેજ ડાઉનલોડ કરે છે અને નવી એસેમ્બલીને ઇન્સ્ટોલેશન માટે ઉપલબ્ધ બનાવે છે.

Linux પર .NET કોર, ઘોડેસવાર પર DevOps

RPM રિપોઝીટરીમાં આ વિશિષ્ટ પેકેજ વિતરણ યોજના શા માટે? શા માટે હું તરત જ એસેમ્બલ પેકેજ રીપોઝીટરીમાં મોકલી શકતો નથી? હકીકત એ છે કે આ સલામતી સુનિશ્ચિત કરવાની શરત છે. આ દૃશ્ય અનધિકૃત લોકો સર્વર પર RPM પેકેજો અપલોડ કરવાની શક્યતાને મર્યાદિત કરે છે જે તમામ Linux મશીનો માટે સુલભ છે.

ડેટાબેઝ વર્ઝનિંગ

વિકાસ ટીમ સાથેના પરામર્શમાં, તે બહાર આવ્યું કે છોકરાઓ એમએસ એસક્યુએલની નજીક હતા, પરંતુ મોટાભાગના બિન-વિન્ડોઝ પ્રોજેક્ટ્સમાં અમે પહેલાથી જ તેમની તમામ શક્તિ સાથે PostgreSQL નો ઉપયોગ કરી રહ્યા હતા. અમે પહેલેથી જ ચૂકવેલ દરેક વસ્તુને છોડી દેવાનું નક્કી કર્યું હોવાથી, અમે અહીં પણ PostgreSQL નો ઉપયોગ કરવાનું શરૂ કર્યું.

Linux પર .NET કોર, ઘોડેસવાર પર DevOps

આ ભાગમાં હું તમને જણાવવા માંગુ છું કે અમે ડેટાબેઝનું વર્ઝન કેવી રીતે કર્યું અને અમે ફ્લાયવે અને એન્ટિટી ફ્રેમવર્ક કોર વચ્ચે કેવી રીતે પસંદગી કરી. ચાલો તેમના ગુણદોષ જોઈએ.

મિનિસી

ફ્લાયવે ફક્ત એક જ રસ્તે જાય છે, અમે અમે પાછા ફરી શકતા નથી - આ એક નોંધપાત્ર ગેરલાભ છે. તમે તેને એન્ટિટી ફ્રેમવર્ક કોર સાથે અન્ય રીતે સરખાવી શકો છો - ડેવલપરની સુવિધાના સંદર્ભમાં. તમને યાદ છે કે અમે આને મોખરે રાખીએ છીએ, અને મુખ્ય માપદંડ Windows ડેવલપમેન્ટ માટે કંઈપણ બદલવાનો ન હતો.

ફ્લાયવે અમારા માટે અમુક પ્રકારના રેપરની જરૂર હતીજેથી છોકરાઓ લખતા નથી SQL પ્રશ્નો. તેઓ OOP શરતોમાં કામ કરવાની ઘણી નજીક છે. અમે ડેટાબેઝ ઑબ્જેક્ટ્સ સાથે કામ કરવા માટે સૂચનાઓ લખી, એક SQL ક્વેરી જનરેટ કરી અને તેને એક્ઝિક્યુટ કરી. ડેટાબેઝનું નવું સંસ્કરણ તૈયાર છે, ચકાસાયેલ છે - બધું સારું છે, બધું કાર્ય કરે છે.

એન્ટિટી ફ્રેમવર્ક કોરમાં માઈનસ છે - તે ભારે ભાર હેઠળ છે સબઓપ્ટિમલ એસક્યુએલ ક્વેરીઝ બનાવે છે, અને ડેટાબેઝમાં ઘટાડો નોંધપાત્ર હોઈ શકે છે. પરંતુ અમારી પાસે ઉચ્ચ-લોડ સેવા ન હોવાથી, અમે સેંકડો આરપીએસમાં લોડની ગણતરી કરતા નથી, અમે આ જોખમો સ્વીકારી લીધા છે અને ભવિષ્યમાં અમને સમસ્યા સોંપી છે.

Плюсы

એન્ટિટી ફ્રેમવર્ક કોર બોક્સની બહાર કામ કરે છે અને વિકાસ માટે સરળ છે, અને ફ્લાયવે હાલના CI માં સરળતાથી એકીકૃત થાય છે. પરંતુ અમે તેને વિકાસકર્તાઓ માટે અનુકૂળ બનાવીએ છીએ :)

રોલ-અપ પ્રક્રિયા

પપેટ જુએ છે કે પેકેજ સંસ્કરણમાં ફેરફાર આવી રહ્યો છે, જેમાં સ્થળાંતર માટે જવાબદાર છે તે સહિત. પ્રથમ, તે એક પેકેજ ઇન્સ્ટોલ કરે છે જેમાં સ્થાનાંતરણ સ્ક્રિપ્ટો અને ડેટાબેઝ-સંબંધિત કાર્યક્ષમતા હોય છે. આ પછી, એપ્લિકેશન કે જે ડેટાબેઝ સાથે કામ કરે છે તે પુનઃપ્રારંભ થાય છે. આગળ બાકીના ઘટકોની સ્થાપના આવે છે. પપેટ મેનિફેસ્ટમાં જે ક્રમમાં પેકેજો ઇન્સ્ટોલ થાય છે અને એપ્લીકેશન લોન્ચ કરવામાં આવે છે તેનું વર્ણન કરવામાં આવ્યું છે.

એપ્લિકેશનો સંવેદનશીલ ડેટાનો ઉપયોગ કરે છે, જેમ કે ટોકન્સ, ડેટાબેઝ પાસવર્ડ, આ બધું પપેટ માસ્ટરની રૂપરેખામાં ખેંચાય છે, જ્યાં તે એનક્રિપ્ટેડ સ્વરૂપમાં સંગ્રહિત થાય છે.

TFS સમસ્યાઓ

અમે નક્કી કર્યા પછી અને સમજ્યા પછી કે બધું જ ખરેખર અમારા માટે કામ કરી રહ્યું છે, મેં અન્ય પ્રોજેક્ટ્સ પર વિન ડેવલપમેન્ટ વિભાગ માટે TFS માં એસેમ્બલી સાથે શું ચાલી રહ્યું છે તે જોવાનું નક્કી કર્યું - પછી ભલે અમે ઝડપથી નિર્માણ કરી રહ્યાં હોઈએ કે નહીં, અને ઝડપ સાથે નોંધપાત્ર સમસ્યાઓ મળી.

મુખ્ય પ્રોજેક્ટ્સમાંના એકને એસેમ્બલ કરવામાં 12-15 મિનિટ લાગે છે - તે લાંબો સમય છે, તમે તેના જેવું જીવી શકતા નથી. ઝડપી પૃથ્થકરણે I/O માં ભયંકર ઘટાડો દર્શાવ્યો, અને આ એરે પર હતું.

ઘટક દ્વારા તેના ઘટકનું વિશ્લેષણ કર્યા પછી, મેં ત્રણ ફોસી ઓળખ્યા. પ્રથમ - "કેસ્પરસ્કી એન્ટીવાયરસ", જે તમામ વિન્ડોઝ બિલ્ડ એજન્ટો પર સ્ત્રોતોને સ્કેન કરે છે. બીજું - વિન્ડોઝ ઈન્ડેક્સર. તે નિષ્ક્રિય કરવામાં આવ્યું ન હતું, અને જમાવટ પ્રક્રિયા દરમિયાન બિલ્ડ એજન્ટ્સ પર બધું જ રીઅલ ટાઇમમાં અનુક્રમિત કરવામાં આવ્યું હતું.

ત્રીજું - એનપીએમ ઇન્સ્ટોલ કરો. તે બહાર આવ્યું છે કે મોટાભાગની પાઇપલાઇન્સમાં અમે આ ચોક્કસ દૃશ્યનો ઉપયોગ કર્યો છે. તે શા માટે ખરાબ છે? જ્યારે નિર્ભરતા વૃક્ષની રચના થાય ત્યારે Npm ઇન્સ્ટોલ પ્રક્રિયા ચલાવવામાં આવે છે package-lock.json, જ્યાં પ્રોજેક્ટ બનાવવા માટે ઉપયોગમાં લેવાતા પેકેજોની આવૃત્તિઓ રેકોર્ડ કરવામાં આવે છે. નુકસાન એ છે કે Npm ઇન્સ્ટોલ દર વખતે ઇન્ટરનેટ પરથી પેકેજના નવીનતમ સંસ્કરણોને ખેંચે છે, અને મોટા પ્રોજેક્ટના કિસ્સામાં આ ઘણો સમય લે છે.

વિકાસકર્તાઓ કેટલીકવાર કોઈ ચોક્કસ ભાગ અથવા સમગ્ર પ્રોજેક્ટ કેવી રીતે કાર્ય કરે છે તે ચકાસવા માટે સ્થાનિક મશીન પર પ્રયોગ કરે છે. કેટલીકવાર તે બહાર આવ્યું કે બધું સ્થાનિક રીતે ઠંડુ હતું, પરંતુ તેઓએ તેને એસેમ્બલ કર્યું, તેને રોલ આઉટ કર્યું અને કંઈ કામ કર્યું નહીં. અમે સમસ્યા શું છે તે શોધવાનું શરૂ કરીએ છીએ - હા, ડિપેન્ડન્સીવાળા પેકેજોની વિવિધ આવૃત્તિઓ.

નિર્ણય

  • AV અપવાદોના સ્ત્રોતો.
  • અનુક્રમણિકા અક્ષમ કરો.
  • પર જાઓ npm ci.

npm ci ના ફાયદા એ છે કે અમે અમે એકવાર અવલંબન વૃક્ષ એકત્રિત કરીએ છીએ, અને અમને વિકાસકર્તા પ્રદાન કરવાની તક મળે છે પેકેજોની વર્તમાન યાદી, જેની સાથે તે તેને ગમે તેટલો સ્થાનિક રીતે પ્રયોગ કરી શકે છે. આ સમય બચાવે છે વિકાસકર્તાઓ જે કોડ લખે છે.

રૂપરેખાંકન

હવે રિપોઝીટરી રૂપરેખાંકન વિશે થોડું. ઐતિહાસિક રીતે આપણે ઉપયોગ કરીએ છીએ નેક્સસ રીપોઝીટરીઝના સંચાલન માટે, સહિત આંતરિક REPO. આ આંતરિક ભંડાર એ તમામ ઘટકો ધરાવે છે જેનો આપણે આંતરિક હેતુઓ માટે ઉપયોગ કરીએ છીએ, ઉદાહરણ તરીકે, સ્વ-લેખિત દેખરેખ.

Linux પર .NET કોર, ઘોડેસવાર પર DevOps

અમે પણ ઉપયોગ કરીએ છીએ ન્યુગેટ, કારણ કે તે અન્ય પેકેજ મેનેજરોની સરખામણીમાં વધુ સારી કેશીંગ ધરાવે છે.

પરિણામ

અમે બિલ્ડ એજન્ટોને ઑપ્ટિમાઇઝ કર્યા પછી, સરેરાશ બિલ્ડ સમય 12 મિનિટથી ઘટાડીને 7 કરવામાં આવ્યો.

જો આપણે વિન્ડોઝ માટે ઉપયોગમાં લેવાતા તમામ મશીનોની ગણતરી કરીએ, પરંતુ આ પ્રોજેક્ટમાં લિનક્સ પર સ્વિચ કર્યું, તો અમે લગભગ $10 બચાવીશું. અને તે ફક્ત લાયસન્સ પર છે, અને જો આપણે સામગ્રીને ધ્યાનમાં લઈએ તો વધુ.

યોજનાઓ

આગામી ક્વાર્ટર માટે, અમે કોડ ડિલિવરીને ઑપ્ટિમાઇઝ કરવા પર કામ કરવાની યોજના બનાવી છે.

પ્રીબિલ્ડ ડોકર ઈમેજ પર સ્વિચ કરી રહ્યાં છીએ. TFS એ ઘણા પ્લગઇન્સ સાથે એક સરસ વસ્તુ છે જે તમને પાઇપલાઇનમાં એકીકૃત કરવાની મંજૂરી આપે છે, જેમાં ડોકર ઇમેજની ટ્રિગર-આધારિત એસેમ્બલીનો સમાવેશ થાય છે. અમે આ ટ્રિગર સમાન માટે બનાવવા માંગીએ છીએ package-lock.json. જો પ્રોજેક્ટ બનાવવા માટે ઉપયોગમાં લેવાતા ઘટકોની રચના કોઈક રીતે બદલાય છે, તો અમે એક નવી ડોકર છબી બનાવીએ છીએ. તે પછીથી એસેમ્બલ એપ્લિકેશન સાથે કન્ટેનર જમાવવા માટે વપરાય છે. અત્યારે એવું નથી, પરંતુ અમે કુબરનેટ્સમાં માઇક્રોસર્વિસ આર્કિટેક્ચર પર સ્વિચ કરવાનું વિચારી રહ્યા છીએ, જે અમારી કંપનીમાં સક્રિય રીતે વિકાસ કરી રહી છે અને લાંબા સમયથી ઉત્પાદન ઉકેલો આપી રહી છે.

સારાંશ

હું દરેકને વિન્ડોઝ ફેંકી દેવા માટે પ્રોત્સાહિત કરું છું, પરંતુ એવું નથી કારણ કે મને તે કેવી રીતે રાંધવું તે ખબર નથી. કારણ એ છે કે મોટાભાગના ઓપનસોર્સ સોલ્યુશન્સ છે Linux સ્ટેક. તમે ઠીક છો સંસાધનો પર બચત કરો. મારા મતે, ભવિષ્ય એક શક્તિશાળી સમુદાય સાથે Linux પર ઓપન સોર્સ સોલ્યુશન્સનું છે.

એલેક્ઝાન્ડર સિંચિનોવની સ્પીકર પ્રોફાઇલ GitHub પર.

DevOps કોન્ફ વ્યાવસાયિકો દ્વારા વ્યાવસાયિકો માટે વિકાસ, પરીક્ષણ અને ઓપરેશન પ્રક્રિયાઓના સંકલન પર એક પરિષદ છે. તેથી જ એલેક્ઝાંડરે જે પ્રોજેક્ટ વિશે વાત કરી હતી? અમલમાં મૂક્યું અને કામ કર્યું, અને પ્રદર્શનના દિવસે બે સફળ પ્રકાશન થયા. ચાલુ RIT++ પર DevOps કોન્ફ 27 અને 28 મેના રોજ પ્રેક્ટિશનરો તરફથી વધુ સમાન કેસો હશે. તમે હજુ પણ છેલ્લી ગાડીમાં કૂદી શકો છો અને રિપોર્ટ જમા કરો અથવા તમારો સમય લો પુસ્તક ને ટિકિટ અમને Skolkovo માં મળો!

સોર્સ: www.habr.com

એક ટિપ્પણી ઉમેરો