Install Magento Cloud This quick start guide will show how to setup & configure Magento eCommerce Platform in less than 5 minutes!
What you will need before you get started :
There is a huge buzz around Docker these days, and we are huge fans of it at Cloud-A. Docker is an essential component of our Continuous Integration System and it also runs Cloud-A’s management plane. We get lots of questions from customers about how they can run their containers on Cloud-A. Here is a look at how you can use Cloud 66 DevOps-as-a-service to deploy, scale and product your doctor container on Cloud-A.
The cloud is still very new to most organizations to the point where it is still widely unknown. This is especially true when you see RFPs being requested for cloud infrastructure services with all sorts of inherent challenges and logical incongruence within them.
We partner with solution integrators specializing in cloud consulting & delivery so although we at Cloud A do not bid on RFP’s directly, we would of course be more than happy to partner with organizations looking to leverage true cloud solutions in Canada. Our partners have helped over 400 organizations achieve their strategic objectives by migrating to Cloud A over the past 15 months. As a result, together we have a deep understanding of the approach and cultural shift required to realize successful change in this new era of computing.
This article hopes to clarify some of the considerations and actions to take when preparing an RFP to maximize the potencial benefits cloud computing has to offer. The goal of this article is to make the RFP attractive to the leading cloud providers and solution integrators from whom you are seeking submissions. There are many factors that are different to your traditional hardware and application requests of the past. Simply, the cloud is a new realm in computing with a lot to know and there are many other folks out there repackaging old tech as “cloud” these days; that is something you need to be careful of. Read more
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.
Migrating your application from Heroku to Cloud 66 involves deploying your code, importing your data and redirecting your traffic to the new endpoint.
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.
Simply provide Cloud 66 the URL to your Git repository so that it can be analyzed. For more information, seeAccessing your Git repository.
Once your code is deployed, it’s time to migrate your data across. The process differs for PostgreSQL and MySQL databases:
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.
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
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.
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.
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.
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.
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.
We are happy to announce our partnership with Cloud 66, a leading provider of Devops-as-a-service, giving you everything you need to deploy, scale and protect your applications on Cloud-A in a single tool.
This partnership allows Cloud-A users to deploy and manage their applications more efficiently than ever before, offering one click, automated functionality for managing the lifecycle of your entire stack on Cloud-A which allows developers to do what they do best.
This partnership is part of an ongoing effort to provide Cloud-A users with world class tools to run their workflows on our high performing, secure, Canadian resident cloud servers.
Visit our Cloud 66 solutions page here for more details.
Cloud-A’s Channel Manager, Geoff Sullivan recently did a webinar with Ulistic called “Putting Clients in the Cloud.” Geoff Describes the notion of “True Cloud” and how it is can revolutionize the efficiency of service delivery for traditional IT managed service providers, and create flexibility and business agility for their clients.
Cloudberry Lab 
is a company that makes backup and file management software for hybrid cloud environments, allowing users to backup or sync files from their local systems to the public cloud. While Cloudberry has paid products for backing up Windows servers and applications, they offer a piece of freeware called Cloudberry Explorer, which is a file manager that allows you to sync files from your Windows system to a number of public cloud options including OpenStack.
CloudBerry Explorer for OpenStack is built on OpenStack Swift technology, which means that users can use it with Cloud-A’s Bulk Storage ($0.075 per GB per month). You will need to create at least one Bulk Storage container by navigating to the storage tab in the Cloud-A dashboard and selecting “New Container.” Appropriately name your container and you are ready to download Cloudberry Explorer.
Tip: To keep your cloud-synced files organized, we recommend creating multiple Bulk Storage containers and treat them as if they were a folder directory on your local system.
Navigate to http://www.cloudberrylab.com/download-thanks.aspx?prod=cbosfree and download CloudBerry Explorer for OpenStack Storage.
Simply follow the steps to completed the installation wizard program.
Once CloudBerry Explorer has launched you will notice that the left side of the screen represents your local systems folder directory and the right represents cloud storage. On the cloud storage side click the source drop down menu and select:
<New Storage Account>
Select Cloud-A
Then enter your specific credentials as follows:
Now Select “Test Connection” to ensure that the system has accepted your credentials.
If Test Connection fails, ensure that you have entered your credentials correctly. If you have entered your credentials correctly but are still receiving a “Connection Failed” error message, ensure that you have the correct ports open for Bulk Storage. Those ports are: 80, 443, 8443 and 8444.
If your credentials were entered correctly, the Bulk Storage container you created in the first step will appear in the file directory on the right side of the screen. To test the connection, select a test file from your local system, and select “Copy.” A transfer status message will appear briefly at the bottom of the screen and the file will copy from the left side of the screen and appear in your cloud storage container on the right.
To prove this concept, log into your Cloud-A dashboard and navigate to your new Bulk Storage container. You should see your test file.
CloudBerry Explorer is a great way to manually sync files to Cloud-A, and a great introduction into hybrid cloud solutions. Check out some of CloudBerry Lab’s other products for more advanced features like scheduled backups and encrypting files.
Be it capital intensive in-house solutions powered by VMware and SAN technology or re-selling contracted collocated infrastructure, managed service providers have been offering some version of the “cloud” for the past decade or so.
Meanwhile, in a not-so-different industry, application developers have been leveraging “new” cloud technology which allows for self serving, on-demand infrastructure, requires no upfront equipment cost, allows you to pay for what you use, and with no buyer-lock in. This is known as the public cloud – powered by Openstack.
Many of the benefits of an Openstack public cloud that software development companies have been enjoying since the inception of the technology can also be enjoyed by a managed service provider. The disconnect? Many of the features of an Openstack public cloud that create these benefits are features that historically, have only mattered to a developer. The reality is, these features can be extremely valuable to an MSP as well.
OpenStack is an opensource project and a community of thousands of developers who contribute to the ongoing growth of the product. While opensource isn’t typically a concept discussed in the IT channel, the concept ensures rapid and ongoing innovation, which in turn allows a MSP to introduce new functionality and features to their own clients.
In a highly competitive industry like the IT channel, differentiating your service from your competitors can make the difference between being competitive and being the leader. Offering your client base innovative, leading edge products and services creates value for your clients and a competitive edge for your business.
APIs are what developers use to automate the process of connecting one application to another. Developers use APIs to link functionality of their products to existing products so that their end users don’t have to do it manually. Why would APIs matter to an MSP? Many of the manual, labour intensive processes MSPs would typically perform to manage their client’s infrastructure can be automated with an API driven public cloud.
More and more public cloud friendly applications are coming to market that integrate directly with public clouds through their APIs. Take Cloudberry Lab (www.cloudberrylab.com) as one example. Cloudberry makes products that synchronize and/or backup local systems to Openstack public clouds, among others. This functionality is driven by APIs.
API driven public clouds, and the abundance of available third party applications are enabling MSPs to expand their product and service portfolio, automate laborious processes and create more value for their clients.
Developers enjoy the benefit of the bill-by-the-minute pricing model of the public cloud for building products, test environments, and other workflows where instances aren’t required to be powered on 24/7.
Utility billing sets MSPs free from hardware staging and allows them to avoid using expensive, production equipment for proof of concept testing and client demonstrations. The economics of the utility model also prevent MSPs from incurring long term colocation or dedicated server contracts, allowing them to add infrastructure as they add clients, and scale back infrastructure when it isn’t needed.
Cloud technology has changed, and it has created an excellent opportunity for MSPs to revolutionize their service delivery model with modern technology, streamlined process, reduced service labour costs, and more attractive economics. Developers have been realizing these benefits for years, and the time is now for MSPs to do the same to gain a competitive edge in their markets.