Skip to content

base-common-images.md

Latest commit

 

History

History
77 lines (49 loc) · 3.51 KB

base-common-images.md

File metadata and controls

77 lines (49 loc) · 3.51 KB
Raw

Define and use base and common images

Base and common images are the images CloudHarness builds for your applications to inherit from as build dependencies.

Some default base and common images are provided by Cloud Harness and can be customized in your project; following the same pattern, can also define other images that can be reused across your project applications and tasks. Define them when you want your applications to share libraries, tooling or a common stack.

Note: If you are interested in customizing where external base images are pulled from, see image sources.

Relevant files and directory structure

  • base-images: base Docker images. Those images can used as base images in CloudHarness apps and tasks.
  • common-images: Static images. Those images can derive from base images can be also used as base images in CloudHarness apps and tasks.

Base images and common images

The main difference between the base images and common images is that base images are built in the root context, while common images are built in their local context. So, base images are general purpose and are mainly used to provide access to shared libraries alongside the solution, while common images can have a specific purpose (e.g. enable widely used application stacks to inherit from).

Use in applications and tasks

After generating the codeChange the Dockerfile in order to inherit from the main Docker image need to:

  1. Add the image as a build dependency to the values.yaml file of your application. The name of the image corresponds to the directory name where the Dockerfile is located
harness:
  dependencies:
    build:
    - cloudharness-base
  1. Refer to the base image with the uppercased-underscored name of the dependency as an argument
ARG CLOUDHARNESS_BASE
FROM $CLOUDHARNESS_BASE

Notice: the dependency may work if other applications in the same deployment declare the same dependency. Anyway, it'a always recommended to specify the dependency wherever it is used

In multi-stage builds, more than one build dependency can be added and referred.

In workflow tasks, the build dependency must be specified in the main application where it is defined.

Default images

CloudHarness defines the following base images:

  • cloudharness-base: python-alpine with cloudharness common libraries preinstalled
  • cloudharness-django: cloudharness-base with cloudharness django fastapi libraries preinstalled
  • cloudharness-fastapi: cloudharness-base with fastapi libraries preinstalled

Also the following common images are defined:

  • cloudharness-flask: common ground image to create Flask backends

Override base and common images from CloudHarness

To override a base or common image just create the same directory path in your solution. The overriding can be used to replace files used in the build process or the Dockerfile itself.

For example, overriding cloudharness-base could be useful to change some behaviour in the CloudHarness libraries or to provide new libraries to share within all applications.

To override cloudharness-base, create a directory MY_SOLUTION/infrastructure/base-images/cloudharness-base then run harness-deployment cloudharness MY_SOLUTION

Change the image a Dockerfile inherits from

Defining a base image is not the only way to change what an application's Dockerfile inherits from. The image each FROM resolves to is itself configurable, per deployment, and is described in image sources.