 Good afternoon everybody and welcome to this session about career and fushi which is Bringing both networking and storage to docker swarm containers This is Hong Bing Lu and I'm Anthony Segura poimadon and to give you a bit of background about what these projects are quarterly network it started on Liberty and and what we started with was There was docker at the moment We were not very satisfied with the kind of networking it gave for production cases and Especially like if you wanted to have your own SDN at the moment there was really nothing so we got talking and finally when they acquired socket plane and they Released live network which they work with we've another people of the community We set out to make a live network remote driver for Neutron and the idea is that Neutron is a trusted and production ready Gateway to a lot of SDNs, there's a lot of backends that implemented and And There was a lot of people that a bit of the late motive of the project is there's a lot of people with clouds That are having VM workloads and as they want to move to container workloads It's better or much more Convenient for them to add those new workloads with an infrastructure that they already know and have people to manage And and that's why we added a cooler live network and the first target that we had was bare metal So if you wanted to run your docker containers on alongside VMs on your compute nodes that that was the first case We also Tackled the case of where no computes Would be there then we noticed that horizon had some issues when Nova was not in the picture at all but But but then we said well There is a lot of people that due to the shortcomings of Isolation prefer to run the containers inside VMs or sometimes just for convenience of deployment that you Have access to a to a cloud, but you don't have necessarily access to to the hardware So you just create a few VMs and you can just run the containers there and spin spin up your Cluster there and then fushi started Cycle later to and set out to do the same thing for cinder If you were at the keynote this morning, there was a demonstration. I think it was John Griffith I never remember exactly with the names. I'm a bit bad, but He's He has his own goal line driver It's made by the by the cinder community And that one is also providing access for for docker to consume Volumes that are stored in in cinder But this one is a different one that is The fushi project and what it does is it also allows you to give access to manila and Hongbin It's top contributor and he's going to talk about that one later. I don't know so much about it. So In this session, we're gonna focus more on container in VM, but if people have questions about what happens with bare metal docker Containers, please feel free to ask them if it's about Kubernetes There's a session about that tomorrow that I hope you you join as well That we will go very deep into the details about how we do things So the three modes in which we allow people to start docker containers inside VMs and when I say VMs that is equivalent to nova instances If you start your VM with something else then you're pretty much on your own so the way that we Perform that is by default When we want to try it out we use neutron trunk ports and I'm going to go into detail about what they are How many of you are familiar with the neutron trunk ports? Okay, I'm glad I made the slide then Then another option is to use Mac villain How many people are aware about Mac villain Okay, so just short somebody for those that are not aware Mac villain is basically a way that you Take a device in this case if it's a VM it's going to have most most likely an Ethernet pure TIO device At zero and you want to have several devices from it one option is you create a bridge You put the Ethernet on the bridge and then you put v add devices into the containers The other option is you get rid of the bridge all together and you use Mac villain which kind of implements a bridge in fact and You just tell to the new virtual device of the Mac villain. I'm I'm linked to this Ethernet zero device and But I have a different Mac. So the the operate the guest operating system driver what it will do is it will Listen for all those Mac villains. The problem is when you have a lot of Mac villain devices In VMs, it doesn't matter so much but in hardware the limitation is There is a limit to how many Macs a Card can listen to before it goes into promiscuous mode and when it goes into promiscuous mode It's like less efficient. So because of this and other reasons People in the community that support for IP villain and what it does is it segmentation the L3 level So all the devices on the on the for the containers that you're gonna run on the VM I want to have the same Mac address and they are gonna gonna split depending on the IP that you assigned to them So maybe you could if you're familiar with the old-school alias devices that you that used to be in in Linux It's it's sort of like that but more modern So the the good thing about the way we implemented this is that we did it only using Neutron Primitives so it should work with any back-end. Maybe the Neutron trunk Not because I know that some back-ends don't support it But nothing prevents them from from implementing this service plug. It's it shouldn't be a big deal for them And we have it tested with Dragonflow I think also with OVN and OVS so it covers quite a big amount of of the deployments that there are nowadays All right, so why is it useful to do that instead of let's say just Have your Docker containers on a Docker zero bridge on the on the VMs Well, one of the of the things that it buys you is that each container So first you can manage those networks on of Docker in in Neutron then each poor each Container gets its own Neutron port so you can direct The API to the to the container and by that I mean you can apply security group to a specific container And I'm going to show how to do that and you can do several other things Like if you would want to then use VPN as a service or something like that You would be able to do that because it's a real object in the in the open-stack infrastructure and then one thing that is a bit bad is that Until we implement trusts you need to have credentials on the VM for like if your tenant of the VMs Once to use this so he has to put his token for in the current configuration on the VM on each VM For it to access keystone, but that's something that we're going to improve and some and for a lot of people it's not a limit that big of a limitation and Yes, the the the as I said before it's about moving people into containers and making it easy and and that if you are Let's say that you're a company and you're adding a new team and the new team wants to work with microservices and they want to use Docker This way they will be able to consume the services that you have running on You're developing a new component that needs to talk to a pre-existing service that runs on VMs You have everything on the same network. So you don't need to to fiddle with your data center so trunk ports If you're familiar with OBS with the reference implementation, usually that is the BR int and you've never seen The one in the middle. So the one in the middle Let's let's follow it from the top up. Okay, that is the the F zero port That's always there and that's always a tap device usually managed by live bird if you use all Regular stuff and then as you can see the top device here is not plugged to be our end But instead is plugged to an OBS bridge that it's the the trunk bridge and what it does is it splits Everything that comes from the tap device depending on the villain the that arrives from the top So in this case, you can see that there's the villain zero Let's say the at zero the the communication that comes from the BM Then there is villain 42 and villain 40 and it splits that into two internal ports so in in green and in Kind of blue. I have my color choice. Sometimes it's a bit poor and then those Three internal ports of OBS are the ones that are Connected to the VR int and as you can see since the pod network in this case As a point pot because in this case it's for for Kubernetes but for Docker it would be Docker network Even though they are on the same network and you can see that they are in the same subnet Their paths don't join until we are in what this means is that if you have security groups that need to be applied between pot to pot communication Or container to container communication. It will still happen. It will not go just inside the VM so this this allows you to have more security and In VR in VR int as always each subnet gets its own Tuck so nothing changes on that Any questions about transports before I move on? All right, so the Mac villain IP villain solution It's a bit different and the reason why is because Neutron transports at the moment only support one kind of segmentation which is villain the one that we showed just now and It would be nice if neutrin also added the Mac villain Support or IP villain support for segmentation But with IP villain it's a bit complicated because by default it allows I'm now. I'm not sure if there is a mode that allows you to not have communication between the different Devices on the on the guest with Mac villain actually there is a mode that Always sends a communication down so that it would allow us to reach VR int It would be nice to have that but for now what we do is we allow we use allowed other spares So we create the port to allocate the IP so nobody else can take it And then we add it to the allowed other spares of the VM. So that's that's how it works and I wanted to say that those several modes of operation That that I said the one that goes all the way down or the one that allows Horizontal communication you should choose them depending on your needs. So for example, if you don't care about Blocking communication inside one subnet, maybe you can use the mode that allows communication And you are gonna have a slightly faster performance. It needs to West traffic inside that subnet so this is a bit to sum up The kind of choices that you have for giving container networking using neuter on the on the Nova instances if you need a lot of containers probably trunk ports with villain are not the go-to solution because it has the limit of the villain ideas which are 4096 and Of course, you could always plug different Ports into the VM like attach new S and then bind to several ones, but we don't support that yet and Honestly, nobody has come up with that requirement. So it's it's it's a thing to to take into consideration the other thing is if you are running your Docker clusters on VMs that are created on me on mitaka or older that don't support trunk ports you are Pretty much the decision is pretty much made for you that you have to run IP villain or McVillan because otherwise you would you will not be able All right, so just to give you an idea of what it takes to run this and I have to to think Leaping mouth or contributing the the plugin support Right now. It's pretty easy if you want to try it out You just do docker plugin install could hear a slash live network to and it will automatically fetch from Docker Hub The last container that we built and it will already propose you to mount those mount points that you can see there Most important of them being it is a career. So if you just place your career dot-com file there It will just Start working and then you can just create the networks and we're gonna get into that. So on Nova instances If you use the OBS reference implementation, you must run the trunk service Plug-in because otherwise the trunk ports will not get created and so on and also you should use the the firewall driver Open be switch Because there is some problem with the hybrid one and believe me It's a big problem because I when I was preparing the team I could not figure out what happened I said, okay, let's try the native OBS firewall driver and then everything started working So I recommend you to do that unless you're a newton developer Then I encourage you to try to fix the one for OBS hybrid alright, so if you don't want to install it like that you can also use peep or you can use Just the tar wall or whatever it's it's pretty much up to you Then other things so that what we saw before was the the configuration of new turn And the confession of career that you would put on each or your of your VMs is the following So you have to specify which is your link device So it knows from which to create the IP villain devices or the villain devices or the McVillan devices And you should specify also what kind of driver you want so Again the same like if you want villain or or McVillan or so and Finally we have options for running SSL So in the typical case you may not need it because you just bound locally to 127.0.0 That one but if you need it because you have some specific requirements you can configure that the communication between Docker and The lib network rest driver is encrypted in in TLS all right and Finally for running which is probably the most interesting one if somebody wants to to get started with this By the way, there is a project on boarding tomorrow That that you will be able to run this if you're bringing your laptop and you are ready to run that stock So as you can see you can create a network You can also create so the default is to create a network and that is just following the API that docker provides you but docker Also gives you the possibility to add your own options And what we do with those options is whenever people come up and have a requirement like hey, I have this BM networking This BM network sorry, and I want to start a container in it to see what's happening in that network So we have an option to specify already the network So that when you create the the net the network in docker Instead of going to Newton creating a separate network with the options that you specified It will find the network in Newton It will make a mapping between them and to be able to that we use the Neutral resource tax which are awesome because they allow us to Preserve the names before we had that we had to modify the name of the of the network So people were like it ain't my network but you know it was still there but but renamed and another interesting thing is that it allows you to Even reuse a port if you have a port that you created and it is unbound And it matches the IP that you specify when you do the docker run It will actually reuse the existing port So if you have a prepared port with some specific security configuration, that's a good way to do it And otherwise you can do the normal docker option of exposing the port and it will set up a security group for it and and and apply it and Here I give to Hongbin to talk about storage So so Tony talk about the current network. That is about the solution That is for the networking power of the docker So I'm going to talk about the foosies which is curry support That is for solving the container persistence these problems and So perhaps I should give a brief introduction of how the Container storage is going to work in the docker. So so when you create a docker containers is It will have the file system of inside a container that is from the image and In the container image, there are several layers of the There are several layer of the image and each layer has a portion of the file systems and Generally all the image that has all come up together to provide the The roof file system of the containers so when you write something this in in the docker and suppose a data volume is not provided and You are writing to a layer that is docker that is create on top of all the image on top of the other image layers and each write to the Layer they the docker is going to copy the file that is in the image and copy the whole file to the to the upper layers and This is how the docker union file system is going to work and This is this approach is good because for share the image for multiple containers and it will put the container that's very fast and But it has some performing issues for copy the files in particular if the file is very large and each each time you write to a file and the whole file is going to copy and that there's there's a significant overhead of if you're writing a lot of data to the containers and The another problem is when you delete the containers and all the data you are writing to the file system is going to loss and So to solving this problem and docker has another feature that's called a data volume and a data volume is a Generally speaking is a storage that is mount to the specific path of the containers And so that each time you write the data to this particular path of the file systems And it will bypass the union file system of the docker's and it will directly write to the Storage that and so foosie is the project that is to provide the implementation of the data volume for the docker's by using the cinders or maninas and it's up to you to choose which bet and you're going to use and there's so use case for the cinders and so first is to allow you to use a docker CLI to Create a data volume that is in the docker's but in the bet it is actually go to Cinders to create senior volumes and use a senior volume as a docker's for their storage and It allows you to dynamic create the volumes or you can pass the volume That's already create and pass pass pass a UID to docker's and let the docker to use that volume And it also support the customer so that if you have multiple horse multiple note and each you create a volume in one of the note and It will be reused by another note if so that the same warning won't difficulty created and In alternative to the cinders there's another choice which is maninas and it has a similar use case But it just use different Use a share file system itself the Brock's doggies So this is The foosie for the docker's so foosie has a component that's called a foosie service And it is the foosie server is just a process and but it's implement the Docker warning plug-in interface and so that it Each time the docker is going to Create a warning that is the if the driver is foosie they will do the docker will call API of the foosie service and foosie server will go to the cinders or maninas to create a Yeah, that's the question. You can say I spare it foosie It can be a VMs or compute note. Yeah, it can be either. I think yes Yes So that is a demo that he will show then like how You can create the the cinder volume and how it is accessible and so on so Yes, the communication between the foosies and the cinder is secured by keystone and Yeah So this is a proposal for the how to integrate the foosie with the Kubernetes and The proposal just get approved, but there's no code there. We haven't started implementation yet So it's a lot of ideas No code but a lot of ideas. I said Yeah, so if you want to join the efforts and welcome to John and and so this proposal is about To reuse the foosie server that we already implement for dockers and we will use it for the Kubernetes so in this Design we propose to have two components. The first one is called a warning provisioners so this warning provisioner is just Just just a process that is watch the Kubernetes API to see if the user that is creating a persistent volume cranked and if the user create a Ppbc that's persisted. Yeah, if the user create a pbc the The volume provisioner you go to first they will provision a persistent volume in the Kubernetes and then they will go to send us on many notes to create a the actual resource and Yes, and then there's another component that's called a fresh volume drivers and this Component should be resized on each node that is one of the cubanet and it will use by the cubanet to connect the To the volume that is already provisioned in before and so that the pod can use these volumes yes, oh So this is the config file of the of the foosies so The operation need to set cell parameters and Some first they can set the warning providers and it can be seen the saw many notes or it can be both So the user can choose which one they want and it need to set the IP address and You need to set the volume connectors. So by default is using the OS bridge Which is the library that is developed by the sender teams and it's need to set the you can set the FS type Which is the sender Pacific? I think it's a since in the Pacific parameters and Yeah, and the money that you can set something that's similar so to use the foosies and this is the sample command and so it So first you can yeah, you use a Docker CLI's and create the volumes and Set the driver as a foosies and Parts several parameter that is seen the Pacific on and specify the warning provider and point to senders Damn the docker will create the volumes which is actually a single volumes and or in an alternative you can point to the volume ID that is a Scene volume that's already create and ask the docker to create volume that is using this volume and so the docker won't create a new volume, but using the existing volumes and and You can do something that's similar for the maninas and the command will be very similar and then when you run the docker is It's just as normal you use a slash re-options to bind the volume to a Pacific path of the containers and That's it Yeah, so for the roadmap for the foosie power is First we are going to so a ton is show that the current level you can use the plug-ins to install the foosie nip network so the For sorry the curative that was so foosie we are planning to do something that's similar to support the docker plug-in installations and We are going to support the TLS to secure the the communication between the dockers and the foosies and for the Kubernetes we are going to implement the fresh volume drivers and implement the Kubernetes integrations and set up a sea ice and for the leap that was Where we can we are going to support the gobo's goal to support the swan mode we are going to support the docker swan multi-node CI and That's the roadmap and then I'm going to show a short demo and so in this so in this demo I'm Going to create a containers and VMs and This I'm going to show that the container and VM can be Can be in the same networks In the same neutral networks, they can pinch each other's and they are Mount to the same share file system so that they can the data that is right to the file system They can see each other's and so I'm doing the docker never needs to You can see that we Already create the docker networks That is of the driver of the courage and we are going to inspect this network you can see all the parameters and Most of them are neutral and Pacific's and for some of the UID of the neutral necks and then I'm going to show you the volumes that I already created and the driver is foosies and We look into the volumes and we see the parameters and this volume is from many nurse and and I'm going to use a money now API to Show the details of this shares and So this is the property of these money that shares It is a shelf house systems and and then I'm going to create docker containers and I Use a slash re-option to bind the volume we already create to the path. There's data and We are going to specify the networks of this container to use my neck, which is the current networks we already create and It take a few seconds and the container is we should get into the containers. Yeah, so right now we get into the containers and And then I'm going to use another terminal to get into the VMs and This we are we I already created and it is under the same level of the containers and This VM is also already Mount to the shelf shelf house systems that is provided by the maninas So I'm going to SSH to this VM So the first thing I'm going to show is We have the IP address of the VMs and I try to inside a containers. I Try to paint the IP address of the VMs and You can see it's paintable and the IP address is actually the private IP address So it's not a public IP address So I'm going to do something that is opposite. So I'm inside the VMs I try to paint the IP address of the containers And it's also paintable Yeah, so that means the VMs and the container is in the same networks and And then I'm going to show the shelf house systems. That's mount to the test share by the VMs and the containers that Which is data's and so first in the In inside the VMs, I'm going to write something to the share directories and So I go back to the containers. I try to check What I'm going to write and and we can see the data is there And then I'm going to do something similar. So inside the Inside a container. I try to write something to the shelf houses to share directories and in the VM We should check it is all is The data is right. Yeah, that's about the demo All right. So if you have any question About Fuji about the Quirrelimp network or about Quirrelimp in general Please feel free to go to one of the microphones and ask Otherwise you can meet us after the session or tomorrow in one of the sessions that we'll do. Tomorrow the onboarding is at Wait, I have it here on some other. I think it's 11 something way project updates At 11 a.m MRI MR 105 and then there is the current over 90 session At 150 All right. So if there is no questions, thanks a lot and I hope that that you will all come tomorrow to the morning and try out Quirrelimp for ship