Deployment area is set to N/A when starting service containers

[benq66]

Hi,

I've been recently experimenting with the Spotfire containers to get a simple local sandbox deployment using vanilla docker, to check how things work when it comes to containerized Spotfire deployment. I'm currently at the stage where one creates a service container (webplayer) and I encounter an issue with it. The container itself runs successfully, and is able to connect to the server, but the Node Manager and the service itself have "N/A (Externally Managed)" in the Deployment Area field. This in-turn restricts the available actions in the admin dashboard for this NM and its services, such as seeing the list of the installed packages and updating the packages, for example. According to the server logs the Node Manager, when it becomes trusted by the server, it switches to the default Deployment Area, but uses its id instead of the name. Here's the aforementioned lines from the server log:

[unknown, #-, #85036] web.controller.TrustController: Received a CSR with fingerprint 74a95a2901a2557e0d159e3c0913dafbcf3392a56737c18be3c8f289ac323d7e
[unknown, #-, #85036] web.controller.TrustController: Deployment area doesn't exist null, resetting to default 2d71f811-19f6-f4ac-c985-3da501193f54
[unknown, #-, #85036] data.service.PersistenceService: Adding [172.17.0.4, spotfire-node-manager] for node Node [serverId=dca5a7aa-8c59-474c-877d-707066fdeb16, serverName=172.17.0.4, port=9443, siteID=5c2c7b84-e1f4-4187-9799-85a2a48f0ebc]

And after these steps the Node Manager and the service are in the N/A deployment area and it's not possible to access any actions for them, such as updating the packages or revoking trust.

I've been looking into the image files and it seems like the Node Manager is configured to have the "externally managed" property set to true, and also to use a default.conf file with null in the deployment area field when the service is created (for example, in the Webplayer container). Could it have something to do with the issue above? Or is it an intended behavior that the NM and the services are not customizable via the admin dashboard when they are deployed in the containers? What does the property "externally managed" actually do, apart from locking the possibility to manage the NM and the services via the admin dashboard? (Couldn't find any documentation about it).

Thank you.

PS
I've tried binding a custom default.conf file with a "Production" value instead of null in the deployment area field, but it didn't change anything, the NM still reset to the deployment area id after receiving a trust answer from the server.

[shuraosipov]

Hey @benq66 , have you managed to find a solution? it looks like the issue is still there even in the latest version of CDK.

[shuraosipov]

Hello @bbassett-tibco, could you please advice here?

[benq66]

Hey @benq66 , have you managed to find a solution? it looks like the issue is still there even in the latest version of CDK.

Hey, @shuraosipov! Unfortunately, the issue was not resolved at the time. After further experimentation and investigation we've decided to keep using the traditional setup for our Spotfire environment, at least for now.

In regards to the issue itself, I think I was able to get a response from the devs when I contacted them about another topic, and the answer was something along the lines that this type of deployment is supposed to be orchestrated / monitored via CLI / other solutions, and the dashboard is not expected to be used for manual operations, so such issues are somewhat expected and are not considered as critical. However, the situation might've changed since then so let's see if the devs provide any updated info about this :)

[shuraosipov]

@benq66 , thanks.
I've found a workaround.

I updated the Docker image for the Spotfire Web Player and replaced the provided default.conf with the custom one in the line below:

spotfire-cloud-deployment-kit/containers/images/spotfire-webplayer/Dockerfile

Line 49 in 1b54a71

COPY --from=extract --chown=spotfire:spotfire /tmp/nodemanager-install/nm/config/default.conf /opt/spotfire/nodemanager/nm/config/default.conf

I also commented out everything inside this script .

After these changes, I see that packages from my custom deployment area are being installed for the new web player service. However, in the web UI, the deployment is still displayed as "externally managed".

[mblixter]

@benq66 , thanks. I've found a workaround.

I updated the Docker image for the Spotfire Web Player and replaced the provided default.conf with the custom one in the line below:

spotfire-cloud-deployment-kit/containers/images/spotfire-webplayer/Dockerfile

Line 49 in 1b54a71

COPY --from=extract --chown=spotfire:spotfire /tmp/nodemanager-install/nm/config/default.conf /opt/spotfire/nodemanager/nm/config/default.conf

I also commented out everything inside this script .

After these changes, I see that packages from my custom deployment area are being installed for the new web player service. However, in the web UI, the deployment is still displayed as "externally managed".

This described behavior of the service containers is not a defect, it is as designed. If you make any changes to a running containerized service via the Web Admin UI, or edit the file system itself by executing into the running container, then those changes will be lost when you restart the service container, as the container will reset the filesystem. This is how containers work, when they are restarted they start up again using the image they are based on and the filesystem from that image.
This is why it's not possible(by default) to update packages or handle anything else about the services when they are running in a container. I would not recommend making the suggested work around to allow you to manage the services via the Web Admin UI. As mentioned, any changes/updates or anything else will be lost when the container is restarted. Restarting a containerized service from the Web Admin UI(or from docker commands or anything else) will actually result in a new service being created and added to the Spotfire Server as the filesystem of the container has reset, the "new" service will have to send a trust request to the Spotfire Server and that results in a new service with a new UID.

If you want to update or add any packages to a service, you should follow the instructions in the README file of the desired service.

[shuraosipov]

Hi @mblixter, Thanks a lot for your response. I totally get how containerized services work and why you made that change. My point was just about finding a simpler way to assign a service to a deployment area and maybe showing which deployment area is being used in the UI. (You could still add an option to display "externally managed," but it would simplify administration.)

[mblixter]

Hi @mblixter, Thanks a lot for your response. I totally get how containerized services work and why you made that change. My point was just about finding a simpler way to assign a service to a deployment area and maybe showing which deployment area is being used in the UI. (You could still add an option to display "externally managed," but it would simplify administration.)

Hi @shuraosipov I understand your perspective, but since the service pods are using the packages build into the image, they are not managed from the Admin Web UI, and as such they are marked as "Externally Managed" and do not show any information about what deployment areas they are using, as they are not using any deployment area from the Spotfire server.
Imagine that you implement your workaround and you assign a service to the "Production" deployment area. You then update the area with the latest Service pack and then update the Web player service via the Web Admin UI buttons that you've made available. During the update of a Web player service the underlying processes will restart which will then cause the pod to restart, and when it starts up again, it'll be using the packages that where build into the image and not the packages from the Production area that you just tried to update from.
So even though you can "assign" services to deployment areas using your workaround, it will not work as you intend it to.