search

giis-uniovi / retorch-st-eShopContainers

RETORCH eShopContainers End-to-End Test Suite
Apache License 2.0
1 stars 0 forks source link

Migration to Docker Internal Network #13

Closed augustocristian closed 11 months ago

augustocristian commented 11 months ago

The application's networking has undergone changes to facilitate multiple parallel executions. The HOST addresses with their bound ports are currently in the process of being phased out and replaced with the inherent Docker addressing using container names. However, I've encountered issues related to address redirection and application persistence. This is due to the necessity of removing all volumes with each execution, as these addresses are stored in various database tables. Another issue revolves around URLs. The application distinguishes between http://IP:80 and http://ip/ (which should be automatically linked to port 80), causing several problems for us.

augustocristian commented 11 months ago

Due to the application's transition to Docker internal networks, it is encountering issues with cookies. This is a result of the URL format changing from IP:PORT1, IP:PORT2 to URLContainer1:80, URLContainer2:80. This is a well-known issue, as documented here: https://github.com/dotnet-architecture/eShopOnContainers/wiki/Frequent-errors. We are actively addressing this issue and working towards a resolution by implementing cookie handling with the SameSite experimental feature.

javiertuya commented 11 months ago

@augustocristian @ClaudiodelaRiva I don't clearly understand this issue. I assume that after the first revision of #6 (that is the priority), everything was working. The only thing in the 2nd review that involves network addressing is an IP address that is harcoded in the source code of a configuration file (and shouldn't).

You can always change this configuration file when the jenkinsfile starts, for instance, by copying an external file (that is placed in the host) to the workspace, or copying and exeucting a script that only touches part of the configuration file.

augustocristian commented 11 months ago

@javiertuya In reference to the discussion found here: https://github.com/giis-uniovi/retorch-st-eShopContainers/pull/6#discussion_r1401622591, the last option you suggested was to use Docker network addressing. This option allows us to deploy multiple instances, with the containers related to the TJob being named with "-tjoba," and their respective addresses being http://service1-tjoba, http://service2-tjob2, and so on. While this may seem straightforward, it has posed numerous challenges for me due to the implementation of microservices and some unnoticed mistakes.

Currently, my focus is on resolving the issue related to cookies arising from different origin names. Please refer to the image here: image. This problem likely stems from the original application being deployed over a single IP with various allocated ports for each service(but deployed in the same site). We are transitioning from this approach to using different containers that communicate over the Docker internal network and interact with the Selenoid browsers.

augustocristian commented 11 months ago

Pd: with this approach we are totally IP-agnostic with the microservices, they are deployed over the slave network and interconnected with their container names

javiertuya commented 11 months ago

@augustocristian Of course, using the container names is the best approach: a network where every application container runs, and the jenkins agent given access to this network to interact with the application containers. Other option was using environment variables (see latest review). A third option is the mentioned here https://github.com/giis-uniovi/retorch-st-eShopContainers/issues/13#issuecomment-1826819530.

But the priority is to finish #6. This PR is already too big and has been open for too long. If changing networking is going to introduce addtional issues it should not be done as part of #6. Further improvements can be left to another PR in the future.