કન્ટેનરની અંદર બિલ્ડાહ ચલાવવા માટેની માર્ગદર્શિકા

કન્ટેનર રનટાઇમને અલગ ટૂલિંગ ઘટકોમાં ડીકપલિંગ કરવાની સુંદરતા શું છે? ખાસ કરીને, આ સાધનોને જોડવાનું શરૂ થઈ શકે છે જેથી તેઓ એકબીજાને સુરક્ષિત કરે.

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

એટલા માટે લોકો સતત બિલ્ડાને કન્ટેનરમાં ચલાવવાનો પ્રયાસ કરે છે. ટૂંકમાં, અમે બનાવ્યું ઉદાહરણ અમારા મતે, બિલ્ડાહને કન્ટેનરની અંદર કેવી રીતે ચલાવવું શ્રેષ્ઠ છે, અને તેના પર અનુરૂપ છબીઓ પોસ્ટ કરી quay.io/buildah. ચાલો, શરુ કરીએ...

ગોઠવણ

આ છબીઓ ડોકરફાઈલ્સમાંથી બનાવવામાં આવી છે, જે ફોલ્ડરમાં બિલ્ડાહ રીપોઝીટરીમાં મળી શકે છે બિલ્ડ.
અહીં આપણે વિચારણા કરીશું ડોકરફાઇલનું સ્થિર સંસ્કરણ.

# stable/Dockerfile
#
# Build a Buildah container image from the latest
# stable version of Buildah on the Fedoras Updates System.
# https://bodhi.fedoraproject.org/updates/?search=buildah
# This image can be used to create a secured container
# that runs safely with privileges within the container.
#
FROM fedora:latest

# Don't include container-selinux and remove
# directories used by dnf that are just taking
# up space.
RUN yum -y install buildah fuse-overlayfs --exclude container-selinux; rm -rf /var/cache /var/log/dnf* /var/log/yum.*

# Adjust storage.conf to enable Fuse storage.
RUN sed -i -e 's|^#mount_program|mount_program|g' -e '/additionalimage.*/a "/var/lib/shared",' /etc/containers/storage.conf

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

podman run --device /dev/fuse quay.io/buildahctr ...
RUN mkdir -p /var/lib/shared/overlay-images /var/lib/shared/overlay-layers; touch /var/lib/shared/overlay-images/images.lock; touch /var/lib/shared/overlay-layers/layers.lock

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

# Set up environment variables to note that this is
# not starting with user namespace and default to
# isolate the filesystem with chroot.
ENV _BUILDAH_STARTED_IN_USERNS="" BUILDAH_ISOLATION=chroot

છેલ્લે, BUILDAH_ISOLATION પર્યાવરણ ચલનો ઉપયોગ કરીને, અમે બિલ્ડાહ કન્ટેનરને મૂળભૂત રીતે chroot આઇસોલેશન સાથે ચલાવવા માટે કહીએ છીએ. અહીં વધારાના ઇન્સ્યુલેશનની જરૂર નથી, કારણ કે અમે પહેલેથી જ કન્ટેનરમાં કામ કરી રહ્યા છીએ. બિલ્ડાહ તેના પોતાના નેમસ્પેસ-સેપરેટેડ કન્ટેનર બનાવવા માટે, SYS_ADMIN વિશેષાધિકાર જરૂરી છે, જેમાં કન્ટેનરના SELinux અને SECOMP નિયમોને હળવા કરવાની જરૂર પડશે, જે સુરક્ષિત કન્ટેનરમાંથી બનાવવાની અમારી પસંદગીની વિરુદ્ધ છે.

કન્ટેનરની અંદર બિલ્ડાહ ચાલી રહ્યું છે

ઉપર ચર્ચા કરેલ બિલ્ડાહ કન્ટેનર ઇમેજ ડાયાગ્રામ તમને આવા કન્ટેનર લોંચ કરવાની પદ્ધતિઓમાં લવચીક રીતે ફેરફાર કરવાની મંજૂરી આપે છે.

ઝડપ વિરુદ્ધ સલામતી

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

ઉપર ચર્ચા કરેલ કન્ટેનર ઇમેજ તેના સંગ્રહને /var/lib/containers માં રાખશે. તેથી, અમારે આ ફોલ્ડરમાં સામગ્રીને માઉન્ટ કરવાની જરૂર છે, અને અમે આ કેવી રીતે કરીએ છીએ તે કન્ટેનર છબીઓ બનાવવાની ઝડપને મોટા પ્રમાણમાં અસર કરશે.

ચાલો ત્રણ વિકલ્પો ધ્યાનમાં લઈએ.

1 વિકલ્પ. જો મહત્તમ સુરક્ષા જરૂરી હોય, તો દરેક કન્ટેનર માટે તમે કન્ટેનર/ઇમેજ માટે તમારું પોતાનું ફોલ્ડર બનાવી શકો છો અને તેને વોલ્યુમ-માઉન્ટ દ્વારા કન્ટેનર સાથે કનેક્ટ કરી શકો છો. અને ઉપરાંત, સંદર્ભ નિર્દેશિકાને કન્ટેનરમાં જ, /build ફોલ્ડરમાં મૂકો:

# mkdir /var/lib/containers1
# podman run -v ./build:/build:z -v /var/lib/containers1:/var/lib/containers:Z quay.io/buildah/stable
buildah  -t image1 bud /build
# podman run -v /var/lib/containers1:/var/lib/containers:Z quay.io/buildah/stable buildah  push  image1 registry.company.com/myuser
# rm -rf /var/lib/containers1

સુરક્ષા આવા કન્ટેનરમાં ચાલતા બિલ્ડામાં મહત્તમ સુરક્ષા હોય છે: તેને ક્ષમતાઓનો ઉપયોગ કરીને કોઈપણ રૂટ વિશેષાધિકારો આપવામાં આવતા નથી, અને તેના પર તમામ SECOMP અને SELinux પ્રતિબંધો લાગુ પડે છે. આવા કન્ટેનરને —uidmap 0 જેવા વિકલ્પ ઉમેરીને વપરાશકર્તા નેમસ્પેસ આઈસોલેશન સાથે પણ ચલાવી શકાય છે. 100000: 10000.

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

2 વિકલ્પ. જો તમને ડોકર-સ્તરની કામગીરીની જરૂર હોય, તો તમે યજમાન કન્ટેનર/સ્ટોરેજને સીધા જ કન્ટેનરમાં માઉન્ટ કરી શકો છો.

# podman run -v ./build:/build:z -v /var/lib/containers:/var/lib/containers --security-opt label:disabled quay.io/buildah/stable buildah  -t image2 bud /build
# podman run -v /var/lib/containers:/var/lib/containers --security-opt label:disabled  quay.io/buildah/stable buildah push image2 registry.company.com/myuser

સુરક્ષા કન્ટેનર બનાવવાની આ સૌથી ઓછી સુરક્ષિત રીત છે કારણ કે તે કન્ટેનરને હોસ્ટ સ્ટોરેજને સંશોધિત કરવાની મંજૂરી આપે છે અને સંભવિત રીતે પોડમેન અથવા CRI-O ને દૂષિત ઇમેજ ફીડ કરી શકે છે. વધુમાં, તમારે SELinux વિભાજનને નિષ્ક્રિય કરવાની જરૂર પડશે જેથી કરીને Buildah કન્ટેનરમાંની પ્રક્રિયાઓ હોસ્ટ પરના સંગ્રહ સાથે ક્રિયાપ્રતિક્રિયા કરી શકે. નોંધ કરો કે આ વિકલ્પ હજુ પણ ડોકર સોકેટ કરતાં વધુ સારો છે કારણ કે કન્ટેનર બાકીની સુરક્ષા સુવિધાઓ દ્વારા લૉક ડાઉન છે અને તે ફક્ત હોસ્ટ પર કન્ટેનર ચલાવી શકતું નથી.

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

3 વિકલ્પ. આ પદ્ધતિનો સાર એ છે કે કન્ટેનર છબીઓ માટેના સામાન્ય ફોલ્ડર સાથે એક પ્રોજેક્ટમાં ઘણી છબીઓને જોડવી.

# mkdir /var/lib/project3
# podman run --security-opt label_level=s0:C100, C200 -v ./build:/build:z 
-v /var/lib/project3:/var/lib/containers:Z quay.io/buildah/stable buildah  -t image3 bud /build
# podman run --security-opt label_level=s0:C100, C200 
-v /var/lib/project3:/var/lib/containers quay.io/buildah/stable buildah push image3  registry.company.com/myuser

આ ઉદાહરણમાં, અમે રનની વચ્ચે પ્રોજેક્ટ ફોલ્ડર (/var/lib/project3) ને ડિલીટ કરતા નથી, તેથી પ્રોજેક્ટની અંદરના તમામ અનુગામી બિલ્ડ્સને કેશીંગથી ફાયદો થાય છે.

સુરક્ષા વિકલ્પો 1 અને 2 ની વચ્ચે કંઈક બીજી બાજુ, તેની ડિઝાઇનના ભાગ રૂપે, કન્ટેનર અન્ય કન્ટેનરની એસેમ્બલીમાં દખલ કરી શકે છે.

પ્રદર્શન. અહીં તે હોસ્ટ લેવલ પર શેર કરેલ કેશનો ઉપયોગ કરતા કરતા વધુ ખરાબ છે, કારણ કે તમે Podman/CRI-O નો ઉપયોગ કરીને પહેલાથી જ ડાઉનલોડ કરેલ ઈમેજનો ઉપયોગ કરી શકતા નથી. જો કે, એકવાર બિલ્ડાહે ઇમેજ ડાઉનલોડ કરી લીધા પછી, પ્રોજેક્ટની અંદરના કોઈપણ અનુગામી બિલ્ડ્સમાં ઇમેજનો ઉપયોગ કરી શકાય છે.

વધારાનો સંગ્રહ

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

જો તમે ઉપર સ્ક્રોલ કરો અને ડોકરફાઈલ જુઓ જેનો ઉપયોગ અમે ઈમેજ quay.io/buildah/stable બનાવવા માટે કરીએ છીએ, તો ત્યાં આના જેવી લાઈનો છે:

# Adjust storage.conf to enable Fuse storage.
RUN sed -i -e 's|^#mount_program|mount_program|g' -e '/additionalimage.*/a "/var/lib/shared",' /etc/containers/storage.conf
RUN mkdir -p /var/lib/shared/overlay-images /var/lib/shared/overlay-layers; touch /var/lib/shared/overlay-images/images.lock; touch /var/lib/shared/overlay-layers/layers.lock

પ્રથમ લીટીમાં, અમે કન્ટેનર ઈમેજની અંદર /etc/containers/storage.conf ને સંશોધિત કરીએ છીએ, સ્ટોરેજ ડ્રાઈવરને /var/lib/shared ફોલ્ડરમાં "additionalimagestores" નો ઉપયોગ કરવાનું કહીએ છીએ. અને આગળની લીટીમાં અમે એક શેર કરેલ ફોલ્ડર બનાવીએ છીએ અને કેટલીક લોક ફાઇલો ઉમેરીએ છીએ જેથી કન્ટેનર/સ્ટોરેજનો કોઈ દુરુપયોગ ન થાય. આવશ્યકપણે, અમે ખાલી કન્ટેનર ઇમેજ સ્ટોર બનાવી રહ્યા છીએ.

જો તમે આ ફોલ્ડર કરતા ઊંચા સ્તરે કન્ટેનર/સ્ટોરેજ માઉન્ટ કરો છો, તો બિલ્ડાહ ઈમેજોનો ઉપયોગ કરી શકશે.

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

# mkdir /var/lib/containers4
# podman run -v ./build:/build:z -v /var/lib/containers/storage:/var/lib/shared:ro -v  /var/lib/containers4:/var/lib/containers:Z  quay.io/buildah/stable 
 buildah  -t image4 bud /build
# podman run -v /var/lib/containers/storage:/var/lib/shared:ro  
-v >/var/lib/containers4:/var/lib/containers:Z quay.io/buildah/stable buildah push image4  registry.company.com/myuser
# rm -rf /var/lib/continers4

નોંધ કરો કે યજમાનનું /var/lib/containers/storage એ કન્ટેનરની અંદર માત્ર-વાંચવા માટેના મોડમાં /var/lib/shared પર માઉન્ટ થયેલ છે. તેથી, કન્ટેનરમાં કામ કરીને, બિલ્ડાહ પોડમેન/સીઆરઆઈ-ઓ (હેલો, સ્પીડ) નો ઉપયોગ કરીને અગાઉ ડાઉનલોડ કરેલી કોઈપણ છબીઓનો ઉપયોગ કરી શકે છે, પરંતુ ફક્ત તેના પોતાના સ્ટોરેજ (હેલો, સુરક્ષા) પર લખી શકે છે. એ પણ નોંધ કરો કે આ કન્ટેનર માટે SELinux વિભાજનને નિષ્ક્રિય કર્યા વિના કરવામાં આવે છે.

મહત્વનું ઘોષણા

કોઈ પણ સંજોગોમાં તમારે અંતર્ગત રીપોઝીટરીમાંથી કોઈપણ છબીઓ કાઢી નાખવા જોઈએ નહીં. નહિંતર, બિલ્ડાહ કન્ટેનર ક્રેશ થઈ શકે છે.

અને આ બધા ફાયદા નથી

વધારાના સ્ટોરેજની શક્યતાઓ ઉપરોક્ત દૃશ્ય સુધી મર્યાદિત નથી. ઉદાહરણ તરીકે, તમે શેર કરેલ નેટવર્ક સ્ટોરેજ પર તમામ કન્ટેનર છબીઓ મૂકી શકો છો અને તેને બધા બિલ્ડાહ કન્ટેનરને ઍક્સેસ આપી શકો છો. ચાલો કહીએ કે અમારી પાસે સેંકડો છબીઓ છે જેનો ઉપયોગ અમારી CI/CD સિસ્ટમ નિયમિતપણે કન્ટેનર છબીઓ બનાવવા માટે કરે છે. અમે આ બધી છબીઓને એક સ્ટોરેજ હોસ્ટ પર કેન્દ્રિત કરીએ છીએ અને પછી, પસંદગીના નેટવર્ક સ્ટોરેજ ટૂલ્સ (NFS, Gluster, Ceph, ISCSI, S3...) નો ઉપયોગ કરીને, અમે આ સ્ટોરેજની સામાન્ય ઍક્સેસ બધા Buildah અથવા Kubernetes નોડ્સ પર ખોલીએ છીએ.

હવે આ નેટવર્ક સ્ટોરેજને /var/lib/shared પર બિલ્ડાહ કન્ટેનરમાં માઉન્ટ કરવા માટે પૂરતું છે અને બસ - બિલ્ડાહ કન્ટેનરને હવે પુલ દ્વારા છબીઓ ડાઉનલોડ કરવાની જરૂર નથી. આમ, અમે પૂર્વ-વસ્તીનો તબક્કો ફેંકી દઈએ છીએ અને તરત જ કન્ટેનર રોલ આઉટ કરવા માટે તૈયાર છીએ.

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

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

વધુમાં, અમે હાલમાં ઓવરલે વોલ્યુમ માઉન્ટ્સ નામની એક નવી સુવિધા પર કામ કરી રહ્યા છીએ, જે કન્ટેનરને વધુ ઝડપી બનાવશે.

નિષ્કર્ષ

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

વધારાના સ્ટોરેજની કાર્યક્ષમતા તમને નોડ્સ પર છબીઓને ડાઉનલોડ કરવાની ગતિ વધારવા અથવા તેને સંપૂર્ણપણે દૂર કરવાની મંજૂરી આપે છે.

સોર્સ: www.habr.com