In a previous blog, I explained how to provision a new Kubernetes environment locally on physical or virtual machines, as well as remotely in the Oracle Public Cloud. In this workshop, I am going to show how to get started by deploying and running a Hello World NodeJS application into it.
There are a few moving parts involved in this exercise:
- Using an Ubuntu Vagrant box, I’ll ask you to git clone a “Hello World NodeJS App”. It will come with its Dockerfile to be easily imaged/containerised.
- Then, you will Docker build your app and push the image into Docker Hub.
- Finally, I’ll ask you to go into your Kubernetes cluster, git clone a repo with a sample Pod definition and run it on your Kubernetes cluster.
Continue reading “Teaching How to Get started with Kubernetes deploying a Hello World App”
This time last year, people were excited talking about technologies such as Mesos or Docker Swarm to orchestrate their Docker containers. Now days (April 2018) almost everybody is talking about Kubernetes instead. This proves how quickly technology is moving, but also it shows that Kubernetes has been endorsed and backed up by the Cloud Giants, including AWS, Oracle, Azure, (obviously Google), etc.
At this point, I don’t see Kubernetes going anywhere in the coming years. On the contrary, I strongly believe that it is going to become the default way to dockerise environments, especially now that it is becoming a PaaS offering with different cloud providers, e.g. Oracle Containers. This is giving the extra push to easily operate in enterprise mission critical solutions, having the backup of a big Cloud Vendor.
Continue reading “Teaching How to quickly provision a Dev Kubernetes Environment locally or in Oracle Cloud”
Much has been written on RedThunder.blog about the Oracle API Platform Cloud Service. In this blog, I am going to get into the advanced topic of Custom Policies. You would start exploring this area when the built-in policies do not cover your use case. The power and ease of implementing Custom Policies, I believe, is a killer value proposition of this platform.
Before we proceed, it would helpful to understand the backend technology of what the API Platform is built on. API Platform built-on the heritage of the sturdy and scalable WebLogic server.
There are 3 components:
- Management Portal – Used to create and manage APIs. This is an application hosted in WebLogic server, utilising WebLogic for clustering and scaling. Oracle hosts and manages this in our Public Cloud and automates the whole installation process, so you just have a make a few clicks to provision it. The Management Portal is the brains of the API Platform, registering Gateways and deploying and publishing APIs to the Gateways and Developer Portal. You can access all its functions through REST API.
- Gateway Node – Holds the run-time of the API. This is based on the Oracle Communications Service Gatekeeper (OCSG) from our telco-grade suite of products. Built-on WebLogic, the Gateway Nodes can be installed on any platform on-premise or in the Cloud (e.g. Amazon, Azure, Oracle). It is packaged as a zip file downloaded from the Management Portal itself. Once installed, the Gateway calls home to the Management Server to register itself. It pulls APIs and the policies associated with it from the Cloud once they are deployed. Gateways forms a logical cluster for HA purposes, so you deploy once and the APIs propagate to all the nodes in the cluster.
The Gateway Install zip also hosts the necessary code nuggets for customisation.
- Developer Portal – Used for developers to review documentation and subscribe to APIs. Also an application, this is by default hosted in the same WebLogic Server as the Management Portal. If you wish to run another Developer Portal, let’s say on-premise or customise it, you can extract the Developer Portal war from the Gateway Server install zip and host it in another WebLogic server.
Now coming to Custom Policies, they are essentially Java-code packaged as war files. The Gateway Install zip holds the code nuggets necessary to generate a Policy Stub. It also holds the necessary libraries aka Policy SDK (matching the version of the Gateway server) to compile against.
Continue reading “Creating Custom Policies for Oracle API Platform Cloud Service”
Much has been written on the design of ideal REST APIs, from Roy Fielding’s original description of HATEOAS interfaces, to much more practical approaches mirroring APIs rolled out by large technology companies. When working alone, I have a lot of freedom in how I design and build my APIs, and I always strive to design APIs which I would love to consume, based upon a number of undocumented, but strongly-held design intuitions. Collections are plurals; sub-objects are used sparingly, and mostly for practical considerations like payload size; HTTP status codes are used appropriately for particular types of errors and responses; etc.
When I work as part of a larger team, I often find that we end up building interfaces with slight inconsistencies, even if the design of them was based upon some documented high-level design principles. These inconsistencies impact the productivity of both internal and external developers which have to use these APIs, as they have to carefully parse the documentation to develop around the ‘quirks’ of the individual APIs.
Ironing out these inconsistencies can be achieved in a couple of ways, adopting a waterfall-style development model, in which each team is required to submit their detailed design specifications to an architecture council for review and sign-off; or putting a system in place which checks new API designs for consistency, and provides real-time feedback to API designers as they sketch out the interface. Oddly enough, the approach that I am going to discuss in this blog post is not the former; instead we are going to explore the Style Guide capabilities offered by Apiary.io, which allows us to develop rules governing API styles, which are assessed in real-time during API design.
Continue reading “API Design Governance – Style Guides in Apiary”
Oracle Identity Cloud Service (IDCS) protects Oracle IaaS, PaaS, SaaS and On-Premises applications. Oracle IDCS provides federated single-sign on experience to its clients. It follows open standards such as SAML 2.0, OAuth 2.0 and OpenID Connect 1.0. In the federation model, Oracle IDCS can either act as an Identity Provider (IdP) or a Service Provider (SP) or both.
Oracle IDCS has a built-in feature that provides multiple social identity providers such as Google, Facebook, LinkedIn and Twitter. It uses underlying OAuth 2.0 protocol to interact with the Social Identity providers. This article presents how to configure IDCS to allow for Social Logins. Let me explain this concept with the sequence diagram below:
Continue reading “Oracle Cloud Security is Openly Social”
Sometimes you just want to build a local environment on your own equipment simply because it’s quick and easy. But you soon realise that other people need access and resources get a bit tight (memory, CPU, etc). That’s when it makes sense to move it from your place into the cloud.
Just recently I realised how useful Oracle Virtual Box’s new export feature is for migrating local VMs into Oracle Public Cloud Infrastructure – Compute Classic. Oracle Virtual Box’s new export formats give me the ability to easily migrate Images to the Oracle Public Cloud where I can scale my environments as required.
Earlier this week I was building a new Oracle Identity and Access Management development environment on my laptop. This worked well from an initial build and configure perspective but there comes a time when I need to make this environment available to my Developers, Testers and other stakeholders. Running this image continuously on my laptop quickly becomes impractical even for development teams.
Continue reading “Your Place or Ours”