1buildah-from(1) General Commands Manual buildah-from(1)
2
3
4
6 buildah-from - Creates a new working container, either from scratch or
7 using a specified image as a starting point.
8
9
11 buildah from [options] image
12
13
15 Creates a working container based upon the specified image name. If
16 the supplied image name is "scratch" a new empty container is created.
17 Image names use a "transport":"details" format.
18
19
20 Multiple transports are supported:
21
22
23 dir:path
24 An existing local directory path containing the manifest, layer tar‐
25 balls, and signatures in individual files. This is a non-standardized
26 format, primarily useful for debugging or noninvasive image inspection.
27
28
29 docker://docker-reference (Default)
30 An image in a registry implementing the "Docker Registry HTTP API
31 V2". By default, uses the authorization state in $XDG\_RUN‐
32 TIME\_DIR/containers/auth.json, which is set using (buildah login). If
33 XDG_RUNTIME_DIR is not set, the default is /run/contain‐
34 ers/$UID/auth.json. If the authorization state is not found there,
35 $HOME/.docker/config.json is checked, which is set using (docker lo‐
36 gin).
37 If docker-reference does not include a registry name, localhost will
38 be consulted first, followed by any registries named in the registries
39 configuration.
40
41
42 docker-archive:path
43 An image is retrieved as a docker load formatted file.
44
45
46 docker-daemon:docker-reference
47 An image docker-reference stored in the docker daemon's internal
48 storage. docker-reference must include either a tag or a digest. Al‐
49 ternatively, when reading images, the format can also be docker-dae‐
50 mon:algo:digest (an image ID).
51
52
53 oci:path:tag**
54 An image tag in a directory compliant with "Open Container Image Lay‐
55 out Specification" at path.
56
57
58 oci-archive:path:tag
59 An image tag in a directory compliant with "Open Container Image Lay‐
60 out Specification" at path.
61
62
63 DEPENDENCIES
64 Buildah resolves the path to the registry to pull from by using the
65 /etc/containers/registries.conf file, containers-registries.conf(5).
66 If the buildah from command fails with an "image not known" error,
67 first verify that the registries.conf file is installed and configured
68 appropriately.
69
70
72 The container ID of the container that was created. On error 1 is re‐
73 turned.
74
75
77 --add-host=[]
78
79
80 Add a custom host-to-IP mapping (host:ip)
81
82
83 Add a line to /etc/hosts. The format is hostname:ip. The --add-host op‐
84 tion can be set multiple times.
85
86
87 --arch="ARCH"
88
89
90 Set the ARCH of the image to be pulled to the provided value instead of
91 using the architecture of the host. (Examples: arm, arm64, 386, amd64,
92 ppc64le, s390x)
93
94
95 --authfile path
96
97
98 Path of the authentication file. Default is ${XDG_\RUNTIME_DIR}/con‐
99 tainers/auth.json. If XDG_RUNTIME_DIR is not set, the default is
100 /run/containers/$UID/auth.json. This file is created using using buil‐
101 dah login.
102
103
104 If the authorization state is not found there, $HOME/.docker/con‐
105 fig.json is checked, which is set using docker login.
106
107
108 Note: You can also override the default path of the authentication file
109 by setting the REGISTRY_AUTH_FILE environment variable. export REG‐
110 ISTRY_AUTH_FILE=path
111
112
113 --cap-add=CAP_xxx
114
115
116 Add the specified capability to the default set of capabilities which
117 will be supplied for subsequent buildah run invocations which use this
118 container. Certain capabilities are granted by default; this option
119 can be used to add more.
120
121
122 --cap-drop=CAP_xxx
123
124
125 Remove the specified capability from the default set of capabilities
126 which will be supplied for subsequent buildah run invocations which use
127 this container. The CAP_AUDIT_WRITE, CAP_CHOWN, CAP_DAC_OVERRIDE,
128 CAP_FOWNER, CAP_FSETID, CAP_KILL, CAP_MKNOD, CAP_NET_BIND_SERVICE,
129 CAP_SETFCAP, CAP_SETGID, CAP_SETPCAP, CAP_SETUID, and CAP_SYS_CHROOT
130 capabilities are granted by default; this option can be used to remove
131 them.
132
133
134 If a capability is specified to both the --cap-add and --cap-drop op‐
135 tions, it will be dropped, regardless of the order in which the options
136 were given.
137
138
139 --cert-dir path
140
141
142 Use certificates at path (*.crt, *.cert, *.key) to connect to the reg‐
143 istry. The default certificates directory is /etc/containers/certs.d.
144
145
146 --cgroup-parent=""
147
148
149 Path to cgroups under which the cgroup for the container will be cre‐
150 ated. If the path is not absolute, the path is considered to be rela‐
151 tive to the cgroups path of the init process. Cgroups will be created
152 if they do not already exist.
153
154
155 --cidfile ContainerIDFile
156
157
158 Write the container ID to the file.
159
160
161 --cni-config-dir=directory
162
163
164 Location of CNI configuration files which will dictate which plugins
165 will be used to configure network interfaces and routing when the con‐
166 tainer is subsequently used for buildah run, if processes to be started
167 will be run in their own network namespaces, and networking is not dis‐
168 abled.
169
170
171 --cni-plugin-path=directory[:directory[:directory[...]]]
172
173
174 List of directories in which the CNI plugins which will be used for
175 configuring network namespaces can be found.
176
177
178 --cpu-period=0
179
180
181 Limit the CPU CFS (Completely Fair Scheduler) period
182
183
184 Limit the container's CPU usage. This flag tell the kernel to restrict
185 the container's CPU usage to the period you specify.
186
187
188 --cpu-quota=0
189
190
191 Limit the CPU CFS (Completely Fair Scheduler) quota
192
193
194 Limit the container's CPU usage. By default, containers run with the
195 full CPU resource. This flag tell the kernel to restrict the con‐
196 tainer's CPU usage to the quota you specify.
197
198
199 --cpu-shares, -c=0
200
201
202 CPU shares (relative weight)
203
204
205 By default, all containers get the same proportion of CPU cycles. This
206 proportion can be modified by changing the container's CPU share
207 weighting relative to the weighting of all other running containers.
208
209
210 To modify the proportion from the default of 1024, use the --cpu-shares
211 flag to set the weighting to 2 or higher.
212
213
214 The proportion will only apply when CPU-intensive processes are run‐
215 ning. When tasks in one container are idle, other containers can use
216 the left-over CPU time. The actual amount of CPU time will vary depend‐
217 ing on the number of containers running on the system.
218
219
220 For example, consider three containers, one has a cpu-share of 1024 and
221 two others have a cpu-share setting of 512. When processes in all three
222 containers attempt to use 100% of CPU, the first container would re‐
223 ceive 50% of the total CPU time. If you add a fourth container with a
224 cpu-share of 1024, the first container only gets 33% of the CPU. The
225 remaining containers receive 16.5%, 16.5% and 33% of the CPU.
226
227
228 On a multi-core system, the shares of CPU time are distributed over all
229 CPU cores. Even if a container is limited to less than 100% of CPU
230 time, it can use 100% of each individual CPU core.
231
232
233 For example, consider a system with more than three cores. If you start
234 one container {C0} with -c=512 running one process, and another con‐
235 tainer {C1} with -c=1024 running two processes, this can result in the
236 following division of CPU shares:
237
238
239 PID container CPU CPU share
240 100 {C0} 0 100% of CPU0
241 101 {C1} 1 100% of CPU1
242 102 {C1} 2 100% of CPU2
243
244
245
246 --cpuset-cpus=""
247
248
249 CPUs in which to allow execution (0-3, 0,1)
250
251
252 --cpuset-mems=""
253
254
255 Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effec‐
256 tive on NUMA systems.
257
258
259 If you have four memory nodes on your system (0-3), use --cpuset-
260 mems=0,1 then processes in your container will only use memory from the
261 first two memory nodes.
262
263
264 --creds creds
265
266
267 The [username[:password]] to use to authenticate with the registry if
268 required. If one or both values are not supplied, a command line
269 prompt will appear and the value can be entered. The password is en‐
270 tered without echo.
271
272
273 --decryption-key key[:passphrase]
274
275
276 The [key[:passphrase]] to be used for decryption of images. Key can
277 point to keys and/or certificates. Decryption will be tried with all
278 keys. If the key is protected by a passphrase, it is required to be
279 passed in the argument and omitted otherwise.
280
281
282 --device=device
283
284
285 Add a host device or devices under a directory to the container. The
286 format is <device-on-host>[:<device-on-container>][:<permissions>]
287 (e.g. --device=/dev/sdc:/dev/xvdc:rwm)
288
289
290 --dns=[]
291
292
293 Set custom DNS servers
294
295
296 This option can be used to override the DNS configuration passed to the
297 container. Typically this is necessary when the host DNS configuration
298 is invalid for the container (e.g., 127.0.0.1). When this is the case
299 the --dns flag is necessary for every run.
300
301
302 The special value none can be specified to disable creation of /etc/re‐
303 solv.conf in the container by Buildah. The /etc/resolv.conf file in the
304 image will be used without changes.
305
306
307 --dns-option=[]
308
309
310 Set custom DNS options
311
312
313 --dns-search=[]
314
315
316 Set custom DNS search domains
317
318
319 --format, -f oci | docker
320
321
322 Control the format for the built image's manifest and configuration
323 data. Recognized formats include oci (OCI image-spec v1.0, the de‐
324 fault) and docker (version 2, using schema format 2 for the manifest).
325
326
327 Note: You can also override the default format by setting the BUIL‐
328 DAH_FORMAT environment variable. export BUILDAH_FORMAT=docker
329
330
331 --http-proxy
332
333
334 By default proxy environment variables are passed into the container if
335 set for the Buildah process. This can be disabled by setting the
336 --http-proxy option to false. The environment variables passed in in‐
337 clude http_proxy, https_proxy, ftp_proxy, no_proxy, and also the upper
338 case versions of those.
339
340
341 Defaults to true
342
343
344 --ipc how
345
346
347 Sets the configuration for IPC namespaces when the container is subse‐
348 quently used for buildah run. The configured value can be "" (the
349 empty string) or "container" to indicate that a new IPC namespace
350 should be created, or it can be "host" to indicate that the IPC name‐
351 space in which Buildah itself is being run should be reused, or it can
352 be the path to an IPC namespace which is already in use by another
353 process.
354
355
356 --isolation type
357
358
359 Controls what type of isolation is used for running processes under
360 buildah run. Recognized types include oci (OCI-compatible runtime, the
361 default), rootless (OCI-compatible runtime invoked using a modified
362 configuration, with --no-new-keyring added to its create invocation,
363 reusing the host's network and UTS namespaces, and creating private
364 IPC, PID, mount, and user namespaces; the default for unprivileged
365 users), and chroot (an internal wrapper that leans more toward ch‐
366 root(1) than container technology, reusing the host's control group,
367 network, IPC, and PID namespaces, and creating private mount and UTS
368 namespaces, and creating user namespaces only when they're required for
369 ID mapping).
370
371
372 Note: You can also override the default isolation type by setting the
373 BUILDAH_ISOLATION environment variable. export BUILDAH_ISOLATION=oci
374
375
376 --memory, -m=""
377
378
379 Memory limit (format: [], where unit = b, k, m or g)
380
381
382 Allows you to constrain the memory available to a container. If the
383 host supports swap memory, then the -m memory setting can be larger
384 than physical RAM. If a limit of 0 is specified (not using -m), the
385 container's memory is not limited. The actual limit may be rounded up
386 to a multiple of the operating system's page size (the value would be
387 very large, that's millions of trillions).
388
389
390 --memory-swap="LIMIT"
391
392
393 A limit value equal to memory plus swap. Must be used with the -m
394 (--memory) flag. The swap LIMIT should always be larger than -m (--mem‐
395 ory) value. By default, the swap LIMIT will be set to double the value
396 of --memory.
397
398
399 The format of LIMIT is <number>[<unit>]. Unit can be b (bytes), k
400 (kilobytes), m (megabytes), or g (gigabytes). If you don't specify a
401 unit, b is used. Set LIMIT to -1 to enable unlimited swap.
402
403
404 --name name
405
406
407 A name for the working container
408
409
410 --net how --network how
411
412
413 Sets the configuration for network namespaces when the container is
414 subsequently used for buildah run. The configured value can be "" (the
415 empty string) or "container" to indicate that a new network namespace
416 should be created, or it can be "host" to indicate that the network
417 namespace in which Buildah itself is being run should be reused, or it
418 can be the path to a network namespace which is already in use by an‐
419 other process.
420
421
422 --os="OS"
423
424
425 Set the OS of the image to be pulled to the provided value instead of
426 using the current operating system of the host.
427
428
429 --pid how
430
431
432 Sets the configuration for PID namespaces when the container is subse‐
433 quently used for buildah run. The configured value can be "" (the
434 empty string) or "container" to indicate that a new PID namespace
435 should be created, or it can be "host" to indicate that the PID name‐
436 space in which Buildah itself is being run should be reused, or it can
437 be the path to a PID namespace which is already in use by another
438 process.
439
440
441 --platform="OS/ARCH[/VARIANT]"
442
443
444 Set the OS/ARCH of the image to be pulled to the provided value instead
445 of using the current operating system and architecture of the host (for
446 example linux/arm). If --platform is set, then the values of the
447 --arch, --os, and --variant options will be overridden.
448
449
450 OS/ARCH pairs are those used by the Go Programming Language. In sev‐
451 eral cases the ARCH value for a platform differs from one produced by
452 other tools such as the arch command. Valid OS and architecture name
453 combinations are listed as values for $GOOS and $GOARCH at
454 https://golang.org/doc/install/source#environment, and can also be
455 found by running go tool dist list.
456
457
458 While buildah from is happy to pull an image for any platform that ex‐
459 ists, buildah run will not be able to run binaries provided by that im‐
460 age without the help of emulation provided by packages like qemu-user-
461 static.
462
463
464 --pull
465
466
467 When the flag is enabled, attempt to pull the latest image from the
468 registries listed in registries.conf if a local image does not exist or
469 the image is newer than the one in storage. Raise an error if the image
470 is not in any listed registry and is not present locally.
471
472
473 If the flag is disabled (with --pull=false), do not pull the image from
474 the registry, use only the local version. Raise an error if the image
475 is not present locally.
476
477
478 Defaults to true.
479
480
481 --pull-always
482
483
484 Pull the image from the first registry it is found in as listed in reg‐
485 istries.conf. Raise an error if not found in the registries, even if
486 the image is present locally.
487
488
489 --pull-never
490
491
492 Do not pull the image from the registry, use only the local version.
493 Raise an error if the image is not present locally.
494
495
496 --quiet, -q
497
498
499 If an image needs to be pulled from the registry, suppress progress
500 output.
501
502
503 --security-opt=[]
504
505
506 Security Options
507
508
509 "label=user:USER" : Set the label user for the container
510 "label=role:ROLE" : Set the label role for the container
511 "label=type:TYPE" : Set the label type for the container
512 "label=level:LEVEL" : Set the label level for the container
513 "label=disable" : Turn off label confinement for the container
514 "no-new-privileges" : Not supported
515
516
517 "seccomp=unconfined" : Turn off seccomp confinement for the container
518 "seccomp=profile.json : White listed syscalls seccomp Json file to
519 be used as a seccomp filter
520
521
522 "apparmor=unconfined" : Turn off apparmor confinement for the container
523 "apparmor=your-profile" : Set the apparmor confinement profile for
524 the container
525
526
527 --shm-size=""
528
529
530 Size of /dev/shm. The format is <number><unit>. number must be greater
531 than 0. Unit is optional and can be b (bytes), k (kilobytes),
532 m(megabytes), or g (gigabytes). If you omit the unit, the system uses
533 bytes. If you omit the size entirely, the system uses 64m.
534
535
536 --tls-verify bool-value
537
538
539 Require HTTPS and verification of certificates when talking to con‐
540 tainer registries (defaults to true). TLS verification cannot be used
541 when talking to an insecure registry.
542
543
544 --ulimit type=soft-limit[:hard-limit]
545
546
547 Specifies resource limits to apply to processes launched during buildah
548 run. This option can be specified multiple times. Recognized resource
549 types include:
550 "core": maximum core dump size (ulimit -c)
551 "cpu": maximum CPU time (ulimit -t)
552 "data": maximum size of a process's data segment (ulimit -d)
553 "fsize": maximum size of new files (ulimit -f)
554 "locks": maximum number of file locks (ulimit -x)
555 "memlock": maximum amount of locked memory (ulimit -l)
556 "msgqueue": maximum amount of data in message queues (ulimit -q)
557 "nice": niceness adjustment (nice -n, ulimit -e)
558 "nofile": maximum number of open files (ulimit -n)
559 "nofile": maximum number of open files (1048576); when run by root
560 "nproc": maximum number of processes (ulimit -u)
561 "nproc": maximum number of processes (1048576); when run by root
562 "rss": maximum size of a process's (ulimit -m)
563 "rtprio": maximum real-time scheduling priority (ulimit -r)
564 "rttime": maximum amount of real-time execution between blocking
565 syscalls
566 "sigpending": maximum number of pending signals (ulimit -i)
567 "stack": maximum stack size (ulimit -s)
568
569
570 --userns how
571
572
573 Sets the configuration for user namespaces when the container is subse‐
574 quently used for buildah run. The configured value can be "" (the
575 empty string) or "container" to indicate that a new user namespace
576 should be created, it can be "host" to indicate that the user namespace
577 in which Buildah itself is being run should be reused, or it can be the
578 path to an user namespace which is already in use by another process.
579
580
581 --userns-uid-map-user mapping
582
583
584 Directly specifies a UID mapping which should be used to set ownership,
585 at the filesystem level, on the container's contents. Commands run us‐
586 ing buildah run will default to being run in their own user namespaces,
587 configured using the UID and GID maps.
588
589
590 Entries in this map take the form of one or more triples of a starting
591 in-container UID, a corresponding starting host-level UID, and the num‐
592 ber of consecutive IDs which the map entry represents.
593
594
595 This option overrides the remap-uids setting in the options section of
596 /etc/containers/storage.conf.
597
598
599 If this option is not specified, but a global --userns-uid-map setting
600 is supplied, settings from the global option will be used.
601
602
603 If none of --userns-uid-map-user, --userns-gid-map-group, or --userns-
604 uid-map are specified, but --userns-gid-map is specified, the UID map
605 will be set to use the same numeric values as the GID map.
606
607
608 NOTE: When this option is specified by a rootless user, the specified
609 mappings are relative to the rootless usernamespace in the container,
610 rather than being relative to the host as it would be when run rootful.
611
612
613 --userns-gid-map-group mapping
614
615
616 Directly specifies a GID mapping which should be used to set ownership,
617 at the filesystem level, on the container's contents. Commands run us‐
618 ing buildah run will default to being run in their own user namespaces,
619 configured using the UID and GID maps.
620
621
622 Entries in this map take the form of one or more triples of a starting
623 in-container GID, a corresponding starting host-level GID, and the num‐
624 ber of consecutive IDs which the map entry represents.
625
626
627 This option overrides the remap-gids setting in the options section of
628 /etc/containers/storage.conf.
629
630
631 If this option is not specified, but a global --userns-gid-map setting
632 is supplied, settings from the global option will be used.
633
634
635 If none of --userns-uid-map-user, --userns-gid-map-group, or --userns-
636 gid-map are specified, but --userns-uid-map is specified, the GID map
637 will be set to use the same numeric values as the UID map.
638
639
640 NOTE: When this option is specified by a rootless user, the specified
641 mappings are relative to the rootless usernamespace in the container,
642 rather than being relative to the host as it would be when run rootful.
643
644
645 --userns-uid-map-user user
646
647
648 Specifies that a UID mapping which should be used to set ownership, at
649 the filesystem level, on the container's contents, can be found in en‐
650 tries in the /etc/subuid file which correspond to the specified user.
651 Commands run using buildah run will default to being run in their own
652 user namespaces, configured using the UID and GID maps. If --userns-
653 gid-map-group is specified, but --userns-uid-map-user is not specified,
654 Buildah will assume that the specified group name is also a suitable
655 user name to use as the default setting for this option.
656
657
658 --userns-gid-map-group group
659
660
661 Specifies that a GID mapping which should be used to set ownership, at
662 the filesystem level, on the container's contents, can be found in en‐
663 tries in the /etc/subgid file which correspond to the specified group.
664 Commands run using buildah run will default to being run in their own
665 user namespaces, configured using the UID and GID maps. If --userns-
666 uid-map-user is specified, but --userns-gid-map-group is not specified,
667 Buildah will assume that the specified user name is also a suitable
668 group name to use as the default setting for this option.
669
670
671 --uts how
672
673
674 Sets the configuration for UTS namespaces when the container is subse‐
675 quently used for buildah run. The configured value can be "" (the
676 empty string) or "container" to indicate that a new UTS namespace
677 should be created, or it can be "host" to indicate that the UTS name‐
678 space in which Buildah itself is being run should be reused, or it can
679 be the path to a UTS namespace which is already in use by another
680 process.
681
682
683 --variant=""
684
685
686 Set the architecture variant of the image to be pulled.
687
688
689 --volume, -v[=[HOST-DIR:CONTAINER-DIR[:OPTIONS]]]
690
691
692 Create a bind mount. If you specify, -v /HOST-DIR:/CONTAINER-DIR, Buil‐
693 dah
694 bind mounts /HOST-DIR in the host to /CONTAINER-DIR in the Buildah
695 container. The OPTIONS are a comma delimited list and can be: [1]
696 ⟨#Footnote1⟩
697
698
699 • [rw|ro]
700
701 • [U]
702
703 • [z|Z|O]
704
705 • [[r]shared|[r]slave|[r]private|[r]unbindable]
706
707
708
709 The CONTAINER-DIR must be an absolute path such as /src/docs. The HOST-
710 DIR must be an absolute path as well. Buildah bind-mounts the HOST-DIR
711 to the path you specify. For example, if you supply /foo as the host
712 path, Buildah copies the contents of /foo to the container filesystem
713 on the host and bind mounts that into the container.
714
715
716 You can specify multiple -v options to mount one or more mounts to a
717 container.
718
719
720 Write Protected Volume Mounts
721
722
723 You can add the :ro or :rw suffix to a volume to mount it read-only or
724 read-write mode, respectively. By default, the volumes are mounted
725 read-write. See examples.
726
727
728 Chowning Volume Mounts
729
730
731 By default, Buildah does not change the owner and group of source vol‐
732 ume directories mounted into containers. If a container is created in a
733 new user namespace, the UID and GID in the container may correspond to
734 another UID and GID on the host.
735
736
737 The :U suffix tells Buildah to use the correct host UID and GID based
738 on the UID and GID within the container, to change the owner and group
739 of the source volume.
740
741
742 Labeling Volume Mounts
743
744
745 Labeling systems like SELinux require that proper labels are placed on
746 volume content mounted into a container. Without a label, the security
747 system might prevent the processes running inside the container from
748 using the content. By default, Buildah does not change the labels set
749 by the OS.
750
751
752 To change a label in the container context, you can add either of two
753 suffixes :z or :Z to the volume mount. These suffixes tell Buildah to
754 relabel file objects on the shared volumes. The z option tells Buildah
755 that two containers share the volume content. As a result, Buildah la‐
756 bels the content with a shared content label. Shared volume labels al‐
757 low all containers to read/write content. The Z option tells Buildah
758 to label the content with a private unshared label. Only the current
759 container can use a private volume.
760
761
762 Overlay Volume Mounts
763
764
765 The :O flag tells Buildah to mount the directory from the host as a
766 temporary storage using the Overlay file system. The RUN command con‐
767 tainers are allowed to modify contents within the mountpoint and are
768 stored in the container storage in a separate directory. In Overlay FS
769 terms the source directory will be the lower, and the container storage
770 directory will be the upper. Modifications to the mount point are de‐
771 stroyed when the RUN command finishes executing, similar to a tmpfs
772 mount point.
773
774
775 Any subsequent execution of RUN commands sees the original source di‐
776 rectory content, any changes from previous RUN commands no longer ex‐
777 ists.
778
779
780 One use case of the overlay mount is sharing the package cache from the
781 host into the container to allow speeding up builds.
782
783
784 Note:
785
786
787 - 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.
788 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.
789 - 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.
790
791
792
793 By default bind mounted volumes are private. That means any mounts done
794 inside container will not be visible on the host and vice versa. This
795 behavior can be changed by specifying a volume mount propagation prop‐
796 erty.
797
798
799 When the mount propagation policy is set to shared, any mounts com‐
800 pleted inside the container on that volume will be visible to both the
801 host and container. When the mount propagation policy is set to slave,
802 one way mount propagation is enabled and any mounts completed on the
803 host for that volume will be visible only inside of the container. To
804 control the mount propagation property of the volume use the
805 :[r]shared, :[r]slave, [r]private or [r]unbindablepropagation flag. The
806 propagation property can be specified only for bind mounted volumes and
807 not for internal volumes or named volumes. For mount propagation to
808 work on the source mount point (the mount point where source dir is
809 mounted on) it has to have the right propagation properties. For shared
810 volumes, the source mount point has to be shared. And for slave vol‐
811 umes, the source mount has to be either shared or slave. [1] ⟨#Foot‐
812 note1⟩
813
814
815 Use df <source-dir> to determine the source mount and then use findmnt
816 -o TARGET,PROPAGATION <source-mount-dir> to determine propagation prop‐
817 erties of source mount, if findmnt utility is not available, the source
818 mount point can be determined by looking at the mount entry in
819 /proc/self/mountinfo. Look at optional fields and see if any propaga‐
820 tion properties are specified. shared:X means the mount is shared,
821 master:X means the mount is slave and if nothing is there that means
822 the mount is private. [1] ⟨#Footnote1⟩
823
824
825 To change propagation properties of a mount point use the mount com‐
826 mand. For example, to bind mount the source directory /foo do mount
827 --bind /foo /foo and mount --make-private --make-shared /foo. This will
828 convert /foo into a shared mount point. The propagation properties of
829 the source mount can be changed directly. For instance if / is the
830 source mount for /foo, then use mount --make-shared / to convert / into
831 a shared mount.
832
833
835 buildah from --pull imagename
836
837
838 buildah from --pull docker://myregistry.example.com/imagename
839
840
841 buildah from docker-daemon:imagename:imagetag
842
843
844 buildah from --name mycontainer docker-archive:filename
845
846
847 buildah from oci-archive:filename
848
849
850 buildah from --name mycontainer dir:directoryname
851
852
853 buildah from --pull-always --name "mycontainer" docker://myregistry.ex‐
854 ample.com/imagename
855
856
857 buildah from --tls-verify=false myregistry/myrepository/imagename:im‐
858 agetag
859
860
861 buildah from --creds=myusername:mypassword --cert-dir ~/auth myreg‐
862 istry/myrepository/imagename:imagetag
863
864
865 buildah from --authfile=/tmp/auths/myauths.json myregistry/myreposi‐
866 tory/imagename:imagetag
867
868
869 buildah from --memory 40m --cpu-shares 2 --cpuset-cpus 0,2 --security-
870 opt label=level:s0:c100,c200 myregistry/myrepository/imagename:imagetag
871
872
873 buildah from --ulimit nofile=1024:1028 --cgroup-parent
874 /path/to/cgroup/parent myregistry/myrepository/imagename:imagetag
875
876
877 buildah from --volume /home/test:/myvol:ro,Z myregistry/myreposi‐
878 tory/imagename:imagetag
879
880
881 buildah from -v /home/test:/myvol:z,U myregistry/myrepository/image‐
882 name:imagetag
883
884
885 buildah from -v /var/lib/yum:/var/lib/yum:O myregistry/myrepository/im‐
886 agename:imagetag
887
888
889 buildah from --arch=arm --variant v7 myregistry/myrepository/image‐
890 name:imagetag
891
892
894 BUILD_REGISTRY_SOURCES
895
896
897 BUILD_REGISTRY_SOURCES, if set, is treated as a JSON object which con‐
898 tains lists of registry names under the keys insecureRegistries,
899 blockedRegistries, and allowedRegistries.
900
901
902 When pulling an image from a registry, if the name of the registry
903 matches any of the items in the blockedRegistries list, the image pull
904 attempt is denied. If there are registries in the allowedRegistries
905 list, and the registry's name is not in the list, the pull attempt is
906 denied.
907
908
909 TMPDIR The TMPDIR environment variable allows the user to specify where
910 temporary files are stored while pulling and pushing images. Defaults
911 to '/var/tmp'.
912
913
915 registries.conf (/etc/containers/registries.conf)
916
917
918 registries.conf is the configuration file which specifies which con‐
919 tainer registries should be consulted when completing image names which
920 do not include a registry or domain portion.
921
922
923 policy.json (/etc/containers/policy.json)
924
925
926 Signature policy file. This defines the trust policy for container im‐
927 ages. Controls which container registries can be used for image, and
928 whether or not the tool should trust the images.
929
930
932 buildah(1), buildah-pull(1), buildah-login(1), docker-login(1), name‐
933 spaces(7), pid_namespaces(7), containers-policy.json(5), containers-
934 registries.conf(5), user_namespaces(7)
935
936
938 1: The Buildah project is committed to inclusivity, a core value of
939 open source. The master and slave mount propagation terminology used
940 here is problematic and divisive, and should be changed. However, these
941 terms are currently used within the Linux kernel and must be used as-is
942 at this time. When the kernel maintainers rectify this usage, Buildah
943 will follow suit immediately.
944
945
946
947buildah March 2017 buildah-from(1)