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 <[email protected]> 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 <[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
