Red Hat OpenShift London 2019 | OpenShift Commons Gathering, 5 Feb 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: London OpenShift Commons Gathering 2019 OpenShift at BIX Michael Sauter Boehringer Ingelheim

Description

London OpenShift Commons Gathering 2019 OpenShift at BIX
Michael Sauter
Boehringer Ingelheim

A

There we go all right, we're back on customer use cases and really excited to have a new open ship, Commons. Member and new to me case study around open shift on OpenShift dedicated and Michael Sauter from BICS and he'll. Explain what VIX stands for and take it away and there'll be a little we're gonna get a little room at the end for a little Q&A with him. Probably so,.

B

Yeah, this Biggs is actually BRX slightly different, so yeah, my name is Michael Sata I work for VX as a back-end engineer and you've probably never heard what bi X is so VIX is if this works.

B

No not happening yeah I'm using the error.

B

Or I'll just use the arrows.

B

On and off again not this time, I guess all you see is that's a no words. So what is bi X BX is very engli, Himes digital lab and for those who also haven't heard of growing English I'm bi is one of the largest pharmaceutical companies worldwide and we had bi X. We use digital innovation to accelerate the development of Health, mint of health care cures and also the discovery of breakthrough treatments. So we use openshift as a platform where we deploy our services to as additional lab.

B

We regularly start new initiatives, so it means we regularly work on new products that has something to do with health and digital and we also hand over successful ones to the large organization and in that regard, openshift is quite crucial to us, because when we develop the initial prototype we can use OpenShift as a platform to develop our applications against and then later on, we can transfer those applications into the wider organization using the same underlying platform, and while the lab runs on a different cluster, then later on running the organization, it's still the same platform and it's very easy to transfer.

B

B

Hey I agree to whatever I am agreeing.

B

Probably, okay and I want to focus a little bit about what these initiatives are and how their life is, how we develop on those- and this will also be somewhat related to the previous talk about open source and enterprise, because we had VIX and digital labs. We have a little bit more freedom and we actually use a lot of open source technology and are also contributors to open source. So everything that you will see what I'm going to talk about today is actually also open source.

B

So when the initiative starts, the goal is obviously to develop the MVP as fast as possible. However, there are many boring tasks that are in the way, so every initiative will have the same requirements roughly that have nothing to do with what the product is actually about right. The product might be very exciting, AI technology whatever, but for the team that works on this, you still need the same set up, so you need something for team collaboration use, for example, JIRA confluence. You need to set those up for the team, then infrastructure.

B

Yes, we use open shift as a platform, but just the platform itself is not enough right. You need various environments where you have your development, your staging and so on. You also need to think about CI NCD. How do you build your software? How do you test your code? How do you scan code? How do you analyze code? How do you deploy to open ship, and also many of those initiatives, will work with the same primitives? So, for example, you might want a springboard application or a node application, an angular front-end, an ionic app.

B

These boiler plates are always the same and going even a bit further than boiler plates. You might even want the same components so, for example, user authentication right we want to have the user service people can authenticate. We want to try out our idea quickly and not work on the user authentication in every team, so.

B

When the start of initiative, you have a lot of tasks that are very boring and very repetitive. None of them provide any value to the user and it's important ly. The team should not have to reinvent the wheel.

B

So if you solve things once in a team, why should the next team have to solve the same problem again if they start from scratch, and we need some form of standardization so within the digital app to know what other teams are working on and be able to help out and have the same understanding, but also if you want to do a successful handover, if every project that you want to hand over is a snowflake that the light large organization has to take over they're not going to be happy so to solve those issues, we build our own desk leg around openshift, so openshift is kind of the the platform we are building on, but many things are not not a given in openshift.

B

They is not prescribed how your process looks like how your pipelines look like, and so the desig we build around. It solves those issues, and this is not only our deficit againi, more, it's open source. That's why we call it the open, def stack and it allows you to set up required infrastructure and continue delivery processes for new projects in less than five minutes. So it's kind of an opinionated way to develop your applications.

B

Let's step a bit through what you get with open, devstack, to show you a little bit what it gives you. So one part is that you can provision a new project. A new project for us means you'll, get a confluence into your space set up. You will get a company bid packet project set up, you get openshift environments, so initially you get two for development and staging, and you can add more as you go, and every initiative also gets their own CI CD set up.

B

So you get your own Jenkins instance, and if you side things around that which I'll get to later so with this set up, a ninja's initiative is ready to go. There is no code, yet there's no application yet, but you basically have the space in which you can operate and once you provisioned a new project, you can then go on and provision components so components.

B

Also you can provision them with one-click. Basically, you pick from a list of quick starters. We call new quick status, so this again might be a spring boot application or a proxy or a mobile application, and this will provision you a repository with some boilerplate, that the developer then is ready to start developing. You also get openshift resources so, for example, for spring boot application you would get an image stream, a buildconfig service deployment configure route, so everything will be connected and set up for you after provisioning, and you also get a CI LCD pipeline.

B

So with this provisioning you it can build the code, it analyzes the code and applies the code. So basically, after you click provisioning, everything is fully auto deployed until in the in the development or staging environment, let's but deeper into what open deaf psyche is made out of if it's basically four different components. So we have a core. There are certain things that the other parts need, for example, based images and so on. There is also setup of the atlantean products, so JIRA confluence. There is a central Nexus to store artifacts in OpenShift.

B

There is also a central sonar cube server for code analysis that each initiative can use. Then, next to the core, there is the provisioning app. This enables users to provision new projects and quick status within those projects. The provisioning app itself is kind of an example using the same process. It's actually made out of the same quick starter and it runs within open ship. So it's kind of eat your own dog food uses the same pipelines to go a bit more into detail. What those quick starters are, quick starters, are sort of skeleton apps.

B

The basics would be, for example, for spring. Would you have a you run a CLI and you get a spring good application, but it also does some modifications to make it actually run on openshift. The quick starter has also the information on how to build that project. So there will be Jenkins agent images that the Jenkins pipeline can use. There is a Champions file which describes how to build and deploy this application.

B

It also delivers how to run the application, so the the docker file, the deployment config and so on, and it sets up openshift resources. And finally, there is Jenkins shared library, so this Jenkins allows you to have to import a shared library into your pipeline, and that allows you to extract generic tasks. You need to do in your pipeline, so, for example, the shared library checks out code. It selects which environment to deploy to it also does a bit of integration. So, for example, it communicates bill status with bitbucket.

B

It does a code scan before deploying and it also builds starts the OpenShift builds and the deployment to have a bit of an example. Here on the left-hand side, you see an example of a chanc, it's file that is provisioned. It calls a custom.

B

Function from from the shared library ODS pipeline, where you've, where you reference an image, an agent image that comes with a quick starter, it maps branches to environments. So you can say, for example, where the master environment, master branch should go to test and all other branches should go to def. You can set this up whatever you want, and then you can see the stages that the quick starter will do by default.

B

So the thing looks very much like a normal champions file, just that you can define some stages yourself and other stages, you just reference. So, for example, in this case this is a Java project, so it builds with Gradle. The shared library does not know how to build Java projects as such, but it knows, for example, the next step. How do you scan and put that to sonarqube?

B

Because that's the same for any type of application, then it starts the open chef builds and will deploy it to open ship starting the open ship built means triggering the build config which references the docker file in the same repository, and this is an example of very simple how a default application could run.

B

Now. There are a few nice things in open devstack, which are not part of a default setup. One thing, for example, is we call the Vepr proxy openshift has a integration with jenkins, so you can create a pipeline and openshift that will be mirrored in Jenkins, but it is a bit tricky to have basically one pipeline per branch, which is what we wanted. So the workflow is that you push co2 to bitbucket. Then bit package will trigger a webhook triggering the build config in OpenShift right.

B

But then you already have some preset build config and you don't know how many you will need and we don't want the application developers to set up their own pipelines. So, instead of triggering the buildconfig directly, we trigger a backup proxy and then this replica proxy deals with creates pipelines on the fly and removes them as needed. So with that, you get one pipeline per branch, and this is quite nice for the for the build history and to keep things separate.

B

We've also built in an ad hoc cloning of environments via Jenkins. So, for example, you can say that for in JIRA I have user stories and for all my user stories, I want to spin up a separate review environment that is cloned from my normal deaf environment. I want to have the same openshift resources, but I want them separately under a separate URL. So what you can do is you can instruct Jenkins to basically say ok for this particularly user story that I am receiving.

B

Is there already an environment that matches to this user story in openshift? If not it automatically clones an existing environment and then deploys to the new environment.

B

Then there are, of course, many small things that open tastic provides, for example, that all the creek starters are configured to pull that dependencies via Nexus. So I just use this as an example to to say that often, if you just provide a nexus instance, it doesn't mean that everyone uses them right, but if you make sure that all the boilerplates people are start with are already correctly configured, then those things actually used and then the open def stack also comes with a few migration scripts to move projects from one cluster to another.

B

So since the lab starts out in a different cluster need to move the project to an in-house cluster or if we're working with sensitive data, things also need to move between clusters. So that's also part of open testing.

B

Now I want to take a little bit of a detour and talk about one particular thing we built into opened a stack or a problem we faced and the solution we came up with, and this problem is basically around how our resource is set up. So I talked about that we have a sonarqube instance or Nexus. So if users want to install the DEF stack in their own openshift cluster, how do you actually set up those things? So, as many of you know, I guess there are ways to do this. You have it.

B

You have templates, you have a manifest that you can bring up, so this is kind of solved, but afterwards so say you have an instance deployed then later on, a new version of open desta comes around and you want to see what has changed. What is the difference between what the new version is and what is running in my hosta? What is the drift? How do I detect that drift and how do you I review what the difference is?

B

And, finally, once you know what the drift is between two different classes, two different configurations: how do I sync them back up and we didn't find a solution that was very easy to use. It's still based on the open chef templates and that is very low entry. Basically, so we developed a small tool on top of the OC commands, which does that I call this as basically a terraform for open shift, as most people know, terraform.

B

Of course, terraform has varied as a lot of providers it. It doesn't have like a nice open shift target so to say where you can manage your deployment, configure your build config via code, so this I think is partly because there is some weird mixture between config and state in the resources in open chef. So this tailor is standard tool. We use it a lot in open des X.

B

So basically, when you install open devstack, you setup all the infrastructure on open shift with this tool and when new versions come around, you can update with this tool. How it works is pretty simple. So first you get the desired state. This is what is in your templates, so your OpenShift templates, we use OC process to process them with parameters and then compare the desired state with a current state, which is an export from your cluster. You compare that. You get the drift.

B

You can see this as textual diff, so people can review what the differences are. For example, you add some new environment variables to your deployment. Config and tailor can then generate chase and patches from that and pass these chase patches to apply those updates. This is crucial because the standard or C apply, for example, does not. It does not delete configuration there. So, for example, if you want to change the deployment strategy of a deployment config, you cannot do that with a OC apply, because it will not delete the other deployment strategy.

B

So you will need to use OC patch and Aussie patch is tricky to use. If you don't have a tool that generates those patches for you, because you need to alright them by hand. So Taylor does that by himself it figures out what to do and does that so yet, as I said, a standalone tool. So if you want to do something like that, that's pretty cool too also. We can manage your whole resources that way and it's a very low entry, because you still use the standard openshift templates.

B

There is no need for a different tool.

B

So with that a little summary, so with open devstack, you can focus on the development, not the process. It is extremely fast ramp up time. So if you had lots of projects or initiatives in your organization, it's a nice tool have that we try with it to solve one the problems once for all the teams.

B

So if there is some kind of glitch we solve it once and open def stick tries integrate tools very tightly so, for example, integration between open Geoff, Jenkins and big packet I think it's very nice that you don't get out of the box and all of that what I described is completely open source. So at github calm, slash opened s Tech and we basically run our dev sick. Just based on that.

B

A

So that's the second new open source project that I've learned about today. The first one was the Tremeloes Orchestra orchestra and your open devstack podesta.

B

So it is possible to.

A

Contribute back it.

B

Is possible yes, so we made through this dance of what was previously described of, can we contribute and what? What will that mean and so on, but it is possible. So if you have any questions, let me know afterwards or on Twitter all.

A

Right, yeah or when.

B

We're having beer this evening.