1CH-IMAGE(1) Charliecloud CH-IMAGE(1)
2
6 ch-image - Build and manage images; completely unprivileged
7
9 $ ch-image [...] build [-t TAG] [-f DOCKERFILE] [...] CONTEXT
10 $ ch-image [...] delete IMAGE_REF
11 $ ch-image [...] import PATH IMAGE_REF
12 $ ch-image [...] list [IMAGE_REF]
13 $ ch-image [...] pull [...] IMAGE_REF [IMAGE_DIR]
14 $ ch-image [...] push [--image DIR] IMAGE_REF [DEST_REF]
15 $ ch-image [...] reset
16 $ ch-image [...] storage-path
17 $ ch-image { --help | --version | --dependencies }
18
20 ch-image is a tool for building and manipulating container images, but
21 not running them (for that you want ch-run). It is completely unprivi‐
22 leged, with no setuid/setgid/setcap helpers. The action to take is
23 specified by a sub-command.
24 Options that print brief information and then exit:
26 -h, --help
28 Print help and exit successfully. If specified before the
29 sub-command, print general help and list of sub-commands; if
30 after the sub-command, print help specific to that sub-com‐
31 mand.
32 --dependencies
34 Report dependency problems on standard output, if any, and
35 exit. If all is well, there is no output and the exit is suc‐
36 cessful; in case of problems, the exit is unsuccessful.
37 --version
39 Print version number and exit successfully.
40 Common options placed before the sub-command:
42 -a, --arch ARCH
44 Use ARCH for architecture-aware registry operations, cur‐
45 rently pull and pulls done within build. ARCH can be: (1)
46 yolo, to bypass architecture-aware code and use the reg‐
47 istry’s default architecture; (2) host, to use the host’s ar‐
48 chitecture, obtained with the equivalent of uname -m (default
49 if --arch not specified); or (3) an architecture name. If the
50 specified architecture is not available, the error message
51 will list which ones are.
52 Notes:
54 1. ch-image is limited to one image per image reference in
56 builder storage at a time, regardless of architecture. For
57 example, if you say ch-image pull --arch=foo baz and then
58 ch-image pull --arch=bar baz, builder storage will contain
59 one image called “baz”, with architecture “bar”.
60 2. Images’ default architecture is usually amd64, so this is
62 usually what you get with --arch=yolo. Similarly, if a
63 registry image is architecture-unaware, it will still be
64 pulled with --arch=amd64 and --arch=host on x86-64 hosts
65 (other host architectures must specify --arch=yolo to pull
66 architecture-unaware images).
67 3. uname -m and image registries often use different names
69 for the same architecture. For example, what uname -m re‐
70 ports as “x86_64” is known to registries as “amd64”.
71 --arch=host should translate if needed, but it’s useful to
72 know this is happening. Directly specified architecture
73 names are passed to the registry without translation.
74 4. Registries treat architecture as a pair of items, archi‐
76 tecture and sometimes variant (e.g., “arm” and “v7”).
77 Charliecloud treats architecture as a simple string and
78 converts to/from the registry view transparently.
79 --no-cache
81 Download everything needed, ignoring the cache.
82 --password-many
84 Re-prompt the user every time a registry password is needed.
85 -s, --storage DIR
87 Set the storage directory (see below for important details).
88 --tls-no-verify
90 Don’t verify TLS certificates of the repository. (Do not use
91 this option unless you understand the risks.)
92 -v, --verbose
94 Print extra chatter; can be repeated.
95
97 If the remote repository needs authentication, Charliecloud will prompt
98 you for a username and password. Note that some repositories call the
99 secret something other than “password”; e.g., GitLab calls it a “per‐
100 sonal access token (PAT)”.
101 These values are remembered for the life of the process and silently
103 re-offered to the registry if needed. One case when this happens is on
104 push to a private registry: many registries will first offer a
105 read-only token when ch-image checks if something exists, then re-au‐
106 thenticate when upgrading the token to read-write for upload. If your
107 site uses one-time passwords such as provided by a security device, you
108 can specify --password-many to provide a new secret each time.
109 These values are not saved persistently, e.g. in a file. Note that we
111 do use normal Python variables for this information, without pinning
112 them into physical RAM with mlock(2) or any other special treatment, so
113 we cannot guarantee they will never reach non-volatile storage.
114 There is no separate login subcommand like Docker. For non-interactive
116 authentication, you can use environment variables CH_IMAGE_USERNAME and
117 CH_IMAGE_PASSWORD. Only do this if you fully understand the implica‐
118 tions for your specific use case, because it is difficult to securely
119 store secrets in environment variables.
120
122 ch-image maintains state using normal files and directories located in
123 its storage directory; contents include temporary images used for
124 building and various caches.
125 In descending order of priority, this directory is located at:
127 -s, --storage DIR
129 Command line option.
130 $CH_IMAGE_STORAGE
132 Environment variable.
133 /var/tmp/$USER/ch-image
135 Default.
136 Unlike many container implementations, there is no notion of storage
138 drivers, graph drivers, etc., to select and/or configure.
139 The storage directory can reside on any filesystem. However, it con‐
141 tains lots of small files and metadata traffic can be intense. For ex‐
142 ample, the Charliecloud test suite uses approximately 400,000 files and
143 directories in the storage directory as of this writing. Place it on a
144 filesystem appropriate for this; tmpfs’es such as /var/tmp are a good
145 choice if you have enough RAM (/tmp is not recommended because ch-run
146 bind-mounts it into containers by default).
147 While you can currently poke around in the storage directory and find
149 unpacked images runnable with ch-run, this is not a supported use case.
150 The supported workflow uses ch-builder2tar or ch-builder2squash to ob‐
151 tain a packed image; see the tutorial for details.
152 The storage directory format changes on no particular schedule. Often
154 ch-image is able to upgrade the directory; however, downgrading is not
155 supported and sometimes upgrade is not possible. In these cases, ch-im‐
156 age will refuse to run until you delete and re-initialize the directory
157 with ch-image reset.
158 WARNING:
160 Network filesystems, especially Lustre, are typically bad choices
161 for the storage directory. This is a site-specific question and your
162 local support will likely have strong opinions.
163
165 Build an image from a Dockerfile and put it in the storage directory.
166 Synopsis
168 $ ch-image [...] build [-t TAG] [-f DOCKERFILE] [...] CONTEXT
169 Description
171 Uses ch-run -w -u0 -g0 --no-home --no-passwd to execute RUN instruc‐
172 tions. Note that FROM implicitly pulls the base image if needed, so you
173 may want to read about the pull subcommand below as well.
174 Required argument:
176 CONTEXT
178 Path to context directory; this is the root of COPY and ADD
179 instructions in the Dockerfile.
180 Options:
182 -b, --bind SRC[:DST]
184 For RUN instructions only, bind-mount SRC at guest DST. The
185 default destination if not specified is to use the same path
186 as the host; i.e., the default is equivalent to
187 --bind=SRC:SRC. If DST does not exist, try to create it as an
188 empty directory, though images do have ten directories
189 /mnt/[0-9] already available as mount points. Can be re‐
190 peated.
191 Note: See documentation for ch-run --bind for important
193 caveats and gotchas.
194 Note: Other instructions that modify the image filesystem,
196 e.g. COPY, can only access host files from the context di‐
197 rectory, regardless of this option.
198 --build-arg KEY[=VALUE]
200 Set build-time variable KEY defined by ARG instruction to
201 VALUE. If VALUE not specified, use the value of environment
202 variable KEY.
203 -f, --file DOCKERFILE
205 Use DOCKERFILE instead of CONTEXT/Dockerfile. Specify a sin‐
206 gle hyphen (-) to use standard input; note that in this case,
207 the context directory is still provided, which matches docker
208 build -f - behavior.
209 --force
211 Inject the unprivileged build workarounds; see discussion
212 later in this section for details on what this does and when
213 you might need it. If a build fails and ch-image thinks
214 --force would help, it will suggest it.
215 -n, --dry-run
217 Don’t actually execute any Dockerfile instructions.
218 --no-force-detect
220 Don’t try to detect if the workarounds in --force would help.
221 --parse-only
223 Stop after parsing the Dockerfile.
224 -t, --tag TAG
226 Name of image to create. If not specified, infer the name:
227 1. If Dockerfile named Dockerfile with an extension: use the
229 extension with invalid characters stripped, e.g. Docker‐
230 file.@FOO.bar → foo.bar.
231 2. If Dockerfile has extension dockerfile: use the basename
233 with the same transformation, e.g. baz.@QUX.dockerfile ->
234 baz.qux.
235 3. If context directory is not /: use its name, i.e. the last
237 component of the absolute path to the context directory,
238 with the same transformation,
239 4. Otherwise (context directory is /): use root.
241 If no colon present in the name, append :latest.
243 Privilege model
245 ch-image is a fully unprivileged image builder. It does not use any se‐
246 tuid or setcap helper programs, and it does not use configuration files
247 /etc/subuid or /etc/subgid. This contrasts with the “rootless” or “‐
248 fakeroot” modes of some competing builders, which do require privileged
249 supporting code or utilities.
250 This approach does yield some quirks. We provide built-in workarounds
252 that should mostly work (i.e., --force), but it can be helpful to un‐
253 derstand what is going on.
254 ch-image executes all instructions as the normal user who invokes it.
256 For RUN, this is accomplished with ch-run -w --uid=0 --gid=0 (and some
257 other arguments), i.e., your host EUID and EGID both mapped to zero in‐
258 side the container, and only one UID (zero) and GID (zero) are avail‐
259 able inside the container. Under this arrangement, processes running in
260 the container for each RUN appear to be running as root, but many priv‐
261 ileged system calls will fail without the workarounds described below.
262 This affects any fully unprivileged container build, not just Char‐
263 liecloud.
264 The most common time to see this is installing packages. For example,
266 here is RPM failing to chown(2) a file, which makes the package update
267 fail:
268 Updating : 1:dbus-1.10.24-13.el7_6.x86_64 2/4
270 Error unpacking rpm package 1:dbus-1.10.24-13.el7_6.x86_64
271 error: unpacking of archive failed on file /usr/libexec/dbus-1/dbus-daemon-launch-helper;5cffd726: cpio: chown
272 Cleanup : 1:dbus-libs-1.10.24-12.el7.x86_64 3/4
273 error: dbus-1:1.10.24-13.el7_6.x86_64: install failed
274 This one is (ironically) apt-get failing to drop privileges:
276 E: setgroups 65534 failed - setgroups (1: Operation not permitted)
278 E: setegid 65534 failed - setegid (22: Invalid argument)
279 E: seteuid 100 failed - seteuid (22: Invalid argument)
280 E: setgroups 0 failed - setgroups (1: Operation not permitted)
281 By default, nothing is done to avoid these problems, though ch-image
283 does try to detect if the workarounds could help. --force activates the
284 workarounds: ch-image injects extra commands to intercept these system
285 calls and fake a successful result, using fakeroot(1). There are three
286 basic steps:
287 1. After FROM, analyze the image to see what distribution it con‐
289 tains, which determines the specific workarounds.
290 2. Before the user command in the first RUN instruction where the
292 injection seems needed, install fakeroot(1) in the image, if one
293 is not already installed, as well as any other necessary initial‐
294 ization commands. For example, we turn off the apt sandbox (for
295 Debian Buster) and configure EPEL but leave it disabled (for Cen‐
296 tOS/RHEL).
297 3. Prepend fakeroot to RUN instructions that seem to need it, e.g.
299 ones that contain apt, apt-get, dpkg for Debian derivatives and
300 dnf, rpm, or yum for RPM-based distributions.
301 The details are specific to each distribution. ch-image analyzes image
303 content (e.g., grepping /etc/debian_version) to select a configuration;
304 see lib/fakeroot.py for details. ch-image prints exactly what it is do‐
305 ing.
306 Compatibility with other Dockerfile interpreters
308 ch-image is an independent implementation and shares no code with other
309 Dockerfile interpreters. It uses a formal Dockerfile parsing grammar
310 developed from the Dockerfile reference documentation and miscellaneous
311 other sources, which you can examine in the source code.
312 We believe this independence is valuable for several reasons. First, it
314 helps the community examine Dockerfile syntax and semantics critically,
315 think rigorously about what is really needed, and build a more robust
316 standard. Second, it yields disjoint sets of bugs (note that Podman,
317 Buildah, and Docker all share the same Dockerfile parser). Third, be‐
318 cause it is a much smaller code base, it illustrates how Dockerfiles
319 work more clearly. Finally, it allows straightforward extensions if
320 needed to support scientific computing.
321 ch-image tries hard to be compatible with Docker and other inter‐
323 preters, though as an independent implementation, it is not bug-compat‐
324 ible.
325 The following subsections describe differences from the Dockerfile ref‐
327 erence that we expect to be approximately permanent. For not-yet-imple‐
328 mented features and bugs in this area, see related issues on GitHub.
329 None of these are set in stone. We are very interested in feedback on
331 our assessments and open questions. This helps us prioritize new fea‐
332 tures and revise our thinking about what is needed for HPC containers.
333 Context directory
335 The context directory is bind-mounted into the build, rather than
336 copied like Docker. Thus, the size of the context is immaterial, and
337 the build reads directly from storage like any other local process
338 would. However, you still can’t access anything outside the context di‐
339 rectory.
340 Variable substitution
342 Variable substitution happens for all instructions, not just the ones
343 listed in the Dockerfile reference.
344 ARG and ENV cause cache misses upon definition, in contrast with Docker
346 where these variables miss upon use, except for certain cache-excluded
347 variables that never cause misses, listed below.
348 ch-image passes the following proxy environment variables in to the
350 build. Changes to these variables do not cause a cache miss. They do
351 not require an ARG instruction, as documented in the Dockerfile refer‐
352 ence. Unlike Docker, they are available if the same-named environment
353 variable is defined; --build-arg is not required.
354 HTTP_PROXY
356 http_proxy
357 HTTPS_PROXY
358 https_proxy
359 FTP_PROXY
360 ftp_proxy
361 NO_PROXY
362 no_proxy
363 In addition to those listed in the Dockerfile reference, these environ‐
365 ment variables are passed through in the same way:
366 SSH_AUTH_SOCK
368 Finally, these variables are also pre-defined but are unrelated to the
370 host environment:
371 PATH=/ch/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
373 TAR_OPTIONS=--no-same-owner
374 Note that ARG and ENV have different syntax despite very similar seman‐
376 tics.
377 COPY
379 Especially for people used to UNIX cp(1), the semantics of the Docker‐
380 file COPY instruction can be confusing.
381 Most notably, when a source of the copy is a directory, the contents of
383 that directory, not the directory itself, are copied. This is docu‐
384 mented, but it’s a real gotcha because that’s not what cp(1) does, and
385 it means that many things you can do in one cp(1) command require mul‐
386 tiple COPY instructions.
387 Also, the reference documentation is incomplete. In our experience,
389 Docker also behaves as follows; ch-image does the same in an attempt to
390 be bug-compatible.
391 1. You can use absolute paths in the source; the root is the context
393 directory.
394 2. Destination directories are created if they don’t exist in the fol‐
396 lowing situations:
397 1. If the destination path ends in slash. (Documented.)
399 2. If the number of sources is greater than 1, either by wildcard or
401 explicitly, regardless of whether the destination ends in slash.
402 (Not documented.)
403 3. If there is a single source and it is a directory. (Not docu‐
405 mented.)
406 3. Symbolic links behave differently depending on how deep in the
408 copied tree they are. (Not documented.)
409 1. Symlinks at the top level — i.e., named as the destination or the
411 source, either explicitly or by wildcards — are dereferenced.
412 They are followed, and whatever they point to is used as the des‐
413 tination or source, respectively.
414 2. Symlinks at deeper levels are not dereferenced, i.e., the symlink
416 itself is copied.
417 4. If a directory appears at the same path in source and destination,
419 and is at the 2nd level or deeper, the source directory’s metadata
420 (e.g., permissions) are copied to the destination directory. (Not
421 documented.)
422 5. If an object appears in both the source and destination, and is at
424 the 2nd level or deeper, and is of different types in the source and
425 destination, then the source object will overwrite the destination
426 object. (Not documented.) For example, if /tmp/foo/bar is a regular
427 file, and /tmp is the context directory, then the following Docker‐
428 file snippet will result in a file in the container at /foo/bar
429 (copied from /tmp/foo/bar); the directory and all its contents will
430 be lost.
431 RUN mkdir -p /foo/bar && touch /foo/bar/baz
433 COPY foo /foo
434 We expect the following differences to be permanent:
436 • Wildcards use Python glob semantics, not the Go semantics.
438 • COPY --chown is ignored, because it doesn’t make sense in an unprivi‐
440 leged build.
441 Features we do not plan to support
443 • Parser directives are not supported. We have not identified a need
444 for any of them.
445 • EXPOSE: Charliecloud does not use the network namespace, so con‐
447 tainerized processes can simply listen on a host port like other un‐
448 privileged processes.
449 • HEALTHCHECK: This instruction’s main use case is monitoring server
451 processes rather than applications. Also, implementing it requires a
452 container supervisor daemon, which we have no plans to add.
453 • MAINTAINER is deprecated.
455 • STOPSIGNAL requires a container supervisor daemon process, which we
457 have no plans to add.
458 • USER does not make sense for unprivileged builds.
460 • VOLUME: This instruction is not currently supported. Charliecloud has
462 good support for bind mounts; we anticipate that it will continue to
463 focus on that and will not introduce the volume management features
464 that Docker has.
465 Examples
467 Build image bar using ./foo/bar/Dockerfile and context directory
468 ./foo/bar:
469 $ ch-image build -t bar -f ./foo/bar/Dockerfile ./foo/bar
471 [...]
472 grown in 4 instructions: bar
473 Same, but infer the image name and Dockerfile from the context direc‐
475 tory path:
476 $ ch-image build ./foo/bar
478 [...]
479 grown in 4 instructions: bar
480 Build using humongous vendor compilers you want to bind-mount instead
482 of installing into the image:
483 $ ch-image build --bind /opt/bigvendor:/opt .
485 $ cat Dockerfile
486 FROM centos:7
487 RUN /opt/bin/cc hello.c
489 #COPY /opt/lib/*.so /usr/local/lib # fail: COPY doesn't bind mount
490 RUN cp /opt/lib/*.so /usr/local/lib # possible workaround
491 RUN ldconfig
492
494 $ ch-image [...] delete IMAGE_REF
495 Delete the image described by the image reference IMAGE_REF from the
497 storage directory.
498
500 Print information about images. If no argument given, list the images
501 in builder storage.
502 Synopsis
504 $ ch-image [...] list [IMAGE_REF]
505 Description
507 Optional argument:
508 IMAGE_REF
510 Print details of what’s known about IMAGE_REF, both locally
511 and in the remote registry, if any.
512 Examples
514 List images in builder storage:
515 $ ch-image list
517 alpine:3.9 (amd64)
518 alpine:latest (amd64)
519 debian:buster (amd64)
520 Print details about Debian Buster image:
522 $ ch-image list debian:buster
524 details of image: debian:buster
525 in local storage: no
526 full remote ref: registry-1.docker.io:443/library/debian:buster
527 available remotely: yes
528 remote arch-aware: yes
529 host architecture: amd64
530 archs available: 386 amd64 arm/v5 arm/v7 arm64/v8 mips64le ppc64le s390x
531
533 $ ch-image [...] import PATH IMAGE_REF
534 Copy the image at PATH into builder storage with name IMAGE_REF. PATH
536 can be:
537 • an image directory
539 • a tarball with no top-level directory (a.k.a. a “tarbomb”)
541 • a standard tarball with one top-level directory
543 If the imported image contains Charliecloud metadata, that will be im‐
545 ported unchanged, i.e., images exported from ch-image builder storage
546 will be functionally identical when re-imported.
547
549 Pull the image described by the image reference IMAGE_REF from a repos‐
550 itory to the local filesystem.
551 Synopsis
553 $ ch-image [...] pull [...] IMAGE_REF [IMAGE_DIR]
554 See the FAQ for the gory details on specifying image references.
556 Description
558 Destination:
559 IMAGE_DIR
561 If specified, place the unpacked image at this path; it is
562 then ready for use by ch-run or other tools. The storage di‐
563 rectory will not contain a copy of the image, i.e., it is
564 only unpacked once.
565 Options:
567 --last-layer N
569 Unpack only N layers, leaving an incomplete image. This op‐
570 tion is intended for debugging.
571 --parse-only
573 Parse IMAGE_REF, print a parse report, and exit successfully
574 without talking to the internet or touching the storage di‐
575 rectory.
576 This script does a fair amount of validation and fixing of the layer
578 tarballs before flattening in order to support unprivileged use despite
579 image problems we frequently see in the wild. For example, device files
580 are ignored, and file and directory permissions are increased to a min‐
581 imum of rwx------ and rw------- respectively. Note, however, that sym‐
582 links pointing outside the image are permitted, because they are not
583 resolved until runtime within a container.
584 The following metadata in the pulled image is retained; all other meta‐
586 data is currently ignored. (If you have a need for additional metadata,
587 please let us know!)
588 • Current working directory set with WORKDIR is effective in down‐
590 stream Dockerfiles.
591 • Environment variables set with ENV are effective in downstream
593 Dockerfiles and also written to /ch/environment for use in ch-run
594 --set-env.
595 • Mount point directories specified with VOLUME are created in the
597 image if they don’t exist, but no other action is taken.
598 Note that some images (e.g., those with a “version 1 manifest”) do not
600 contain metadata. A warning is printed in this case.
601 Examples
603 Download the Debian Buster image matching the host’s architecture and
604 place it in the storage directory:
605 $ uname -m
607 aarch32
608 pulling image: debian:buster
609 requesting arch: arm64/v8
610 manifest list: downloading
611 manifest: downloading
612 config: downloading
613 layer 1/1: c54d940: downloading
614 flattening image
615 layer 1/1: c54d940: listing
616 validating tarball members
617 resolving whiteouts
618 layer 1/1: c54d940: extracting
619 image arch: arm64
620 done
621 Same, specifying the architecture explicitly:
623 $ ch-image --arch=arm/v7 pull debian:buster
625 pulling image: debian:buster
626 requesting arch: arm/v7
627 manifest list: downloading
628 manifest: downloading
629 config: downloading
630 layer 1/1: 8947560: downloading
631 flattening image
632 layer 1/1: 8947560: listing
633 validating tarball members
634 resolving whiteouts
635 layer 1/1: 8947560: extracting
636 image arch: arm (may not match host arm64/v8)
637 Download the same image and place it in /tmp/buster:
639 $ ch-image pull debian:buster /tmp/buster
641 [...]
642 $ ls /tmp/buster
643 bin dev home lib64 mnt proc run srv tmp var
644 boot etc lib media opt root sbin sys usr
645
647 Push the image described by the image reference IMAGE_REF from the lo‐
648 cal filesystem to a repository.
649 Synopsis
651 $ ch-image [...] push [--image DIR] IMAGE_REF [DEST_REF]
652 See the FAQ for the gory details on specifying image references.
654 Description
656 Destination:
657 DEST_REF
659 If specified, use this as the destination image reference,
660 rather than IMAGE_REF. This lets you push to a repository
661 without permanently adding a tag to the image.
662 Options:
664 --image DIR
666 Use the unpacked image located at DIR rather than an image in
667 the storage directory named IMAGE_REF.
668 Because Charliecloud is fully unprivileged, the owner and group of
670 files in its images are not meaningful in the broader ecosystem. Thus,
671 when pushed, everything in the image is flattened to user:group
672 root:root. Also, setuid/setgid bits are removed, to avoid surprises if
673 the image is pulled by a privileged container implementation.
674 Examples
676 Push a local image to the registry example.com:5000 at path /foo/bar
677 with tag latest. Note that in this form, the local image must be named
678 to match that remote reference.
679 $ ch-image push example.com:5000/foo/bar:latest
681 pushing image: example.com:5000/foo/bar:latest
682 layer 1/1: gathering
683 layer 1/1: preparing
684 preparing metadata
685 starting upload
686 layer 1/1: a1664c4: checking if already in repository
687 layer 1/1: a1664c4: not present, uploading
688 config: 89315a2: checking if already in repository
689 config: 89315a2: not present, uploading
690 manifest: uploading
691 cleaning up
692 done
693 Same, except use local image alpine:3.9. In this form, the local image
695 name does not have to match the destination reference.
696 $ ch-image push alpine:3.9 example.com:5000/foo/bar:latest
698 pushing image: alpine:3.9
699 destination: example.com:5000/foo/bar:latest
700 layer 1/1: gathering
701 layer 1/1: preparing
702 preparing metadata
703 starting upload
704 layer 1/1: a1664c4: checking if already in repository
705 layer 1/1: a1664c4: not present, uploading
706 config: 89315a2: checking if already in repository
707 config: 89315a2: not present, uploading
708 manifest: uploading
709 cleaning up
710 done
711 Same, except use unpacked image located at /var/tmp/image rather than
713 an image in ch-image storage. (Also, the sole layer is already present
714 in the remote registry, so we don’t upload it again.)
715 $ ch-image push --image /var/tmp/image example.com:5000/foo/bar:latest
717 pushing image: example.com:5000/foo/bar:latest
718 image path: /var/tmp/image
719 layer 1/1: gathering
720 layer 1/1: preparing
721 preparing metadata
722 starting upload
723 layer 1/1: 892e38d: checking if already in repository
724 layer 1/1: 892e38d: already present
725 config: 546f447: checking if already in repository
726 config: 546f447: not present, uploading
727 manifest: uploading
728 cleaning up
729 done
730
732 $ ch-image [...] reset
733 Delete all images and cache from ch-image builder storage.
735
737 $ ch-image [...] storage-path
738 Print the storage directory path and exit.
740
742 CH_IMAGE_USERNAME, CH_IMAGE_PASSWORD
743 Username and password for registry authentication. See important
744 caveats in section “Authentication” above.
745 CH_LOG_FILE
747 If set, append log chatter to this file, rather than standard
748 error. This is useful for debugging situations where standard
749 error is consumed or lost.
750 Also sets verbose mode if not already set (equivalent to --ver‐
752 bose).
753 CH_LOG_FESTOON
755 If set, prepend PID and timestamp to logged chatter.
756
758 If Charliecloud was obtained from your Linux distribution, use your
759 distribution’s bug reporting procedures.
760 Otherwise, report bugs to: <https://github.com/hpc/charliecloud/issues>
762
764 charliecloud(7)
765 Full documentation at: <https://hpc.github.io/charliecloud>
767
769 2014–2021, Triad National Security, LLC
7700.25 2021-09-20 00:00 UTC CH-IMAGE(1)