Skip to content

Commit affffe8

Browse files
authored
docs: update docs with v1.0.0 changes (#47)
* docs: update docs with v1.0.0 changes Signed-off-by: mbshields <[email protected]> * docs: update What's New for v1.0.0, add SBOM article Signed-off-by: mbshields <[email protected]> * docs: resolve more PR comments Signed-off-by: mbshields <[email protected]> * docs: resolve comments, change zotregistry.io to .dev Signed-off-by: mbshields <[email protected]> --------- Signed-off-by: mbshields <[email protected]>
1 parent b3e2a8c commit affffe8

11 files changed

+351
-89
lines changed

docs/reference/stacker_cli.md

+35-13
Original file line numberDiff line numberDiff line change
@@ -1,18 +1,21 @@
11
# Stacker Command-Line Interface Reference
22

3+
This document lists the command line interface (CLI) commands for stacker version 1.0.0.
4+
35
<table>
46
<tr><td><a href="#stacker">stacker</a></td><td>Stacker builds OCI images</td></tr>
5-
<tr><td><a href="#stacker-build">stacker build</a></td><td>Build a new OCI image from a stacker yaml file</td></tr>
6-
<tr><td><a href="#stacker-recursive-build">stacker recursive-build</a></td><td>Find stacker yaml files under a directory and builds all OCI layers they define</td></tr>
7-
<tr><td><a href="#stacker-publish">stacker publish</a></td><td>Publish OCI images previously built from one or more stacker yaml files</td></tr>
8-
<tr><td><a href="#stacker-chroot-exec">stacker chroot</a></td><td>Run a command in a chroot (same as <code>stacker exec</code>)</td></tr>
9-
<tr><td><a href="#stacker-clean">stacker clean</a></td><td>Clean up after a stacker build</td></tr>
10-
<tr><td><a href="#stacker-inspect">stacker inspect</a></td><td>Print the json representation of an OCI image</td></tr>
11-
<tr><td><a href="#stacker-grab">stacker grab</a></td><td>Grab a file from the layer's filesystem</td></tr>
12-
<tr><td><a href="#stacker-unpriv-setup">stacker unpriv-setup</a></td><td>Do the necessary unprivileged setup for stacker build to work without root</td></tr>
7+
<tr><td><a href="#stacker-build">stacker build</a></td><td>Builds a new OCI image from a stacker yaml file</td></tr>
8+
<tr><td><a href="#stacker-recursive-build">stacker recursive-build</a></td><td>Finds stacker yaml files under a directory and builds all OCI images they define</td></tr>
9+
<tr><td><a href="#stacker-convert">stacker convert</a></td><td>Converts a Dockerfile into a stacker yaml file</td></tr>
10+
<tr><td><a href="#stacker-publish">stacker publish</a></td><td>Publishes OCI images previously built from one or more stacker yaml files</td></tr>
11+
<tr><td><a href="#stacker-chroot-exec">stacker chroot</a></td><td>Runs a command in a chroot (same as <code>stacker exec</code>)</td></tr>
12+
<tr><td><a href="#stacker-clean">stacker clean</a></td><td>Cleans up after a stacker build</td></tr>
13+
<tr><td><a href="#stacker-inspect">stacker inspect</a></td><td>Prints the json representation of an OCI image</td></tr>
14+
<tr><td><a href="#stacker-grab">stacker grab</a></td><td>Grabs a file from the image's filesystem</td></tr>
15+
<tr><td><a href="#stacker-unpriv-setup">stacker unpriv-setup</a></td><td>Does the necessary unprivileged setup for stacker build to work without root</td></tr>
1316
<tr><td><a href="#stacker-gc">stacker gc</a></td><td>Garbage collection of unused OCI imports/outputs snapshots</td></tr>
14-
<tr><td><a href="#stacker-check">stacker check</a></td><td>Check that all runtime required items (like kernel features) are present</td></tr>
15-
<tr><td><a href="#stacker-help">stacker help</a></td><td>Show a list of commands or help for one command</td></tr>
17+
<tr><td><a href="#stacker-check">stacker check</a></td><td>Checks that all runtime required items (like kernel features) are present</td></tr>
18+
<tr><td><a href="#stacker-help">stacker help</a></td><td>Shows a list of commands or help for one command</td></tr>
1619
</table>
1720

1821
<a name="stacker"></a>
@@ -26,11 +29,12 @@
2629
stacker [global options] command [command options] [arguments...]
2730

2831
VERSION:
29-
stacker v0.40.1-e54a685 liblxc a330126b45c7c3b6fcf0f9ba6c1eda7bdb4e508a
32+
stacker <version> liblxc <digest>
3033

3134
COMMANDS:
3235
build builds a new OCI image from a stacker yaml file
3336
recursive-build finds stacker yaml files under a directory and builds all OCI layers they define
37+
convert converts a Dockerfile into a stacker yaml file (experimental, best-effort)
3438
publish publishes OCI images previously built from one or more stacker yaml files
3539
chroot, exec run a command in a chroot
3640
clean cleans up after a `stacker build`
@@ -42,10 +46,11 @@
4246
help, h Shows a list of commands or help for one command
4347

4448
GLOBAL OPTIONS:
49+
--work-dir value set the working directory for stacker's cache, OCI output and rootfs output
4550
--stacker-dir value set the directory for stacker's cache (default: ".stacker")
4651
--oci-dir value set the directory for OCI output (default: "oci")
4752
--roots-dir value set the directory for the rootfs output (default: "roots")
48-
--config value stacker config file with defaults (default: "/users/mishield/.config/stacker/conf.yaml")
53+
--config value stacker config file with defaults (default: "/home/<username>/.config/stacker/conf.yaml")
4954
--debug enable stacker debug mode
5055
-q, --quiet silence all logs
5156
--log-file value log to a file instead of stderr
@@ -102,6 +107,21 @@
102107
--stacker-file-pattern value, -p value regex pattern to use when searching for stackerfile paths (default: "\\/stacker.yaml$")
103108
--search-dir value, -d value directory under which to search for stackerfiles to build (default: ".")
104109

110+
<a name="stacker-convert"></a>
111+
112+
## stacker convert
113+
114+
NAME:
115+
stacker convert - converts a Dockerfile into a stacker yaml file (experimental, best-effort)
116+
117+
USAGE:
118+
stacker convert [command options] [arguments...]
119+
120+
OPTIONS:
121+
--docker-file value, -i value the input Dockerfile (default: "Dockerfile")
122+
--output-file value, -o value the output stacker file (default: "stacker.yaml")
123+
--substitute-file value, -s value the output file containing detected substitutions (default: "stacker-subs.yaml")
124+
105125
<a name="stacker-publish"></a>
106126

107127
## stacker publish
@@ -115,6 +135,7 @@
115135
OPTIONS:
116136
--stacker-file value, -f value the input stackerfile (default: "stacker.yaml")
117137
--stacker-file-pattern value, -p value regex pattern to use when searching for stackerfile paths (default: "\\/stacker.yaml$")
138+
--substitute-file value file containing variable substitution in stackerfiles, 'FOO: bar' yaml format
118139
--search-dir value, -d value directory under which to search for stackerfiles to publish
119140
--url value url where to publish the OCI images
120141
--username value username for the registry where the OCI images are published
@@ -125,6 +146,7 @@
125146
--show-only show the images to be published without actually publishing them
126147
--force force publishing the images present in the OCI layout even if they should be rebuilt
127148
--layer-type value set the output layer type (supported values: tar, squashfs); can be supplied multiple times (default: "tar")
149+
--image value image to be published; can be specified multiple times
128150

129151
<a name="stacker-chroot-exec"></a>
130152

@@ -157,7 +179,7 @@
157179
stacker clean [command options] [arguments...]
158180

159181
OPTIONS:
160-
--all no-op; this used to do soemthing, and is left in for compatibility
182+
--all no-op; this used to do something, and is left in for compatibility
161183

162184
<a name="stacker-inspect"></a>
163185

docs/reference/stacker_file.md

+39-45
Original file line numberDiff line numberDiff line change
@@ -63,50 +63,42 @@ layer on a previously specified layer in the stacker file.
6363

6464
`scratch`: which is an empty rootfs and can be used to host statically built binaries.
6565

66-
### `import`
66+
### `imports`
6767

68-
The `import` directive describes what files should be made available in
69-
`/stacker` during the `run` phase. There are three forms of importing supported
70-
today:
68+
The `imports` directive describes what files should be made available in `/stacker/imports` during the `run` phase. There are three forms of importing supported today:
7169

7270
/path/to/file
7371

74-
Will import a file or directory from the local filesystem. If the file or
75-
directory changes between stacker builds, it will be hashed and the new file
76-
will be imported on subsequent builds.
72+
Will import a file or directory from the local filesystem. If the file or directory changes between stacker builds, it will be hashed and the new file will be imported on subsequent builds.
7773

7874
http://example.com/foo.tar.gz
7975

80-
Will import foo.tar.gz and make it available in `/stacker`. Note that stacker
81-
will NOT update this file unless the cache is cleared, to avoid excess network
82-
usage. That means that updates after the first time stacker downloads the file
83-
will not be reflected.
76+
Will import foo.tar.gz and make it available in `/stacker`. Note that stacker will NOT update this file unless the cache is cleared, to avoid excess network usage. That means that updates after the first time stacker downloads the file will not be reflected.
8477

8578
stacker://$name/path/to/file
8679

87-
Will grab /path/to/file from the previously built layer `$name`.
80+
Will grab /path/to/file from the previously built image `$name`.
8881

8982
#### `import hash`
9083

91-
The `import` directive also supports specifying the hash(sha256sum) of import source,
92-
for all the three forms presented above, for example:
84+
Each entry in the `import` directive also supports specifying the hash (sha256sum) of import source, for all the three forms presented above. For example:
9385
```
94-
import:
86+
imports:
9587
- path: config.json
9688
hash: f55af805b012017bc....
9789
- path: http://example.com/foo.tar.gz
9890
hash: b458dfd63e7883a64....
9991
- path: stacker://$name/path/to/file
10092
hash: f805b012017bc769a....
10193
```
102-
Before copying the file it will check if the requested hash matches the actual one.
94+
Before copying the file, stacker will check that the file's hash matches the given value. For file imports, the source file is hashed at build time. For HTTP imports, the value returned by the server in the `X-Checksum-Sha256` HTTP header is checked first. If that value matches, the file is downloaded and then hashed and compared again.
10395

104-
`stacker build` supports the flag `--require-flag` which checks that all http(s) remote
105-
imports have an hash in all stacker YAMLs.
96+
`stacker build` supports the flag `--require-hash`, which will cause a build error if any HTTP(S) remote imports do not have a hash specified, in all transitively included stacker YAMLs.
97+
98+
If `--require-hash` is not passed, this import mode can be combined with unchecked imports, and only files that have the hash specified will be checked.
10699

107-
This new import mode can be combined with the old one, for example:
108100
```
109-
import:
101+
imports:
110102
- path: "config.json
111103
hash: "BEEFcafeaaaaAAAA...."
112104
- /path/to/file
@@ -116,13 +108,17 @@ import:
116108

117109
The `import` directive also supports specifying the destination path (specified
118110
by `dest`) in the resulting container image, where the source file (specified
119-
by `path`) will be copyied to, for example:
111+
by `path`) will be copyed to. For example:
120112
```
121-
import:
113+
imports:
122114
- path: config.json
123115
dest: /
124116
```
125117

118+
### `import` (Deprecated)
119+
120+
The deprecated `import` directive operates like `imports` except that the entries in the `import` array will be placed into `/stacker` instead of `/stacker/imports`.
121+
126122
### `overlay_dirs`
127123
This directive works only with OverlayFS backend storage.
128124

@@ -146,7 +142,7 @@ to be available under container's /usr/local/ and all the files/dirs from the ho
146142
These correspond exactly to the similarly named bits in the [OCI image
147143
config
148144
spec](https://github.com/opencontainers/image-spec/blob/master/config.md#properties),
149-
and are available for users to pass things through to the runtime environment
145+
and are available for users to pass variables through to the runtime environment
150146
of the image.
151147

152148
### `generate_labels`
@@ -163,19 +159,17 @@ be the label content.
163159
By default, environment variables do not pass through (pollute) the
164160
build environment.
165161

166-
`build_env`: this is a dictionary with environment variable definitions.
167-
their values will be present in the build's environment.
162+
`build_env`: A dictionary of environment variable definitions. The values will be present in the build's environment.
168163

169-
`build_env_passthrough`: This is a list of regular expressions that work as a
164+
`build_env_passthrough`: A list of regular expressions that work as a
170165
filter on which environment variables should be passed through from the current
171-
env into the container. To let all variables through simply set
166+
env into the container. To let all variables through, simply set
172167
`build_env_passthrough`: `[".*"]`
173168

174-
If `build_env_passthrough` is not set, then the default value is to allow
175-
through proxy variables `HTTP_PROXY, HTTPS_PROXY, FTP_PROXY, http_proxy,
176-
https_proxy, ftp_proxy`.
169+
If `build_env_passthrough` is not set, the default behavior is to allow
170+
through proxy variables `HTTP_PROXY, HTTPS_PROXY, FTP_PROXY, http_proxy, https_proxy, ftp_proxy`.
177171

178-
Values in the `build_env` override values passed through via
172+
Values in the `build_env` override values passed through via `build_env_passthrough`.
179173

180174
### `full_command`
181175

@@ -199,18 +193,18 @@ not include all of its build dependencies.
199193
- /foo/bar -> /bar/baz
200194
- /zomg
201195

202-
The first one binds /foo/bar to /bar/baz, and the second host /zomg to
196+
The first binds /foo/bar to /bar/baz, and the second binds host /zomg to
203197
container /zomg.
204198

205-
Right now there is no awareness of change for any of these bind mounts, so
206-
--no-cache should be used to re-build if the content of the bind mount has
199+
At this time there is no awareness of change for any of these bind mounts, so
200+
`--no-cache` should be used to re-build if the content of the bind mount has
207201
changed.
208202

209203
### `config`
210204

211-
`config` key is a special type of entry in the root in the `stacker.yaml` file.
212-
It cannot contain a layer definition, it is used to provide configuration
213-
applicable for building all the layers defined in this file. For example,
205+
The `config` key is a special type of entry in the root of the `stacker.yaml` file.
206+
It cannot contain an image definition; it is used to provide configuration
207+
applicable for building all the images defined in this file. For example,
214208

215209
config:
216210
prerequisites:
@@ -220,17 +214,17 @@ applicable for building all the layers defined in this file. For example,
220214
#### `prerequisites`
221215

222216
If the `prerequisites` list is present under the `config` key, stacker will
223-
make sure to build all the layers in the stacker.yaml files found at the paths
224-
contained in the list. This way stacker supports building multiple
217+
make sure to build all the images in the stacker.yaml files found at the paths
218+
contained in the list. In this way, stacker supports building multiple
225219
stacker.yaml files in the correct order.
226220

227-
In this particular case the parent folder of the current folder, let's call it
228-
`parent`, has 3 subfolders `folder1`, `folder2` and `folder3`, each containing a
221+
In this particular case, the parent folder of the current folder, let's call it
222+
`parent`, has 3 subfolders (`folder1`, `folder2`, and `folder3`), each containing a
229223
`stacker.yaml` file. The example `config` above is in `parent/folder1/stacker.yaml`.
230224

231-
When `stacker build -f parent/folder1/stacker.yaml` is invoked, stacker would search
232-
for the other two stacker.yaml files and build them first, before building
233-
the stacker.yaml specified in the command line.
225+
When `stacker build -f parent/folder1/stacker.yaml` is invoked, stacker searches
226+
for the other two stacker.yaml files and builds them first, before building
227+
the stacker.yaml file specified in the command line.
234228

235229
#### `annotations`
236230

@@ -242,7 +236,7 @@ itself and not as part of the index.json.
242236
a.b.c.key: abc_val
243237
p.q.r.key: pqr_val
244238

245-
While `config` section supports a similar `labels`, it is more pertitent to the
239+
While the `config` section supports a similar `labels`, it is more pertinent to the
246240
image runtime. On the other hand, `annotations` is intended to be
247241
image-specific metadata aligned with the
248242
[annotations in the image spec](https://github.com/opencontainers/image-spec/blob/main/annotations.md).

docs/user_guide/annotation_support.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ itself and not as part of the index.json.
88
a.b.c.key: abc_val
99
p.q.r.key: pqr_val
1010

11-
While `config` section supports a similar `labels`, it is more pertitent to the
11+
While the `config` section supports a similar `labels`, it is more pertinent to the
1212
image runtime. On the other hand, `annotations` is intended to be
1313
image-specific metadata aligned with the
1414
[annotations in the image spec](https://github.com/opencontainers/image-spec/blob/main/annotations.md).

docs/user_guide/convert_dockerfile.md

+32
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
# Convert a Dockerfile to stacker yaml
2+
3+
When moving a project from a docker build environment to a stacker build environment, you can use the [`stacker convert`](../reference/stacker_cli.md#stacker-convert) command to create a stacker yaml file from the existing Dockerfile.
4+
5+
!!! note
6+
7+
The conversion is a best-effort process and may not be successful in all cases.
8+
9+
During the conversion, variables from the Dockerfile may be exported to a substitution file, which can be declared in the `stacker build` command when building the project.
10+
11+
When invoking the `stacker convert` command, you have the option to specify the input (Dockerfile) filename, an output (stacker) filename, and a name for a substitution file, if such a file is generated by the conversion. Alternatively, you can use the default names provided:
12+
13+
14+
| Command option | Abbreviation | Default name |
15+
| --- | --- | --- |
16+
| --docker-file | -i | "Dockerfile" |
17+
| --output-file | -o | "stacker.yaml" |
18+
| --substitute-file | -s | "stacker-subs.yaml" |
19+
20+
21+
To execute a conversion, use the following syntax:
22+
23+
stacker convert [-i <name>] [-o <name>] [-s <name>]
24+
25+
26+
27+
28+
29+
30+
31+
32+

0 commit comments

Comments
 (0)