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

બે પ્રકારની સ્થિતિ, એક નિકાલજોગ છે

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

પૂછો કે તમારી કઈ VPN ફાઇલો જાહેર કરેલા ઇનપુટ છે અને કઈ અકસ્માત છે:

docker diff wg-vpn
docker inspect --format '{{json .Mounts}}' wg-vpn

diff બતાવે છે કે લખી શકાય તેવા સ્તરમાં શું બદલાયું, અને તે બરાબર એ જ વસ્તુઓનો સમૂહ છે જે અદૃશ્ય થશે. mount યાદી બતાવે છે કે શું ટકી રહે છે. બંનેની સરખામણી કંઈ ગુમાવ્યા પહેલાં પ્રશ્નનો જવાબ આપે છે.

bind mount, નામવાળું volume કે secret: દરેક શું સુરક્ષિત કરે છે

ત્રણેય VPN પ્રોફાઇલ રાખી શકે છે, અને તે કોણ તેને વાંચી શકે છે અને બદલી વખતે શું થાય છે તેમાં ભિન્ન છે.

MechanismSurvives recreationWho can read it
Writable layerNoAnyone with container access, until it is gone
Bind mountYes, while the host path existsWhatever the host permissions allow
Named volumeYes, until the volume is removedManaged by the runtime
SecretYes, as a declared inputThe container process, by design

bind mount હોસ્ટ પાથને મેપ કરે છે, તેથી ફાઇલ તે પાથ જેટલી સુરક્ષિત છે અને હોસ્ટની પરવાનગીઓ જેટલી દૃશ્યમાન છે. નામવાળું volume runtime દ્વારા સંચાલિત થાય છે અને કન્ટેનર દૂર થવા પર ટકી રહે છે, જે તેને ડિપ્લોયમેન્ટની માલિકીની સ્થિતિ માટે વધુ સુરક્ષિત ડિફોલ્ટ બનાવે છે. secret પદ્ધતિ એવી સામગ્રી માટે છે જે તમે image અથવા environment variable માં નથી ઇચ્છતા.

દરેક environment variable અને હોસ્ટ ફાઇલને સમાન સંરક્ષણ ન ગણો, કારણ કે તે સમાન નથી.

કન્ટેનરની અંદર સંપાદન જ જાળ છે

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

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

તે પહોળું કરવું જ કન્ટેનરની સુવિધાને હોસ્ટના એક્સપોઝરમાં ફેરવે છે.

જાણીપૂર્વક પુનઃરચના કરો, પછી ચાર વસ્તુઓ ચકાસો

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

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

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

કન્ટેનરની બહાર પુનઃપ્રાપ્તિ નકલ રાખો

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

જો VPN ધરાવતું કન્ટેનર બદલાય, તો તેનો નેટવર્ક સ્ટેક વહેંચતી એપ્લિકેશનોને runtime ના સમર્થિત જીવનચક્રમાં સંકલન કરો.

તે સંકલન જ ફરી શરૂ કરવા અને વિક્ષેપ વચ્ચેનો તફાવત છે. ડિપ્લોયમેન્ટે વર્ણવવું જોઈએ કે રૂપરેખાંકન ક્યાંથી આવે છે, અને volume દસ્તાવેજીકરણ એ જ જગ્યા છે જ્યાં runtime ખરેખર શું જાળવે છે તે તપાસવું.

સંબંધિત લેખો