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 <[email protected]> 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 > [email protected] > http://lists.linuxcontainers.org/listinfo/lxc-users _______________________________________________ lxc-users mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-users
