{"id":38785,"date":"2019-10-31T22:25:55","date_gmt":"2019-10-31T19:25:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/rekomendatsii-po-zapusku-buildah-vnutri-kontejnera\/"},"modified":"2019-10-31T22:25:55","modified_gmt":"2019-10-31T19:25:55","slug":"rekomendatsii-po-zapusku-buildah-vnutri-kontejnera","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/rekomendatsii-po-zapusku-buildah-vnutri-kontejnera","title":{"rendered":"Anbefalinger til at k\u00f8re Buildah inden i en beholder","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hvad er fordelen ved at opdele containerudf\u00f8relsesmilj\u00f8et i separate v\u00e6rkt\u00f8jer? Is\u00e6r at disse v\u00e6rkt\u00f8jer kan kombineres for at beskytte hinanden.<\/p>\n

\"Anbefalinger
\n
\nMange tiltr\u00e6kkes af ideen om at udf\u00f8re bygning af OCI-containere inden for Kubernetes<\/a><\/noindex> eller et lignende system. Lad os sige, at vi har CI\/CD, der konstant bygger billeder, s\u00e5 noget som Red Hat OpenShift<\/a><\/noindex>\/Kubernetes \u0431\u044b\u043b\u043e \u0431\u044b \u0432\u0435\u0441\u044c\u043c\u0430 \u043f\u043e\u043b\u0435\u0437\u043d\u043e \u0441 \u0442\u043e\u0447\u043a\u0438 \u0437\u0440\u0435\u043d\u0438\u044f \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u0438\u044f \u043d\u0430\u0433\u0440\u0443\u0437\u043a\u0438 \u043f\u0440\u0438 \u0441\u0431\u043e\u0440\u043a\u0435. \u0414\u043e \u043d\u0435\u0434\u0430\u0432\u043d\u0438\u0445 \u043f\u043e\u0440 \u0431\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u043b\u044e\u0434\u0435\u0439 \u043f\u0440\u043e\u0441\u0442\u043e \u0434\u0430\u0432\u0430\u043b\u0438 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430\u043c \u0434\u043e\u0441\u0442\u0443\u043f \u043a Docker-\u0441\u043e\u043a\u0435\u0442\u0443 \u0438 \u0440\u0430\u0437\u0440\u0435\u0448\u0430\u043b\u0438 \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0442\u044c \u043a\u043e\u043c\u0430\u043d\u0434\u0443 docker build. Vi viste allerede for flere \u00e5r siden<\/a><\/noindex>, at dette er meget usikkert, faktisk er det endda v\u00e6rre end at give root- eller sudo-adgang uden adgangskode.
\n<\/a><\/noindex>
\nDerfor fors\u00f8ger folk konstant at k\u00f8re Buildah i en container. Kort sagt, vi har skabt eksempel<\/a><\/noindex> hvordan vi mener, at man bedst k\u00f8rer Buildah inden i en container, og vi har lagt de relevante billeder p\u00e5 quay.io\/buildah<\/a><\/noindex>. Lad os komme i gang\u2026<\/p>\n

Indstillinger<\/h3>\n

\nDisse billeder er bygget fra Dockerfiles, som kan findes i Buildah-repositoriet i mappen buildahimage<\/a><\/noindex>.
\nHer vil vi se p\u00e5 den stabile version af Dockerfile<\/a><\/noindex>.<\/p>\n

# stable\/Dockerfile\n#\n# Build a Buildah container image from the latest\n# stable version of Buildah on the Fedoras Updates System.\n# https:\/\/bodhi.fedoraproject.org\/updates\/?search=buildah\n# This image can be used to create a secured container\n# that runs safely with privileges within the container.\n#\nFROM fedora:latest\n\n# Don't include container-selinux and remove\n# directories used by dnf that are just taking\n# up space.\nRUN yum -y install buildah fuse-overlayfs --exclude container-selinux; rm -rf \/var\/cache \/var\/log\/dnf* \/var\/log\/yum.*\n\n# Adjust storage.conf to enable Fuse storage.\nRUN sed -i -e 's|^#mount_program|mount_program|g' -e '\/additionalimage.*\/a \"\/var\/lib\/shared\",' \/etc\/containers\/storage.conf\n<\/code><\/pre>\n
\nI stedet for OverlayFS, der er implementeret p\u00e5 niveauet for v\u00e6rtens Linux-kerne, bruger vi inde i containeren programmet fuse-overlay<\/a><\/noindex>, da OverlayFS i \u00f8jeblikket kun kan montere, hvis det gives SYS_ADMIN-rettigheder via Linux-capabilities. Og vi \u00f8nsker at k\u00f8re vores Buildah-containere uden nogen root-rettigheder. Fuse-overlay fungerer ret hurtigt og har bedre ydeevne end storage-driveren VFS. V\u00e6r opm\u00e6rksom p\u00e5, at n\u00e5r man k\u00f8rer en Buildah-container, der bruger Fuse, er det n\u00f8dvendigt at give adgang til enhed \"\/dev\/fuse\".<\/p>\n
podman run --device \/dev\/fuse quay.io\/buildahctr ...\nRUN 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\n<\/code><\/pre>\n
\nDern\u00e6st opretter vi en mappe til yderligere lagringsomr\u00e5der. Container\/storage<\/a><\/noindex> underst\u00f8tter konceptet med at tilslutte yderligere skrivebeskyttede lagringsomr\u00e5der af billeder. For eksempel kan man konfigurere overlay storage-omr\u00e5de p\u00e5 \u00e9n maskine og derefter montere dette lager p\u00e5 en anden maskine via NFS og bruge billederne derfra uden at downloade dem via pull. Vi har brug for dette lager for at kunne tilslutte et eller andet lagringssted med billeder fra v\u00e6rten og bruge det inde i containeren.<\/p>\n
# Set up environment variables to note that this is\n# not starting with user namespace and default to\n# isolate the filesystem with chroot.\nENV _BUILDAH_STARTED_IN_USERNS=\"\" BUILDAH_ISOLATION=chroot\n<\/code><\/pre>\n
\nOg endelig, ved hj\u00e6lp af milj\u00f8variablen BUILDAH_ISOLATION, fort\u00e6ller vi, at Buildah-containeren som standard skal k\u00f8re med chroot-isolering. Yderligere isolering er ikke n\u00f8dvendig her, da vi allerede arbejder i en container. For at Buildah kan oprette sine egne containere med namespaces, kr\u00e6ves SYS_ADMIN-privilegiet, og for dette skal SELinux- og SECCOMP-reglerne lempes for containeren, hvilket strider imod vores ops\u00e6tning for at udf\u00f8re bygning fra en sikker container.<\/p>\n
K\u00f8rer Buildah inde i containeren<\/h3>\n
\nDen ovenfor n\u00e6vnte Buildah-containerbillede skema giver fleksibilitet til at variere m\u00e5derne at starte s\u00e5danne containere.<\/p>\n
Hastighed kontra sikkerhed<\/h4>\n
\nComputersikkerhed er altid et kompromis mellem hastigheden p\u00e5 processen og hvor meget beskyttelse der er bygget omkring den. Dette udsagn g\u00e6lder ogs\u00e5 ved opbygning af containere, s\u00e5 nedenfor vil vi se p\u00e5 mulighederne for dette kompromis.<\/p>\n
Den ovenfor beskrevne containerbillede vil opbevare sit lager i \/var\/lib\/containers. Derfor skal vi montere indholdet i denne mappe, og m\u00e5den vi g\u00f8r dette p\u00e5, vil have stor indflydelse p\u00e5 hastigheden ved opbygning af containerbilleder.<\/p>\n
Lad os overveje tre muligheder.<\/p>\n
Mulighed 1.<\/b> Hvis der kr\u00e6ves maksimal sikkerhed, kan der oprettes en s\u00e6rskilt mappe til hver container for containers\/image og tilsluttes den til containeren via volume-mount. Derudover kan kontekstmappen placeres i selve containeren, i mappen \/build:<\/p>\n
# mkdir \/var\/lib\/containers1\n# podman run -v .\/build:\/build:z -v \/var\/lib\/containers1:\/var\/lib\/containers:Z quay.io\/buildah\/stable\nbuildah  -t image1 bud \/build\n# podman run -v \/var\/lib\/containers1:\/var\/lib\/containers:Z quay.io\/buildah\/stable buildah  push  image1 registry.company.com\/myuser\n# rm -rf \/var\/lib\/containers1\n<\/code><\/pre>\n
\nSikkerhed.<\/i> At arbejde i en s\u00e5dan container giver Buildah maksimal sikkerhed: den f\u00e5r ingen root-rettigheder gennem capabilities, og alle SECOMP- og SELinux-begr\u00e6nsninger g\u00e6lder. En s\u00e5dan container kan endda k\u00f8re med isolering af User Namespace ved at tilf\u00f8je en mulighed som \u2014uidmap 0:100000:10000.<\/p>\n
Ydeevne.<\/i> Men ydeevnen her er minimal, da enhver billeder fra containerregistrene hver gang kopieres til v\u00e6rten, og caching virker slet ikke. N\u00e5r Buildah-containeren er f\u00e6rdig, skal den sende billedet til registreret og destruere indholdet p\u00e5 v\u00e6rten. N\u00e5r containerbilledet skal opbygges n\u00e6ste gang, skal det downloades igen fra registreret, da der p\u00e5 v\u00e6rten i mellemtiden ikke vil v\u00e6re noget tilbage.<\/p>\n
Mulighed 2.<\/b> Hvis der er brug for Docker-niveau-ydeevne, kan man montere container\/storage fra v\u00e6rten direkte ind i containeren.<\/p>\n
# 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\n# podman run -v \/var\/lib\/containers:\/var\/lib\/containers --security-opt label:disabled  quay.io\/buildah\/stable buildah push image2 registry.company.com\/myuser\n<\/code><\/pre>\n
\nSikkerhed.<\/i> Dette er den mindst sikre metode til at bygge containere, da containeren her har tilladelse til at \u00e6ndre lageret p\u00e5 v\u00e6rten, og den kan potentielt inds\u00e6tte et ondsindet billede i Podman eller CRI-O. Derudover kr\u00e6ver det, at SELinux-separationen deaktiveres, s\u00e5 processerne i Buildah-containeren kan interagere med lageret p\u00e5 v\u00e6rten. V\u00e6r opm\u00e6rksom p\u00e5, at denne mulighed stadig er bedre end Docker-socketen, da containeren er beskyttet af de resterende sikkerhedsfunktioner og ikke bare kan tage og k\u00f8re en hvilken som helst container p\u00e5 v\u00e6rten.<\/p>\n
Ydeevne.<\/i> Her er den maksimal, da caching udnyttes fuldt ud. Hvis Podman eller CRI-O allerede har downloadet det n\u00f8dvendige billede til v\u00e6rten, beh\u00f8ver Buildah-processen inde i containeren ikke at downloade det igen, og efterf\u00f8lgende bygninger baseret p\u00e5 dette billede kan ogs\u00e5 hente det n\u00f8dvendige fra cachen.<\/p>\n
Mulighed 3.<\/b> Essensen af denne metode er at kombinere flere billeder i et projekt med en f\u00e6lles mappe til containerbilleder.<\/p>\n
# mkdir \/var\/lib\/project3\n# podman run --security-opt label_level=s0:C100, C200 -v .\/build:\/build:z \n-v \/var\/lib\/project3:\/var\/lib\/containers:Z quay.io\/buildah\/stable buildah  -t image3 bud \/build\n# podman run --security-opt label_level=s0:C100, C200 \n-v \/var\/lib\/project3:\/var\/lib\/containers quay.io\/buildah\/stable buildah push image3  registry.company.com\/myuser\n<\/code><\/pre>\n
\nI dette eksempel sletter vi ikke projektmappen (\\\/var\\\/lib\\\/project3) mellem k\u00f8rslerne, s\u00e5 alle efterf\u00f8lgende bygninger inden for projektet drager fordel af cachen.<\/p>\n
Sikkerhed.<\/i> En mellemting mellem mulighederne 1 og 2. P\u00e5 den ene side har containerne ikke adgang til indholdet p\u00e5 v\u00e6rten og kan derfor ikke inds\u00e6tte noget d\u00e5rligt i Podman\/CRI-O's lager. P\u00e5 den anden side kan containeren inden for sit projekt blande sig i bygningen af andre containere.<\/p>\n
Ydeevne.<\/i> Her er den d\u00e5rligere end ved at bruge en f\u00e6lles cache p\u00e5 niveau med v\u00e6rten, da det ikke er muligt at bruge billeder, der allerede er downloadet tidligere ved hj\u00e6lp af Podman\/CRI-O. Men efter at Buildah har downloaded billedet, kan dette billede bruges i enhver efterf\u00f8lgende bygning inden for projektet.<\/p>\n
Yderligere lagre<\/h4>\n
\nVed containers\\\/storage<\/a><\/noindex> Der er en fantastisk ting som yderligere lagre (additional stores), som g\u00f8r det muligt for containermotorer at bruge eksterne lagre af billeder i read-only overlay mode, n\u00e5r der startes og bygges containere. I princippet kan man tilf\u00f8je et eller flere \"kun l\u00e6se\" lagre i filen storage.conf, s\u00e5 containermotoren kan lede efter det n\u00f8dvendige billede, n\u00e5r en container startes. Den vil kun downloade billedet fra registreret, hvis det ikke findes i noget af disse lagre. Containermotoren kan kun skrive i skrivebeskyttede lagre\u2026<\/p>\n
Hvis vi ruller op og ser p\u00e5 Dockerfile, som vi bruger til at bygge billedet quay.io\/buildah\/stable, s\u00e5 er der linjer som disse:<\/p>\n
# Adjust storage.conf to enable Fuse storage.\nRUN sed -i -e 's|^#mount_program|mount_program|g' -e '\/additionalimage.*\/a \"\/var\/lib\/shared\",' \/etc\/containers\/storage.conf\nRUN 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\n<\/code><\/pre>\n
\nI den f\u00f8rste linje modificerer vi \/etc\/containers\/storage.conf inde i containerbilledet, og instruerer storage-driveren om at bruge \"additionalimagestores\" i mappen \/var\/lib\/shared. I den n\u00e6ste linje opretter vi en f\u00e6lles mappe og tilf\u00f8jer et par lock-filer, for at undg\u00e5 klager fra containers\/storage. I princippet opretter vi blot et tomt lager for containerbilleder. <\/p>\n
Hvis man monterer containers\/storage et niveau over denne mappe, kan Buildah bruge billederne.<\/p>\n
Lad os nu vende tilbage til ovenst\u00e5ende Variant 2, hvor Buildah-containeren kan l\u00e6se og skrive til containers\/store p\u00e5 v\u00e6rter, og derfor opn\u00e5r maksimal ydeevne gennem caching af billeder p\u00e5 Podman\/CRI-O niveau, men giver minimum sikkerhed, da den kan skrive direkte til lagre. Og s\u00e5 kan vi tilf\u00f8je yderligere lagre og f\u00e5 det bedste fra to verdener.<\/p>\n
# mkdir \/var\/lib\/containers4\n# 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 \n buildah  -t image4 bud \/build\n# podman run -v \/var\/lib\/containers\/storage:\/var\/lib\/shared:ro  \n-v >\/var\/lib\/containers4:\/var\/lib\/containers:Z quay.io\/buildah\/stable buildah push image4  registry.company.com\/myuser\n# rm -rf \/var\/lib\/continers4\n<\/code><\/pre>\n
\nV\u00e6r opm\u00e6rksom p\u00e5, at \/var\/lib\/containers\/storage p\u00e5 v\u00e6rten er monteret i \/var\/lib\/shared inde i containeren i read-only mode. Derfor kan Buildah, mens den arbejder i containeren, bruge alle billeder, som tidligere er blevet downloadet af Podman\/CRI-O (hej, hastighed), men kan kun skrive til sit eget lager (hej, sikkerhed). V\u00e6r ogs\u00e5 opm\u00e6rksom p\u00e5, at dette g\u00f8res uden at deaktivere SELinux separation for containeren.<\/p>\n
Vigtig detalje<\/h4>\n
\nMan m\u00e5 under ingen omst\u00e6ndigheder slette nogen billeder fra det underliggende lager. Ellers kan Buildah-containeren falde ud.<\/p>\n
Og det er bestemt ikke alle fordelene<\/h4>\n
\nMulighederne for ekstra lagerpladser er ikke kun begr\u00e6nset til det ovenfor beskrevne scenarie. For eksempel kan man placere alle containerbilleder i et f\u00e6lles netv\u00e6rkslager og give adgang til dem for alle Buildah-containere. Antag, at vi har hundreder af billeder, som vores CI\/CD-system regelm\u00e6ssigt bruger til at bygge containerbilleder. Vi samler alle disse billeder p\u00e5 en enkelt host-lager og \u00e5bner derefter, ved hj\u00e6lp af foretrukne netv\u00e6rkslagermidler (NFS, Gluster, Ceph, ISCSI, S3\u2026), adgang til dette lager for alle Buildah- eller Kubernetes-noder.<\/p>\n
Nu er det nok at montere dette netv\u00e6rkslager i Buildah-containeren p\u00e5 \/var\/lib\/shared, og s\u00e5 \u2013 Buildah-containere beh\u00f8ver slet ikke at downloade billeder via pull. Dermed fjerner vi fasen for forudfyldning (pre-population) og er straks klar til at udrulle containere.<\/p>\n
Og selvf\u00f8lgelig kan dette bruges inden for et eksisterende Kubernetes-system eller containerinfrastruktur for at k\u00f8re og udf\u00f8re containere hvor som helst uden at downloade billeder via pull. Desuden, n\u00e5r containerregisteret modtager et push-anmodning om at uploade et opdateret billede, kan det automatisk sende dette billede til det f\u00e6lles netv\u00e6rkslager, hvor det straks bliver tilg\u00e6ngeligt for alle noder.<\/p>\n
St\u00f8rrelsen p\u00e5 containerbilleder kan nogle gange n\u00e5 mange gigabyte. Funktionaliteten af ekstra lager muligg\u00f8r, at man undg\u00e5r at klone s\u00e5danne billeder til noderne og g\u00f8r containeropstarten n\u00e6sten \u00f8jeblikkelig.<\/p>\n
Desuden arbejder vi i \u00f8jeblikket p\u00e5 en ny funktion til overlay volume mounts, som vil g\u00f8re opbygningen af containere endnu hurtigere.<\/p>\n
Konklusion<\/h3>\n
\nAt k\u00f8re Buildah inde i en container i et Kubernetes\/CRI-O, Podman eller endda Docker-milj\u00f8 er helt muligt, og det er desuden enkelt og meget sikrere end at bruge docker.socket. Vi har betydeligt \u00f8get fleksibiliteten i arbejdet med billeder, og nu kan du k\u00f8re dem p\u00e5 forskellige m\u00e5der for at opn\u00e5 den optimale balance mellem sikkerhed og ydeevne.<\/p>\n
Funktionaliteten af ekstra lager g\u00f8r det muligt at accelerere eller endda helt eliminere download af billeder til noder.
\n
Kilde: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u0412 \u0447\u0435\u043c \u043f\u0440\u0435\u043b\u0435\u0441\u0442\u044c \u0440\u0430\u0437\u0434\u0435\u043b\u0435\u043d\u0438\u044f \u0441\u0440\u0435\u0434\u044b \u0438\u0441\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 \u043d\u0430 \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0435 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u0430\u043b\u044c\u043d\u044b\u0435 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u044e\u0449\u0438\u0435? \u0412 \u0447\u0430\u0441\u0442\u043d\u043e\u0441\u0442\u0438, \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e \u044d\u0442\u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b \u043c\u043e\u0436\u043d\u043e \u043d\u0430\u0447\u0430\u0442\u044c \u043a\u043e\u043c\u0431\u0438\u043d\u0438\u0440\u043e\u0432\u0430\u0442\u044c, \u0447\u0442\u043e\u0431\u044b \u043e\u043d\u0438 \u0437\u0430\u0449\u0438\u0449\u0430\u043b\u0438 \u0434\u0440\u0443\u0433 \u0434\u0440\u0443\u0433\u0430. \u041c\u043d\u043e\u0433\u0438\u0445 \u043f\u0440\u0438\u0432\u043b\u0435\u043a\u0430\u0435\u0442 \u0438\u0434\u0435\u044f \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0442\u044c \u0441\u0431\u043e\u0440\u043a\u0443 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043d\u044b\u0445 OCI-\u043e\u0431\u0440\u0430\u0437\u043e\u0432 \u0432 \u0440\u0430\u043c\u043a\u0430\u0445 Kubernetes \u0438\u043b\u0438 \u043f\u043e\u0434\u043e\u0431\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u044b. \u0414\u043e\u043f\u0443\u0441\u0442\u0438\u043c, \u0443 \u043d\u0430\u0441 \u0435\u0441\u0442\u044c CI\/CD, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e \u0441\u043e\u0431\u0438\u0440\u0430\u0435\u0442 \u043e\u0431\u0440\u0430\u0437\u044b, \u0442\u043e\u0433\u0434\u0430 \u0447\u0442\u043e-\u0442\u043e \u0442\u0438\u043f\u0430 Red Hat OpenShift\/Kubernetes \u0431\u044b\u043b\u043e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":29093,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-38785","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Anbefalinger til at k\u00f8re Buildah inde i en container | ProHoster","description":"Hvad er fordelen ved at opdele containerudf\u00f8relsesmilj\u00f8et i separate v\u00e6rkt\u00f8jskomponenter?","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/rekomendatsii-po-zapusku-buildah-vnutri-kontejnera","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0420\u0435\u043a\u043e\u043c\u0435\u043d\u0434\u0430\u0446\u0438\u0438 \u043f\u043e \u0437\u0430\u043f\u0443\u0441\u043a\u0443 Buildah \u0432\u043d\u0443\u0442\u0440\u0438 \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u0430 | ProHoster","og:description":"\u0412 \u0447\u0435\u043c \u043f\u0440\u0435\u043b\u0435\u0441\u0442\u044c \u0440\u0430\u0437\u0434\u0435\u043b\u0435\u043d\u0438\u044f \u0441\u0440\u0435\u0434\u044b \u0438\u0441\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u044f \u043a\u043e\u043d\u0442\u0435\u0439\u043d\u0435\u0440\u043e\u0432 \u043d\u0430 \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0435 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u0430\u043b\u044c\u043d\u044b\u0435 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u044e\u0449\u0438\u0435?","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/rekomendatsii-po-zapusku-buildah-vnutri-kontejnera","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:25:55+00:00","article:modified_time":"2019-10-31T19:25:55+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"38785","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-23 23:24:21","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:03:14","updated":"2026-01-23 23:24:21","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/38785","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=38785"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/38785\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/29093"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=38785"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=38785"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=38785"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}