Minishift is a tool that allows you to run OpenShift locally as an OpenShift cluster from a single node inside a virtual machine.
Technologies are evolving, and with them are changing and the processes of developing and deploying applications. If earlier these were fairly standard things with a strictly limited set of components involved, then in recent years, with the advent of new tools and frameworks, there have been dramatic changes in this area. Installing a software package on your personal computer today looks trivial, but put yourself in the shoes of the IT department, and immediately a lot of questions will arise. Where did this or that software component come from? Why is it needed? How is it updated? Who is supporting him? These are really important and unavoidable questions if the organization adheres to advanced security practices and must comply with security policies and rules.
Deploying a full-fledged OpenShift environment on a typical developer’s machine is usually not very practical. At the same time, the local Minishift allows the developer to realize all the advantages of containerized workload management, increasing its productivity and eliminating the complexity of operational support.
With the transition to OpenShift, organizations realize that having a local container platform for a developer provides several advantages: for example, developer independence from the OpenShift corporate environment and, as a result, reducing the load on the latter. In other words, it helps to reduce costs and implement additional services.
So you want a local OpenShift
Based on our experience, we can say that before using Minishift, you need to do the following:
- Describe system requirements
- Formulate a list of dependencies
This information will help sysadmins, kids from desktop support, and people who are responsible for complying with policies and security rules understand what they have to deal with. System requirements and dependencies directly correlate with which deployment option will be used.
Since here we are familiar with the corporate scenario, we will focus on the
Container Development Kit (CDK) , a branch of the Minishift project, brought to the stage of the finished software product.
There are two options for installing CDK:
- Using a standalone executable file
- As part of the Red Hat Development Suite , which includes various container development tools, including OpenJDK, Red Hat JBoss Developer Studio, VirtualBox, and the Container Development Kit
Most organizations, as experience shows, prefer to use a standalone executable file, rather than the Red Hat Development Suite, just to avoid unnecessary tools. On the other hand, the Red Hat package is great for developers who are outside the corporate context because it provides a simple and straightforward, step-by-step installation of the CDK. In addition, organizations can already use tools similar to those that are part of the Red Hat Development Suite.
Regardless of the CDK installation method you choose, you will need one of the supported hypervisors, since the CDK works as a virtual machine (VM).
There may be several options:
What kind of hypervisor depends on the operating system on the development machine, and in most organizations it is either Windows or OS X, because most developers very rarely use Linux as their main OS for work.
The need to have VMs on developers' machines is far from being pleasant to everyone, since this requires additional processor resources and RAM. Security professionals are also not thrilled, as this can compromise security at the network and PC level. In addition, administrator rights are required to install and sometimes to use the hypervisor.
Fortunately, with the proliferation of new approaches to development, when VMs are used together with automated environment customization tools, such as Vagrant, many organizations already have hypervisors on development machines, and they can skip this step, eliminating a number of serious obstacles to using Minishift in corporate environments.
Installation and Setup
Sooner or later the obstacles will be overcome, and the turn of installation and configuration of the CDK will come. Usually, organizations block the download of executable files for security reasons, so you will have to use other mechanisms. For example, it may be a directory of approved software, or you can place the CDK installer in a repository, such as
Sonatype Nexus or
JFrog Artifactory , from where users can download it.
If the installation is done manually, without using the centralized deployment and configuration tools available in the organization, the user can either directly launch the installer executable file or put it in the directory specified in the PATH variable, where this file will be available from any terminal session. In the case of Windows, the user usually does not have permission to change the system PATH variable, since it applies to all accounts on the machine. But the user can edit his personal variable PATH, which is valid only for his account.
The next step is to install the CDK itself using the appropriate command:
minishift setup-cdkThis command extracts the .iso file used to boot the VM and prepares the system for use. At the same time, all files are copied to the .minishift folder in the user's home (HOME) directory ($ HOME / .minishift). This folder can be changed either using the –minishift-home flag, either using the MINISHIFT_HOME environment variable. In corporate environments, the home directory is often located in a network folder so that the user, if necessary, can transfer to another computer and calmly continue working. However, this option adversely affects the performance of the CDK, since reading and writing will be performed over the network, and not from the local disk. In addition, without connecting to the corporate network, the user loses access to the files necessary for the operation of the CDK. When selecting an alternative location for the CDK, the user must have write access to the selected destination folder.
And finally, the last step that needs to be performed before running the CDK is to provide credentials for registering a copy of the Red Hat Enterprise Linux (RHEL) included in the CDK on the Red Hat Network (RHN) website. Registration is needed so that containers running in the OpenShift environment can use yum packages, since yum uses the subscription of the underlying host. A development subscription can be obtained free of charge at the site
developers.redhat.com , or it can be part of an existing corporate license. However, the CDK can work without a subscription machine, with limited functionality.
The credentials can either be set in the environment variables MINISHIFT_USERNAME and MINISHIFT_PASSWORD, or specified in the start parameters -username and -password, or set as one of the configuration parameters using the config minishift command. In addition to the credentials, the config minishift command allows you to specify a number of other parameters, such as the hypervisor driver, the number of CPUs and RAM for the VM. For example, here’s how the VM driver is set:
minishift config set vm-driver virtualbox
After that, it remains only to run the CDK (with additional parameters if necessary):
minishift start
After that, the Container Development Kit will create a new VM, register it and perform other necessary operations, namely:
- Load a containerized version of OpenShift
- Select a set of Persistent Volumes for organizing permanent storage.
- Enables a number of additional modules to extend the basic functionality of OpenShift
- Create administrator and developer accounts to interact with the platform
Once launched, the CDK will provide a URL for accessing the web console, as well as credentials for logging into a developer account.
In general, with all the prerequisites, the basic installation of the Container Development Kit should be easy.
And on June 16 at DevOpsDays Moscow 2018 we will hold a master class / workshop / live demonstration of the scenario of using the OpenShift platform, deployed in the Azure public cloud.We show all three variants of deployment - from the source code, from the image of the container, from the template. Let us show how easy it is to set up a webcam so that our application is automatically rebuilt upon the occurrence of a specific event, for example, after a commit. We will show the A / B test script, tell you about the concept of the service account and run the super-legacy application in a container.
We will spend only an hour of your time to show how (in our humble opinion) your daily CI / CD tasks are quickly and easily solved using the OpenShift Container Platform on Microsoft Azure. Come!
BONUS: Want a promo code for a discount? Write us in private messages.