As you may have heard, Oracle has joined the Open Container
Initiative (OCI). We are happy to see an open standard being established for
container technologies. We feel containers have some real advantages for cloud
deployments when used properly, and we see this as an opportunity to bring our
experience with containers to the community. You see, our interest in container
technologies didn’t happen recently. We’ve been working on them for more than
I find it amusing that the industry has come full circle on
containers. With the OCI and technologies like Docker, we’ve comeback to
application containers, which is where Solaris originally started with zones.
When I was a kernel engineer in the early 1990’s, we used
chroot(1) to create build environments so that the build wouldn’t modify the
system we were running on. That worked, but it didn’t prevent me from
accidentally performing “rm –rf *” as ‘root’ one night at 2am working against a
deadline and not realizing I was not in the chroot environment. (Ouch!) My admin
team friends never let me live that one down.
Then, there were BSD Jails. They were the next step in container
technologies. They helped prevent those kinds of stupid user mistakes by
partitioning a system up into a virtualized environment.
In 2005, Sun Microsystems introduced containers in Solaris 10,
called Solaris Zones. Originally, the engineers wanted to build lightweight
application containers. This was at a time when the industry was moving toward virtual
machines, and it was decided that a full OS container would be better.
Over time, we added great capabilities to Solaris 10 Zones like
resource management and exclusive IP Stacks. Security has always been a focus
for Solaris and was one of the driving reasons for containers as a technology. Now,
you didn’t need to share the stack any longer. We embedded those capabilities
into Trusted Solaris. Oracle certified Solaris Zones as a hard partition
boundary. So, you could run the Oracle Database in a Solaris Zone and reduce
your license costs and only use the hardware you needed; a benefit that’s still
in use today.
The work didn’t stop there; we introduced other types of zones,
which we use today to support older releases of Oracle Solaris in a zone. And
there was even a time when Solaris supported versions of Linux in a zone.
After the Oracle acquisition of Sun Microsystems, the rate of
innovation accelerated. Oracle infused new life (and money) into (now) Oracle
Solaris development. The Zones team grew significantly.
With the first release of Oracle Solaris 11 11/11 (Yes, we
really did that), we gave zones the ability to create secure virtual networks
with our built-in network virtualization, code named “Crossbow”.
Continuing on the theme of security, with Oracle Solaris 11, you
could delegate administration for Oracle Solaris Zones. You no longer had to
give the “Zone Administrator” administrator privileges for the entire system.
We added the ability to update and rollback zones seamlessly
with the Boot Environments made possible with the integration of ZFS as the
root file system. This meant user errors could simply be rolled back rather
than having to hand unroll changes or take backups for every change that was
made to a system or a zone. But one of my favorite capabilities of zones was
the Immutable Zone! With Immutable Zones, you can make a Zone read-only (or
partially read-only) so that not even the almighty “root” can modify it... Hmm...
Too bad we didn’t have zones and ZFS when I was a new engineer!
Amazingly, that’s only a few of the highlights of zones in
Oracle Solaris 11 11/11. There are many, many more.
Oracle Solaris 11.1 was released about one year after Solaris 11
and we added zones on shared storage (ZOSS). ZOSS allows you to host a zone on a
About 18 months after the release of Oracle Solaris 11.1, we
released Oracle Solaris 11.2. This was a milestone release for the Oracle
Solaris Zones Team (now known as the Oracle Solaris Virtualization Team). Speed
has also always been a critical motivating factor for containers. But, with
that speed, there’s a tradeoff with containers. That is flexibility. With
containers, you share the underlying kernel. So, when you need to patch a
container, you patch all the containers on a system at the same time, and then
you need to reboot the system, and thus, take all the containers down at the
same time! There go your SLAs!
It was about the time that we were releasing Oracle Solaris 11.2
that containers began to get traction as a viable virtualization technology for
cloud. I remember reading an article while I was waiting in an airport lounge
that said that containers were going to “save the cloud.” I found it ironic that
this person had just seemingly come to the conclusion that full virtual
machines had a significant amount of overhead that was impacting efficiency of
I found this particularly funny because I was about to get on an
airplane to go tell hundreds of people about 11.2 and a new type of container our
team had built into Oracle Solaris 11.2 that acts like a type-2 hypervisor. We
call them “Kernel Zones.” So, you are able to run a full kernel in a container,
solving one of the biggest problems container technologies have. But even more
importantly, our brilliant engineers managed to make the new kernel zones have
only marginally more overhead on the system than what we now call a “Native
Zone.” So, you get the performance of a native zone (container) and the
flexibility of a type-2 hypervisor for Oracle Solaris without the hypervisor
overhead. You can read more about kernel
But kernel zones, while great, aren’t the entire picture. In
Oracle Solaris 11.2, we also gave you the ability to reconfigure a Zone while
it was running. No more reboots to add memory, disk, CPU, etc.! When you
combine that capability with Oracle Database running in an Oracle Solaris Zone,
you have the ability to do capacity on demand for the Oracle Database. Allowing
multiple Oracle Databases to share a single system in a secure way that doesn’t
impact their performance. That’s just cool.
In Oracle Solaris 11.2, we also gave you a full distribution of
OpenStack, now called Oracle OpenStack for
Oracle Solaris, where we tightly integrated both Oracle Solaris Zones and kernel
zones into OpenStack Nova compute.
The final piece to the Oracle Solaris 11.2 puzzle with Zones is
Unified Archives. Zones is integrated with Unified Archives. So, you can
snapshot a running Zone, and redeploy it elsewhere easily, but because of the
integration, you can resize the Zone as it’s being deployed and change the type of virtualization
too. So, your dev/test environment is only a 2 vCPU Zone with 2GB of RAM. But
you want to deploy it into a much larger 128 vCPU/8TB Immutable Kernel Zone? Engineers
use virtual machines, but your production environments use containers or the
other way around? No Problem! Just change the virtualization type and/or the
size as your needs demand.
Earlier this month, we announced Oracle Solaris 11.3 Beta. You
can download it here. In Oracle
Solaris 11.3, we give you secure live migration. What makes our live migration
“secure?” We automatically offload the Zone to the processor crypto engines as
it’s being transmitted from the source. Then, on the destination, we decrypt it
via the same hardware automatic hardware offload. Meaning that the Zone is
secure during the migration, and there is nearly no performance penalty to do
it. Making security simple is one of the important things we focus on. The more
complicated security is, the less likely people will get it right. Here’s just
one way we make it simple to be secure.
Now, with the Open Container Initiative, we have the opportunity
to take all of that technology we’ve been building into Oracle Solaris Zones,
and apply them to the original concept zones were born out of, application
containers. It’s been more than 10 years in the making, but we’ve come back to
It’s going to be interesting to see where we go next and where this
all takes us. We look forward to being a part of the Open Container Initiative.
Keep an eye out for some more news coming very soon.