 So I should never talk into this okay okay hello I'm trying all my check this is like I've got on And we get to ignore those right okay, so don't Would like to ask you to take your seats We will start in a minute So I hope you are ready and full of energy and Excitement for the for the next talk So I think we are Ready guys So please warmly welcome Brian Exelbeard and Navi shake Thank you very much It's great to be here. I want to thank the conference organizers for what they've done It's been fantastic. I hope you all are ready for this. So I'm Brian Exelbeard I work for Red Hat. I work with project atomic I work specifically on the atomic developer bundle with my colleague Who I'll let introduce himself. Hi, this is the beat I work for red hat and I mostly have one atomic developer bundle and it's Connection with the client side tools. I'm from India And I guess I'll add I'm from America But I live here so you can ask all of your check language questions to someone else Because I'm yeah struggling So anyway, we're here to talk about the atomic developer bundle today, but we had a couple of questions first How many people here would describe themselves as mostly on a dev or mostly on the dev side of the equation just by show of hands? Okay, so for those watching the live stream that was about 4,000 people in the audience And how many of you would describe yourselves as mostly on the ops side of the equation and so I'm assuming the other 3,000 people showed up today to find out how computers work Okay, that good love to see that Second question is how many of you work in an environment where a hundred percent of the computers are all running the same operating system? And I'm talking about the desktops or laptops Okay, I want to talk to you guys later because I'm very interested in how that happened So I'm seeing that like 99% of the people here on a mixed development mixed Environment for their local computers and that's good to hear so we're here to talk about the atomic developer bundle and Naveed take it away. Yep. Oh, wait. Sorry. I'm the first love So what's the problem? Well, we're trying to make Linux container development easy That's the goals of project atomic and we want this to be easy for developers of all stripes We want to look at uniform development environments. That's what everybody wants in their organization The problem is that developers tended like diversity They have their own particular setups. They like their own particular tools. They like their own particular builds They like their own particular editors, whatever the case may be So we need to find a balance between what's going to make what comes out of the process great for operations But what goes into the process has the level of feel that's going to make developers productive We want to help developers concentrate on development. We want to help operators concentrate on operations We don't want a lot of people to spend a lot of time doing things across the work where it's not productive work So for example, if you're deploying a new orchestrator for your containers Your developers just need an environment they can dev in they shouldn't spend three weeks learning how to configure an Orchestrator just so that they can get started The other thing is since 99% of us work in environments with mixed operating systems Not all the operating systems support what we're doing in production. You can't run Linux containers natively on Windows and Mac we need to help people out there and We're also seeing that a lot of the tools that have come out in the market to try and solve some of these problems They're not necessarily all open and they're not necessarily all generic in their usability A lot of them have very specific use cases or trying to feed very specific tool chains Yep, so Solution to the problems that we have so we have come up with a platform independent developer environment tool Where a developer who is running on Windows or Mac or Linux should be able to develop on containers So this basically we have come up with a vagrant box Which is platform independence so that developers running on non-linux platform should be able to use these of vagrant boxes this vagrant box to Containize their of them containerize their applications and to be able to to enable them to work on containers So what all things we have in this? Vagrant box so we have pre-configured tools for example different types of Orchestrators like Docker Kubernetes open-shift mesos marathon. This also this box is extensible So this does not this work does not enforce Developer or DevOps to use particular stack for example a stack from a particular vendor like Docker Docker machine It does not Enforce a developer to use particular set of a stack. So a developer is free To choose the orchestrator that developer wants to containerize its application upon and pull the respective box and start hacking so We also we have also come up with the liquid specification visit which is a way to Define your application in a way that your application is Is packaged once and is able to be deployed on the different orchestrator So to demo about the vagrant box or adb we have come up with three different use cases command line with Carla ID Igor and my environment Mike. So Let's start with the demo So command line Carla so Carla wants just a command command line She doesn't want rest and she doesn't want to pollute her machine With the development tools that she's going to configure on this box So in this demo we are going to see a Sample vagrant file which we have in our repository and this vagrant file configures a vagrant box With the Kubernetes So as you can see you can pull in this vagrant file just Have it and do vagrant up So Carla has a vagrant box which is adb and it has Kubernetes pre-configured in it in it now Carla gets gets access to Kubernetes So as we can see the Kubernetes is running here with a single note set up So we have configured Kubernetes with single note set up here master and minion is residing in the same box And we also have we also can we have also configured Docker here So the Docker which is running here is running on local units you unique socket as well as the TCP port so that The color can run the Docker locally as well as from the client from different client like the Docker client from offset The box and using the eclipse So here Carla gets Access to the box Using command line with different tools pre-configured now if Carla wants to Deploy his application and test his application using Kubernetes She does not really need to worry about setting up Kubernetes on the box She just need to do vagrant up and start with start with hacking the second use case that we have is ID Igor so Igor always works on ID so the example that we are going to demo here is of eclipse Igor does not really want to know about that Does not really want to know about the underlying is stuff. That's happening Igor just cares about That this is my application which is in my eclipse and I want to containerize my application So Igor gets and so we have enabled this tooling using different plugins One of the plug-in that we have come up with its name is vagrant even for which is going to be renamed soon So I'll talk about that. So this plug-in this configures Igor's environment and In a way that different client-side tooling can connect to the Docker daemon or different services that are running inside the box So I'll demo point So here all Igor needs to do is get a vagrant file. That's it And since we are using virtual box as a provider via we have configured the private networking Vagrant up Yep, so I already have the vagrant box up and running and I need to execute this plug-in. So I'll show you Plug-in name is vagrant adb info So here as you can see The plug-in is doing doing two things one is first It is copying over this required client-side search for Docker client to connect to the Docker daemon Which is running inside the box because as I mentioned earlier the Docker daemon inside the box is configured to run over TCP And it is protected using the TLS So for any client which wants to connect to Docker daemon inside the box the client need required client-side search So this daemon is doing This plug-in is copying over the search from inside the box to the host machine and displaying that this information These required environment variables are necessary for any client to connect to the daemon inside the box So the last line in the output as you can see if you just Well Evaluate all the environment variables the client should be ready to work So in eclipse we have a docker plug-in which consumes the TCP APIs which implements the TCP APIs and It can connect to a docker daemon So here I have docker explorer, which is a view for connecting to docker daemon and as you can see that all I have to do is Fill in the information so this view can also connect if you have the local docker daemon running on your box You can connect to the daemon using the Unix socket or if since we are connecting to the box ADV box, so we need to input the URI so since the daemon which is running inside the box is Is protected using search so no any so that No any random client should connect to it So that the connection should fail if we if we do not provide the part to The search so the ping now fail, but since if we give the right path of the search as you can see I just bring up the box once again live demos Okay Yep, so we'll move to the next demo. I'm sorry about that live demos We apparently didn't make the correct sacrifices before we started. We are very sorry But we're now really going to tempt fate with the next demo This is my environment Mike and we wanted to show off some cross-platform functionality But we didn't have a Windows machine available. So did you actually screw that in? No Who screws that in? So we brought a Mac instead one second, okay, cool it worked Okay, so what we have done on this Mac is we have downloaded virtual box because that's the supported one of the two Supported hypervisors and the only one supported on Mac We have downloaded vagrant so that we can run the vagrant files And then we've downloaded a set of tools from the upstream Because the community is already producing tools for us. So we've got the Docker client Version 182 in this case for the Mac We have the current open shift actually I think this is a little behind on open shift, but it's the open shift client OC and then we're actually running cube control from Homebrew if you've used the Mac they have a side packaging system called homebrew and cube control is actually packaged So you can just brew install cube control On the Mac, let's find my terminal Is that big enough in the back? perfect, okay, so On this let's take a look at like Docker info So we've got some images and containers already running and part of the reason for that is that I brought up an open shift box Which is why I downloaded the OC client So you can see here for example that I can do a Docker images. I'm not going to bother to run anything in part because The network here is not allowing me to pull images this morning I do not have dot in my path. I am a bad person But I've got some Docker images out there. That's somewhat interesting I can actually run cube control and I think there's a pod running. Oh I'm not allowed to list pods in this particular project. I'm sorry OC Oh, I deleted the project. That's why Let's take a look at the CLI or the OpenShift web demo here I Actually deleted that project. That's kind of embarrassing. So I can prove that OC works By running a new project for you. This is a lot harder when you're holding a mic in one hand So we created a new OpenShift project and again I'm not going to launch anything inside of OpenShift because that requires a pull and we don't actually have network at this conference So as a consequence, I can't actually show you that part But we've got all of the client tools wired in this user does not have to SSH into the box They don't have to deal with the fact that they're running a Linux box if they don't want to they don't have to deal with any of the Connectivity issues everything comes pre-configured including OpenShift So those are our three personas command line Carla ID E Igor and my environment Mike We have a clips so I Missed up with my environment variables. So now I have them here. So as you can see that Here I have a Docker Explorer view and I'm repeating the demo that I did earlier. So here We have to give the name to the connection because you are eclipse Docker to link can connect to multiple Docker clients so we can give the name like DevCon and This is the URL of the vagrant box and two three seven six is the port where Docker demon is running And as you can see that these are the search Where the client required client sets are residing. So we need to provide the direct detection So pink is now succeed. So this is a pink to the Docker demon inside the box from my client and Now here you can browse different containers and images that are inside the box So if you want to pull an image so you can perform all the operations that you are doing from the Command line using the eclipse itself So I can do a poll Finish or network. Come on. It's just one and me Okay so here we have the image and If you want to create a container to fit just right click over the image name run and you have the detailed Options that you can provide to create the container out of image. So here I'm providing this a command eco command and as you can see that There are different options that you can use if you if you want to attach some data volume you environment variables you can just Put in here and if you want to limit the CPU that you want to provide to this container All the all the operations that are available all the options that are available via the command line is now Is in the run container view? explanation Okay, so yeah, yeah, so the output that is being exported by the container inside the box is copied over right to eclipse So so as a demo this is To show showcase the eclipse connection with the adb box Right here. So now the eclipse developer can directly containerize your jbos or Java application right from the eclipse inside the box Yep, so So, how did we how do we make these source? So this vagrant box that we have now support Two different or or kiss two different or provide us one is virtual box and live word and it is also made up with different set of utility scripts and like as I said earlier that the Docker Docker demon is configured for client-side tooling to connect and Oh Kubernetes as well as open shift is there We have a vagrant plug-in for client-side two links and we are using sent us seven as the base OS for our adb box And we are using sent us build system for building this adb boxes and putting them on atlas ashikop so as of now we have five different Five different providers that can run your containers or your application TLS protected Docker demon Kubernetes single note setup mesos marathon Open shift the open shift that we are providing inside the box is running inside the containers So the open shift is configured inside the box is in different set of containers that Together provide the open shift service inside the box. We we have atomic sale in the box so that you can use the atomic sale I and pulling your container images leverage the labels that you have embedded inside your Docker images as well as deploy atomic and the liquid images and the liquid apps We are currently building the box that's on hessie core using sent us and we chose sent us because of its stability The community of users that it has and the fact that it has a special interest group system that allows us to build the box Easily within their environments this box can be built on any distribution So we would encourage people in other areas who are interested in seeing this come out for their distribution of choice to work With us on that we'd love to do that The CIDC says CICD system and sent us will probably begin to be used soon so that we have a master test environment as well So it's what's for dinner? You can actually use it right now You can download it from cloud that sent us org You can also pull it from hessie core using the standard vagrant methodology the client CLIs for your various Non-Linux systems or Linux systems are available upstream. You can get Docker Kubernetes and open shift Obviously if your distribution or operating system packages them, we would encourage you to use those But otherwise go and get the correct versions from the upstream There is I'll if you'll pop back on there is one note You can just type vagrant a knit project atomic slash adb if you're running virtual box You do have to make one modification to the vagrant file Otherwise I'll live vert it runs out of the box But we have sample vagrant files that will bring up cube open shift And Mesa's marathon so you should use those if you want to use those environments Everything is online on github under the projects atomic organization It's in the adb and the vagrant adb info for the plug-in as we've mentioned We are renaming the plug-in and adding some additional functionality, so you'll get a pointer soon for that We do everything in the open on a mailing list on the container tools mailing list It's a mailing list shared by most of project atomic Which allows all of the pieces of the project to stay in touch with what everybody else is doing So I'd encourage you to join we hang out on nula cule and atomic on free node And we have meetings twice a week related to this part of the project We meet an IRC on Mondays and we meet over video conferencing on wins excuse me on Wednesdays. Yes Wednesdays So what's the future like and how can you help us? Well first use it help us find the rough edges help us figure out what your use cases need that we don't think about Join the project give us your input We're looking at more hypervisors. We're always looking at more orchestrators, especially where there's a use case for more orchestrators We're improving the plug-in to have a more service oriented architecture So that we can increase the amount of things that a user can do from outside of the box We are working on some rather big issues right now. We've got some TLS certificate generation problems So if you happen to love TLS, we'd love to talk to you We've got four potential solutions for a late certificate generation issue And if you know something about this, we would like to talk to you As I mentioned, we have a new vagrant plug-in architecture. So if you like writing Ruby, you like writing vagrant plugins There's a space for you here We are looking at doing Docker image caching currently the CBS is being extended to allow that it's not there yet We're gonna want to look at other distribution build systems as well where there's desire for that kind of stuff We're looking at folder synchronization between the local workstation and the vagrant box We want to make sure that whatever we choose is both completely open and has unlimited rights of redistribution So we're looking at alternatives to the traditional hypervisor provided Opportunities there in part because we want to try and maintain Uniformity in terms of the way the box behaves across different systems. So we're looking at SSH FS if you've used it There's a space for you here. Please come And then we're also working on DNS support because use cases like OpenShift really need DNS support to be useful in particular this has been a bit more of a challenge under windows because Ruby forking has changed a bit and doesn't quite work correctly under Windows and Like three layers deep in the pile of turtles. There's a problem with a Ruby fork We think we've got it fixed, but if you like digging in piles of turtles This is good for you So this is the part where you ask all of the questions and I make no need to answer them I don't think either of us personally have looked at the successor program So it's hard to offer an opinion on it If you've got information about it It's definitely something we need to bring up and discuss on the mailing list and figure out what the right path for our project is And the question was about the successor to Vagrant that has she for has come out and what was the name of it again? auto So that was the question for those thousands of people watching at home One more question and you get a scarf by the way, please come see us You'll be very warm. Yes The question was does the vagrant file bring up one virtual machine and right now? All of the providers are configured to launch a single virtual machine where they operate in a client server or master minions style We are running everything in a single machine. There's certainly an opportunity for this to launch multiple machines So that for example, you could see it say an entire Kubernetes cluster And we'd certainly take a look at a PR on that other questions and you get a scarf to go with the scarf you have Everybody gets this car Okay, cool So everything is online and get hub if you want to see some of the demo scripts that we ran through Or tried to run through in a couple of cases. These are the project URLs. We strongly encourage you to take a look and visit us I'm not Naviche. He is I'm still Brian Exelbeard. Here's our Twitter and email address Thank you very much So Oh Oh Oh Oh Okay, guys, I see that your laptops are dying so you have charging like sockets in the desks. Yeah, so you don't Search for them in the corners of the room. There should be Under the desk look closer Oh Oh