This article will show the reader how to deploy UCRM on a cloud server in few simple steps.
Table of Contents
This tutorial will demonstrate how to deploy UCRM on a cloud server in few simple steps. This tutorial uses DigitalOcean with estimated costs from $10/month. The usage is charged hourly, so if used to test just for an hour, the user will only be charged $0.015.
Any other cloud server of the reader's choice may be used as well.
1. Create an account on DigitalOcean https://www.digitalocean.com/
2. Click Create a New Droplet
3. Choose Ubuntu 16.04.1 as the image.
4. Choose your plan. The $10/mo size is recommended. You can always change your plan in the future if you realize the server load is too high. You will be charged per hour, so you can try any plan for a while without any high costs.
5. Choose a datacenter close to your location.
6. Check "User data" in the Select additional options section.
7. Insert the following commands in the textbox shown in the image above.
- curl -fsSL https://raw.githubusercontent.com/U-CRM/billing/master/install.sh > /tmp/install.sh
- curl -fsSL https://raw.githubusercontent.com/U-CRM/billing/master/install-cloud.sh > /tmp/install-cloud.sh
- sudo bash /tmp/install-cloud.sh > /tmp/install-output
8. Optionally, you can add your SSH key. This will enable you to connect to the server without using a password. Otherwise, your root password will be sent to the email associated to your DigitalOcean account.
9. Click Create.
10. Get a coffee and wait for about 30 seconds for the server to startup, and then another 4-8 mins to download and deploy UCRM on the server. You should see this:
11. Then go to http://your_server_ip where "your_server_ip" is the IP of your Droplet.
Proceed to next steps just like you would in case of a local UCRM version.
1. Set up UCRM:
Create organization, set up mailer and app settings, etc.
Upload db backup including the encryption key from your existing local UCRM
2. Set up domain name. Follow this guide.
3. Set up ssl cert (mandatory when online payment gateways are used, such as PayPal, Stripe, etc.). Follow this guide to create your own cert.
To turn on https on UCRM server, follow our UCRM - Setting up SSL Certificate article. Note that in step 5 of that article, you need to connect to your Droplet server in order to restart it. Use this command to do so:
Where "your_server_ip" is the IP of your Droplet. Use the password in the email associated to your DigitalOcean account.
4. Mind your data. UCRM creates database backups regularly but those backups are stored on the same server. You may want to establish another precautions such as snapshots, external volumes etc. See more on the subject here.
Information about the Cloud Version and its Limitations
The UCRM version which can be deployed on a cloud is the very same version which you can download and run on your local server. There are some limitations regarding the UCRM usage on a cloud outside of your network. We are working on a fully supported UCRM cloud version, but for now please be advised about these limitations which are due to the fact that UCRM can not reach any device in your private network:
- No restrictions. You can set up IP of your Droplet server as the destination of the netflow packets. Automatic netflow setup will work only for a gateway router with public IP. If you want to turn netflow on for another router, you need to do so manually.
- The Suspension feature can work only when on a gateway router with public IP. List of suspended clients’ IPs will not be synchronized on any other device (router or CPE) because typically, these devices are in your private network and they are not accessible by UCRM cloud.
- The shaping feature can work only when on a gateway router with public IP. The reason is exactly the same as for the Suspension feature.
Device synchronization, outage notifications
- Again, these features will work only for a gateway router with public IP. These features are not available in UCRM cloud version for any other device of your private network.
HTTPS Support with Certificate on Load Balancer
When a SSL certificate is set up on the load balancer (e.g. AWS), HTTPS can be forced via FORCE_HTTPS and TRUSTED_PROXIES environment variables.
- TRUSTED_PROXIES must be configured properly when behind proxy, otherwise it will cause an infinite loop to happen.
- TRUSTED_PROXIES is only taken into account when FORCE_HTTPS is enabled.
Example of docker-compose.env with forced HTTPS:
In case the proxy IP is constantly changing, all proxies must be enabled. This can be done be setting TRUSTED_PROXIES to ALL:
In this case, the server must be configured to NOT respond to traffic from any clients other than the load balancer.
For AWS this can be done with security groups. Learn more.