In this article, I will present options for building containers that will run in Kubernetes and Red Hat OpenShift. There are many reasons against development in the environment that will ultimately run the container, such as cost, speed, tooling, and so on. Creating a container that works on your PC requires a local development environment that gives you the complete experience of coding, building, debugging, and running—and then pushes all pieces of the container to a host or cloud service. The best way to describe this process is tantamount to encapsulating your entire software building experience into one file and then sending it off to a server.
Container development offers a new way of thinking about software development. It is an application development model in which you decide which operating system and runtimes run your application, and which libraries to include. A software container holds the application, libraries, runtimes, operating system, as well as specifications for the network port, environment variable values, and more.
3 Options for building containers on a PC
I will provide solutions and better alternatives to developing in the same environment that runs the container. The following sections describe three options for building containers on a local desktop or laptop:
1. Docker Desktop is the most common environment
Docker Desktop is the most common environment for building containers on your PC for good reason. It has been around the longest, and it’s pretty much synonymous with containers. All you have to do is install it on your system running Windows, macOS, or Linux (Debian, Fedora, and Ubuntu are supported).
In addition, Docker Desktop is the only container-building solution that supports containers that run on Microsoft Windows. If you want to build your legacy Windows applications on your PC for Kubernetes or OpenShift, you must use Docker Desktop.
There are a few pros and cons to choosing Docker Desktop:
Pros:
- Very popular and common.
- Can build Windows containers.
Cons:
- It might cost you money, depending on your company's size and needs.
- Runs a daemon on your machine.
2. The pros and cons of Podman Desktop
You will find free and open source alternatives for many software development tools. In this case, the alternative to Docker Desktop is Podman Desktop. Podman is the tool I use and recommend. It bills itself (on the website) as "Fast and Light, Open, Simple" with an "Extensible Workflow."
Pros:
- Free and open source.
- Runs on Windows, macOS, and Linux.
- No daemon.
Cons:
- Cannot build Windows containers.
I suggest you pick up a free copy at the Podman Desktop website and start building container images today.
3. Building with Red Hat OpenShift Dev Spaces
Last but not least, Red Hat OpenShift Dev Spaces (formerly Red Hat CodeReady Workspaces) is the wildcard in the mix. OpenShift Dev Spaces is a browser-based IDE that runs in an OpenShift cluster. Yes, that means you need access to an OpenShift cluster, which may be a show-stopper. You might find that this is the best all-around solution.
This option requires a completely different approach to building a service. Initially, you will build a CI/CD system with all the OpenShift objects required, such as DeploymentConfig, secrets, service, and route. This may seem like backward thinking, but you will eventually need all these objects, so why do it not now?
Configuring the CI/CD system requires a bit more work, but the payoff is huge. You will be able to do robust development, coordinate multiple developers' efforts, and automate many build tasks.
Dev Spaces is convenient because it runs in the browser. This practice seemed odd at first to me. But once I decided to run my browser in full-screen mode (by pressing F11), I quickly forgot that I was in a browser. The response is snappy and familiar—Visual Studio Code in a browser.
You can build and debug your code right there in the browser. There is a way to build a container in the browser-based IDE as well, but it isn't obvious. We will cover that approach in a future article. For now, let's assume this cycle:
Build and test and debug → Push to git repo → Trigger CI/CD builds → Run in your Kubernetes/OpenShift cluster
You can now switch from any machine (Mac, Windows, Linux, Chromebook, iPad Air, etc.) to another machine. All you need is the URL to your project. You don't need to install anything.
Pros:
- Portable across any platform that can run a modern browser.
- Forces you to use a CI/CD system.
- Nothing to install.
Cons:
- You must have access to an OpenShift cluster. (Hint: You can get free access at Developer Sandbox for Red Hat OpenShift.)
- Forces you to use a CI/CD system.
- Container builds take longer as you wait for the CI/CD system to do its thing.
- You are not running your containers locally; they are running in OpenShift.
This is a pretty slick way of working once you get accustomed to it. This solution pays off in the long run. You can learn more about it at the Dev Spaces website.
Which cluster to use?
Once you have established your local container development environment, you will most likely need a Kubernetes cluster where you can run multiple services that, together, comprise the system you are creating. Along with the development environment and cluster, it is a great idea to have a CI/CD system that builds and tests the application and flows into the cluster. You want to get to the point where you push your code to a Git repository, and the application automatically builds and lands in your cluster.
Of course, if you use the Dev Spaces service, you already have a cluster. If not, here are four alternatives:
1. Your organization's cluster
This is the gold standard. If your organization has a Kubernetes or OpenShift cluster, and if there is namespace in which you can run containers, you have the best option. Build, run, test, and debug on your machine, then push the container to the cluster. Or you can push your code to your CI/CD for it to end up in your cluster, using Dev Spaces.
2. Minikube
Minikube is a small Kubernetes instance that runs on your machine. It takes up some memory and CPU resources, but you get complete control over the cluster in exchange. This is great for a quick cycle of code-build-debug-test.
3. Red Hat OpenShift Local
Red Hat OpenShift Local (formerly called Red Hat CodeReady Containers) is similar to Minikube in that it runs on your local machine. The most significant difference should be obvious—running OpenShift versus Kubernetes with Minikube. But OpenShift Local is also Kubernetes under the covers. You can treat this as a Kubernetes cluster if you are not developing for OpenShift. You can also build for OpenShift and get some of its many benefits.
4. Developer Sandbox for Red Hat OpenShift
This solution costs you nothing and takes no CPU cycles from your PC. This is the same model as using your organization's cluster, but there are some limitations to remember:
- It's intended as a learning environment, so the amount of RAM and disk space is limited. You will get out-of-memory (OOM) errors eventually. I know this from experience.
- Your free trial expires after 30 days. Yes, you can renew, but this isn't an ideal situation.
- The Developer Sandbox is a free offering from Red Hat. How long will it be around? Who knows?
This option works well if you are just getting started, especially if you are creating a proof-of-concept application. However, Developer Sandbox is not a long-term solution.
You can join the Red Hat Developer Program for free and get free access to Developer Sandbox for Red Hat OpenShift.
Cost-free container development
Start building container images and running them on Kubernetes or OpenShift without spending any money. I hope my advice inspires you to learn, experiment, and move forward. On top of everything else, the process is fun too.