ContainerShip Blog

c2c — Docker Compose to ContainerShip Converter

 

When you are just starting out with Docker, you will spend some time reading through the documentation, getting familiar with the steps needed to containerize your app.

Topics: Docker DevOps Web Development

Parse on ContainerShip

As you have undoubtedly heard, on January 28th Facebook announced it was shutting down Parse, a hosted backend for applications. While Facebook was kind enough to give a full years notice, developers were left scrambling for a replacement. Coincidentally, Parse had scheduled to release an open-source replacement the same day, known as parse-server. As of now, theparse-server project is fully compliant with the Parse API, lacking only push delivery features (which they are open to building with the help of the community [update: parse-server now supports push notifications!]). Since at ContainerShip we strive to make developers’ lives easier, we thought a one-click installation of parse-server would be pretty neat. So if you’re looking for a Parse replacement, or are just interested in how to get it set up on ContainerShip, keep reading for available options.


Option 1: From the Marketplace

The easiest way to stand up parse-server is through the ContainerShip marketplace. From a single instance IDE to a distributed database, our marketplace allows users to launch a stack of software onto any hosting provider they connect, with a single click. In this case, when you navigate to our marketplace, and select Parse Server, you will be prompted to review the settings for two applications: parse-server, and parse-mongodb.

 

This stack will launch one instance of parse-server, and a mongodb database onto the selected cluster, automatically configuring parse-server to utilize the mongodb that was launched.When configuring the stack, you can change the default amount of CPU and memory which is allocated to each container for the application. If you choose to run with thedefault resource specs, you will need a server with at least 4GB of RAM.

Once you have finished modifying the resource requirements, you will be prompted to enter two important environment variables required to configure your parse-server installation:

PARSE_SERVER_MASTER_KEY
PARSE_SERVER_APPLICATION_ID
 

 

The placeholder text provides a short description of each required environment variable, but for further explanation, be sure to check out the official repository wiki. Once you’ve configured parse-server to your liking, you can launch both applications onto your cluster by clicking the “Launch” button. When you are redirected back to the cluster’s applications page, you should see your two new applications starting up.

Since the parse-server application automatically launches a loadbalancer on port 80, you will also see the containership-loadbalancer application starting. The creation of this loadbalancer makes your parse-server instance available on the automatically generated DNS address, which is found in the application’s configuration tab (it will look similar to: parse-server.50df23484220cf3db4b03eb30e119d9e.dns.cship.co). It will likely take you longer to read this section than it will to get your parse-server running, and thats a good thing :)

 

Option 2: From the Wizard

If you’d like to customize your installation of parse-server a bit more than our marketplace stack does out-of-the-box, creation through the wizard is for you! Once you reach the “Create Application” modal by clicking “From Wizard” on your cluster applications page, you can begin configuring your parse-server application. You will need to enter a few key pieces of information:

  • Application name (self-explanatory)
  • Docker image (we use containership/parse-server:2.0.7)
  • CPU and memory requirements.

While we have not thoroughly analyzed parse-server, we have assigned it 0.25 CPU shares and 512MB RAM respectively; adjust these values how you see fit.

Once you click “Create”, it’s time to add some environment variables! You will need a minimum of 3 environment variables to get parse-server to run successfully:

PARSE_SERVER_MASTER_KEY
PARSE_SERVER_APPLICATION_ID
PARSE_SERVER_DATABASE_URI

You may notice that the last environment listed here did not need to be configured in the marketplace installation guide. That’s because ContainerShip automatically set the PARSE_SERVER_DATABASE_URI environment variable to the url of the mongodb database launched along with parse-server.

Since you may be BYOM (bringing your own Mongo), feel free to set this URI to wherever your database is hosted. Check out MongoLab for a hosted solution, or the MongoDB marketplace item in ContainerShip Cloud. Once the required environment variables are set, you can optionally configure the remaining available variables found in the documentation. When you’re ready, go ahead and scale your parse-server application up to at least 1 container, and take a deep breath: you’ve replaced hosted Parse.

To access your parse-server application, visit the automatically generated DNS entry on the randomly allocated discovery port (it will look similar to:parse-server.50df23484220cf3db4b03eb30e119d9e.dns.cship.co:11932). If you’d like the application to respond on another port, simply create a loadbalancer!


Hopefully you’ve found this guide helpful in getting a self-hosted Parse replacement set up. If you don’t already have a ContainerShip Cloud account, sign up to get started. If you found this article helpful, be sure to recommend it to others, and leave an feedback in the comments!

 
Topics: Containership Parse Open Source Marketplace

What’s all this talk about Cloud/Container Native & Cloud First and how does it relate to DevOps?

In the last two years I’ve noticed a lot of posts, webinars, and meetup groupsdedicated to talking about building software that is “Cloud/Container Native” and I think it’s great that more focus is being put on the topic. With containers and orchestration being all the rage, it’s important to discuss the developer side of the DevOps contract, and how to build software that will function properly in a more automated world. That is what building cloud native software is all about. Taking steps during development to ensure that applications are being architected in a way that will enable things like logging, metrics, scaling, and more to snap in to place. It’s exciting that as an industry and a craft, we are moving in a direction that makes life easier for everyone involved, but it was not always like this, and we still have a long way to go before every team can reach DevOps nirvana.

Topics: Cloud Computing DevOps Hosting Web Development