Skip to main content

CodeReady Containers inside vs. outside

CodeReady Containers

Red Hat has produced a single-node kubernetes install that can run on a single developer's machine (also known by the acronym CRC).  This allows you to spin up a cluster, administrate it, and install your own software to it in an environment you completely control.

To kick the tires, I wanted to do the following:
  • Deploy a dead-simple application with one REST endpoint 
  • Be able to access it from outside the cluster (i.e. figure out ingress using ISTIO, not just the OpenShift automatic route)
  • Use an external build process using Maven and Google Jib (I like the buildpack like way that OpenShift provides, but I wanted to start without depending on all of that magic).

Google Jib 

 In order to get jib to work, I needed two things:

  1. I had to go searching for how the registry that is bundled into CRC is exposed.  You can find the route in the admin console.  The name is default-route-openshift-image-registry.apps-crc.testing.
  2. I had to figure out how to establish security with the registry.  That part was easy, in the admin console you can click on your user in the top right corner and have it generate a security token.  Please note - these tokens expire fairly quickly, so you might want to create a service account and get a longer-term token.
<plugin>
  <groupId>com.google.cloud.tools</groupId>
  <artifactId>jib-maven-plugin</artifactId>
  <version>2.4.0</version>
  <configuration>
    <allowInsecureRegistries>true</allowInsecureRegistries>
    <from>
      <auth>
<username>kubeadmin</username>
<password>*****</password>
      </auth>  
              <image>default-route-openshift-image-registry.apps-crc.testing/openshift/openjdk-11-rhel8@sha256:5c1bb0a3e2b5ce9018e990dfef68fd040e8584975d05eee109ee4f3daf0366e1</image>
      </from>
      <to>
<auth>
  <username>kubeadmin</username>
  <password>*****</password>
        </auth>
<image>default-route-openshift-image-registry.apps-crc.testing/jib-test/jib-image:1.0</image>
       </to>
    </configuration>
</plugin>

Deploying the application

After getting the image into the cluster, I thought that deploying it would be the easy part - it was not.  Every time I deployed the service, I would get an ImagePull Error and the pods would fail to start with a security access error.  After multiple attempts I determined that the reason it wasn't working is because I had created the pull secret with the external, rather than the internal name.

To illustrate
when Red Hat's internal build process runs (1), it already knows the necessary secret to both push and pull the image.  And, critical point here, they are known as exactly the same name.  But when I built outside the cluster, the image reference I pushed: default-route-openshift-image-registry.apps-crc.testing/jib-test/jib-image:1.0 was not the reference I needed (2)  internally in the cluster.

To create the pull secret for an internal pull, I had to use a kubectl command like:

kubectl create secret docker-registry jliptak-regcred
--namespace=jib-test
--docker-server=image-registry.openshift-image-registry.svc:5000 
--docker-username=kubeadmin  
 --docker-password=*** 

which uses the internal  rather than the external name.

Once I had the secret generated with the internal registry name, the deployment worked fine.  So if you are using external tools with Red Hat CodeReady Containers, just remember two different rules:
  • If you are building or working outside the cluster, use the ingress/route reference for the registry (standard HTTPS).
  • If you are building, working or pulling inside the cluster, use the direct port 5000 reference for the registry.


Comments

Post a Comment

Popular posts from this blog

Spring Boot native builds when internet downloads are blocked made simple

 No direct access to the internet If you work at a company that controls their software bill of materials, it's quite common to be blocked from directly downloading from: Maven Central Docker hub GitHub (the public parts) Getting the bits Maven Maven is first, because without it, you won't be able to compile your Spring Boot application, let alone move on to turning it into a native docker image. I will be showing changes need to work with artifactory, but you should be able to adapt it to other mirror solutions.  repositories {   maven {     name = "central"     url = "https://artifactory.example.com/central"     credentials {       username = "${project.ext.properties.artifactory_username}"       password = "${project.ext.properties.artifactory_apikey}"     }   } } With this configuration change, you should be able to download your plugins and dependencies, allowing you to compile and ...
Post a Comment
Read more

Kotlin Notebook when you're blocked from Maven Central

 TLDR; If you are blocked getting to maven central when first using Kotlin Notebooks because of company firewalls, you can use a tool like Fiddler Tool to redirect to a different network location. Kotlin Notebooks Kotlin Notebooks are a JDK based environment that brings the Python based Jupyter Notebooks  expressiveness to IntelliJ. From the blog post announcing the plugin, it looks like this: At home, the installation of jar files looked like this: I played around with it at home, but I couldn't use it at work.  Many companies, mine included, do not allow software components to be used when downloaded directly from the internet. In my companies case, we use a product called Artifactory, which allows you to mirror the content from Maven Central while still applying policies like CVE scanning, tracking, etc. The way it should work IntelliJ, as one of the leading IDE's, generally supports this quite well.  In fact, there is a whole setting page dedicated to dealing wi...
Post a Comment
Read more

Active vs. Passive Log4jShell remediation

 Log4jShell  All computer professionals should be aware of the Log4jShell ( CVE-2021-44228 ) and it follow on defects.  There is no shortage of opinions and lessons to be be learned: The difficulty of performing safe interpretation The problems when assumptions are not clearly documented.  I, for one, was completely shocked to find out that a logging system would actually attempt to do variable substitution in an actual message. The difficulty of finding and resolving issues with such a common library that is not provided by an OS package manager. IT'S A LOG4J CHRISTMAS One of my favorite podcasts, Security Now - episode 850 , discussed an analysis by Google regarding the depth of log4j dependencies.  From the show notes : One contributing reason is because Log4j is, more often than not, an indirect dependency. Java libraries are built by writing some code which uses functions from other Java libraries, which are built by writing some code which uses functions f...
Post a Comment
Read more