We recommend running the Yarkon service in a standard “N+1” configuration, relying on horizontal scalability. To figure out the number “N”, you need to know the number of expected users. We recommend using t3.small instances with about one instance per 1,000 users. You can use fewer, larger instances.
For instance, if you expect to have 4,000 users, we recommend using 4+1=5 Yarkon instances to ensure high availability.
The standard Yarkon AMI allocates 8 GB of disk space, and it is sufficient for the normal operation of the server.
For the HA set up to work, all instances (servers) require access to a shared database.
Yarkon can work with any of the following widely available databases:
We run our environments on MySQL, so will describe that use case, but you can use any of the others with minor or no changes.
Our recommendation is to use AWS RDS for the database. It takes care of handling backups and recovery, and gives you high-availability for the database out of the box, as long as you use the “Multi-AZ” option. To save on cost, start with a small instance, and only increase it if you see that the performance of the database is degraded (use the AWS monitoring tools for that).
If you prefer to build your own database, you can definitely do so, but you then have to make sure to take care of backups and maintenance.
Once you have your database up and running, you need to create the schema for Yarkon. Together with our trial version, we provide an initial schema creation SQL script that you can use to prepare the database.
The script is located here:
/var/app/current/migrations/0.0.0.sql. Run it from the database command prompt when logged in as a user with
CREATE DATABASE permissions. By default, it names the Yarkon schema
aphek, but you can change that if you want.
Yarkon does not require its own database, it can share with any other application.
Lastly, you need to tell the Yarkon servers how to access the database. Assuming you are using the standard Yarkon AMI, you need to update the configuration file
/var/app/current/yarkon-server.pm2.json like so:
If you run your Yarkon servers using your own scripts, make sure to set up the
ENV variables in the same way.
Of course, update the placeholders to match your environment, and make sure the database user specified has
When done, restart the Yarkon service – when using the standard Yarkon AMI, you can do it from the command line using:
The Yarkon service must be set up within a VPC, to guarantee it is secure.
To ensure the service can handle local network issues, set up your instances in different availability zones. It is recommended to have the Yarkon servers in your internal network – preferably with no public IP but at the very least firewall-ed from the internet – for security.
Use a standard AWS load balancer for internet access. Either ELB (classic) or ALB would work. Per AWS best practice, this is a great opportunity to set up SSL termination (HTTPS) on the load balancer, allowing you to route HTTP traffic between the load balancer and your instances over your internal network. When setting up the security groups, have the Yarkon servers accessible from the load balancer only.