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 This option can be used to override the DNS configuration passed to the
281 container. Typically this is necessary when the host DNS configuration
282 is invalid for the container (e.g., 127.0.0.1). When this is the case
283 the --dns flag is necessary for every run.
284 The special value none can be specified to disable creation of
287 /etc/resolv.conf in the container by Buildah. The /etc/resolv.conf file
288 in the image will be used without changes.
289 --dns-option=[]
292 Set custom DNS options
295 --dns-search=[]
298 Set custom DNS search domains
301 --file, -f Dockerfile
304 Specifies a Dockerfile which contains instructions for building the
307 image, either a local file or an http or https URL. If more than one
308 Dockerfile is specified, FROM instructions will only be accepted from
309 the first specified file.
310 If a local file is specified as the Dockerfile and it does not exist,
313 the context directory will be prepended to the local file value.
314 If you specify -f -, the Dockerfile contents will be read from stdin.
317 --force-rm bool-value
320 Always remove intermediate containers after a build, even if the build
323 fails (default false).
324 --format
327 Control the format for the built image's manifest and configuration
330 data. Recognized formats include oci (OCI image-spec v1.0, the
331 default) and docker (version 2, using schema format 2 for the mani‐
332 fest).
333 Note: You can also override the default format by setting the BUIL‐
336 DAH_FORMAT environment variable. export BUILDAH_FORMAT=docker
337 --http-proxy
340 By default proxy environment variables are passed into the container if
343 set for the buildah process. This can be disabled by setting the
344 --http-proxy option to false. The environment variables passed in
345 include http_proxy, https_proxy, ftp_proxy, no_proxy, and also the
346 upper case versions of those.
347 Defaults to true
350 --iidfile ImageIDfile
353 Write the image ID to the file.
356 --ipc how
359 Sets the configuration for IPC namespaces when handling RUN instruc‐
362 tions. The configured value can be "" (the empty string) or "con‐
363 tainer" to indicate that a new IPC namespace should be created, or it
364 can be "host" to indicate that the IPC namespace in which buildah
365 itself is being run should be reused, or it can be the path to an IPC
366 namespace which is already in use by another process.
367 --isolation type
370 Controls what type of isolation is used for running processes as part
373 of RUN instructions. Recognized types include oci (OCI-compatible run‐
374 time, the default), rootless (OCI-compatible runtime invoked using a
375 modified configuration, with --no-new-keyring added to its create invo‐
376 cation, with network and UTS namespaces disabled, and IPC, PID, and
377 user namespaces enabled; the default for unprivileged users), and
378 chroot (an internal wrapper that leans more toward chroot(1) than con‐
379 tainer technology).
380 Note: You can also override the default isolation type by setting the
383 BUILDAH_ISOLATION environment variable. export BUILDAH_ISOLATION=oci
384 --label label
387 Add an image label (e.g. label=value) to the image metadata. Can be
390 used multiple times.
391 --loglevel number
394 Adjust the logging level up or down. Valid option values range from -2
397 to 3, with 3 being roughly equivalent to using the global --debug
398 option, and values below 0 omitting even error messages which accompany
399 fatal errors.
400 --layers bool-value
403 Cache intermediate images during the build process (Default is false).
406 Note: You can also override the default value of layers by setting the
409 BUILDAH_LAYERS environment variable. export BUILDAH_LAYERS=true
410 --logfile filename
413 Log output which would be sent to standard output and standard error to
416 the specified file instead of to standard output and standard error.
417 --memory, -m=""
420 Memory limit (format: <number>[<unit>], where unit = b, k, m or g)
423 Allows you to constrain the memory available to a container. If the
426 host supports swap memory, then the -m memory setting can be larger
427 than physical RAM. If a limit of 0 is specified (not using -m), the
428 container's memory is not limited. The actual limit may be rounded up
429 to a multiple of the operating system's page size (the value would be
430 very large, that's millions of trillions).
431 --memory-swap="LIMIT"
434 A limit value equal to memory plus swap. Must be used with the -m
437 (--memory) flag. The swap LIMIT should always be larger than -m (--mem‐
438 ory) value. By default, the swap LIMIT will be set to double the value
439 of --memory.
440 The format of LIMIT is <number>[<unit>]. Unit can be b (bytes), k
443 (kilobytes), m (megabytes), or g (gigabytes). If you don't specify a
444 unit, b is used. Set LIMIT to -1 to enable unlimited swap.
445 --net how --network how
448 Sets the configuration for network namespaces when handling RUN
451 instructions. The configured value can be "" (the empty string) or
452 "container" to indicate that a new network namespace should be created,
453 or it can be "host" to indicate that the network namespace in which
454 buildah itself is being run should be reused, or it can be the path to
455 a network namespace which is already in use by another process.
456 --no-cache
459 Do not use existing cached images for the container build. Build from
462 the start with a new set of cached layers.
463 --pid how
466 Sets the configuration for PID namespaces when handling RUN instruc‐
469 tions. The configured value can be "" (the empty string) or "con‐
470 tainer" to indicate that a new PID namespace should be created, or it
471 can be "host" to indicate that the PID namespace in which buildah
472 itself is being run should be reused, or it can be the path to a PID
473 namespace which is already in use by another process.
474 --platform="Linux"
477 This option has no effect on the build. Other container engines use
480 this option to control the execution platform for the build (e.g., Win‐
481 dows, Linux) which is not required for Buildah as it supports only
482 Linux.
483 --pull
486 When the flag is enabled, attempt to pull the latest image from the
489 registries listed in registries.conf if a local image does not exist or
490 the image is newer than the one in storage. Raise an error if the image
491 is not in any listed registry and is not present locally.
492 If the flag is disabled (with --pull=false), do not pull the image from
495 the registry, use only the local version. Raise an error if the image
496 is not present locally.
497 Defaults to true.
500 --pull-always
503 Pull the image from the first registry it is found in as listed in reg‐
506 istries.conf. Raise an error if not found in the registries, even if
507 the image is present locally.
508 --quiet, -q
511 Suppress output messages which indicate which instruction is being pro‐
514 cessed, and of progress when pulling images from a registry, and when
515 writing the output image.
516 --rm bool-value
519 Remove intermediate containers after a successful build (default true).
522 --runtime path
525 The path to an alternate OCI-compatible runtime, which will be used to
528 run commands specified by the RUN instruction. Default is runc.
529 Note: You can also override the default runtime by setting the BUIL‐
532 DAH_RUNTIME environment variable. export BUILDAH_RUN‐
533 TIME=/usr/local/bin/runc
534 --runtime-flag flag
537 Adds global flags for the container rutime. To list the supported
540 flags, please consult the manpages of the selected container runtime
541 (runc is the default runtime, the manpage to consult is runc(8)).
542 Note: Do not pass the leading -- to the flag. To pass the runc flag
545 --log-format json to buildah bud, the option given would be --run‐
546 time-flag log-format=json.
547 --security-opt=[]
550 Security Options
553 "label=user:USER" : Set the label user for the container
556 "label=role:ROLE" : Set the label role for the container
557 "label=type:TYPE" : Set the label type for the container
558 "label=level:LEVEL" : Set the label level for the container
559 "label=disable" : Turn off label confinement for the container
560 "no-new-privileges" : Not supported
561 "seccomp=unconfined" : Turn off seccomp confinement for the container
564 "seccomp=profile.json : White listed syscalls seccomp Json file to
565 be used as a seccomp filter
566 "apparmor=unconfined" : Turn off apparmor confinement for the container
569 "apparmor=your-profile" : Set the apparmor confinement profile for
570 the container
571 --shm-size=""
574 Size of /dev/shm. The format is <number><unit>. number must be greater
577 than 0. Unit is optional and can be b (bytes), k (kilobytes),
578 m(megabytes), or g (gigabytes). If you omit the unit, the system uses
579 bytes. If you omit the size entirely, the system uses 64m.
580 --squash
583 Squash all of the new image's layers (including those inherited from a
586 base image) into a single new layer.
587 --tag, -t imageName
590 Specifies the name which will be assigned to the resulting image if the
593 build process completes successfully. If imageName does not include a
594 registry name, the registry name localhost will be prepended to the
595 image name.
596 --target stageName
599 Set the target build stage to build. When building a Dockerfile with
602 multiple build stages, --target can be used to specify an intermediate
603 build stage by name as the final stage for the resulting image. Com‐
604 mands after the target stage will be skipped.
605 --tls-verify bool-value
608 Require HTTPS and verify certificates when talking to container reg‐
611 istries (defaults to true).
612 --ulimit type=soft-limit[:hard-limit]
615 Specifies resource limits to apply to processes launched when process‐
618 ing RUN instructions. This option can be specified multiple times.
619 Recognized resource types include:
620 "core": maximimum core dump size (ulimit -c)
621 "cpu": maximum CPU time (ulimit -t)
622 "data": maximum size of a process's data segment (ulimit -d)
623 "fsize": maximum size of new files (ulimit -f)
624 "locks": maximum number of file locks (ulimit -x)
625 "memlock": maximum amount of locked memory (ulimit -l)
626 "msgqueue": maximum amount of data in message queues (ulimit -q)
627 "nice": niceness adjustment (nice -n, ulimit -e)
628 "nofile": maximum number of open files (ulimit -n)
629 "nofile": maximum number of open files (1048576); when run by root
630 "nproc": maximum number of processes (ulimit -u)
631 "nproc": maximum number of processes (1048576); when run by root
632 "rss": maximum size of a process's (ulimit -m)
633 "rtprio": maximum real-time scheduling priority (ulimit -r)
634 "rttime": maximum amount of real-time execution between blocking
635 syscalls
636 "sigpending": maximum number of pending signals (ulimit -i)
637 "stack": maximum stack size (ulimit -s)
638 --userns how
641 Sets the configuration for user namespaces when handling RUN instruc‐
644 tions. The configured value can be "" (the empty string) or "con‐
645 tainer" to indicate that a new user namespace should be created, it can
646 be "host" to indicate that the user namespace in which buildah itself
647 is being run should be reused, or it can be the path to an user names‐
648 pace which is already in use by another process.
649 --userns-uid-map mapping
652 Directly specifies a UID mapping which should be used to set ownership,
655 at the filesytem level, on the working container's contents. Commands
656 run when handling RUN instructions will default to being run in their
657 own user namespaces, configured using the UID and GID maps.
658 Entries in this map take the form of one or more triples of a starting
661 in-container UID, a corresponding starting host-level UID, and the num‐
662 ber of consecutive IDs which the map entry represents.
663 This option overrides the remap-uids setting in the options section of
666 /etc/containers/storage.conf.
667 If this option is not specified, but a global --userns-uid-map setting
670 is supplied, settings from the global option will be used.
671 If none of --userns-uid-map-user, --userns-gid-map-group, or
674 --userns-uid-map are specified, but --userns-gid-map is specified, the
675 UID map will be set to use the same numeric values as the GID map.
676 --userns-gid-map mapping
679 Directly specifies a GID mapping which should be used to set ownership,
682 at the filesytem level, on the working container's contents. Commands
683 run when handling RUN instructions will default to being run in their
684 own user namespaces, configured using the UID and GID maps.
685 Entries in this map take the form of one or more triples of a starting
688 in-container GID, a corresponding starting host-level GID, and the num‐
689 ber of consecutive IDs which the map entry represents.
690 This option overrides the remap-gids setting in the options section of
693 /etc/containers/storage.conf.
694 If this option is not specified, but a global --userns-gid-map setting
697 is supplied, settings from the global option will be used.
698 If none of --userns-uid-map-user, --userns-gid-map-group, or
701 --userns-gid-map are specified, but --userns-uid-map is specified, the
702 GID map will be set to use the same numeric values as the UID map.
703 --userns-uid-map-user user
706 Specifies that a UID mapping which should be used to set ownership, at
709 the filesytem level, on the working container's contents, can be found
710 in entries in the /etc/subuid file which correspond to the specified
711 user. Commands run when handling RUN instructions will default to
712 being run in their own user namespaces, configured using the UID and
713 GID maps. If --userns-gid-map-group is specified, but
714 --userns-uid-map-user is not specified, buildah will assume that the
715 specified group name is also a suitable user name to use as the default
716 setting for this option.
717 --userns-gid-map-group group
720 Specifies that a GID mapping which should be used to set ownership, at
723 the filesytem level, on the working container's contents, can be found
724 in entries in the /etc/subgid file which correspond to the specified
725 group. Commands run when handling RUN instructions will default to
726 being run in their own user namespaces, configured using the UID and
727 GID maps. If --userns-uid-map-user is specified, but
728 --userns-gid-map-group is not specified, buildah will assume that the
729 specified user name is also a suitable group name to use as the default
730 setting for this option.
731 --uts how
734 Sets the configuration for UTS namespaces when the handling RUN
737 instructions. The configured value can be "" (the empty string) or
738 "container" to indicate that a new UTS namespace should be created, or
739 it can be "host" to indicate that the UTS namespace in which buildah
740 itself is being run should be reused, or it can be the path to a UTS
741 namespace which is already in use by another process.
742 --volume, -v[=[HOST-DIR:CONTAINER-DIR[:OPTIONS]]]
745 Create a bind mount. If you specify, -v /HOST-DIR:/CONTAINER-DIR, Buil‐
748 dah
749 bind mounts /HOST-DIR in the host to /CONTAINER-DIR in the Buildah
750 container. The OPTIONS are a comma delimited list and can be:
751 · [rw|ro]
754 · [z|Z|O]
756 · [[r]shared|[r]slave|[r]private]
758 The CONTAINER-DIR must be an absolute path such as /src/docs. The
762 HOST-DIR must be an absolute path as well. Buildah bind-mounts the
763 HOST-DIR to the path you specify. For example, if you supply /foo as
764 the host path, Buildah copies the contents of /foo to the container
765 filesystem on the host and bind mounts that into the container.
766 You can specify multiple -v options to mount one or more mounts to a
769 container.
770 You can add the :ro or :rw suffix to a volume to mount it read-only or
773 read-write mode, respectively. By default, the volumes are mounted
774 read-write. See examples.
775 Labeling Volume Mounts
778 Labeling systems like SELinux require that proper labels are placed on
781 volume content mounted into a container. Without a label, the security
782 system might prevent the processes running inside the container from
783 using the content. By default, Buildah does not change the labels set
784 by the OS.
785 To change a label in the container context, you can add either of two
788 suffixes :z or :Z to the volume mount. These suffixes tell Buildah to
789 relabel file objects on the shared volumes. The z option tells Buildah
790 that two containers share the volume content. As a result, Buildah
791 labels the content with a shared content label. Shared volume labels
792 allow all containers to read/write content. The Z option tells Buildah
793 to label the content with a private unshared label. Only the current
794 container can use a private volume.
795 Overlay Volume Mounts
798 The :O flag tells Buildah to mount the directory from the host as a
801 temporary storage using the Overlay file system. The RUN command con‐
802 tainers are allowed to modify contents within the mountpoint and are
803 stored in the container storage in a separate directory. In Ovelay FS
804 terms the source directory will be the lower, and the container storage
805 directory will be the upper. Modifications to the mount point are
806 destroyed when the RUN command finishes executing, similar to a tmpfs
807 mount point.
808 Any subsequent execution of RUN commands sees the original source
811 directory content, any changes from previous RUN commands no longer
812 exists.
813 One use case of the overlay mount is sharing the package cache from the
816 host into the container to allow speeding up builds.
817 Note:
820 - Overlay mounts are not currently supported in rootless mode.
823 - The `O` flag is not allowed to be specified with the `Z` or `z` flags. Content mounted into the container is labeled with the private label.
824 On SELinux systems, labels in the source directory needs to be readable by the container label. If not, SELinux container separation must be disabled for the container to work.
825 - Modification of the directory volume mounted into the container with an overlay mount can cause unexpected failures. It is recommended that you do not modify the directory until the container finishes running.
826 By default bind mounted volumes are private. That means any mounts done
830 inside container will not be visible on the host and vice versa. This
831 behavior can be changed by specifying a volume mount propagation prop‐
832 erty.
833 When the mount propagation policy is set to shared, any mounts com‐
836 pleted inside the container on that volume will be visible to both the
837 host and container. When the mount propagation policy is set to slave,
838 one way mount propagation is enabled and any mounts completed on the
839 host for that volume will be visible only inside of the container. To
840 control the mount propagation property of the volume use the
841 :[r]shared, :[r]slave or :[r]private propagation flag. The propagation
842 property can be specified only for bind mounted volumes and not for
843 internal volumes or named volumes. For mount propagation to work on the
844 source mount point (the mount point where source dir is mounted on) it
845 has to have the right propagation properties. For shared volumes, the
846 source mount point has to be shared. And for slave volumes, the source
847 mount has to be either shared or slave.
848 Use df <source-dir> to determine the source mount and then use findmnt
851 -o TARGET,PROPAGATION <source-mount-dir> to determine propagation prop‐
852 erties of source mount, if findmnt utility is not available, the source
853 mount point can be determined by looking at the mount entry in
854 /proc/self/mountinfo. Look at optional fields and see if any propagaion
855 properties are specified. shared:X means the mount is shared, master:X
856 means the mount is slave and if nothing is there that means the mount
857 is private.
858 To change propagation properties of a mount point use the mount com‐
861 mand. For example, to bind mount the source directory /foo do mount
862 --bind /foo /foo and mount --make-private --make-shared /foo. This will
863 convert /foo into a shared mount point. The propagation properties of
864 the source mount can be changed directly. For instance if / is the
865 source mount for /foo, then use mount --make-shared / to convert / into
866 a shared mount.
867
870 Build an image using local Dockerfiles
871 buildah bud .
872 buildah bud -f Dockerfile.simple .
875 cat /Dockerfile | buildah bud -f - .
878 buildah bud -f Dockerfile.simple -f Dockerfile.notsosimple .
881 buildah bud -t imageName .
884 buildah bud --tls-verify=true -t imageName -f Dockerfile.simple .
887 buildah bud --tls-verify=false -t imageName .
890 buildah bud --runtime-flag log-format=json .
893 buildah bud --runtime-flag debug .
896 buildah bud --authfile /tmp/auths/myauths.json --cert-dir /auth
899 --tls-verify=true --creds=username:password -t imageName -f Docker‐
900 file.simple .
901 buildah bud --memory 40m --cpu-period 10000 --cpu-quota 50000 --ulimit
904 nofile=1024:1028 -t imageName .
905 buildah bud --security-opt label=level:s0:c100,c200 --cgroup-parent
908 /path/to/cgroup/parent -t imageName .
909 buildah bud --volume /home/test:/myvol:ro,Z -t imageName .
912 buildah bud -v /var/lib/dnf:/var/lib/dnf:O -t imageName .
915 buildah bud --layers -t imageName .
918 buildah bud --no-cache -t imageName .
921 buildah bud --layers --force-rm -t imageName .
924 buildah bud --no-cache --rm=false -t imageName .
927 buildah bud --dns-search=example.com --dns=223.5.5.5
930 --dns-option=use-vc .
931 Building an image using a URL
934 This will clone the specified GitHub repository from the URL and use it
935 as context. The Dockerfile at the root of the repository is used as
936 Dockerfile. This only works if the GitHub repository is a dedicated
937 repository.
938 buildah bud github.com/scollier/purpletest
941 Note: You can set an arbitrary Git repository via the git:// scheme.
944 Building an image using a URL to a tarball'ed context
947 Buildah will fetch the tarball archive, decompress it and use its con‐
948 tents as the build context. The Dockerfile at the root of the archive
949 and the rest of the archive will get used as the context of the build.
950 If you pass an -f PATH/Dockerfile option as well, the system will look
951 for that file inside the contents of the tarball.
952 buildah bud -f dev/Dockerfile ⟨https://10.10.10.1/docker/con‐
955 text.tar.gz⟩
956 Note: supported compression formats are 'xz', 'bzip2', 'gzip' and
959 'identity' (no compression).
960
963 registries.conf (/etc/containers/registries.conf)
964 registries.conf is the configuration file which specifies which con‐
967 tainer registries should be consulted when completing image names which
968 do not include a registry or domain portion.
969 policy.json (/etc/containers/policy.json)
972 Signature policy file. This defines the trust policy for container
975 images. Controls which container registries can be used for image, and
976 whether or not the tool should trust the images.
977
980 buildah(1), CPP(1), buildah-login(1), docker-login(1), namespaces(7),
981 pid_namespaces(7), policy.json(5), registries.conf(5), user_names‐
982 paces(7)
983buildah April 2017 buildah-bud(1)