This article was originally posted by Fabio Akita who is a Ruby evangelist and entrepreneur in Brazil.
If you attended RubyConf Brazil in 2014, you must have seen the Jelastic Cloud presentation from Locaweb (a hosting provider), that was launching its Ruby support as beta, at that time.
As there are some tricks, which need mentioning, I decided to publish a brief post in order to share the possibilities of Jelastic. Unlike VPS or similar solutions, Jelastic is a Platform as a Service (PaaS), offering both horizontal (more servers under a load balancer) and vertical scalability (more resources like faster memory and CPU on the same machine). It also pre-sets almost everything, so you do not have to deal with such stuff like setting NGINX as a reverse proxy for load balance, or configuring PostgreSQL.
Trial account creation is very easy, you get your password by email and can enter the dashboard. From there just set the topology of your application – you have an option to choose the technology (Java , PHP, Ruby, Node.js , Python, .NET). With Ruby you can directly choose the Raptor Beta option. Then you can set up as many cloudlets as you want (as far as I understand 1 cloudlet is a processing unit that is 128 MB RAM and 200 MHz CPU and can enlarge vertically up to 64 cloudlets or 8GB and 12.80Ghz) per node. And horizontally, you can choose to have up to 18 nodes. In terms of price, you can go up to R$15 per month (note that it’s pay per use and the price is not fixed) to R$10,179 with maximum configurations.
An average configuration for most applications of small/medium size consists of 8 reserved cloudlets of 768Mb and 1.2GHZ, 2 nodes in balance with 256MB of Memcached, and 1.6Ghz 1Gb of PostgreSQL (always set your DB larger than your web machine) which costs about R$280 per month, or the equivalent of $96, which I found to be the competitive international alternative (yes, it is controversial, but taxes are taken into account).
You can deploy an environment directly from a Github repository or from zip file. After that, you can access any of your engines directly via SSH. This step is very important as it’s the only way to configure an environment (especially environment variables which are right for your settings). Make an SSH connection and create an .env file with your production data using the dotenv-rails gem.
One important thing : if using the default database configuration through config/database.yml, some problems may occur with PostgreSQL – it seems that there is a version conflict between the libpg in web nodes and the PostgreSQL on a separate node. To bypass this, set the the variable DATABASE_URL inside the .env file (which by default bypasses the database.yml and connects over TCP instead of Unix Sockets). The format of this variable must be like this:
DATABASE_URL: 'postgres://[user]:[password]@[host]:5432/[database name]'
While creating the PostgreSQL server you will also receive an email with a link to phpPGAdmin, a web interface for database configuration, you can go there and create a new user (do not set ‘webadmin’ user, of course). Another option is to access the database server through SSH and use common commands like createuser and createdb. Do not forget to add your SSH public key to the application settings tab, it is quite easy.
Automatic deployment will put your application files in the correct place and will run the installation process. After deployment is ready, you’ll need to get into the NGINX node through SSH in order to perform tasks such as rake db: migrate and rake assets: precompile. If you are using Memcache (with Rack::Cache, for example), you may need to use SSH to access the rails console, in order to reset the cache via Rails.cache.clear. In my case, even after the deployment had said Bundler was run, I still needed to get into the application directory and to run bundle install manually. It’s nothing major, but remember that. (Not a problem, but needs mentioning)
Note: When I’ve published the post that Jelastic (it seems that it uses the structure of OpenShift behind) supports a rake_deploy file, Kemel told me to just add post-deployment configurations that can be automatically executed, without entering SSH every time. See this documentation.
Finally, if you did everything right, from now on, you can access your application from the address [app name].jelasticlw.com. Then you can configure the application to accept a Custom Domain (one you registered) and its DNS service (either on Locaweb itself or services such as Zerigo, SimpleDNS) to set the CNAME and point it to the Jelastic address.
I didn’t have the chance to test all Jelastic configurations, especially such options as SSL adding and also Auto Scaling (horizontally), so that if your application exceeds certain CPU consumption thresholds and/or memory, it can automatically add or remove nodes (you set minimum and maximum numbers of nodes). So you don’t need to worry about accessing your site during unexpected spiking, and it will consume only the resources that are necessary.
Negative points, from a point of view of Ruby PaaS – unfortunately it does not have the concept of open buildpacks, there’s no way to configure a deployment pipeline properly to perform the Rake Tasks of Assets Precompile, Db: Migrate, etc. No support for Procfile to access the correct application server (I recommend using Raptor right away). The vertical scalability doesn’t help much – while increasing CPU capacity, we still need to use SSH to configure the number of worker processes, on Unicorn, for example. While I’ve been testing the platform, I tried to add the load balancer and it didn’t work. The last but important point: there is no support for workers (background jobs) with only web nodes available. Even if you need to run cronjobs, it will run in competition with your web processes, which has a negative effect on the web application response time. I haven’t analyzed this point yet (if anyone knows how, be sure to share this info in the comments).
Positive moments, the application was installed (Hurray!), I’ve faced some difficulties, as mentioned above, but the important thing is that in the end, it really worked. It’s too early to say something about behavior (it was my first test), but let’s see what happens in the future. Jelastic evolves continuously: the very first addition of the Raptor, considerably confirms it.
Jelastic is not for complete beginners, who want to install WordPress or Magento with one-click, like most shared web hosts do pre-configured. It is a deal for developers with some experience and who should not be held responsible for customer infrastructure. VPS setup is not difficult, but maintenance can be – especially if it is necessary to update machine resources, mainly when it becomes necessary to configure horizontal scaling and more advanced features like auto horizontal scalability.
Jelastic pricing is definitely higher than common shared hosting providers, but it is like comparing apples with bananas. Shared hosting providers are geared for small stuff, such as almost completely static sites, which do not require much processing activities. Anything that is larger than a small blog will suffer in a shared hosting environment. The next hosting options that Brazilian providers had available were Cloud Server (VPS) or directly bare metal hardware.
Jelastic is well on its way, and the direction that the company is moving can be a great approach worth exploring. The first deployment can be a bit painful until you learn what can be done, but after that, everything is less complicated and definitely the cost-benefit of maintaining an experienced system administrator full time on your payroll will make up for your developer spending a couple hours learning how to configure the platform.
In a world where it still “normal” to see people deploying via FTP (protip: GROSS!) and edit files directly in production, a product like Jelastic can help to educate for more correct concepts of deployment in production.
If you would like to test Ruby on Jelastic cloud, simply signup for a 2-week-free-trial and share your experience in the comments below.