Base Image Override Files

When using KIB to create an OS image that is compliant with DKP, the instructions on how to build and configure the image are included in the file located in images/<builder-type>/<os-version.yaml, as seen below:

./konvoy-image build images/<builder-type>/{os}-{version}.yaml

In previous versions of KIB, only Azure and AWS providers were available. Therefore, specifying a vSphere was not necessary.

Although there are several parameters specified by default in the Packer templates for each provider, it is possible to override the default values.

One option is to execute KIB with specific flags to override the values of the source AMI (--source-ami), AMI region (--ami-regions), AWS EC2 instance type (--aws-instance-type), and so on. For a comprehensive list of these flags, please run:

CODE

./konvoy-image build --help

Another option is by creating a file with the parameters to be overridden and specify the --overrides flag as shown below:

CODE

./konvoy-image build images/<builder-type>/<os>-<version>.yaml --overrides overrides.yaml

While CLI flags can be used in combination with override files, CLI flags take priority over any override files.

Example 1:

For example, when using the AWS Packer builder to override the above base image with another base image, create an override file and set the source_ami under the packer key. This overrides the image search and forces the use of the specified source_ami.

CODE

---
packer:
  source_ami: "ami-0123456789"

After creating the override file for our source_ami, we can pass our override file by using the --overrides flag when building our image. Replace infrastructure provider in the command below before running it (aws, azure, vsphere) :

CODE

./konvoy-image build aws images/ami/centos-7.yaml --overrides override-source-ami.yaml

Example 2:

To abide to security practices, a user could set their own username and password while creating the base OS image and override the default credentials in KIB. To do this, create a file with the following content:

CODE

---
packer:
  ssh_username: "<USERNAME>"
  ssh_password: "<PASSWORD>"

For a complete list of the variables that can be modified for each Packer builder, users can refer to:

An AWS example would be the current base image description at images/ami/centos-7.yaml which is similar to the following:

CODE

---
# Example images/ami/centos-7.yaml 
download_images: true
packer:
  ami_filter_name: "CentOS 7.9.2009 x86_64"
  ami_filter_owners: "125523088429"
  distribution: "CentOS"
  distribution_version: "7"
  source_ami: ""
  ssh_username: "centos"
  root_device_name: "/dev/sda1"
build_name: "centos-7"
packer_builder_type: "amazon"
python_path: ""

or

An Azure example would be the current base image description at images/azure/centos-79.yaml which is similar to the following:

CODE

---
# Example images/azure/centos-79.yaml
download_images: true
packer:
  distribution: "centos"  #offer
  distribution_version: "7_9-gen2"  #SKU
  image_publisher: "openlogic"
  image_version: "latest"
  ssh_username: "centos"
  
build_name: "centos-7"
packer_builder_type: "azure"
python_path: ""

or

A vSphere example would be the current base image description at images/vsphere/rhel-79.yaml which is similar to the following:

CODE

---
download_images: true
build_name: "rhel-79"
packer_builder_type: "vsphere"
guestinfo_datasource_slug: "https://raw.githubusercontent.com/vmware/cloud-init-vmware-guestinfo"
guestinfo_datasource_ref: "v1.4.0"
guestinfo_datasource_script: "{{guestinfo_datasource_slug}}/{{guestinfo_datasource_ref}}/install.sh"
packer:
cluster: "zone1"
  datacenter: "dc1"
  datastore: "esxi-06-disk1"
  folder: "cluster-api"
  insecure_connection: "false"
  network: "Airgapped"
  resource_pool: "Users"
  template: "base-rhel-7"
  vsphere_guest_os_type: "rhel7_64Guest"
  guest_os_type: "rhel7-64"
  #goss params
  distribution: "RHEL"
  distribution_version: "7.9"

See Supported Operating Systems for details.