એક લેબ સર્વર, ત્રણ વિશ્વાસ ભૂમિકાઓ, એક નિષ્ફળતા ડોમેન

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

ત્રણ ભૂમિકાઓ જે હાલમાં બધું વહેંચે છે

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

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

નીચેનો સ્કેચ તે વિભાજન માટે પ્રારંભિક બિંદુ છે, ઉચ્ચ ઉપલબ્ધતાનું વચન નહીં. તેને ચકાસવાની પરિકલ્પના તરીકે લો, અંતિમ ડિઝાઇન તરીકે નહીં.

ત્રણ ભૂમિકાઓ અલગ કરો, ત્રણ પ્રક્રિયાઓ નહીં

એક હોસ્ટ પર ત્રણ મહેમાનો ત્રણ અધિકાર સમૂહો અને ત્રણ નેટવર્ક સ્થાનો આપે છે. તેઓ ત્રણ નિષ્ફળતા ડોમેન આપતા નથી, અને ડિઝાઇનએ તે મોટેથી કહેવું જોઈએ.

વિભાજન ફક્ત ત્યારે જ મદદ કરે જ્યારે એક મહેમાનમાં સમાધાન આપોઆપ બીજાને અધિકાર ન આપે, અને તે હાઇપરવાઇઝર સેટિંગ છે, નામકરણ પરંપરા નહીં. VM ને ગેટવે કહેવાથી બીજા મહેમાનને હોસ્ટ સુધી પહોંચતા રોકાતું નથી. હોસ્ટનામને બદલે વર્ચ્યુઅલ સ્વિચ રૂપરેખાંકન વાંચો, પછી ખાતરી કરો કે દરેક મહેમાન તમે ધારો છો ત્યાં બેઠું છે.

host
├─ vpn-gw      10.60.10.2/24   public 51820/udp only
├─ services    10.60.0.10/24   no route to the management network
└─ ci-runner   10.60.20.2/24   outbound only, no host socket

ટોપોલોજી લખો અને પછી તેના માલિક હોય તેવા સાધનોથી ચકાસો. ખોટા બ્રિજ પર દેખાતું મહેમાન તપાસ છે, વિગત નહીં. કોઈપણ સેવા રૂપરેખાંકન બદલતા પહેલા નેટવર્ક સુધારો.

VPN મહેમાનને ફક્ત તેના પોતાના દરવાજા ખોલવા દો

રાઉટર પર ટનલ પોર્ટ પ્રકાશિત કરો અને બીજું કંઈ નહીં. મહેમાન વ્યવસ્થાપન પોર્ટ મેનેજમેન્ટ માર્ગના છે, ઇન્ટરનેટના નહીં, અને હાઇપરવાઇઝરનું પોતાનું ઇન્ટરફેસ પણ ત્યાં જ છે.

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

virsh net-list --all
virsh net-dumpxml lab-private
sudo nft list ruleset | grep -n -E '51820|10.60'

હોસ્ટ પર સાંભળતું અને મેનેજમેન્ટ માટે ન જરૂરી હોય તેવું કંઈપણ બિલકુલ સાંભળવું ન જોઈએ. તેમાં હાઇપરવાઇઝર API નો સમાવેશ થાય છે, જેને જાહેર ઇન્ટરફેસ પર ખુલ્લું રાખવું સરળ છે.

બિલ્ડ કાર્યોને જુદા પ્રકારની સીમા જોઈએ

CI કાર્ય રિપોઝિટરી-નિયંત્રિત આદેશો ચલાવે છે, તેથી તેનો વિશ્વાસ કોણ કોડ પુશ કરી શકે તેના પર આધાર રાખે છે. શેલ એક્ઝિક્યુટર તે આદેશોને હોસ્ટ પર રનરના વપરાશકર્તા તરીકે ચલાવે છે, અને તે ઉપલબ્ધ સૌથી પહોળી સીમા છે.

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

સેવા મહેમાન ડેટાનો માલિક છે, તેથી તેની બેકઅપ યોજના એ છે જે ચાલવી જ જોઈએ. રિપોઝિટરીઓ, અપલોડ અને ડેટાબેઝને એક જ સમયપત્રકમાં રાખો. કાર્યની સ્થિતિ વાંચવાને બદલે પુનઃસ્થાપન ચકાસો.

ત્રણેય વહેંચે તે નિષ્ફળતા માટે યોજના કરો

એક હોસ્ટ એક નિષ્ફળતા ડોમેન છે. રીબૂટ એ જ ક્ષણે ટનલ અને દરેક ખાનગી સેવા દૂર કરે છે, અને તે જ સમયે અંદર જવાનો રસ્તો સૌથી વધુ મહત્વનો હોય છે.

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

virsh list --all
systemctl is-active libvirtd
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' https://10.60.0.10/
ss -ltnp | grep -E ':51820|:443'

પ્રક્રિયાઓની શરૂઆતનો ક્રમ માર્ગો અને DNS વિશે કંઈ સાબિત કરતો નથી, તેથી એકમની સ્થિતિને બદલે માર્ગ ચકાસો. દૂરસ્થ વપરાશકર્તાને ખરેખર માર્ગની જ જરૂર હોય છે.