pegasystems / pega-helm-charts

Orchestrate a Pega Platform™ deployment by using Docker, Kubernetes, and Helm to take advantage of Pega Platform Cloud Choice flexibility.
https://community.pega.com/knowledgebase/articles/cloud-choice
Apache License 2.0
125 stars 200 forks source link

Specifying additonal web.xml snippet #577

Open maracle6 opened 1 year ago

maracle6 commented 1 year ago

Is your feature request related to a problem? Please describe. To configure a JMS Listener, we need to add tags to web.xml. Currently we have to pass in the entire web.xml in custom.webXML in our values.yaml. The web.xml is over 1600 lines, needs to be added to each tier, and to be safe we need to update it on every release since there could be some change to the one in prweb.war.

We need a way to pass in the web.xml updates more easily.

Describe the solution you'd like For our use case, where we simply need to add a snippet inside the tag of web.xml, I'd like to be able to supply a parameter custom.env.WEB_XML_SNIPPET, which would then be inserted into the web.xml by the docker entrypoint script. This would pair with the custom.env.CONTEXT_XML_SNIPPET that already exists (see https://github.com/pegasystems/pega-helm-charts/issues/121).

Describe alternatives you've considered The Helm chart allows for a web.xml to be placed in the deploy/config directory of the chart, but this then means that the chart is specific to a particular application and isn't generic for use with any values.yaml.

The existing custom.webXML capability to pass in the entire file could be more convenient if it supported an external secret. That way, you wouldn't need to embed the 1600 line web.xml in your values.yaml. However if there's any update to the OOTB web.xml in a patch or new minor release we would need to identify the change and update our secret properly. This at best adds additional work to every update, and at worst could lead to use of an incorrect web.xml. For use cases where we're only adding to the web.xml it's preferable to insert a snippet at runtime.

We also considered whether specifying specific changes to context.xml and web.xml makes sense for end users that just want to implement JMS. Currently we need to have some understanding of the internals of Pega's docker image. Maybe there could be a more abstract way to describe JMS resources and references, and the Helm code determines how to turn those elements into changes to the appropriate config files in the runtime image. We don't know if it's feasible to do this in an abstract way and still support all possible JMS integrations.

kishorv10 commented 5 months ago

US-613462 (internal)

PEGA-NarasimhaRao-Meda commented 5 months ago

@maracle6

Can you please elaborate on the need for adding JMS resources in web.xml? Since web.xml resource does not go through many changes unlike context xml which goes through significant changes every release, we have not provided template version of web.xml and expect the user to mount the necessary changes/configurations as part of file. And also are you referring to https://github.com/pegasystems/pega-helm-charts/blob/master/charts/pega/config/deploy/tomcat-web.xml or web.xml from prweb archive?

Based on our analysis we recommend you to mount web.xml from deploy/config folder.

maracle6 commented 4 months ago

Can you please elaborate on the need for adding JMS resources in web.xml? Since web.xml resource does not go through many changes unlike context xml which goes through significant changes every release, we have not provided template version of web.xml and expect the user to mount the necessary changes/configurations as part of file. And also are you referring to https://github.com/pegasystems/pega-helm-charts/blob/master/charts/pega/config/deploy/tomcat-web.xml or web.xml from prweb archive?

@PEGA-NarasimhaRao-Meda I'm referring to the web.xml in the prweb archive. If we use the deploy/config folder, then we're unable to use the chart from a remote repo and have to rely on local copies. This has a risk factor since each user of the charts needs to maintain their own copy of the distribution, and could easily lead to using an outdated version of the chart. The bigger problem is that every patch release someone should be analyzing the web.xml to see if the one being used in the deploy/config folder needs to be updated. Even if changes are infrequent, there's no way to know without checking.

My suggestion is to support this in the docker image (no change to Helm charts needed) with this update to docker-entrypoint.sh:

#
# Copying mounted web.xml file to conf
#
if [ -e "${web_xml}" ]; then
  echo "Loading web.xml from ${web_xml}...";
  cp "${web_xml}" "${PEGA_DEPLOYMENT_DIR}/WEB-INF/"
else
  echo "No web.xml was specified in ${web_xml}. Using defaults."
fi

#
# Adding snippet to web.xml
#
if [ -n "$WEB_XML_SNIPPET" ]; then
  echo "Inserting WEB_XML_SNIPPET into web.xml";
  awk -v var="$WEB_XML_SNIPPET" '/<\/web-app>/ {print var;} 1' ${PEGA_DEPLOYMENT_DIR}/WEB-INF/web.xml > /tmp/web.xml && mv /tmp/web.xml ${PEGA_DEPLOYMENT_DIR}/WEB-INF/web.xml
fi

The "adding snippet to web.xml" section is new and would simply add the contents of WEB_XML_SNIPPET, if that has been defined in the values file, at the end of the web.xml inside the closing tag. Users would define WEB_XML_SNIPPET in their values file the same way they can currently define CONTEXT_XML_SNIPPET. It would support uses cases including: