|
1 | 1 | # Packer-based image build
|
2 | 2 |
|
3 |
| -The appliance contains code and configuration to use [Packer](https://developer.hashicorp.com/packer) with the [OpenStack builder](https://www.packer.io/plugins/builders/openstack) to build images. |
4 |
| - |
5 |
| -The Packer configuration defined here builds "fat images" which contain packages, binaries and container images but no cluster-specific configuration. Using these: |
6 |
| - |
7 |
| -- Enables the image to be tested in CI before production use. |
8 |
| -- Ensures re-deployment of the cluster or deployment of additional nodes can be completed even if packages are changed in upstream repositories (e.g. due to RockyLinux or OpenHPC updates). |
9 |
| -- Improves deployment speed by reducing the number of package downloads to improve deployment speed. |
10 |
| - |
11 |
| -The fat images StackHPC builds and tests in CI are available from [GitHub releases](https://github.com/stackhpc/ansible-slurm-appliance/releases). However with some additional configuration it is also possible to: |
12 |
| - |
13 |
| -1. Build site-specific fat images from scratch. |
14 |
| -2. Extend an existing fat image with additional functionality. |
| 3 | +The appliance contains configuration to use [Packer](https://developer.hashicorp.com/packer) |
| 4 | +with the [OpenStack builder](https://www.packer.io/plugins/builders/openstack) |
| 5 | +to build images. Using images: |
| 6 | + |
| 7 | +- Enables the image to be tested in a `staging` environment before deployment |
| 8 | + to the `production` environment. |
| 9 | +- Ensures re-deployment of the cluster or deployment of additional nodes is |
| 10 | + repeatable. |
| 11 | +- Improves deployment speed by reducing the number of package installation. |
| 12 | + |
| 13 | +The Packer configuration here can be used to build two types of images: |
| 14 | + |
| 15 | +1. "Fat images" which contain packages, binaries and container images but no |
| 16 | + cluster-specific configuration. These start from a RockyLinux GenericCloud |
| 17 | + (or compatible) image. The fat images StackHPC builds and tests in CI are |
| 18 | + available from [GitHub releases](https://github.com/stackhpc/ansible-slurm-appliance/releases). |
| 19 | + However site-specific fat images can also be built from a different source |
| 20 | + image e.g. if a different partition layout is required. |
| 21 | +2. "Extra-build" images which extend a fat image to create a site-specific |
| 22 | + image with with additional packages or functionality. For example the NVIDIA |
| 23 | + `cuda` packages cannot be redistributed hence require an "extra" build. |
15 | 24 |
|
16 | 25 | ## Usage
|
17 | 26 |
|
18 |
| -To build either a site-specific fat image from scratch, or to extend an existing StackHPC fat image: |
19 |
| - |
20 |
| -1. Ensure the current OpenStack credentials have sufficient authorisation to upload images (this may or may not require the `member` role for an application credential, depending on your OpenStack configuration). |
21 |
| -2. The provided dev credentials for StackHPC's "Ark" Pulp server must be added to the target environments. This is done by overriding `dnf_repos_username` and `dnf_repos_password` with your vault encrypted credentials in `environments/<base_environment>/inventory/group_vars/all/pulp.yml`. See the [experimental docs](experimental/pulp.md) if you wish instead wish to use a local Pulp server. |
22 |
| -3. Create a Packer [variable definition file](https://developer.hashicorp.com/packer/docs/templates/hcl_templates/variables#assigning-values-to-input-variables) at e.g. `environments/<environment>/builder.pkrvars.hcl` containing at a minimum: |
23 |
| - |
24 |
| -```hcl |
25 |
| -flavor = "general.v1.small" # VM flavor to use for builder VMs |
26 |
| -networks = ["26023e3d-bc8e-459c-8def-dbd47ab01756"] # List of network UUIDs to attach the VM to |
27 |
| -source_image_name = "Rocky-9-GenericCloud-Base-9.4" # Name of image to create VM with, i.e. starting image |
28 |
| -inventory_groups = "control,login,compute" # Additional inventory groups to add build VM to |
29 |
| -``` |
30 |
| - |
31 |
| -Note that: |
32 |
| - |
33 |
| -- The network used for the Packer VM must provide outbound internet access but does not need to provide access to resources which the final cluster nodes require (e.g. Slurm control node, network filesystem servers etc.). |
34 |
| -- The flavor used must have sufficent memory for the build tasks, but otherwise does not need to match the final cluster nodes. Usually 8GB is sufficent. By default, the build VM is volume-backed to allow control of the root disk size (and hence final image size) so the flavor disk size does not matter. |
35 |
| -- The source image should be either a RockyLinux GenericCloud image for a site-specific image build from scratch, or a StackHPC fat image if extending an existing image. |
36 |
| -- The `inventory_groups` variable takes a comma-separated list of Ansible inventory groups to add the build VM to. This is in addition to the `builder` group which it is always added to. This controls which Ansible roles and functionality run during build, and hence what gets added to the image. |
37 |
| - All possible groups are listed in `environments/common/groups` but common options for this variable will be: |
38 |
| - - `update,control,login,compute`: The resultant image has all packages in the source image updated, and then packages for all types of nodes in the cluster are added. When using a GenericCloud image for `source_image_name` this builds a site-specific fat image from scratch. |
39 |
| - - One or more specific groups which are not enabled in the appliance by default, e.g. `lustre`. When using a StackHPC fat image for `source_image_name` this extends the image with just this additional functionality. |
| 27 | +For either a site-specific fat-image build or an extra-build: |
| 28 | + |
| 29 | +1. Ensure the current OpenStack credentials have sufficient authorisation to |
| 30 | + upload images (this may or may not require the `member` role for an |
| 31 | + application credential, depending on your OpenStack configuration). |
| 32 | +2. If package installs are required, add the provided dev credentials for |
| 33 | + StackHPC's "Ark" Pulp server to the `site` environment: |
| 34 | + |
| 35 | + ```yaml |
| 36 | + # environments/site/inventory/group_vars/all/dnf_repos.yml: |
| 37 | + dnf_repos_username: your-ark-username |
| 38 | + dnf_repos_password: "{{ vault_dnf_repos_password }}" |
| 39 | + ``` |
| 40 | +
|
| 41 | + ```yaml |
| 42 | + # environments/site/inventory/group_vars/all/dnf_repos.yml: |
| 43 | + dnf_repos_password: "your-ark-password" |
| 44 | + ``` |
| 45 | +
|
| 46 | + > [!IMPORTANT] |
| 47 | + > The latter file should be vault-encrypted. |
| 48 | +
|
| 49 | + Alternatively, configure a [local Pulp mirror](experimental/pulp.md). |
| 50 | +
|
| 51 | +3. Create a Packer [variable definition file](https://developer.hashicorp.com/packer/docs/templates/hcl_templates/variables#assigning-values-to-input-variables). It must specify at least the |
| 52 | + the following variables: |
| 53 | +
|
| 54 | + ```hcl |
| 55 | + # environments/site/builder.pkrvars.hcl: |
| 56 | + flavor = "general.v1.small" # VM flavor to use for builder VMs |
| 57 | + networks = ["26023e3d-bc8e-459c-8def-dbd47ab01756"] # List of network UUIDs to attach the VM to |
| 58 | + source_image_name = "Rocky-9-GenericCloud-Base-9.4" # Name of image to create VM with, i.e. starting image |
| 59 | + inventory_groups = "doca,cuda,extra_packages" # Build VM inventory groups => functionality to add to image |
| 60 | + ``` |
| 61 | + |
| 62 | + See the top of [packer/openstack.pkr.hcl](../packer/openstack.pkr.hcl) |
| 63 | + for all possible variables which can be set. |
| 64 | + |
| 65 | + Note that: |
| 66 | + |
| 67 | + - Normally the network must provide outbound internet access. However it |
| 68 | + does not need to provide access to resources used by the actual cluster |
| 69 | + nodes (e.g. Slurm control node, network filesystem servers etc.). |
| 70 | + - The flavor used must have sufficent memory for the build tasks (usually |
| 71 | + 8GB), but otherwise does not need to match the actual cluster node |
| 72 | + flavor(s). |
| 73 | + - By default, the build VM is volume-backed to allow control of the root |
| 74 | + disk size (and hence final image size), so the flavor's disk size does not |
| 75 | + matter. The default volume size is not sufficent if enabling `cuda` and/or |
| 76 | + `doca` and should be increased: |
| 77 | + ```terraform |
| 78 | + volume_size = 35 # GB |
| 79 | + ``` |
| 80 | + - The source image should be either: |
| 81 | + - For a site-specific fatimage build: A RockyLinux GenericCloud or |
| 82 | + compatible image. |
| 83 | + - For an extra-build image: Usually the appropriate StackHPC fat image, |
| 84 | + as defined in `environments/.stackhpc/tofu/cluster_image.auto.tfvars.json` at the |
| 85 | + checkout's current commit. See the [GitHub release page](https://github.com/stackhpc/ansible-slurm-appliance/releases) |
| 86 | + for download links. In some cases extra builds may be chained, e.g. |
| 87 | + one extra build adds a Lustre client, and the resulting image is used |
| 88 | + as the source image for an extra build adding GPU support. |
| 89 | + - The `inventory_groups` variable takes a comma-separated list of Ansible |
| 90 | + inventory groups to add the build VM to (in addition to the `builder` |
| 91 | + group which is it always in). This controls which Ansible roles and |
| 92 | + functionality run during build, and hence what gets added to the image. |
| 93 | + All possible groups are listed in `environments/common/groups` but common |
| 94 | + options for this variable will be: |
| 95 | +
|
| 96 | + - For a fatimage build: `fatimage`: This is defined in `enviroments/site/inventory/groups` |
| 97 | + and results in an update of all packages in the source image, plus |
| 98 | + installation of packages for default control, login and compute nodes. |
| 99 | +
|
| 100 | + - For an extra-built image, one or more specific groups. This extends the |
| 101 | + source image with just this additional functionality. The example above |
| 102 | + installs NVIDIA DOCA network drivers, NVIDIA GPU drivers/Cuda packages |
| 103 | + and also enables installation of packages defined in the |
| 104 | + `appliances_extra_packages_other` variable (see |
| 105 | + [docs/operations.md](./operations.md#adding-additional-packages)). |
40 | 106 |
|
41 | 107 | 4. Activate the venv and the relevant environment.
|
42 | 108 |
|
43 | 109 | 5. Build images using the relevant variable definition file, e.g.:
|
44 | 110 |
|
45 |
| -```shell |
46 |
| -cd packer/ |
47 |
| -PACKER_LOG=1 /usr/bin/packer build -on-error=ask -var-file=$PKR_VAR_environment_root/builder.pkrvars.hcl openstack.pkr.hcl |
48 |
| -``` |
| 111 | + ```shell |
| 112 | + cd packer/ |
| 113 | + PACKER_LOG=1 /usr/bin/packer build -on-error=ask -var-file=../environments/site/builder.pkrvars.hcl openstack.pkr.hcl |
| 114 | + ``` |
49 | 115 |
|
50 |
| -**NB:** If the build fails while creating the volume, check if the source image has the `signature_verified` property: |
| 116 | + **NB:** If the build fails while creating the volume, check if the source image has the `signature_verified` property: |
51 | 117 |
|
52 |
| -```shell |
53 |
| -openstack image show $SOURCE_IMAGE |
54 |
| -``` |
| 118 | + ```shell |
| 119 | + openstack image show $SOURCE_IMAGE |
| 120 | + ``` |
55 | 121 |
|
56 |
| -If it does, remove this property: |
| 122 | + If it does, remove this property: |
57 | 123 |
|
58 |
| -```shell |
59 |
| -openstack image unset --property signature_verified $SOURCE_IMAGE |
60 |
| -``` |
| 124 | + ```shell |
| 125 | + openstack image unset --property signature_verified $SOURCE_IMAGE |
| 126 | + ``` |
61 | 127 |
|
62 |
| -then delete the failed volume, select cancelling the build when Packer queries, and then retry. This is [OpenStack bug 1823445](https://bugs.launchpad.net/cinder/+bug/1823445). |
| 128 | + then delete the failed volume, select cancelling the build when Packer asks, |
| 129 | + and then retry. This is [OpenStack bug 1823445](https://bugs.launchpad.net/cinder/+bug/1823445). |
63 | 130 |
|
64 |
| -6. The built image will be automatically uploaded to OpenStack with a name prefixed `openhpc` and including a timestamp and a shortened Git hash. |
| 131 | +6. The built image will be automatically uploaded to OpenStack. By default it |
| 132 | + will have a name prefixed `openhpc` and including a timestamp and a shortened |
| 133 | + Git hash. |
65 | 134 |
|
66 | 135 | ## Build Process
|
67 | 136 |
|
|
0 commit comments