Apply Composite Template with a nostart or no restart

I have a situation with Webmethods 9.12 as follows:

  • I have product and fixpack installed in a docker image
  • I have a composite template to configure some of the COMMON-* attributes for the product
  • I run the sagcc apply for the composite template and it installs the layers then tries to start the runtime components. This hangs indefinitely and eventually times out because the build server I’m running the CC and product containers on is relatively isolated

The problem is: I do not want these products inside the container to start up yet. It’s a build server and not the place to startup runtime components. These containers will be tagged with what product and ENV they are configured for.

Is there an attribute in the template or a flag for sagcc that I can pass to exempt the product instance from starting after the template layers are applied?

The short answer is that it is not currently possible to control final state on the environment at the end of the template is applied. The template always performs restart at the very end and checks for components ONLINE status.

There is a couple of special use cases when this is not true:

  1. When provisioning is executed against the ‘local’ node there is no restart. This is likely not going to help in your case

  2. There is a system property that can be set on Command Central to suppress the restart, but it will affect ALL provisioning operations. This might be OK if this is CC instance is exclusively used by the build server.
    However, there will be many situations when products will be started during the template application because such products require being ONLINE to accept configuration requests. So, though restart will not be performed at the very end, the products will still be started.

It seems that you’re specifically working on Docker image builds.
Have you looked into this project?

It executes templates during the standard docker build driven by a Dockerfile and a template. The runtime will be started as needed, but it does not matter since it will be in a temp container created by the Docker engine.
This is the cleanest way to build Docker images on any Docker enabled host.


1 Like

Thanks for the feedback. Unfortunately my company wants 9.12 before going for the brand new 10 version

so I don’t think the 10.# docker way will work for us just yet

What is that CC property I can set? I’ll give that a try at least.

System property is this one:

You can set it via COMMON-SYSPROPS on CCE component and after that restart CCE.

Best Regards,

Hmm, I’m running the command central docker container though, so the restart kills off the docker container

Can it be passed in as an -e var on the docker run command?

Customizations should be done at the image build time, not at container runtime.

Please see how to customize command central image from DockerStore

As far as using CC Docker Builder with webMethods 9.12 - we’re planning to support that later this year, possibly in the spring months.