in our company we setup MSR 10.7 on openshift platform which is hosted on AWS
Any recommendations on how we can apply fixes to the MSR which is already running in production environment
our docker images are residing in github
@gatlavenkatajaswanth.reddy , how are you building Docker images for MSR? Please note that you will need to have new Docker image that contains required fixes. Please have a look @ Product Details (softwareag.com), wherein we publish new Docker images with latest fixes. You will need to use similar approach for the Docker images that you are creating for your envs.
Regards,
Kalpesh
2 Likes
To rephrase in a somewhat more blunt way, what @Kalpesh_Shah1 already explained: You never change things manually on an existing Docker image. That applies to the installation of fixes just like to changing Flow services or any configuration item.
If there is a problem with that, it almost always means that there is conceptual issue in how containerization is used.
1 Like
SoftwareAG provides prod ready tested containers at containers.softwareag.com. You can download the image and replace it if you are using the base image.
SoftwareAG also provides helm charts for MWS. If you are using helm charts to deploy your containers, you can just change the tag and upgrade it.
If you built your own containers and yaml files, then you need to install fixes on your on prem installation and create the image again.
Hi @engin_arlak yes we have a base image
is there any guide on how we can install fixes to that base image
Thanks @Kalpesh_Shah1 , we will check on this
@gatlavenkatajaswanth.reddy, as Kalpesh inquired, can you please elaborate on how you’re building your image?
The recommendation is to follow the approach outlined by @engin_arlak, meaning you don’t apply the fixes yourself. Instead, you rely on Software AG to release an already patched image to their container registry and you simply use the image from there.
Having said this, it appears that you’re on version 10.7 and I believe the earliest version currently avaiable on the Software AG container registry is 10.11, so unless you’re willing to upgrade to a later version, you may indeed be stuck patching the image yourself, which is why it’s important to understand how you’re generating the image. As Christoph elaborated, you shouldn’t patch the running container like you traditionally would a running Integration Server, for example. Instead, you need to create an already patched image and then deploy that like you did the previous one.
For what it’s worth, I too had to create a custom Docker image build process for webMethods products because my customer was also using an earlier version and because we wanted to Dockerize products that weren’t available as Docker images out of the box (e.g. Asset Build Environment). The approach I landed on was to create a “builder” image that contained the Software AG installer and Update Manager pre-installed along with a shell script that either installed products, fixes, or both based on arguments passed in at build-time. This “builder” image was then used in a Docker multi-stage build (
Multi-stage builds | Docker Docs)
HTH,
Percio
2 Likes
we too build custom docker images in our local and push it to git, i dont have indepth understanding on how it was done as we have recently taken ownership of the cloud platform and previously we worked on onpremise
the current base image we are using is nearly 2 years old
we are exploring different ways on how we can apply fixes
Ok. If you need help, let me know as I have a little bit of experience with this. The devil is in the details and I removed a lot of details below, but conceptually this is what I’m recommending at a high level:
- Create a Dockerfile to generate a Docker image that contains Software AG Update Manager pre-installed. For example, this Dockerfile command downloads the Update Manager bootstrapper and installs SUM in RedHat (9.2-minimal image):
# Download the Software AG Update Manager bootstrapper and install Update Manager
RUN curl -s -o /tmp/sum-installer.bin https://empowersdc.softwareag.com/ccinstallers/SoftwareAGUpdateManagerInstaller20230322-11-LinuxX86.bin \
&& chmod +x /tmp/sum-installer.bin \
&& microdnf install -y gzip tar \
&& /tmp/sum-installer.bin --accept-license -d /opt/softwareag-sum
- In this same Dockerfile, copy a shell script into the image that launches SUM to installs fixes from a given image file and a given SUM script. For example, a script named update.sh that executes a command like the one below:
/opt/softwareag-sum/bin/UpdateManagerCMD.sh -installFromImage /tmp/sum-image.zip -installDir /opt/softwareag -readScript /tmp/sum-script.txt
- Now, to install fixes for Software AG products inside an existing Docker image, you could create a Dockerfile that uses a multi-stage build as follows:
FROM your-wm-product-image AS base
FROM sum-image AS sum
# Copy the Software AG product files from base
COPY --from=base /opt/softwareag /opt/softwareag
# Copy the SUM script and image into the container
COPY ./sum-files/sum-image.zip /tmp
COPY ./sum-files/sum-script.txt /tmp
# Run the update script to install the fixes from the image based on the script
RUN /some/location/update.sh
# Copy the resulting product directory
FROM your-pristine-OS-image
COPY --chown=sagadmin:sagadmin --from=install /opt/softwareag /opt/softwareag
Like I said, the devil is in the details and there are multiple ways to skin this cat, but hopefully this gives you some direction.
Also, I hope you realize that you can apply this same concept for creating your Docker images from scratch, but rather than exectuing Update Manager, you’d execute the Software AG installer. In fact, in my current project, I have a single image called install that has both the installer and update manager. Inside that image, I have a single script called install.sh that takes care of first calling Installer and then calling Update Manager. I have gone back and forth on whether I like this approach better or having separate images for each but there is merit to both approaches.
HTH,
Percio
Thanks @Percio_Castro1 for your suggestion
we will check on your recommendation and explore this scenario
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.