Some test text!
Web / Guides / Deploy to AWS
This guide will show you how to build a highly reliable auto scaling server backend that will automatically work with your WebViewer based application to display documents. This server backend is built through a CloudFormation template.
We also offer directions on running WebViewer Server on a single EC2 server.
This will be the easiest and quickest way to get going on Amazon. This guide will show you how to setup a single EC2 server and run the WebViewer Server container on it.
Log into the Amazon Web Services console and select the EC2 service. Select the EC2 Dashboard and click
Launch Instance. From here we will configure this EC2 server for launch.
Amazon Linux AMI for your server. Select
Choose Instance Type - select the instance you want. We recommend at minimum the
t2.medium instance. Select
Configure Security Group and hit
Add Rule. Set the type to
Review and Launch. In moments your server is will be online. The next step will setup and install Docker.
To perform the next steps you need to SSH into the EC2 Server, this can be done by getting its EC2 Public Key and finding its DNS public name, both which should be visible on the details of the server. Once you've found these, perform a SSH on t
he DNS public name. SSH can be done with a tool such as putty on windows and the ssh command on Linux.
sudo yum update -y sudo yum install -y docker sudo service docker start sudo usermod -aG docker ec2-user
docker run --name webviewer-server -p 80:8090 -e INCLUDE_DEMO='true' pdftron/webviewer-server:latest
If you choose to attach a load balancer to WebViewer Server there are some things to keep in mind.
The server uses both typical HTTP/HTTPS requests and Websockets. This means if you are using the classic load balancer you cannot use HTTP/HTTPS listeners and must instead use TCP/SSL listeners.
When load balancing between multiple servers you should keep this section of the guide in mind. If clients are not kept stickied to a server on first connection, there will be connection issues.
In this portion of the guide we go over using our CloudFormation template to launch an auto scaling server architecture for running WebViewer Server.
This auto-scaling server setup will provide a way to handle any incoming load by scaling servers out as required, and in as required. Prior to launching this template, you should already have an Amazon Web Services account that is able to use these features:
ACM and the
Elastic Container Service.
The steps for usage are as follows.
Download the template and
Create a New Stack on CloudFormation using this template.
The first page to appear will be for configuration. Most options available are in regards to customizing the scalability aspect of the WebViewer Server. Below are key notes about several configuration options.
Stack Name- All resources will be prefixed with the stack name. Required.
EC2Key- The private key the infrastructure resources will use. Required.
AvailabilityZone (1 & 2)- The zones your resources are run in, must be two seperate zones. Required.
Path- The path of your resources in AWS, should be ‘/’ unless there are special considerations. Required.
PDFNetKey- Your Apryse license. The server will continue to run in demo mode until an Apryse key is provided.
SSLServerCertificateARN- required to run the server with HTTPS, to setup a SSL Certificate on AWS we suggest using the Certificate Manager: https://docs.aws.amazon.com/acm/latest/userguide/acm-overview.html
ECSNotificationTopic- The ARN of a SNS notification topic. Notifications will be sent to the group given when the containers upscale and downscale.
... many more options are included which correspond to those defined in our config
Hit next. The next page is entirely optional and can be used to setup any custom alarms. Click next.
On this page, check the box titled
I acknowledge that AWS CloudFormation might create IAM Resources. Click
Create. In approximately 15 minutes your stack will be created and ready to go.
Once the stack creation has completed, you can select
Outputs in the dropdown menu on CloudFormation. This will show links to the resources created.
Now that your server has built you have a complete WebViewer backend for viewing documents. To target the server with your application you need to find the DNS name of the main load balancer. The load balancer will be prefixed with your stack name. It can be also found by:
Outputssection of your stack in CloudFormation.
Any certificates or domains you are using for the WebViewer Server should be tied to this DNS name. From here, you can use this DNS name in your WebViewer initializer as directed by the WebViewer Server guide .
A demo of the WebViewer Server’s capabilities can also be found at:
CloudFormation. Right click on your stack and select
CloudFormation. Right click on your stack and select
If your update becomes stuck during this update it means the CloudFormation changes were too complex for CloudFormation to handle. In this situation we recommend creating a new stack with the new template.
All logs for the Apryse server will be placed under a single log group in CloudWatch. This log group can be found in the Outputs of your stack under PDFTronCloudWatchGroup. The log group name will be prefixed with your stack name.
Contained within the group will be 2 types of log, one for each container. The logs within the group represent each ECS cluster and are as follows:
As of version 1.1.0 of the template we now offer built in notification alarms regarding container upscaling and downscaling activity. We offer an option within the settings for placing your SNS group for notifications on AWS.
WebViewer Server does not come with built in alarms to notify users on server state changes. These can be user added. Below are some key metrics that could be used for your alarms and notifications:
true. Continue through the configuration till you have successfully updated the server.
SSHServerSG. Find its public IP and use this to SSH, along with the
EC2Keyyou specified during configuration.
EC2Keyfile to this server through SSH.
While using SSH on this server, you will be able to access any private IP address used by your WebViewer Server stack using your EC2Key and SSH.
In our documentation we have several arguments here . These arguments can be set in the template as well by modifying the
Environment variable. Some variables are set in the template by default. Do not alter existing options under this
Environment variable, they are either required in their state or controlled by the options available at the start of the template load.
There are a handful of known issues:
Updating an existing stack after changing
AWS::ECS::Service configuration in the template may cause failure on update as well as long delays before this failure notification.
Deleting the stack results in failure occasionally.
When deploying the server, the CloudFormation template is used as a blueprint for AWS infrastructure. It builds this infrastructure and pulls in our WebViewer Server Docker image. These images are pulled directly from DockerHub.
The diagram below shows how the
CloudFormation auto scaling server setup is designed
Elastic Container Service is the backbone of the system. It manages 2 types of container:
Elastic Container Service, in tandem with the auto scaling groups control container and server instance scalability. A series of Lambda functions manage performance measures, alarms and network mapping for these containers. This ensures high availability for the server.
At the front of everything sits an
AWS Classic Load Balancer. The internal network is private and heavily restricted to ensure security. As a result, the AWS Classic Load Balancer is the only public facing part of the system and gives access to the main functionality required for application development with WebViewer.
Some customers may choose to construct their own architecture on Amazon when using WebViewer Server. This part of the guide will detail things you will need to know when doing so.
WebViewer Server must have some sort of stickiness mechanism for client connections. We achieve this by using a cookie with HAProxy and running a Lambda which acts as service discovery for all WebViewer Server instances in our auto-scaling template. This Lambda directly notifies our HAProxy instances through TCP management of available instances.
Load Balancers on Amazon can cause issues when run with WebViewer Server. This is due to our usage of websockets and the fact that the Classic load balancer does not actually support websockets on the HTTP layer. You can get around this by accepting incoming connections on SSL and redirecting them to the server through TCP or SSL.
Ensure proper idle timeouts on load balancers. If the timeouts of the balancers are too short (less than 60 seconds), inactivity could result in abruptly terminated interactions for clients.
The network balancer provides the highest level of performance when load balancing, but is difficult to implement with WebViewer Server.
The load balancer can use WebViewer Server's health check mechanism to determine if instances are working properly
Get the answers you need: Chat with us