Over the past year, Kubernetes has emerged as the industry standard for container platforms. There are now several platforms based on Kubernetes that are offered with their own interface and preconfigured services as well as additional features. For example, the container platform dubbed “Openshift” by Red Hat is being used more and more frequently.
In many companies, development and test environments are encapsulated in their own networks and thus secured. This means that access to and from the Internet is not possible. Even the standard installation of Openshift is somewhat complex. With the requirement to set up the environment offline, the complexity increases significantly.
We’ve tried it out and show you what you need to bear in mind when installing offline. We used Openshift with the corresponding Ansible installer and our tool orcharhino:
Openshift is a container platform from Red Hat, based on Kubernetes. As is usual with Red Hat, there is both an enterprise version with a subscription model (Openshift Enterprise) and an open source version (Openshift Origin).
New features will be integrated into Openshift Origin and included in the Enterprise version as soon as they are stable. In addition to the usual features of a container platform such as multi-tenancy, high availability, orchestration tools and integrated services for logging and monitoring, Openshift’s special feature is a collection of developer tools. These range from an integrated, containerized Jenkins to webhooks for git repositories and Openshift’s source-to-image builds (S2I). With S2I, developers can give their code in a git repository directly to Openshift. They can use the corresponding development framework for this. If they do not specify this, Openshift decides which framework to use based on the file extensions.
Openshift then starts a base image with the corresponding framework. The next step is to clone the Git directory, start the application and save the resulting container image in the integrated Openshift registry.
The second tool used is orcharhinobased on Foreman and Katello (similar to Redhat Satellite 6). This allows repositories to be synchronized and provided as a mirror. In this case, both yum repositories and container images are required for the installation of Openshift. Debian distributions and SLES can also be provided. With the corresponding lifecycle environments and content views, the version statuses can be frozen and fixed. This provides stable package versions for productive operation. The required servers can be set up directly via appropriately connected hypervisors. Baremetal solutions are also possible. All servers can then be prepared directly for the Openshift installation using the integrated configuration management tools.
For an offline installation, it must be ensured that all repositories and packages are available. Via orcharhino these are provided. In addition to the packages, the container images must also be synchronized. These are necessary if Openshift is to be installed in the containerized version. This is also necessary for the corresponding services that are to run in Openshift after installation. These services include the provision of metrics, management of logs, a registry and the HAProxy for routing.
When synchronizing container images with orcharhino, the repo structure is changed. This changes the naming of the images.
From:
registry.access.redhat.com/openshift3/ose-haproxy-router:v3.7.46
is indicated by orcharhino :
orcharhino.atix.demo:5000/ATIX-production-openshift_content-container_images-ose-haproxy-router:v3.7.46
according to the following scheme:
:5000/----: |
The sources used for the images and their modified repo structure must now be taken into account in the Ansible inventory for the offline installation. Openshift can then be set up in an environment without direct internet access.
This requires the use of orcharhino as registry is necessary. For the base images, the following parameters are then added for the installation:
openshift_docker_additional_registries=orcharhino.atix.demo:5000oreg_url=ATIX-production-openshift_content-container_images-ose-${component}:${version}
It is possible to span Openshift across multiple networks. For example, test and development environments can be separated but managed with the same master servers. Similarly, new environments can be added to an existing offline environment and upgrades can be carried out on existing installations.
The more complex the requirements, the more attention needs to be paid. The basic features are shown here – further details depend heavily on the environment and requirements in which the container platform is set up.
If you have any questions about the blog post or if you need support with the installation of a complex Openshift environment, you can contact us at any time!
