 So you have probably seen a message that the lecture is recorded. It will be only, so in terms of video, it will be only the lecture itself, sort of thing that I'm actually sharing. And if you ask a question, your voice will be recorded and we will add the lecture to so maybe aware of that. Nonetheless, I would still encourage you very much to ask questions. So if anything pops out that you want to know, just raise your hand and ask the question. So this lecture is an introductory lecture. It will be relatively short, I think about 15 minutes because right after we will do some exercises with containers just to get a feeling of starting a container from an image and playing around with it for a little bit. And after these exercises, we will have a little break. And after the break, we will have a longer exercise that goes into the topic more deeply. So an introduction. What are containers? Containers are nothing more, nothing less than a virtualized environment. And a virtualized environment is an isolated file system that is accessible from a host computer, meaning that there is a file system there that can work on its own and is completely isolated from the host, meaning for example, your computer running Windows or whatever. And it's completely isolated from that. So it does not rely on the installations that are already there on your computer, but forms is an environment by itself. Containers should not be confused with a virtual machine. So if maybe you have heard of virtual machines before, they are very popular ways of, for example, having a certain piece of hardware. And on that piece of hardware have multiple different operating systems on it. So that's very often used. If you, for example, buy a big server and you don't want to use the entire server for one specific purpose, but you want to have, for example, two different operating systems running on that server. And that's where you usually use a virtual machine for. You can imagine that a virtual machine brings the entire operating system, that it's relatively heavy. A difference between a virtual machine and a container is that a container is also a virtualized environment, but instead of bringing the entire operating system, it only carries the essential information to perform a task. So while a virtual machine, the applications within a virtual machine can be very broad, it just brings the entire operating system. A container is usually developed for very specific tasks. And therefore they are relatively small. While virtual machines are usually very big. In information technology terms, containers share the kernel with the host operating system, so they don't bring the entire kernel. So in that way, it only takes the essential information to perform the task while virtual machines bring the entire operating system. So why are these containers so popular? Oh, you probably have heard of containers before. You find them nowadays everywhere and a lot of different applications. For example, also in development of computer software. And the main reason for that is that dependency issues are a general problem. So if you are using a computer, if you are developing scripts, programs, usually at some point you run into issues with dependencies, meaning that some version of a dependent software might be installed on your computer, but you need a different version for your particular script to run. And then if you are shipping scripts to, for example, other computer, other operating systems, then all of a sudden your script does not work anymore. So in the interaction between development and operations, so that short for or short DevOps is short for that, development operations that their containers are very frequently used because then you develop in a container, but you can actually also run your code in a container during operation and during testing and actually also during really hosting a program, for example. Well, these containers, because they carry on with this essential information, they are very lightweight. So for example, you can the Ubuntu container, basically having most of the functionality of a Ubuntu operating system is only 500 megabytes and they pretty much have the entire operating system at your hands. And another very important advantage is that you can develop containers pretty much everywhere. You can develop containers on your Windows computer, on a Linux computer, or on a Mac computer. So the only thing you need to install is container software. Most of the times that is Docker and just start developing containers. And once you have your container developed, you just have to ship it to another computer, also running container software, and you can actually run that container. And it will have exactly the same functionality as it had when you were developing it on your Windows computer. Another and last very important advantage of containers is that the environment they are running in is shared, meaning that containers, you can run multiple containers at the same time, quite easily, and it will not require a lot of your hardware. But maybe even more importantly, these containers, they can communicate through a virtual network, meaning that you can have containers with very specific purposes. For example, hosting a database and hosting a website, you can let them communicate. And that is very, very interesting functionality. For this course, we will not focus on that. So we will not build any virtualized networks because it's a little bit too advanced to learn in a single day, but it's important to realize and to know that it's actually possible. So if you are talking about containers, there are two very important concepts that you will be using all the time. One important concept is the image. And an image you can kind of compare to a recipe for a certain dish. So an image is read-only. It can be stored on the longer term and it can be used as a base, meaning that, for example, if you have a recipe for potatoes in the oven, you can use that as a base and build further upon that. For example, building further by adding herbs or some vegetables, for example. And that's actually also the thing you can do with an image. So the image stores the information of a container and a container can then be compared to the actual dish. So a container is based on the image. So the image kind of describes how a container should look like. It is short-lived because you only use it as a runtime. And you usually only do minor adjustments. So for example, if you have a dish in front of you, maybe you add some salt and pepper, but you don't do much more. You're not going to cook it again, for example. And the same happens for a container. So usually within a container, when your container is running, you don't do very major adjustments. You just use it for its actual purpose. In the terms of a dish, that would be eating it in terms of a container. That would be actually running a certain square, for example. So that's kind of how images and containers relate to each other. So and it's quite important not to mix them up. So an image is basically a recipe and a container is basically a dish. A recipe can be stored in a long term and serves as a template. A container is something that is relatively short-lived and actually does the job. So if you talk about containers, very often people talk about docker. So even some people use it interchangeably. Some people even say, I built a docker. Well, that's actually not entirely correct because you have these two different concepts of images and containers. Docker is the most popular container software and it is that for a reason. One reason for that is that it is entirely free to use and there's a lot of very nice functionalities. And also an important reason is that you can run it on all three major systems. So on Mac and Windows, it even has a general user interface. I don't think on Linux it doesn't, but you can develop very nicely on all three of the operating systems. Meaning that pretty much everybody with the computer can run docker and therefore can work with containers. Because of that, it is very great for container development, but also because of all this functionality. For example, this very extensive dockerfell, which we will be talking about later on, very nicely can describe how to build an image. And also because we have this nice interface and command line interface, it is great for container development. Fourth of all, because it's so popular, it also has a very large repository of base images and base images are images that can serve as a base on which you can build further upon. So it's basically a very large list of all kinds of recipes that you can use in order to build further upon. And actually, if you are building images that can later on serve as a container, you always start with a base image. You can build images from scratch, but in practice, there are not a lot of people that do that. So usually they always start with one of the base images and they can be based on lots of different things. So for example, if you're mainly working with Python, for example, there's a nice base image for Python. There are R-based images. They're just plain operating system images like Ubuntu and many, many more. And all the images that are on Darkahob can serve as a base in order to build further upon. And of course, that's super powerful. Okay. I have a question for you. And this is an actual quiz question that can be right or wrong. I'll go to VFACT again. So the question is, which statement is true? And they are related, of course, to the topics we just discussed. As we have entered, we'll stop. Okay. So almost none of you have answered the first two statements. So the first statement is the concept of containers property of Docker. So Docker is the only software that can be used to develop containers. This is not true because there is a lot of different container software. One of them, one of the alternatives is, for example, singularity. There's a lot of functionality with singularity that is very similar to Docker. And there are also other container software. If you have many different tasks, it's best to use a single container. No, you actually want to build a container for specific purposes. So if you would have, for example, virtual machine, you can use that for many different tasks that run on that particular operating system with a container. You want to develop it for something very specific. Then the latter two, the last two. Actually, it is kind of a trick question. If you are a little bit more advanced with containers, and then you will actually know that both of them are true. So the last one is actually the one I was aiming for. An image contains the information for generating a container. So the image would be the recipe. And out of a recipe, out of an image, you can generate a container that is actually running the runtime of an image. So the last one is kind of the correct one. The third one is actually also true. And that's where the analogy between recipe and dish ends. From a container, you can actually make an image again. And we will actually do that in the exercises, but it is not good practice. We'll go back to the lecture. So by the way, if you have any questions, just let me know. Just raise your hand and we will discuss it. Last slide of this short lecture, and then we will play around a little bit with containers. So I often get the question, what is the difference between a conda and docker? So or actually between a dependency manager like conda, or for example, pip and a container like docker, like you are using with docker. Well, so it is actually, people often use them for kind of the same purpose. And that purpose would be isolation. So you isolate a certain set of dependencies from another set of dependencies in order to be able to run your favorite script. However, the level of isolation is different. So with a dependency manager, your dependencies are still installed on your computer. So they are still installed locally. Well, with a container, you actually bring most of the, most of the different operating system. And therefore the dependency is entirely isolated also on the operating system level from your computer. And this makes containers usually more reproducible, meaning that if you are using a dependency manager on one computer might give different results on a different computer, although those differences might be slight. And even maybe a more important reason, one description that you can give to a dependency manager, for example, the Konda environment YAML, might be able to install successfully on one computer, but might not be able to install successfully on a different computer. Well, if you have container software running, containers will always ship. So if a container runs on one computer and does a job successfully, then it will also run on another computer. So that's the main difference between a dependency manager and a container. So a dependency manager still has dependencies installed on your own computer. Well, a container isolates the entire operating system. And actually, dependency managers are often used in side containers. So of course, dependency managers are still, are in general super useful. And especially if you combine containers with dependency managers, they are even more useful because, for example, what you can do is use a Konda base image, have an environment YAML locally stored, and use it environment YAML to install all the dependencies inside the container and ship all your dependencies together in that Konda container. There's a question of Anya. Yes, does this make the environment created by dependency managers smaller than the default container environment in size? Yes, so it depends a little bit. Yeah, no, I think it's almost always the case. Yeah, that if you install it on your local computer, there are some dependencies already there on your local computer, for example, that are reused of a container, you always ship some extra files with it that are necessary for the operating system to run. Yeah, thanks. Okay, then it's time to get our hands dirty. Some exercises, it's not much. It starts really from the basics, they're relatively basic. So the exercise is to run your first or at least your first container of today, probably, from a Ubuntu image and see what kind of power that gives you inside that container, meaning that inside that container you will be root and you can change a lot of things to that container and, well, get it to work for your purpose. There's a question of Mani. Yeah, I have one question. Suppose we have one virus infected scripts that we want to run it, so what is the best solution for running this malicious script? You just have to run it in a Docker environment or in a condo or in a virtual machine. So you mean like a script that's harmful? Yes, it's a malicious script and we don't want to infect the whole system. We just want to first investigate how it looks like. So what do you suggest? We just want to run it into the container or we can run it on which one is safer or which one is machine? I think they would be both safe in a way or safe. I think running malicious scripts is always, well, might always be a bit unsafe. So if you run a script inside a container and you don't mount any local directory, so you can mount directories from your computer to a container, meaning that there is interaction between your computer and the container, meaning that can actually write files to a directory on your computer. Then a container will be entirely isolated from the host and, in principle, nothing should happen. But I would be very cautious, that's for sure. What about the virtual machine? In principle, the same happens for a virtual machine. However, so the virtual machine will be isolated from the host it's running on. So from the hardware it's running on. So in principle, nothing should happen to the host. But I can imagine that malicious software can also actually give damage to the hardware itself. Maybe over on the CPU or whatever. And then still a virtual machine can do that. Then also a local container can do that. Welcome. Okay, so then what I would suggest is to go to the website. So let me just quickly show it. Maybe you have already found it. So what I'm going to assume is that you have read the pre-chorus preparations and that you have installed both Docker and you have an account on Docker hop. If you haven't done already so, please do it as soon as possible. I cannot provide too many assistance with installing Docker because it can be very assistant dependent where the issues are. If you do not manage to install Docker for this course, you can always use play with Docker. You would need a Docker hop account for it. But there is some kind of environment where you can use Docker and play around with it, pull some images and do actually, by far, most of the exercises we have in this course. So for the exercises, go to course material. And then for these exercises, you go to introduction to containers. You also find the PDFs of the presentations over here and some exercises. So relatively basic, we'll just run a container, go inside it, and see whether you are actually inside that container, run a few commands. So what I suggest is we take until 10.30 for that, but we also include the break. So at 10.30, you should have finished the exercises and also had the break because then we will continue with, well, we will discuss the exercise first and then we will continue with the lecture.