DevOps on Oracle Solaris Like A Pro

As you may know we also release technical blogs about Oracle Solaris on the Observatory blog and on this blog we recently wrote a series of blogs on the DevOps Hands on Lab we did at Oracle OpenWorld this year. One of the requests I got after these blogs was for a higher level overview blog of this DevOps Hands on Lab. So here it is.

Introduction

In general this Hands on Lab was created to show how you can set up a typical DevOps toolchain on (a set of) Oracle Solaris systems. In practice the toolchain will be more complex and probably a combination of different types of systems and Operating Systems.

In this example we've chosen to do everything on Oracle Solaris in part to show that this is possible (as this is sometimes not realized), and how you can leverage Oracle Solaris features like Solaris Zones and SMF to your advantage when doing so.

In this particular case we also used Oracle WebLogic Server to show how this is installed on Oracle Solaris and to show how install and use the Oracle Maven plugin for WebLogic Server as this is also a very handy tool and works pretty much the same on all platforms.

The Workflow

The DevOps toolchain we want to create essentially looks like this:

Note: The whole setup here is inside a single VirtualBox instance with Solaris Zones inside it because in the Hands on Lab every participant get a separate laptop and this way we can simulate the full set up within a single system.

The general flow goes from left to right with the following main steps:

• A developer writes their code, probably on their laptop or workstation in their favorite development tool, in this case we are using NetBeans but they can essentially use any tool they like. The language in this case is Java because we're going to be using WebLogic as the application server but the same flow holds for other languages too.
• Once the developer is ready to test their code, they commit their changes to their source code management system, which in our case is Git. In Git you first commit to the local copy of your code repository and then you push your changes to the main repo (which often is called "Origin"). This main repository is where other developers also will be pushing their changes and is often located on a central server (or even on a public location like GitHub).
• Once the new version is in the central repository it will signal this to a build manager, in our case we've chosen to use Jenkins as the build manager as it's extremely popular and has many extra modules for all kinds of use cases. In this case Jenkins is installed on the same "server" (personified by a Solaris Zone) as the main Git repository but this is by no means necessary, we're running in the same environment to save space. Jenkins has jobs defined by the developer where they can configure what needs to happen once the code is changed.
• According to the job configuration Jenkins will then build and run the first tests on the application, but first it creates a clone of the Git repository into a work environment so it can run a completely fresh build.
• Now the code is built and tested, on our case we're using Maven as the Java build tool, it will put the resulting code in the same work environment. For the initial testing of the resulting code we can use a tool like JUnit, this is done with test code that has come from the developer inside the same repository. In simple example we don't use any test code.
• Once the build is successful Jenkins tells Maven to connect to the application server on the deployment server and push the new version to it so you can do further testing. The use of deployment server may be confusing, at this stage it's more a test server simulating being a deployment server.

At this point the new version of the application is up and running, which means it can for example be connected to other systems in a larger test of all the different application pieces, or just used for individual function testing.

The intent of this whole chain is to allow a developer to push their code into the repository and that after that everything automatically happens and they don't have to do anything by hand or submit tickets to have someone else clear space on a system set it up and install all the bits necessary. This is all predefined and rolled out automatically, saving a lot of time and engineering cycles both on the developer side as well as on the operations side.

The other benefit is that the developers can very easily try out different versions quickly after each other this way quickly iterating to a better solution than if things need to

The reality of course is slightly more complex than this simple case. This workflow would be used maybe for initial testing and once it has successfully run this new version can be promoted to a different repository where it will be built (possibly by a different Jenkins server) and then deployed to for example systems for stress testing, or pre-production systems for testing in a production like setting. And then finally once it's deemed ready it can be promoted and deployed to the production systems. And all of this can be made easier with this type of automation.

DevOps and Oracle Solaris

So what about DevOps and Oracle Solaris? Well, there are many aspects to this, first as you can see in this Hands on Lab example, all these tools run just like they would on other platforms. This is in part because they are designed to do so and also in part because the languages they're based on also run on Oracle Solaris. We actually ship most of them (Java, Python, Ruby, Perl, …) with Oracle Solaris and adding them is a simple package install.

In general we ship a lot of FOSS tools with Oracle Solaris as well as work with FOSS communities to make and keep it working on Oracle Solaris. So besides the languages we include source code management systems like Mercurial, Subversion, Git, and others. We ship JUnit, all the GNU tools, Puppet, and many other tools and packages. Maven or Jenkins mentioned in the example above we don't ship because these constantly update themselves anyway and folks tend to be picky about what version they want to use.

We actually use many of these tools in our own development of new Solaris versions. For example we use Mercurial and Git as you may expect for all the different types of code we either write ourselves or bring in from the FOSS communities. But we also heavily use a tool like Jenkins to automate our build and test system. We rely in the same way on these tools to make development simpler, with less mistakes, and quicker.

Finally a short word on using the tools in Oracle Solaris for a DevOps environment. In the Lab we only use Solaris Zones and SMF, the first to create isolated OS containers that can function as secure isolated environments with their own resources and namespaces. And the second to turn Jenkins into a Solaris service that you can enable and disable, and that will automatically restart if it for some reason fails or is accidentally stopped.

But there are many others you can use too. For example you can use Boot Environments to easily move between different configuration or patch versions. You can use the built-in Network Virtualization to create separate networks, each isolated from each other that can even span different systems. You can use Unified Archives to create an archive of a system, domain, or zone in a certain state which you can easily roll out multiple times across one or more systems/domains/zones to fit growing demand. And there are many others.

As stated above the in-depth technical blogs can be found on the Observatory blog, and they are spread over Part 1, Part 2, Part 3, and Part 4.

Note: that even though the workflow goes from left to right, the blogs build the toolchain from right to left as it's easier verify each step is working that way.