Per default every application deployed on anynines is accessible via a subdomain of a9sapp.eu for both HTTP and SSL protected HTTPS.
However, in most cases applications should be accessible via a custom domain and, of course, this should be also possible via HTTP and HTTPS.
Anynines is based on Cloud Foundry, an open source PaaS. Hence, it is pretty easy to import your own domains and let them point to your application using functionality provided by Cloud Foundry. The anynines team has then added the missing link and created support for custom SSL certificates to protect your custom domains.
Running your applications on anynines gives you the possibility to set up an SSL certificate for your custom domains.
This blogpost guides you through the process of mapping your domain to an application running on anynines, getting and importing a SSL certificate to make your application available through the secure HTTPS protocol. (more…)
A few words about continuous deployment
Continuous deployment is part of the continuous delivery paradigm. The basic idea of continuous delivery is to automate the software delivery process as far as possible. This includes automated testing, continuous integration as well as continuous deployment.
Your continuous deployment benefits
With a working continuous deployment chain in place you gain the following benefits:
This prevents individual developers having uncommitted code.
Everything must be committed to be tested and everything must be tested to be deployed.
Easy to learn and use
As you will learn in this article continuous deployment is easy to setup. But more importantly, think of your growing team of developers. New team members have to learn how to use your CI and deployment process.
With a continuous deployment in place all they need to learn is to commit to a git repository.
Everybody can deploy
Many teams allow only certain members to deploy code. Why is that? Most likely either because of lacking trust within the team and/or because of complicated deployment procedures. You can get rid of both causes, easily by enforcing a CI along with an automated deployment. (more…)
The Fog HP storage provider is currently the most stable and recommended way to access Swift using Ruby as the HP storage implementation is more reliable than the OpenStack provider.
So while you should use OpenStack::Identity for tenant and user management, Swift access is rather done using HP::Storage of the HP provider.
During the creation of the Anynines OpenStack Swift file storage service a pull request to the Ruby fog gem has been made.
The pull request enhances the HP Fog provider to create temporary URLs for files stored on OpenStack Swift.
Here HP goes a different way calculating the required signature to request a temporary url. Both strategies: HP and OpenStack are now supported. (more…)