|
| 1 | +# appc Dependencies |
| 2 | + |
| 3 | +Some of the most common questions people new to acbuild ask are related to image |
| 4 | +dependencies. How do they work, how are they referenced, what's the difference |
| 5 | +between `acbuild begin <image>` and `acbuild dependency add <image>`. |
| 6 | + |
| 7 | +This document aims to provide a detailed explanation of image dependencies in |
| 8 | +AppC and how they can be manipulated with acbuild. |
| 9 | + |
| 10 | +## acbuild begin |
| 11 | + |
| 12 | +One way to interact with other images is via `acbuild begin`. Specifics on the |
| 13 | +different ways to invoke it are [here][1]. |
| 14 | + |
| 15 | +The short version of it is that when you run `acbuild begin` and provide an |
| 16 | +image, the build will start out containing everything from the specified image. |
| 17 | +It'll have the same manifest, and all the files in the other image will be |
| 18 | +present. When `acbuild write` is called, the resulting image will include all of |
| 19 | +this information, so the final image will be the same size or larger than the |
| 20 | +image you began from. |
| 21 | + |
| 22 | +When this method is used, the original image is copied and modified, and the |
| 23 | +original image isn't needed at runtime when you hand the resulting container |
| 24 | +image to a container runtime. |
| 25 | + |
| 26 | +In AppC terminology, this isn't even using dependencies at all. |
| 27 | + |
| 28 | +## acbuild dependency add |
| 29 | + |
| 30 | +AppC provides a way for images to point to other images needed at runtime; these |
| 31 | +other images are called dependencies. These pointers can be added via the |
| 32 | +`acbuild dep add` command. Specifics on using it are [here][2]. |
| 33 | + |
| 34 | +When a container runtime goes to run an image, it also needs all of that image's |
| 35 | +dependencies, and all of the dependencies' dependencies, and so on. Adding a |
| 36 | +dependency to an image simply adds a pointer to a different image, and nothing |
| 37 | +else about the dependency (other than potentially things like labels, and an |
| 38 | +expected hash) are stored in the image being built. |
| 39 | + |
| 40 | +These pointers take the form of AppC image names. When you give an image with |
| 41 | +dependencies to a container runtime, the runtime should first check its local |
| 42 | +store for any images with matching names, use those if they exist, and otherwise |
| 43 | +perform AppC discovery to find the images on the internet and fetch them. AppC |
| 44 | +image names and discovery are described in greater detail [here][3]. |
| 45 | + |
| 46 | +acbuild doesn't have a persistent local store, so if acbuild needs to find |
| 47 | +dependencies (which happens if you use the `run` command after a `dep add` |
| 48 | +command) it immediately falls back to performing AppC discovery to find the |
| 49 | +image. This means that local dependencies are not currently supported. |
| 50 | + |
| 51 | +[1]: Documentation/subcommands/begin.md |
| 52 | +[2]: Documentation/subcommands/dependency.md |
| 53 | +[3]: https://github.com/appc/spec/blob/master/spec/discovery.md |
0 commit comments