Introduction
Kubernetes is around for almost 7 years now! Ever since the beggining there have been efforts to make consuming / binding to services simpler. And while discovering the actual service is not so much of an issue (if you employ a set of conventions), getting the credentials etc is slightly trickier.
The Service Catalog has been an effort that promised to simplify provisioning and binding to services, but it seems that it has lost its momentum. The lack of uniformity between providers, the differences in how each service communicated the binding information and the fact that people tend to favor operators for provisioning services made it pretty hard to use in practice.
Prologue
ap4k is a collection of java annotations and processors for generating, customizing and testing kubernetes and openshift manifests.
The idea of using java annotations for customizing kubernetes and openshift manifests is not something entirely new. In 2015 fabric8 provided an artifact called `kubernetes-generator` (not to be confused with other generators under the fabric8 umbrella) that allowed developers to hook into the compilation process code that customized these manifests. The way the code was hooked into the compilation processors was via java annotations. The idea was nice but did required developers to write actual code, and thus was soon abandoned as in favor of the fabric8-maven-plugin which was rewritten at the same time by Rolland Huss.
Introduction
This is the second post in my series about the service catalog. If you haven’t done already please read the first post: service catalog: introduction.
In this second post I’ll create from scratch a spring boot application that exposes a JPA crud via rest. This application will use a service catalog managed microsoft sql server database and I will demonstrate how you can automagically connect to it using the service catalog connector.
The spring cloud connector
There is a spring cloud project called spring cloud connectors. This project is all about connecting to cloud managed services. I have been working on an implementation specific to the service catalog. The idea is that you can use the service catalog to manage the services and use the service catalog connector to transparently connect to it.
Overview
This is the first of a series of posts around the service catalog. The end goal is to demonstrate how the service catalog can simplify building apps on kubernetes and openshift.
The first part will cover:
- why
- how to install
- how to use
The target environment will be openshift 3.10 on Linux using `oc cluster up` for development purposes.
Introduction
Working with kubernetes since its early days, there are countless of times where I had to go into creating manifests for the services my application is using. By services I am referring to things like databases, messaging systems, or any other pieces of third party software my application might need.
Intro
During the summer I had the chance to play a little bit with Jenkins inside Kubernetes. More specifically I wanted to see what’s the best way to get the Docker Workflow Plugin running. So, the idea was to have a Pod running Jenkins and use it to run builds that are defined using Docker Workflow Plugin. After a lot of reading and a lot more experimenting I found out that there are many ways of doing this, with different pros and different cons each. This post goes through all the available options. More specifically: