Affordable and Scalable Meteor deploys
I work at AYVÚ, a small startup located in Argentina, and we cannot afford Galaxy (yet!). So, we found a way to deploy, scale and configure our apps in a fully automated manner.
We’re currently using:
And we’re really excited to say these tools work great together!
Dockerizing our app
The first part of this tutorial is to dockerize our app. Thanks to MeteorHacks, this is a one-liner.
Add these lines to Dockerfile at the root of your project:
FROM meteorhacks/meteord:onbuild(If you want to read more about this, go check meteord)
Now, let’s build the machine. The first time we do this, it’s going to take some time, since we need to download all the data it needs to build our docker.
$ docker build .
Sending build context to Docker daemon 700 MB
[...]
Successfully built c43e6d9b207eTake note of that c43e6d9b207e! (replace it with your own ID). We’re going to need it later.
The funny part: Tutum
Let’s start for the basics: what is tutum?
Tutum describes itself as a platform for Docker orchestation. With Tutum, we can push our Docker project to Tutum’s cloud, create some servers at AWS/DigitalOcean/Azure, and distribute our app over them. Yes, we can make some clusters for our app!
You’re going to need an account at Soft Layer, Amazon AWS, Digital Ocean, Microsoft Azure or Packet from here on.
In the Tutum panel, click on your user, press “Account info”, and add credentials to any of these services. If you have your own (clean) VPS, you can also use that! Tutum let’s you bring your own hardware, but I’ll leave that task to you.
After adding a VPS Provider, go to Nodes
Now click on Launch New Node Cluster, and create as many machines as you want. We only need one for this tutorial.
Pushing our code
Okay, now we have our servers created, and ready for deploying an app there. Now, what?
Well, we need to push our code to our servers! If you created 50 servers, don’t worry. It only needs to be done once :)
Go to Repositories, in Tutum, and press Create new repository. Give it a name and press Create.
Then, it’ll tell you how to push your app there.
Replace $username with your username, $tag with the tag id we created before, and $appname with the name you gave to your repository.
$ docker tag $tag tutum.co/$username/$appname
$ docker push tutum.co/$username/$tag:latestThis is going to take some time, again, because it needs to upload several images to the cloud.
Creating a load balancer
Since our point is to have several VPS running our code, we need a load balancer to route our requests. It’s not as hard as it sounds.
Go to the tab services, and click Jumpstarts. Press on Proxies, and select haproxy.
We need to publish the ports 80. If you want to see some stats, you may want to also publish the port 1936, and if you need SSL, the port 443.
We can leave the rest as-is for now. Press the button Next: environment variables.
The only thing we need to do here is to add an API role, Full access.
Now, press Deploy, and…
And that’s it! We have our load balancer deployed.
Creating the service
Finally, we’re going to deploy our app!
Go to the tab services, and click Create Services. Press on the last tab, Private repositories, and select yours.
We need to publish the port 80 of our app, but let’s leave it as dynamic.
This generates a public url for our app, but with a random port. That way, we can have multiple apps running on different ports and our load balancer is going to take care of routing all the requests to the correct port.
In environment variables, we need to set several things.
If you use the email package, you may need to set a MAIL_URL variable.
I’m using Compose, so I also set MONGO_OPLOG_URL and MONGO_URL to the directions compose gives to me.
ROOT_URL is also need, so your app knows how to manage routes, and,
VIRTUAL_HOST. VIRTUAL_HOST is a special variable, in which you declare what URLs this app has.
You’ll have to set it to something like: VIRTUAL_HOST: app.com
If you need to make more crazy things, take a look at the docs.
And that’s it! You may need to add DISABLE_WEBSOCKETS and set it to 1 if you have problems with websockets.
Now we have a panel. Play a little with the numbers of containers, see how fast new dockers are being deployed.
One last thing for our app to be available publically: we need to let our loadbalancer know it needs to route this app.
Let’s go to Services, and go to your load balancer settings. Press edit, go to environment variables, and in Link Servicesadd your app. Save, and then press redeploy.
Configuring our DNS
We now need to route petitions from the http://ourawesomeapp.com to our load balancer. For that, we need to take note of the domain tutum gives us. Go to endpoints, inside your load balancer, and copy the address insideService endpoints.
You have to omit the http:// and the port. We only need the domain.
BRO TIP: If you have more than one node deployed in your cluster, and your load balancer is in both, you can dig(UNIX command) that address and see how even the load balancer is being balanced, at DNS level.
Now go to the panel of your DNS provider (i’m using CloudFlare) and make two CNAME. One for the root domain and another for www, so people can type http://www.ourawesomeapp.com.
Point both CNAMEs to the domain tutum gave us.
It’s a kinda magic!
Wait a little until the DNS are updated, and ta-da! We have our app deployed!
Now our app is being load-balanced against all the servers we configured.
If your app is under stress, just move the number of containers and your app will be distributed against other servers. Or add another node to your cluster! Or you can even play a little with the tags tutum provides, and make your app automatically deploy to all your machines tagged with mysuperproject.
It’s really easy, isn’t it?
