#17 - Containers

We talked about container from the ground up!
Is it only Docker in the space (no!).
What are they for, why they're also incredible for local work, how we like to work with them.
Why they're amazing for production purposes and can be found everywhere.

Meir talked about his experience with Nest.js (Omer: I'm definitely adding a +1 here, Nest is amazing!): https://nestjs.com

Omer mentioned Neovim's collaboration plugin: https://github.com/jbyuki/instant.nvim

Leadership Lessons From The Great Books
Because understanding great literature is better than trying to read and understand...

Listen on: Apple Podcasts   Spotify

Meir's blog: https://meirg.co.il
Omer's blog: https://omerxx.com
Telegram channel: https://t.me/espressops

Transcript

0:00

Okay, okay, oh my ready. I'm very much ready. I have props today and action. Wow, oh, so there. Ready, action, action, action. Let's go. Let's go. So hello everyone and welcome to the owner already for it for the 17th this time I remember 17th. Yeah, episode of DevOps topics and today we are going to talk about Containers. We just need to add something. We have discussed containers in the past as if everyone knows what it is and how it works because we assume stuff and we did start with container orchestration which was probably premature. So today we're going back to the basics and talking about containers from the ground up. And maybe also about CICD. Maybe. Maybe. Maybe. We'll see. If we know what is CICD. Yeah. Yeah. We'll see. Okay, so OML. What's the first thing that comes up to your mind? When I say containers or docile. Okay. Okay. Okay. Let's start with what you said or docile. I think that's not a synonym and we need to get used to in 2023 not to say Docker containers. We need to say just containers, container images, stuff like that. One because Docker is kind of it's not dying but it's kind of a lot of its places taken by other providers will touch on them a little bit later but it's not only Docker today. There are a lot of new players in the in the in the ground. So first of all, about Docker containers. You can say Docker. That's fine. And the first thing you asked me, what's the first thing that comes up to my mind? That's kind of an unfair question to the crowd because when you ask me what's a container, obviously I had to like first of all learn on myself, learn on my own what containers are then teach others and read about it. And obviously we work with it daily both of us and I'm assuming other engineers that are listening in. So let's just give two sentences of a basic background for those of us who are not completely familiar with containers. And then we'll move on. But you need to approve my words. Of course. Even before you said it. Oh, come on. I'll tell you how I how I introduce it to people that don't know where they're on. So what we have used to we got used to working with servers in a past, right? We had physical servers today were well, a lot of companies are working with physical servers. A lot of others are working in the cloud. But we were used to physical servers regardless of how we work with them. And then there was this notion of virtual machines, which were kind of a way to compartmentalize different components of the server and basically utilize the same amount of resources. For example, I have a huge monster of a machine with eight cores and a lot of memory and I can utilize it for a lot of applications rather than we're running one process. And then some people might say, okay, just run a few processes. What's the problem? But then I tell you, what if I'm running one process that's a Python application or a Django application? And the other is Ruby on Rails. The third one is a Postgres database. And the fourth one is an engine X, an engine X process, right? At some point, we'll have a lot of issues, conflicts, stuff are going to happen because I'm installing many dependencies with many package managers, if and if I'm just using one technology, if I'm just running Python, maybe one is running with 3.7, the other is 3.5 or 2.7. This creates a lot of issues in the computing world. I'm just, you know, I'm going to start it for a second. I mean, we skip the path, we'll usually just set compata, what-allize. Compata. Amazing. Amazing. So I had to... So all the time you talked, I was like, you said, compata, mentalized. Like, okay, good for you with that word. My hobbies, my one of my hobbies is learning new words and just injecting them as if it I was born with that. Like, blah, blah, blah, blah, blah. Exactly. Exactly. Prioritization. No, no, no, blah, blah, blah, blah, blah. For proprietary. Yes. This one. Exactly. Okay, so just even before you go ahead with the Python 3.7, 3.9, whatever. So I think let's focus on the compata, third of the lights that you said. Okay. Okay. Again, the idea here and I'm not yet touching containers. The idea with virtual machines was, let's compartmentalize and let's separate the resources, right? Because I can use the same core, I can use the same amount of resources, but I'm having some kind of separation and the idea of separation is having a clean environment. Because if I run now, peeping stolen, I'm downloading, downloading stuff from the internet. The environment is clean. Now, there are a way to fix that with tooling. For example, for Python, you have pi n. For other applications, you have similar tooling. It gets complicated. You can imagine not all technologies have the same, the same way to separate environments and having a virtual machine is basically your way of taking one large box and separating into small boxes and installing many, many boxes. When you explain to someone that's not even part of our field, you can say that. I have a huge box with a lot of resources that are there's a lot of space. Instead of running one tiny box in it, I can fit as many boxes as I can. And that way I utilize and obviously save money. Obviously, whatever are the by-product of utilizing a resource. And then someone said, okay, virtual machines are great, but it's kind of like duplicating the same operating system again and again, not going into the intricacies and other great word intricacies. Not going into the specifics of what does that mean to replicate the operating system, but operating system is something that's heavy to replicate. It takes a lot of more resources again because the separation isn't free. It costs a little bit. So let's use containers. Containers is a way of, by the way, built on Linux. In Linux, it's called namespaces. I think it's based on that, right? So you have namespaces in Linux that lets you kind of separate different resources, CPU memory. You can allocate different parts of your resources on the machine to different processes and create a complete separation between them. So containers are built on top of that. It's, I think the term in Linux is C groups. So that's based on that and C groups is that the base of containers, essentially. And then you have a complete separate environment with its own operating system, but it's utilizing the underlying machine operating system. I hope this makes sense. But let's just say that it's a lot more efficient way to run small boxes inside this big box. How's that for an explanation, Mayor? Can you write me one, two, 10? 10 always always 10. I'll just add that that you said Linux, but it's also relevant to Windows, right? Because you also have Windows containers. Well, hopefully not, but yes, you're very no, no, you do. You do. You have Windows containers. And I think like what I like to do with Windows containers, like if you are creating an installer, maybe for your Windows application. So if you do it inside a Windows container, it's easier. Not sure if we'll get to that, but just, you know, you will listen and keep that in mind. Something that's important here. When you're running stuff that are not stuff, when you're running containers, not on Linux, I think you need to have a special hypervisor and that's kind of a layer between the underlying operating system. In this game, Linux can be Mac or West, can be Windows, whatever you're running there, but this would create some kind of translation for the system to be able to actually utilize containers. It's not available for you like you would have with Linux. That's one. So either way, okay, so, okay, so I think we can say that for local development, usually, I would just say usually I hope I'm not helping any developers who work on Linux, okay, but usually we walk on Windows or Mac OS, right? So for local development, you usually have a hypervisor as you just mentioned, but in the cloud, where you run stuff, you know, on Kubernetes and whatever, then over there, like there's no hypervisor, so everything is super fast as it should be. So for example, it runs natively, basically, yes, when you're running that Kubernetes in the cloud, it's pretty much native. Yes. And performance wise, it's especially viruses when it comes to five system regarding the copy, files, move files, so height files, rate files, whatever. So that's very important to walk as native as you can, because if you have high loads with IO, you know, input, output throughput, then may take a lot of time. I want to stop you there for a second, because I feel like you jumped a little bit forward, because we both kind of well versed in the field of containers, but you said, you started with local development, right? And I want to make an argument and I want to, I want to hear your opinion on that. And I always argue to developers that you need to kind of know containers, it used to be only Docker, but you need to know Docker, you need to know how to work with computers, sorry, with containers, even if you're not running literal containers in the cloud, or that's the end goal of the day, just because it's ability to separate you from the environment. And then I heard stuff like, no man, I have by end, I solve it with this and that and that. I believe that having a container that installs only what you need with the exact same environment that you'd be running, even if that's a machine, right? And easy to want AWS. It's not a container, nothing to do with containers, you'll still get a lot of benefit from that. What are your thoughts on that? So I could tell that in the past few days, okay, recently, I think that would be like jumping to the end of the conversation, like this, my story of the week, that I created like this full mono repo for front end backend and, you know, database and everything altogether, right? And as part of it, I thought to myself, should the local development process be in containers, or maybe install the applications natively and locally on the machine? So just to give you an example, it's the glance of what application I'm talking about. So let's say node, right? So as you said, if you have multiple version of nodes, you can use NVM, right, node version, manager, same for Python, Python, whatever. And for the RVM, yes. Yeah, so to tell you the truth, because I like all the functionality of hot reload, natively runs out in a computer and in for local development, like to me, like fast is top priority, you know, if it's not fast, it's not good, because I want the fastest input I can get, input output, whatever you call it, you know. Agreed. So when it comes to combining containers, so the only thing that I'm running containers is, I'd say database or local, okay, for local development. So database, AWS, Cognito, so for example, local stack, if you want local authentication everything, so I'd say external services, services that I'm not building, I will run locally as containers with local compose, right, but the things that I develop, like next JS backend and a font that may be with VIT or, you know, React, whatever. So these ones, I'm not running in containers. These ones are running natively on a machine. Perfect. What now you're going to cry? Are you ready for the Y? I'm not sure. Am I? Because, because the dogs, okay, I always say read the dogs, all right. Okay. If you, okay, if the dogs were oriented for development in containers, I'd go for that, but because all the dogs for all languages are oriented for, please install this on your machine. Unlike, if I want the developers to be aware and, you know, because sometimes what I do, I create something or work with the developers and I want them to have the dogs of open source projects that we're working on without maintaining a new set of dogs and whatever. I want, I want to be as aligned as possible with, let's say, nest JS, okay, I don't want to rewrite the dogs just to work in containers and I want them to tell, oh, read this blog post, you'll learn how. No, read the dogs of nest JS, it's exactly what we need to do in our project. That's my answer. Okay. Okay. So it brings me to my next idea. Like a developer, right? So no, actually. So that is exactly what any developer would say. I've been working with nests specifically for a year and a half and I did, I did run it in a container, but maybe that's because my thinking is I'm more oriented with ops, at least in some parts of my career. Let's call it. And I know what's going to happen. What issues I'm going to tackle? I'm not in, well, at least when I was working on that, my thinking wasn't exactly a 100% developer. It was someone that thinks this has to run in production. I very much cared about it. And I kind of 50% of me wanted it to run smooth and fast. Like you just mentioned, working exactly like the dogs just, but the other half of me wanted to see this running as it would on Kubernetes or in my case, I don't remember even what it was or it was running on a container. I wanted to see the end result in my face, right? And I wasn't to work kind of in tandem because I want to have the thing right running in front of me in a container. I still wanted to have my nice environment. I love them. I want to develop in VIM. I don't want to SSH into an instance and do something. You love VIM. Let's talk about the, talk about it on another episode because I can not only work just on that. Yeah. Okay. So what I do, and I'm assuming you're to with local development is basically, I am you could using Docker compose just like you because compose is awesome. I have a comment on compose. Remember, I need to say something about that, but at the end. So I'm using Docker compose because it's easy to orchestrate stuff. Exactly. Like you said, you can use services, MySQL, Postgres, whatever you want to put there and have a direct link between the containers. And obviously, instantly, if your container crashes, it'll put it back up, you can scale things up. You can do lots of nice stuff with it. And I just mount my local directory onto the containers so that I can keep working on files. And basically mounting for those of you who are unfamiliar is literally mounting your local development workspace onto the containers. So the files you're changing are not copied onto the container. It's the same file. Okay. Your container sees what you're doing locally. And then when I change, you're speaking about hot reload. So I'm changing in the code. I'm saving it and VIM and the hot reload does its thing and it reruns in the container. That's why I like it. And that's how I like to work. That's it. I totally get what you're saying. So I'm just putting it. But I have a high bullet solution of what you said. Go ahead. So because I don't want the developers to upload their code to the cloud and then everything would explode. You know, because we like it. We like explosions, but not when it comes to the cloud, right? The cloud should become, right? It should be in place. So what I do usually is I told you, I use like in previous sessions episodes. I told you, I use a make file. So everything is aligned with the developers and CIT and whatever. So as part of my make file, I love to add the command like make a van production maybe. And then it, so I also add, so let's say it's like a font and application. Usually you build it, right? And then you have static files and it's in the this folder, okay? This is the right or this folder. And then I add another layer, okay? It's like an external layer, like maybe a server layer, okay? Which imitates, you know, maybe I'd say maybe like AWS Cloud font or Cloud Flow, anything that serves my static files. Just to see, just to allow the developers to see how which we look like if they upload everything to the cloud. So then like their application, even though they develop everything with the hot reload, the SGS, which is a backend and the font and you know, which is react with Vito or whatever, I enable them the ability to just run and test, like because you don't do it all day long. But if before they upload before maybe they commit and push maybe it's for a big change, like it's not really a test. It's more of a, this is how it's really going to be in the cloud, you know what I mean? What would physically when you run make production, what's your container? So it's going to take, it's going to take the fight. Yeah, it's going to build a container exactly. So it's going to run a container out of it. As you said, like mount the code, it's going to do what you said, but not as part of the development process. But as I said, like a hybrid solution of they're working with a hot reload locally, natively everything is super fast. And still, you know, they can check if everything works if they upload it to the cloud. So that's my hybrid solution for that. That's perfect. That works great. And that exactly connects to the part that I want to know that it works because it'll have to build the code. If you're running, I don't know, you're running nests, you're probably working in TypeScript, I'm guessing, you have to transpile your trust. Happen to me now with React, everything worked when I wrote down VIT Dev, everything worked. And then I was like, okay, VIT, when you build these crashes, why React 17, React 18? That's cool. Perfect. You know, that's crazy. Here's a great use case, another great use case for container. Should we take it to the next level and speak about the cloud? Go and speak about the cloud. We have enough time to speak about the cloud. Okay. It's not really five minutes. Okay. What I meant to say was I want to talk about production. So far, we've been talking about containers for local development, which is amazing. I like it. Here you are, like you need to. So the real use case for that is putting things in production, pretty much for the same reasons. By the way, you want to have an environment that's easy to replicate. You want to know that what you're doing locally can be replicated in production. And the, you know how the title goes, it works on my machine. We get rid of that. I don't care that it works on your machine because I don't know what your machine is like. I don't know what version you have, what packages are installed, what versions you're not even aware that are installed, what are their surrounding, you know, surrounding services are running in the background, and I'm not aware with containers. It's, it just won't work. I like to aggregate everything you said, like when I solve problems, I say, what's the state of your machine? Like, it's like saying, like if I take everything just said, I'd say, I don't care about the state of your machine, which includes everything you just said, you know, so it eliminates the state, you know, this is what I like about it. Let's eliminate the state. Exactly. And then we get stuck with the versions, you know what I mean? So let's make sure the versions are right. But if you have this state, eliminating the state, or yeah, I think that's most of the time, it's like 90% of the problem, I think, like to me, I think most of the time, it's like, oh, I also installed this and that on my machine and this conflict with this one because it's installed globally. And. Exactly. And that takes me to the next thing that we haven't touched yet. And that's the Docker file. And Docker file is your way of seeing exactly what you said is code because we have this way of templating what you just said, the versions, the operating system, the underlying layers, the environment, the variables, whatever else, the arguments, processes, everything. It's just listed in this template that's called the Docker file. And you see what's going on. Yes, there is a way to snapshot containers without seeing all that kind of like taking an AMI for an EC2 and AWS, you can just Docker commit and then you have a snapshot works pretty much the same, not the common use case. You'd more often than not, you'd want to have a Docker files. I think we can have a full episode just on Docker files and best practices and how to work with them. Up to you, if you want to live it as that or get further into it, I just want to finish the idea of production. So we talked about the ability to replicate your environment from local environment to the cloud or wherever you're running production. So that's one. The second thing is we want to scale. We talked about scale in the past. We had one episodes picking exactly about that and containers. Let's ask scale. I talked about virtual machines before that also allowed us to scale with containers much faster because we're sharing the host, we're sharing the operating system of the host. So it's easy to replicate the containers, especially if they're small, if they're efficient, it's easy to just put up more of the same. And then I can run a lot of instances. And this means I can scale up, I can obviously share the load, probably use some kind of load balancer on top to help me with the routing. And that's why containers are great. And if I'm taking into the last level, we talked about replication, we talked about speed of instantiation. And the last level is obviously things like ECS, Nomad Kubernetes. We have in the world orchestrators. And these help us to have a fleet of instances of nodes that are serving as demons. We don't have to manage them, they're managed by the cluster. And then I can take a lot of these small boxes that are called containers, just spread them around on the instances. And that's taken care of by the, by the, but we have to do this, you know, you have to do this to orchestrate between them, you know, we gotta be like this, case you orchestrate between the effects. Okay. That's it. Okay. I also, okay, I say about educating for containers. Okay. So for example, the research team in my company, they're like, okay. So the anything installed, many applications, many Python applications switch between Python applications. And I didn't know that. So then I asked them like, what are your problems? Like, what, what, what delays your delivery and whatever. And then it felt like if they just use containers, maybe creating a Docker file with okay, Docker image version, all their applications in one piece, they can just run containers. So on the application in containers, like the one that they can, it's important to say, we talked about containers, but if you need a graphical user interface, forget about it. Okay. And some applications need a graphical user interface, especially if it's research, maybe it's something like open CV, you know, that requires face detection, I don't know, like, many applications need a graphical user interface. So as long as you don't need a graphical user interface, maybe even your research team or development team or Q8 team, if you want to aggregate or, you know, to couple or a set of applications together without breaking stuff. And then as you mentioned earlier, like it works on my machine, why doesn't it work on your machine? So then they can talk in like in doc images versions, like have you taken this, this image or that image, which image version are you working on instead of talking about Python version, application version, blah, blah, blah, blah, blah. So maybe education to containers is also good thing, not only in LND, you know, maybe even for sales, if they use applications, I'm not sure, right? Anywhere in the organization. So you reminded me of a very important tip about containers running in production. You talked about how we can pinpoint one specific version of a container. When we build containers, we give them something that's called a label. They give themselves this kind of a hash kind of like a gig hash. When you push them into what we call a registry that hosts them can be for production or not, we're naturally giving them some more understand human readable labels. Let's call them. This is for production. This is staging. This is for this branch. This is your favorite one, your favorite one is latest. Okay, this is it. latest is a bad label to use for everything, not only for containers, but operating systems versions of libraries and pretty sure that everyone listening into this already knows that. And if you don't, please do listen to that carefully. latest, we're not the greatest. Let's leave it at that. I think we're done. Basically, latest will ruin your life at some point. It'll be great as long as you go, automatic updates, funny stuff. At some point, it'll break something. That's because you're pulling latest. You have breaking changes. You're not aware of what's going on. And the next thing I wanted to say, which builds on top of that is if you keep pushing latest and get rid of all the other labels, it'll be hard to pinpoint a specific image. You want unique, very like unique one to one unique labels. So you can pinpoint something. And when you go to production, you know exactly what's running. And you can pinpoint the hash and maybe even debug it later locally if you want to do stuff. That's it. Do you know that if you use latest, like let's say you do like your local health, okay, right? That's what you want to say. And accept all going to hell. You can, okay, you can use the hash digest to pinpoint latest. Did you know that? So if you have a tag, okay, tags, just, just to be, we are aligned, okay, okay, guys, okay, okay, girl, tags, docal tags, containal tags are mutable. It means if I tag something as version 1.67, whatever, it's still mutable. It means that if I push the same tag again and, you know, something's changed, the tag will be updated. So it's mutable, it's editable. But the hash is immutable, okay, the SHA 256, you know, that just whatever. Yeah. So you can use latest all the time. If you want to use a fixed version, like, you know, the same version all the time, you can add the add sign and then add the hash. So it can be like latest, add sign hash, whatever, like with the SHA digest. Yeah, so that's very cool. So I think, okay, why am I saying that? Because if you want to use maybe use an open source project, and they don't have other tags. So an open source project in docal hub, and you're saying listen, they have the latest tag now, but maybe a new version, you know, will update the tag of latest, and it will break my application. But they still want to use this specific latest version. So how can I pinpoint that? So you can use SHA digest with latest, and then you can pinpoint latest to a specific version. Cool, huh? That's a perfect tip. I think it's hard to understand from the audio. So let's put that in the show notes if you're really interested. I will, I will, because I know I am, and that's a really cool tip, and will be helpful for a lot, for sure. Okay. All right, do you want to wrap it up? What do you say? I think I already said in my experience of the week with the NSJS and React whatever, but even though we say even though, not though, even though, okay, because we like to, we like to hit pizza, so we make dough. Yeah, some of us. So even though, we are ending this conversation in a minute, we need to ask Omer like, Omer, what was your experience this week experience project, something funny, anything? Cool. I do have one, but I will take one step back on myself saying we need to wrap it up, and I just want to say one thing. We talked about Docker compose. So I wanted to remind you that. Yeah, okay, good. Okay, I have one comment on that. I've uploaded like a YouTube explaining the basics of Docker compose, and a guy from Docker reached out and told me everything's great. You were working really nicely. I was actually testing a local development trying to show people how to work with the exactly what you said mounting my local host using services like Postgres, etc. And he told me that's all nice and dandy. You know how you run Docker dash compose. It's Docker space compose. Exactly. Docker dash compose is a Python version not supported anymore. They're getting rid of it. The new version Docker space compose is written in Go. That's the one that Docker supporting general public information. That is it. That was my comment about my cool project. I have a lot of them. I'll pick one. You probably already know my love for a new VIM and VIM. And we were discussing at my company this week how we what tools we can use to collaborate collaborate and code. We're actually looking for ways to have a programming session pretty easy in VS code. Not very easy. Actually, but you can do it in VS code there. We talked about a new IDE. I forgot its name. It's a new startup. They're developing an IDE that's centered around running per programming sessions. It's easy to share your screen, easy to see double cursors, easy to edit different stuff. You can know who's doing what kind of like working on a shared Google doc, but with code. So there is a plugin. We found a plugin for a new VIM that's called instant.novim. I'll share it in the show notes as well if you're interested. And that's basically letting you do the same. You're starting a session. You get like this SSH hash and secret, of course, to let your partner connect to your local machine. And then you get a split screen. It shows you who's doing what it shows you the name next to the code that's written. You can see double cursors starting to run and typing stuff. There's a really cool demo on their GitHub page. So I'll put it below. And that's it. That's my finding this week. So I'm excited to try it next week. Yeah, cool. All right. I think. Yes. Okay. Yeah. So I don't think so. We had enough fun for today, I think. I think we did. Okay. So see you next week. This time we will thank you for the crowd. Thank you for everyone attending. Thank you. Yeah. All right. Bye. Bye.