Skip to content

Instantly share code, notes, and snippets.

@tmckayus
tmckayus / remote_crc.md
Last active April 2, 2024 12:13
Running 'crc' on a remote server

Overview: running crc on a remote server

This document shows how to deploy an OpenShift instance on a server using CodeReady Containers (crc) that can be accessed remotely from one or more client machines (sometimes called a "headless" instance). This provides a low-cost test and development platform that can be shared by developers. Deploying this way also allows a user to create an instance that uses more cpu and memory resources than may be available on his or her laptop.

While there are benefits to this type of deployment, please note that the primary use case for crc is to deploy a local OpenShift instance on a workstation or laptop and access it directly from the same machine. The headless setup is configured completely outside of crc itself, and supporting a headless setup is beyond the mission of the crc development team. Please do not ask for changes to crc to support this type of deployment, it will only cost the team time as they politely decline :)

The instructions here were tested with F

@tmckayus
tmckayus / insecure_registry_crc.md
Created October 8, 2019 18:02
Adding an insecure registry for crc

Adding insecure registries on crc (and other things that require a node reboot)

Overview

Since crc deploys the OpenShift instance in a single VM, certain configuration changes can't be applied using the normal OpenShift mechanism. In a full deployment with multiple nodes, OpenShift coordinates the update and reboot of each node in the cluster, evacuating and rescheduling pods as it goes so everything continues to run. With a single VM this isn't possible, so some configuration changes have to be made manually.

@tmckayus
tmckayus / search_logs_crc.md
Created October 8, 2019 18:05
Search OpenShift logs on crc when you're out of ideas

Pro-tip on searching OpenShift logs in crc when you're out of ideas

To search quickly for content in the OpenShift logs across all pods and namespaces, enter a debug shell and grep in /var/log. This can be a handy way to search for errors when you're not quite sure what's going on with your application, you've already examined pods and events to no avail, and you don't know where to turn. Be warned, though, the output may be voluminous, so it helps to have some clue what you're looking for.