Cloud-a Seeded graduate enables Researcher, Student, and Industry collaboration

QReserve, an Ontario based startup that provides an online database of research equipment, services and facilities to help researchers, students and industry connect and collaborate has recently graduated from Cloud-A’s Seeded program for startups. QReserve applied and was accepted into the Seeded program and as a result, received six months of free, unlimited infrastructure-as-a-service to help grow their business.

QReserve helps researchers, students and industry connect and collaborate by offering an online database of research equipment, services and facilities. Research labs can list their equipment and services in QReserve for free and the database is free to search by anybody, anywhere. To help universities and colleges participate as a whole, QReserve provides a student liaison service that hires, trains and manages local students who work with an institution’s researchers to help them get their lab onto QReserve. University administrators can then embed QReserve’s platform into their own website to make it easy for internal users to collaborate and for external industry and researchers to connect. QReserve has on-boarded several institutional customers such as McMaster University, Brock University and UBC Okanagan.

QReserve architected their application on Cloud-A where it still runs today. The Canadian resident, on-demand, API driven infrastructure-as-a-service that Cloud-A provides gives QReserve the agility to scale their infrastructure as they grow, and pay for it when they need it.

Having QReserve hosted in Canada is important to Canadian universities and colleges who trust us with their information. While looking for a Canadian cloud hosting company, Cloud-A appealed to us not only for their seeded program that helped considerably with cash flow early on but also for their personable and very fast support team. When an issue or question arose, I knew I had access to a real person who understood and cared about my business.

Brandon Aubie, CEO / Co-Founder, QReserve

For more information about Qreserve, please visit their website at https://www.qreserve.com or contact Brandon Aubie at brandon.aubie@qreserve.com.

QReserve in the news:

Feature in the Hamilton Spector (March 11, 2015)

Feature in University Affairs magazine (October 15, 2014)

Migrating from the Heroku PaaS to Cloud 66 & Cloud-A

cloud66

We come across clients all the time who have their applications built on Heroku, but have requirements from their clients to have their data resident in Canada. This was one of the drivers for creating the relationship we have with Cloud66. Here is a guide for migrating from Heroku to Cloud66 + Cloud-A.

About migrating from Heroku

Migrating your application from Heroku to Cloud 66 involves deploying your code, importing your data and redirecting your traffic to the new endpoint.

What server size do I need?

Using Heroku, you can choose between 1X (512 MB), 2X (1 GB) and PX (6 GB) server sizes. This makes it easy to calculate your server requirements, and we recommend that you use similar server resources when deploying your stack with Cloud 66. We also recommend that you have a separate server for your database in production environments.

Heroku-f7903473

Migrating

1. Code

Simply provide Cloud 66 the URL to your Git repository so that it can be analyzed. For more information, seeAccessing your Git repository.

2. Data

Once your code is deployed, it’s time to migrate your data across. The process differs for PostgreSQL and MySQL databases:

PostgreSQL

From your Heroku toolbelt, create a database backup URL by running heroku pgbackups:url. Next, visit your stack detail page and click the Import Heroku data link. Paste the URL provided by the toolbelt into the field, and click Import Heroku data.

MySQL

Start by dumping your existing database. Refer to the ClearDB documentation for common problems.

$ mysqldump -u [username] -p[password] [dbname] > backup.sql

Once you have a MySQL dump file, use the Cloud 66 toolbelt to upload the file to your stack database server. Remember to replace the fields below with your values.

$ cx upload -s "[stack_name]" [database_server_name] backup.sql /tmp/backup.sql

Next, use the toolbelt to SSH to your server.

$ cx ssh -s "[stack_name]" [server_first_name]

Finally, use the command below to import your backup into the database. You can find the generated username, password and database name by visting your stack detail page and clicking into your database server (eg. MySQL server).

$ mysql -u [generated_user_name] -p [generated_password] "[database_name]" < /tmp/backupfile.sql

3. Traffic

Once you’re ready to serve traffic from your Cloud 66 stack, you need to redirect your traffic to it. For more information, see Configure your DNS.

Useful pointers

Web server and Procfile

By default, Cloud 66 will deploy your stack with Phusion Passenger, but you can also choose acustom web server like Unicorn. You may have a web entry in your Procfile to do this on Heroku. Cloud 66 ignores this entry to avoid compatability issues.

To run a custom web server, we require a custom_web entry. It is important to set this before analyzing your stack, to avoid building the stack with Passenger.

You can also use the Procfile to define other background jobs.

Dyno recycling

Heroku restarts all dynos at 24 hours of uptime, which may conceal possible memory leaks in your application. When you migrate to Cloud 66, these will become noticeable because we don’t restart your workers (other than during a deployment), so the leak can grow to be bigger. A temporary solution is to re-create the Heroku restart behavior, for example with this script:

for OUTPUT in $(pgrep -f sidekiq); do kill -TERM $OUTPUT; done

This will send a TERM signal to any Sidekiq workers, giving them 10 seconds (by default) to finish gracefully. Any workers that don’t finish within this time period are forcefully terminated and their messages are sent back to Redis for future processing. You can customize this script to fit your needs, and add it to your stack as a shell add-in.

Note that this is a temporary solution, and we recommend that you use a server monitoring solution to identify the source of your leak.

Asset Pipeline Compilation

If you haven’t compiled assets locally, Heroku will attempt to run the assets:precompile task during slug compilation. Cloud 66 allows you to specify whether or not to run this during deployment.

Making your App Canadian Data Resident

Probably the simplest step in the whole process is ensuring that your application is Canadian data resident. You will need to create an account with Cloud-A. Then when you set up your stack on Cloud66 ensure that you select Cloud-A as your cloud provider of choice.

Ready to give it a try?

Get started with a $10 credit

Create my account!

Linux security best practices for running your server in the cloud

At Cloud-A we enable our users to signup and manage their own infrastructure, giving them full control to configure and secure their own instances, networks and storage as they wish. We like to provide tips, tricks and best practises to give you the information you need to ensure that your instances are secure. Here are a few best practises for hardening and securing your Linux instances on Cloud-A.

Eliminate Unneeded Service

  • Do not run any unneeded services such as FTP.
  • If you are running DNS, be sure to close it off from being an open resolver so that you do not become part of a DDoS attack.

Lock down SSH

  • Disable root login via SSH
  • Only allow specified IPs to connect via SSH
  • Only allow SSH Key based authentication  – Do not allow password authentication
  • Use an alternative SSH port

Use fail2ban

(http://www.fail2ban.org/wiki/index.php/Main_Page)

  • Use fail2ban to automatically add malicious IPs to the firewall drop rules.

Update packages on regular basis

  • Keep your packages up to date to avoid being susceptible to zero day attacks.

More Links:

http://www.tecmint.com/linux-server-hardening-security-tips/

http://cloudfaqs.wordpress.com/2013/09/14/20-linux-server-hardening-security-tips/

http://www.gtcomm.net/blog/securing-a-linux-server-hardening-ssh-security/

http://security.stackexchange.com/questions/18480/building-a-secure-server-with-centos