1podman-build(1)() podman-build(1)()
2
6 podman-build - Build a container image using a Containerfile
7
10 podman build [options] [context]
11 podman image build [options] [context]
14
17 podman build Builds an image using instructions from one or more Con‐
18 tainerfiles or Dockerfiles and a specified build context directory. A
19 Containerfile uses the same syntax as a Dockerfile internally. For this
20 document, a file referred to as a Containerfile can be a file named
21 either 'Containerfile' or 'Dockerfile'.
22 The build context directory can be specified as the http(s) URL of an
25 archive, git repository or Containerfile.
26 If no context directory is specified, then Podman will assume the cur‐
29 rent working directory as the build context, which should contain the
30 Containerfile.
31 Containerfiles ending with a ".in" suffix will be preprocessed via
34 CPP(1). This can be useful to decompose Containerfiles into several
35 reusable parts that can be used via CPP's #include directive. Notice,
36 a Containerfile.in file can still be used by other tools when manually
37 preprocessing them via cpp -E.
38 When the URL is an archive, the contents of the URL is downloaded to a
41 temporary location and extracted before execution.
42 When the URL is an Containerfile, the Containerfile is downloaded to a
45 temporary location.
46 When a Git repository is set as the URL, the repository is cloned
49 locally and then set as the context.
50
53 --add-host=host
54 Add a custom host-to-IP mapping (host:ip)
57 Add a line to /etc/hosts. The format is hostname:ip. The --add-host
60 option can be set multiple times.
61 --annotation=annotation
64 Add an image annotation (e.g. annotation=value) to the image metadata.
67 Can be used multiple times.
68 Note: this information is not present in Docker image formats, so it is
71 discarded when writing images in Docker formats.
72 --arch=arch
75 Set the ARCH of the image to the provided value instead of the archi‐
78 tecture of the host.
79 --authfile=path
82 Path of the authentication file. Default is ${XDG_RUNTIME_DIR}/contain‐
85 ers/auth.json, which is set using podman login. If the authorization
86 state is not found there, $HOME/.docker/config.json is checked, which
87 is set using docker login. (Not available for remote commands)
88 Note: You can also override the default path of the authentication file
91 by setting the REGISTRY_AUTH_FILE environment variable. export REG‐
92 ISTRY_AUTH_FILE=path
93 --build-arg=arg=value
96 Specifies a build argument and its value, which will be interpolated in
99 instructions read from the Containerfiles in the same way that environ‐
100 ment variables are, but which will not be added to environment variable
101 list in the resulting image's configuration.
102 --cache-from
105 Images to utilize as potential cache sources. Podman does not currently
108 support caching so this is a NOOP.
109 --cap-add=CAP_xxx
112 When executing RUN instructions, run the command specified in the
115 instruction with the specified capability added to its capability set.
116 Certain capabilities are granted by default; this option can be used to
117 add more.
118 --cap-drop=CAP_xxx
121 When executing RUN instructions, run the command specified in the
124 instruction with the specified capability removed from its capability
125 set. The CAP_AUDIT_WRITE, CAP_CHOWN, CAP_DAC_OVERRIDE, CAP_FOWNER,
126 CAP_FSETID, CAP_KILL, CAP_MKNOD, CAP_NET_BIND_SERVICE, CAP_SETFCAP,
127 CAP_SETGID, CAP_SETPCAP, CAP_SETUID, and CAP_SYS_CHROOT capabilities
128 are granted by default; this option can be used to remove them.
129 If a capability is specified to both the --cap-add and --cap-drop
132 options, it will be dropped, regardless of the order in which the
133 options were given.
134 --cert-dir=path
137 Use certificates at path (*.crt, *.cert, *.key) to connect to the reg‐
140 istry. Default certificates directory is /etc/containers/certs.d. (Not
141 available for remote commands)
142 --cgroup-parent=path
145 Path to cgroups under which the cgroup for the container will be cre‐
148 ated. If the path is not absolute, the path is considered to be rela‐
149 tive to the cgroups path of the init process. Cgroups will be created
150 if they do not already exist.
151 --compress
154 This option is added to be aligned with other containers CLIs. Podman
157 doesn't communicate with a daemon or a remote server. Thus, compress‐
158 ing the data before sending it is irrelevant to Podman.
159 --cni-config-dir=directory
162 Location of CNI configuration files which will dictate which plugins
165 will be used to configure network interfaces and routing for containers
166 created for handling RUN instructions, if those containers will be run
167 in their own network namespaces, and networking is not disabled.
168 --cni-plugin-path=directory[:directory[:directory[...]]]
171 List of directories in which the CNI plugins which will be used for
174 configuring network namespaces can be found.
175 --cpu-period=limit
178 Limit the CPU CFS (Completely Fair Scheduler) period
181 Limit the container's CPU usage. This flag tell the kernel to restrict
184 the container's CPU usage to the period you specify.
185 --cpu-quota=limit
188 Limit the CPU CFS (Completely Fair Scheduler) quota
191 Limit the container's CPU usage. By default, containers run with the
194 full CPU resource. This flag tell the kernel to restrict the con‐
195 tainer's CPU usage to the quota you specify.
196 --cpu-shares, -c=shares
199 CPU shares (relative weight)
202 By default, all containers get the same proportion of CPU cycles. This
205 proportion can be modified by changing the container's CPU share
206 weighting relative to the weighting of all other running containers.
207 To modify the proportion from the default of 1024, use the --cpu-shares
210 flag to set the weighting to 2 or higher.
211 The proportion will only apply when CPU-intensive processes are run‐
214 ning. When tasks in one container are idle, other containers can use
215 the left-over CPU time. The actual amount of CPU time will vary depend‐
216 ing on the number of containers running on the system.
217 For example, consider three containers, one has a cpu-share of 1024 and
220 two others have a cpu-share setting of 512. When processes in all three
221 containers attempt to use 100% of CPU, the first container would
222 receive 50% of the total CPU time. If you add a fourth container with a
223 cpu-share of 1024, the first container only gets 33% of the CPU. The
224 remaining containers receive 16.5%, 16.5% and 33% of the CPU.
225 On a multi-core system, the shares of CPU time are distributed over all
228 CPU cores. Even if a container is limited to less than 100% of CPU
229 time, it can use 100% of each individual CPU core.
230 For example, consider a system with more than three cores. If you start
233 one container {C0} with -c=512 running one process, and another con‐
234 tainer {C1} with -c=1024 running two processes, this can result in the
235 following division of CPU shares:
236 PID container CPU CPU share
239 100 {C0} 0 100% of CPU0
240 101 {C1} 1 100% of CPU1
241 102 {C1} 2 100% of CPU2
242 --cpuset-cpus=num
246 CPUs in which to allow execution (0-3, 0,1)
249 --cpuset-mems=nodes
252 Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effec‐
255 tive on NUMA systems.
256 If you have four memory nodes on your system (0-3), use
259 --cpuset-mems=0,1 then processes in your container will only use memory
260 from the first two memory nodes.
261 --creds=creds
264 The [username[:password]] to use to authenticate with the registry if
267 required. If one or both values are not supplied, a command line
268 prompt will appear and the value can be entered. The password is
269 entered without echo.
270 --device=host-device[:container-device][:permissions]
273 Add a host device to the container. Optional permissions parameter can
276 be used to specify device permissions, it is combination of r for read,
277 w for write, and m for mknod(2).
278 Example: --device=/dev/sdc:/dev/xvdc:rwm.
281 Note: if _hostdevice is a symbolic link then it will be resolved first.
284 The container will only store the major and minor numbers of the host
285 device.
286 Note: if the user only has access rights via a group, accessing the
289 device from inside a rootless container will fail. The crun(1) runtime
290 offers a workaround for this by adding the option --annotation
291 run.oci.keep_original_groups=1.
292 --disable-compression, -D
295 Don't compress filesystem layers when building the image unless it is
298 required by the location where the image is being written. This is the
299 default setting, because image layers are compressed automatically when
300 they are pushed to registries, and images being written to local stor‐
301 age would only need to be decompressed again to be stored. Compression
302 can be forced in all cases by specifying --disable-compression=false.
303 --disable-content-trust
306 This is a Docker specific option to disable image verification to a
309 Docker registry and is not supported by Podman. This flag is a NOOP
310 and provided solely for scripting compatibility.
311 --dns=dns
314 Set custom DNS servers
317 This option can be used to override the DNS configuration passed to the
320 container. Typically this is necessary when the host DNS configuration
321 is invalid for the container (e.g., 127.0.0.1). When this is the case
322 the --dns flag is necessary for every run.
323 The special value none can be specified to disable creation of
326 /etc/resolv.conf in the container by Podman. The /etc/resolv.conf file
327 in the image will be used without changes.
328 --dns-option=option
331 Set custom DNS options
334 --dns-search=domain
337 Set custom DNS search domains
340 --file, -f=Containerfile
343 Specifies a Containerfile which contains instructions for building the
346 image, either a local file or an http or https URL. If more than one
347 Containerfile is specified, FROM instructions will only be accepted
348 from the first specified file.
349 If a build context is not specified, and at least one Containerfile is
352 a local file, the directory in which it resides will be used as the
353 build context.
354 If you specify -f -, the Containerfile contents will be read from
357 stdin.
358 --force-rm=true|false
361 Always remove intermediate containers after a build, even if the build
364 fails (default false).
365 --format
368 Control the format for the built image's manifest and configuration
371 data. Recognized formats include oci (OCI image-spec v1.0, the
372 default) and docker (version 2, using schema format 2 for the mani‐
373 fest).
374 Note: You can also override the default format by setting the BUIL‐
377 DAH_FORMAT environment variable. export BUILDAH_FORMAT=docker
378 -h, --help
381 Print usage statement
384 --http-proxy
387 Pass through HTTP Proxy environment variables.
390 --iidfile=ImageIDfile
393 Write the image ID to the file.
396 --ipc=how
399 Sets the configuration for IPC namespaces when handling RUN instruc‐
402 tions. The configured value can be "" (the empty string) or "con‐
403 tainer" to indicate that a new IPC namespace should be created, or it
404 can be "host" to indicate that the IPC namespace in which podman itself
405 is being run should be reused, or it can be the path to an IPC names‐
406 pace which is already in use by another process.
407 --isolation=type
410 Controls what type of isolation is used for running processes as part
413 of RUN instructions. Recognized types include oci (OCI-compatible run‐
414 time, the default), rootless (OCI-compatible runtime invoked using a
415 modified configuration and its --rootless flag enabled, with
416 --no-new-keyring --no-pivot added to its create invocation, with net‐
417 work and UTS namespaces disabled, and IPC, PID, and user namespaces
418 enabled; the default for unprivileged users), and chroot (an internal
419 wrapper that leans more toward chroot(1) than container technology).
420 Note: You can also override the default isolation type by setting the
423 BUILDAH_ISOLATION environment variable. export BUILDAH_ISOLATION=oci
424 --label=label
427 Add an image label (e.g. label=value) to the image metadata. Can be
430 used multiple times.
431 Users can set a special LABEL io.containers.capabilities=CAP1,CAP2,CAP3
434 in a Containerfile that specified the list of Linux capabilities
435 required for the container to run properly. This label specified in a
436 container image tells Podman to run the container with just these capa‐
437 bilities. Podman launches the container with just the specified capa‐
438 bilities, as long as this list of capabilities is a subset of the
439 default list.
440 If the specified capabilities are not in the default set, Podman will
443 print an error message and will run the container with the default
444 capabilities.
445 --layers
448 Cache intermediate images during the build process (Default is true).
451 Note: You can also override the default value of layers by setting the
454 BUILDAH_LAYERS environment variable. export BUILDAH_LAYERS=true
455 --logfile=filename
458 Log output which would be sent to standard output and standard error to
461 the specified file instead of to standard output and standard error.
462 --loglevel number
465 Adjust the logging level up or down. Valid option values range from -2
468 to 3, with 3 being roughly equivalent to using the global --debug
469 option, and values below 0 omitting even error messages which accompany
470 fatal errors.
471 --memory, -m=LIMIT Memory limit (format: [], where unit = b (bytes), k
474 (kilobytes), m (megabytes), or g (gigabytes))
475 Allows you to constrain the memory available to a container. If the
478 host supports swap memory, then the -m memory setting can be larger
479 than physical RAM. If a limit of 0 is specified (not using -m), the
480 container's memory is not limited. The actual limit may be rounded up
481 to a multiple of the operating system's page size (the value would be
482 very large, that's millions of trillions).
483 --memory-swap=LIMIT
486 A limit value equal to memory plus swap. Must be used with the -m
489 (--memory) flag. The swap LIMIT should always be larger than -m (--mem‐
490 ory) value. By default, the swap LIMIT will be set to double the value
491 of --memory.
492 The format of LIMIT is <number>[<unit>]. Unit can be b (bytes), k
495 (kilobytes), m (megabytes), or g (gigabytes). If you don't specify a
496 unit, b is used. Set LIMIT to -1 to enable unlimited swap.
497 --net, --network=string
500 Sets the configuration for network namespaces when handling RUN
503 instructions. The configured value can be "" (the empty string) or
504 "container" to indicate that a new network namespace should be created,
505 or it can be "host" to indicate that the network namespace in which
506 podman itself is being run should be reused, or it can be the path to a
507 network namespace which is already in use by another process.
508 --no-cache
511 Do not use existing cached images for the container build. Build from
514 the start with a new set of cached layers.
515 --os=string
518 Set the OS to the provided value instead of the current operating sys‐
521 tem of the host.
522 --pid=pid
525 Sets the configuration for PID namespaces when handling RUN instruc‐
528 tions. The configured value can be "" (the empty string) or "con‐
529 tainer" to indicate that a new PID namespace should be created, or it
530 can be "host" to indicate that the PID namespace in which podman itself
531 is being run should be reused, or it can be the path to a PID namespace
532 which is already in use by another process.
533 --platform="Linux"
536 This option has no effect on the build. Other container engines use
539 this option to control the execution platform for the build (e.g., Win‐
540 dows, Linux) which is not required for Buildah as it supports only
541 Linux.
542 --pull
545 When the flag is enabled, attempt to pull the latest image from the
548 registries listed in registries.conf if a local image does not exist or
549 the image is newer than the one in storage. Raise an error if the image
550 is not in any listed registry and is not present locally.
551 If the flag is disabled (with --pull=false), do not pull the image from
554 the registry, unless there is no local image. Raise an error if the
555 image is not in any registry and is not present locally.
556 Defaults to true.
559 --pull-always
562 Pull the image from the first registry it is found in as listed in reg‐
565 istries.conf. Raise an error if not found in the registries, even if
566 the image is present locally.
567 --pull-never
570 Do not pull the image from the registry, use only the local version.
573 Raise an error if the image is not present locally.
574 --quiet, -q
577 Suppress output messages which indicate which instruction is being pro‐
580 cessed, and of progress when pulling images from a registry, and when
581 writing the output image.
582 --rm=true|false
585 Remove intermediate containers after a successful build (default true).
588 --runtime=path
591 The path to an alternate OCI-compatible runtime, which will be used to
594 run commands specified by the RUN instruction.
595 Note: You can also override the default runtime by setting the BUIL‐
598 DAH_RUNTIME environment variable. export BUILDAH_RUN‐
599 TIME=/usr/local/bin/runc
600 --runtime-flag=flag
603 Adds global flags for the container runtime. To list the supported
606 flags, please consult the manpages of the selected container runtime
607 (runc is the default runtime, the manpage to consult is runc(8). When
608 the machine is configured for cgroup V2, the default runtime is crun,
609 the manpage to consult is crun(8).).
610 Note: Do not pass the leading -- to the flag. To pass the runc flag
613 --log-format json to podman build, the option given would be --run‐
614 time-flag log-format=json.
615 --security-opt=option
618 Security Options
621 · apparmor=unconfined : Turn off apparmor confinement for the
624 container
625 · apparmor=your-profile : Set the apparmor confinement profile
627 for the container
628 · label=user:USER : Set the label user for the container
630 processes
631 · label=role:ROLE : Set the label role for the container
633 processes
634 · label=type:TYPE : Set the label process type for the con‐
636 tainer processes
637 · label=level:LEVEL : Set the label level for the container
639 processes
640 · label=filetype:TYPE : Set the label file type for the con‐
642 tainer files
643 · label=disable : Turn off label separation for the con‐
645 tainer
646 · seccomp=unconfined : Turn off seccomp confinement for the con‐
648 tainer
649 · seccomp=profile.json : White listed syscalls seccomp Json
651 file to be used as a seccomp filter
652 --shm-size=size
656 Size of /dev/shm. The format is <number><unit>. number must be greater
659 than 0. Unit is optional and can be b (bytes), k (kilobytes),
660 m(megabytes), or g (gigabytes). If you omit the unit, the system uses
661 bytes. If you omit the size entirely, the system uses 64m.
662 --sign-by=fingerprint
665 Sign the image using a GPG key with the specified FINGERPRINT.
668 --squash
671 Squash all of the image's new layers into a single new layer; any pre‐
674 existing layers are not squashed.
675 --squash-all
678 Squash all of the new image's layers (including those inherited from a
681 base image) into a single new layer.
682 --tag, -t=imageName
685 Specifies the name which will be assigned to the resulting image if the
688 build process completes successfully. If imageName does not include a
689 registry name, the registry name localhost will be prepended to the
690 image name.
691 --target=stageName
694 Set the target build stage to build. When building a Containerfile
697 with multiple build stages, --target can be used to specify an interme‐
698 diate build stage by name as the final stage for the resulting image.
699 Commands after the target stage will be skipped.
700 --tls-verify=true|false
703 Require HTTPS and verify certificates when talking to container reg‐
706 istries (defaults to true). (Not available for remote commands)
707 --ulimit=type=soft-limit[:hard-limit]
710 Specifies resource limits to apply to processes launched when process‐
713 ing RUN instructions. This option can be specified multiple times.
714 Recognized resource types include:
715 "core": maximum core dump size (ulimit -c)
716 "cpu": maximum CPU time (ulimit -t)
717 "data": maximum size of a process's data segment (ulimit -d)
718 "fsize": maximum size of new files (ulimit -f)
719 "locks": maximum number of file locks (ulimit -x)
720 "memlock": maximum amount of locked memory (ulimit -l)
721 "msgqueue": maximum amount of data in message queues (ulimit -q)
722 "nice": niceness adjustment (nice -n, ulimit -e)
723 "nofile": maximum number of open files (ulimit -n)
724 "nproc": maximum number of processes (ulimit -u)
725 "rss": maximum size of a process's (ulimit -m)
726 "rtprio": maximum real-time scheduling priority (ulimit -r)
727 "rttime": maximum amount of real-time execution between blocking
728 syscalls
729 "sigpending": maximum number of pending signals (ulimit -i)
730 "stack": maximum stack size (ulimit -s)
731 --userns=how
734 Sets the configuration for user namespaces when handling RUN instruc‐
737 tions. The configured value can be "" (the empty string) or "con‐
738 tainer" to indicate that a new user namespace should be created, it can
739 be "host" to indicate that the user namespace in which podman itself is
740 being run should be reused, or it can be the path to an user namespace
741 which is already in use by another process.
742 --userns-uid-map=mapping
745 Directly specifies a UID mapping which should be used to set ownership,
748 at the filesystem level, on the working container's contents. Commands
749 run when handling RUN instructions will default to being run in their
750 own user namespaces, configured using the UID and GID maps.
751 Entries in this map take the form of one or more triples of a starting
754 in-container UID, a corresponding starting host-level UID, and the num‐
755 ber of consecutive IDs which the map entry represents.
756 This option overrides the remap-uids setting in the options section of
759 /etc/containers/storage.conf.
760 If this option is not specified, but a global --userns-uid-map setting
763 is supplied, settings from the global option will be used.
764 If none of --userns-uid-map-user, --userns-gid-map-group, or
767 --userns-uid-map are specified, but --userns-gid-map is specified, the
768 UID map will be set to use the same numeric values as the GID map.
769 --userns-gid-map=mapping
772 Directly specifies a GID mapping which should be used to set ownership,
775 at the filesystem level, on the working container's contents. Commands
776 run when handling RUN instructions will default to being run in their
777 own user namespaces, configured using the UID and GID maps.
778 Entries in this map take the form of one or more triples of a starting
781 in-container GID, a corresponding starting host-level GID, and the num‐
782 ber of consecutive IDs which the map entry represents.
783 This option overrides the remap-gids setting in the options section of
786 /etc/containers/storage.conf.
787 If this option is not specified, but a global --userns-gid-map setting
790 is supplied, settings from the global option will be used.
791 If none of --userns-uid-map-user, --userns-gid-map-group, or
794 --userns-gid-map are specified, but --userns-uid-map is specified, the
795 GID map will be set to use the same numeric values as the UID map.
796 --userns-uid-map-user=user
799 Specifies that a UID mapping which should be used to set ownership, at
802 the filesystem level, on the working container's contents, can be found
803 in entries in the /etc/subuid file which correspond to the specified
804 user. Commands run when handling RUN instructions will default to
805 being run in their own user namespaces, configured using the UID and
806 GID maps. If --userns-gid-map-group is specified, but
807 --userns-uid-map-user is not specified, podman will assume that the
808 specified group name is also a suitable user name to use as the default
809 setting for this option.
810 --userns-gid-map-group=group
813 Specifies that a GID mapping which should be used to set ownership, at
816 the filesystem level, on the working container's contents, can be found
817 in entries in the /etc/subgid file which correspond to the specified
818 group. Commands run when handling RUN instructions will default to
819 being run in their own user namespaces, configured using the UID and
820 GID maps. If --userns-uid-map-user is specified, but
821 --userns-gid-map-group is not specified, podman will assume that the
822 specified user name is also a suitable group name to use as the default
823 setting for this option.
824 --uts=how
827 Sets the configuration for UTS namespaces when the handling RUN
830 instructions. The configured value can be "" (the empty string) or
831 "container" to indicate that a new UTS namespace should be created, or
832 it can be "host" to indicate that the UTS namespace in which podman
833 itself is being run should be reused, or it can be the path to a UTS
834 namespace which is already in use by another process.
835 --volume, -v[=[HOST-DIR:CONTAINER-DIR[:OPTIONS]]]
838 Create a bind mount. If you specify, -v /HOST-DIR:/CONTAINER-DIR, Pod‐
841 man
842 bind mounts /HOST-DIR in the host to /CONTAINER-DIR in the Podman
843 container. The OPTIONS are a comma delimited list and can be:
844 · [rw|ro]
847 · [z|Z|O]
849 · [[r]shared|[r]slave|[r]private]
851 The CONTAINER-DIR must be an absolute path such as /src/docs. The
855 HOST-DIR must be an absolute path as well. Podman bind-mounts the
856 HOST-DIR to the path you specify. For example, if you supply /foo as
857 the host path, Podman copies the contents of /foo to the container
858 filesystem on the host and bind mounts that into the container.
859 You can specify multiple -v options to mount one or more mounts to a
862 container.
863 You can add the :ro or :rw suffix to a volume to mount it read-only or
866 read-write mode, respectively. By default, the volumes are mounted
867 read-write. See examples.
868 Labeling Volume Mounts
871 Labeling systems like SELinux require that proper labels are placed on
874 volume content mounted into a container. Without a label, the security
875 system might prevent the processes running inside the container from
876 using the content. By default, Podman does not change the labels set by
877 the OS.
878 To change a label in the container context, you can add either of two
881 suffixes :z or :Z to the volume mount. These suffixes tell Podman to
882 relabel file objects on the shared volumes. The z option tells Podman
883 that two containers share the volume content. As a result, Podman
884 labels the content with a shared content label. Shared volume labels
885 allow all containers to read/write content. The Z option tells Podman
886 to label the content with a private unshared label. Only the current
887 container can use a private volume.
888 Overlay Volume Mounts
891 The :O flag tells Podman to mount the directory from the host as a tem‐
894 porary storage using the Overlay file system. The RUN command contain‐
895 ers are allowed to modify contents within the mountpoint and are stored
896 in the container storage in a separate directory. In Overlay FS terms
897 the source directory will be the lower, and the container storage
898 directory will be the upper. Modifications to the mount point are
899 destroyed when the RUN command finishes executing, similar to a tmpfs
900 mount point.
901 Any subsequent execution of RUN commands sees the original source
904 directory content, any changes from previous RUN commands no longer
905 exists.
906 One use case of the overlay mount is sharing the package cache from the
909 host into the container to allow speeding up builds.
910 Note:
913 - Overlay mounts are not currently supported in rootless mode.
916 - 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.
917 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.
918 - 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.
919 By default bind mounted volumes are private. That means any mounts done
923 inside container will not be visible on the host and vice versa. This
924 behavior can be changed by specifying a volume mount propagation prop‐
925 erty.
926 When the mount propagation policy is set to shared, any mounts com‐
929 pleted inside the container on that volume will be visible to both the
930 host and container. When the mount propagation policy is set to slave,
931 one way mount propagation is enabled and any mounts completed on the
932 host for that volume will be visible only inside of the container. To
933 control the mount propagation property of volume use the :[r]shared,
934 :[r]slave or :[r]private propagation flag. The propagation property can
935 be specified only for bind mounted volumes and not for internal volumes
936 or named volumes. For mount propagation to work on the source mount
937 point (mount point where source dir is mounted on) has to have the
938 right propagation properties. For shared volumes, the source mount
939 point has to be shared. And for slave volumes, the source mount has to
940 be either shared or slave.
941 Use df <source-dir> to determine the source mount and then use findmnt
944 -o TARGET,PROPAGATION <source-mount-dir> to determine propagation prop‐
945 erties of source mount, if findmnt utility is not available, the source
946 mount point can be determined by looking at the mount entry in
947 /proc/self/mountinfo. Look at optional fields and see if any propaga‐
948 tion properties are specified. shared:X means the mount is shared,
949 master:X means the mount is slave and if nothing is there that means
950 the mount is private.
951 To change propagation properties of a mount point use the mount com‐
954 mand. For example, to bind mount the source directory /foo do mount
955 --bind /foo /foo and mount --make-private --make-shared /foo. This will
956 convert /foo into a shared mount point. The propagation properties of
957 the source mount can be changed directly. For instance if / is the
958 source mount for /foo, then use mount --make-shared / to convert / into
959 a shared mount.
960
963 Build an image using local Containerfiles
964 $ podman build .
965 $ podman build -f Containerfile.simple .
967 $ cat $HOME/Dockerfile | podman build -f - .
969 $ podman build -f Dockerfile.simple -f Containerfile.notsosimple .
971 $ podman build -f Dockerfile.in $HOME
973 $ podman build -t imageName .
975 $ podman build --tls-verify=true -t imageName -f Dockerfile.simple .
977 $ podman build --tls-verify=false -t imageName .
979 $ podman build --runtime-flag log-format=json .
981 $ podman build --runtime-flag debug .
983 $ podman build --authfile /tmp/auths/myauths.json --cert-dir $HOME/auth --tls-verify=true --creds=username:password -t imageName -f Dockerfile.simple .
985 $ podman build --memory 40m --cpu-period 10000 --cpu-quota 50000 --ulimit nofile=1024:1028 -t imageName .
987 $ podman build --security-opt label=level:s0:c100,c200 --cgroup-parent /path/to/cgroup/parent -t imageName .
989 $ podman build --volume /home/test:/myvol:ro,Z -t imageName .
991 $ podman build -v /var/lib/yum:/var/lib/yum:O -t imageName .
993 $ podman build --layers -t imageName .
995 $ podman build --no-cache -t imageName .
997 $ podman build --layers --force-rm -t imageName .
999 $ podman build --no-cache --rm=false -t imageName .
1001 Building an image using a URL, Git repo, or archive
1005 The build context directory can be specified as a URL to a Container‐
1006 file, a Git repository, or URL to an archive. If the URL is a Contain‐
1007 erfile, it is downloaded to a temporary location and used as the con‐
1008 text. When a Git repository is set as the URL, the repository is cloned
1009 locally to a temporary location and then used as the context. Lastly,
1010 if the URL is an archive, it is downloaded to a temporary location and
1011 extracted before being used as the context.
1012 Building an image using a URL to a Containerfile
1015 Podman will download the Containerfile to a temporary location and then
1016 use it as the build context.
1017 $ podman build https://10.10.10.1/podman/Containerfile
1020 Building an image using a Git repository
1024 Podman will clone the specified GitHub repository to a temporary loca‐
1025 tion and use it as the context. The Containerfile at the root of the
1026 repository will be used and it only works if the GitHub repository is a
1027 dedicated repository.
1028 $ podman build git://github.com/scollier/purpletest
1031 Building an image using a URL to an archive
1035 Podman will fetch the archive file, decompress it, and use its contents
1036 as the build context. The Containerfile at the root of the archive and
1037 the rest of the archive will get used as the context of the build. If
1038 you pass -f PATH/Containerfile option as well, the system will look for
1039 that file inside the contents of the archive.
1040 $ podman build -f dev/Containerfile https://10.10.10.1/podman/context.tar.gz
1043 Note: supported compression formats are 'xz', 'bzip2', 'gzip' and
1047 'identity' (no compression).
1048
1051 registries.conf (/etc/containers/registries.conf)
1052 registries.conf is the configuration file which specifies which con‐
1055 tainer registries should be consulted when completing image names which
1056 do not include a registry or domain portion.
1057
1060 If you are using a useradd command within a Containerfile with a large
1061 UID/GID, it will create a large sparse file /var/log/lastlog. This can
1062 cause the build to hang forever. Go language does not support sparse
1063 files correctly, which can lead to some huge files being created in
1064 your container image.
1065 Solution
1068 If you are using useradd within your build script, you should pass the
1069 --no-log-init or -l option to the useradd command. This option tells
1070 useradd to stop creating the lastlog file.
1071
1074 podman(1), buildah(1), containers-registries.conf(5), crun(8), runc(8),
1075 useradd(8)
1076
1079 May 2018, Minor revisions added by Joe Doss joe@solidadmin.com
1080 ⟨mailto:joe@solidadmin.com⟩
1081 December 2017, Originally compiled by Tom Sweeney tsweeney@redhat.com
1084 ⟨mailto:tsweeney@redhat.com⟩
1085 podman-build(1)()