 Alright, next step is to put off the guys. We're going to be talking about what's going to happen to you next week. Thank you. Hello, I'm Spiroffs. I'm a computing engineer at the CERN Cloud team. And I'm the project team on the OpenSpec Magnum project. It's a computer infrastructure management project for OpenSpec. And I'm going to talk about OSHA computers. OSHA computers. First, let me say that the Elux containers are just normal processes controlled by Elux kernel by Elux default groups. And the name spaces, so it's got a different name, so this is a totally new mindset. But specifically about OSHA containers, the most popular containers are containers mounted by Docker. And in 2015, Docker and other vendors created OSHA specification. So, OSHA specification has three parts. It's the runtime specification that defines how runtime should understand the configuration which describes the container and how it should run it, how it needs to create mount and mount name spaces and names of all these, and how to implement the lifecycle operations of the container. Then there is the image spec which defines how the image should propose that the image should have a manifest that describes the layers with the image index. And also there is the set of layers described in the image index. And of course it has the configuration configuration. And finally, it's the file system bundle. So, when the container runtime or any other tool pulls an image that is OSHA compliant, it extracts it in the file system bundle that has a file system where the container will start and the configuration which points to the file system and describes all the capabilities and the needs that I mentioned. But why we need the OSHA containers? So, as I said, containers are just a few new processes. You need someone to start the container. And most likely, if you have more than 100 containers, you need a supervisor of these containers. If you are in a large deployment, most of them will be orchestrated containers. So, you have a system like OpenSharm, or Kubernetes, or NOMAD, or NISUS, DCS, something else. But if you are in a single post, then you don't want to orchestrate. You need something to manage the containers. In most of the distribution, the processes are managed by system D. So, an idea would be to manage other containers with system D, but that means if they call system D, and then system D is called the DockerDemon, then the DockerDemon talks to the container, the great container. This has some directions, because when we talk to the DockerDemon, the Docker client, we do an API call. So, that might be a secret. And you need to be using the direction in system D. So, it's better to manage containers that are directly with the DockerDemon, or the system D. Another use case is Kubernetes. Kubernetes was initially started by talking to Docker, but that means you get that grant again that you do the API calls to the DockerDemon. So, in Kubernetes, with a component that creates the actual containers with this couplet, they create the CRI specification. And there are a couple of CRI specification implementations, like one is the CRI container D and the CRIO. Container D is a project that is behind Docker now, and it's developed by DockerDemon and other contributors. And CRIO is another specification, that is another implementation of the CRI specification, that is implemented in the CRI container and other contributors, and it was based in the previous design of Docker. So, a use case for that is... I'm going to use the use case that I will describe later. It's like a CNA problem. So, what is in the process that needs to start before Docker, and sometimes like manage Docker or configure Docker. So, if you have an orchestrated environment based in Docker, you might not be able to run all the containers with the containers, so you might want both of them. So, in this talk, I will try to motivate why I got into this. So, I would like to clarify that I'm coming from the user's perspective to the developer of the CRI specification, or any of these two, the user and the consumer of them. So, all this construction comes from the CRI container service. So, at CERN, we have just one minute to describe what CERN is. I hope that you already know. It's the European Council of Nuclear Research, and that has a fundamental analysis in probably particle physics. So, at CERN, we have a big accelerator that accelerates the protons and create collisions, and these collisions create events and lots of data. So, our biggest use case is batch processing. To process all this data. And in 2018 or since 2015, containers are a very good use case to define workloads that you run in a computing grid or in a plethora of environments. So, here is the big motivation. Other use cases are energy analysis, which are most prominently defined by two notebooks that you can build a container that essentially is a notebook and you can do analysis and then share the container images so that other cases elsewhere can do the same analysis and ensure that it will run in the same environment and it will have exactly the same results. The other thing is that all IED companies and IED environments have is transaction management, continuous investment employment. As we are a big open-stack shop, we also run open-stack containers. So, the container service is based on a project called Magnum, since I'm the project team with them. So, this is a very simple workflow, so in the first command we just create a cluster and we say in this case that I want a token form cluster with 100 nodes and you wait some time in our cases like this or maybe less or more depending on the environment. You wait for the cluster to be complete and then you just get the credentials to talk directly to the ticket to the container on the master nodes and just talk straight to the containers. And in this case, as you can see, after two commands you don't have to do list, you can start to talk to the cluster and the container so no open-stack anymore. And this is how a node looks, even if it's Swarm or Kubernetes in this environment that Magnum creates. So, in the Apricots we have a Swarm cluster that has a token demo. In the legacy Swarm, before Swarm mode, you have a Swarm agent that's running a container on every node. We also have the ETCD that should run on our console that should run on the master nodes. In our case, we have some templates which we run in containers and then we have an open-stack agent that takes configuration from open-stack and applies the nodes. Similarly, and even more complicated in the Kubernetes interface, we have more Kubernetes components. We have Lana, we have ETCD, we have a Seri runtime, and then we have the agent and the plugins that we want. So, in the case of, for example, for the legacy Swarm, if you wanted to run ETCD in a container, you should, and you had it on the docker, it's a chickening problem because you need to start ETCD before starting the docker. So, if you want to start ETCD in the container, there is a deadlock there. So, what you want to do is to start in an ETCD in a different way, like as a Managed Container by ETCD, and then deploy the Swarm cluster. It's exactly the same review stage in Kubernetes. So, if you want to run, for example, Kublet in a container, and if you want to run Kublet in a container managed by docker and Kublet, you need to, you cannot know which one to start first. So, in our case, we can start Kublet in an ETCD Managed Container and start docker again in a system container and then stop that container and start the pod in Kubernetes. And, of course, the other interface is the OpenStack agent which defines and configures all of this. So, since this agent contributes everything, it must start personally before all. So, this was the initial motivation. And, for these problems, we ended up living in a CI container. So, how to build them? I was about to describe the build up, but since I found it more complicated, I think it's easier to build manually. So, a system container is a container that runs in atomic hosts. Project atomic hosts as Fedora and send us atomic hosts. Send us atomic hosts, and if you are in the other private world, they have a record of the state, but in our case, we use Fedora or send us. This comes with the atomic utility and some set of other tools that allows you to create containers to be managed by system D. And, to build those containers, you must have you must build them and to be also managed by system D. So, we have a docker file and then we use docker to build the image. And then we have a system D template, which would be added to the docker image and then extracted by the utility and deployed on the node. So, the system D knows how to manage that container with RunC. We have a list of TMP files, which are files that may be that container and they may be they don't. And then my association which are default files for the application of the trans in the container and the application which is the standard from the OCI specification. We have a lot of these files in the list that I've written before. So, this is how we look to build the container. There is a fellow world example, of course, in the atomic system containers repo. So, you can just build the fellow world atomic, the fellow world container as a normal one that you would do with the prep and then you push the rest. Then you can just do atomic install which is also only an atomic host but then there's also a data based system and if you do atomic install minus my system, which means that if you run a group unless you specify otherwise in the configuration and then you can give it a name and that name will create a system-based based on that template. And then you can do just system-based start from work and start that system to use it. So, in our case it was a precondition. We could run whatever lines and double-stack specific rules that we wanted to define host. So, treating the host as a middle-level infrastructure that we don't take host and install a bunch of things or we don't just rebuild host all the time we just take that distribution and then we explain that we want. But, if you start looking into a shared containers and if you ask anyone that works on them, the most difficult part is to create the configuration file. So, in one of the documentation of RunC, the OSA specification they said, this is how to create a template and then you populate it. There was nothing after that, there was no documentation. So, you should start starting about name spaces with the the main page of the kernel but the permitting that you need as an advice is the main space because if you run a process without the main space it just starts in the high system of the host. So, the root file system of the container just goes away and you don't use it. Probably, you should add IDC but it's important then you should add the user to have a user name spaces and create what's seen by user and then you might also need BID to have if you have more than one processes in your container you might want to have a different main space and using system containers which are containers that are very close to the host you usually don't want to add a network name space it's better not to add it and share the same network space with the host. Then, the capabilities if you go to the website that I missed to add in here of the Linux kernel main pages then the number of capabilities is endless. So, one advice that you have that it's a pretty cool hack is if you start a container with Docker and you won't find, okay this container that runs in Docker, what capabilities it's using this is a pretty cool hack how to find it, you get the ID of Docker and then you go to the proc file system and there's some grep and dock you can find exactly which capabilities you need. So, this is the world world first day iterations that I was doing for my any containers and then of course you have mounts. So, in mounts you should be able to understand when do you want or what do you want to share with your host or share with your other containers. So, in this case in this case this mount is a byte mount the container will have access and these are private so that means only my container will have access to that directory and changes that I'm doing there are not provided to the host that will be provided doesn't have to be shared and that is also because we have Haslave which means only the host changes and then they are provided to the container. I think, let's go through my talk I finished a few minutes early so I put in some links here and that you I advise you if you are in the containers to go have a look at the runtime and the image spec they are not very long and they are very well defined and don't follow all the links that they have because they go to ares which are extremely long and you can check the other system containers repo that I've contributed and the atomic team contributes and you can pay your containers there of course it is my project and if you have any questions you can leave a free note and I'll be bigger. Questions? Let's say for example that I am an e-max user and I have a lot of plugins and a lot of sectors Can I make a container with my e-max my plugins, my settings that whenever whichever machine I'm running I tell for example Docker to run this container it's going to run with the user of that machine and not the super user of some special container in the container If it is defined in the compensation Docker will follow the situation because Docker is a non-straighted client in the runtime and these containers that I described apart from some special files for the system beginners are just normal containers that Docker runs than other containers How does Docker know which user was the user of that as far as the container in that usually the container is formed is formed on the root but then they run as a different user but they are not rootless containers How does he know a whole different container the user the user can look at the container and just know that's where the container is The user that created the container in the first place will be a good build and then inside the container the user will be specified in the right hand of the container