1buildah-bud(1) General Commands Manual buildah-bud(1)
2
6 buildah-bud - Build an image using instructions from Dockerfiles.
7
10 buildah build-using-dockerfile [options] context
11 buildah bud [options] context
14 bud is an alias for build-using-dockerfile.
17
20 Builds an image using instructions from one or more Dockerfiles and a
21 specified build context directory.
22 The build context directory can be specified as the http(s) URL of an
25 archive, git repository or Dockerfile.
26 Dockerfiles ending with a ".in" suffix will be preprocessed via CPP(1).
29 This can be useful to decompose Dockerfiles into several reusable parts
30 that can be used via CPP's #include directive. Notice, a Dockerfile.in
31 file can still be used by other tools when manually preprocessing them
32 via cpp -E.
33 When the URL is an archive, the contents of the URL is downloaded to a
36 temporary location and extracted before execution.
37 When the URL is an Dockerfile, the Dockerfile is downloaded to a tempo‐
40 rary location.
41 When a Git repository is set as the URL, the repository is cloned
44 locally and then set as the context.
45
48 --add-host=[]
49 Add a custom host-to-IP mapping (host:ip)
52 Add a line to /etc/hosts. The format is hostname:ip. The --add-host
55 option can be set multiple times.
56 --annotation annotation
59 Add an image annotation (e.g. annotation=value) to the image metadata.
62 Can be used multiple times.
63 Note: this information is not present in Docker image formats, so it is
66 discarded when writing images in Docker formats.
67 --authfile path
70 Path of the authentication file. Default is ${XDG_RUNTIME_DIR}/contain‐
73 ers/auth.json, which is set using buildah login. If the authorization
74 state is not found there, $HOME/.docker/config.json is checked, which
75 is set using docker login.
76 --build-arg arg=value
79 Specifies a build argument and its value, which will be interpolated in
82 instructions read from the Dockerfiles in the same way that environment
83 variables are, but which will not be added to environment variable list
84 in the resulting image's configuration.
85 --cache-from
88 Images to utilise as potential cache sources. Buildah does not cur‐
91 rently support caching so this is a NOOP.
92 --cap-add=CAP_xxx
95 When executing RUN instructions, run the command specified in the
98 instruction with the specified capability added to its capability set.
99 Certain capabilities are granted by default; this option can be used to
100 add more.
101 --cap-drop=CAP_xxx
104 When executing RUN instructions, run the command specified in the
107 instruction with the specified capability removed from its capability
108 set. The CAP_AUDIT_WRITE, CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_FOWNER,
109 CAP_FSETID, CAP_KILL, CAP_MKNOD, CAP_NET_BIND_SERVICE, CAP_SETFCAP,
110 CAP_SETGID, CAP_SETPCAP, CAP_SETUID, and CAP_SYS_CHROOT capabilities
111 are granted by default; this option can be used to remove them.
112 If a capability is specified to both the --cap-add and --cap-drop
115 options, it will be dropped, regardless of the order in which the
116 options were given.
117 --cert-dir path
120 Use certificates at path (*.crt, *.cert, *.key) to connect to the reg‐
123 istry. Default certificates directory is /etc/containers/certs.d.
124 --cgroup-parent=""
127 Path to cgroups under which the cgroup for the container will be cre‐
130 ated. If the path is not absolute, the path is considered to be rela‐
131 tive to the cgroups path of the init process. Cgroups will be created
132 if they do not already exist.
133 --compress
136 This option is added to be aligned with other containers CLIs. Buildah
139 doesn't send a copy of the context directory to a daemon or a remote
140 server. Thus, compressing the data before sending it is irrelevant to
141 Buildah.
142 --cni-config-dir=directory
145 Location of CNI configuration files which will dictate which plugins
148 will be used to configure network interfaces and routing for containers
149 created for handling RUN instructions, if those containers will be run
150 in their own network namespaces, and networking is not disabled.
151 --cni-plugin-path=directory[:directory[:directory[...]]]
154 List of directories in which the CNI plugins which will be used for
157 configuring network namespaces can be found.
158 --cpu-period=0
161 Limit the CPU CFS (Completely Fair Scheduler) period
164 Limit the container's CPU usage. This flag tell the kernel to restrict
167 the container's CPU usage to the period you specify.
168 --cpu-quota=0
171 Limit the CPU CFS (Completely Fair Scheduler) quota
174 Limit the container's CPU usage. By default, containers run with the
177 full CPU resource. This flag tell the kernel to restrict the con‐
178 tainer's CPU usage to the quota you specify.
179 --cpu-shares, -c=0
182 CPU shares (relative weight)
185 By default, all containers get the same proportion of CPU cycles. This
188 proportion can be modified by changing the container's CPU share
189 weighting relative to the weighting of all other running containers.
190 To modify the proportion from the default of 1024, use the --cpu-shares
193 flag to set the weighting to 2 or higher.
194 The proportion will only apply when CPU-intensive processes are run‐
197 ning. When tasks in one container are idle, other containers can use
198 the left-over CPU time. The actual amount of CPU time will vary depend‐
199 ing on the number of containers running on the system.
200 For example, consider three containers, one has a cpu-share of 1024 and
203 two others have a cpu-share setting of 512. When processes in all three
204 containers attempt to use 100% of CPU, the first container would
205 receive 50% of the total CPU time. If you add a fourth container with a
206 cpu-share of 1024, the first container only gets 33% of the CPU. The
207 remaining containers receive 16.5%, 16.5% and 33% of the CPU.
208 On a multi-core system, the shares of CPU time are distributed over all
211 CPU cores. Even if a container is limited to less than 100% of CPU
212 time, it can use 100% of each individual CPU core.
213 For example, consider a system with more than three cores. If you start
216 one container {C0} with -c=512 running one process, and another con‐
217 tainer {C1} with -c=1024 running two processes, this can result in the
218 following division of CPU shares:
219 PID container CPU CPU share
222 100 {C0} 0 100% of CPU0
223 101 {C1} 1 100% of CPU1
224 102 {C1} 2 100% of CPU2
225 --cpuset-cpus=""
229 CPUs in which to allow execution (0-3, 0,1)
232 --cpuset-mems=""
235 Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effec‐
238 tive on NUMA systems.
239 If you have four memory nodes on your system (0-3), use
242 --cpuset-mems=0,1 then processes in your container will only use memory
243 from the first two memory nodes.
244 --creds creds
247 The [username[:password]] to use to authenticate with the registry if
250 required. If one or both values are not supplied, a command line
251 prompt will appear and the value can be entered. The password is
252 entered without echo.
253 --disable-compression, -D
256 Don't compress filesystem layers when building the image unless it is
259 required by the location where the image is being written. This is the
260 default setting, because image layers are compressed automatically when
261 they are pushed to registries, and images being written to local stor‐
262 age would only need to be decompressed again to be stored. Compression
263 can be forced in all cases by specifying --disable-compression=false.
264 --disable-content-trust
267 This is a Docker specific option to disable image verification to a
270 Docker registry and is not supported by Buildah. This flag is a NOOP
271 and provided soley for scripting compatibility.
272 --dns=[]
275 Set custom DNS servers
278 --dns-option=[]
281 Set custom DNS options
284 --dns-search=[]
287 Set custom DNS search domains
290 --file, -f Dockerfile
293 Specifies a Dockerfile which contains instructions for building the
296 image, either a local file or an http or https URL. If more than one
297 Dockerfile is specified, FROM instructions will only be accepted from
298 the first specified file.
299 If a local file is specified as the Dockerfile and it does not exist,
302 the context directory will be prepended to the local file value.
303 If you specify -f -, the Dockerfile contents will be read from stdin.
306 --force-rm bool-value
309 Always remove intermediate containers after a build, even if the build
312 fails (default false).
313 --format
316 Control the format for the built image's manifest and configuration
319 data. Recognized formats include oci (OCI image-spec v1.0, the
320 default) and docker (version 2, using schema format 2 for the mani‐
321 fest).
322 Note: You can also override the default format by setting the BUIL‐
325 DAH_FORMAT environment variable. export BUILDAH_FORMAT=docker
326 --http-proxy
329 By default proxy environment variables are passed into the container if
332 set for the buildah process. This can be disabled by setting the
333 --http-proxy option to false. The environment variables passed in
334 include http_proxy, https_proxy, ftp_proxy, no_proxy, and also the
335 upper case versions of those.
336 Defaults to true
339 --iidfile ImageIDfile
342 Write the image ID to the file.
345 --ipc how
348 Sets the configuration for IPC namespaces when handling RUN instruc‐
351 tions. The configured value can be "" (the empty string) or "con‐
352 tainer" to indicate that a new IPC namespace should be created, or it
353 can be "host" to indicate that the IPC namespace in which buildah
354 itself is being run should be reused, or it can be the path to an IPC
355 namespace which is already in use by another process.
356 --isolation type
359 Controls what type of isolation is used for running processes as part
362 of RUN instructions. Recognized types include oci (OCI-compatible run‐
363 time, the default), rootless (OCI-compatible runtime invoked using a
364 modified configuration, with --no-new-keyring added to its create invo‐
365 cation, with network and UTS namespaces disabled, and IPC, PID, and
366 user namespaces enabled; the default for unprivileged users), and
367 chroot (an internal wrapper that leans more toward chroot(1) than con‐
368 tainer technology).
369 Note: You can also override the default isolation type by setting the
372 BUILDAH_ISOLATION environment variable. export BUILDAH_ISOLATION=oci
373 --label label
376 Add an image label (e.g. label=value) to the image metadata. Can be
379 used multiple times.
380 --loglevel number
383 Adjust the logging level up or down. Valid option values range from -2
386 to 3, with 3 being roughly equivalent to using the global --debug
387 option, and values below 0 omitting even error messages which accompany
388 fatal errors.
389 --layers bool-value
392 Cache intermediate images during the build process (Default is false).
395 Note: You can also override the default value of layers by setting the
398 BUILDAH_LAYERS environment variable. export BUILDAH_LAYERS=true
399 --logfile filename
402 Log output which would be sent to standard output and standard error to
405 the specified file instead of to standard output and standard error.
406 --memory, -m=""
409 Memory limit (format: <number>[<unit>], where unit = b, k, m or g)
412 Allows you to constrain the memory available to a container. If the
415 host supports swap memory, then the -m memory setting can be larger
416 than physical RAM. If a limit of 0 is specified (not using -m), the
417 container's memory is not limited. The actual limit may be rounded up
418 to a multiple of the operating system's page size (the value would be
419 very large, that's millions of trillions).
420 --memory-swap="LIMIT"
423 A limit value equal to memory plus swap. Must be used with the -m
426 (--memory) flag. The swap LIMIT should always be larger than -m (--mem‐
427 ory) value. By default, the swap LIMIT will be set to double the value
428 of --memory.
429 The format of LIMIT is <number>[<unit>]. Unit can be b (bytes), k
432 (kilobytes), m (megabytes), or g (gigabytes). If you don't specify a
433 unit, b is used. Set LIMIT to -1 to enable unlimited swap.
434 --net how --network how
437 Sets the configuration for network namespaces when handling RUN
440 instructions. The configured value can be "" (the empty string) or
441 "container" to indicate that a new network namespace should be created,
442 or it can be "host" to indicate that the network namespace in which
443 buildah itself is being run should be reused, or it can be the path to
444 a network namespace which is already in use by another process.
445 --no-cache
448 Do not use existing cached images for the container build. Build from
451 the start with a new set of cached layers.
452 --pid how
455 Sets the configuration for PID namespaces when handling RUN instruc‐
458 tions. The configured value can be "" (the empty string) or "con‐
459 tainer" to indicate that a new PID namespace should be created, or it
460 can be "host" to indicate that the PID namespace in which buildah
461 itself is being run should be reused, or it can be the path to a PID
462 namespace which is already in use by another process.
463 --platform="Linux"
466 This option has no effect on the build. Other container engines use
469 this option to control the execution platform for the build (e.g., Win‐
470 dows, Linux) which is not required for Buildah as it supports only
471 Linux.
472 --pull
475 When the flag is enabled, attempt to pull the latest image from the
478 registries listed in registries.conf if a local image does not exist or
479 the image is newer than the one in storage. Raise an error if the image
480 is not in any listed registry and is not present locally.
481 If the flag is disabled (with --pull=false), do not pull the image from
484 the registry, use only the local version. Raise an error if the image
485 is not present locally.
486 Defaults to true.
489 --pull-always
492 Pull the image from the first registry it is found in as listed in reg‐
495 istries.conf. Raise an error if not found in the registries, even if
496 the image is present locally.
497 --quiet, -q
500 Suppress output messages which indicate which instruction is being pro‐
503 cessed, and of progress when pulling images from a registry, and when
504 writing the output image.
505 --rm bool-value
508 Remove intermediate containers after a successful build (default true).
511 --runtime path
514 The path to an alternate OCI-compatible runtime, which will be used to
517 run commands specified by the RUN instruction. Default is runc.
518 Note: You can also override the default runtime by setting the BUIL‐
521 DAH_RUNTIME environment variable. export BUILDAH_RUN‐
522 TIME=/usr/local/bin/runc
523 --runtime-flag flag
526 Adds global flags for the container rutime. To list the supported
529 flags, please consult the manpages of the selected container runtime
530 (runc is the default runtime, the manpage to consult is runc(8)).
531 Note: Do not pass the leading -- to the flag. To pass the runc flag
534 --log-format json to buildah bud, the option given would be --run‐
535 time-flag log-format=json.
536 --security-opt=[]
539 Security Options
542 "label=user:USER" : Set the label user for the container
545 "label=role:ROLE" : Set the label role for the container
546 "label=type:TYPE" : Set the label type for the container
547 "label=level:LEVEL" : Set the label level for the container
548 "label=disable" : Turn off label confinement for the container
549 "no-new-privileges" : Not supported
550 "seccomp=unconfined" : Turn off seccomp confinement for the container
553 "seccomp=profile.json : White listed syscalls seccomp Json file to
554 be used as a seccomp filter
555 "apparmor=unconfined" : Turn off apparmor confinement for the container
558 "apparmor=your-profile" : Set the apparmor confinement profile for
559 the container
560 --shm-size=""
563 Size of /dev/shm. The format is <number><unit>. number must be greater
566 than 0. Unit is optional and can be b (bytes), k (kilobytes),
567 m(megabytes), or g (gigabytes). If you omit the unit, the system uses
568 bytes. If you omit the size entirely, the system uses 64m.
569 --squash
572 Squash all of the new image's layers (including those inherited from a
575 base image) into a single new layer.
576 --tag, -t imageName
579 Specifies the name which will be assigned to the resulting image if the
582 build process completes successfully. If imageName does not include a
583 registry name, the registry name localhost will be prepended to the
584 image name.
585 --target stageName
588 Set the target build stage to build. When building a Dockerfile with
591 multiple build stages, --target can be used to specify an intermediate
592 build stage by name as the final stage for the resulting image. Com‐
593 mands after the target stage will be skipped.
594 --tls-verify bool-value
597 Require HTTPS and verify certificates when talking to container reg‐
600 istries (defaults to true).
601 --ulimit type=soft-limit[:hard-limit]
604 Specifies resource limits to apply to processes launched when process‐
607 ing RUN instructions. This option can be specified multiple times.
608 Recognized resource types include:
609 "core": maximimum core dump size (ulimit -c)
610 "cpu": maximum CPU time (ulimit -t)
611 "data": maximum size of a process's data segment (ulimit -d)
612 "fsize": maximum size of new files (ulimit -f)
613 "locks": maximum number of file locks (ulimit -x)
614 "memlock": maximum amount of locked memory (ulimit -l)
615 "msgqueue": maximum amount of data in message queues (ulimit -q)
616 "nice": niceness adjustment (nice -n, ulimit -e)
617 "nofile": maximum number of open files (ulimit -n)
618 "nofile": maximum number of open files (1048576); when run by root
619 "nproc": maximum number of processes (ulimit -u)
620 "nproc": maximum number of processes (1048576); when run by root
621 "rss": maximum size of a process's (ulimit -m)
622 "rtprio": maximum real-time scheduling priority (ulimit -r)
623 "rttime": maximum amount of real-time execution between blocking
624 syscalls
625 "sigpending": maximum number of pending signals (ulimit -i)
626 "stack": maximum stack size (ulimit -s)
627 --userns how
630 Sets the configuration for user namespaces when handling RUN instruc‐
633 tions. The configured value can be "" (the empty string) or "con‐
634 tainer" to indicate that a new user namespace should be created, it can
635 be "host" to indicate that the user namespace in which buildah itself
636 is being run should be reused, or it can be the path to an user names‐
637 pace which is already in use by another process.
638 --userns-uid-map mapping
641 Directly specifies a UID mapping which should be used to set ownership,
644 at the filesytem level, on the working container's contents. Commands
645 run when handling RUN instructions will default to being run in their
646 own user namespaces, configured using the UID and GID maps.
647 Entries in this map take the form of one or more triples of a starting
650 in-container UID, a corresponding starting host-level UID, and the num‐
651 ber of consecutive IDs which the map entry represents.
652 This option overrides the remap-uids setting in the options section of
655 /etc/containers/storage.conf.
656 If this option is not specified, but a global --userns-uid-map setting
659 is supplied, settings from the global option will be used.
660 If none of --userns-uid-map-user, --userns-gid-map-group, or
663 --userns-uid-map are specified, but --userns-gid-map is specified, the
664 UID map will be set to use the same numeric values as the GID map.
665 --userns-gid-map mapping
668 Directly specifies a GID mapping which should be used to set ownership,
671 at the filesytem level, on the working container's contents. Commands
672 run when handling RUN instructions will default to being run in their
673 own user namespaces, configured using the UID and GID maps.
674 Entries in this map take the form of one or more triples of a starting
677 in-container GID, a corresponding starting host-level GID, and the num‐
678 ber of consecutive IDs which the map entry represents.
679 This option overrides the remap-gids setting in the options section of
682 /etc/containers/storage.conf.
683 If this option is not specified, but a global --userns-gid-map setting
686 is supplied, settings from the global option will be used.
687 If none of --userns-uid-map-user, --userns-gid-map-group, or
690 --userns-gid-map are specified, but --userns-uid-map is specified, the
691 GID map will be set to use the same numeric values as the UID map.
692 --userns-uid-map-user user
695 Specifies that a UID mapping which should be used to set ownership, at
698 the filesytem level, on the working container's contents, can be found
699 in entries in the /etc/subuid file which correspond to the specified
700 user. Commands run when handling RUN instructions will default to
701 being run in their own user namespaces, configured using the UID and
702 GID maps. If --userns-gid-map-group is specified, but
703 --userns-uid-map-user is not specified, buildah will assume that the
704 specified group name is also a suitable user name to use as the default
705 setting for this option.
706 --userns-gid-map-group group
709 Specifies that a GID mapping which should be used to set ownership, at
712 the filesytem level, on the working container's contents, can be found
713 in entries in the /etc/subgid file which correspond to the specified
714 group. Commands run when handling RUN instructions will default to
715 being run in their own user namespaces, configured using the UID and
716 GID maps. If --userns-uid-map-user is specified, but
717 --userns-gid-map-group is not specified, buildah will assume that the
718 specified user name is also a suitable group name to use as the default
719 setting for this option.
720 --uts how
723 Sets the configuration for UTS namespaces when the handling RUN
726 instructions. The configured value can be "" (the empty string) or
727 "container" to indicate that a new UTS namespace should be created, or
728 it can be "host" to indicate that the UTS namespace in which buildah
729 itself is being run should be reused, or it can be the path to a UTS
730 namespace which is already in use by another process.
731 --volume, -v[=[HOST-DIR:CONTAINER-DIR[:OPTIONS]]]
734 Create a bind mount. If you specify, -v /HOST-DIR:/CONTAINER-DIR, Buil‐
737 dah
738 bind mounts /HOST-DIR in the host to /CONTAINER-DIR in the Buildah
739 container. The OPTIONS are a comma delimited list and can be:
740 · [rw|ro]
743 · [z|Z]
745 · [[r]shared|[r]slave|[r]private]
747 The CONTAINER-DIR must be an absolute path such as /src/docs. The
751 HOST-DIR must be an absolute path as well. Buildah bind-mounts the
752 HOST-DIR to the path you specify. For example, if you supply /foo as
753 the host path, Buildah copies the contents of /foo to the container
754 filesystem on the host and bind mounts that into the container.
755 You can specify multiple -v options to mount one or more mounts to a
758 container.
759 You can add the :ro or :rw suffix to a volume to mount it read-only or
762 read-write mode, respectively. By default, the volumes are mounted
763 read-write. See examples.
764 Labeling systems like SELinux require that proper labels are placed on
767 volume content mounted into a container. Without a label, the security
768 system might prevent the processes running inside the container from
769 using the content. By default, Buildah does not change the labels set
770 by the OS.
771 To change a label in the container context, you can add either of two
774 suffixes :z or :Z to the volume mount. These suffixes tell Buildah to
775 relabel file objects on the shared volumes. The z option tells Buildah
776 that two containers share the volume content. As a result, Buildah
777 labels the content with a shared content label. Shared volume labels
778 allow all containers to read/write content. The Z option tells Buildah
779 to label the content with a private unshared label. Only the current
780 container can use a private volume.
781 By default bind mounted volumes are private. That means any mounts done
784 inside container will not be visible on the host and vice versa. This
785 behavior can be changed by specifying a volume mount propagation prop‐
786 erty.
787 When the mount propagation policy is set to shared, any mounts com‐
790 pleted inside the container on that volume will be visible to both the
791 host and container. When the mount propagation policy is set to slave,
792 one way mount propagation is enabled and any mounts completed on the
793 host for that volume will be visible only inside of the container. To
794 control the mount propagation property of the volume use the
795 :[r]shared, :[r]slave or :[r]private propagation flag. The propagation
796 property can be specified only for bind mounted volumes and not for
797 internal volumes or named volumes. For mount propagation to work on the
798 source mount point (the mount point where source dir is mounted on) it
799 has to have the right propagation properties. For shared volumes, the
800 source mount point has to be shared. And for slave volumes, the source
801 mount has to be either shared or slave.
802 Use df <source-dir> to determine the source mount and then use findmnt
805 -o TARGET,PROPAGATION <source-mount-dir> to determine propagation prop‐
806 erties of source mount, if findmnt utility is not available, the source
807 mount point can be determined by looking at the mount entry in
808 /proc/self/mountinfo. Look at optional fields and see if any propagaion
809 properties are specified. shared:X means the mount is shared, master:X
810 means the mount is slave and if nothing is there that means the mount
811 is private.
812 To change propagation properties of a mount point use the mount com‐
815 mand. For example, to bind mount the source directory /foo do mount
816 --bind /foo /foo and mount --make-private --make-shared /foo. This will
817 convert /foo into a shared mount point. The propagation properties of
818 the source mount can be changed directly. For instance if / is the
819 source mount for /foo, then use mount --make-shared / to convert / into
820 a shared mount.
821
824 Build an image using local Dockerfiles
825 buildah bud .
826 buildah bud -f Dockerfile.simple .
829 cat /Dockerfile | buildah bud -f - .
832 buildah bud -f Dockerfile.simple -f Dockerfile.notsosimple .
835 buildah bud -t imageName .
838 buildah bud --tls-verify=true -t imageName -f Dockerfile.simple .
841 buildah bud --tls-verify=false -t imageName .
844 buildah bud --runtime-flag log-format=json .
847 buildah bud --runtime-flag debug .
850 buildah bud --authfile /tmp/auths/myauths.json --cert-dir /auth
853 --tls-verify=true --creds=username:password -t imageName -f Docker‐
854 file.simple .
855 buildah bud --memory 40m --cpu-period 10000 --cpu-quota 50000 --ulimit
858 nofile=1024:1028 -t imageName .
859 buildah bud --security-opt label=level:s0:c100,c200 --cgroup-parent
862 /path/to/cgroup/parent -t imageName .
863 buildah bud --volume /home/test:/myvol:ro,Z -t imageName .
866 buildah bud --layers -t imageName .
869 buildah bud --no-cache -t imageName .
872 buildah bud --layers --force-rm -t imageName .
875 buildah bud --no-cache --rm=false -t imageName .
878 buildah bud --dns-search=example.com --dns=223.5.5.5
881 --dns-option=use-vc .
882 Building an image using a URL
885 This will clone the specified GitHub repository from the URL and use it
886 as context. The Dockerfile at the root of the repository is used as
887 Dockerfile. This only works if the GitHub repository is a dedicated
888 repository.
889 buildah bud github.com/scollier/purpletest
892 Note: You can set an arbitrary Git repository via the git:// scheme.
895 Building an image using a URL to a tarball'ed context
898 Buildah will fetch the tarball archive, decompress it and use its con‐
899 tents as the build context. The Dockerfile at the root of the archive
900 and the rest of the archive will get used as the context of the build.
901 If you pass an -f PATH/Dockerfile option as well, the system will look
902 for that file inside the contents of the tarball.
903 buildah bud -f dev/Dockerfile ⟨https://10.10.10.1/docker/con‐
906 text.tar.gz⟩
907 Note: supported compression formats are 'xz', 'bzip2', 'gzip' and
910 'identity' (no compression).
911
914 registries.conf (/etc/containers/registries.conf)
915 registries.conf is the configuration file which specifies which con‐
918 tainer registries should be consulted when completing image names which
919 do not include a registry or domain portion.
920 policy.json (/etc/containers/policy.json)
923 Signature policy file. This defines the trust policy for container
926 images. Controls which container registries can be used for image, and
927 whether or not the tool should trust the images.
928
931 buildah(1), CPP(1), buildah-login(1), docker-login(1), namespaces(7),
932 pid_namespaces(7), policy.json(5), registries.conf(5), user_names‐
933 paces(7)
934buildah April 2017 buildah-bud(1)