Version 4.1 of Univention Corporate Server supports Docker Apps from within the App Center. However, firstly lets have a look back on how the App Center has developed over the last years to better explain the reasons why we decided to support Docker. Afterwards, we will have a quick look at the technical details of the implementation within UCS before discussing what the advantages for app vendors and, most importantly, users are. Lastly, I will be happy to give a quick peek into what the future has in store for the App Center.
The App Center before UCS 4.0
The Univention App Center was introduced about three years ago and has since developed into one of the most central components of UCS by enabling administrators to install and maintain central applications with a few simple clicks. We have received overwhelming feedback from both our users as well as our partners and the offer of applications has grown consistently.
As of today, the App Center includes tools for every scenario ranging from groupware solutions to content management systems, from ERP software to tools to administrate IT infrastructure and from security software to backup suits. Additionally, a number of small, but important, specialized solutions has found its home in the App Center. To sum it up: The App Center offers the option to easily extend a UCS domain with many components needed for a productive IT environment.
From the point of view of the many independent software vendors the packaging of applications proved to be very simple. They only had to provide a package for the operating system and a couple of meta information and the software became available in the App Center and could be installed by the users.
However, software manufacturers were always bound to the stable and mature basis UCS provides. Apps had to rely on system libraries and programming languages that were included in the base system. Newer versions were generally not possible as the risk of compatibility problems was higher than the possible gain.
Here at Univention, we have expanded the automated tests that an app passes through before being released. This helps us to ensure that no application harms the domain when being installed or uninstalled.
With a growing number of apps these tests have become more and more complex to exclude any problems due to the interplay of multiple apps. This became especially relevant when dealing with the question of how to uninstall software before installing a similar solution. We are slowly reaching the limit of what we can accomplish here.
Docker Apps in UCS 4.1
This is only one of the many reasons why we started searching for an alternative. This search for an alternative to install an app directly on the server led us to start looking at Docker. The container technology behind Docker provides a thin but secure encapsulation of the processes which in turn provides every application with their own environment that the app can modify without compromising the stability of the server as a whole.
You start so-called containers which create a system that is separate from the remaining one but in such a way that you can still easily access it from the main system. In such a container the app will then be installed. One of the important features is that this container has relatively low operational costs. It is, for example, still using the same Linux Kernel.
Fully virtualized solutions would have produced considerably higher degrees of complexity, especially if it still should be possible to modify the system from the outside and yes, the App-Center also provides these options. Full virtual machines would also be considerably more expensive computationally. Another added problem would be to deal with the fact that most UCS systems are already running in virtualized environments or in the Cloud establishing the need to deal with virtualized systems within virtualized systems.
Docker Conventions ignored!
Most often Docker is hailed as the solution for so-called “Microservices”. Thereby, each container is running exactly one process with exactly one purpose. This in turn means that for a bigger job like deciding “I want to run a groupware” many containers are needed. Sticking to the groupware example, one would need a container for accepting mails, one for modifying the mailbox, one for the communication with the network, one for logging and so on. Files will not be saved in the container but in volumes so that many different containers and the host can access the files.
We chose a different route when planning the integration of Docker apps. We are not starting one process but are practically starting a whole operating system. The Docker containers that are used by the apps are fully functional, admittedly highly simplified and lightweight UCS systems. When starting a container, they boot and when stopping a container they shut down. When running, they start the app that has been installed in that container.
For the software vendors, there is little to no difference between a Docker app and a usual UCS app. Also in the future they only have to provide software packages for UCS and do not need to take care of providing Docker containers. Likewise there is no change for the users. They can use the containers like a normal UCS system which admittedly is reduced to being a single platform for the app.
Advantages of Docker Apps
Docker apps encapsulate the file system around the actual app. As apps cannot influence one another, container technology greatly enhances the security for the users. Docker apps are easy to secure and, if there is a problem, it is easy to revert to an older version.
For the manufacturers there is little change. They still provide the apps using the well-known steps. The only difference is that their packages are not anymore installed on the server itself but within a container. Is, however, the container little different from the host system, the ISV can mostly ignore that Docker is used.
A great advantage for the software vendor is however that he has the system for himself. New versions of packages can be installed, configuration files can be replaced and much more. Compatibility can be mostly ignored. The container can even be updated independently of the host system, enabling the container to be on a more recent or on an older UCS version than the remaining domain.
We also did a lot of work on the interfaces between the host system and the containers. In the best case, the app vendor does not have to change anything when providing its application in the App Center. The integration into UCS is then realized by using these interfaces, which are provided by the App Center servers from outside the container.
For us here at Univention the automated checks are eased considerably. We do not have to deal with apps that might or might not exclude or influence one another. Instead, we can focus on the interfaces and the core components, while the app vendors extend the UCS domain by providing further business solutions to the customers.
All of the above convinced us that the new Docker apps are an important step in making the Univention App Center fit for the future and making it considerably easier for the app vendors to provide their solutions. For the customers it is an important step towards a comfortable and secure IT domain.
We are eager to see how our Docker apps will be accepted.
Epilog: The Future of the Univention App Center
UCS 4.1 will include the first iteration of Docker Apps. We made sure that the interfaces are designed according to the wishes of our partners. While the number of interfaces will certainly grow with time, we will continue to work closely with our ISV partners.
We also have built the foundation to include foreign containers into UCS. While we have focused on UCS containers, in the future we will be supporting other operating systems such as Ubuntu or Fedora. We are also considering how to support containers built by the app vendors. Even though that in turn would develop more into the direction of micro services.