{"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\/de\/blog\/administrirovanie\/rekomendatsii-po-zapusku-buildah-vnutri-kontejnera","title":{"rendered":"Empfehlungen zum Start von Buildah innerhalb des Containers","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Was ist das Besondere an der Trennung der Ausf\u00fchrungsumgebung von Containern in separate Instrumente? Insbesondere, dass diese Werkzeuge kombiniert werden k\u00f6nnen, um sich gegenseitig zu sch\u00fctzen.<\/p>\n

\"Empfehlungen
\n
\nViele sind an der Idee interessiert, OCI-Container-Images innerhalb von Kubernetes<\/a><\/noindex> oder einem \u00e4hnlichen System zu erstellen. Angenommen, wir haben ein CI\/CD, das st\u00e4ndig Images baut, dann etwas wie -Plattform bereitstellt. Weitere Informationen \u00fcber die Funktionsweise finden Sie<\/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. Wir haben vor einigen Jahren bereits gezeigt<\/a><\/noindex>, dass dies sehr unsicher ist, tats\u00e4chlich ist es sogar schlimmer, als einem root oder sudo ohne Passwort zu geben.
\n<\/a><\/noindex>
\nDeshalb versuchen die Leute st\u00e4ndig, Buildah in einem Container auszuf\u00fchren. Kurz gesagt, wir haben erstellt Beispiel<\/a><\/noindex> wie, unserer Meinung nach, Buildah am besten innerhalb eines Containers ausgef\u00fchrt wird, und haben die entsprechenden Images auf quay.io\/buildah<\/a><\/noindex>. Lass uns anfangen\u2026<\/p>\n

Einstellungen<\/h3>\n

\nDiese Images wurden aus Dockerfiles erstellt, die im Buildah-Repository im Ordner buildahimage<\/a><\/noindex>.
\nHier betrachten wir die stabile Version des Dockerfiles<\/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
\nAnstelle von OverlayFS, das auf der Host-Linux-Kernel-Ebene implementiert ist, verwenden wir innerhalb des Containers das Programm fuse-overlay<\/a><\/noindex>, da OverlayFS derzeit nur dann montieren kann, wenn sie die Berechtigungen SYS_ADMIN \u00fcber Linux-Capabilities erh\u00e4lt. Und wir m\u00f6chten unsere Buildah-Container ohne root-Berechtigungen ausf\u00fchren. Fuse-overlay funktioniert recht schnell und bietet bessere Leistung als der Storage-Treiber VFS. Beachte, dass beim Starten eines Buildah-Containers, der Fuse verwendet, das Ger\u00e4t \/dev\/fuse bereitgestellt werden muss.<\/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
\nAls n\u00e4chstes erstellen wir ein Verzeichnis f\u00fcr zus\u00e4tzliche Speicher. Container\/storage<\/a><\/noindex> unterst\u00fctzt das Konzept des Anbindens zus\u00e4tzlicher schreibgesch\u00fctzter Speicher f\u00fcr Images. Beispielsweise kann ein Overlay-Speicherbereich auf einer Maschine konfiguriert und dann \u00fcber NFS auf einer anderen Maschine gemountet werden, um die Images ohne Download durch Pull zu verwenden. Wir ben\u00f6tigen diesen Speicher, um in einem Container auf einen Host-Image-Speicher als Volume zugreifen zu k\u00f6nnen.<\/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
\nUnd schlie\u00dflich, indem wir die Umgebungsvariable BUILDAH_ISOLATION verwenden, geben wir an, dass standardm\u00e4\u00dfig der Buildah-Container mit chroot-Isolation gestartet werden soll. Zus\u00e4tzliche Isolation ist hier nicht erforderlich, da wir bereits in einem Container arbeiten. Damit Buildah eigene Container mit Namensraum-Trennung erstellen kann, ist die SYS_ADMIN-Befugnis erforderlich, und daf\u00fcr m\u00fcssen die SELinux- und SECCOMP-Richtlinien f\u00fcr den Container gelockert werden, was unserer Installation widerspricht, die den Aufbau aus einem sicheren Container heraus durchf\u00fchren soll.<\/p>\n
Starten wir Buildah innerhalb des Containers<\/h3>\n
\nDas oben beschriebene Schema des Buildah-Container-Images erm\u00f6glicht eine flexible Variierung der Startmethoden solcher Container.<\/p>\n
Geschwindigkeit gegen Sicherheit<\/h4>\n
\nComputersicherheit ist immer ein Kompromiss zwischen der Geschwindigkeit des Prozesses und der Menge an Schutz, die darum herum aufgebaut ist. Diese Aussage gilt auch f\u00fcr das Erstellen von Containern, weshalb wir im Folgenden die M\u00f6glichkeiten eines solchen Kompromisses betrachten werden.<\/p>\n
Das oben beschriebene Container-Image wird seinen Speicher in \/var\/lib\/containers haben. Daher m\u00fcssen wir den Inhalt in diesen Ordner einh\u00e4ngen, und die Art und Weise, wie wir dies tun, wird sich erheblich auf die Geschwindigkeit des Baus von Container-Images auswirken.<\/p>\n
Betrachten wir drei M\u00f6glichkeiten.<\/p>\n
Option 1.<\/b> Wenn maximale Sicherheit erforderlich ist, kann f\u00fcr jeden Container ein eigenes Verzeichnis f\u00fcr containers\/image erstellt und \u00fcber Volume-Mount an den Container angeschlossen werden. Dar\u00fcber hinaus kann das Kontextverzeichnis im Container selbst im Verzeichnis \/build platziert werden:<\/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
\nSicherheit.<\/i> Ein in einem solchen Container arbeitendes Buildah bietet maximale Sicherheit: Es erh\u00e4lt keine Root-Rechte durch die Mittel von Capabilities, und es gelten alle SECOMP- und SELinux-Einschr\u00e4nkungen. Ein solcher Container kann sogar mit der Isolation des User Namespace gestartet werden, indem man eine Option wie \u2014uidmap 0:100000:10000 hinzuf\u00fcgt.<\/p>\n
Leistung.<\/i> Die Leistung ist hier jedoch minimal, da jede Abbildung aus Container-Registrierungen jedes Mal auf den Host kopiert wird und Caching \u00fcberhaupt nicht funktioniert. Wenn Buildah seine Arbeit beendet, muss der Container das Image in das Repository hochladen und den Inhalt auf dem Host l\u00f6schen. Wenn das Container-Image das n\u00e4chste Mal erstellt wird, muss es erneut aus dem Repository heruntergeladen werden, da zu diesem Zeitpunkt auf dem Host nichts mehr vorhanden sein wird.<\/p>\n
Option 2.<\/b> Wenn die Leistung auf Docker-Niveau ben\u00f6tigt wird, kann der container\/storage des Hosts direkt im Container eingebunden werden.<\/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
\nSicherheit.<\/i> Dies ist die sicherheitsm\u00e4\u00dfig schw\u00e4chste Methode zum Erstellen von Containern, da der Container hier berechtigt ist, das Speicherverzeichnis auf dem Host zu modifizieren, und potenziell ein b\u00f6sartiges Image an Podman oder CRI-O einspeisen kann. Dar\u00fcber hinaus muss die SELinux-Trennung deaktiviert werden, damit die Prozesse im Buildah-Container mit dem Speicher des Hosts interagieren k\u00f6nnen. Beachten Sie, dass diese Option immer noch besser ist als der Docker-Socket, da der Container durch die verbleibenden Sicherheitsfunktionen blockiert wird und nicht einfach einen beliebigen Container auf dem Host starten kann.<\/p>\n
Leistung.<\/i> Hier ist sie maximal, da das Caching vollst\u00e4ndig genutzt wird. Wenn Podman oder CRI-O das ben\u00f6tigte Image bereits auf dem Host heruntergeladen haben, muss der Buildah-Prozess im Container es nicht erneut herunterladen, und nachfolgende Builds basierend auf diesem Image k\u00f6nnen ebenfalls das N\u00f6tige aus dem Cache beziehen.<\/p>\n
Option 3.<\/b> Das Wesen dieses Verfahrens besteht darin, mehrere Images zu einem Projekt mit einem gemeinsamen Verzeichnis f\u00fcr Container-Images zu kombinieren.<\/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
\nIn diesem Beispiel l\u00f6schen wir das Projektverzeichnis (\/var\/lib\/project3) zwischen den Ausf\u00fchrungen nicht, sodass alle nachfolgenden Builds im Rahmen des Projekts von den Vorteilen des Caching profitieren.<\/p>\n
Sicherheit.<\/i> Eine Art Mischung zwischen den Optionen 1 und 2. Einerseits haben die Container keinen Zugang zum Inhalt auf dem Host und k\u00f6nnen dementsprechend nichts Schlechtes im Podman\/CRI-O-Image-Speicher einspeisen. Andererseits kann der Container im Rahmen seines Projekts in die Erstellung anderer Container eingreifen.<\/p>\n
Leistung.<\/i> Hier ist die Situation schlechter als bei der Verwendung eines gemeinsamen Caches auf Host-Ebene, da Bilder, die zuvor mit Podman\/CRI-O heruntergeladen wurden, nicht verwendet werden k\u00f6nnen. Nachdem Buildah jedoch ein Image heruntergeladen hat, kann dieses in allen nachfolgenden Builds im Rahmen des Projekts verwendet werden.<\/p>\n
Zus\u00e4tzliche Speicher<\/h4>\n
\nDer containers\/storage<\/a><\/noindex> Es gibt so etwas Tolles wie zus\u00e4tzliche Speicher (additional stores), dank dem Container-Engines bei der Bereitstellung und dem Erstellen von Containern externe Speicher f\u00fcr Images im read-only Overlay-Modus nutzen k\u00f6nnen. Im Grunde genommen kann in die Datei storage.conf ein oder mehrere \"Nur-Lesen\"-Speicher hinzugef\u00fcgt werden, so dass der Container-Engine beim Start des Containers in diesen nach dem ben\u00f6tigten Image sucht. Dabei l\u00e4dt er das Image nur aus dem Registry herunter, wenn er es in keinem dieser Speicher findet. Der Container-Engine kann nur in schreibbare Speicher schreiben...<\/p>\n
Wenn wir nach oben scrollen und die Dockerfile ansehen, die wir zum Erstellen des Images quay.io\/buildah\/stable verwenden, finden wir folgende Zeilen:<\/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
\nIn der ersten Zeile modifizieren wir \/etc\/containers\/storage.conf innerhalb des Container-Images und sagen dem Storage-Treiber, dass er \"additionalimagestores\" im Ordner \/var\/lib\/shared verwenden soll. In der n\u00e4chsten Zeile erstellen wir einen gemeinsamen Ordner und f\u00fcgen ein paar Lock-Dateien hinzu, um Konflikte mit containers\/storage zu vermeiden. Im Grunde genommen erstellen wir einfach einen leeren Container-Image-Speicher. <\/p>\n
Wenn containers\/storage einen Level \u00fcber diesem Ordner gemountet wird, kann Buildah die Images verwenden.<\/p>\n
Kommen wir nun zur\u00fcck zur zuvor betrachteten Variante 2, wenn der Buildah-Container in containers\/store auf Hosts lesen und schreiben kann und somit maximale Leistung durch Caching der Images auf Podman\/CRI-O-Ebene erzielt, aber nur minimale Sicherheit bietet, da er direkt in die Speicher schreiben kann. Und jetzt f\u00fcgen wir hier zus\u00e4tzliche Speicher hinzu und erhalten das Beste aus beiden Welten.<\/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
\nBeachten Sie, dass \/var\/lib\/containers\/storage des Hosts im Container in \/var\/lib\/shared im read-only Modus gemountet ist. Daher kann Buildah im Container alle zuvor mit Podman\/CRI-O heruntergeladenen Images verwenden (Hallo, Geschwindigkeit), kann jedoch dabei nur in seinen eigenen Speicher schreiben (Hallo, Sicherheit). Beachten Sie auch, dass dies ohne Deaktivierung der SELinux-Trennung f\u00fcr den Container geschieht.<\/p>\n
Wichtiger Hinweis<\/h4>\n
\nEs d\u00fcrfen keinesfalls Images aus dem darunter liegenden Speicher gel\u00f6scht werden. Andernfalls k\u00f6nnte der Buildah-Container abst\u00fcrzen.<\/p>\n
Und das sind l\u00e4ngst nicht alle Vorteile<\/h4>\n
\nDie M\u00f6glichkeiten zus\u00e4tzlicher Speicherl\u00f6sungen beschr\u00e4nken sich nicht nur auf das oben beschriebene Szenario. Zum Beispiel k\u00f6nnen alle Container-Images in einem gemeinsamen Netzwerk-Storage abgelegt werden, auf das alle Buildah-Container Zugriff haben. Angenommen, wir haben Hunderte von Images, die unser CI\/CD-System regelm\u00e4\u00dfig zum Erstellen von Container-Images verwendet. Wir b\u00fcndeln all diese Images auf einem bestimmten Host-Speicher und gew\u00e4hren dann, unter Verwendung bevorzugter Netzwerkspeicherl\u00f6sungen (NFS, Gluster, Ceph, ISCSI, S3\u2026), allen Buildah- oder Kubernetes-Nodes Zugriff auf diesen Speicher.<\/p>\n
Jetzt reicht es aus, diesen Netzwerkspeicher im Buildah-Container unter \/var\/lib\/shared zu mounten, und schon m\u00fcssen die Buildah-Container keine Images mehr \u00fcber Pull herunterladen. Damit f\u00e4llt die Phase der Vorbef\u00fcllung (Pre-Population) weg, und wir sind sofort bereit, die Container auszurollen.<\/p>\n
Und nat\u00fcrlich kann dies im Rahmen eines bestehenden Kubernetes-Systems oder einer Container-Infrastruktur genutzt werden, um Container \u00fcberall auszuf\u00fchren und zu betreiben, ohne Images \u00fcber Pull herunterzuladen. Dar\u00fcber hinaus kann das Container-Registry, das einen Push-Befehl zum Hochladen eines aktualisierten Images erh\u00e4lt, dieses Image automatisch in den gemeinsamen Netzwerkspeicher senden, wo es sofort f\u00fcr alle Knoten verf\u00fcgbar wird.<\/p>\n
Die Gr\u00f6\u00dfen von Container-Images k\u00f6nnen manchmal mehrere Gigabyte erreichen. Die Funktionalit\u00e4t zus\u00e4tzlicher Speicherorte erm\u00f6glicht es, auf die Klonierung solcher Images bei den Knoten zu verzichten und macht das Starten von Containern nahezu sofort.<\/p>\n
Dar\u00fcber hinaus arbeiten wir derzeit an einer neuen Funktion f\u00fcr Overlay-Volume-Mounts, die den Aufbau von Containern noch schneller machen wird.<\/p>\n
Fazit<\/h3>\n
\nEs ist durchaus m\u00f6glich, Buildah innerhalb eines Containers in einer Umgebung mit Kubernetes\/CRI-O, Podman oder sogar Docker auszuf\u00fchren. Au\u00dferdem ist es einfach und deutlich sicherer als die Verwendung von docker.socket. Wir haben die Flexibilit\u00e4t bei der Arbeit mit Images erheblich erh\u00f6ht, und jetzt k\u00f6nnen Sie diese auf verschiedene Weisen starten, um das optimale Gleichgewicht zwischen Sicherheit und Leistung zu erreichen.<\/p>\n
Die Funktionalit\u00e4t zus\u00e4tzlicher Speicherorte erm\u00f6glicht es, das Herunterladen von Images auf die Knoten zu beschleunigen oder sogar vollst\u00e4ndig zu eliminieren.
\n
Quelle: 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\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\udd47Empfehlungen zum Starten von Buildah innerhalb eines Containers | ProHoster","description":"Was ist der Vorteil der Trennung der Containerausf\u00fchrungsumgebung in separate instrumentelle Komponenten?","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/rekomendatsii-po-zapusku-buildah-vnutri-kontejnera","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/38785","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=38785"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/38785\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/29093"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=38785"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=38785"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=38785"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}