particle-os-cli/template/templates/modules/containerfile
Gerald Pinder 8069006c03
feat: Stages (#173)
## Stages

A new property (`stages`) is being added to the recipe file schema. This
property will allow users to define a list of Containerfile stages each
with their own modules. Stages can be used to compile programs, perform
parallel operations, and copy the results into the final image without
contaminating the final image.

### Module Support

Currently the only modules that work out-of-the-box are `copy`,
`script`, `files`, and `containerfile`. Other modules are dependent on
the programs installed on the image. In order to better support some of
our essential modules, a setup script is ran at the start of each stage
that is not `scratch`. This script will install `curl`, `wget`, `bash`,
and `grep` and use the package manager for the detected distributions.

At this time, the following distributions are supported:

- Debian
- Ubuntu
- Fedora
- Alpine

Contributions to increase the size of this list is
[welcome](https://github.com/blue-build/cli)!

### Syntax

- **Required**
- `from` - The full image ref (image name + tag). This will be set in
the `FROM` statement of the stage.
- `name` - The name of the stage. This is used when referencing the
stage when using the `from:` property in the `copy` module.
- `modules` - The list of modules to execute. The exact same syntax used
by the main recipe `modules:` property.
- **Optional**
- `shell` - Allows a user to pass in an array of strings that are passed
directly into the [`SHELL`
instruction](https://docs.docker.com/reference/dockerfile/#shell).

#### Example

```yaml
stages:
- name: ubuntu-test
  from: ubuntu
  modules:
  - type: files
    files:
    - usr: /usr
  - type: script
    scripts:
    - example.sh
    snippets:
    - echo "test" > /test.txt
  - type: test-module
  - type: containerfile
    containerfiles:
    - labels
    snippets:
    - RUN echo "This is a snippet"
```

### Tasks
- [x] `from-file:` - Allows the user to store their stages in a separate
file so it can be included in multiple recipes
- [x] `no-cache:` - This will be useful for stages that want to pull the
latest changes from a git repo and not have to rely on the base image
getting an update for the build to be triggered again.
- [x] Add setup script to be able to install necessary programs to run
`bluebuild` modules in stages
- [x] Check for circular dependencies and error out

## `copy` module

This is a 1-1 for the [`COPY`
instruction](https://docs.docker.com/reference/dockerfile/#copy). It has
the ability to copy files between stages, making this a very important
addition to complete functionality for the stages feature. Each use of
this "module" will become its own layer.

### Decision to use `--link`

We use the `--link`
[option](https://docs.docker.com/reference/dockerfile/#benefits-of-using---link)
which allows that layer to have the same hash if the files haven't
changed regardless of if the previous instructions have changed. This
allows these layers to not have to be re-downloaded on the user's
computer if the copied files haven't changed.

### Syntax

- **Required**
- `src` - The source directory/file from the repo OR when `from:` is set
the image/stage that is specified.
  - `dest` - The destination directory/file inside the working image.
- **Optional**
  - `from` - The stage/image to copy from.

#### Example

```yaml
modules:
- type: copy
  from: ubuntu-test
  src: /test.txt
  dest: /
```

### Tasks
- [x] make `from:` optional
- [x] Add README.md and module.yml

## Feature gating

Gating this feature until we release for `v0.9.0`. The plan will be to
build all features (including this one) for main branch builds. This
means that these features will be available when using the `main` image
and consequently the `use_unstable_cli:` option on the GitHub Action.
All future `v0.9.0` features will be gated as well to allow for patches
to `v0.8`.

### Tasks
- [x] Build `--all-features` on non-tagged builds
- [x] Add stages and copy features
2024-05-18 13:23:50 +00:00
..
containerfile.j2 refactor: Move templates to their own crate (#83) 2024-02-25 14:45:33 -06:00
module.yml feat: Stages (#173) 2024-05-18 13:23:50 +00:00
README.md feat: Stages (#173) 2024-05-18 13:23:50 +00:00

containerfile

:::caution Only compiler-based builds can use this module as it is built-in to the BlueBuild CLI tool. :::

The containerfile module is a tool for adding custom Containerfile instructions for custom image builds. This is useful when you wish to use some feature directly available in a Containerfile, but not in a bash module, such as using a RUN instruction with custom mounts.

Since standard compiler-based BlueBuild image builds generate a Containerfile from your recipe, there is no need to manage it yourself. However, we know that we also have technical users that would like to have the ability to customize their Containerfile. This is where the containerfile module comes into play.

Usage

snippets:

The snippets property is the easiest to use when you just need to insert a few custom lines to the Containerfile. Each entry under the snippets property will be directly inserted into your final Containerfile for your build.

modules:
  - type: containerfile
    snippets:
      - RUN --mount=type=tmpfs,target=/tmp /some/script.sh

This makes it really easy to add individual, custom instructions.

:::note NOTE: Each entry of a snippet will be its own layer in the final Containerfile. :::

containerfiles:

The containerfiles property allows you to tell the compiler which directory contains a Containerfile in ./containerfiles/.

Below is an example of how a containerfile module would be used with the containerfiles property:

modules:
  - type: containerfile
    containerfiles:
      - example
      - subroutine

In the example above, the compiler would look for these files:

  • ./containerfiles/example/Containerfile
  • ./containerfiles/subroutine/Containerfile

You could then store files related to say the subroutine Containerfile in ./containerfiles/subroutine/ to keep it organized and portable for other recipes to use.

:::note NOTE: The instructions you add in your Containerfile's each become a layer unlike other modules which are typically run as a single RUN command, thus creating only one layer. :::

Order of operations

The order of operations is important in a Containerfile. There's a very simple set of rules for the order in this module:

  • For each defined containerfile module:
    • First all containerfiles: are added to the main Containerfile in the order they are defined
    • Then all snippets are added to the main Containerfile in the order they are defined

If you wanted to have some snippets run before any containerfiles have, you will want to put them in their own module definition before the entry for containerfiles. For example:

modules:
  - type: containerfile
    snippets:
      - RUN --mount=type=tmpfs,target=/tmp /some/script.sh
  - type: containerfile
    containerfiles:
      - example
      - subroutine

In the example above, the COPY from the snippets will always come before the containerfiles "example" and "subroutine".