Issue with separate Deployment Controller server

Hello everyone,

As per the recommended infrastructure architecture by OutSytems, it is recommended to segregate the Deployment Controller (DC) in a separate server. As per my understanding, by this it means that the separate server should only act as DC and not as a Front End (FE) server. 

Now we already had two servers in our UAT environment, Server A and Server B, where Server A was acting as DC+FE and Server B was acting as FE which were having some older version of OutSytems 11. Multiple mobile and web applications applications were already running in the UAT environment. Now we have to separate out the DC to a separate server along with the platform upgrade to the latest version of OutSystems. To do this, we followed the below steps on a high-level:

  1. Disabled all the OutSystems services and IIS in Server A and Server B.
  2. Onboarded a brand new Server C and installed Platform server setup  by following the guide for fresh install of Deployment Controller only. So in this server only the Deployment Controller Service is running, all other services are turned off.
  3. Detached the license from Server A and attached it to Server C as per the guide.
  4. Upgraded the platform server version in Server A and attached it as a FE server.
  5. Upgraded the platform server version in Server B and attached it as a FE server.

Now we can find the below errors in Service Center Error logs:

  • No connection could be made because the target machine actively refused it Server C:12002  
  • No connection could be made because the target machine actively refused it Server C:12001  

Ports 12001 and 12002 are ports for deployment service and scheduler service. These are not accessible as these services are turned off in new DC server, which ideally should be turned off as per the platform server installation guide of OutSystems. And they are used only when the platform is trying to deploy the existing applications to this server.

Now my question is why does the platform try to deploy existing applications in the DC server as it is not a DC+FE server?

I have also observed that after onboarding the environment to Lifetime, even Lifetime tries to access the port 12001 of Server C which is the deployment service port and not deployment Controller port. The DC port is 12000. As a result of this lifetime is showing error "Trouble in reaching the environment"

Am I missing something?

Regards,

Shounak

mvp_badge
MVP

Hi Shounak,

As per the network requirements of the platform, for monitoring purposes both port 12001 and 12002 should be open from DC (source) to FE (destination).

Hope this helps.

Regards,

Nordin

Hi Nordin,

As per the network requirements that you provided above (highlighted), Controller should have access to the 12001 and 12002 ports  of Front-End which is already there in my case. The controller is successfully able to access the Front Ends and there are no issues regarding it. 

However, as per the network requirements that you provided, the reverse scenario is not necessary, i.e., it is not required for a Front End to have access to the deployment controller in 12001 and 12002 ports. 

But what is happening is the deployment controller is trying to deploy the application on itself and trying to access the 12001 and 12002 ports of its own. This should not happen if the server is configured only as a Controller and not as a Controller+FrontEnd. This is the exact issue that I am facing. 

Why should the Controller try to access its own 12001 and 12002 ports and trying to deploy the applications on it self?

Also why the lifetime should try to access the 12001 port of the Controller? 

regards,

Shounak

mvp_badge
MVP

Hi Shounak,

I thought the logged errors are from the FE, but as I understand now they are logged by the DC right?

That should not be the case you're right. From FE to DC only port 12000 needs to be open. Personally, I have not installed an environment with a dedicated DC yet, so I'm not sure what's going on here.

Did you make sure Server A is not acting as a DC anymore after installing Server C?

And can you share the complete error stack with us?

Regards,

Nordin

Hi Nordin,

Yes the errors are logged by the DC that is server C.

I am almost sure that the server A is not acting as a DC anymore as I properly followed the guide to onboard the servers. However, the fact can only be confirmed from the Environment health of the Service Center. But unfortunately, I am even unable to access the Environment Health page. it is getting timed out with exactly the same errors that I started above.

  The stack trace is given below:

Regards

Shounak

mvp_badge
MVP

Hi Shounak,

So I spoke to a colleague of mine Nicolay Moot who has faced the same scenario you're facing at one of our clients a while ago. The issue you're describing was similar to his.

They came up with the following solution in order to solve the issue:

  • You need to login to Service Center and go to Administration >> Servers screen
  • Open the detailscreen of the DC (Server C) in the list and disable it.

This was not the desired solution they were looking for at the time, but at least it solved the issue for them.

I would still recommend to open a support case with OutSystems and report this as it should not be the default behavior of the platfom.

Let us know how it goes.

Regards,

Nordin

That's a brilliant idea @Nordin Ahdi . Thanks buddy. I will definitely try this. Technically speaking, if I disable the server from the service center, it will stop acting as a front-end. But it will still keep working as a DC which it actually should. Why didn't this idea came to my mind (Grrrrrr!)?

Since our environments are banking environments and the same is not written in any official OutSystems documentation or guide, I had also raised a ticket with OS support. I'm waiting for their answer. 

If I don't get anything fruitful from them, then your idea will be my last resort. 

I will be waiting for the support reply before marking your reply as an answer.

Thanks and regards,

Shounak

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.