This blog post is about using the domain mapping functionality in IBM Cloud Code Engine to use custom domains and TLS certificates for your applications. The source code related to an example setup is in the GitHub project example WebApp build on Vue.js. But now we are going to use a wild card certificate for our domain *.example.com. With a TLS certificate for that domain.
Run Watson NLP for Embed on IBM Cloud Code Engine
This blog post is about using the IBM Watson Natural Language Processing Library for Embed on IBM Cloud Code Engine and is related to my blog post Run Watson NLP for Embed on your local computer with Docker. IBM Cloud Code Engine is a fully managed, serverless platform where you can run container images or batch jobs.
Open the door wide open for Watson Assistant with “custom extensions” – an awesome progression
IBM Watson Assistant is a SaaS offering from IBM to build conversational assistants. IBM Watson Assistant is using artificial intelligence which helps to understand users in context, to provide them easy and fast, consistent, and accurate answers across various applications, devices, or channels. IBM Watson Assistant is built on natural language understanding (NLU), natural language processing (NLP) and machine learning (ML). The first version was already very good, and IBM clients and partners were starting to take these advantages; for example Watson Assistant was used at the International Space Station. Here you can find some more details: CIMON brings AI to the International Space Station. Based on the feedback from clients, the IBM development and design team has created a brand new experience and added new functionalities to the service for example they expanded the integration possibilities with extensions. In this blog post I focus especially on custom extensions development and setup.
Open the door for root users in Red Hat OpenShift (example StatefulSet)
This "blog post"/"cheat sheet" is about "Open the door for root users in OpenShift (example StatefulSet)". The topic is in context of two blog posts I wrote called Run a PostgreSQL container as a non-root user in OpenShift and Open the door for root users in Red Hat OpenShift¶.
Open the door for root users in Red Hat OpenShift (example Deployment)¶
This "blog post"/"cheat sheet" is about "Open the door for root users in OpenShift". The topic is in context of an older blog post I wrote called Run a PostgreSQL container as a non-root user in OpenShift. Let's look for the opposite perspective this blog post.
Using the internal OpenShift container registry to deploy an application
This cheat sheet is an extension to a blog post I made which is called: Configure a project in an IBM Cloud Red Hat OpenShift cluster to access the IBM Cloud Container Registry . In that related blog post we used the IBM Cloud Container registry to get the container images to run our example application. Now in this cheat sheet we will use the Red Hat OpenShift internal container registry and the Docker build strategy to deploy the same example application to OpenShift.
Configure a project in an IBM Cloud Red Hat OpenShift cluster to access the IBM Cloud Container Registry
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.
10 Hours of Live Recordings, which are built on Experience, about Application Security
It’s awesome we just created 10 hours of live recordings, which are built on experience, about application security. That learning journey was made by the IBM Developer Hybrid Cloud Build Team from IBM and I am a part of that team. We put together great content for you. By the way, I was responsible for the content ;-). I also has been the moderator for most of the sessions and I also gave sessions by myself. The learning journey is called #ApplicationSecurityLearningJourney.
Use environment variables to make a containerized Vue.js frontend application more flexible and deploy it to Code Engine
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.
How to use environment variables to make a containerized Quarkus application more flexible
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.