కంటైనర్ రన్‌టైమ్‌ను ప్రత్యేక టూలింగ్ కాంపోనెంట్‌లుగా విడదీయడం యొక్క అందం ఏమిటి? ప్రత్యేకించి, ఈ సాధనాలు ఒకదానికొకటి రక్షించుకునేలా కలపడం ప్రారంభించవచ్చు.
చాలా మంది వ్యక్తులు కంటెయినరైజ్డ్ OCI చిత్రాలను నిర్మించాలనే ఆలోచనకు ఆకర్షితులవుతారు లేదా ఇలాంటి వ్యవస్థ. నిరంతరం చిత్రాలను సేకరించే CI/CD మన వద్ద ఉందని చెప్పండి, ఆపై అలాంటిదే /బిల్డ్‌ల సమయంలో లోడ్ బ్యాలెన్సింగ్ విషయంలో కుబెర్నెట్స్ చాలా ఉపయోగకరంగా ఉంటుంది. ఇటీవలి వరకు, చాలా మంది వ్యక్తులు డాకర్ సాకెట్‌కు కంటైనర్‌లకు ప్రాప్యతను అందించారు మరియు వాటిని డాకర్ బిల్డ్ కమాండ్‌ను అమలు చేయడానికి అనుమతించారు. ఇది చాలా అసురక్షితమని, నిజానికి, ఇది పాస్‌వర్డ్‌లేని రూట్ లేదా సుడో ఇవ్వడం కంటే దారుణంగా ఉంది.
అందుకే బిల్డాను కంటైనర్‌లో నడపడానికి ప్రజలు నిరంతరం ప్రయత్నిస్తారు. సంక్షిప్తంగా, మేము సృష్టించాము ఎలా, మా అభిప్రాయం ప్రకారం, కంటైనర్ లోపల బిల్డాను అమలు చేయడం ఉత్తమం మరియు సంబంధిత చిత్రాలను పోస్ట్ చేసింది . ప్రారంభిద్దాం...
సర్దుబాటు
ఈ చిత్రాలు డాకర్‌ఫైల్స్ నుండి నిర్మించబడ్డాయి, వీటిని ఫోల్డర్‌లోని బిల్డ్ రిపోజిటరీలో చూడవచ్చు .
ఇక్కడ మేము పరిశీలిస్తాము .
# 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
హోస్ట్ Linux కెర్నల్ స్థాయిలో అమలు చేయబడిన OverlayFSకి బదులుగా, మేము కంటైనర్‌లో ప్రోగ్రామ్‌ను ఉపయోగిస్తాము , ఎందుకంటే ప్రస్తుతం OverlayFS మీరు Linux సామర్థ్యాలను ఉపయోగించి SYS_ADMIN అనుమతులు ఇస్తే మాత్రమే మౌంట్ చేయగలదు. మరియు మేము మా Buildah కంటైనర్లను ఎటువంటి రూట్ అధికారాలు లేకుండా అమలు చేయాలనుకుంటున్నాము. ఫ్యూజ్-ఓవర్లే చాలా త్వరగా పని చేస్తుంది మరియు VFS స్టోరేజ్ డ్రైవర్ కంటే మెరుగైన పనితీరును కలిగి ఉంటుంది. ఫ్యూజ్‌ని ఉపయోగించే Buildah కంటైనర్‌ను అమలు చేస్తున్నప్పుడు, మీరు తప్పనిసరిగా /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 ఐసోలేషన్‌తో రన్ చేయమని Buildah కంటైనర్‌కి చెబుతున్నాము. ఇక్కడ అదనపు ఇన్సులేషన్ అవసరం లేదు, ఎందుకంటే మేము ఇప్పటికే కంటైనర్‌లో పని చేస్తున్నాము. Buildah దాని స్వంత నేమ్‌స్పేస్-వేరు చేయబడిన కంటైనర్లను సృష్టించడానికి, SYS_ADMIN ప్రత్యేక హక్కు అవసరం, దీనికి కంటైనర్ యొక్క SELinux మరియు SECCOMP నియమాలను సడలించడం అవసరం, ఇది సురక్షితమైన కంటైనర్ నుండి నిర్మించాలనే మా ప్రాధాన్యతకు విరుద్ధం.
కంటైనర్ లోపల బిల్డాను నడుపుతోంది
పైన చర్చించిన Buildah కంటైనర్ ఇమేజ్ రేఖాచిత్రం అటువంటి కంటైనర్లను ప్రారంభించే పద్ధతులను సరళంగా మార్చడానికి మిమ్మల్ని అనుమతిస్తుంది.
వేగం వర్సెస్ భద్రత
కంప్యూటర్ భద్రత అనేది ప్రక్రియ యొక్క వేగం మరియు దాని చుట్టూ ఎంత రక్షణ కల్పించబడిందనే దాని మధ్య ఎల్లప్పుడూ రాజీ ఉంటుంది. కంటైనర్లను సమీకరించేటప్పుడు ఈ ప్రకటన కూడా నిజం, కాబట్టి మేము అటువంటి రాజీ కోసం ఎంపికలను క్రింద పరిశీలిస్తాము.
పైన చర్చించిన కంటైనర్ ఇమేజ్ దాని నిల్వను /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.
ప్రదర్శన. కానీ ఇక్కడ పనితీరు తక్కువగా ఉంటుంది, ఎందుకంటే కంటైనర్ రిజిస్ట్రీల నుండి ఏవైనా చిత్రాలు ప్రతిసారీ హోస్ట్‌కి కాపీ చేయబడతాయి మరియు కాషింగ్ అస్సలు పని చేయదు. దాని పనిని పూర్తి చేసినప్పుడు, Buildah కంటైనర్ తప్పనిసరిగా రిజిస్ట్రీకి చిత్రాన్ని పంపాలి మరియు హోస్ట్‌లోని కంటెంట్‌ను నాశనం చేయాలి. తదుపరిసారి కంటైనర్ చిత్రం నిర్మించబడినప్పుడు, అది మళ్లీ రిజిస్ట్రీ నుండి డౌన్‌లోడ్ చేయబడాలి, ఆ సమయానికి హోస్ట్‌లో ఏమీ మిగిలి ఉండదు.
ఎంపిక 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
సెక్యూరిటీ. కంటైనర్లను నిర్మించడానికి ఇది అతి తక్కువ సురక్షితమైన మార్గం ఎందుకంటే ఇది హోస్ట్ నిల్వను సవరించడానికి కంటైనర్‌ను అనుమతిస్తుంది మరియు Podman లేదా CRI-Oకి హానికరమైన చిత్రాన్ని అందించగలదు. అదనంగా, మీరు SELinux విభజనను నిలిపివేయవలసి ఉంటుంది, తద్వారా Buildah కంటైనర్‌లోని ప్రక్రియలు హోస్ట్‌లోని నిల్వతో పరస్పర చర్య చేయగలవు. ఈ ఎంపిక ఇప్పటికీ డాకర్ సాకెట్ కంటే మెరుగ్గా ఉందని గుర్తుంచుకోండి ఎందుకంటే కంటైనర్ మిగిలిన భద్రతా లక్షణాల ద్వారా లాక్ చేయబడింది మరియు హోస్ట్‌లో కంటైనర్‌ను అమలు చేయలేము.
ప్రదర్శన. కాషింగ్ పూర్తిగా ఉపయోగించబడినందున ఇక్కడ ఇది గరిష్టంగా ఉంటుంది. Podman లేదా CRI-O ఇప్పటికే అవసరమైన చిత్రాన్ని హోస్ట్‌కి డౌన్‌లోడ్ చేసి ఉంటే, కంటైనర్‌లోని Buildah ప్రక్రియ దానిని మళ్లీ డౌన్‌లోడ్ చేయనవసరం లేదు మరియు ఈ చిత్రం ఆధారంగా తదుపరి నిర్మాణాలు కూడా కాష్ నుండి అవసరమైన వాటిని తీసుకోగలుగుతాయి. .
ఎంపిక 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 ఇమేజ్ స్టోరేజ్‌లోకి ఏదైనా చెడు జారిపోదు. మరోవైపు, దాని రూపకల్పనలో భాగంగా, ఒక కంటైనర్ ఇతర కంటైనర్ల అసెంబ్లీకి అంతరాయం కలిగించవచ్చు.
ప్రదర్శన. ఇక్కడ మీరు Podman/CRI-Oని ఉపయోగించి ఇప్పటికే డౌన్‌లోడ్ చేసిన చిత్రాలను ఉపయోగించలేరు కాబట్టి, హోస్ట్ స్థాయిలో భాగస్వామ్య కాష్‌ని ఉపయోగిస్తున్నప్పుడు కంటే ఇది చాలా ఘోరంగా ఉంది. అయితే, Buildah చిత్రాన్ని డౌన్‌లోడ్ చేసిన తర్వాత, ప్రాజెక్ట్‌లోని ఏదైనా తదుపరి బిల్డ్‌లలో చిత్రాన్ని ఉపయోగించవచ్చు.
అదనపు నిల్వ
У అదనపు దుకాణాలు (అదనపు దుకాణాలు) వంటి అద్భుతమైన విషయం ఉంది, దీనికి ధన్యవాదాలు కంటైనర్లను ప్రారంభించేటప్పుడు మరియు నిర్మించేటప్పుడు, కంటైనర్ ఇంజిన్‌లు బాహ్య ఇమేజ్ స్టోర్‌లను చదవడానికి మాత్రమే ఓవర్లే మోడ్‌లో ఉపయోగించవచ్చు. ముఖ్యంగా, మీరు storage.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”ని ఉపయోగించమని చెబుతాము. మరియు తదుపరి లైన్‌లో మేము భాగస్వామ్య ఫోల్డర్‌ను సృష్టించి, కొన్ని లాక్ ఫైల్‌లను జోడిస్తాము, తద్వారా కంటైనర్లు/నిల్వ నుండి దుర్వినియోగం ఉండదు. ముఖ్యంగా, మేము కేవలం ఖాళీ కంటైనర్ ఇమేజ్ స్టోర్‌ని సృష్టిస్తున్నాము.
మీరు ఈ ఫోల్డర్ కంటే ఎక్కువ స్థాయిలో కంటైనర్లు/స్టోరేజ్‌ని మౌంట్ చేస్తే, Buildah చిత్రాలను ఉపయోగించగలుగుతుంది.
ఇప్పుడు పైన చర్చించిన ఎంపిక 2కి తిరిగి వెళ్దాం, Buildah కంటైనర్ హోస్ట్‌లలోని కంటైనర్లు/స్టోర్‌లను చదవగలదు మరియు వ్రాయగలదు మరియు తదనుగుణంగా, Podman/CRI-O స్థాయిలో ఇమేజ్‌లను కాషింగ్ చేయడం వల్ల గరిష్ట పనితీరును కలిగి ఉంటుంది, కానీ కనీస భద్రతను అందిస్తుంది. ఎందుకంటే ఇది నేరుగా నిల్వకు వ్రాయగలదు. ఇప్పుడు ఇక్కడ అదనపు నిల్వను జోడించి, రెండు ప్రపంచాలలోని ఉత్తమమైన వాటిని పొందండి.
# 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కి మౌంట్ చేయబడిందని గమనించండి. అందువల్ల, కంటైనర్‌లో పని చేస్తున్నప్పుడు, Buildah Podman/CRI-O (హలో, స్పీడ్) ఉపయోగించి గతంలో డౌన్‌లోడ్ చేసిన ఏవైనా చిత్రాలను ఉపయోగించవచ్చు, కానీ దాని స్వంత నిల్వకు మాత్రమే వ్రాయగలదు (హలో, భద్రత). కంటైనర్ కోసం SELinux విభజనను నిలిపివేయకుండానే ఇది జరుగుతుందని కూడా గమనించండి.
ముఖ్యమైన స్వల్పభేదాన్ని
ఎట్టి పరిస్థితుల్లోనూ మీరు అంతర్లీన రిపోజిటరీ నుండి ఎటువంటి చిత్రాలను తొలగించకూడదు. లేకపోతే, Buildah కంటైనర్ క్రాష్ కావచ్చు.
మరియు ఇవి అన్ని ప్రయోజనాలు కాదు
అదనపు నిల్వ యొక్క అవకాశాలు పై దృష్టాంతానికి పరిమితం కాలేదు. ఉదాహరణకు, మీరు అన్ని కంటైనర్ చిత్రాలను భాగస్వామ్య నెట్‌వర్క్ నిల్వలో ఉంచవచ్చు మరియు అన్ని బిల్డ్ కంటైనర్‌లకు యాక్సెస్ ఇవ్వవచ్చు. కంటైనర్ చిత్రాలను రూపొందించడానికి మా CI/CD సిస్టమ్ క్రమం తప్పకుండా ఉపయోగించే వందలాది చిత్రాలను కలిగి ఉన్నామని చెప్పండి. మేము ఈ చిత్రాలన్నింటినీ ఒకే స్టోరేజ్ హోస్ట్‌పై కేంద్రీకరిస్తాము, ఆపై, ప్రాధాన్య నెట్‌వర్క్ స్టోరేజ్ టూల్స్ (NFS, Gluster, Ceph, ISCSI, S3...) ఉపయోగించి, మేము ఈ స్టోరేజ్‌కి అన్ని Buildah లేదా Kubernetes నోడ్‌లకు సాధారణ యాక్సెస్‌ను తెరుస్తాము.
ఇప్పుడు ఈ నెట్‌వర్క్ నిల్వను /var/lib/sharedలోని Buildah కంటైనర్‌లోకి మౌంట్ చేస్తే సరిపోతుంది మరియు అంతే - Buildah కంటైనర్లు ఇకపై పుల్ ద్వారా చిత్రాలను డౌన్‌లోడ్ చేయవలసిన అవసరం లేదు. అందువల్ల, మేము జనాభాకు ముందు దశను విసిరివేస్తాము మరియు వెంటనే కంటైనర్లను బయటకు తీయడానికి సిద్ధంగా ఉన్నాము.
వాస్తవానికి, చిత్రాలను డౌన్‌లోడ్ చేయకుండా ఎక్కడైనా కంటైనర్లను లాంచ్ చేయడానికి మరియు అమలు చేయడానికి ఇది లైవ్ కుబెర్నెట్స్ సిస్టమ్ లేదా కంటైనర్ ఇన్‌ఫ్రాస్ట్రక్చర్‌లో ఉపయోగించబడుతుంది. అంతేకాకుండా, కంటైనర్ రిజిస్ట్రీ, దానికి నవీకరించబడిన చిత్రాన్ని అప్‌లోడ్ చేయడానికి పుష్ అభ్యర్థనను స్వీకరిస్తుంది, ఈ చిత్రాన్ని స్వయంచాలకంగా భాగస్వామ్య నెట్‌వర్క్ నిల్వకు పంపుతుంది, ఇక్కడ ఇది అన్ని నోడ్‌లకు తక్షణమే అందుబాటులో ఉంటుంది.
కంటైనర్ చిత్రాలు కొన్నిసార్లు అనేక గిగాబైట్‌ల పరిమాణాన్ని చేరుకోగలవు. అదనపు నిల్వ యొక్క కార్యాచరణ నోడ్‌ల అంతటా అటువంటి చిత్రాలను క్లోనింగ్ చేయకుండా నిరోధించడానికి మిమ్మల్ని అనుమతిస్తుంది మరియు కంటైనర్లను దాదాపు తక్షణమే లాంచ్ చేస్తుంది.
అదనంగా, మేము ప్రస్తుతం ఓవర్లే వాల్యూమ్ మౌంట్‌లు అనే కొత్త ఫీచర్‌పై పని చేస్తున్నాము, ఇది కంటైనర్లను మరింత వేగంగా నిర్మించేలా చేస్తుంది.
తీర్మానం
Kubernetes/CRI-O, Podman లేదా Dockerలో కంటైనర్‌లో Buildahని అమలు చేయడం సాధ్యమయ్యేది, సరళమైనది మరియు docker.socketని ఉపయోగించడం కంటే చాలా సురక్షితమైనది. మేము చిత్రాలతో పని చేసే సౌలభ్యాన్ని బాగా పెంచాము, కాబట్టి మీరు భద్రత మరియు పనితీరు మధ్య సమతుల్యతను ఆప్టిమైజ్ చేయడానికి వాటిని వివిధ మార్గాల్లో అమలు చేయవచ్చు.
అదనపు నిల్వ యొక్క కార్యాచరణ, చిత్రాలను నోడ్‌లకు డౌన్‌లోడ్ చేయడాన్ని వేగవంతం చేయడానికి లేదా పూర్తిగా తొలగించడానికి మిమ్మల్ని అనుమతిస్తుంది.
మూలం: www.habr.com