Introduction
This is the first part of the three-part blog post series on containerization & orchestration technologies Docker and Kubernetes with SAP Commerce (Hybris). This series aims at leveraging Docker and Kubernetes to deploy and run SAP Commerce (Hybris) and Solr standalone in master-slave mode on the cloud.
Series is divided into 3 parts:
- Introduction to Aspects and Valtech Custom Recipe
- Create Hybris, DB & Solr Docker images
- Run Hybris on Google Kubernetes Engine
Valtech offers a custom recipe that makes creation, configuration of Hybris Docker images easier. In this post, we look at the details of the recipe and we also look at the concept of aspects and understand the details and configuration of the custom aspect. Both concepts act as an introduction for the second and third parts of the blog post series.
This post assumes that you have knowledge of Docker and SAP Commerce (Hybris). The platform version used in this blog post is SAP Commerce 1905.
In this post, terms SAP Commerce and Hybris are used interchangeably, they both mean the same.
Docker image can be created in two ways. One way is by running the ant task 'createPlatformImageStructure' that comes with the platform, and the second way is by using a Valtech custom recipe.
Create Hybris Docker image using ant task
Hybris provides a way to create a Docker image via ant task 'createPlatformImageStructure'. More details are available here.
Below are ant commands that need to be executed:
$ ant production -Dproduction.include.tomcat=false -Dproduction.legacy.mode=false -Dtomcat.legacy.deployment=false -Dproduction.create.zip=false
$ ant createPlatformImageStructureEasy peasy, right? The obvious question that should have crossed your mind by now if you are like me is - "If Hybris provides a way to create Docker image, why need a different approach?" Let's examine that below.
Why custom recipe?
The advantage of the recipe is, local.properties like DB URL, Solr URL, and few other properties change for every environment (Dev, Staging, Production). For example, you built a platform image that has all the needed functionality, but you need to build a separate image for every environment with the right set of properties, which is not necessarily a bad thing, but if you want to create one image and use it on all environments by externalizing properties as mentioned above and to be able set them during runtime, wouldn't that be cool? Recipe exactly does that!
Going forward, the rest of this article focuses on creating Docker images from the custom recipe.
Using the custom recipe
Enough introduction, let's dive into the details. The recipe can be cloned from the repository. Creating Docker images from the recipe is explained in the second part of this series. This recipe provides everything you need to install SAP Hybris Commerce Responsive B2C Commerce Accelerator with Spartacus related extensions and containerizing HSQLDB and Hybris platform.
Let's get an understanding of the key components of the recipe, and we will go into detail into each component.
build.gradle contains configuration for two Docker images (Hybris and HsqlDB).
Hybris configuration
Hybris has a platform containerization Gradle plugin to create Docker images. Custom recipe extends the plugin. Documentation for the platform plugin can be found here.
As you can notice, inside platformimage/dockerbasics directory, you can see template files; they serve as the base templates. You can make changes to these files should you need to add/remove anything. The template files have placeholders, and these would be replaced with values from default.properties files when Gradle task is run to create the Dockerfile.
One more benefit of using this recipe is, let's say that there is a need to change ajpPort of the Tomcat. Using recipe, tomcat port can be configured in the recipe and easily maintained in the code repository. With ant task, it is not possible because the changes have to be made inside the platform folder, which is not maintained in the repo.
Snippet from Dockerfile.tmpl
default.properties (properties can be changed to suit your needs)
As mentioned above, one of the things you can do with this recipe is to externalize the configuration. Let's see how that can be done. As you may know that build.gradle allows you to define local.properties among other things. In that section, you can define placeholders for properties values and Dockerfile allows you to configure properties that would be replaced during runtime. Any properties that are specific to your project that you want to externalize can be added to build.gradle.
build.gradle
Dockerfile.tmpl
In the next parts in this series, you will also see how you can overwrite these properties from docker-compose, Kubernetes configuration. By now, you should have noticed that we are setting ourselves up for externalizing configuration for running Hybris on the cloud.
Before we proceed with the creation of Docker images, one concept that needs to be introduced is "Aspects". Let's have a look.
Aspects
Hybris Docker image encapsulates all the platform functionality that you enable in extensionsinfo.xml. But when running the platform, do you need all the functionality? For instance, on backoffice node, would it be possible to disable storefronts? Would it be possible to run a platform instance that just runs a huge batch job and terminates after the job is finished? Would it be possible to run an instance that exposes web services in the form of OCC and not load any other applications? Aspects make all of the above scenarios possible. Benefit? The memory footprint of the running Hybris instance would be minimized by only enabling the applications that are absolutely needed. This is achieved by disabling web applications in local.properties. For example, if you want to run a backoffice node, the properties file from 'aspects/onlyBackoffice/hybris/conf/50-local.properties' inside the Docker image would be used. Below is the snippet from the backoffice aspect local.properties.
Apart from properties like db.url and so on, the file also contains a list of applications that are disabled with the format <extensionname>.webroot=<disabled>, this setting will tell tomcat not to enable those extensions.
One more advantage of aspects is, it allows us to launch different instances with different JVM memory settings. For example, the backoffice node can be configured with different memory settings than a storefront node.
With one image, multiple instances of the platform with different aspect configurations can be run at the same time.
Available aspects OOB are - default (which runs everything), onlyBackoffice, onlyHac, allWebApps, noneWebApps.
Creat custom aspect
A custom aspect can be created to suit your needs. In build.gradle file of the recipe, I have included a custom aspect named "onlyOCC" which only loads web application that has webroot '/rest', which is a web service webroot in Hybris. The format to configure webroot is {extensionname}.webroot. For more reading on this topic, refer to the section "Configuring Extension Web Paths in Aspects" on this page.
HSQLDB configuration
The HSQLDB image used in the recipe is part of the platform, for the sake of convenience, it is made available as part of the recipe to facilitate configuration of DB port, etc. You can use a DB (MySQL, etc.) of your choice.
Conclusion
In this article, we looked at the custom recipe, it's advantages and, introduction to aspects and their benefits.
In the next blog post, we look at the creation of the Docker image from the custom recipe.
About the Author
Ravi Avulapati – Specializes in Java, J2EE, and frameworks, SAP Commerce (Hybris), Search with Solr, Solution & Enterprise Architecture, Microservices, DevOps, Cloud solutions. Machine learning and deep learning enthusiast.
About Valtech
Valtech is a global full-service digital agency focussed on business transformation with offerings in strategy consulting, experience design & technology services. Valtech is an SAP partner and is an SAP recognized expert in SAP Commerce.
- SAP Managed Tags:
2 Comments
