{"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 f\u00fcr den Start von Buildah innerhalb eines Containers","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Was ist das Besondere daran, die Ausf\u00fchrungsumgebung von Containern in separate Werkzeugkomponenten zu unterteilen? Besonders, dass man diese Werkzeuge miteinander kombinieren kann, um sich gegenseitig zu sch\u00fctzen.<\/p>\n

\"Empfehlungen
\n
\nViele ziehen die Idee an, OCI-Container-Images im Rahmen von Kubernetes<\/a><\/noindex> oder einem \u00e4hnlichen System zu erstellen. Angenommen, wir haben CI\/CD, das kontinuierlich Images erstellt, dann w\u00e4re etwas wie 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. Wir haben bereits vor einigen Jahren 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 Nummer 00 oder<\/a><\/noindex> eine Vorgehensweise entworfen, von der wir glauben, dass sie am besten geeignet ist, um Buildah innerhalb eines Containers zu starten, und haben die entsprechenden Images auf quay.io\/buildah<\/a><\/noindex>. Lassen Sie uns anfangen\u2026<\/p>\n

Konfiguration<\/h3>\n

\nDiese Images wurden aus Dockerfiles erstellt, die im Buildah-Repository im Ordner buildahimage<\/a><\/noindex>.
\nzu finden sind. Hier betrachten wir<\/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
\ndie stabile Version des Dockerfiles. Anstelle von OverlayFS, das auf der Ebene des Host-Linux-Kernels implementiert ist, verwenden wir im Container das Programm<\/a><\/noindex>fuse-overlay<\/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 Speicherorte. Container\/storage<\/a><\/noindex> unterst\u00fctzt das Konzept, zus\u00e4tzliche schreibgesch\u00fctzte Speicherorte f\u00fcr Images zu verbinden. Zum Beispiel kann man einen Overlay-Speicherbereich auf einem Rechner einrichten und dann dieses Speicherverzeichnis via NFS auf einem anderen Rechner bereitstellen und die Images daraus verwenden, ohne sie \u00fcber Pull herunterzuladen. Wir ben\u00f6tigen dieses Speicherverzeichnis, um ein Image-Volume vom Host anzuh\u00e4ngen und innerhalb des Containers zu verwenden.<\/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
\nSchlie\u00dflich geben wir mit der Umgebungsvariable BUILDAH_ISOLATION 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 seine eigenen Container mit Namensraumtrennung erstellt, ist die SYS_ADMIN-Berechtigung erforderlich, was bedeutet, dass die SELinux- und SECCOMP-Regeln f\u00fcr den Container gelockert werden m\u00fcssen, was im Widerspruch zu unserem Ansatz steht, Builds aus einem sicheren Container durchzuf\u00fchren.<\/p>\n
Wir f\u00fchren Buildah im Container aus<\/h3>\n
\nDas oben dargestellte Schema des Buildah-Container-Images erm\u00f6glicht flexible Variationen der Startmethoden solcher Container.<\/p>\n
Geschwindigkeit gegen Sicherheit<\/h4>\n
\nComputersicherheit ist stets ein Kompromiss zwischen der Ausf\u00fchrungsgeschwindigkeit und dem Schutzniveau, das dar\u00fcbergelegt wird. Diese Aussage gilt auch beim Erstellen von Containern, deshalb betrachten wir im Folgenden die Optionen f\u00fcr diesen Kompromiss.<\/p>\n
Das oben besprochene Container-Image speichert seine Daten in \/var\/lib\/containers. Daher m\u00fcssen wir die Inhalte in diesen Ordner einbinden, und die Methode, wie wir dies tun, hat erheblichen Einfluss auf die Geschwindigkeit des Buildprozesses der Container-Images.<\/p>\n
Betrachten wir drei Optionen.<\/p>\n
Option 1.<\/b> Wenn maximale Sicherheit gefordert ist, kann f\u00fcr jeden Container ein eigenes Verzeichnis f\u00fcr containers\/image erstellt und \u00fcber einen Volume-Mount mit dem Container verbunden werden. Zudem kann das Kontextverzeichnis direkt im Container im Ordner \/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 laufendes Buildah bietet maximale Sicherheit: Es werden ihm keine Root-Rechte \u00fcber F\u00e4higkeiten gew\u00e4hrt, und es unterliegt allen Einschr\u00e4nkungen von SECOMP und SELinux. Ein solcher Container kann sogar mit Benutzer-Namensraum-Isolation gestartet werden, indem man eine Option wie \u2014uidmap 0:100000:10000 hinzuf\u00fcgt.<\/p>\n
Leistung.<\/i> Die Leistung ist hier minimal, da alle Images aus Container-Repositories jedes Mal auf den Host kopiert werden und das Caching \u00fcberhaupt nicht funktioniert. Nach der Nutzung muss der Buildah-Container das Image ins Repository hochladen und den Inhalt auf dem Host l\u00f6schen. Wenn das Container-Image beim n\u00e4chsten Mal wieder aufgebaut 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 Sie Leistung auf Docker-Niveau ben\u00f6tigen, k\u00f6nnen Sie den container\/storage des Hosts direkt im Container einbinden.<\/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 am wenigsten sichere Methode zum Erstellen von Containern, da der Container hier berechtigt ist, das Storage auf dem Host zu ver\u00e4ndern, und potenziell kann er Podman oder CRI-O ein b\u00f6sartiges Image unterjubeln. Dar\u00fcber hinaus muss die SELinux-Trennung deaktiviert werden, damit die Prozesse im Buildah-Container mit dem Storage auf dem Host interagieren k\u00f6nnen. Beachten Sie, dass diese Option dennoch besser als der Docker-Socket ist, 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 es maximal, da das Caching vollst\u00e4ndig genutzt wird. Wenn Podman oder CRI-O das erforderliche Image bereits auf den Host heruntergeladen haben, muss der Buildah-Prozess innerhalb des Containers es nicht erneut herunterladen, und auch sp\u00e4tere Builds, die auf diesem Image basieren, k\u00f6nnen das Ben\u00f6tigte aus dem Cache abrufen.<\/p>\n
Option 3.<\/b> Die Idee dieser Methode besteht darin, mehrere Images zu einem Projekt mit einem gemeinsamen Ordner 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 den Projektordner (\/var\/lib\/project3) zwischen den Starts nicht, sodass alle nachfolgenden Builds im Rahmen des Projekts von den Vorteilen des Caching profitieren.<\/p>\n
Sicherheit.<\/i> Etwas zwischen Option 1 und 2. Einerseits haben die Container keinen Zugriff auf den Inhalt des Hosts und k\u00f6nnen daher nichts Schlechtes in das Image-Repository von Podman\/CRI-O einschleusen. Andererseits kann der Container im Rahmen seines Projekts in den Build anderer Container eingreifen.<\/p>\n
Leistung.<\/i> Hier ist es schlechter als bei der Verwendung des gemeinsam genutzten Caches auf Hostebene, da bereits zuvor heruntergeladene Images mit Podman\/CRI-O nicht verwendet werden k\u00f6nnen. Nachdem Buildah das Image jedoch heruntergeladen hat, kann es in allen nachfolgenden Builds innerhalb des Projekts verwendet werden.<\/p>\n
Zus\u00e4tzliche Repositories<\/h4>\n
\nU containers\/storage<\/a><\/noindex> Es gibt diese gro\u00dfartige Funktion namens zus\u00e4tzliche Repositories (additional stores), die es Container-Engines erm\u00f6glicht, beim Starten und Erstellen von Containern externe Image-Repositories im schreibgesch\u00fctzten Overlay-Modus zu verwenden. Im Grunde genommen k\u00f6nnen in die Datei storage.conf ein oder mehrere \"nur zur Lekt\u00fcre\"-Repositories hinzugef\u00fcgt werden, so dass die Container-Engine beim Start des Containers in diesen Repositories nach dem ben\u00f6tigten Image suchen kann. Das Image wird nur aus dem Registry heruntergeladen, wenn es in keinem dieser Repositories gefunden wird. Die Container-Engine kann nur in f\u00fcr das Schreiben zug\u00e4ngliche Repositories schreiben...<\/p>\n
Wenn Sie nach oben scrollen und sich das Dockerfile ansehen, das wir zum Erstellen des Images quay.io\/buildah\/stable verwenden, finden Sie dort 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 weisen den Storage-Treiber an, die \"additionalimagestores\" im Verzeichnis \/var\/lib\/shared zu verwenden. In der folgenden Zeile erstellen wir einen gemeinsamen Ordner und f\u00fcgen einige Lock-Dateien hinzu, um Konflikte mit containers\/storage zu vermeiden. Im Grunde genommen schaffen wir einfach einen leeren Speicher f\u00fcr Container-Images. <\/p>\n
Wenn man containers\/storage \u00fcber diesem Ordner einbindet, kann Buildah die Images nutzen.<\/p>\n
Jetzt kehren wir zu dem oben besprochenen Szenario 2 zur\u00fcck, in dem der Buildah-Container in containers\/store auf Hosts lesen und schreiben kann und somit maximale Leistung durch die Zwischenspeicherung der Images auf Podman\/CRI-O-Ebene erzielt, jedoch minimalen Schutz bietet, da er direkt in die Speicher schreiben kann. Lassen Sie uns nun zus\u00e4tzliche Speicherorte hinzuf\u00fcgen und das Beste aus beiden Welten erhalten.<\/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
\nBitte beachten Sie, dass das Verzeichnis \/var\/lib\/containers\/storage des Hosts im Container unter \/var\/lib\/shared im Nur-Lese-Modus eingebunden ist. Daher kann Buildah im Container auf alle zuvor heruntergeladenen Images von Podman\/CRI-O zugreifen (Hallo, Geschwindigkeit), aber es kann nur in seinen eigenen Speicher schreiben (Hallo, Sicherheit). Auch ist zu beachten, dass dies ohne Deaktivierung der SELinux-Trennung f\u00fcr den Container erfolgt.<\/p>\n
Wichtiger Hinweis<\/h4>\n
\nEs sollten auf keinen Fall irgendwelche Images aus dem zugrunde liegenden Speicher entfernt werden. Andernfalls kann der Buildah-Container abst\u00fcrzen.<\/p>\n
Und das sind l\u00e4ngst nicht alle Vorteile<\/h4>\n
\nDie M\u00f6glichkeiten zus\u00e4tzlicher Speichersysteme beschr\u00e4nken sich nicht nur auf das oben beschriebene Szenario. Beispielsweise k\u00f6nnen alle Container-Images in einem gemeinsamen Netzwerk-Speicher abgelegt und allen Buildah-Containern Zugang gew\u00e4hrt werden. Angenommen, wir haben Hunderte von Images, die unser CI\/CD-System regelm\u00e4\u00dfig zur Erstellung von Container-Images verwendet. Wir konzentrieren all diese Images auf einem einzigen Host-Speicher und er\u00f6ffnen dann unter Verwendung bevorzugter Netzwerk-Speichermethoden (NFS, Gluster, Ceph, ISCSI, S3\u2026) den gemeinsamen Zugang zu diesem Speicher f\u00fcr alle Buildah- oder Kubernetes-Knoten.<\/p>\n
Jetzt muss dieses Netzwerkspeicher lediglich in den Buildah-Container unter \/var\/lib\/shared eingebunden werden \u2013 und das war's. Die Buildah-Container m\u00fcssen die Images nicht mehr \u00fcber Pull herunterladen. Damit entf\u00e4llt die Phase der Vorbef\u00fcllung, und wir k\u00f6nnen sofort mit dem Rollout der Container beginnen.<\/p>\n
Nat\u00fcrlich kann dies innerhalb des bestehenden Kubernetes-Systems oder der Container-Infrastruktur verwendet werden, um Container \u00fcberall auszuf\u00fchren, ohne Images \u00fcber Pull herunterzuladen. Dar\u00fcber hinaus kann das Container-Registry, das einen Push-Anruf zum Hochladen eines aktualisierten Images erh\u00e4lt, dieses Image automatisch in einen gemeinsamen Netzwerkspeicher senden, wo es sofort f\u00fcr alle Nodes verf\u00fcgbar ist.<\/p>\n
Die Gr\u00f6\u00dfen von Container-Images k\u00f6nnen manchmal mehrere Gigabyte erreichen. Die Funktion zus\u00e4tzlicher Speicher erm\u00f6glicht es, solche Images nicht auf jeder Node zu klonen, was den Start von Containern nahezu sofort macht.<\/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 Kubernetes\/CRI-O-, Podman- oder sogar Docker-Umgebung auszuf\u00fchren. Dar\u00fcber hinaus ist es einfach und viel sicherer, als docker.socket zu verwenden. Wir haben die Flexibilit\u00e4t bei der Arbeit mit Images erheblich verbessert, sodass Sie sie nun auf verschiedene Weise ausf\u00fchren k\u00f6nnen, um ein optimales Gleichgewicht zwischen Sicherheit und Leistung zu erzielen.<\/p>\n
Die Funktionalit\u00e4t zus\u00e4tzlicher Speicherl\u00f6sungen erm\u00f6glicht es, den Download von Images auf 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 Ausf\u00fchren von Buildah innerhalb eines Containers | ProHoster","description":"Was ist der Vorteil der Trennung der Laufzeitumgebung von Containern in separate Instrumente? Insbesondere, dass diese Werkzeuge kombiniert werden k\u00f6nnen, um sich gegenseitig zu sch\u00fctzen. Viele finden die Idee, OCI-Container-Images innerhalb von Kubernetes oder einem \u00e4hnlichen System zu bauen, ansprechend. Angenommen, wir haben eine CI\/CD-Pipeline, die kontinuierlich Images erstellt, dann w\u00e4re etwas wie Red Hat OpenShift\/Kubernetes ideal.","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? \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","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"},"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}]}}