 Welcome. My name is Craig Peters and I'm a product manager at JFrog. I'm here to talk to you about how you can work with OpenShift and understand what a Kubernetes registry means. So first just a couple of words about myself. You can follow me on the social media, you can follow me as an athlete, whatever you like. I'm a cyclist. That's what I love to do when I'm not playing with computers. When I am playing with computers I spend a ton of time these days building cloud native apps for Kubernetes and playing with all of the different distributions of Kubernetes most recently with OpenShift. So today I'm here to talk to you about a few things. First I want to introduce you to who is JFrog as a company and why are we relevant in the space? Why would anybody care about what is JFrog? Then I'll talk about the notion of a Kubernetes registry and how that relates to package management. And lastly I'll share a demo. We're going to do a Node.js application. We're going to use the OpenShift S2i to build that and use the capabilities of JFrog to detect issues in that application to block its build and deployment so that you know so that you don't put unsafe apps into production in your environment and that's what a Kubernetes registry can help you do. So first about JFrog our vision is to enable software organizations to ship their software safely and reliably to any kind of environment. So our target can be OpenShift, our target can be traditional application stacks, LAMP, what have you. The reason we do that is that we believe that automating the build and delivery of software is what helps us go fast and go safe. We believe that software updates should flow and we have a lot of evidence to show that a lot of people believe this as well. So we have a very large customer base. We have customers all across many many industries, everything from big internet and service providers all the way through engineering, research, aerospace, education and so forth. So we've got a lot of downloads. We have a big support of the open source community. So if you have an open source project you can actually use our software as a service. You can sign up on our website and so with that let me get started explaining what it is that we are talking about when we talk about repository management. Well repositories are the way that you manage the artifacts. The artifacts are actually the assets of a software enterprise. So you've got kind of two major assets. You've got your source code. The source code describes the sort of first-party information that you're building into your applications but then you also have any dependencies. So in fact if you look at the software that you're delivering into your applications it it varies anywhere from sort of 50% software that you wrote to 10% software you wrote and the rest of it it can be even less but the rest of it are dependencies. They can be dependencies on open source libraries which is very common in this sphere to dependencies on commercial attributes and commercial packages that you've acquired. So the question in big enterprises is where do we put those assets? How do we manage those? And what happens is in big enterprises they have to be very careful about what software they run in which environments. That means that you create very tight constraints over what packages can go where and you end up building sort of bespoke systems for each kind of package. So I have my system for managing my Maven artifacts. I'll have a Maven repo that maybe mirrors Maven Central and then I'll have another mirror for NPM and what that does is that creates a management overhead. What that means is that every time somebody wants to take on a new tool or use a new CI system they have to create a new way to manage those kinds of packages inside their enterprise with enforcing all of the policies around restrictor access control storage management audit ability and all of that. That is a massive cost for teams that are you're paying them to deliver software fast and to be innovative that you don't want to block people who want to use some new language from doing that by you know making them wait three months until you get the right infrastructure in place. So that's that's the problem that we are trying to help solve. We do that through a suite of tools. So the core thing that I would say how many of you know Artifactory but there's a very small audience so it's not a very interesting question. Artifactory is kind of the core of the system. It's the repository manager platform. It sits on top of an infrastructure that does distributed access control across very highly distributed organizations. You can do hybrid cloud applications with common role-based access control on-prem and off-prem. Xray then provides you the ability to have deep insight into what are in your packages. Since this is most of your application they're actually running in production it's actually pretty interesting to know whether or not there's a vulnerability in a third-party library that you depend upon. You have a management plane on top of that that helps you configure this infrastructure for deploying and distributing applications across both on-prem and off-prem applications and then Bintray is the piece that enables a CDN to act like a repository. So you can make a remote repo that's a Docker registry and that's what Bintray does. It layers that on top of a CDN so you have efficient distribution of binaries. So this provides this fills in the gap from your source code control and allows you to have flexibility for any automation tool to any deployment target and here what we're going to look at is how we're deploying on to OpenShift as a Kubernetes cluster. So taking a step back if we talk about the full software development lifecycle, Artifactory, and JFart products provide key values around the asset management for packages at many points of the software development lifecycle. So you do your planning we don't really have a role to play there and thinking about what it is you want to do there's other tools for that but when you're actually building your code that's where those assets go. Then we in the testing and release phases we give you all the metadata you need to understand whether or not something's ready to promote from one stage to the next and then in the distribution phase we help you push those binaries to the endpoints where they need to be. So if you have remote data centers where you have to make sure the bits are close to the consumers or IoT applications where you need to push things all the way out to the edge of the network and manage them as packages, Bintray provides that as a service. So that brings me to the notion of what is a Kubernetes registry. So OpenShift provides this really powerful tool for both doing application development and operations of applications on Kubernetes. It's a very powerful system. It doesn't help you know what all your third party dependencies are. So a Kubernetes registry is the notion of using all of this powerful software that I just talked about which allow you to do package management of all of the things that are contained in your application. So if you think about deploying an application to Kubernetes you need three things. You need a Kubernetes cluster, you need a Docker registry and you need some tooling for automated deployment of any updates to those applications to your Kubernetes cluster. The challenge is if you don't know what's in those containers you're exposing yourself and as we talked about before your containers actually contain a little bit of code that you wrote and a lot of code that somebody else wrote whether they're open source projects or commercial packages that you depend upon. So when you use a tool like Artifactory what you get is the ability to have traceability from all the way from your Docker containers all the way back to any dependencies you have on say the RPMs. So in Docker we understand the deep structure of all of the layers in Docker. We can unpack those and identify the contained packages and I'll show that to you in just a minute. So the notion here is that you know you build base image base layer images of the operating system components you depend upon. You bring in the third party components that you depend upon whether they're open source or commercial and often you know if we were trying to stack these like in terms of the proportion of how much of your application they make up usually this is by far the biggest amount of code right here and then the little bit of code you do that provides your core value add as an enterprise or as an application developer you're tying your dependencies together in your application code and then you're taking all of that and putting it in a Docker image putting that in a repository. Then you're deploying it to the the Kubernetes cluster to operate it to OpenShift. So what we do is we provide full traceability forward and back across all of the stacks and now I'll show that to you in a demo. So what I'm going to do is go over to OpenShift let's make sure I'm logged in still. So I have a very simple project here just to show the principles. So in this project it's a it's a stupid little Node.js app that shows our logo and the version right of the package right big deal so that's that's nice. Let's find out what's going on with that application today so I'm going to go look at the builds for that application. I'm trying to ship software fast right I want to make sure that I trust what's in there so if I go in here I notice that the last time this build ran it failed so if I take a look at the history of this I can see that over time is sometimes it succeeds and sometimes it fails. I mean this is a demo system so I know why it failed but let's go find out why right. This particular last build failed if we go take a look at the logs what I'll see is that it gave me an error here it failed to fetch a dependency so my Node.js application so I have the CentOS Node.js app that I built was trying to download it looks like it's an NPM library called ecstatic so why did that fail if I go take a look at that I can see that it's actually trying to go this artifact failed it tried to download it from Artifactory Artifactory said hey this was blocked based on a policy so this policy is configured in x-ray so let's take a look at what that looks like. So if I go over to x-ray x-ray real quickly this is the tool that actually provides me the deep package inspection so I can understand what's in what's contained in what are the hierarchical relationships between all of the contained packages in in my environment it's a service that you run on prom or in the cloud that constantly updates with new vulnerabilities and new license information so you can understand what what you're running and changes and issues from what you're running so we're constantly streaming new vulnerabilities from known vulnerability sources but I'm particularly interested in this component that I was just trying to build so let me log in hold on so I was interested in the Node.js application right the one that I just failed to build so let's take a look in that don't tell me the Internet's are failing me here let's try that again seems like Wi-Fi might be failing us I actually saw that happen for our poor friends before us from Microsoft Azure so ah fantastic we've come back to life so I looked for this component that I built right so this is the one that failed like why was the build failing I can actually get a full report of any issues that are in this this this application so this is actually the application the last time it successfully built this is the security profile of that application so I can see the contained relationship I can see for example that I do have some major violations here well let's find out what where those are so this node this headers container actually has a number of different security issues in it maybe I shouldn't be using that but I can actually see this is the impact analysis I can understand where those issues are present across all the different layers of my application stack so in this case I can see that this npm oh no this is the RPM headers dependency is actually contained in multiple Docker layers I can see which Docker layers those are so I can actually understand the impact of where this RPM dependency is reflected but I'm interested in this case specifically about my ecstatic issue so let's go take a look at the watches here so if I go look at my npm watches a watch is configured to allow me to not necessarily block everything that happens inside my organization I want to set thresholds or policies about what's allowable what what's my sensitivity to risk and what's my tolerance to risk so in a watch let's go take a look at the configuration of this watch so we'll take a look at it it's I'm watching the Artifactory npm remote so in this case this is a way I can govern what kinds of dependencies I'm bringing into my organization so every time somebody uses the npm registry and it pulls in an external dependency that causes this watch to be triggered what does this watch actually do this watch says I have a severity filter so any time I find a major issue or greater in a new npm dependency I'm going to do a block of the download so I can do various different things so the x-ray allows me to have very configurable policies under what conditions for which types of artifacts do I want to do which kinds of actions so in this case I've blocked the download which is helps me understand why I've had that issue so if I go look at the violations here I can see that ecstatic has been blocked right because it is a major if I'd used any of these other types I could also have done that so I can see well that's a do DDOS kind of violation in npm and so here I can see where that is is contained so now I have a deep understanding of why my application wouldn't build so it's really very straightforward I can just go do you know best practice for software development I'm going to go pull that violating dependency right out of my application so let's just delete that sucker out I'm going to go ahead and commit those changes directly to master best practice for software development right so now that I've committed that I can go back into OpenShift let's go look back at the let's go just do a rebuild now and see what happens so I'm rebuilding it let's take a look at let's view this particular build and see what's happening let's take a look at the logs well now I'm not downloading that ecstatic so this is the OpenShift S2I so we've actually built our own image that uses Artifactory as the Kubernetes repository for the OpenShift S2I build so we're actually pulling all of our dependencies dynamically from endpoints in Artifactory and then when we've succeeded with the build we're actually going to push it back in to Artifactory oh we've failed to fetch it did I not merge my change why did that fail jQuery save maybe let's just try to run it again let's rebuild that sucker nope failed to fetch it again I'm not sure what's going on why do I still have a dependency maybe I'm changing the wrong oh I know why because I'm changing my fork of of his no no no I can't explain why right now I'm not going to worry about it what I'm going to do is I'm going to take a step back and say look Artifactory is this layer which allows me to abstract from my storage all the different package types which you depend upon and you can then have a consistent way to manage both local and remote repositories for all of the different package types for which you depend upon as an enterprise and if you want to try this out the best way to do that is to go to our website and get a free trial so we enable you to use the product for 30 days you can use it for all of your functionality it's complete functionality you can run it on any of the major clouds AWS Google or Amazon it works great with OpenShift we have a blog here where you can I can actually if you download it and you do self-manage you can actually deploy it via OpenShift scripts to to your OpenShift cluster and there's a nice blog about that as well so if you have any questions I will be here for those so thank you very much