Testing inside of Kubernetes and Openshift Yegor Maksymchuk, Soft Serve, Ukraine Testing inside of Kubernetes and Openshift

Agenda Radanalytics.io Benefits of Openshift Automation of deployment in Openshift Fabric8-kubernetes-client, XTF, radanalytics-utils as libraries for Java

whoami Yegor Maksymchuk Senior AQC engineer, Soft Serve Ukraine Telegram: @QAStudy.online GitHub: YegorMaksymchuk LinkedIn: ymaksymchuk

Data Science in the Cloud

OSHINKO Why ? Integration with Apache Spark in the Openshift. Usability on UI and API level, it should be easy to use. OSHINKO

Example oc cluster up oc new-project xpdays-demo oc create -f https://radanalytics.io/resources.yaml oc create -f https://radanalytics.io/assets/zeppelin-example/zeppelin-openshift.yaml oc new-app oshinko-webui oshinko create xpdays-spark-cluster oshinko get xpdays-spark-cluster oc new-app --template=$namespace/apache-zeppelin-openshift \ --param=APPLICATION_NAME=apache-zeppelin \ --param=GIT_URI=https://github.com/rimolive/zeppelin-notebooks.git \ --param=ZEPPELIN_INTERPRETERS=md

Problems More than 10 application under test. Tests should not be run, in case bad deployment. All application works in Openshift.

Solutions Possible solutions: Our choice: Bash scripts Java Ansible scripts Jenkins Openshift plugin Java or Python for tests Our choice: Java Fabric8-k8s-client Kubernetes and Openshift Rest API

Kubernetes: Architecture

Kubernetes:POD apiVersion: v1 kind: Pod metadata: name: pod-demo labels: spec: containers: - name: pod-demo image: yemax/pod-demo:1 ports: - containerPort: 8081 Base entity inK8s. It is group of one or more containers with shared storage/network, and a specification for how to run the containers. Containers within a pod share an IP address and port space, and can find each other via localhost.

Kubernetes:Namespace { "kind": "Namespace", "apiVersion": "v1", "metadata": { "name": "development", "labels": { "name": "development" } Namespace - grouping entities, provide shared resources. Not security K8s user see all nemaspace. Node same as workers same as Minions - it vm or physical servers, what managed be k8s master.

Kubernetes: Replica Sets ReplicaSet is the next-generation Replication Controller. The only difference between a ReplicaSet and a Replication Controller right now is the selector support. ReplicaSet supports the new set-based selector requirements as described in the labels user guide whereas a Replication Controller only supports equality-based selector requirements. About labels and selectors, we will talk later when starting with deployment from java code demo.

K8s: Deployment DC - it is main entity what responsible for creation a Replica Set, and include information about what POD should be created by RS.

Kubernetes: Ingress This entity responsible for a connect external traffic to service. It is a Ngenix WebServer with special rule suite. Or An Ingress is a collection of rules that allow inbound connections to reach the cluster services.

Openshift

Openshift

Openshift

s2i-lighttpd/ Dockerfile – This is a standard Dockerfile where we’ll define the builder image Makefile – a helper script for building and testing the builder image test/ run – test script, testing if the builder image works correctly test-app/ – directory for your test application .s2i/bin/ assemble – script responsible for building the application run – script responsible for running the application save-artifacts – script responsible for incremental builds, covered in a future article usage – script responsible for printing the usage of the builder image

Fabric8

Fabric8 Fabric8 maven plugin Fabric8 Platform for Dev\Testing and CI

Fabric8

Fabric8

Useful materials: