Launching osbot in docker container

[RawTech]

Hello, ( first post on the forums \o/ )

Long story short, I'm trying to run osbot in a docker container. When the jar is ran, the launcher starts a new process which is the bot client itself. This causes the container to exit since the original process stopped.

I can get around this by running with the -debug flag, which doesn't launch a new process, however this behaviour is not desirable (would rather not run with debug on). Additionally I'm fairly confident these 2 arguments aren't supposed to work together since I get an x server warning when both are passed (-script nointerface & -debug 5005 output at bottom of post)

 

Dockerfile:

FROM java:8

RUN mkdir -p /root/OSBot/Data
RUN mkdir -p /root/OSBot/Scripts

RUN wget https://osbot.org/mvc/get -O /root/OSBot/osbot.jar

COPY map.bin /root/OSBot/Data
COPY script.jar /root/OSBot/Scripts

ENTRYPOINT ["java", "-jar", "/root/OSBot/osbot.jar", "-allow", "nointerface,lowcpu", "-login", "REDACTED"]

 

Output when running:

[root@docker-standalone osbot]# docker run --rm osbot -bot REDACTED -script Script:1                                                                                                 
Starting OSBot with no interfaces, inherits lowresource
Starting OSBot in low cpu mode
Starting local script with name: Script
[DEBUG][11/14 06:00:39 PM]: Injected 2 field list filters
[DEBUG][11/14 06:00:39 PM]: Injected 2 field filters
[DEBUG][11/14 06:00:39 PM]: Injected 2 method list filters
[DEBUG][11/14 06:00:39 PM]: Injected 3 method filters
Starting OSBot in low resource mode
[root@docker-standalone osbot]#

As you can see it immediately exits once the client attempts to start.

Ideally I would not like to put in a hack to keep the original process running as I would like the container to exit cleanly once my script calls stop().

 

Bonus points if I can get a pointer to map.zip / map.bin on an osbot webserver somewhere such I can automatically fetch the latest in the Dockerfile.

 

Any help appreciated!

Cheers

 

 

Snippet when running -debug and -allow nointerface

Spoiler

[root@docker-standalone osbot]# docker run --rm osbot -bot REDACTED -script Script:1 -debug 5005
Starting OSBot with no interfaces, inherits lowresource
Starting OSBot in low cpu mode
Starting local script with name: Script
Debug enabled on port 5005
[DEBUG][11/14 06:08:12 PM]: Injected 2 field list filters
[DEBUG][11/14 06:08:12 PM]: Injected 2 field filters
[DEBUG][11/14 06:08:12 PM]: Injected 2 method list filters
[DEBUG][11/14 06:08:12 PM]: Injected 3 method filters
Starting OSBot in low resource mode
In debug mode!
Listening for transport dt_socket at address: 5005
Stealth injection class-filter enabled!
Successfully loaded OSBot!
[INFO][11/14 06:08:13 PM]: Welcome to OSBot 2.5.25!
[ERROR][11/14 06:08:13 PM]: Uncaught exception!
java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
        at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:204)
        at java.awt.Window.<init>(Window.java:536)
        at java.awt.Frame.<init>(Frame.java:420)
        at java.awt.Frame.<init>(Frame.java:385)
        at javax.swing.JFrame.<init>(JFrame.java:189)
        at org.osbot.BotApplication.IiIIIiiIIiII(kr:240)
        at org.osbot.uE.IiIIIiiIIiII(ay:186)
        at org.osbot.BotApplication.main(kr:198)

 

 

Edited November 14, 2018 by rawtech

[HunterRS]

Haven't tried this but might want to look into forking and then running the client.

Also out of curiosity, why do you want to run it inside a docker?

Edit:

As for the X server, I agree with your conclusion. Maybe something devs should look into as there is no reason X11 should be active when no interface is used.

Edited November 14, 2018 by HunterRS

[RawTech]

I considered forking, but I would like to avoid it if possible since it plays havoc with stdout and enabling docker to detect zombie/killed processes. But if it works, then it works.

And docker because I use it a lot at work and I appreciate the portability, can run it anywhere without leaving a mess on the file system etc. Plus it makes proxying easier if you have a docker "bot" network with a proxy or two for outbound traffic, gives me peace of mind that nothing can escape out of the systems native internet connection & potentially leak IP addresses.

 

I'll post something to the bug reports forum Re the x server.

[Ragnar Lothbrok]

## Custom Dockerfile
FROM consol/centos-xfce-vnc

USER 0

RUN sudo yum -y install java-1.8.0-openjdk-devel

COPY osbot.jar Desktop/osbot.jar

ADD OSBot /headless/OSBot
ADD out/artifacts/OakFarm_jar/OakFarm.jar /headless/OSBot/Scripts/OakFarm.jar

RUN chmod 777 Desktop/osbot.jar
RUN chmod 777 /headless/OSBot
RUN chmod 777 /headless/OSBot/Scripts
RUN chmod 777 /headless/OSBot/Data
RUN chmod 777 /headless/OSBot/Local
RUN chmod 777 /headless/OSBot/Data/client.jar
RUN chmod 777 /headless/OSBot/Data/filter_dda51e36.jar
RUN chmod 777 /headless/OSBot/Data/map.bin
RUN chmod 777 /headless/OSBot/Data/map.zip
RUN chmod 777 /headless/OSBot/Scripts/OakFarm.jar

USER 1000

CMD java -jar Desktop/osbot.jar -debug 5005 -login [your username]:[your password] -bot none:none:0000 -script OakFarm:$mule -allow norandoms,lowcpu,lowresource -proxy $proxy -world $world

Here's the dockerfile I used on my farm - this uses. If the bot crashes the container will restart as will the client.

EDIT:

Will also copy the webwalking links so you can start one first runtime

Edited November 14, 2018 by Ragnar Lothbrok

[HunterRS]

6 hours ago, Ragnar Lothbrok said:

## Custom Dockerfile
FROM consol/centos-xfce-vnc

USER 0

RUN sudo yum -y install java-1.8.0-openjdk-devel

COPY osbot.jar Desktop/osbot.jar

ADD OSBot /headless/OSBot
ADD out/artifacts/OakFarm_jar/OakFarm.jar /headless/OSBot/Scripts/OakFarm.jar

RUN chmod 777 Desktop/osbot.jar
RUN chmod 777 /headless/OSBot
RUN chmod 777 /headless/OSBot/Scripts
RUN chmod 777 /headless/OSBot/Data
RUN chmod 777 /headless/OSBot/Local
RUN chmod 777 /headless/OSBot/Data/client.jar
RUN chmod 777 /headless/OSBot/Data/filter_dda51e36.jar
RUN chmod 777 /headless/OSBot/Data/map.bin
RUN chmod 777 /headless/OSBot/Data/map.zip
RUN chmod 777 /headless/OSBot/Scripts/OakFarm.jar

USER 1000

CMD java -jar Desktop/osbot.jar -debug 5005 -login [your username]:[your password] -bot none:none:0000 -script OakFarm:$mule -allow norandoms,lowcpu,lowresource -proxy $proxy -world $world

Here's the dockerfile I used on my farm - this uses. If the bot crashes the container will restart as will the client.

EDIT:

Will also copy the webwalking links so you can start one first runtime

You are using a centos based docker and running the client on it. I do not think this is what he is looking for as it adds some overhead.

EDIT:

To clear up, I believe the Java docker has a stripped down Unix base more suitable for minimal Java use

Edited November 15, 2018 by HunterRS

[RawTech]

I've gone with the following solution for now..

Created a custom entrypoint script which I later intend to add support for environment variables to pass stuff in dynamically.

 

Dockerfile:

FROM java:8

RUN mkdir -p /root/OSBot/Data
RUN mkdir -p /root/OSBot/Scripts

RUN wget https://osbot.org/mvc/get -O /root/OSBot/osbot.jar

COPY map.bin /root/OSBot/Data
COPY script.jar /root/OSBot/Scripts
COPY entrypoint.sh /

ENTRYPOINT ["/entrypoint.sh"]

 

entrypoint.sh

https://pastebin.com/raw/nJ4qt3dz (Posted on pastebin as cloudflare thinks its malicious and wont let me submit)

 

It effectively forks by tailing the stdout (/prod/<pid>/fd/1) of the new java process, the only problem with this approach is that the logs aren't properly passed to the docker daemon and the kill commands are not handled gracefully, but it works.

 

This keeps the image size down to 700MB rather than 2GB that consol/centos-xfce-vnc uses.

If I ever find a more elegant solution I will be sure to update this thread.

 

Thanks for your input.

Edited November 15, 2018 by rawtech
typo

[BeepBooPvm]

Did you ever improve upon the container or is this still good enough for you?

[RawTech]

Not hugely. Some form of X server is required to launch the client heedlessly it seems.

I have changed the entry point to use debug mode to get around the tailing of the logs from the filesystem.