[lxc-users] selenium

Sun Jun 4 15:37:14 UTC 2017

Sorry, I forgot to include the link for setting up Xorg with GPU
acceleration on LXD:
https://discuss.linuxcontainers.org/t/howto-how-to-run-graphics-accelerated-gui-apps-in-lxd-containers-on-your-ubuntu-desktop/94

On Sun, Jun 4, 2017 at 11:35 AM, Sean McNamara <smcnam at gmail.com> wrote:
> Firefox is one of those web browsers that conventionally requires an X
> server to be running for it to execute. This might tempt you to want
> to start up a *physical* Xorg server backed by real graphics hardware,
> but that's very wasteful of resources, unless you want to look at /
> interact with the Firefox instances "live" on the console monitor of
> the computer running these Firefox instances.
>
> If you *do* want to pass enough GPU hardware into the LXD containers
> that you could run a proper desktop environment in a container, with
> access to the GPU, you can start with this guide:
>
> Otherwise, you have plenty of options that do not require any special
> hardware access, and will run on default unprivileged LXD instances
> without any customization from the LXD side.
>
> The two general approaches are:
>
> (1) Run a *headless* web browser, meaning, a web browser that does not
> require an X server. These browsers' visual rendering output is
> generally only available using Selenium's "take screenshot" command.
> You can't view it live.
>
> -or-
>
> (2) Run a *virtual* X server that isn't backed by any hardware, just
> system memory -- like Xvfb, Xvnc, or Xrdp. Once you're running Xvfb or
> another virtual X server, and set the DISPLAY environment variable to
> match the display the Xvfb instance is running under, any web browser
> that normally requires an X server, like Chrome or Firefox, will work,
> and they'll render their windows in software to the virtual X server.
> With this setup, you have the option to be able to view the X server's
> display head "live" by connecting to it through a supported remote
> desktop protocol. For example, Xvnc would allow you to connect to the
> X server over VNC. You might also be able to set up a separate VNC or
> RDP server that lets you connect to an Xvfb instance.
>
>
> As far as performance, headless web browsers can do many optimizations
> -- like lazy rendering, where it only renders if you request a
> screenshot -- to save CPU cycles when performing Selenium tests. You
> don't have to worry about GPU requirements though; most webpages can
> still be rendered efficiently purely on the CPU with no hardware
> acceleration. The notable exception would be if any of the sites you
> visit with Selenium need WebGL or WebCL APIs.
>
>
> To learn more about the headless approach, here are a few options you
> can explore, in order from newest / most experimental to oldest / most
> bitrotten:
>
> (a) Headless Chrom(ium,e) and Headless Firefox are now a thing, at
> least in their alpha builds. Eventually the code for headless
> Chromium/Firefox with Selenium support will make it to a stable
> release of Firefox and Chrome. You can either wait until that happens,
> or grab a pre-release build today and try it out.
>
> http://www.cnx-software.com/2017/04/13/headless-mode-to-be-supported-in-chrome-and-firefox-browsers/
>
> (2) Use jBrowserDriver, which has the advantage that it's very CPU
> efficient, but the disadvantage that it uses a version of WebKit
> embedded within the Java runtime. So the recentness of its JavaScript
> APIs and HTML5 feature availability will depend on the version of Java
> you use. The latest stable Java 8 from Oracle still uses a WebKit
> that's about a year and a half behind the latest Chrome/Firefox in web
> standards support. Fortunately jBrowserDriver is being actively
> maintained.
>
> https://github.com/MachinePublishers/jBrowserDriver
>
> (3) Use PhantomJS, which is also CPU efficient, doesn't depend on
> Java, but is basically unmaintained now -- its prior maintainers have
> moved on, so don't count on major new fixes and features to be
> released any time soon, if ever. PhantomJS is also based on WebKit,
> but from Qt -- and a rather outdated version of it at this point --
> from around 2014. PhantomJS hasn't seen any code changes since
> February, which is a good sign that the project is now entering its
> abandonware phase.
>
>
> Neither PhantomJS nor jBrowserDriver uses Chromium's V8 for
> high-performance JavaScript, either, so they're significantly less CPU
> efficient when it comes to churning through lots of JS code. They use
> upstream WebKit's "JSCore", which isn't great. It's barely serviceable
> and kind of (but not entirely) up to modern web standards.
>
>
> If nothing in the headless category meets your needs (yet?), you can
> always use any X-backed web browser with a virtual X server, as
> mentioned. This is the more conventional way to do it, and comes at a
> modest performance cost (that adds up if you use lots of instances),
> but works fine for small to moderate sized workloads.
>
> http://elementalselenium.com/tips/38-headless
>
>
> If your question was rather how to manage running instances of Firefox
> across many LXD containers while connecting to / managing them from a
> centralized driver process, you could definitely use Selenium Grid for
> that -- set up a single central Selenium Grid Hub somewhere, then set
> up a Node on each LXD container, and have them all connect to the Hub.
> Then, when you use RemoteWebDriver to connect to the hub, you'll be
> able to get instances from all the LXD nodes.
>
> http://www.seleniumhq.org/docs/07_selenium_grid.jsp
>
>
> Hope that helps,
>
> Sean
>
>
> On Sun, Jun 4, 2017 at 11:03 AM, Diederik de Boer <ddeboer at educator.eu> wrote:
>> Hi all,
>>
>> I would like to run alot of selenium tests in multiple lxd containers.
>> what is the best way to let selenium run firefox in a container ?
>>
>> Regards,
>>
>> Diederik
>>
>> _______________________________________________
>> lxc-users mailing list
>> lxc-users at lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users