EC2 થી ખાનગી RDS: એ જ VPC, peering કે બીજું કંઈક?

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

લેપટોપનું VPN એ એપ્લિકેશનનો માર્ગ નથી

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

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

નિર્ણય 1: એ જ VPC, સીધો માર્ગ

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

aws ec2 authorize-security-group-ingress --group-id sg-0db123   --protocol tcp --port 5432 --source-group sg-0app456

aws rds describe-db-instances --db-instance-identifier prod-db   --query 'DBInstances[0].{Endpoint:Endpoint.Address,Port:Endpoint.Port,Public:PubliclyAccessible,Groups:VpcSecurityGroups}'

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

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

નિર્ણય 2: બીજું VPC અથવા બીજું ખાતું

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

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

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

નિર્ણય 3: ડેટાબેઝ કઈ ઓળખ સ્વીકારે છે

નેટવર્ક ઍક્સેસ અને ડેટાબેઝ પ્રમાણીકરણ અલગ સ્તરો છે, અને તેમને ભેગા કરવાથી સૌથી ગેરમાર્ગે દોરતી ભૂલો થાય છે. ઇન્સ્ટન્સ રોલ એ AWS API કૉલ કરવા માટેની AWS ઓળખ છે. તે ડેટાબેઝ વપરાશકર્તા નથી. IAM ડેટાબેઝ પ્રમાણીકરણ એ સમર્થિત સુવિધા છે જ્યાં એન્જિન અને ગોઠવણી પરવાનગી આપે, અને તે હજી પણ ડેટાબેઝ વપરાશકર્તામાં મેપિંગ છે, તેનો વિકલ્પ નથી.

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

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

ડિપ્લોય કરેલા પર્યાવરણમાંથી ચકાસો

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

psql "host=prod-db.abc123.eu-west-1.rds.amazonaws.com port=5432 dbname=app sslmode=verify-full" -c 'select 1'

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