Setting up Init Container for Customization

You can now configure an init container to apply customizations to the product during certified container deployment. All the customizations from the init container are mounted to the application containers during initialization. These customizations are then applied to the product as soon as the application containers begin running when the application containers get into running state.

The new customization init container is an alternative to deploying customization via Customization UI/APIs. You can choose either of the options for deploying your customization, however you cannot choose both the options at the same time. Once the customization init container option is enabled in helm charts, the Customization UI is available for viewing in read-only mode. During this phase, you cannot add, edit, or remove any customization using the Customization UI.

Tip:

When you enable the customization init container option, it will automatically delete any customizations you previously added through the Customization UI. These will be replaced by the customizations included in the customization init container. Make sure to review the customizations you have on the Customization UI and confirm that all the required ones have been included in the customization init container image before you enable this feature.

On the other hand, if you switch back from customization init container to Customization UI, then the customizations need to be cleaned-up manually from the Customization UI and applied again.

The Customization UI saves all customizations uploaded through the UI/API in the database, drawbacks of which, especially if there are many customizations, are as highlighted below:
  • During application startup, it retrieves all customizations from the database and applies them to the application sequentially using the traditional install3rdParty and InstallService. This method works well with few customizations, but as the number increases, it significantly slows down the container startup time.
  • There are limitations to deleting or updating customizations once they are installed.
  • The size of the customization file further degrades the performance of the pod startup time.
On the other hand, when using the customization init container feature, customizations are applied at the file system directly. The advantages of which are as mentioned below:
  • You can add any number of customizations without relatively impacting the pod startup time.
  • All updates to the database for custom services and Customization UI entries for view-only are handled as part of the db setup job as a one-time database update during application install or upgrade.
  • Updates to the database for customizations are only required when there are changes to the customizations or new custom services are added to the image.
  • There is no limit to the size of the custom jars or services that can be added to the product.
  • You can easily delete or update customizations by just updating the customization container image.
Tip: You now have two options for customizing your setup: continue using the customization UI or switch to the new customization init container option. The choice depends on the kind and number of customizations you need. If your changes are simple, like overriding property values or adding a few light-weight custom jars or services, the customization UI option is convenient and avoids the additional overhead of building an image. However, if you have many customizations with significantly high number of custom jars and/or services, the new customization init container is the best suited option given its substantial benefits list above.
Note: With the new customization init container feature, the node installation status for each customization shown on the Customization UI will no longer be added or updated anymore. Applying customizations with the init container is a single-step process which can be enabled through helm configurations. All customizations from the init image will be applied to the application automatically if the option is enabled. This avoids unnecessary database updates during pod startup and termination which in turn speeds up the pod performance.

The other significant advantage with the customization init container is that all the customizations can now be maintained on a single source repository, built and packaged using CI/CD pipelines, as an independent container image purpose-built for customization. This helps with better handling and maintainability of all customization resources.

The customization init container supports all product customization options currently supported by customization UI, along with a few extra options. The supported customizations include:
  1. Custom Third-party Libraries libraries including jars, db driver jars, properties and shared or native libraries
  2. Custom Services
  3. User Exits
  4. Custom Properties including override files and adding new/or updating existing product property files
  5. Custom SFG Protocols
  6. UI Branding for all currently supported web interfaces including dashboard, mailbox, filegateway, myfilegateway and myfg20
  7. Liberty or API server extensions (new)
  8. Startup script extensions (new)