An easy installation guide
Background
IBM Cloud Private is a Kubernetes-based platform that runs on your infrastructure. It can be used for managing a rich catalog of IBM applications, as well as for hosting your own internal apps.
This tutorial will teach you how to install IBM Cloud Private 2.1.0 - Community Edition on RHEL 7.4
Requirements
The infrastructure for your Kubernetes cluster must be created prior to following this guide. At minimum a master and single worker node are required. The machine specs used for testing are below. A minimum of 151 GB of disk space on the master node is recommended.
Master Node — 4 CPUs, 8 GB RAM, 80 GB disk, public/accessable IP
Worker Node(s) — 2 CPUs, 4 GB RAM, 40 GB…
A guide for IBM Cloud Private 1.2.0
Background
IBM Cloud private
IBM Cloud Private is a Kubernetes based platform that provides an integrated and private PaaS cloud platform for running on-premises enterprise workloads. The platform has three main use cases:
- Developing and running production cloud native applications in a private cloud
- Securely integrating and using data and services from sources external to the private cloud
- Refactoring and modernizing heritage enterprise applications
For more information about IBM Cloud Private, see its official announcement page.
Istio
Istio is an encrypted service network mesh for microservices. Istio runs within Kubernetes, and its use requires no changes to the application code. Istio can manage traffic flows between microservices, enforce access policies, and aggregate telemetry data. …
Service accounts and namespaces allow you to limit pod and user permission in Kubernetes. Audit logs provide insight into what accounts are accessing what resources. Learn how to use these Kubernetes features!
Prerequisites:
Overview
In this walkthrough, you create a namespace and add 2 service accounts, each with its own role, to it. One account can read secrets, Kubernetes objects that store sensitive information, and the other cannot. Each of these service accounts is attached to its own pod. Both of these pods run the same container image. At run time, secrets are read from within the container by using a curl command. The authorization to access the secret is determined by an API token that is mounted within the container. This token is generated by using the pod’s service account name. …
Binding Services Without Hassle
Background
We will discuss 3 scenarios: Your NodeJS app is using Watson services exclusively, your app is already using the vcap_services library, and your app is not currently using the vcap_services library. This post assumes you have a basic familiarity with NodeJS, Bluemix, and Kubernetes.
UPDATE: Due to some changes to the vcap_services library, fuzzy matching when specifying only the service name is no longer supported. As a result, for scenario 2 & 3 you should specify the <service_instance_name>. Scenario 1 can be handled as described in the linked article. …
About
