[lxc-users] selenium

Sun Jun 4 15:35:44 UTC 2017

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