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.
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 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:
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.
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.
https://crc32c.blogspot.com/2017/09/leeeroooy-jenkins-or-lets-do-some-cicd.html