The IPython/Jupyter notebook is a wonderful environment for computations, prose, plots, and interactive widgets that you can share with collaborators. People use the notebook all over the place across many varied languages. It gets used by data scientists, researchers, analysts, developers, and people in between.
Docker announced Docker Machine in December 2014. This clever new software eliminates the need to create virtual machines and install Docker before starting Docker containers on them. It handles the provisioning and install process for you behind the scenes. You can learn more about Docker Machines at its GitHub project page.
Let’s take a quick look at how we can get some of this awesomeness!
This is the third article in my series on OpenStack orchestration with Heat. In Part 1, I introduced the HOT template syntax, and then in Part 2, I showed you some of the techniques Heat offers to orchestrate the deployment of applications that run entirely within a single compute instance.
Today, building on the same ideas exposed in my previous article, I’m going to show you how to design deployments across more than one instance, and I’m going to demonstrate these concepts by deploying an application that runs on a server and connects to a MySQL database on another server. You have seen how to deploy a Python application in my previous examples, so, to add some variety, I’m now going to switch to a PHP application as guinea pig. That application is none other than the venerable Wordpress.
Welcome to the second part of my series on OpenStack orchestration with Heat. In the previous article, I gave you an introduction to Heat orchestration. All the examples that I showed you were simple and not terribly useful, as they were only intended to introduce the structure of the HOT (Heat Orchestration Template) syntax.
In today’s article, I’m going to elevate the complexity quite a bit, demonstrating some of the tricks you can use with Heat to perform deployments of single instance applications. As with the introductory examples, you are encouraged to try my examples on a Rackspace Private Cloud, DevStack or any other OpenStack installation that includes Heat.
With this article I begin a series of hands-on developer oriented blog posts that explore OpenStack orchestration using Heat.
To make the most of this article, I recommend that you have an OpenStack installation where you can run the examples I present below. You can use our Rackspace Private Cloud distribution, DevStack, or any other OpenStack distribution that includes Heat.
Keystone and many current OpenStack API components run in an Eventlet based http server. Eventlet is designed to perform well in networked environments and handles everything in a single thread.
The developers responsible for the Keystone project have recently recommended using Apache (with the mod_wsgi module) as a front-end rather than the traditional “Keystone” Eventlet-based process.
By using Apache as the front-end for Keystone, one gains better performance due to Apache’s ability to do multithreading. One can also take advantage of the variety of http server modules currently available for Apache. One popular module, Shibboleth, provides the ability to use one set of credentials to authenticate against multiple OpenStack clouds (more info here).
Here is a straight forward guide on how to setup Keystone to utilize Apache in your existing OpenStack deployment.
If you already have an existing Swift cluster and you would like to add additional storage, you can use the swift-ring-builder command on the ring builder files from any server that you have the utility installed on. Once you update the files, you will need to push them out to all the nodes in your cluster.
TLS and SSL are two critical technologies which underly much of the secure communications that occur on the internet. Over the past few years, spurred by increasingly effective attacks and a desire for new functionality, SSL and TLS have seen many new features, as well as practical improvements.
Python is currently in a transitional period between Python 2 and Python 3. For
the past few years, all new feature development has been happening on Python 3,
including new features in Python’s
ssl module. This means that Python 3 users
have had acccess to these improvements to TLS, but Python 2 users (still the
majority of Python users) have been falling behind.
To simplify the custom image creation process, Rackspace released boot.rackspace.com, a collection of iPXE scripts that allows you to rapidly network boot Operating Systems, Utilities and other tools very easily. It’s especially useful for remote access environments when you don’t want to utilize remote attached CD’s in a Dell DRAC, HP iLO or some other type of remote tool. It’s especially awesome for bootstrapping your own custom installation on a Cloud Server!