This blog post is about an example usage of the awesome tutorial made by Masa Abushamleh at IBM Developer called Secure routes for your microservices on Red Hat OpenShift. I applied the content, with some small modifications, to my existing example application. It’s the same application I used in this blog post Using the internal OpenShift container registry to deploy an application.
This blog post is about some basic thoughts when you going to use a Red Hat OpenShift cluster as a service on IBM Cloud or on any other cloud provider.
When you run a Red Hat OpenShift cluster as a service on IBM Cloud, you should get a basic understanding of the shared responsibilities for that service offering on IBM Cloud or for any other cloud provider.
Continue reading
This cheat sheet is about, how to configure a project in an IBM Cloud Red Hat OpenShift to access the IBM Cloud Container Registry. We use an image pull secret to access container images from IBM Cloud Container Registries. The cheat sheet combines different steps, which are available in the IBM Cloud documentation you find here.
We configure a created project in OpenShift to access two different IBM Cloud Container Registries.
IBM Cloud Account where we instantiated the IBM Cloud Red Hat OpenShift cluster. Let us call this IBM Cloud Account ONE.IBM Cloud Account called IBM Cloud Account TWO. This configuration works like to the configuration for external private registries.The IBM Cloud Red Hat OpenShift cluster is a part of IBM Cloud Account ONE.
The image below shows a simplified architecture overview:
Continue readingNote: The cheat sheet references to source code, which is available in that example GitHub project. In case you want to follow the steps, you can clone the GitHub project to your local computer.
This blog post addresses the topic, how to use environment variables to make a containerized Vue.js frontend application more flexible. We will touch following technologies Vue.js, NGINX, JavaScript, Dockerfile and Code Engine.
When you run a containerized application on a container orchestration platform like Kubernetes, Open Shift or on a serverless frameworks like Knative or Code Engine or other platforms, it’s helpful to pass endpoints to other applications to the containerized application by using environment variables. When the container will be restarted, these variables can be provided to the container and no adjustment in the source code is necessary. You can use configmaps or in Code Engine simply the environment variable itself.
The example source code you find in this workshop.
In addition, it’s useful when you take a look into this awesome blog post: Externalise and Configure Frontend Environment Variables on Kubernetes which was used for the starting point for the configuration.
Continue reading
This blog post addresses the topic, how to use environment variables to make a containized Quarkus application more flexible. We will touch following technologies Quarkus, OpenJ9 Java runtime, MicroProfile, Dockerfile definition and Code Engine.
When you run a containerized application on a container orchestration platform like Kubernetes, Open Shift or with a serverless framework like Knative or Code Engine or on other platforms, it is helpful to pass endpoints to other applications to the containerized application by using environment variables. When the container will be restarted, these variables can be provided to the container and no adjustment in the source code is necessary. You can use configmaps or in Code Engine simple the environment variable itself.
We will follow along an application example for the implementation and the example source code you find in the Get started to deploy a Java Microservices application to Code Engine workshop. (or the direct link to the used file in the GitHub repository is provided in the blog post itself)
Continue reading
Code Engine is build to create modern, source-centric, containerized, and serverless apps and jobs.
Take a quiz to get started with the Code Engine terminology.
The topic batch jobs is more related to AI and machine learning, and run AI model training temporarily with highly workload, and thats at the moment not so much in my scope.
My starting point with Code Engine was in my YouTube video: Code Engine, Containerized Application, Node-RED Starter Kit and Scale To Zero. With that in mind, from my perspective Code Engine is a very good starting point for smaller containerized applications, because you can precisely control costs with scale to zero. … and by the way, it’s easy of use.
That motivated me to create a simple hands-on workshop, where you are guided to deploy the Cloud Native Starter security example application to Code Engine. The source code of the example application is included to the GitHub project of the workshop. Access the the workshop on IBM Developer.
This blog post does contain the tasks to create a Docker image and upload the image to dockerhub and clean up the image and container on the local machine.
Continue reading
In this blog post I want to point out that I noticed that the IBM Cloud Container Registry is deprecating container builds.
If you don’t know the IBM Cloud Container Registry here are some useful features:
In this blog post I want to show, how to setup a remote development container for a Vue.js application, which isn’t able to run on my local machine, even after the update of Node.js, npm and yarn.
I still get the error which is shown in the following image and it seems this error is related to the installed MacOS version 10.15.5.
To be able to work with the Vue.js project, I use now the remote container development functionality in Visual Studio Code as a workaround . This is very close to my blog post “Run a MicroProfile Microservice on OpenLiberty in a Remote development container in Visual Studio Code”.
You can follow the steps of the setup of the workaround for the “OS X 64-bit with Unsupported runtime (83)” problem.
Ensure you have installed Docker Desktop on your local machine.
Step 1: Install the following extensions in Visual Studio Code
Step 2: Open in your Visual Studio Code workspace the remote containers extension window (“Open a remote window“)
Step 3: Start “Remote Containers: Add Development Container Configuration Files …” and select a container as a starting point, here I use the Node 14 container definition (you can customize the “Dockerfile” to your needs). The container configuration in the Dockerfile contains Node.js, npm and yarn , which I need for the Vue.js development.
The gif below shows the steps.
Step 4: Verify the newly created folder “.devcontainer” and related files “devcontainer.json” and “Dockerfile”.
Step 5: I my case I only need to customize the “devcontainer.json” file to expose the port 8080, to access my Vue.js application in a local browser.
Step 6: Now open the local folder with “Remote Containers: Open Folder in container” in the remote development container. That will map the local folder as volume to the remote development container and code changes will be saved on your local file system and start the Vue.js development.
In the gif you see:
I hope this was useful for you and let’s see what’s next?
Greetings,
Thomas
#Docker, #Container, #Vuejs, #VisualStudioCode, #RemoteDevelopment
In this blog post I want to point out a simple topic: How to run a simple PostgreSQL Docker image as a non-productive container in OpenShift? As you maybe know, OpenShift doesn’t allow by default to run container images as root.
The image below shows the result of the simply deployed postgreSQL image from dockerhub.
It’s possible to enable images to run as root on OpenShift, that’s documented in the OpenShift documentation here, by adding a service account.
But, in this blog post we choose an alternative way, where we don’t change the security in OpenShift, here we will customize the postgreSQL Docker image a bit. We will follow the steps to create a postgreSQL database on OpenShift, along the creation of the database called postgreSQL database-articles for the Cloud Native Starter reactive example .
These are the major steps:
Thomas Suedbroecker's Blog 