Docker应承构建、运行、拉
它的成果遵循与Podman沟通的蹊径,是无保卫措施和无根的,而且可以天生OCI兼容的镜像,可以确保你的镜像与Docker构建镜像的运行方法沟通。除此之外,Buildah还提供了对图像层的更风雅的节制,应承将很多变动提交到单个层中。与Docker对比,Buildah构建的镜像是特定于用户的,因此只能列出本身构建的镜像。 那么,既然Buildah已经包括在podman CLI中,为什么还要行使单独的Buildah CLI?缘故起因在于,buildahcli是podman build中包括的呼吁的超集,也许不必要打仗buildah CLI,可是通过行使它,也许还会发明一些特殊有效的特征。 可以看一个小型进程展示: ~ $ buildah bud-f Dockerfile . ~ $ buildah from alpine:latest # Create starting container - equivalentto "FROM alpine:latest" Getting image source signatures Copying blobdf20fa9351a1 done Copying configa24bb40132 done Writing manifest toimage destination Storing signatures alpine-working-container # Name of the temporary container ~ $ buildah runalpine-working-container -- apk add --update --no-cache python3 # equivalent to "RUN apk add--update --no-cache python3" fetch fetch ... ~ $ buildahcommit alpine-working-container my-final-image # Create final image Getting image source signatures Copying blob50644c29ef5a skipped: already exists Copying blob362b9ae56246 done Copying config1ff90ec2e2 done Writing manifest toimage destination Storing signatures 1ff90ec2e26e7c0a6b45b2c62901956d0eda138fa6093d8cbb29a88f6b95124c ~# buildah images REPOSITORY TAG IMAGE ID CREATED SIZE localhost/my-final-imagelatest 1ff90ec2e26e 22 seconds ago 51.4 MB 从上面的剧本可知,可以仅行使buildah bud来构建镜像,个中bud代表行使Dockerfile举办构建,可是还可以行使更多的剧本化要领,通过Buildahs的from、run和copy,这与Dockerfile中的呼吁等效。 接下来是Google的Kaniko。Kanik也与Dockerfile构建容器镜像,相同于Buildah,它也不必要保卫历程。其与Buildah的首要区别在于,Kaniko更专注于在Kubernetes中构建镜像。 Kanik行使gcr.io/kaniko-project/executor作为镜像运行,这对付Kubernetes故意义,但对付当地构建而言并不利便,且无法到达目标,由于必要行使Docker运行Kaniko镜像来构建新镜像。 话虽云云,假如正在探求用于在Kubernetes集群中构建镜像的器材(譬喻在CI/CD管道中),无保卫历程而且(大概)更安详,Kaniko也许是一个不错的选择。 (编辑:湖南网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |