Docker with ID-based Licenses

[tomasbocinec]

Hello,

Is it possible to run readyapi functional tests using the headless  Readyapi runner in Docker ?

I tried to create a new docker image, but it recognized the test runner run  in the container and tried to apply the old type of license.

[richie]

Hey @tomasbocinec,

Could you clarify whst you mean by ID based licenses?

ReadyAPI supports 2 different licensing options.

1. Fixed term, per machine, per user
2. Floating licenses

Youll need the floater option for docker containers as its a non-persistent environment.

If you could just explain a bit more i'm sure someone will be able to answer

Cheers,

Rich

[tomasbocinec · Accepted solution]

Hi,

I meant this license https://support.smartbear.com/readyapi/docs/general-info/licensing/id-based/index.html

There are two types of float licenses: "file based" and "ID-based". I am currently working with "ID-based".

In the latest version of docker container https: //hub.docker.com/r/smartbear/ready-api-soapui-testrunner/ which is released today ,there is a change in the EntryPoint.sh script that will allow you to work with this new license. However, the application itself in the docker continues to report the problem after launch.

I did a workeround in which I forbade the application to look in the  linux folder "/proc" ,  thanks to which the application does not know that it runs in docker and everything finally works.

[TanyaYatskovska]

Hi @tomasbocinec,

I suggest that you contact the Support team regarding the licensing questions. You can reach out them here:

https://support.smartbear.com/readyapi

[threehook]

Hi @tomasbocinec,

I am also working with the ID-based license and this works fine if I run the ReadyAPI testrunner from regular Linux. But if I use the docker image (smartbear/ready-api-soapui-testrunner) then it fails.
Can you explain your workaround to get the application work with this new license?
You mentioned that you forbid the application to look in linux folder "/proc".
Can you please explain how you did that?
Maybe this will help me too.

regards,

@threehook

[tomasbocinec]

Hi @threehook 

My workeround was lock "/proc".  Thanks to this, the application could not detect that it is running in docker.

This can be done, for example, by using this command that runs before  entrypoint, for example in a before script in a pipeline
mount -o remount, rw, nosuid, nodev, noexec, relatime, hidepid = 2 / proc

I've dealt with it this way in the past, maybe it's solved in the new version without a workeround.

[threehook]

Hey @tomasbocinec,

Thanks for sending the workaround.

Unfortunately it does not work yet.
I used the solution into a before-script of my gitlab-ci job/pipeline and it does not give an error on your line.
Maybe it's just a matter of tweaking it a little bit. I will try to figure it out cause I think you pointed me to the right direction.
I will leave a message here when I succeed.

Thanks again,

@threehook

[tomasbocinec]

Hi @threehook 

I also used gitlab pipeline, here is my unprofessional solution for a demonstration,