Organised by Liquid Studio Helsinki

1. CO-CREATION.
PROTOTYPING.
NEW TECHNOLOGIES.
WELCOME TO
LIQUID
STUDIO
AWS MEETUP 20.9.2018
Instagram: @liquidstudiohel
#liquidstudio

2. E2E TESTING WITH HEADLESS
CHROME RUNNING ON AWS ECS
ILKKA ANTTONEN, LS

3. ILKKA
ANTTONEN
“CHIEF TECHNOLOGY
SPORTING NERD.”
CTO. Responsible for all technological
aspects in the studio & how the
technology is delivered to customers. He
is passionate about combining softer
values and best interests of people with
technology
- what and why before how.
FUN FACT:
This geeky father of two got
his first computer (C64) when he was
only eight, back in the day.

4. Tests and screenshotting of web pages as part of
the CI/CD pipeline
• No excuses for developers
• Collect a history of screen shots
Separate tests from the browser instance
• Prefer remote, headless, installation of browser
• Avoid need to redeploy when tests change
• Browser version under control (although only Chromium)
Explore Fargate as runtime for containers
• Compare EC2 and Fargate as ECS runtimes
MOTIVATION AND
GOALS
Copyright © 2017 Accenture. All rights reserved. 4

5. Copyright © 2017 Accenture. All rights reserved. 5
OPTIONS FOR
HEADLESS BROWSER
NightmareJS
• Long-time favourite of community with
a clean and nice syntax
• Running a local instance is trivial
• For headless operation a custom
Docker image needs to be built with
multiple packages
• The custom container runs inside the
build machine with Docker in Docker
and is downloaded for every test
execution in the CI-cycle
Puppeteer +
Browserless
• Puppeteer is developed by the
Chromium team so it has excellent
support
• Browserless is both a container and
a service developed by Joel Griffith.
It supports for example debugging,
emojis and smart memory
management in the container
• Puppeteer can call the remote
browser through WS API
Chromeless
• Element evaluation needs more
custom Javascript
• Supports remote Lambda-based
installation(!)
• Lambda executions go through
Kinesis stream which can cause
unexpected costs depending on
test implementation
• Deprecated on July the 30th (in the
middle of my studies) in favour of
Puppeteer
+

6. Copyright © 2017 Accenture. All rights reserved. 6
OPTIONS FOR
CONTAINER RUNTIME
Fargate on ECS
• No servers to worry about (for some cost)
• AWSVPC is the only supported network type
• ‘Auto-assign public IP’ has to be selected or a NAT
gateway has to be defined for Fargate to be able to
fetch the image from external repository (like
Dockerhub)
• Internet access through Internet gateway works from
the box when the public IP is assigned
• The container SG must allow sufficient access from the
ALB (easiest is full access) so that keep-alive checks
and routing works correctly
EC2 on ECS
• Servers and agents need to be kept up-to-date
• Multiple networking types are available, but the supported
way to enable Internet access for containers is to use
AWSVPC with a NAT gateway attached to the VPC
(Internet gateway isn’t sufficient)
• Cost savings are possible especially if there’s anyway a
EC2 ECS instance running
• Scaling and monitoring the services isn’t trivial

7. Copyright © 2017 Accenture. All rights reserved. 7
IMPLEMENTED SOLUTION
Fargate VPC
Internet
gateway
Container SG
Application
Load Balancer
ALB SG
Limited connectivity from CI/CD. 80
Site to test
ECS
Fargate
Browserlesss
container
DockerHub
AWS cloud

8. Notes
• Ava as test running framework
• Ava uses Babel 7 natively which allows ES2017
• Remote endpoint set for Puppeteer
• At the moment Browserless requires the tested site to
use https (which is just fine)
• Screenshot is saved locally
• Simple test just checks that the page title matches
EXAMPLE CODE
Copyright © 2017 Accenture. All rights reserved. 8

9. DEMO AND
QUESTIONS
THANKS FOR
LISTENING!
(AND CHECK
BROWSERLESS.IO)